From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 97A9148C for ; Wed, 29 Jul 2015 09:59:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 79AFD7C for ; Wed, 29 Jul 2015 09:59:44 +0000 (UTC) Received: by iodd187 with SMTP id d187so15958906iod.2 for ; Wed, 29 Jul 2015 02:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vinumeris.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KTfW6aZr4a0zu5V6jotJW6FuHlWfbA8w5NevCzWtoCE=; b=mwlRF4YsYag2AjdaKJrP+jicgJ/RdzBvt6rY3lLQErx0vaEDbiEETV8DHhEasYakPJ hH01gTP//3gD1iXmYbSG4drWYtSZhUGEQiG5tjdEgdDkQz+e7WMH1T69T/SsGrCq+nr7 6+Xv8VFAvX9Hqq3xqGqOZ8aKVJH3ClxpqKA3U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KTfW6aZr4a0zu5V6jotJW6FuHlWfbA8w5NevCzWtoCE=; b=QVgCvMwfudBytLusb6gO3NwVBPk5F7+QQGyXa6auIh+paOqTFOpQMzXkNBi+OVI4F+ ActkYn2FVLNP5nlE9q4Xg0LUc4pWgxRtROW73XzrEUdqnKYtVuvlc7uQXGc0ijs1wSNO WDe8XLqbXjjSzrCg/8I6G7N9CrrgVHdpiFd42Zy9B77QrRQq6OmzkSvLT0kq05GY/B2t SmoJWV4ngHnJntuKe4+G+19CbrAsMX/Oq4pPUT9P3mGxdzsdwEateGaAIi0XfNC5JFEi yI7QjN3UjwbcKhqfZl9j9b7IUjy/KdJMmPgJc2j/jBjmsHNo34MgTYEAAFIapsCQdG+u q5Zg== X-Gm-Message-State: ALoCoQldYqufItkQfalhtyNifo6TWxeFeOAByIAEtOwXtFwhxyALF4Qg7n3ocrsSjf68uTInNMqz MIME-Version: 1.0 X-Received: by 10.107.129.215 with SMTP id l84mr66679ioi.78.1438163983919; Wed, 29 Jul 2015 02:59:43 -0700 (PDT) Received: by 10.50.108.111 with HTTP; Wed, 29 Jul 2015 02:59:43 -0700 (PDT) In-Reply-To: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com> References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com> Date: Wed, 29 Jul 2015 11:59:43 +0200 Message-ID: From: Mike Hearn To: Eric Lombrozo Content-Type: multipart/alternative; boundary=001a113ec6ac6406cb051c00a573 X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 09:59:45 -0000 --001a113ec6ac6406cb051c00a573 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 stil= l > too easy to attack the network. This idea had to wait until the network w= as > more mature to handle things. > No such event happened, and the hypothesis of which you talk never existed. > Enter a =E2=80=9Ctemporary=E2=80=9D anti-spam measure - a one megabyte bl= ock 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=E2=80=A6a 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 anythin= g > to do with mining - validators do not get compensated=E2=80=A6validation = 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 includ= ed 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=E2=80=99t even properly validate blocks. And the bigger the b= locks > 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 obtai= n > 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? --001a113ec6ac6406cb051c00a573 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I do love history lessons from people who weren't actu= ally there.

Let me correct your misconceptions.


Initially there was no block size limit - it was though= t that the fee market would naturally develop and would impose economic con= straints on growth.

The term "fee mar= ket" was never used back then, and Satoshi did not ever postulate econ= omic constraints on growth. Back then the talk was (quite sensibly) how to = grow faster, not how to slow things down!

=C2=A0
But this hypothesis failed after a sudde= n influx of new uses. It was still too easy to attack the network. This ide= a had to wait until the network was more mature to handle things.

No such event happened, and the hypothesis of wh= ich you talk never existed.

=C2=A0
Enter a =E2=80=9Ctemporary=E2=80=9D 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 t= ry and avoid the user experience degrading significantly in the event of a = "DoS block", back when everyone used Bitcoin-Qt. The fear was tha= t some malicious miner would generate massive blocks and make the wallet to= o painful to use, before there were any alternatives.

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

=C2=A0
Now o= n to your claims:

1) We = never really got to test things out=E2=80=A6a fee market never really got c= reated, 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.
=C2=A0
2) Turns out the vast majority = of validation nodes have little if anything to do with mining - validators = do not get compensated=E2=80=A6validation cost is externalized to the entir= e network.

Satoshi explicitly envisione= d a future where only miners ran nodes, so it had nothing to do with this e= ither.

Validators validate for themselves. Calcula= ting a local UTXO set and then not using it for anything doesn't help a= nyone. SPV wallets need filtering and serving capability, but a computer ca= n filter and serve the chain without validating it.

The only purposes non-mining, non-rpc-serving, non-Qt-wallet-sustaining f= ull nodes are needed for with today's network are:
  1. Fi= ltering 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 e= very node will serve the entire chain but only special "archival nodes= "

  2. Relaying validated transactions so SPV wallets can s= tick 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 transa= ctions that were broadcast before they started, but not yet included in a b= lock. This is useful for a better user interface.
Outside of = serving lightweight P2P wallets there's no purpose in running a P2P nod= e if you aren't mining, or using it as a trusted node for your own oper= ations.

And if one day there aren't enou= gh network nodes being run by volunteers to service all the lightweight wal= lets, then we can easily create an incentive scheme to fix that.
= =C2=A0

3) Miners don=E2= =80=99t even properly validate blocks. And the bigger the blocks get, the g= reater the propensity to skip this step. Oops!

Miners who don't validate have a habit of bleeding money: =C2= =A0 that's the system working as designed.

=C2= =A0
4) A satisfactory mechanism for thi= n 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&qu= ot; 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 d= one so far fails to meet some arbitrary and undefined level of perfection. = "Satisfactory" and "reasonably secure" don't mean a= nything, especially not coming from someone who hasn't done the work, s= o why should anyone care about that opinion of yours?

<= div>
--001a113ec6ac6406cb051c00a573--