Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary

[Eric Lombrozo <elombrozo@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 8064 bytes --]


> On Jul 29, 2015, at 2:59 AM, Mike Hearn <hearn@vinumeris.com> wrote:
> 
> I do love history lessons from people who weren't actually there.
> 
> Let me correct your misconceptions.
> 
> 
> Initially there was no block size limit - it was thought that the fee market would naturally develop and would impose economic constraints on growth.
> 
> The term "fee market" was never used back then, and Satoshi did not ever postulate economic constraints on growth. Back then the talk was (quite sensibly) how to grow faster, not how to slow things down!

Irrelevant what term was used - and as brilliant as Satoshi might have been at some things, he obviously got this one wrong.
> 


> But this hypothesis failed after a sudden influx of new uses. It was still too easy to attack the network. This idea had to wait until the network was more mature to handle things.
> 
> No such event happened, and the hypothesis of which you talk never existed.
> 

Nobody threatened to start mining huge blocks given how relatively inexpensive it was to mine back then?

> 
> Enter a “temporary” anti-spam measure - a one megabyte block size limit.
> 
> The one megabyte limit was nothing to do with anti spam. It was a quick kludge to try and avoid the user experience degrading significantly in the event of a "DoS block", back when everyone used Bitcoin-Qt. The fear was that some malicious miner would generate massive blocks and make the wallet too painful to use, before there were any alternatives.

I thought I clarified this in an earlier post - I meant DoS. Please don’t digress on such stupid technicalities.


> The plan was to remove it once SPV wallets were widespread. But Satoshi left before that happened.
> 

Guess what? SPV wallets are still not particularly widespread…and those that are out there are notoriously terrible at detecting network forks and making sure they are on the right one.

> 
> Now on to your claims:
> 
> 1) We never really got to test things out…a fee market never really got created, we never got to see how fees would really work in practice.
> 
> The limit had nothing to do with fees. Satoshi explicitly wanted free transactions to last as long as possible.

Something has to limit block sizes in practice. Perhaps Satoshi was not constrained by finite computational resources, but the rest of us sure are. The fact that without imposing a hardcoded limit Satoshi couldn’t figure out a way to keep the DoS-block guys away suggests he didn’t have this fully worked out.

I understand that initially it was desirable that transactions be free…but surely even Satoshi understood this couldn’t be perpetually self-sustaining…and that the ability to bid for inclusion in blocks would eventually become a crucial component of the network. Or were fees just added for decoration?

We’re already more than six years into this. When were these mechanisms going to be developed and tested? After 10 years? 20? Perhaps after 1024 years?(https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki <https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki>)

> 
> 2) Turns out the vast majority of validation nodes have little if anything to do with mining - validators do not get compensated…validation cost is externalized to the entire network.
> 
> Satoshi explicitly envisioned a future where only miners ran nodes, so it had nothing to do with this either.

And Satoshi was dead wrong. As others have pointed out in this thread, while this is certainly of historical interest, it is irrelevant from an engineering perspective.


> Validators validate for themselves. Calculating a local UTXO set and then not using it for anything doesn't help anyone. SPV wallets need filtering and serving capability, but a computer can filter and serve the chain without validating it.

Right. Turns out the ledger structure is terrible for constructing the kinds of proofs that are most important to validators - i.e. whether an output exists, what its script and amounts are, whether it’s been spent, etc…

Despite Satoshi’s brilliance, software architecture was obviously not his strongest suit. But it didn’t really matter at the beginning since this was really an experiment…and he succeeded in making his point.

> The only purposes non-mining, non-rpc-serving, non-Qt-wallet-sustaining full nodes are needed for with today's network are:
> Filtering the chain for bandwidth constrained SPV wallets (nb: you can run an SPV wallet that downloads all transactions if you want). But this could be handled by specialised nodes, just like we always imagined in future not every node will serve the entire chain but only special "archival nodes"
> 
> Relaying validated transactions so SPV wallets can stick a thumb into the wind and heuristically guess whether a transaction is valid or not. This is useful for a better user interface.
> 
> Storing the mempool and filtering/serving it so SPV wallets can find transactions that were broadcast before they started, but not yet included in a block. This is useful for a better user interface.
> Outside of serving lightweight P2P wallets there's no purpose in running a P2P node if you aren't mining, or using it as a trusted node for your own operations.
> 
> And if one day there aren't enough network nodes being run by volunteers to service all the lightweight wallets, then we can easily create an incentive scheme to fix that.

Yes, let’s wait until things are about to break before even beginning to address the issue…because we can “easily create” anything we haven’t invented yet at the last minute.

> 
> 
> 3) Miners don’t even properly validate blocks. And the bigger the blocks get, the greater the propensity to skip this step. Oops!
> 
> Miners who don't validate have a habit of bleeding money:   that's the system working as designed.
> 

Erm…most miners just trust mining pool operators to validate blocks for them…and some of the biggest pools have been blatantly cutting corners. Yes, a few pools might have temporarily bled a little…but properly validating is probably not the equilibrium strategy…and as time goes on, they are likely to start cutting corners again. Whether they ultimately bleed money isn’t really the point - many believe that cutting corners is actually a rational strategy. If you want to discuss the game theory behind this, fine…but the fact some of the biggest mining pool operators are on record saying they are likely to continue doing this is enough to seriously put to question one of the most fundamental assumptions behind the network security model.

> 
> 4) A satisfactory mechanism for thin clients to be able to securely obtain reasonably secure, short proofs for their transactions never materialized.
> 
> It did. I designed it. The proofs are short and "reasonably secure" in that it would be a difficult and expensive attack to mount.

You have my respect for BIP37, Mike. I know you can do amazing work. You actually made SPV semi-useful despite inheriting such crappy data structures. This is indeed to be respected.

> 
> But as is so often the case with Bitcoin Core these days, someone who came along much later has retroactively decided that the work done so far fails to meet some arbitrary and undefined level of perfection. "Satisfactory" and "reasonably secure" don't mean anything, especially not coming from someone who hasn't done the work, so why should anyone care about that opinion of yours?

Not done the work?

I’m one of the very few developers in this space that has actually tried *hard* to make your BIP37 work. Amongst the desktop wallets listed on bitcoin.org <http://bitcoin.org/>, there are only two that have always supported SPV (or at least I think MultiBit has always supported it, perhaps I’m wrong). One is MultiBit, the other one is mine. I give you credit for your work…perhaps you could be generous enough to extend me some credit too?


[-- Attachment #1.2: Type: text/html, Size: 13217 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]