Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.178 as permitted sender)
	client-ip=209.85.220.178; envelope-from=jeremy.spilman@gmail.com;
	helo=mail-vc0-f178.google.com; 
MIME-Version: 1.0
Date: Fri, 19 Apr 2013 18:48:11 -0700
Message-ID: <CA+CODZEQX_xiaJE7WtFZC2qfVfDqZAgg-ydU5Q73O-QTkXJpPw@mail.gmail.com>
From: Jeremy Spilman <jeremy.spilman@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=047d7bfeb10a38f7d904dac10723
Subject: Re: [Bitcoin-development] Anti DoS for tx replacement
Precedence: list

--047d7bfeb10a38f7d904dac10723
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

 I=92m not sure I followed John=92s proposal fully, why would a user sign T=
X1
committing funds to the MULTISIG they may never get back? I also don=92t se=
e
the problem with getting a signed TX2 back from the AP before releasing
TX1... see the sequence below. But more importantly, we only need exactly
one replacement, so for starters we could anti-DoS by allowing only
nSequence of 0 or MAX.

 If this was enabled on test-net, I would be including a link to
transactions that implement the following proposal. At the moment, the best
I can do is unit test and generate the rawtransaction output at each step =
=96
you can find source code and test output here:
https://gist.github.com/jspilman/5424310

 The initial funding transaction and time-locked refund is pretty annoying
to setup, if you want to support the general case of coins from arbitrarily
sized inputs. You will have:
 - 1 or more inputs from the user, 0 or 1 change outputs
 - 0 or more inputs from the AP, 0 or 1 change outputs
 - 1 output to =912 PK1 PK2 2 CHECKMULTISIG=92

 This precludes using SIGHASH_SINGLE except for the special cases where
inputs are perfectly sized (i.e. they are created in a prior step).

 0. User and AP negotiate how much to escrow, who pays the fees, and how
far in the future nLockTime will be set (how long user=92s funds will be ti=
ed
if AP doesn=92t close the channel)

 1. User creates an unsigned TX1 with 1 or more inputs from user=92s
=91listunspent=92, change going back to user (if any), and a single output =
of
=91FundAmount=92 with scriptPubKey of =912 PK1 OP_0 CHECKMULTISIG=92, and s=
ends to
the AP

 2. AP adds to TX1; their inputs (if any), their change (if any), replaces
OP_0 in the scriptPubKey with a PK they control, and signs SIGHASH_ALL, and
returns TX1 to User.

 3. User verifies TX1 is as agreed, and signs it SIGHASH_ALL, but keeps it
to himself. User, having completed TX1, knows its TxID and can now create
TX2-Locked spending TX1 back to themselves. User sets nLockTime to the
agreed point, signs SIGHASH_ALL, and sends TX2-Locked to AP.

 4. AP verifies TX2-Locked and adds their signature, and returns TX2-Locked
to User. User can now broadcast TX1 and TX2-Locked.

 5. At each payment milestone, user creates TX2-Final; TX1 as input, final
nSequence, no lock time, with a single output going back to to the user,
and an amount equal to the remaining balance of the channel. User signs
with SIGHASH_SINGLE and sends to the AP.

 6. AP can add an output to TX2-Final sending their portion of the coins
where ever they want, sign it SIGHASH_ALL, and broadcast it at any point,
closing the channel. AP must broadcast TX2-Final before nLockTime, but has
no guarantee the user hasn=92t offered a bribe for miners by spending
TX2-Locked with a large fee, e.g. a pissed off user spends TX2-Locked
entirely to fees just to see if they can convince miners to wait for it.

 The alternative to the TX2-Locked is a 3rd party in the MULTISIG who is
trusted to close the channel at the request of either party, based on the
latest TX2-Final which was sent by the user. In this case there is no
TX2-Locked, only a single boardcast version of TX2-Final, and you do not
need transaction replacement at all.

 Thanks,
--Jeremy

