Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2239C487 for ; Wed, 29 Jul 2015 17:17:50 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from COL004-OMC4S1.hotmail.com (col004-omc4s1.hotmail.com [65.55.34.203]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AC1FE1C6 for ; Wed, 29 Jul 2015 17:17:48 +0000 (UTC) Received: from COL131-DS18 ([65.55.34.201]) by COL004-OMC4S1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 29 Jul 2015 10:17:48 -0700 X-TMN: [GIeR70jEZji7g+sO/y246CFIPChQgc2n] X-Originating-Email: [raystonn@hotmail.com] Message-ID: From: "Raystonn ." To: "Mike Hearn" , "Eric Lombrozo" References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com> In-Reply-To: Date: Wed, 29 Jul 2015 10:17:31 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01D0C9E7.C7ADF840" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-OriginalArrivalTime: 29 Jul 2015 17:17:48.0354 (UTC) FILETIME=[7DE40A20:01D0CA22] X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,FREEMAIL_FROM, FREEMAIL_REPLY, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD 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'ttemporary 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 17:17:50 -0000 ------=_NextPart_000_0040_01D0C9E7.C7ADF840 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Eric, any plans to correct your article at = https://bitcoinmagazine.com/21377/settling-block-size-debate/? From: Mike Hearn via bitcoin-dev=20 Sent: Wednesday, July 29, 2015 4:15 AM To: Eric Lombrozo=20 Cc: Bitcoin Dev=20 Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure = isn'ttemporary 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.=20 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=E2=80=A6and 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.=20 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". =20 I understand that initially it was desirable that transactions be = free=E2=80=A6but surely even Satoshi understood this couldn=E2=80=99t be = perpetually self-sustaining=E2=80=A6and 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=E2=80=99re 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=E2=80=99s = been spent, etc=E2=80=A6 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=E2=80=99s wait until things are about to break before even = beginning to address the issue=E2=80=A6because we can =E2=80=9Ceasily = create=E2=80=9D anything we haven=E2=80=99t 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=E2=80=99m 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=E2=80=99m wrong). One is MultiBit, the other one is mine. I = give you credit for your work=E2=80=A6perhaps 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. -------------------------------------------------------------------------= ------- _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ------=_NextPart_000_0040_01D0C9E7.C7ADF840 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Eric, any plans to correct your article at ht= tps://bitcoinmagazine.com/21377/settling-block-size-debate/?
 
 
From: Mike Hearn via=20 bitcoin-dev
Sent: Wednesday, July 29, 2015 4:15 AM
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam = measure=20 isn'ttemporary
 
Irrelevant what term was used - and as brilliant as Satoshi might = have=20 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=20 stuff is obvious.
 
Consider this:  the highest Bitcoin tx fees can possibly go is = perhaps=20 a little higher than what our competition charges. Too much higher than = that,=20 and people will just say, you know what .... I'll make a bank transfer. = It's=20 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=20 because the infrastructure for doing them is cross subsidised by the = fees on=20 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=20 Bitcoin has some features those other systems lack (and vice versa). So = it can=20 still be competitive.
 
But your extremely vague notion of a "fee market" neglects to = consider that=20 it already exists, and it's not a market of "Bitcoin users buying space = in=20 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=20 this stuff is obvious.
 
Nobody threatened to start mining huge blocks given how = relatively=20 inexpensive it was to mine back = then?
 
Not that I recall. It wasn't a response to any actual event, I = think, but=20 rather a growing realisation that the code was full of DoS = attacks.
 
 
Guess what? SPV wallets are still not particularly = widespread=E2=80=A6and those=20 that are out there are notoriously terrible at detecting network forks = and=20 making sure they are on the right one.
 
