path: root/f5/24d7a2534e663f25dce9aaf0c415a3e19d6519

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">&lt;<a=
 href=3D"mailto:bitcoin-development-request@lists.sourceforge.net" target=
=3D"_blank">bitcoin-development-request@lists.sourceforge.net</a>&gt;</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 &#39;help&#39; 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 &quot;Re: Contents of Bitcoin-development digest...&quot;<br>
<br>
<br>
Today&#39;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&#39;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&#39;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 &lt;<a href=3D"mailto:eric@voskuil.org">eric@voskuil.org=
</a>&gt;<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 &lt;<a href=3D"mailto:martin.habovstiak@gmail.com">ma=
rtin.habovstiak@gmail.com</a>&gt;<br>
Cc: Bitcoin Dev &lt;<a href=3D"mailto:bitcoin-development@lists.sourceforge=
.net">bitcoin-development@lists.sourceforge.net</a>&gt;,=C2=A0 =C2=A0 Paul =
Puey<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:paul@airbitz.co">paul@air=
bitz.co</a>&gt;<br>
Message-ID: &lt;<a href=3D"mailto:54DA4657.5080604@voskuil.org">54DA4657.50=
80604@voskuil.org</a>&gt;<br>
Content-Type: text/plain; charset=3D&quot;utf-8&quot;<br>
<br>
On 02/10/2015 09:16 AM, M?rtin H?bo??tiak wrote:<br>
&gt; I&#39;m not sure if I was clear enough. Handshake should be used to<br=
>
&gt; establish authenticated AND encrypted communication using ECDH (or<br>
&gt; just DH, but I think it&#39;s easier to use ECDH, since required funct=
ions<br>
&gt; are already used in Bitcoin protocol), like RedPhone does. BTW<br>
&gt; knowledge of verification string is useless to the attacker.<br>
<br>
Yes, I think this was clear from your description.<br>
<br>
&gt; Yes, the customer must verify it verbally and the merchant shouldn&#39=
;t<br>
&gt; send the transaction before verification. Other possibility is that in=
<br>
&gt; case of differing verification strings new address is generated, so<br=
>
&gt; attacker doesn&#39;t know the address. But in this case, amount is lea=
ked<br>
&gt; 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>
&gt; Anyway, I don&#39;t believe the transaction can be made securely witho=
ut<br>
&gt; such interaction except with white-listing public keys, so I see no<br=
>
&gt; 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>
&gt; We don&#39;t have such strict regulations but I agree that security is=
<br>
&gt; important. Currently I think that verbal verification and manual<br>
&gt; confirmation is the best way to achieve high security and reasonable<b=
r>
&gt; 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>
&gt; 2015-02-10 17:55 GMT+01:00 Eric Voskuil &lt;<a href=3D"mailto:eric@vos=
kuil.org">eric@voskuil.org</a>&gt;:<br>
&gt;&gt; Martin,<br>
&gt;&gt;<br>
&gt;&gt; I like your idea for the commit protocol in that it resolves the<b=
r>
&gt;&gt; vandalous address substitution attack. However, I don&#39;t see a =
way to<br>
&gt;&gt; prevent privacy loss without adverse impact to the scenario.<br>
&gt;&gt;<br>
&gt;&gt; Anyone could perform the handshake and thereby obtain the payment<=
br>
&gt;&gt; request. Therefore to prevent inadvertent disclosure the customer =
must<br>
&gt;&gt; visually confirm the &quot;phrase&quot; and then verbally tell the=
 merchant to<br>
&gt;&gt; proceed by sending the payment request.<br>
&gt;&gt;<br>
&gt;&gt; One might argue that it&#39;s sufficient to preserve the integrity=
 of the<br>
