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 13:15:49 +0200 [thread overview]
Message-ID: <CA+w+GKTZV5sgXNU_xoBby1_X6eae=5_vhENmyKY0yxWHcBiU5g@mail.gmail.com> (raw)
In-Reply-To: <D25BD175-7099-4A6B-89BB-A35E94F555A9@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6810 bytes --]
>
> Irrelevant what term was used - and as brilliant as Satoshi might have
> been at some things, he obviously got this one wrong.
>
I don't think it's obvious. You may disagree, but don't pretend any of this
stuff is obvious.
Consider this: the highest Bitcoin tx fees can possibly go is perhaps a
little higher than what our competition charges. Too much higher than that,
and people will just say, you know what .... I'll make a bank transfer.
It's cheaper and not much slower, sometimes no slower at all.
And now consider that in many parts of the world bank transfers are free.
They aren't actually free, of course, but they *appear* to be free because
the infrastructure for doing them is cross subsidised by the fees on other
products and services, or hidden in the prices of goods sold.
So that's a market reality Bitcoin has to handle. It's already more
expensive than the competition sometimes, but luckily not much more, and
anyway Bitcoin has some features those other systems lack (and vice versa).
So it can still be competitive.
But your extremely vague notion of a "fee market" neglects to consider that
it already exists, and it's not a market of "Bitcoin users buying space in
Bitcoin blocks". It's "users paying to move money".
You can argue with this sort of economic logic if you like, but don't claim
this stuff is obvious.
Nobody threatened to start mining huge blocks given how relatively
> inexpensive it was to mine back then?
>
Not that I recall. It wasn't a response to any actual event, I think, but
rather a growing realisation that the code was full of DoS attacks.
> 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.
>
The most popular mobile wallet (measured by installs) on Android is SPV. It
has between 500,000 and 1 million installs, whilst Coinbase has not yet
crossed the 500,000 mark. One of the most popular wallets on iOS is SPV. If
we had SPV wallets with better user interfaces on desktops, they'd be more
popular there too (perhaps MultiBit HD can recapture some lost ground).
So I would argue that they are in fact very widespread.
Likewise, they are not "notoriously terrible" at detecting chain forks.
That's a spurious idea that you and Patrick have been pushing lately, but
they detect them and follow reorgs across them according to the SPV
algorithm, which is based on most work done. This is exactly what they are
designed to do.
Contrast this with other lightweight wallets which either don't examine the
block chain or implement the algorithm incorrectly, and I fail to see how
this can be described as "notoriously terrible".
> 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?
>
Fees were added as a way to get money to miners in a fair and decentralised
way.
Attaching fees directly to all transactions is certainly one way to use
that, but it's not the only way. As noted above, our competitors prefer a
combination of price-hiding and cross subsidisation. Both of these can be
implemented with tx fees, but not necessarily by trying to artificially
limit supply, which is economically nonsensical.
> 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)
>
Maybe when there is a need? I already discussed this topic of need here:
https://medium.com/@octskyward/hashing-7d04a887acc8
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…
>
Validators don't require proofs. That's why they are validators.
I think you're trying to say the block chain doesn't provide the kinds of
proofs that are most important to lightweight wallets. But I would
disagree. Even with UTXO commitments, there can still be double spends out
there in the networks memory pools you are unaware of. Merely being
presented with a correctly signed transaction doesn't tell you a whole lot
..... if you wait for a block, you get the same level of proof regardless
of whether there are UTXO commitments or not. If you don't then you still
have to have some trust in your peers that you are seeing an accurate and
full view of network traffic.
So whilst there are ways to make the protocol incrementally better, when
you work through the use cases for these sorts of data structures and ask
"how will this impact the user experience", the primary candidates so far
don't seem to make much difference.
Remote attestation from secure hardware would make a big difference though.
Then you could get rid of the waiting times entirely because you know the
sending wallet won't double spend.
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.
>
bitcoinj already has a micropayment channel implementation in it. There's a
bit of work required to glue everything together, but it's not a massive
project to start using this to pay nodes for their services.
But it's not needed right now: serving these clients is so darn cheap. And
there is plenty of room for optimising things still further!
> 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, 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?
>
MultiBit has always supported it. I apologise for implying you have not
built a wallet. I think yours is mSIGNA, right? Did it used to be called
something else? I recognise the website design but must admit, I have not
heard of mSIGNA before.
Regardless, as a fellow implementor, I would appreciate it more if you
designed and implemented upgrades, rather than just trashing the work done
so far as "notoriously terrible", Satoshi as "not a systems architect" and
so on.
[-- Attachment #2: Type: text/html, Size: 9422 bytes --]
next prev parent reply other threads:[~2015-07-29 11:15 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-28 22:25 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
2015-07-29 10:43 ` Eric Lombrozo
2015-07-29 11:15 ` Mike Hearn [this message]
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+GKTZV5sgXNU_xoBby1_X6eae=5_vhENmyKY0yxWHcBiU5g@mail.gmail.com' \
--to=hearn@vinumeris$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=elombrozo@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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