summaryrefslogtreecommitdiff
path: root/87
diff options
context:
space:
mode:
authorDavid Vorick <david.vorick@gmail.com>2013-05-21 10:26:18 -0400
committerbitcoindev <bitcoindev@gnusha.org>2013-05-21 14:26:26 +0000
commit69eb40ed7df7c178968c2c3448e07cbf343ce7cb (patch)
tree764d41f0f0648b4a05ce612680c5884a1c134e74 /87
parentd74fb70e3da4dd4b959757f7a921809971ec93d5 (diff)
downloadpi-bitcoindev-69eb40ed7df7c178968c2c3448e07cbf343ce7cb.tar.gz
pi-bitcoindev-69eb40ed7df7c178968c2c3448e07cbf343ce7cb.zip
Re: [Bitcoin-development] Double Spend Notification
Diffstat (limited to '87')
-rw-r--r--87/d89ddb1da063867f6381add58ff820cfd1e728309
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&#39;ve been wondering why a blockchain is=
+ necessary at all.
+ Ripple doesn&#39;t have one (I haven&#39;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&#39;=
+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
+&#39;confirmed&#39; 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">&lt;<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@peter=
+todd.org</a>&gt;</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>
+&gt; One point that was only recently exposed to me is that replacement<br>
+&gt; combined with child-pays-for-parent creates a new kind of double spend=
+<br>
+&gt; _defense_: If someone double spends a payment to an online key of<br>
+&gt; yours, you can instantly produce a child transaction that pays 100% of=
+<br>
+&gt; the double spend to fees... so a double spender can hurt you but not<b=
+r>
+&gt; profit from it. =A0(and if your side of the transaction is<br>
+&gt; 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&#39;s trusting the merchant,<b=
+r>
+but you&#39;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&#39;t double-spend,<=
+br>
+the rest of the balance becomes available after n confirmations. A<br>
+BTC-&gt;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>&#39;s<br>
+shared-send service is another application, as is SatoshiDice. (the<br>
+failed bet tx can be the refund)<br>
+<br>
+What&#39;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&#39;s double-spend. Now the<br>
+customer can promise the miner future business, but they&#39;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>
+&#39;peter&#39;[:-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 &amp; We&#39;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, &amp; 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--
+
+