&gt;&gt; transaction while suffering the privacy loss, especially given tha=
t a<br>
&gt;&gt; hijacked handshake should never result in a completed transaction =
-<br>
&gt;&gt; unless of course the hijacker pays.<br>
&gt;&gt;<br>
&gt;&gt; But imagine someone purchasing their meds. HIPAA requires the chec=
kout<br>
&gt;&gt; queue to form behind a yellow line. That speaks directly to this q=
uestion.<br>
&gt;&gt;<br>
&gt;&gt; e<br>
&gt;&gt;<br>
&gt;&gt; On 02/06/2015 01:07 AM, M?rtin H?bo??tiak wrote:<br>
&gt;&gt;&gt; 2015-02-06 2:29 GMT+01:00 Eric Voskuil &lt;<a href=3D"mailto:e=
ric@voskuil.org">eric@voskuil.org</a>&gt;:<br>
&gt;&gt;&gt;&gt; On 02/05/2015 04:36 PM, Martin Habov?tiak wrote:<br>
&gt;&gt;&gt;&gt;&gt; I believe, we are still talking about transactions of =
physical<br>
&gt;&gt;&gt;&gt;&gt; people in physical world. So yes, it&#39;s proximity b=
ased - people<br>
&gt;&gt;&gt;&gt;&gt; tell the words by mouth. :)<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Notice from my original comment:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; A MITM can substitute the key. If you don&=
#39;t have verifiable<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; identity associated with the public key (P=
KI/WoT), you need<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; a shared secret (such as a secret phrase).=
<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I said this could only be accomplished using a shared secr=
et or a<br>
&gt;&gt;&gt;&gt; trusted public key. Exchanging a value that is derived fro=
m a pair of<br>
&gt;&gt;&gt;&gt; public keys is a distinction without a difference. The pro=
blem remains<br>
&gt;&gt;&gt;&gt; that the parties must have a secure/out-of-band channel fo=
r<br>
&gt;&gt;&gt;&gt; communicating this value.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; The fact that they are face-to-face establishes this chann=
el, but that<br>
&gt;&gt;&gt;&gt; brings us back to the original problem, as it requires man=
ual<br>
&gt;&gt;&gt;&gt; verification - as in visual/audible scanning of the two va=
lues for<br>
&gt;&gt;&gt;&gt; comparison. At that point the visual comparison of the add=
ress, or some<br>
&gt;&gt;&gt;&gt; value derived from it, is simpler.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I have never been against manual verification. What I&#39;m tr=
ying to say<br>
&gt;&gt;&gt; is let&#39;s just make manual verification easier and more sec=
ure.<br>
&gt;&gt;&gt; Comparison of address is simpler for the coder but also simple=
r to<br>
&gt;&gt;&gt; attack. It has these problems:<br>
&gt;&gt;&gt; - Addresses broadcasted in plaintext (privacy issue)<br>
&gt;&gt;&gt; - Amounts broadcasted in plaintext (privacy issue)<br>
&gt;&gt;&gt; - Address is long - takes lot of time to verify (user experien=
ce issue)<br>
&gt;&gt;&gt; - Address prefix can be brute-forced, if too short or used to =
make<br>
&gt;&gt;&gt; &quot;black hole&quot; address if longer (vandalism issue)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Commit protocol can be used for both the encryption and the<br=
>
&gt;&gt;&gt; authentication while user experience is not bad and everything=
 is<br>
&gt;&gt;&gt; still secure.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; In case of RedPhone, you read those words verbally ove=
r not-yet-<br>
&gt;&gt;&gt;&gt;&gt; verified channel relying on difficulty of spoofing you=
r voice. Also<br>
&gt;&gt;&gt;&gt;&gt; the app remembers the public keys, so you don&#39;t ne=
ed to verify<br>
&gt;&gt;&gt;&gt;&gt; second time.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; This is reasonable, but wouldn&#39;t help in the case of a=
n ad-hoc<br>
&gt;&gt;&gt;&gt; connection between parties who don&#39;t know each other w=
ell.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; I suggest you to try RedPhone (called Signal on iPhone=
) yourself.<br>
&gt;&gt;&gt;&gt;&gt; It&#39;s free/open source, Internet-based and end-to-e=
nd encrypted. You<br>
&gt;&gt;&gt;&gt;&gt; may find it useful some day. Also I&#39;m willing to h=
elp you with<br>
&gt;&gt;&gt;&gt;&gt; trying it after I wake up. (~8 hours: Send me private =
e-mail if<br>
&gt;&gt;&gt;&gt;&gt; you want to.)<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I appreciate the offer. I really don&#39;t trust *any* sma=
rtphone as a<br>
&gt;&gt;&gt;&gt; platform for secure communication/data. But encrypting on =
the wire does<br>
&gt;&gt;&gt;&gt; of course shrink the attack surface and increase the attac=
ker&#39;s cost.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; e<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; D?a 6. febru?ra 2015 1:22:23 CET pou??vate? Eric Vosku=
il<br>
&gt;&gt;&gt;&gt; &lt;<a href=3D"mailto:eric@voskuil.org">eric@voskuil.org</=
a>&gt; nap?sal:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; On 02/05/2015 04:04 PM, M?rtin H?bo??tiak wrote:<b=
r>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; That&#39;s exactly what I though when seeing t=
he RedPhone code, but after<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; I studied the commit protocol I realized it&#3=
9;s actually secure and<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; convenient way to do it. You should do that to=
o. :)<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; I was analyzing the model as you described it to m=
e. A formal analysis<br>
&gt;&gt;&gt;&gt;&gt;&gt; of the security model of a particular implementati=
on, based on<br>
&gt;&gt;&gt;&gt;&gt;&gt; inference<br>
&gt;&gt;&gt;&gt;&gt; &gt;from source code, is a bit beyond what I signed up=
 for. But I&#39;m<br>
