<div dir="ltr">UNSUBSCRIBE</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 11, 2015 at 2:25 AM, <span dir="ltr"><<a href="mailto:bitcoin-development-request@lists.sourceforge.net" target="_blank">bitcoin-development-request@lists.sourceforge.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Bitcoin-development mailing list submissions to<br>
<a href="mailto:bitcoin-development@lists.sourceforge.net">bitcoin-development@lists.sourceforge.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:bitcoin-development-request@lists.sourceforge.net">bitcoin-development-request@lists.sourceforge.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:bitcoin-development-owner@lists.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>
1. Re: Proposal for P2P Wireless (Bluetooth LE) transfer of<br>
Payment URI (Eric Voskuil)<br>
2. Proposal: Requiring a miner's signature in the block header<br>
(Hector Chu)<br>
3. Re: Proposal: Requiring a miner's signature in the block<br>
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="mailto:eric@voskuil.org">eric@voskuil.org</a>><br>
Subject: Re: [Bitcoin-development] Proposal for P2P Wireless<br>
(Bluetooth LE) transfer of Payment URI<br>
To: M?rtin H?bo??tiak <<a href="mailto:martin.habovstiak@gmail.com">martin.habovstiak@gmail.com</a>><br>
Cc: Bitcoin Dev <<a href="mailto:bitcoin-development@lists.sourceforge.net">bitcoin-development@lists.sourceforge.net</a>>, Paul Puey<br>
<<a href="mailto:paul@airbitz.co">paul@airbitz.co</a>><br>
Message-ID: <<a href="mailto:54DA4657.5080604@voskuil.org">54DA4657.5080604@voskuil.org</a>><br>
Content-Type: text/plain; charset="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 functions<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 leaked<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 without<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<br>
> 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="mailto:eric@voskuil.org">eric@voskuil.org</a>>:<br>
>> Martin,<br>
>><br>
>> I like your idea for the commit protocol in that it resolves the<br>
>> 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 that 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 checkout<br>
>> queue to form behind a yellow line. That speaks directly to this question.<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="mailto:eric@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 based - 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't have verifiable<br>
>>>>>>>> identity associated with the public key (PKI/WoT), you need<br>
>>>>>>>> a shared secret (such as a secret phrase).<br>
>>>><br>
>>>> I said this could only be accomplished using a shared secret or a<br>
>>>> trusted public key. Exchanging a value that is derived from a pair of<br>
>>>> public keys is a distinction without a difference. The problem remains<br>
>>>> that the parties must have a secure/out-of-band channel for<br>
>>>> communicating this value.<br>
>>>><br>
>>>> The fact that they are face-to-face establishes this channel, but that<br>
>>>> brings us back to the original problem, as it requires manual<br>
>>>> verification - as in visual/audible scanning of the two values for<br>
>>>> comparison. At that point the visual comparison of the address, or some<br>
>>>> value derived from it, is simpler.<br>
>>><br>
>>> I have never been against manual verification. What I'm trying to say<br>
>>> is let's just make manual verification easier and more secure.<br>
>>> Comparison of address is simpler for the coder but also simpler 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 experience 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 over not-yet-<br>
>>>>> verified channel relying on difficulty of spoofing your voice. Also<br>
>>>>> the app remembers the public keys, so you don't need to verify<br>
>>>>> second time.<br>
>>>><br>
>>>> This is reasonable, but wouldn't help in the case of an ad-hoc<br>
>>>> connection between parties who don't know each other well.<br>
>>>><br>
>>>>> I suggest you to try RedPhone (called Signal on iPhone) yourself.<br>
>>>>> It's free/open source, Internet-based and end-to-end encrypted. You<br>
>>>>> may find it useful some day. Also I'm willing to help 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* smartphone as a<br>
>>>> platform for secure communication/data. But encrypting on the wire does<br>
>>>> of course shrink the attack surface and increase the attacker's cost.<br>
>>>><br>
>>>> e<br>
>>>><br>
>>>>> D?a 6. febru?ra 2015 1:22:23 CET pou??vate? Eric Voskuil<br>
>>>> <<a href="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:<br>
>>>>>>> That's exactly what I though when seeing the RedPhone code, but after<br>
>>>>>>> I studied the commit protocol I realized it's actually secure and<br>
>>>>>>> convenient way to do it. You should do that too. :)<br>
>>>>><br>
>>>>>> I was analyzing the model as you described it to me. A formal analysis<br>
>>>>>> of the security model of a particular implementation, 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 of 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 message 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 and the first two bytes<br>
>>>>>>> are used to select two words from a shared dictionary which are<br>
>>>>>>> displayed on the screen of both the initiator and the second party.<br>
>>>>><br>
>>>>>>> The parties communicate those two words and verify 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 chance 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 two words based on the<br>
>>>>>>> first two bytes, four words from BIP39 wordlist were chosen, it would<br>
>>>>>>> provide entropy of 44 bits which I believe should be enough even for<br>
>>>>>>> paranoid people.<br>
>>>>>>><br>
>>>>>>> How this would work in Bitcoin payment scenario: user's phone<br>
>>>>>>> broadcasts his name, merchant inputs amount and 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 words match.<br>
>>>>><br>
>>>>>> So the assumption is that there exists a secure (as in proximity-based)<br>
>>>>>> communication channel?<br>
>>>>><br>
>>>>>> e<br>
>>>>><br>
>>>>>>> 2015-02-06 0:46 GMT+01:00 Eric Voskuil <<a href="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 the public nature of the<br>
>>>>>> broadcast<br>
>>>>>>>>>> coupled with strong public identity, the privacy compromise is<br>
>>>>>> much<br>
>>>>>>>>>> worse. Now transactions are cryptographically tainted.<br>
>>>>>>>>>><br>
>>>>>>>>>> This is also the problem with BIP-70 over the web. TLS and other<br>
>>>>>>>>>> security precautions aside, an interloper on the communication,<br>
>>>>>> desktop,<br>
>>>>>>>>>> datacenter, etc., can capture payment requests and strongly<br>
>>>>>> correlate<br>
>>>>>>>>>> transactions to identities in an automated manner. The payment<br>
>>>>>> request<br>
>>>>>>>>>> must be kept private between the parties, and that's hard to do.<br>
>>>>>>>>><br>
>>>>>>>>> What about using encryption with forward secrecy? Merchant would<br>
>>>>>>>>> generate signed request containing public ECDH part, buyer would<br>
>>>>>> send<br>
>>>>>>>>> back transaction encrypted with ECDH and his public ECDH part. If<br>
>>>>>>>>> receiving address/amount is meant to be private, use commit<br>
>>>>>> protocol<br>
>>>>>>>>> (see ZRTP/RedPhone) and short authentication 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'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 then establishing that<br>
>>>>>> secret<br>
>>>>>>>> over a public channel.<br>
>>>>>>>><br>
>>>>>>>> You can bootstrap a private session over the untrusted network using<br>
>>>>>> a<br>
>>>>>>>> trusted public key (PKI/WoT). But the presumption 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 sufficiently 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="mailto:hectorchu@gmail.com">hectorchu@gmail.com</a>><br>
Subject: [Bitcoin-development] Proposal: Requiring a miner's signature<br>
in the block header<br>
To: <a href="mailto:bitcoin-development@lists.sourceforge.net">bitcoin-development@lists.sourceforge.net</a><br>
Message-ID:<br>
<<a href="mailto:CAAO2FKEFxC_byt4xVJb0S-7yy0M7M-Av7MHUH-RBDuri_GAFtw@mail.gmail.com">CAAO2FKEFxC_byt4xVJb0S-7yy0M7M-Av7MHUH-RBDuri_GAFtw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="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), 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 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 users<br>
hostage and change the rules to suit themselves. For instance by eliminating<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<br>
for<br>
hashing by the pooled miners. It is possible to divide the work among the<br>
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<br>
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 try 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 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 would be<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="mailto:natanael.l@gmail.com">natanael.l@gmail.com</a>><br>
Subject: Re: [Bitcoin-development] Proposal: Requiring a miner's<br>
signature in the block header<br>
To: Hector Chu <<a href="mailto:hectorchu@gmail.com">hectorchu@gmail.com</a>><br>
Cc: <a href="mailto:bitcoin-development@lists.sourceforge.net">bitcoin-development@lists.sourceforge.net</a><br>
Message-ID:<br>
<CAAt2M1_qj0r03=<a href="mailto:Ref9mN7bJLg-odep3m5teZ7JWDLC%2BzknQdQQ@mail.gmail.com">Ref9mN7bJLg-odep3m5teZ7JWDLC+zknQdQQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Den 11 feb 2015 09:55 skrev "Hector Chu" <<a href="mailto:hectorchu@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 hashed), 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<br>
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 users<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 may<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 would<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 however<br>
break P2Pool instead.<br>
<br>
Also, note that threshold signatures (group signatures) could probably be<br>
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 your<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="http://goparallel.sourceforge.net/" target="_blank">http://goparallel.sourceforge.net/</a><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br>
<br>
End of Bitcoin-development Digest, Vol 45, Issue 37<br>
***************************************************<br>
</blockquote></div><br></div>