path: root/87/d89ddb1da063867f6381add58ff820cfd1e728

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--