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

Mike Hearn hearn at vinumeris.com
Wed Jul 29 09:59:43 UTC 2015


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!



> 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.



> 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.

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


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.


> 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.

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.

The only purposes non-mining, non-rpc-serving, non-Qt-wallet-sustaining
full nodes are needed for with today's network are:

   1. 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"

   2. 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.

   3. 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.


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.



> 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.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150729/79c8c15d/attachment-0001.html>


More information about the bitcoin-dev mailing list