The most popular mobile wallet (measured by installs) on Android is = SPV. It=20 has between 500,000 and 1 million installs, whilst Coinbase has not yet = crossed=20 the 500,000 mark. One of the most popular wallets on iOS is SPV. If we = had SPV=20 wallets with better user interfaces on desktops, they'd be more popular = there=20 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.=20 That's a spurious idea that you and Patrick have been pushing lately, = but they=20 detect them and follow reorgs across them according to the SPV = algorithm, which=20 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=20 block chain or implement the algorithm incorrectly, and I fail to see = how this=20 can be described as "notoriously terrible".
 

 
I understand that initially it was desirable that transactions be = free=E2=80=A6but surely even Satoshi understood this couldn=E2=80=99t = be perpetually=20 self-sustaining=E2=80=A6and that the ability to bid for inclusion in = blocks would=20 eventually become a crucial component of the network. Or were fees = just added=20 for decoration?
 
Fees were added as a way to get money to miners in a fair and = decentralised=20 way.
 
Attaching fees directly to all transactions is certainly one way to = use=20 that, but it's not the only way. As noted above, our competitors prefer = a=20 combination of price-hiding and cross subsidisation. Both of these can = be=20 implemented with tx fees, but not necessarily by trying to artificially = limit=20 supply, which is economically nonsensical.
 
 
We=E2=80=99re already more than six years into this. When were = these mechanisms=20 going to be developed and tested? After 10 years? 20? Perhaps after = 1024=20 years?(https://github.com/bitcoin/bips/blob/master/bip-0042.medi= awiki)
 
Maybe when there is a need? I already discussed this topic of need=20 here:
 
https://medi= um.com/@octskyward/hashing-7d04a887acc8
 
Right. Turns out the ledger structure is terrible for = constructing the=20 kinds of proofs that are most important to validators - i.e. whether = an output=20 exists, what its script and amounts are, whether it=E2=80=99s been = spent,=20 etc=E2=80=A6
 
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=20 proofs that are most important to lightweight wallets. But I would = disagree.=20 Even with UTXO commitments, there can still be double spends out there = in the=20 networks memory pools you are unaware of. Merely being presented with a=20 correctly signed transaction doesn't tell you a whole lot ..... if you = wait for=20 a block, you get the same level of proof regardless of whether there are = UTXO=20 commitments or not. If you don't then you still have to have some trust = in your=20 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=20 you work through the use cases for these sorts of data structures and = ask "how=20 will this impact the user experience", the primary candidates so far = don't seem=20 to make much difference.
 
Remote attestation from secure hardware would make a big difference = though.=20 Then you could get rid of the waiting times entirely because you know = the=20 sending wallet won't double spend.
 
 
Yes, let=E2=80=99s wait until things are about to break before = even beginning to=20 address the issue=E2=80=A6because we can =E2=80=9Ceasily = create=E2=80=9D anything we haven=E2=80=99t invented=20 yet at the last minute.
 
bitcoinj already has a micropayment channel implementation in it. = There's a=20 bit of work required to glue everything together, but it's not a massive = project=20 to start using this to pay nodes for their services.
 
But it's not needed right now:  serving these clients is so = darn=20 cheap. And there is plenty of room for optimising things still = further!
 
 
I=E2=80=99m one of the very few developers in this space that has = actually tried=20 *hard* to make your BIP37 work. Amongst the desktop wallets listed on = bitcoin.org, there are = only two=20 that have always supported SPV (or at least I think MultiBit has = always=20 supported it, perhaps I=E2=80=99m wrong). One is MultiBit, the other = one is mine. I=20 give you credit for your work=E2=80=A6perhaps you could be generous = enough to extend=20 me some credit too?
 
MultiBit has always supported it. I apologise = for=20 implying you have not built a wallet. I think yours is mSIGNA, right? = Did it=20 used to be called something else? I recognise the website design but = must admit,=20 I have not heard of mSIGNA before.
 
Regardless, as a fellow implementor, I would = appreciate=20 it more if you designed and implemented upgrades, rather than just = trashing the=20 work done so far as "notoriously terrible", Satoshi as "not a systems = architect"=20 and so on.
 

_______________________________________________
bitcoin-dev mailing=20 list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfound= ation.org/mailman/listinfo/bitcoin-dev
------=_NextPart_000_0040_01D0C9E7.C7ADF840--