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 B235249D for ; Wed, 29 Jul 2015 11:15:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8FAF3E0 for ; Wed, 29 Jul 2015 11:15:50 +0000 (UTC) Received: by ioea135 with SMTP id a135so17693887ioe.1 for ; Wed, 29 Jul 2015 04:15:50 -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=X2akoz9VwUZl4G7FCALVJmRSIr5b9wXqKryrcp62klY=; b=mQnSz/AD5g7F+GBp/IVpw2VHJ5JsF8MKTQdmsPWxnzQha4f/6Dh7V9S7vDZ74uAH9c tsxYme+y8g0jEpdJ7/3LhHBUJ+EPtgF1Z9NrZ4pKgZMnbsHcEhquBnFtL4V6GOMDSqXl Zp/dkeDsiiPZ6FCN61VoLOg7K0F255J2G5Ado= 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=X2akoz9VwUZl4G7FCALVJmRSIr5b9wXqKryrcp62klY=; b=ZWFldmTGJgV4/03vTgOOpe1WdkWwPHZmNm0AIiWD/q2fsb75xl3IAiVXzW0+jPNC16 oEiDqAejFng9D9NEz95kNt9Ucw3Rhll7YDggdMR8AIOScCUe2+klkECGQP8KuWD9sLPi z4/ZIa5OViRRzxKA8ctpTzlMVQpTFHdgH8HDAJssvcw1FWunQzPTSsJzno8M14gKaDqh 5MdCshq6p4jR3jNXom8f3jjf5dhgmtGxkmkjX3ZrsDPfkqFcBU5HIFz57aL2Ty+wYB8F DbHRVquR3uZHuz+QZ0t40xRdFYvtS7VevHHyrKyofuGwEUoxmWJu3XOKbptBPtmh54sJ YJ5g== X-Gm-Message-State: ALoCoQmmag3LLzO4xz+Wplljju3G4ptXLflsx9KkPkfDZoyNwfNHpy01v510WEQlVNd5ooLuhTCG MIME-Version: 1.0 X-Received: by 10.107.135.193 with SMTP id r62mr544508ioi.29.1438168549929; Wed, 29 Jul 2015 04:15:49 -0700 (PDT) Received: by 10.50.108.111 with HTTP; Wed, 29 Jul 2015 04:15:49 -0700 (PDT) In-Reply-To: References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com> Date: Wed, 29 Jul 2015 13:15:49 +0200 Message-ID: From: Mike Hearn To: Eric Lombrozo Content-Type: multipart/alternative; boundary=001a113eceb28bd33c051c01b550 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,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 11:15:51 -0000 --001a113eceb28bd33c051c01b550 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > 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=E2=80=A6and= those > that are out there are notoriously terrible at detecting network forks an= d > 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 bloc= ks 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 mech= anisms > 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 beginni= ng 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 actuall= y 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=A6= 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. --001a113eceb28bd33c051c01b550 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Irrelev= ant what term was used - and as brilliant as Satoshi might have been at som= e things, he obviously got this one wrong.
I don't think it's obvious. You may disagree, but don&#= 39;t pretend any of this stuff is obvious.

Conside= r this: =C2=A0the highest Bitcoin tx fees can possibly go is perhaps a litt= le 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.
= =C2=A0
And now consider that in many parts of the world bank tran= sfers are free.

They aren't actually free, of = course, but they appear=C2=A0to be free because the infrastructure f= or doing them is cross subsidised by the fees on other products and service= s, or hidden in the prices of goods sold.

So that&= #39;s a market reality Bitcoin has to handle. It's already more expensi= ve than the competition sometimes, but luckily not much more, and anyway Bi= tcoin has some features those other systems lack (and vice versa). So it ca= n still be competitive.=C2=A0

But your extremely v= ague notion of a "fee market" neglects to consider that it alread= y 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 relati= vely 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.

=C2=A0
Guess what?= SPV wallets are still not particularly widespread=E2=80=A6and those that a= re 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 no= t yet crossed the 500,000 mark. One of the most popular wallets on iOS is S= PV. 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 g= round).

So I would argue that they are in fact ver= y widespread.

Likewise, they are not "notorio= usly terrible" at detecting chain forks. That's a spurious idea th= at you and Patrick have been pushing lately, but they detect them and follo= w reorgs across them according to the SPV algorithm, which is based on most= work done. This is exactly what they are designed to do.=C2=A0
<= br>
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"= .

=C2=A0
<= div style=3D"word-wrap:break-word">
I understand that initially it= was desirable that transactions be free=E2=80=A6but surely even Satoshi un= derstood this couldn=E2=80=99t be perpetually self-sustaining=E2=80=A6and t= hat the ability to bid for inclusion in blocks would eventually become a cr= ucial 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 pr= efer a combination of price-hiding and cross subsidisation. Both of these c= an be implemented with tx fees, but not necessarily by trying to artificial= ly limit supply, which is economically nonsensical.

=C2=A0
We=E2=80=99re already more than six years into t= his. When were these mechanisms going to be developed and tested? After 10 = years? 20? Perhaps after 1024 years?(https://github.com/b= itcoin/bips/blob/master/bip-0042.mediawiki)

Maybe when there is a need? I already discussed = this topic of need here:


=
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<= br>

Validators don= 't require proofs. That's why they are validators.

I think you're trying to say the block chain doesn't provi= de the kinds of proofs that are most important to lightweight wallets. But = I would disagree. Even with UTXO commitments, there can still be double spe= nds 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 regardl= ess 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 accurat= e and full view of network traffic.

So whilst ther= e 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 th= is 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 ge= t 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 l= ast 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 pr= oject to start using this to pay nodes for their services.

But it's not needed right now: =C2=A0serving these clients is = so darn cheap. And there is plenty of room for optimising things still furt= her!

=C2=A0
I=E2=80=99m on= e of the very few developers in this space that has actually tried *hard* t= o make your BIP37 work. Amongst the desktop wallets listed on bitcoin.org, there are only two tha= t have always supported SPV (or at least I think MultiBit has always suppor= ted 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 enou= gh 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 i= t 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.

--001a113eceb28bd33c051c01b550--