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 BC6A049B for ; Wed, 29 Jul 2015 12:03:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EE09B12F for ; Wed, 29 Jul 2015 12:03:49 +0000 (UTC) Received: by pacan13 with SMTP id an13so4903950pac.1 for ; Wed, 29 Jul 2015 05:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=XcLKEGzp4Rfnq9MoojNJlX32UcizdnSqkcxhCkmjnc0=; b=nMctb/E4QCNpGjbttXvHuj1I7dLAfZ9is9wLMtQx9bQI80R6Ak2dyUUJf/oo6cd/zK aiJI/RFQrKUcpDss3cUjLt3N6wOHPhFE5rqwmvGDt/9/gDD8n9HjpZIWj32YQemi+CVW G1FEo4BD5sksRJ5EbR7J0t4Wy3Sa8bq8QRdr1k7eY3Brg8dJQx00fA+AXZ9Ff7zB8bX+ 6J5ZhEVXlCT+S2MQyjpUBIM2Vqax5qwjmr4tVsb4BjPXd5jL9uIpQ1y76ZY40+D4J4Ff YsJuT29AN5RdlZcwJGv6YX2KYBgMZdj7KNdm981lM7KqGrOaGFCutKiDXYoHtmb8MCf9 AHlg== X-Received: by 10.66.161.232 with SMTP id xv8mr92980372pab.137.1438171429601; Wed, 29 Jul 2015 05:03:49 -0700 (PDT) Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by smtp.gmail.com with ESMTPSA id xp10sm40720785pac.34.2015.07.29.05.03.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Jul 2015 05:03:48 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7EFA5E39-B4BA-4A27-A140-41790D94A0A0"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Eric Lombrozo In-Reply-To: Date: Wed, 29 Jul 2015 05:03:45 -0700 Message-Id: <59FC8BA8-C61F-4340-887F-CE2DD57ADD49@gmail.com> References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com> To: Mike Hearn X-Mailer: Apple Mail (2.2098) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, MIME_QP_LONG_LINE, 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 12:03:51 -0000 --Apple-Mail=_7EFA5E39-B4BA-4A27-A140-41790D94A0A0 Content-Type: multipart/alternative; boundary="Apple-Mail=_C58B19EA-3EC9-4A5C-BD9B-7D2F67AABE54" --Apple-Mail=_C58B19EA-3EC9-4A5C-BD9B-7D2F67AABE54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 29, 2015, at 4:15 AM, Mike Hearn wrote: >=20 > Irrelevant what term was used - and as brilliant as Satoshi might have = been at some things, he obviously got this one wrong. >=20 > I don't think it's obvious. You may disagree, but don't pretend any of = this stuff is obvious. >=20 > 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. >=20 > And now consider that in many parts of the world bank transfers are = free. >=20 > 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. >=20 > 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". >=20 > You can argue with this sort of economic logic if you like, but don't = claim this stuff is obvious. 100% granted - it was not obvious=E2=80=A6and we speak today with the = benefit of hindsight. I=E2=80=99ll clarify my argument, for the sake of anyone who thinks = I=E2=80=99m looking to play word games rather than trying to figure out = a good way forward. Point is=E2=80=A6processing blocks requires computational resources that = someone needs to put up. Unless the people who are putting up these = resources are properly incentivized to continue doing it, the network = will fail. Unfortunately, it was unforeseen that most nodes on the network would = turn out to not be miners=E2=80=A6and that most miners wouldn=E2=80=99t = even run full nodes. Yes, I speak with the benefit of hindsight, had I = been discussing this in 2008 I very well could have made the same = mistake or worse. But it isn=E2=80=99t 2008, it=E2=80=99s 2015=E2=80=A6and= we=E2=80=99ve learned a thing or two since. Given that things are what they are, it is clear that larger blocks = externalize costs onto the rest of the network. Waiting until we can no longer count on the altruistic goodwill of = volunteers because they suddenly decide that they have better uses for = their computers is probably not such a wonderful idea. But even worse is = further burdening the network with externalized costs before we=E2=80=99ve= solved these important issues=E2=80=A6especially given the evidence = that larger blocks tend to lead to network forks. No, I=E2=80=99m not = talking about regular run-of-the-mill reorgs=E2=80=A6I=E2=80=99m talking = consensus forks - a network partition that cannot be reconciled without = manual intervention, so please don=E2=80=99t distract the issue. Yes, = each incident occurred for a very different reason=E2=80=A6but you=E2=80=99= d have to be blind to miss the correlation between bigger blocks and the = propensity for forks. What Satoshi might have thought in 2008-2009 is fascinating from a = historical perspective, but his early pioneering insights don=E2=80=99t = appear to be of much help in addressing these particular issues. > Nobody threatened to start mining huge blocks given how relatively = inexpensive it was to mine back then? >=20 > 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. >=20 >=20 > Guess what? SPV wallets are still not particularly widespread=E2=80=A6an= d those that are out there are notoriously terrible at detecting network = forks and making sure they are on the right one. >=20 > 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). >=20 > So I would argue that they are in fact very widespread. >=20 > 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 >=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? >=20 > Fees were added as a way to get money to miners in a fair and = decentralised way. >=20 > 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. >=20 >=20 > 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 = ) >=20 > Maybe when there is a need? I already discussed this topic of need = here: >=20 > https://medium.com/@octskyward/hashing-7d04a887acc8 = >=20 > 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 >=20 > Validators don't require proofs. That's why they are validators. >=20 > 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. >=20 > 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. >=20 > 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. >=20 >=20 > 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. >=20 > 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. >=20 > 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! >=20 >=20 > 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? >=20 > 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. >=20 > 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. >=20 --Apple-Mail=_C58B19EA-3EC9-4A5C-BD9B-7D2F67AABE54 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 29, 2015, at 4:15 AM, Mike Hearn <hearn@vinumeris.com>= wrote:

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.

