public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <hearn@vinumeris.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
Date: Wed, 29 Jul 2015 11:59:43 +0200	[thread overview]
Message-ID: <CA+w+GKTfPXkVPaCC+3ZsQv=_DPMHoRwbigS40Testpyq4rZxsw@mail.gmail.com> (raw)
In-Reply-To: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4318 bytes --]

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?

[-- Attachment #2: Type: text/html, Size: 5720 bytes --]

  parent reply	other threads:[~2015-07-29  9:59 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-28 22:25 [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
2015-07-29  0:43 ` Jean-Paul Kogelman
2015-07-29  0:44   ` Eric Lombrozo
2015-07-29  0:46   ` Mark Friedenbach
2015-07-29  0:55     ` Eric Lombrozo
2015-07-29  2:40       ` Eric Lombrozo
2015-07-29  3:37         ` Eric Lombrozo
2015-07-29  3:46           ` Milly Bitcoin
2015-07-29  5:17             ` Eric Lombrozo
2015-07-29 11:18         ` Thomas Zander
2015-07-29  9:59 ` Mike Hearn [this message]
2015-07-29 10:43   ` Eric Lombrozo
2015-07-29 11:15     ` Mike Hearn
2015-07-29 12:03       ` Eric Lombrozo
2015-07-29 12:13         ` Thomas Zander
2015-07-29 17:17       ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Raystonn .
2015-07-29 19:56       ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Owen
2015-07-29 20:09         ` Gregory Maxwell
2015-07-29 21:28           ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Raystonn .
2015-07-29 22:11             ` Venzen Khaosan
2015-07-29 23:10               ` Raystonn .
2015-07-30  3:49                 ` Adam Back
2015-07-30  4:51                   ` Andrew LeCody
2015-07-30  8:21                     ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
2015-07-30  9:15                       ` Eric Lombrozo
2015-07-30 12:29                       ` Gavin
2015-07-30 12:50                         ` Pieter Wuille
2015-07-30 14:03                           ` Thomas Zander
2015-07-30 14:05                           ` Gavin Andresen
2015-07-30 14:28                             ` Pieter Wuille
2015-07-30 15:36                             ` Jorge Timón
2015-07-30 23:33                         ` Eric Lombrozo
2015-07-31  0:15                           ` Milly Bitcoin
2015-07-31 21:30                             ` Jorge Timón
2015-07-31 21:43                               ` Eric Lombrozo
2015-07-31  6:42                           ` Thomas Zander
2015-07-31 20:45                             ` Eric Lombrozo
2015-07-31 20:57                               ` Eric Lombrozo
2015-08-01 20:22                               ` John T. Winslow
2015-08-01 21:05                                 ` Pieter Wuille
2015-07-30  9:16                   ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Venzen Khaosan
2015-07-30  9:38                     ` Jorge Timón
2015-07-30 13:33                       ` Venzen Khaosan
2015-07-30 14:10                         ` Jorge Timón
2015-07-30 14:52                       ` Thomas Zander
2015-07-30 15:24                         ` Bryan Bishop
2015-07-30 15:55                           ` Gavin Andresen
2015-07-30 17:24                             ` Thomas Zander
2015-07-31 15:27                             ` Bryan Bishop
2015-07-30 16:07                           ` Thomas Zander
2015-07-30 17:42                             ` Thomas Zander
2015-07-30 18:02                               ` Mark Friedenbach
2015-07-31  0:22                                 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
2015-07-31  8:06                                 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Thomas Zander
2015-07-30 15:41                         ` Jorge Timón
2015-07-30  9:44             ` odinn
2015-07-29 20:23         ` [bitcoin-dev] Why Satoshi's temporary anti-spam measureisn't temporary Raystonn .
2015-07-29 11:29     ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Thomas Zander
2015-07-29 18:00     ` Jorge Timón
2015-07-30  7:08       ` Thomas Zander
2015-07-29 16:53   ` Gregory Maxwell
2015-07-29 17:30     ` Sriram Karra
2015-07-29 18:03     ` Mike Hearn
2015-07-29 19:53       ` Gregory Maxwell
2015-07-30 14:15         ` Thomas Zander
2015-07-30  9:05       ` odinn
2015-07-31  1:25 Raystonn
2015-07-31  3:18 ` Milly Bitcoin
     [not found] <f9e27b28-f967-45f7-bd1b-c427534ade9c@me.com>
2015-07-31 23:05 ` Jean-Paul Kogelman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+w+GKTfPXkVPaCC+3ZsQv=_DPMHoRwbigS40Testpyq4rZxsw@mail.gmail.com' \
    --to=hearn@vinumeris.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=elombrozo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox