Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <joshuasindy@gmail.com>) id 1YLdhU-0004rD-FD for bitcoin-development@lists.sourceforge.net; Wed, 11 Feb 2015 20:15:56 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.180 as permitted sender) client-ip=209.85.217.180; envelope-from=joshuasindy@gmail.com; helo=mail-lb0-f180.google.com; Received: from mail-lb0-f180.google.com ([209.85.217.180]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YLdhR-0003GT-5C for bitcoin-development@lists.sourceforge.net; Wed, 11 Feb 2015 20:15:56 +0000 Received: by mail-lb0-f180.google.com with SMTP id z12so5481825lbi.11 for <bitcoin-development@lists.sourceforge.net>; Wed, 11 Feb 2015 12:15:46 -0800 (PST) X-Received: by 10.112.217.68 with SMTP id ow4mr191450lbc.97.1423685746689; Wed, 11 Feb 2015 12:15:46 -0800 (PST) MIME-Version: 1.0 Sender: joshuasindy@gmail.com Received: by 10.152.132.197 with HTTP; Wed, 11 Feb 2015 12:15:16 -0800 (PST) In-Reply-To: <mailman.1217.1423646736.2626.bitcoin-development@lists.sourceforge.net> References: <mailman.1217.1423646736.2626.bitcoin-development@lists.sourceforge.net> From: Joshua <josh@root.bz> Date: Wed, 11 Feb 2015 13:15:16 -0700 X-Google-Sender-Auth: Wj4bitdEKGchA9AGZg2FzGjGCVs Message-ID: <CAM-6kX84C=GWx07k1yO+4nJbNx31XS=iTjtXQhLWTR6ZUmJ10w@mail.gmail.com> To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=001a1134c93e340ccb050ed5abfb X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (joshuasindy[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YLdhR-0003GT-5C Subject: Re: [Bitcoin-development] Bitcoin-development Digest, Vol 45, Issue 37 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: <bitcoin-development.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> List-Post: <mailto:bitcoin-development@lists.sourceforge.net> List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> X-List-Received-Date: Wed, 11 Feb 2015 20:15:56 -0000 --001a1134c93e340ccb050ed5abfb Content-Type: text/plain; charset=UTF-8 UNSUBSCRIBE On Wed, Feb 11, 2015 at 2:25 AM, < bitcoin-development-request@lists.sourceforge.net> wrote: > Send Bitcoin-development mailing list submissions to > bitcoin-development@lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > or, via email, send a message with subject or body 'help' to > bitcoin-development-request@lists.sourceforge.net > > You can reach the person managing the list at > bitcoin-development-owner@lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Bitcoin-development digest..." > > > Today's Topics: > > 1. Re: Proposal for P2P Wireless (Bluetooth LE) transfer of > Payment URI (Eric Voskuil) > 2. Proposal: Requiring a miner's signature in the block header > (Hector Chu) > 3. Re: Proposal: Requiring a miner's signature in the block > header (Natanael) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 10 Feb 2015 09:56:39 -0800 > From: Eric Voskuil <eric@voskuil.org> > Subject: Re: [Bitcoin-development] Proposal for P2P Wireless > (Bluetooth LE) transfer of Payment URI > To: M?rtin H?bo??tiak <martin.habovstiak@gmail.com> > Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>, Paul Puey > <paul@airbitz.co> > Message-ID: <54DA4657.5080604@voskuil.org> > Content-Type: text/plain; charset="utf-8" > > On 02/10/2015 09:16 AM, M?rtin H?bo??tiak wrote: > > I'm not sure if I was clear enough. Handshake should be used to > > establish authenticated AND encrypted communication using ECDH (or > > just DH, but I think it's easier to use ECDH, since required functions > > are already used in Bitcoin protocol), like RedPhone does. BTW > > knowledge of verification string is useless to the attacker. > > Yes, I think this was clear from your description. > > > Yes, the customer must verify it verbally and the merchant shouldn't > > send the transaction before verification. Other possibility is that in > > case of differing verification strings new address is generated, so > > attacker doesn't know the address. But in this case, amount is leaked > > and there is quite high probability it can be found in the Blockchain. > > Yes, for each handshake the payment request would need to contain a > different address, mitigating some of the privacy loss. > > > Anyway, I don't believe the transaction can be made securely without > > such interaction except with white-listing public keys, so I see no > > reason why interaction should be problematic. > > It can be done securely and privately by transfer of a shared secret > through a private channel. > > > We don't have such strict regulations but I agree that security is > > important. Currently I think that verbal verification and manual > > confirmation is the best way to achieve high security and reasonable > > user-friendliness. > > I think for a broadcast model (e.g. Bluetooth only) that is the only > want to ensure integrity and privacy. A narrow cast can use proximity to > establish trust. > > > 2015-02-10 17:55 GMT+01:00 Eric Voskuil <eric@voskuil.org>: > >> Martin, > >> > >> I like your idea for the commit protocol in that it resolves the > >> vandalous address substitution attack. However, I don't see a way to > >> prevent privacy loss without adverse impact to the scenario. > >> > >> Anyone could perform the handshake and thereby obtain the payment > >> request. Therefore to prevent inadvertent disclosure the customer must > >> visually confirm the "phrase" and then verbally tell the merchant to > >> proceed by sending the payment request. > >> > >> One might argue that it's sufficient to preserve the integrity of the > >> transaction while suffering the privacy loss, especially given that a > >> hijacked handshake should never result in a completed transaction - > >> unless of course the hijacker pays. > >> > >> But imagine someone purchasing their meds. HIPAA requires the checkout > >> queue to form behind a yellow line. That speaks directly to this > question. > >> > >> e > >> > >> On 02/06/2015 01:07 AM, M?rtin H?bo??tiak wrote: > >>> 2015-02-06 2:29 GMT+01:00 Eric Voskuil <eric@voskuil.org>: > >>>> On 02/05/2015 04:36 PM, Martin Habov?tiak wrote: > >>>>> I believe, we are still talking about transactions of physical > >>>>> people in physical world. So yes, it's proximity based - people > >>>>> tell the words by mouth. :) > >>>> > >>>> Notice from my original comment: > >>>> > >>>>>>>> A MITM can substitute the key. If you don't have verifiable > >>>>>>>> identity associated with the public key (PKI/WoT), you need > >>>>>>>> a shared secret (such as a secret phrase). > >>>> > >>>> I said this could only be accomplished using a shared secret or a > >>>> trusted public key. Exchanging a value that is derived from a pair of > >>>> public keys is a distinction without a difference. The problem remains > >>>> that the parties must have a secure/out-of-band channel for > >>>> communicating this value. > >>>> > >>>> The fact that they are face-to-face establishes this channel, but that > >>>> brings us back to the original problem, as it requires manual > >>>> verification - as in visual/audible scanning of the two values for > >>>> comparison. At that point the visual comparison of the address, or > some > >>>> value derived from it, is simpler. > >>> > >>> I have never been against manual verification. What I'm trying to say > >>> is let's just make manual verification easier and more secure. > >>> Comparison of address is simpler for the coder but also simpler to > >>> attack. It has these problems: > >>> - Addresses broadcasted in plaintext (privacy issue) > >>> - Amounts broadcasted in plaintext (privacy issue) > >>> - Address is long - takes lot of time to verify (user experience issue) > >>> - Address prefix can be brute-forced, if too short or used to make > >>> "black hole" address if longer (vandalism issue) > >>> > >>> Commit protocol can be used for both the encryption and the > >>> authentication while user experience is not bad and everything is > >>> still secure. > >>> > >>>> > >>>>> In case of RedPhone, you read those words verbally over not-yet- > >>>>> verified channel relying on difficulty of spoofing your voice. Also > >>>>> the app remembers the public keys, so you don't need to verify > >>>>> second time. > >>>> > >>>> This is reasonable, but wouldn't help in the case of an ad-hoc > >>>> connection between parties who don't know each other well. > >>>> > >>>>> I suggest you to try RedPhone (called Signal on iPhone) yourself. > >>>>> It's free/open source, Internet-based and end-to-end encrypted. You > >>>>> may find it useful some day. Also I'm willing to help you with > >>>>> trying it after I wake up. (~8 hours: Send me private e-mail if > >>>>> you want to.) > >>>> > >>>> I appreciate the offer. I really don't trust *any* smartphone as a > >>>> platform for secure communication/data. But encrypting on the wire > does > >>>> of course shrink the attack surface and increase the attacker's cost. > >>>> > >>>> e > >>>> > >>>>> D?a 6. febru?ra 2015 1:22:23 CET pou??vate? Eric Voskuil > >>>> <eric@voskuil.org> nap?sal: > >>>> > >>>>>> On 02/05/2015 04:04 PM, M?rtin H?bo??tiak wrote: > >>>>>>> That's exactly what I though when seeing the RedPhone code, but > after > >>>>>>> I studied the commit protocol I realized it's actually secure and > >>>>>>> convenient way to do it. You should do that too. :) > >>>>> > >>>>>> I was analyzing the model as you described it to me. A formal > analysis > >>>>>> of the security model of a particular implementation, based on > >>>>>> inference > >>>>> >from source code, is a bit beyond what I signed up for. But I'm > >>>>>> perfectly willing to comment on your description of the model if you > >>>>>> are > >>>>>> willing to indulge me. > >>>>> > >>>>>>> Shortly, how it works: > >>>>>>> The initiator of the connection sends commit message containing the > >>>>>>> hash of his temporary public ECDH part, second party sends back > their > >>>>>>> public ECDH part and then initiator sends his public ECDH part in > >>>>>>> open. All three messages are hashed together and the first two > bytes > >>>>>>> are used to select two words from a shared dictionary which are > >>>>>>> displayed on the screen of both the initiator and the second party. > >>>>> > >>>>>>> The parties communicate those two words and verify they match. > >>>>> > >>>>>> How do they compare words if they haven't yet established a secure > >>>>>> channel? > >>>>> > >>>>>>> If an attacker wants to do MITM, he has a chance of choosing right > >>>>>>> public parts 1:65536. There is no way to brute-force it, since that > >>>>>>> would be noticed immediately. If instead of two words based on the > >>>>>>> first two bytes, four words from BIP39 wordlist were chosen, it > would > >>>>>>> provide entropy of 44 bits which I believe should be enough even > for > >>>>>>> paranoid people. > >>>>>>> > >>>>>>> How this would work in Bitcoin payment scenario: user's phone > >>>>>>> broadcasts his name, merchant inputs amount and selects the name > from > >>>>>>> the list, commit message is sent (and then the remaining two > >>>>>>> messages), merchant spells four words he sees on the screen and > buyer > >>>>>>> confirms transaction after verifying that words match. > >>>>> > >>>>>> So the assumption is that there exists a secure (as in > proximity-based) > >>>>>> communication channel? > >>>>> > >>>>>> e > >>>>> > >>>>>>> 2015-02-06 0:46 GMT+01:00 Eric Voskuil <eric@voskuil.org>: > >>>>>>>> On 02/05/2015 03:36 PM, M?rtin H?bo??tiak wrote: > >>>>>>>>>> A BIP-70 signed payment request in the initial broadcast can > >>>>>> resolve the > >>>>>>>>>> integrity issues, but because of the public nature of the > >>>>>> broadcast > >>>>>>>>>> coupled with strong public identity, the privacy compromise is > >>>>>> much > >>>>>>>>>> worse. Now transactions are cryptographically tainted. > >>>>>>>>>> > >>>>>>>>>> This is also the problem with BIP-70 over the web. TLS and other > >>>>>>>>>> security precautions aside, an interloper on the communication, > >>>>>> desktop, > >>>>>>>>>> datacenter, etc., can capture payment requests and strongly > >>>>>> correlate > >>>>>>>>>> transactions to identities in an automated manner. The payment > >>>>>> request > >>>>>>>>>> must be kept private between the parties, and that's hard to do. > >>>>>>>>> > >>>>>>>>> What about using encryption with forward secrecy? Merchant would > >>>>>>>>> generate signed request containing public ECDH part, buyer would > >>>>>> send > >>>>>>>>> back transaction encrypted with ECDH and his public ECDH part. If > >>>>>>>>> receiving address/amount is meant to be private, use commit > >>>>>> protocol > >>>>>>>>> (see ZRTP/RedPhone) and short authentication phrase (which is > hard > >>>>>> to > >>>>>>>>> spoof thanks to commit protocol - see RedPhone)? > >>>>>>>> > >>>>>>>> Hi Martin, > >>>>>>>> > >>>>>>>> The problem is that you need to verify the ownership of the public > >>>>>> key. > >>>>>>>> A MITM can substitute the key. If you don't have verifiable > identity > >>>>>>>> associated with the public key (PKI/WoT), you need a shared secret > >>>>>> (such > >>>>>>>> as a secret phrase). But the problem is then establishing that > >>>>>> secret > >>>>>>>> over a public channel. > >>>>>>>> > >>>>>>>> You can bootstrap a private session over the untrusted network > using > >>>>>> a > >>>>>>>> trusted public key (PKI/WoT). But the presumption is that you are > >>>>>>>> already doing this over the web (using TLS). That process is > subject > >>>>>> to > >>>>>>>> attack at the CA. WoT is not subject to a CA attack, because it's > >>>>>>>> decentralized. But it's also not sufficiently deployed for some > >>>>>> scenarios. > >>>>>>>> > >>>>>>>> e > >>>>>>>> > >>>>> > >>>>> > >>>> > >> > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 473 bytes > Desc: OpenPGP digital signature > > ------------------------------ > > Message: 2 > Date: Wed, 11 Feb 2015 08:54:15 +0000 > From: Hector Chu <hectorchu@gmail.com> > Subject: [Bitcoin-development] Proposal: Requiring a miner's signature > in the block header > To: bitcoin-development@lists.sourceforge.net > Message-ID: > < > CAAO2FKEFxC_byt4xVJb0S-7yy0M7M-Av7MHUH-RBDuri_GAFtw@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > A proposal for stemming the tide of mining centralisation -- Requiring a > miner's signature in the block header (the whole of which is hashed), and > paying out coinbase to the miner's public key. > > Please comment on whether this idea is feasible, has been thought of > before, > etc., etc. Thank you. > > Motivation > ---------- > > Mining is centralising to a handful of pool operators. This is bad for a > number of political reasons, which we won't go into right now. But I have > always believed that some years down the line, they could hold the users > hostage and change the rules to suit themselves. For instance by > eliminating > the halving of the block reward. > > Solution > -------- > > Currently the block header is formed by the pool operator and distributed > for > hashing by the pooled miners. It is possible to divide the work among the > miners as the only thing that is used to search the hash space is by > changing > a nonce or two. > > I propose that we require each miner to sign the block header prior to > hashing. The signature will be included in the data that is hashed. > Further, > the coinbase for the block must only pay out to the public key counterpart > of > the private key used to sign the block header. > > A valid block will therefore have a signature in the block header that is > verified by the public key being paid by the coinbase transaction. > > Ramifications > ------------- > > Work can no longer be divided among the pooled miners as before, without > sharing the pool's private key amongst all of them. If the pool does try to > take this route, then any of the miners may redeem the coinbase when it > matures. Therefore, all miners will use their own key pair. > > This will make it difficult to form a cooperating pool of miners who may > not > trust each other, as the block rewards will be controlled by disparate > parties > and not by the pool operator. Only a tight clique of trusted miners would > be > able to form their own private pool in such an environment. > > Attacks > ------- > > Pooled hashpower, instead of earning bitcoins legitimately may try to break > the system instead. They may try a double-spending attack, but in order to > leverage the pool to its full potential the pool operator would again have > to > share their private key with the whole pool. Due to the increased > cooperation > and coordination required for an attack, the probability of a 51% attack is > much reduced. > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 3 > Date: Wed, 11 Feb 2015 10:25:27 +0100 > From: Natanael <natanael.l@gmail.com> > Subject: Re: [Bitcoin-development] Proposal: Requiring a miner's > signature in the block header > To: Hector Chu <hectorchu@gmail.com> > Cc: bitcoin-development@lists.sourceforge.net > Message-ID: > <CAAt2M1_qj0r03= > Ref9mN7bJLg-odep3m5teZ7JWDLC+zknQdQQ@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Den 11 feb 2015 09:55 skrev "Hector Chu" <hectorchu@gmail.com>: > > > > A proposal for stemming the tide of mining centralisation -- Requiring a > > miner's signature in the block header (the whole of which is hashed), and > > paying out coinbase to the miner's public key. > > > > Please comment on whether this idea is feasible, has been thought of > before, > > etc., etc. Thank you. > > > > Motivation > > ---------- > > > > Mining is centralising to a handful of pool operators. This is bad for a > > number of political reasons, which we won't go into right now. But I have > > always believed that some years down the line, they could hold the users > > hostage and change the rules to suit themselves. For instance by > eliminating > > the halving of the block reward. > > [...] > > > I propose that we require each miner to sign the block header prior to > > hashing. The signature will be included in the data that is hashed. > Further, > > the coinbase for the block must only pay out to the public key > counterpart of > > the private key used to sign the block header. > > [...] > > > This will make it difficult to form a cooperating pool of miners who may > not > > trust each other, as the block rewards will be controlled by disparate > parties > > and not by the pool operator. Only a tight clique of trusted miners would > be > > able to form their own private pool in such an environment. > > People already trust things like cloud mining, so your solution with > increasing technical trust requirements won't help. But you will however > break P2Pool instead. > > Also, note that threshold signatures (group signatures) could probably be > used by an actual distrusting pool's miners. There are already a proof of > concept for this implemented with secp256k1 that works with Bitcoin clients > silently. This wouldn't prevent such a pool from working. > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > > ------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > End of Bitcoin-development Digest, Vol 45, Issue 37 > *************************************************** > --001a1134c93e340ccb050ed5abfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">UNSUBSCRIBE</div><div class=3D"gmail_extra"><br><div class= =3D"gmail_quote">On Wed, Feb 11, 2015 at 2:25 AM, <span dir=3D"ltr"><<a= href=3D"mailto:bitcoin-development-request@lists.sourceforge.net" target= =3D"_blank">bitcoin-development-request@lists.sourceforge.net</a>></span= > wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex">Send Bitcoin-development mailing= list submissions to<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-development@lists.sou= rceforge.net">bitcoin-development@lists.sourceforge.net</a><br> <br> To subscribe or unsubscribe via the World Wide Web, visit<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://lists.sourceforge.net/lists/= listinfo/bitcoin-development" target=3D"_blank">https://lists.sourceforge.n= et/lists/listinfo/bitcoin-development</a><br> or, via email, send a message with subject or body 'help' to<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-development-request@l= ists.sourceforge.net">bitcoin-development-request@lists.sourceforge.net</a>= <br> <br> You can reach the person managing the list at<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-development-owner@lis= ts.sourceforge.net">bitcoin-development-owner@lists.sourceforge.net</a><br> <br> When replying, please edit your Subject line so it is more specific<br> than "Re: Contents of Bitcoin-development digest..."<br> <br> <br> Today's Topics:<br> <br> =C2=A0 =C2=A01. Re: Proposal for P2P Wireless (Bluetooth LE) transfer of<br= > =C2=A0 =C2=A0 =C2=A0 Payment URI (Eric Voskuil)<br> =C2=A0 =C2=A02. Proposal: Requiring a miner's signature in=C2=A0 =C2=A0= =C2=A0 =C2=A0 the block header<br> =C2=A0 =C2=A0 =C2=A0 (Hector Chu)<br> =C2=A0 =C2=A03. Re: Proposal: Requiring a miner's signature in the bloc= k<br> =C2=A0 =C2=A0 =C2=A0 header (Natanael)<br> <br> <br> ----------------------------------------------------------------------<br> <br> Message: 1<br> Date: Tue, 10 Feb 2015 09:56:39 -0800<br> From: Eric Voskuil <<a href=3D"mailto:eric@voskuil.org">eric@voskuil.org= </a>><br> Subject: Re: [Bitcoin-development] Proposal for P2P Wireless<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (Bluetooth LE) transfer of Payment URI<br> To: M?rtin H?bo??tiak <<a href=3D"mailto:martin.habovstiak@gmail.com">ma= rtin.habovstiak@gmail.com</a>><br> Cc: Bitcoin Dev <<a href=3D"mailto:bitcoin-development@lists.sourceforge= .net">bitcoin-development@lists.sourceforge.net</a>>,=C2=A0 =C2=A0 Paul = Puey<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:paul@airbitz.co">paul@air= bitz.co</a>><br> Message-ID: <<a href=3D"mailto:54DA4657.5080604@voskuil.org">54DA4657.50= 80604@voskuil.org</a>><br> Content-Type: text/plain; charset=3D"utf-8"<br> <br> On 02/10/2015 09:16 AM, M?rtin H?bo??tiak wrote:<br> > I'm not sure if I was clear enough. Handshake should be used to<br= > > establish authenticated AND encrypted communication using ECDH (or<br> > just DH, but I think it's easier to use ECDH, since required funct= ions<br> > are already used in Bitcoin protocol), like RedPhone does. BTW<br> > knowledge of verification string is useless to the attacker.<br> <br> Yes, I think this was clear from your description.<br> <br> > Yes, the customer must verify it verbally and the merchant shouldn'= ;t<br> > send the transaction before verification. Other possibility is that in= <br> > case of differing verification strings new address is generated, so<br= > > attacker doesn't know the address. But in this case, amount is lea= ked<br> > and there is quite high probability it can be found in the Blockchain.= <br> <br> Yes, for each handshake the payment request would need to contain a<br> different address, mitigating some of the privacy loss.<br> <br> > Anyway, I don't believe the transaction can be made securely witho= ut<br> > such interaction except with white-listing public keys, so I see no<br= > > reason why interaction should be problematic.<br> <br> It can be done securely and privately by transfer of a shared secret<br> through a private channel.<br> <br> > We don't have such strict regulations but I agree that security is= <br> > important. Currently I think that verbal verification and manual<br> > confirmation is the best way to achieve high security and reasonable<b= r> > user-friendliness.<br> <br> I think for a broadcast model (e.g. Bluetooth only) that is the only<br> want to ensure integrity and privacy. A narrow cast can use proximity to<br= > establish trust.<br> <br> > 2015-02-10 17:55 GMT+01:00 Eric Voskuil <<a href=3D"mailto:eric@vos= kuil.org">eric@voskuil.org</a>>:<br> >> Martin,<br> >><br> >> I like your idea for the commit protocol in that it resolves the<b= r> >> vandalous address substitution attack. However, I don't see a = way to<br> >> prevent privacy loss without adverse impact to the scenario.<br> >><br> >> Anyone could perform the handshake and thereby obtain the payment<= br> >> request. Therefore to prevent inadvertent disclosure the customer = must<br> >> visually confirm the "phrase" and then verbally tell the= merchant to<br> >> proceed by sending the payment request.<br> >><br> >> One might argue that it's sufficient to preserve the integrity= of the<br> >> transaction while suffering the privacy loss, especially given tha= t a<br> >> hijacked handshake should never result in a completed transaction = -<br> >> unless of course the hijacker pays.<br> >><br> >> But imagine someone purchasing their meds. HIPAA requires the chec= kout<br> >> queue to form behind a yellow line. That speaks directly to this q= uestion.<br> >><br> >> e<br> >><br> >> On 02/06/2015 01:07 AM, M?rtin H?bo??tiak wrote:<br> >>> 2015-02-06 2:29 GMT+01:00 Eric Voskuil <<a href=3D"mailto:e= ric@voskuil.org">eric@voskuil.org</a>>:<br> >>>> On 02/05/2015 04:36 PM, Martin Habov?tiak wrote:<br> >>>>> I believe, we are still talking about transactions of = physical<br> >>>>> people in physical world. So yes, it's proximity b= ased - people<br> >>>>> tell the words by mouth. :)<br> >>>><br> >>>> Notice from my original comment:<br> >>>><br> >>>>>>>> A MITM can substitute the key. If you don&= #39;t have verifiable<br> >>>>>>>> identity associated with the public key (P= KI/WoT), you need<br> >>>>>>>> a shared secret (such as a secret phrase).= <br> >>>><br> >>>> I said this could only be accomplished using a shared secr= et or a<br> >>>> trusted public key. Exchanging a value that is derived fro= m a pair of<br> >>>> public keys is a distinction without a difference. The pro= blem remains<br> >>>> that the parties must have a secure/out-of-band channel fo= r<br> >>>> communicating this value.<br> >>>><br> >>>> The fact that they are face-to-face establishes this chann= el, but that<br> >>>> brings us back to the original problem, as it requires man= ual<br> >>>> verification - as in visual/audible scanning of the two va= lues for<br> >>>> comparison. At that point the visual comparison of the add= ress, or some<br> >>>> value derived from it, is simpler.<br> >>><br> >>> I have never been against manual verification. What I'm tr= ying to say<br> >>> is let's just make manual verification easier and more sec= ure.<br> >>> Comparison of address is simpler for the coder but also simple= r to<br> >>> attack. It has these problems:<br> >>> - Addresses broadcasted in plaintext (privacy issue)<br> >>> - Amounts broadcasted in plaintext (privacy issue)<br> >>> - Address is long - takes lot of time to verify (user experien= ce issue)<br> >>> - Address prefix can be brute-forced, if too short or used to = make<br> >>> "black hole" address if longer (vandalism issue)<br> >>><br> >>> Commit protocol can be used for both the encryption and the<br= > >>> authentication while user experience is not bad and everything= is<br> >>> still secure.<br> >>><br> >>>><br> >>>>> In case of RedPhone, you read those words verbally ove= r not-yet-<br> >>>>> verified channel relying on difficulty of spoofing you= r voice. Also<br> >>>>> the app remembers the public keys, so you don't ne= ed to verify<br> >>>>> second time.<br> >>>><br> >>>> This is reasonable, but wouldn't help in the case of a= n ad-hoc<br> >>>> connection between parties who don't know each other w= ell.<br> >>>><br> >>>>> I suggest you to try RedPhone (called Signal on iPhone= ) yourself.<br> >>>>> It's free/open source, Internet-based and end-to-e= nd encrypted. You<br> >>>>> may find it useful some day. Also I'm willing to h= elp you with<br> >>>>> trying it after I wake up. (~8 hours: Send me private = e-mail if<br> >>>>> you want to.)<br> >>>><br> >>>> I appreciate the offer. I really don't trust *any* sma= rtphone as a<br> >>>> platform for secure communication/data. But encrypting on = the wire does<br> >>>> of course shrink the attack surface and increase the attac= ker's cost.<br> >>>><br> >>>> e<br> >>>><br> >>>>> D?a 6. febru?ra 2015 1:22:23 CET pou??vate? Eric Vosku= il<br> >>>> <<a href=3D"mailto:eric@voskuil.org">eric@voskuil.org</= a>> nap?sal:<br> >>>><br> >>>>>> On 02/05/2015 04:04 PM, M?rtin H?bo??tiak wrote:<b= r> >>>>>>> That's exactly what I though when seeing t= he RedPhone code, but after<br> >>>>>>> I studied the commit protocol I realized it= 9;s actually secure and<br> >>>>>>> convenient way to do it. You should do that to= o. :)<br> >>>>><br> >>>>>> I was analyzing the model as you described it to m= e. A formal analysis<br> >>>>>> of the security model of a particular implementati= on, based on<br> >>>>>> inference<br> >>>>> >from source code, is a bit beyond what I signed up= for. But I'm<br> >>>>>> perfectly willing to comment on your description o= f the model if you<br> >>>>>> are<br> >>>>>> willing to indulge me.<br> >>>>><br> >>>>>>> Shortly, how it works:<br> >>>>>>> The initiator of the connection sends commit m= essage containing the<br> >>>>>>> hash of his temporary public ECDH part, second= party sends back their<br> >>>>>>> public ECDH part and then initiator sends his = public ECDH part in<br> >>>>>>> open. All three messages are hashed together a= nd the first two bytes<br> >>>>>>> are used to select two words from a shared dic= tionary which are<br> >>>>>>> displayed on the screen of both the initiator = and the second party.<br> >>>>><br> >>>>>>> The parties communicate those two words and ve= rify they match.<br> >>>>><br> >>>>>> How do they compare words if they haven't yet = established a secure<br> >>>>>> channel?<br> >>>>><br> >>>>>>> If an attacker wants to do MITM, he has a chan= ce of choosing right<br> >>>>>>> public parts 1:65536. There is no way to brute= -force it, since that<br> >>>>>>> would be noticed immediately. If instead of tw= o words based on the<br> >>>>>>> first two bytes, four words from BIP39 wordlis= t were chosen, it would<br> >>>>>>> provide entropy of 44 bits which I believe sho= uld be enough even for<br> >>>>>>> paranoid people.<br> >>>>>>><br> >>>>>>> How this would work in Bitcoin payment scenari= o: user's phone<br> >>>>>>> broadcasts his name, merchant inputs amount an= d selects the name from<br> >>>>>>> the list, commit message is sent (and then the= remaining two<br> >>>>>>> messages), merchant spells four words he sees = on the screen and buyer<br> >>>>>>> confirms transaction after verifying that word= s match.<br> >>>>><br> >>>>>> So the assumption is that there exists a secure (a= s in proximity-based)<br> >>>>>> communication channel?<br> >>>>><br> >>>>>> e<br> >>>>><br> >>>>>>> 2015-02-06 0:46 GMT+01:00 Eric Voskuil <<a = href=3D"mailto:eric@voskuil.org">eric@voskuil.org</a>>:<br> >>>>>>>> On 02/05/2015 03:36 PM, M?rtin H?bo??tiak = wrote:<br> >>>>>>>>>> A BIP-70 signed payment request in= the initial broadcast can<br> >>>>>> resolve the<br> >>>>>>>>>> integrity issues, but because of t= he public nature of the<br> >>>>>> broadcast<br> >>>>>>>>>> coupled with strong public identit= y, the privacy compromise is<br> >>>>>> much<br> >>>>>>>>>> worse. Now transactions are crypto= graphically tainted.<br> >>>>>>>>>><br> >>>>>>>>>> This is also the problem with BIP-= 70 over the web. TLS and other<br> >>>>>>>>>> security precautions aside, an int= erloper on the communication,<br> >>>>>> desktop,<br> >>>>>>>>>> datacenter, etc., can capture paym= ent requests and strongly<br> >>>>>> correlate<br> >>>>>>>>>> transactions to identities in an a= utomated manner. The payment<br> >>>>>> request<br> >>>>>>>>>> must be kept private between the p= arties, and that's hard to do.<br> >>>>>>>>><br> >>>>>>>>> What about using encryption with forwa= rd secrecy? Merchant would<br> >>>>>>>>> generate signed request containing pub= lic ECDH part, buyer would<br> >>>>>> send<br> >>>>>>>>> back transaction encrypted with ECDH a= nd his public ECDH part. If<br> >>>>>>>>> receiving address/amount is meant to b= e private, use commit<br> >>>>>> protocol<br> >>>>>>>>> (see ZRTP/RedPhone) and short authenti= cation phrase (which is hard<br> >>>>>> to<br> >>>>>>>>> spoof thanks to commit protocol - see = RedPhone)?<br> >>>>>>>><br> >>>>>>>> Hi Martin,<br> >>>>>>>><br> >>>>>>>> The problem is that you need to verify the= ownership of the public<br> >>>>>> key.<br> >>>>>>>> A MITM can substitute the key. If you don&= #39;t have verifiable identity<br> >>>>>>>> associated with the public key (PKI/WoT), = you need a shared secret<br> >>>>>> (such<br> >>>>>>>> as a secret phrase). But the problem is th= en establishing that<br> >>>>>> secret<br> >>>>>>>> over a public channel.<br> >>>>>>>><br> >>>>>>>> You can bootstrap a private session over t= he untrusted network using<br> >>>>>> a<br> >>>>>>>> trusted public key (PKI/WoT). But the pres= umption is that you are<br> >>>>>>>> already doing this over the web (using TLS= ). That process is subject<br> >>>>>> to<br> >>>>>>>> attack at the CA. WoT is not subject to a = CA attack, because it's<br> >>>>>>>> decentralized. But it's also not suffi= ciently deployed for some<br> >>>>>> scenarios.<br> >>>>>>>><br> >>>>>>>> e<br> >>>>>>>><br> >>>>><br> >>>>><br> >>>><br> >><br> <br> -------------- next part --------------<br> A non-text attachment was scrubbed...<br> Name: signature.asc<br> Type: application/pgp-signature<br> Size: 473 bytes<br> Desc: OpenPGP digital signature<br> <br> ------------------------------<br> <br> Message: 2<br> Date: Wed, 11 Feb 2015 08:54:15 +0000<br> From: Hector Chu <<a href=3D"mailto:hectorchu@gmail.com">hectorchu@gmail= .com</a>><br> Subject: [Bitcoin-development] Proposal: Requiring a miner's signature<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 in=C2=A0 =C2=A0 =C2=A0 the block header<br> To: <a href=3D"mailto:bitcoin-development@lists.sourceforge.net">bitcoin-de= velopment@lists.sourceforge.net</a><br> Message-ID:<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:CAAO2FKEFxC_byt4xVJb0S-7y= y0M7M-Av7MHUH-RBDuri_GAFtw@mail.gmail.com">CAAO2FKEFxC_byt4xVJb0S-7yy0M7M-A= v7MHUH-RBDuri_GAFtw@mail.gmail.com</a>><br> Content-Type: text/plain; charset=3D"utf-8"<br> <br> A proposal for stemming the tide of mining centralisation -- Requiring a<br= > miner's signature in the block header (the whole of which is hashed), a= nd<br> paying out coinbase to the miner's public key.<br> <br> Please comment on whether this idea is feasible, has been thought of before= ,<br> etc., etc. Thank you.<br> <br> Motivation<br> ----------<br> <br> Mining is centralising to a handful of pool operators. This is bad for a<br= > number of political reasons, which we won't go into right now. But I ha= ve<br> always believed that some years down the line, they could hold the users<br= > hostage and change the rules to suit themselves. For instance by eliminatin= g<br> the halving of the block reward.<br> <br> Solution<br> --------<br> <br> Currently the block header is formed by the pool operator and distributed<b= r> for<br> hashing by the pooled miners. It is possible to divide the work among the<b= r> miners as the only thing that is used to search the hash space is by<br> changing<br> a nonce or two.<br> <br> I propose that we require each miner to sign the block header prior to<br> hashing. The signature will be included in the data that is hashed. Further= ,<br> the coinbase for the block must only pay out to the public key counterpart<= br> of<br> the private key used to sign the block header.<br> <br> A valid block will therefore have a signature in the block header that is<b= r> verified by the public key being paid by the coinbase transaction.<br> <br> Ramifications<br> -------------<br> <br> Work can no longer be divided among the pooled miners as before, without<br= > sharing the pool's private key amongst all of them. If the pool does tr= y to<br> take this route, then any of the miners may redeem the coinbase when it<br> matures. Therefore, all miners will use their own key pair.<br> <br> This will make it difficult to form a cooperating pool of miners who may no= t<br> trust each other, as the block rewards will be controlled by disparate<br> parties<br> and not by the pool operator. Only a tight clique of trusted miners would b= e<br> able to form their own private pool in such an environment.<br> <br> Attacks<br> -------<br> <br> Pooled hashpower, instead of earning bitcoins legitimately may try to break= <br> the system instead. They may try a double-spending attack, but in order to<= br> leverage the pool to its full potential the pool operator would again have<= br> to<br> share their private key with the whole pool. Due to the increased<br> cooperation<br> and coordination required for an attack, the probability of a 51% attack is= <br> much reduced.<br> -------------- next part --------------<br> An HTML attachment was scrubbed...<br> <br> ------------------------------<br> <br> Message: 3<br> Date: Wed, 11 Feb 2015 10:25:27 +0100<br> From: Natanael <<a href=3D"mailto:natanael.l@gmail.com">natanael.l@gmail= .com</a>><br> Subject: Re: [Bitcoin-development] Proposal: Requiring a miner's<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 signature in the block header<br> To: Hector Chu <<a href=3D"mailto:hectorchu@gmail.com">hectorchu@gmail.c= om</a>><br> Cc: <a href=3D"mailto:bitcoin-development@lists.sourceforge.net">bitcoin-de= velopment@lists.sourceforge.net</a><br> Message-ID:<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAAt2M1_qj0r03=3D<a href=3D"mailto:Ref9mN7b= JLg-odep3m5teZ7JWDLC%2BzknQdQQ@mail.gmail.com">Ref9mN7bJLg-odep3m5teZ7JWDLC= +zknQdQQ@mail.gmail.com</a>><br> Content-Type: text/plain; charset=3D"utf-8"<br> <br> Den 11 feb 2015 09:55 skrev "Hector Chu" <<a href=3D"mailto:he= ctorchu@gmail.com">hectorchu@gmail.com</a>>:<br> ><br> > A proposal for stemming the tide of mining centralisation -- Requiring= a<br> > miner's signature in the block header (the whole of which is hashe= d), and<br> > paying out coinbase to the miner's public key.<br> ><br> > Please comment on whether this idea is feasible, has been thought of<b= r> before,<br> > etc., etc. Thank you.<br> ><br> > Motivation<br> > ----------<br> ><br> > Mining is centralising to a handful of pool operators. This is bad for= a<br> > number of political reasons, which we won't go into right now. But= I have<br> > always believed that some years down the line, they could hold the use= rs<br> > hostage and change the rules to suit themselves. For instance by<br> eliminating<br> > the halving of the block reward.<br> <br> [...]<br> <br> > I propose that we require each miner to sign the block header prior to= <br> > hashing. The signature will be included in the data that is hashed.<br= > Further,<br> > the coinbase for the block must only pay out to the public key<br> counterpart of<br> > the private key used to sign the block header.<br> <br> [...]<br> <br> > This will make it difficult to form a cooperating pool of miners who m= ay<br> not<br> > trust each other, as the block rewards will be controlled by disparate= <br> parties<br> > and not by the pool operator. Only a tight clique of trusted miners wo= uld<br> be<br> > able to form their own private pool in such an environment.<br> <br> People already trust things like cloud mining, so your solution with<br> increasing technical trust requirements won't help. But you will howeve= r<br> break P2Pool instead.<br> <br> Also, note that threshold signatures (group signatures) could probably be<b= r> used by an actual distrusting pool's miners. There are already a proof = of<br> concept for this implemented with secp256k1 that works with Bitcoin clients= <br> silently. This wouldn't prevent such a pool from working.<br> -------------- next part --------------<br> An HTML attachment was scrubbed...<br> <br> ------------------------------<br> <br> ---------------------------------------------------------------------------= ---<br> Dive into the World of Parallel Programming. The Go Parallel Website,<br> sponsored by Intel and developed in partnership with Slashdot Media, is you= r<br> hub for all things parallel software development, from weekly thought<br> leadership blogs to news, videos, case studies, tutorials and more. Take a<= br> look and join the conversation now. <a href=3D"http://goparallel.sourceforg= e.net/" target=3D"_blank">http://goparallel.sourceforge.net/</a><br> <br> ------------------------------<br> <br> _______________________________________________<br> Bitcoin-development mailing list<br> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= pment@lists.sourceforge.net</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= " target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment</a><br> <br> <br> End of Bitcoin-development Digest, Vol 45, Issue 37<br> ***************************************************<br> </blockquote></div><br></div> --001a1134c93e340ccb050ed5abfb--