Forwarded from 401 Ian Grigg (@RamonQuesada 🌷🇺🇸)
Forwarded from 395 Adam Back (@RamonQuesada 🌷🇺🇸)
Twitter
iang
@adam3us @wakgill Historically the block size debate was based on theoretical considerations (to be kind, most of it was opinion). We’ve now seen 2 large scale experiments with large blocks, so empirically we’ve a lot more info. In short, nothing much bad…
33 – How many people were involved in programming Bitcoin? Bear and Hal reviewed the code
"1. The Original Website - Satoshi Nakamoto
- Dr. Craig S. Wright & Ryan X. Charles."
2021 01 04
https://youtu.be/_E7iuVM4CIA
"1. The Original Website - Satoshi Nakamoto
- Dr. Craig S. Wright & Ryan X. Charles."
2021 01 04
https://youtu.be/_E7iuVM4CIA
https://observatorioblockchain.com/bitcoin/ray-dillinger-a-quien-satoshi-pidio-revisar-codigo-fuente-dice-que-bitcoin-es-un-desastre/#.X_nVozJoDKc.telegram
Ray Dillinger critica duramente en lo que se ha convertido Bitcoin
Ray Dillinger critica duramente en lo que se ha convertido Bitcoin
Noticias Blockchain | Observatorio Blockchain
Ray Dillinger critica duramente en lo que se ha convertido Bitcoin
Ray Dillinger crítica en lo que se ha convertido Bitcoin y muchas de las cosas que lo rodean, como la minería o los exchanges de criptomonedas
Who is Ray Dillinger? | Ramon Quesada
https://ramonquesada.com/english/who-is-ray-dillinger/
https://ramonquesada.com/english/who-is-ray-dillinger/
Ramon Quesada
Who is Ray Dillinger? | Ramon Quesada
"My background is mostly software QA and Natural-language processing. I got a couple of patents for a way to disambiguate pronouns in free text and autogeneration of queryable content from parsing free text.
The more remarkable discovery? That bitcoin may but hint at the depth of his work. When I contact a crypt
named Ray Dillinger, one of Satoshi's early (and initially sceptical) interlocutors, he insists that,
"intellectually speaking", approaching Satoshi's creation is "like being on the coastline of a new continent,
wondering what the eventual complete map will contain it will take decades, perhaps a century or more,
before new refinements and ideas become even remotely difficult to come up with."
What does Dillinger mean? Starting from the proposition that the most corrosive crimes against society
and individuals in the data age tend to involve falsification, whether at the hands of Enron, Bernie
Madoffor bankers flogging bent mortgages, Dillinger observes: "The rules of a consensus-history system
could, in principle, be as minimal or complete as we are able to express in a programming language. It is
possible, therefore, to extend the idea of a universally consistent history -- in which attempts to
misrepresent simply fail -- much further than simply recording monetary transactions. Can you imagine a
society in which most forms of falsification simply fail? "We can't build that yet. But with Nakamoto'sprotocol, we are starting to see how such a thing could be built."
At which point the question of who Satoshi is suddenly seems secondary. What Dillinger describes is an
internet in which all information does not look the same. The dawn of Web 3.0. And perhaps by the time we
have that, we'll also have the name of its creator | Andrew Smith is the author of Totally Wired: the Wild
Rise and Crazy Fall of the First Dotcom Dream, and Moondust. @wiresmith
https://www.gwern.net/docs/bitcoin/2014-smithset.pdf
Title: Desperately seeking Satoshi; From nowhere, bitcoin is now worth billions. Where did it come from?
Andrew Smithset off to find Satoshi Nakamoto, the mysterious genius behind the hit e-currency
Source: Sunday Times (London, England). (Mar. 2, 2014): News: p16.
Document Type: Article
Copyright : COPYRIGHT 2014 NI Syndication Limited. Sunday Times
http://www.sunday-times.co.uk
named Ray Dillinger, one of Satoshi's early (and initially sceptical) interlocutors, he insists that,
"intellectually speaking", approaching Satoshi's creation is "like being on the coastline of a new continent,
wondering what the eventual complete map will contain it will take decades, perhaps a century or more,
before new refinements and ideas become even remotely difficult to come up with."
What does Dillinger mean? Starting from the proposition that the most corrosive crimes against society
and individuals in the data age tend to involve falsification, whether at the hands of Enron, Bernie
Madoffor bankers flogging bent mortgages, Dillinger observes: "The rules of a consensus-history system
could, in principle, be as minimal or complete as we are able to express in a programming language. It is
possible, therefore, to extend the idea of a universally consistent history -- in which attempts to
misrepresent simply fail -- much further than simply recording monetary transactions. Can you imagine a
society in which most forms of falsification simply fail? "We can't build that yet. But with Nakamoto'sprotocol, we are starting to see how such a thing could be built."
At which point the question of who Satoshi is suddenly seems secondary. What Dillinger describes is an
internet in which all information does not look the same. The dawn of Web 3.0. And perhaps by the time we
have that, we'll also have the name of its creator | Andrew Smith is the author of Totally Wired: the Wild
Rise and Crazy Fall of the First Dotcom Dream, and Moondust. @wiresmith
https://www.gwern.net/docs/bitcoin/2014-smithset.pdf
Title: Desperately seeking Satoshi; From nowhere, bitcoin is now worth billions. Where did it come from?
Andrew Smithset off to find Satoshi Nakamoto, the mysterious genius behind the hit e-currency
Source: Sunday Times (London, England). (Mar. 2, 2014): News: p16.
Document Type: Article
Copyright : COPYRIGHT 2014 NI Syndication Limited. Sunday Times
http://www.sunday-times.co.uk
Me encanta como se estrujan el cerebro algunos, jejeje
"Adam Back ha comentado alguna vez, que pareciera que Satoshi era un outsider, al no tener referencias cypherpunks"
41:40
" Si alguien encuentra un borrador del WP eCash.pdf seguramente sea falso,
Debería llevar la referencia de bMoney de 1998"
33:10
2015 Análisis de metada del WP alojado en bitcoin.org
- uno 03 08 2008 (8 páginas)
- otro 23 04 2009 (9 páginas)
un párrafo mas, sobre incentivos, las fees como incentivos
Minuto 52
En dic 2013 Ray Dillinger pública en BitcoinTalk (parte) de la copia del código que recibió de Satoshi, de fecha 16 nov 2008
"¿Qué sabemos de Satoshi antes de publicar el whitepaper de Bitcoin? - L92" en YouTube
https://youtu.be/mgn6TOW1IHg
"Adam Back ha comentado alguna vez, que pareciera que Satoshi era un outsider, al no tener referencias cypherpunks"
41:40
" Si alguien encuentra un borrador del WP eCash.pdf seguramente sea falso,
Debería llevar la referencia de bMoney de 1998"
33:10
2015 Análisis de metada del WP alojado en bitcoin.org
- uno 03 08 2008 (8 páginas)
- otro 23 04 2009 (9 páginas)
un párrafo mas, sobre incentivos, las fees como incentivos
Minuto 52
En dic 2013 Ray Dillinger pública en BitcoinTalk (parte) de la copia del código que recibió de Satoshi, de fecha 16 nov 2008
"¿Qué sabemos de Satoshi antes de publicar el whitepaper de Bitcoin? - L92" en YouTube
https://youtu.be/mgn6TOW1IHg
YouTube
¿Qué sabemos de Satoshi antes de publicar el whitepaper de Bitcoin? - L92
El 31 de octubre de 2008 Satoshi Nakamoto hizo público el whitepaper de Bitcoin en la lista de correo de criptografía Metzdowd. 64 días después se minó el bloque génesis y 6 días más tarde lanzó la versión 0.1.0 del cliente de Bitcoin. De esos 70 días tenemos…
Re: Bitcoin P2P e-cash paper
From: Eugen Leitl <eugen () leitl ! org>
Date: 2008-11-17 19:37:11
Message-ID: 20081117193711.GP11544 () leitl ! org
[Download RAW message or body]
----- Forwarded message from Ray Dillinger <bear@sonic.net> -----
From: Ray Dillinger <bear@sonic.net>
Date: Fri, 14 Nov 2008 18:20:23 -0800
To: satoshi@vistomail.com
Cc: jamesd@echeque.com, cryptography@metzdowd.com
Subject: Re: Bitcoin P2P e-cash paper
X-Mailer: Evolution 2.6.3
Okay.... I'm going to summarize this protocol as I understand it.
I'm filling in some operational details that aren't in the paper
by supplementing what you wrote with what my own "design sense"
tells me are critical missing bits or "obvious" methodologies for
use.
First, people spend computer power creating a pool of coins to use
as money. Each coin is a proof-of-work meeting whatever criteria
were in effect for money at the time it was created. The time of
creation (and therefore the criteria) is checkable later because
people can see the emergence of this particular coin in the
transaction chain and track it through all its "consensus view"
spends. (more later on coin creation tied to adding a link).
When a coin is spent, the buyer and seller digitally sign a (blinded)
transaction record, and broadcast it to a bunch of nodes whose purpose
is keeping track of consensus regarding coin ownership. If someone
double spends, then the transaction record can be unblinded revealing
the identity of the cheater. This is done via a fairly standard cut-
and-choose algorithm where the buyer responds to several challenges
with secret shares, and the seller then asks him to "unblind" and
checks all but one, verifying that they do contain secret shares any
two of which are sufficient to identify the buyer. In this case the
seller accepts the unblinded spend record as "probably" containing
a valid secret share.
The nodes keeping track of consensus regarding coin ownership are in
a loop where they are all trying to "add a link" to the longest chain
they've so far recieved. They have a pool of reported transactions
which they've not yet seen in a "consensus" signed chain. I'm going
to call this pool "A". They attempt to add a link to the chain by
moving everything from pool A into a pool "L" and using a CPU-
intensive digital signature algorithm to sign the chain including
the new block L. This results in a chain extended by a block
containing all the transaction records they had in pool L, plus
the node's digital signature. While they do this, new
transaction records continue to arrive and go into pool A again
for the next cycle of work.
They may also recieve chains as long as the one they're trying to
extend while they work, in which the last few "links" are links
that are *not* in common with the chain on which they're working.
These they ignore. (? Do they ignore them? Under what
circumstances would these become necessary to ever look at again,
bearing in mind that any longer chain based on them will include
them?)
But if they recieve a _longer_ chain while working, they
immediately check all the transactions in the new links to make
sure it contains no double spends and that the "work factors" of
all new links are appropriate. If it contains a double spend,
then they create a "transaction" which is a proof of double
spending, add it to their pool A, broadcast it, and continue work.
If one of the "new" links has an inappropriate work factor (ie,
someone didn't put enough CPU into it for it to be "licit"
according to the rules) a new "transaction" which is a proof
of the protocol violation by the link-creating node is created,
broadcast, and added to pool A, and the chain is rejected. In
the case of no double spends and appropriate work factors for
all links not yet seen, they accept the new chain as consensus.
From: Eugen Leitl <eugen () leitl ! org>
Date: 2008-11-17 19:37:11
Message-ID: 20081117193711.GP11544 () leitl ! org
[Download RAW message or body]
----- Forwarded message from Ray Dillinger <bear@sonic.net> -----
From: Ray Dillinger <bear@sonic.net>
Date: Fri, 14 Nov 2008 18:20:23 -0800
To: satoshi@vistomail.com
Cc: jamesd@echeque.com, cryptography@metzdowd.com
Subject: Re: Bitcoin P2P e-cash paper
X-Mailer: Evolution 2.6.3
Okay.... I'm going to summarize this protocol as I understand it.
I'm filling in some operational details that aren't in the paper
by supplementing what you wrote with what my own "design sense"
tells me are critical missing bits or "obvious" methodologies for
use.
First, people spend computer power creating a pool of coins to use
as money. Each coin is a proof-of-work meeting whatever criteria
were in effect for money at the time it was created. The time of
creation (and therefore the criteria) is checkable later because
people can see the emergence of this particular coin in the
transaction chain and track it through all its "consensus view"
spends. (more later on coin creation tied to adding a link).
When a coin is spent, the buyer and seller digitally sign a (blinded)
transaction record, and broadcast it to a bunch of nodes whose purpose
is keeping track of consensus regarding coin ownership. If someone
double spends, then the transaction record can be unblinded revealing
the identity of the cheater. This is done via a fairly standard cut-
and-choose algorithm where the buyer responds to several challenges
with secret shares, and the seller then asks him to "unblind" and
checks all but one, verifying that they do contain secret shares any
two of which are sufficient to identify the buyer. In this case the
seller accepts the unblinded spend record as "probably" containing
a valid secret share.
The nodes keeping track of consensus regarding coin ownership are in
a loop where they are all trying to "add a link" to the longest chain
they've so far recieved. They have a pool of reported transactions
which they've not yet seen in a "consensus" signed chain. I'm going
to call this pool "A". They attempt to add a link to the chain by
moving everything from pool A into a pool "L" and using a CPU-
intensive digital signature algorithm to sign the chain including
the new block L. This results in a chain extended by a block
containing all the transaction records they had in pool L, plus
the node's digital signature. While they do this, new
transaction records continue to arrive and go into pool A again
for the next cycle of work.
They may also recieve chains as long as the one they're trying to
extend while they work, in which the last few "links" are links
that are *not* in common with the chain on which they're working.
These they ignore. (? Do they ignore them? Under what
circumstances would these become necessary to ever look at again,
bearing in mind that any longer chain based on them will include
them?)
But if they recieve a _longer_ chain while working, they
immediately check all the transactions in the new links to make
sure it contains no double spends and that the "work factors" of
all new links are appropriate. If it contains a double spend,
then they create a "transaction" which is a proof of double
spending, add it to their pool A, broadcast it, and continue work.
If one of the "new" links has an inappropriate work factor (ie,
someone didn't put enough CPU into it for it to be "licit"
according to the rules) a new "transaction" which is a proof
of the protocol violation by the link-creating node is created,
broadcast, and added to pool A, and the chain is rejected. In
the case of no double spends and appropriate work factors for
all links not yet seen, they accept the new chain as consensus.
If the new chain is accepted, then they give up on adding their
current link, dump all the transactions from pool L back into pool
A (along with transactions they've recieved or created since
starting work), eliminate from pool A those transaction records
which are already part of a link in the new chain, and start work
again trying to extend the new chain.
If they complete work on a chain extended with their new link, they
broadcast it and immediately start work on another new link with
all the transactions that have accumulated in pool A since they
began work.
Do I understand it correctly?
Biggest Technical Problem:
Is there a mechanism to make sure that the "chain" does not consist
solely of links added by just the 3 or 4 fastest nodes? 'Cause a
broadcast transaction record could easily miss those 3 or 4 nodes
and if it does, and those nodes continue to dominate the chain, the
transaction might never get added.
To remedy this, you need to either ensure provable propagation of
transactions, or vary the work factor for a node depending on how
many links have been added since that node's most recent link.
Unfortunately, both measures can be defeated by sock puppets.
This is probably the worst problem with your protocol as it
stands right now; you need some central point to control the
identities (keys) of the nodes and prevent people from making
new sock puppets.
Provable propagation would mean that When Bob accepts a new chain
from Alice, he needs to make sure that Alice has (or gets) all
transactions in his "A" and "L" pools. He sends them, and
Alice sends back a signed hash to prove she got them. Once
Alice has recieved this block of transactions, if any subsequent
chains including a link added by Alice do not include those
transactions at or before that link, then Bob should be able to
publish the block he sent Alice, along with her signature, in a
transaction as proof that Alice violated protocol. Sock puppets
defeat this because Alice just signs subsequent chains using a
new key, pretending to be a different node.
If we go with varying the work factor depending on how many new
links there are, then we're right back to domination by the 3
or 4 fastest nodes, except now they're joined by 600 or so
sock puppets which they use to avoid the work factor penalty.
If we solve the sock-puppet issue, or accept that there's a central
point controlling the generation of new keys, then generation of
coins should be tied to the act of successfully adding a block to
the "consensus" chain. This is simple to do; creation of a coin
is a transaction, it gets added along with all the other transactions
in the block. But you can only create one coin per link, and of
course if your version of the chain isn't the one that gets accepted,
then in the "accepted" view you don't have the coin and can't spend
it. This gives the people maintaining the consensus database a
reason to spend CPU cycles, especially since the variance in work
factor by number of links added since their own last link (outlined
above) guarantees that everyone, not just the 3 or 4 fastest nodes,
occasionally gets the opportunity to create a coin.
Also, the work requirement for adding a link to the chain should
vary (again exponentially) with the number of links added to that
chain in the previous week, causing the rate of coin generation
(and therefore inflation) to be strictly controlled.
You need coin aggregation for this to scale. There needs to be
a "provable" transaction where someone retires ten single coins
and creates a new coin with denomination ten, etc. This is not
too hard, using the same infrastructure you've already got; it
simply becomes part of the chain, and when the chain is accepted
consensus, then everybody can see that it happened.
Bear
-----------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" https://marc.info/?l=cypherpunks&m=122695116217709&w=2
current link, dump all the transactions from pool L back into pool
A (along with transactions they've recieved or created since
starting work), eliminate from pool A those transaction records
which are already part of a link in the new chain, and start work
again trying to extend the new chain.
If they complete work on a chain extended with their new link, they
broadcast it and immediately start work on another new link with
all the transactions that have accumulated in pool A since they
began work.
Do I understand it correctly?
Biggest Technical Problem:
Is there a mechanism to make sure that the "chain" does not consist
solely of links added by just the 3 or 4 fastest nodes? 'Cause a
broadcast transaction record could easily miss those 3 or 4 nodes
and if it does, and those nodes continue to dominate the chain, the
transaction might never get added.
To remedy this, you need to either ensure provable propagation of
transactions, or vary the work factor for a node depending on how
many links have been added since that node's most recent link.
Unfortunately, both measures can be defeated by sock puppets.
This is probably the worst problem with your protocol as it
stands right now; you need some central point to control the
identities (keys) of the nodes and prevent people from making
new sock puppets.
Provable propagation would mean that When Bob accepts a new chain
from Alice, he needs to make sure that Alice has (or gets) all
transactions in his "A" and "L" pools. He sends them, and
Alice sends back a signed hash to prove she got them. Once
Alice has recieved this block of transactions, if any subsequent
chains including a link added by Alice do not include those
transactions at or before that link, then Bob should be able to
publish the block he sent Alice, along with her signature, in a
transaction as proof that Alice violated protocol. Sock puppets
defeat this because Alice just signs subsequent chains using a
new key, pretending to be a different node.
If we go with varying the work factor depending on how many new
links there are, then we're right back to domination by the 3
or 4 fastest nodes, except now they're joined by 600 or so
sock puppets which they use to avoid the work factor penalty.
If we solve the sock-puppet issue, or accept that there's a central
point controlling the generation of new keys, then generation of
coins should be tied to the act of successfully adding a block to
the "consensus" chain. This is simple to do; creation of a coin
is a transaction, it gets added along with all the other transactions
in the block. But you can only create one coin per link, and of
course if your version of the chain isn't the one that gets accepted,
then in the "accepted" view you don't have the coin and can't spend
it. This gives the people maintaining the consensus database a
reason to spend CPU cycles, especially since the variance in work
factor by number of links added since their own last link (outlined
above) guarantees that everyone, not just the 3 or 4 fastest nodes,
occasionally gets the opportunity to create a coin.
Also, the work requirement for adding a link to the chain should
vary (again exponentially) with the number of links added to that
chain in the previous week, causing the rate of coin generation
(and therefore inflation) to be strictly controlled.
You need coin aggregation for this to scale. There needs to be
a "provable" transaction where someone retires ten single coins
and creates a new coin with denomination ten, etc. This is not
too hard, using the same infrastructure you've already got; it
simply becomes part of the chain, and when the chain is accepted
consensus, then everybody can see that it happened.
Bear
-----------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" https://marc.info/?l=cypherpunks&m=122695116217709&w=2
Telegram´s Channels
@SatoshisQuotes
@BitCoin2008_2010
@BitCoinWP
@BitCoinSourceForge
@BitcoinTalkForum
@Hal_Finney
@RayDillinger
@IanGrigg
@JosephVaughnPerling
@GavinAndresen1
@MikeHearn
@StefanMatthews
@CalvinAyre
@Jimmy_Nguyen
@SteveShadders
@GeorgeGilder
@DavidRees
@DaveKleiman
@KleimanVsCSW
@UyenTNguyen
Craig Wright
@Craig_Wright. 40 Members
@CSW_Academic 95 Members
@CSW_Articles 104 Members
@CSW_Books
@CSW_Business
@CSW_Cybersecurity
@CSW_Economics
@CSW_Ideology
@CSW_interviews
@CSW_interviewsVideos
@CSW_Legal
@CSW_Patent
@CSW_Religion
@CSW_Satoshi 199 Members
@CSW_Slack. 480 Members
@CSW_VideoTalks
@CSW_Videos
@CSW_Asperger
@CSW_Gallery
@theArtofBitcoin 64 Members
@TheSatoshiAffaire 50 Mem.
@DonLynam
CSW personal Batlles
@BitCoinWP
@Double_Spend
@BitCoinDatabaseOwnership
@BitCoin_Domain
@RamonQuesadaNews -140
@SatoshisQuotes
@BitCoin2008_2010
@BitCoinWP
@BitCoinSourceForge
@BitcoinTalkForum
@Hal_Finney
@RayDillinger
@IanGrigg
@JosephVaughnPerling
@GavinAndresen1
@MikeHearn
@StefanMatthews
@CalvinAyre
@Jimmy_Nguyen
@SteveShadders
@GeorgeGilder
@DavidRees
@DaveKleiman
@KleimanVsCSW
@UyenTNguyen
Craig Wright
@Craig_Wright. 40 Members
@CSW_Academic 95 Members
@CSW_Articles 104 Members
@CSW_Books
@CSW_Business
@CSW_Cybersecurity
@CSW_Economics
@CSW_Ideology
@CSW_interviews
@CSW_interviewsVideos
@CSW_Legal
@CSW_Patent
@CSW_Religion
@CSW_Satoshi 199 Members
@CSW_Slack. 480 Members
@CSW_VideoTalks
@CSW_Videos
@CSW_Asperger
@CSW_Gallery
@theArtofBitcoin 64 Members
@TheSatoshiAffaire 50 Mem.
@DonLynam
CSW personal Batlles
@BitCoinWP
@Double_Spend
@BitCoinDatabaseOwnership
@BitCoin_Domain
@RamonQuesadaNews -140
Deryk Makgill, who is a felon under various laws.. (@wakgill) twitteó: Wow! Ray Dillinger (one of first people to reply to Satoshi/comment on Bitcoin code) wrote an email declaring it a "failure" today.
'The scarcity of block chain space has led people to re-invent every last feature of the banks they thought they were going to be escaping.' https://t.co/LWGZ8cqE3g https://twitter.com/wakgill/status/1343946053205307394?s=20
'The scarcity of block chain space has led people to re-invent every last feature of the banks they thought they were going to be escaping.' https://t.co/LWGZ8cqE3g https://twitter.com/wakgill/status/1343946053205307394?s=20
Twitter
Deryk Makgill
Wow! Ray Dillinger (one of first people to reply to Satoshi/comment on Bitcoin code) wrote an email declaring it a "failure" today. 'The scarcity of block chain space has led people to re-invent every last feature of the banks they thought they were going…
Básicamente la mejor información sobre el código la aportó Ray Dillinger, en el 2013 publicada en BitcoinTalk, bajo el seudónimo de Cryddit
Copyright (c) 2008 Satoshi Nakamoto
Bitcoin source from November 2008.
December 23, 2013
https://bitcointalk.org/index.php?topic=382374.0
Copyright (c) 2008 Satoshi Nakamoto
Bitcoin source from November 2008.
December 23, 2013
https://bitcointalk.org/index.php?topic=382374.0
Básicamente la mejor información sobre el código la aportó Ray Dillinger, en el 2013 publicada en BitcoinTalk, bajo el seudónimo de Cryddit
Copyright (c) 2008 Satoshi Nakamoto
Bitcoin source from November 2008.
December 23, 2013
https://www.bitpost.app/tx/4d7529062f42a0251cf7096cbb01a1e5bb8c492965a982bea72b6a5a6434abaa
Copyright (c) 2008 Satoshi Nakamoto
Bitcoin source from November 2008.
December 23, 2013
https://www.bitpost.app/tx/4d7529062f42a0251cf7096cbb01a1e5bb8c492965a982bea72b6a5a6434abaa
Forwarded from 2010 360-2 - One MB block size limit 1Mb (@RamonQuesada 🌷)
Re: Permanently keeping the 1MB (anti-spam) restriction is a great idea ...
February 07, 2015
Cryddit / @RayDillinger
For what it's worth:
I'm the guy who went over the blockchain stuff in Satoshi's first cut of the bitcoin code. Satoshi didn't have a 1MB limit in it. The limit was originally Hal Finney's idea. Both Satoshi and I objected that it wouldn't scale at 1MB. Hal was concerned about a potential DoS attack though, and after discussion, Satoshi agreed. The 1MB limit was there by the time Bitcoin launched. But all 3 of us agreed that 1MB had to be temporary because it would never scale.
Several attempted "abuses" of the blockchain under the 1MB limit have proved Hal right about needing the limit at least for launching purposes. A lot of people wanted to piggyback extraneous information onto the blockchain, and before miners (and the community generally) realized that blockchain space was a valuable resource they would have allowed it. The blockchain would probably be several times as big a download now if that limit hadn't been in place, because it would have a lot of random 1-satoshi transactions that exist only to encode information for altcoins etc.
At this point I don't think random schmoes who would allow just any transaction are getting a lot of blocks. The people who have made a major investment in hashing power are doing the math to figure out which tx are worthwhile to include because block propagation time (and therefore the risk of orphan blocks) is proportional to block size. So at this point I think blockchain bloat as such is no longer likely to a problem, and the 1MB limit is no longer necessary. It has been more-or-less replaced by a profitability limit that motivates people to not waste blockchain bandwidth, and miners are now reliably dropping transactions that don't pay fees. "
https://bitcointalk.org/index.php?topic=946236.msg10388435#msg10388435
February 07, 2015
Cryddit / @RayDillinger
For what it's worth:
I'm the guy who went over the blockchain stuff in Satoshi's first cut of the bitcoin code. Satoshi didn't have a 1MB limit in it. The limit was originally Hal Finney's idea. Both Satoshi and I objected that it wouldn't scale at 1MB. Hal was concerned about a potential DoS attack though, and after discussion, Satoshi agreed. The 1MB limit was there by the time Bitcoin launched. But all 3 of us agreed that 1MB had to be temporary because it would never scale.
Several attempted "abuses" of the blockchain under the 1MB limit have proved Hal right about needing the limit at least for launching purposes. A lot of people wanted to piggyback extraneous information onto the blockchain, and before miners (and the community generally) realized that blockchain space was a valuable resource they would have allowed it. The blockchain would probably be several times as big a download now if that limit hadn't been in place, because it would have a lot of random 1-satoshi transactions that exist only to encode information for altcoins etc.
At this point I don't think random schmoes who would allow just any transaction are getting a lot of blocks. The people who have made a major investment in hashing power are doing the math to figure out which tx are worthwhile to include because block propagation time (and therefore the risk of orphan blocks) is proportional to block size. So at this point I think blockchain bloat as such is no longer likely to a problem, and the 1MB limit is no longer necessary. It has been more-or-less replaced by a profitability limit that motivates people to not waste blockchain bandwidth, and miners are now reliably dropping transactions that don't pay fees. "
https://bitcointalk.org/index.php?topic=946236.msg10388435#msg10388435