diff options
author | David Vorick <david.vorick@gmail.com> | 2013-05-21 10:26:18 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2013-05-21 14:26:26 +0000 |
commit | 69eb40ed7df7c178968c2c3448e07cbf343ce7cb (patch) | |
tree | 764d41f0f0648b4a05ce612680c5884a1c134e74 /87 | |
parent | d74fb70e3da4dd4b959757f7a921809971ec93d5 (diff) | |
download | pi-bitcoindev-69eb40ed7df7c178968c2c3448e07cbf343ce7cb.tar.gz pi-bitcoindev-69eb40ed7df7c178968c2c3448e07cbf343ce7cb.zip |
Re: [Bitcoin-development] Double Spend Notification
Diffstat (limited to '87')
-rw-r--r-- | 87/d89ddb1da063867f6381add58ff820cfd1e728 | 309 |
1 files changed, 309 insertions, 0 deletions
diff --git a/87/d89ddb1da063867f6381add58ff820cfd1e728 b/87/d89ddb1da063867f6381add58ff820cfd1e728 new file mode 100644 index 000000000..a41abbd53 --- /dev/null +++ b/87/d89ddb1da063867f6381add58ff820cfd1e728 @@ -0,0 +1,309 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <david.vorick@gmail.com>) id 1UenWE-0007NE-K1 + for bitcoin-development@lists.sourceforge.net; + Tue, 21 May 2013 14:26:26 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.223.172 as permitted sender) + client-ip=209.85.223.172; envelope-from=david.vorick@gmail.com; + helo=mail-ie0-f172.google.com; +Received: from mail-ie0-f172.google.com ([209.85.223.172]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1UenWD-0003n3-7D + for bitcoin-development@lists.sourceforge.net; + Tue, 21 May 2013 14:26:26 +0000 +Received: by mail-ie0-f172.google.com with SMTP id 16so1779324iea.3 + for <bitcoin-development@lists.sourceforge.net>; + Tue, 21 May 2013 07:26:20 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.50.67.10 with SMTP id j10mr1586202igt.70.1369146379073; Tue, + 21 May 2013 07:26:19 -0700 (PDT) +Received: by 10.42.216.16 with HTTP; Tue, 21 May 2013 07:26:18 -0700 (PDT) +In-Reply-To: <20130521130534.GA27580@tilt> +References: <519AC3A8.1020306@quinnharris.me> + <CA+i0-i_+Tes+ePRqmDGEXDQ_L=S5y8gHBKk77zaLgTGOS3OMyA@mail.gmail.com> + <CAPg+sBjmXyLkgfwzC8h+ZFkmyUf6nzbGo0oAWR9nsJOTOfOXEg@mail.gmail.com> + <CAAS2fgRCpXUgw=GpE9_AcTgWcdCaDC6_16Xp5+oOZC0_1xmf-w@mail.gmail.com> + <20130521130534.GA27580@tilt> +Date: Tue, 21 May 2013 10:26:18 -0400 +Message-ID: <CAFVRnyrROk8SXVjrr5LWb4c68zjezj=Oe+bqpBNjp=y+e5uWVA@mail.gmail.com> +From: David Vorick <david.vorick@gmail.com> +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Content-Type: multipart/alternative; boundary=047d7bdc10d891ff2a04dd3b3bf6 +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 + (david.vorick[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.2 MISSING_HEADERS Missing To: header + 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 + 0.0 TO_NO_BRKTS_PCNT To: misformatted + percentage +X-Headers-End: 1UenWD-0003n3-7D +Subject: Re: [Bitcoin-development] Double Spend Notification +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: Tue, 21 May 2013 14:26:26 -0000 + +--047d7bdc10d891ff2a04dd3b3bf6 +Content-Type: text/plain; charset=ISO-8859-1 + +I've been wondering why a blockchain is necessary at all. Ripple doesn't +have one (I haven't looked closely at their implementation but it seems +reasonable to go without one). + +When you do blockchain based transaction confirmations, you give full +authority to the miner that finds the transaction block. That miner gets to +decide which transactions are real and which transactions are fraudulent, +and even has the option to not include any particular transaction (maybe +they used dirty coins, or something like that). The advantage to using a +blockchain is that any tough decisions to choose between two conflicting +transactions can be decided in an easy manner. The person who finds the +next block picks their favorite and tells everybody else. + +But this has a huge downside: network confirmation can take more than 10 +minutes (for an unlucky block). If you really want to be certain, a +confirmation can take more than an hour (multi-block confirmations). + +For a transaction with no conflict, the network should be able to confirm +the transaction within a few seconds, because the information can propagate +to all of the nodes that quickly. The new issue is that if conflicting +transactions appear on opposite sides of the network, there needs to be +some way for the network to determine which transaction gets priority. +Right now the method is to wait for a miner to find a block and then go +with his decision, but perhaps there's some way to resolve a double spend +conflict without waiting for a block. + +All you really need is for 51% of the nodes in the network to confirm a +transaction as legitimate in order for it to be 'confirmed' by the entire +network. Malicious nodes (nodes that confirm both conflicting transactions, +or nodes that refuse to confirm a transaction even though there are no +conflicts) can be excommunicated. The two challenges then would be + +1. telling everybody when a transaction has hit 51% confirmation +2. dealing with a triple-or-more spend: A has 25% confirmation, B has 40% +confirmation, C has 35% confirmation, who wins? + +For the first problem, each node only needs to see the transaction twice: +once when the node sees it for the first time and confirms it, and a second +time after the transaction hits 51% and is announced to the network as +confirmed. The first node to see the transaction hit 51% will make the +announcement. + +The second problem could be reduced to a majority-wins problem. If a node +sees that 94% of votes are in, and one of the transactions is more than 6% +ahead of the others, that transaction is the winner. + +If for whatever reason a clear majority is not hit by the time the next +mining block is found, the miner could just choose the transaction that had +the most votes when it saw it. It may be outdated but would clear up any +issues. This delay would only occur for a transaction if the spender of the +coins was attempting a double spend, and would indicate dishonesty to the +merchants. They could then choose to wait and see if their account is the +winner or they could just refuse to give out their goods. + + +On Tue, May 21, 2013 at 9:05 AM, Peter Todd <pete@petertodd.org> wrote: + +> On Mon, May 20, 2013 at 08:54:25PM -0700, Gregory Maxwell wrote: +> > One point that was only recently exposed to me is that replacement +> > combined with child-pays-for-parent creates a new kind of double spend +> > _defense_: If someone double spends a payment to an online key of +> > yours, you can instantly produce a child transaction that pays 100% of +> > the double spend to fees... so a double spender can hurt you but not +> > profit from it. (and if your side of the transaction is +> > potentially/partially reversible he will lose)... +> +> You can do better than that actually: you can arrange the transaction +> such that the double-spender is hurt by asking them to pay an excess on +> top of the initial payment, and having that excess get returned to them +> in a subsequent transaction. Of course, that's trusting the merchant, +> but you're trusting the merchant to ship to a product anyway so... +> +> A really interesting example for this though would be applications where +> you are making a deposit. You credit the customer account immediately +> with half of the deposit amount, allowing them to immediately spend that +> portion for something transferable. (perhaps an alt-coin) If the +> customer tries to double-spend you burn half to fees, still leaving the +> other half to pay for what they did spend. If they don't double-spend, +> the rest of the balance becomes available after n confirmations. A +> BTC->alt-coin exchange could use this mechanism for instance, although +> it only works with widespread replace-by-fee adoption; blockchain.info's +> shared-send service is another application, as is SatoshiDice. (the +> failed bet tx can be the refund) +> +> What's nice here is even if the customer tries to pay a miner to do the +> dirty work, a short-term rational miner still has an incentive to screw +> over the customer by accepting the merchant's double-spend. Now the +> customer can promise the miner future business, but they've shown +> themselves to be dishonest... how much honor is there among thieves? +> +> -- +> 'peter'[:-1]@petertodd.org +> 00000000000000f31f5cd20f915e3edb8e3fceea49580235b984fea63f1f882c +> +> +> ------------------------------------------------------------------------------ +> Try New Relic Now & We'll Send You this Cool Shirt +> New Relic is the only SaaS-based application performance monitoring service +> that delivers powerful full stack analytics. Optimize and monitor your +> browser, app, & servers with just a few lines of code. Try New Relic +> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +> +> + +--047d7bdc10d891ff2a04dd3b3bf6 +Content-Type: text/html; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div><div><div>I've been wondering why a blockchain is= + necessary at all. + Ripple doesn't have one (I haven't looked closely at their=20 +implementation but it seems reasonable to go without one).<br><br> +</div>When you do blockchain based transaction confirmations, you give=20 +full authority to the miner that finds the transaction block. That miner + gets to decide which transactions are real and which transactions are=20 +fraudulent, and even has the option to not include any particular=20 +transaction (maybe they used dirty coins, or something like that). The=20 +advantage to using a blockchain is that any tough decisions to choose=20 +between two conflicting transactions can be decided in an easy manner.=20 +The person who finds the next block picks their favorite and tells=20 +everybody else.<br> +<br></div>But this has a huge downside: network confirmation can take=20 +more than 10 minutes (for an unlucky block). If you really want to be=20 +certain, a confirmation can take more than an hour (multi-block=20 +confirmations).<br> +<br></div><div>For a transaction with no conflict, the network should be + able to confirm the transaction within a few seconds, because the=20 +information can propagate to all of the nodes that quickly. The new=20 +issue is that if conflicting transactions appear on opposite sides of=20 +the network, there needs to be some way for the network to determine=20 +which transaction gets priority. Right now the method is to wait for a=20 +miner to find a block and then go with his decision, but perhaps there'= +s + some way to resolve a double spend conflict without waiting for a=20 +block.<br> +<br></div><div>All you really need is for 51% of the nodes in the=20 +network to confirm a transaction as legitimate in order for it to be=20 +'confirmed' by the entire network. Malicious nodes (nodes that conf= +irm=20 +both conflicting transactions, or nodes that refuse to confirm a=20 +transaction even though there are no conflicts) can be excommunicated.=20 +The two challenges then would be<br> +<br></div><div>1. telling everybody when a transaction has hit 51% confirma= +tion<br></div><div>2. dealing with a triple-or-more spend: A has 25% confir= +mation, B has 40% confirmation, C has 35% confirmation, who wins?<br><br> + +</div><div>For the first problem, each node only needs to see the=20 +transaction twice: once when the node sees it for the first time and=20 +confirms it, and a second time after the transaction hits 51% and is=20 +announced to the network as confirmed. The first node to see the=20 +transaction hit 51% will make the announcement.<br> +<br></div><div>The second problem could be reduced to a majority-wins=20 +problem. If a node sees that 94% of votes are in, and one of the=20 +transactions is more than 6% ahead of the others, that transaction is=20 +the winner.<br><br> +</div>If for whatever reason a clear majority is not hit by the=20 +time the next mining block is found, the miner could just choose the=20 +transaction that had the most votes when it saw it. It may be outdated=20 +but would clear up any issues. This delay would only occur for a=20 +transaction if the spender of the coins was attempting a double spend,=20 +and would indicate dishonesty to the merchants. They could then choose=20 +to wait and see if their account is the winner or they could just refuse + to give out their goods.</div><div class=3D"gmail_extra"><br><br><div clas= +s=3D"gmail_quote">On Tue, May 21, 2013 at 9:05 AM, Peter Todd <span dir=3D"= +ltr"><<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@peter= +todd.org</a>></span> wrote:<br> +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex"><div class=3D"im">On Mon, May 20, 2013 at 08= +:54:25PM -0700, Gregory Maxwell wrote:<br> +> One point that was only recently exposed to me is that replacement<br> +> combined with child-pays-for-parent creates a new kind of double spend= +<br> +> _defense_: If someone double spends a payment to an online key of<br> +> yours, you can instantly produce a child transaction that pays 100% of= +<br> +> the double spend to fees... so a double spender can hurt you but not<b= +r> +> profit from it. =A0(and if your side of the transaction is<br> +> potentially/partially reversible he will lose)...<br> +<br> +</div>You can do better than that actually: you can arrange the transaction= +<br> +such that the double-spender is hurt by asking them to pay an excess on<br> +top of the initial payment, and having that excess get returned to them<br> +in a subsequent transaction. Of course, that's trusting the merchant,<b= +r> +but you're trusting the merchant to ship to a product anyway so...<br> +<br> +A really interesting example for this though would be applications where<br= +> +you are making a deposit. You credit the customer account immediately<br> +with half of the deposit amount, allowing them to immediately spend that<br= +> +portion for something transferable. (perhaps an alt-coin) If the<br> +customer tries to double-spend you burn half to fees, still leaving the<br> +other half to pay for what they did spend. If they don't double-spend,<= +br> +the rest of the balance becomes available after n confirmations. A<br> +BTC->alt-coin exchange could use this mechanism for instance, although<b= +r> +it only works with widespread replace-by-fee adoption; <a href=3D"http://bl= +ockchain.info" target=3D"_blank">blockchain.info</a>'s<br> +shared-send service is another application, as is SatoshiDice. (the<br> +failed bet tx can be the refund)<br> +<br> +What's nice here is even if the customer tries to pay a miner to do the= +<br> +dirty work, a short-term rational miner still has an incentive to screw<br> +over the customer by accepting the merchant's double-spend. Now the<br> +customer can promise the miner future business, but they've shown<br> +themselves to be dishonest... how much honor is there among thieves?<br> +<div class=3D"HOEnZb"><div class=3D"h5"><br> +--<br> +'peter'[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet= +ertodd.org</a><br> +00000000000000f31f5cd20f915e3edb8e3fceea49580235b984fea63f1f882c<br> +</div></div><br>-----------------------------------------------------------= +-------------------<br> +Try New Relic Now & We'll Send You this Cool Shirt<br> +New Relic is the only SaaS-based application performance monitoring service= +<br> +that delivers powerful full stack analytics. Optimize and monitor your<br> +browser, app, & servers with just a few lines of code. Try New Relic<br= +> +and get this awesome Nerd Life shirt! <a href=3D"http://p.sf.net/sfu/newrel= +ic_d2d_may" target=3D"_blank">http://p.sf.net/sfu/newrelic_d2d_may</a><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></blockquote></div><br></div> + +--047d7bdc10d891ff2a04dd3b3bf6-- + + |