&gt;&gt;&gt;&gt;&gt;&gt; perfectly willing to comment on your description o=
f the model if you<br>
&gt;&gt;&gt;&gt;&gt;&gt; are<br>
&gt;&gt;&gt;&gt;&gt;&gt; willing to indulge me.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; Shortly, how it works:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; The initiator of the connection sends commit m=
essage containing the<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; hash of his temporary public ECDH part, second=
 party sends back their<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; public ECDH part and then initiator sends his =
public ECDH part in<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; open. All three messages are hashed together a=
nd the first two bytes<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; are used to select two words from a shared dic=
tionary which are<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; displayed on the screen of both the initiator =
and the second party.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; The parties communicate those two words and ve=
rify they match.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; How do they compare words if they haven&#39;t yet =
established a secure<br>
&gt;&gt;&gt;&gt;&gt;&gt; channel?<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; If an attacker wants to do MITM, he has a chan=
ce of choosing right<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; public parts 1:65536. There is no way to brute=
-force it, since that<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; would be noticed immediately. If instead of tw=
o words based on the<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; first two bytes, four words from BIP39 wordlis=
t were chosen, it would<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; provide entropy of 44 bits which I believe sho=
uld be enough even for<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; paranoid people.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; How this would work in Bitcoin payment scenari=
o: user&#39;s phone<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; broadcasts his name, merchant inputs amount an=
d selects the name from<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; the list, commit message is sent (and then the=
 remaining two<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; messages), merchant spells four words he sees =
on the screen and buyer<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; confirms transaction after verifying that word=
s match.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; So the assumption is that there exists a secure (a=
s in proximity-based)<br>
&gt;&gt;&gt;&gt;&gt;&gt; communication channel?<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; e<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; 2015-02-06 0:46 GMT+01:00 Eric Voskuil &lt;<a =
href=3D"mailto:eric@voskuil.org">eric@voskuil.org</a>&gt;:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; On 02/05/2015 03:36 PM, M?rtin H?bo??tiak =
wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; A BIP-70 signed payment request in=
 the initial broadcast can<br>
&gt;&gt;&gt;&gt;&gt;&gt; resolve the<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; integrity issues, but because of t=
he public nature of the<br>
&gt;&gt;&gt;&gt;&gt;&gt; broadcast<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; coupled with strong public identit=
y, the privacy compromise is<br>
&gt;&gt;&gt;&gt;&gt;&gt; much<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; worse. Now transactions are crypto=
graphically tainted.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; This is also the problem with BIP-=
70 over the web. TLS and other<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; security precautions aside, an int=
erloper on the communication,<br>
&gt;&gt;&gt;&gt;&gt;&gt; desktop,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; datacenter, etc., can capture paym=
ent requests and strongly<br>
&gt;&gt;&gt;&gt;&gt;&gt; correlate<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; transactions to identities in an a=
utomated manner. The payment<br>
&gt;&gt;&gt;&gt;&gt;&gt; request<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; must be kept private between the p=
arties, and that&#39;s hard to do.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; What about using encryption with forwa=
rd secrecy? Merchant would<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; generate signed request containing pub=
lic ECDH part, buyer would<br>
&gt;&gt;&gt;&gt;&gt;&gt; send<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; back transaction encrypted with ECDH a=
nd his public ECDH part. If<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; receiving address/amount is meant to b=
e private, use commit<br>
&gt;&gt;&gt;&gt;&gt;&gt; protocol<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; (see ZRTP/RedPhone) and short authenti=
cation phrase (which is hard<br>
&gt;&gt;&gt;&gt;&gt;&gt; to<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; spoof thanks to commit protocol - see =
RedPhone)?<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Hi Martin,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; The problem is that you need to verify the=
 ownership of the public<br>