100% granted - it was not obvious=E2=80=A6and we speak = today with the benefit of hindsight.

I=E2=80=99ll clarify my argument, for the sake of = anyone who thinks I=E2=80=99m looking to play word games rather than = trying to figure out a good way forward.

Point is=E2=80=A6processing blocks requires = computational resources that someone needs to put up. Unless the people = who are putting up these resources are properly incentivized to continue = doing it, the network will fail. 

Unfortunately, it was unforeseen that most nodes = on the network would turn out to not be miners=E2=80=A6and that most = miners wouldn=E2=80=99t even run full nodes. Yes, I speak with the = benefit of hindsight, had I been discussing this in 2008 I very well = could have made the same mistake or worse. But it isn=E2=80=99t 2008, = it=E2=80=99s 2015=E2=80=A6and we=E2=80=99ve learned a thing or two = since.

Given that things are what = they are, it is clear that larger blocks externalize costs onto the rest = of the network.

Waiting until we can = no longer count on the altruistic goodwill of volunteers because they = suddenly decide that they have better uses for their computers is = probably not such a wonderful idea. But even worse is further burdening = the network with externalized costs before we=E2=80=99ve solved these = important issues=E2=80=A6especially given the evidence that larger = blocks tend to lead to network forks. No, I=E2=80=99m not talking about = regular run-of-the-mill reorgs=E2=80=A6I=E2=80=99m talking consensus = forks - a network partition that cannot be reconciled without manual = intervention, so please don=E2=80=99t distract the issue. Yes, each = incident occurred for a very different reason=E2=80=A6but you=E2=80=99d = have to be blind to miss the correlation between bigger blocks and the = propensity for forks.

What = Satoshi might have thought in 2008-2009 is fascinating from a historical = perspective, but his early pioneering insights don=E2=80=99t appear to = be of much help in addressing these particular issues.

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. 

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=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=99= 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<= /a>)

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.


= --Apple-Mail=_C58B19EA-3EC9-4A5C-BD9B-7D2F67AABE54-- --Apple-Mail=_7EFA5E39-B4BA-4A27-A140-41790D94A0A0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVuMEhAAoJEJNAI64YFENUGdMQAJYQ1fISOkSIdZ4FmliDTRkt gmNmwMn4mWdHCA8SZFOSqIlvGUsCJVh+S7GusHFp6UUi/WRNw4XYLdf/0oX6kGgr W/9dzW16w86isMbWRJqNwv8gzIOjK0IDFLc0XYfAH4QOMCSpWnX6XTTr6AOjZboX KgYHpRkJQcm2a2GCCdfjbo12NGUYz1UN+wu4R5WRj2IieQtepv6k5RJ6B6IdNtAL zy4Q3niTE7dkMT0uH5UmgT58S5rZeOjPKMdM/BH0+cpX6Nri75kYcGXy8EhAwJhf BLz2nn4jsFsTbf/dNE7Z9RX9JyeiGs4G231op354LkjMXsmomRdqN8TD9Ih0Ynn7 LghnKoc3rjqobzRbhH9TntTlAbpQlKo6KZHzPSCPuG16d+93UZPUNA7KcnJgyoNt TGfEXI7fjBABj869OCXomYnIBvWi+mtPUJdUfbLxAyZCXoizOtRL9FMFyQxnAp0i UqRsDCbgHw7I6o4MbV1tnRWcdz6ApdkBp3z+RIvKQ9t+WtT2DhnJOsSv1NL+LRzJ AYiN/YEPNR5sDw8bWrh+QkuPvuh2+YuZCIz4u29NbNF/Ela/Wya88uhM2BmJIKpJ W69GJgIo7/MgVtCDTkC6TUGyYD34U0gxc9kWKd79blqBukMjh5yMeJtugCCeApbq 8njKBaCdo8BYmxkYCqLj =Ubx5 -----END PGP SIGNATURE----- --Apple-Mail=_7EFA5E39-B4BA-4A27-A140-41790D94A0A0--