--047d7bfeb10a38f7d904dac10723
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div style=3D"font-family:Calibri;color:rgb(0,0,0);font-si=
ze:12pt">
<div>I=92m not sure I followed John=92s proposal fully, why would a user si=
gn TX1=20
committing funds to the MULTISIG they may never get back?  I also don=92t s=
ee the=20
problem with getting a signed TX2 back from the AP before releasing TX1... =
see=20
the sequence below. But more importantly, we only need exactly one replacem=
ent,=20
so for starters we could anti-DoS by allowing only nSequence of 0 or MAX.</=
div><div><br></div>
<div> </div>
<div>If this was enabled on test-net, I would be including a link to=20
transactions that implement the following proposal.  At the moment, the bes=
t I=20
can do is unit test and generate the rawtransaction output at each step =96=
 you=20
can find source code and test output here: <font face=3D"Times New Roman"><=
a href=3D"https://gist.github.com/jspilman/5424310">https://gist.github.com=
/jspilman/5424310</a></font></div><div><br></div>
<div> </div>
<div>The initial funding transaction and time-locked refund is pretty annoy=
ing=20
to setup, if you want to support the general case of coins from arbitrarily=
=20
sized inputs.  You will have:</div>
<div>  - 1 or more inputs from the user, 0 or 1 change outputs</div>
<div>  - 0 or more inputs from the AP, 0 or 1 change outputs</div>
<div>  - 1 output to =912 PK1 PK2 2 CHECKMULTISIG=92</div><div><br></div>
<div> </div>
<div>This precludes using SIGHASH_SINGLE except for the special cases where=
=20
inputs are perfectly sized (i.e. they are created in a prior step).</div><d=
iv><br></div>
<div> </div>
<div>0. User and AP negotiate how much to escrow, who pays the fees, and ho=
w far=20
in the future nLockTime will be set (how long user=92s funds will be tied i=
f AP=20
doesn=92t close the channel)</div><div><br></div>
<div> </div>
<div>1. User creates an unsigned TX1 with 1 or more inputs from user=92s=20
=91listunspent=92, change going back to user (if any), and a single output =
of=20
=91FundAmount=92 with scriptPubKey of =912 PK1 OP_0 CHECKMULTISIG=92, and s=
ends to the=20
AP</div><div><br></div>
<div> </div>
<div>2. AP adds to TX1; their inputs (if any), their change (if any), repla=
ces=20
OP_0 in the scriptPubKey with a PK they control, and signs SIGHASH_ALL, and=
=20
returns TX1 to User.</div><div><br></div>
<div> </div>
<div>3. User verifies TX1 is as agreed, and signs it SIGHASH_ALL, but keeps=
 it=20
to himself.  User, having completed TX1, knows its TxID and can now create=
=20
TX2-Locked spending TX1 back to themselves.  User sets nLockTime to the agr=
eed=20
point, signs SIGHASH_ALL, and sends TX2-Locked to AP.</div><div><br></div>
<div> </div>
<div>4. AP verifies TX2-Locked and adds their signature, and returns TX2-Lo=
cked=20
to User. User can now broadcast TX1 and TX2-Locked.</div><div><br></div>
<div> </div>
<div>5. At each payment milestone, user creates TX2-Final; TX1 as input, fi=
nal=20
nSequence, no lock time, with a single output going back to to the user, an=
d an=20
amount equal to the remaining balance of the channel.  User signs with=20
SIGHASH_SINGLE and sends to the AP.</div><div><br></div>
<div> </div>
<div>6. AP can add an output to TX2-Final sending their portion of the coin=
s=20
where ever they want, sign it SIGHASH_ALL, and broadcast it at any point,=
=20
closing the channel.  AP must broadcast TX2-Final before nLockTime, but has=
 no=20
guarantee the user hasn=92t offered a bribe for miners by spending TX2-Lock=
ed with=20
a large fee, e.g. a pissed off user spends TX2-Locked entirely to fees just=
 to=20
see if they can convince miners to wait for it.</div><div><br></div>
<div> </div>
<div>The alternative to the TX2-Locked is a 3rd party in the MULTISIG who i=
s=20
trusted to close the channel at the request of either party, based on the l=
atest=20
TX2-Final which was sent by the user. In this case there is no TX2-Locked, =
only=20
a single boardcast version of TX2-Final, and you do not need transaction=20
replacement at all.</div><div><br></div>
<div> </div>
<div>Thanks,</div>
<div>--Jeremy</div></div></div>

--047d7bfeb10a38f7d904dac10723--