&gt;&gt;&gt;&gt;&gt;&gt; key.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; A MITM can substitute the key. If you don&=
#39;t have verifiable identity<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; associated with the public key (PKI/WoT), =
you need a shared secret<br>
&gt;&gt;&gt;&gt;&gt;&gt; (such<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; as a secret phrase). But the problem is th=
en establishing that<br>
&gt;&gt;&gt;&gt;&gt;&gt; secret<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; over a public channel.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; You can bootstrap a private session over t=
he untrusted network using<br>
&gt;&gt;&gt;&gt;&gt;&gt; a<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; trusted public key (PKI/WoT). But the pres=
umption is that you are<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; already doing this over the web (using TLS=
). That process is subject<br>
&gt;&gt;&gt;&gt;&gt;&gt; to<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; attack at the CA. WoT is not subject to a =
CA attack, because it&#39;s<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; decentralized. But it&#39;s also not suffi=
ciently deployed for some<br>
&gt;&gt;&gt;&gt;&gt;&gt; scenarios.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; e<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;<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 &lt;<a href=3D"mailto:hectorchu@gmail.com">hectorchu@gmail=
.com</a>&gt;<br>
Subject: [Bitcoin-development] Proposal: Requiring a miner&#39;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 &lt;<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>&gt;<br>
Content-Type: text/plain; charset=3D&quot;utf-8&quot;<br>
<br>
A proposal for stemming the tide of mining centralisation -- Requiring a<br=
>
miner&#39;s signature in the block header (the whole of which is hashed), a=
nd<br>
paying out coinbase to the miner&#39;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&#39;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&#39;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 &lt;<a href=3D"mailto:natanael.l@gmail.com">natanael.l@gmail=
.com</a>&gt;<br>
Subject: Re: [Bitcoin-development] Proposal: Requiring a miner&#39;s<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 signature in the block header<br>
To: Hector Chu &lt;<a href=3D"mailto:hectorchu@gmail.com">hectorchu@gmail.c=
om</a>&gt;<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 &lt;CAAt2M1_qj0r03=3D<a href=3D"mailto:Ref9mN7b=
JLg-odep3m5teZ7JWDLC%2BzknQdQQ@mail.gmail.com">Ref9mN7bJLg-odep3m5teZ7JWDLC=
+zknQdQQ@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=3D&quot;utf-8&quot;<br>
<br>
Den 11 feb 2015 09:55 skrev &quot;Hector Chu&quot; &lt;<a href=3D"mailto:he=
ctorchu@gmail.com">hectorchu@gmail.com</a>&gt;:<br>
&gt;<br>
&gt; A proposal for stemming the tide of mining centralisation -- Requiring=
 a<br>
&gt; miner&#39;s signature in the block header (the whole of which is hashe=
d), and<br>
&gt; paying out coinbase to the miner&#39;s public key.<br>
&gt;<br>
&gt; Please comment on whether this idea is feasible, has been thought of<b=
r>
before,<br>
&gt; etc., etc. Thank you.<br>
&gt;<br>
&gt; Motivation<br>
&gt; ----------<br>
&gt;<br>
&gt; Mining is centralising to a handful of pool operators. This is bad for=
 a<br>
&gt; number of political reasons, which we won&#39;t go into right now. But=
 I have<br>
&gt; always believed that some years down the line, they could hold the use=
rs<br>
&gt; hostage and change the rules to suit themselves. For instance by<br>
eliminating<br>
&gt; the halving of the block reward.<br>
<br>
[...]<br>
<br>
&gt; I propose that we require each miner to sign the block header prior to=
<br>
&gt; hashing. The signature will be included in the data that is hashed.<br=
>
Further,<br>
&gt; the coinbase for the block must only pay out to the public key<br>
counterpart of<br>
&gt; the private key used to sign the block header.<br>
<br>
[...]<br>
<br>
&gt; This will make it difficult to form a cooperating pool of miners who m=
ay<br>
not<br>
&gt; trust each other, as the block rewards will be controlled by disparate=
<br>
parties<br>
&gt; and not by the pool operator. Only a tight clique of trusted miners wo=
uld<br>
be<br>
&gt; 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&#39;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&#39;s miners. There are already a proof =
of<br>
concept for this implemented with secp256k1 that works with Bitcoin clients=
<br>
silently. This wouldn&#39;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--