From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YLtPY-0007vk-3c for bitcoin-development@lists.sourceforge.net; Thu, 12 Feb 2015 13:02:28 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.49 as permitted sender) client-ip=74.125.82.49; envelope-from=natanael.l@gmail.com; helo=mail-wg0-f49.google.com; Received: from mail-wg0-f49.google.com ([74.125.82.49]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YLtPX-0005Rd-4g for bitcoin-development@lists.sourceforge.net; Thu, 12 Feb 2015 13:02:28 +0000 Received: by mail-wg0-f49.google.com with SMTP id l18so9931798wgh.8 for ; Thu, 12 Feb 2015 05:02:21 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.172.35 with SMTP id az3mr7561608wjc.43.1423746141026; Thu, 12 Feb 2015 05:02:21 -0800 (PST) Received: by 10.194.28.170 with HTTP; Thu, 12 Feb 2015 05:02:20 -0800 (PST) Received: by 10.194.28.170 with HTTP; Thu, 12 Feb 2015 05:02:20 -0800 (PST) In-Reply-To: References: <20150212064719.GA6563@savin.petertodd.org> Date: Thu, 12 Feb 2015 14:02:20 +0100 Message-ID: From: Natanael To: Mike Hearn Content-Type: multipart/alternative; boundary=089e0122e8b6fc80de050ee3ba22 X-Spam-Score: -0.6 (/) 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 (natanael.l[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1YLtPX-0005Rd-4g Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 13:02:28 -0000 --089e0122e8b6fc80de050ee3ba22 Content-Type: text/plain; charset=UTF-8 Den 12 feb 2015 13:49 skrev "Mike Hearn" : >> >> Are you not counting collateralized multisignature notaries? Its an extended version of the Greenaddress.it model. > > It makes unconfirmed transactions useless in the classical Bitcoin model. Obviously if you introduce a trusted third party you can fix things, but then you're back to having the disadvantages of centralised trust. That trust you put in them is extremely limited, and temporary. First of all, the standard multisignature notary model applies like how I originally described it in my blog post over a year ago. You can prove a doublespend instantly by showing two conflicting transactions both signed by thar party. This pair can be distributed as a proof of malice globally in seconds via a push messaging mechanism. After confirmation in the blockchain, you have standard Bitcoin transaction security. To profit, the notary would have to be sure the payout from agreeing on collusion (or to perform the doublespend themselves) would pay out better than acting honestly for a given amount of time info the future. This means transactions for small sums are secure. To provide security for high value transactions, NRW adds a collateral transaction that the notary stands for and signs in advance, and gives to the seller. The key here is that it is constructed such that if the original payment gets doublespent, then this collateral transaction to the seller becomes spendable. So there is two outcomes - either the customer or the notary pays the seller. The customer can't force a doublespend. The notary can't steal or freeze funds (due to nlocktime fund recovery option). The seller knows he'll get the funds for sure before delivering the goods. Nobody is at risk. --089e0122e8b6fc80de050ee3ba22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Den 12 feb 2015 13:49 skrev "Mike Hearn" <mike@plan99.net>:
>>
>> Are you not counting collateralized multisignature notaries? Its a= n extended version of the Greenaddress.it model.
>
> It makes unconfirmed transactions useless in the classical Bitcoin mod= el. Obviously if you introduce a trusted third party you can fix things, bu= t then you're back to having the disadvantages of centralised trust.

That trust you put in them is extremely limited, and tempora= ry.

First of all, the standard multisignature notary model appli= es like how I originally described it in my blog post over a year ago.

You can prove a doublespend instantly by showing two conflic= ting transactions both signed by thar party. This pair can be distributed a= s a proof of malice globally in seconds via a push messaging mechanism.

After confirmation in the blockchain, you have standard Bitc= oin transaction security.
To profit, the notary would have to be sure the payout from agreeing on col= lusion (or to perform the doublespend themselves) would pay out better than= acting honestly for a given amount of time info the future. This means tra= nsactions for small sums are secure.

To provide security for high value transactions, NRW adds a = collateral transaction that the notary stands for and signs in advance, and= gives to the seller. The key here is that it is constructed such that if t= he original payment gets doublespent, then this collateral transaction to t= he seller becomes spendable.

So there is two outcomes - either the customer or the notary= pays the seller. The customer can't force a doublespend. The notary ca= n't steal or freeze funds (due to nlocktime fund recovery option). The = seller knows he'll get the funds for sure before delivering the goods. = Nobody is at risk.

--089e0122e8b6fc80de050ee3ba22--