Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yy1V2-00039G-DS for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 17:21:44 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.192.53 as permitted sender) client-ip=209.85.192.53; envelope-from=tier.nolan@gmail.com; helo=mail-qg0-f53.google.com; Received: from mail-qg0-f53.google.com ([209.85.192.53]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yy1Uy-0006R0-Av for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 17:21:44 +0000 Received: by qgez61 with SMTP id z61so19523808qge.1 for ; Thu, 28 May 2015 10:21:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.132.17 with SMTP id 17mr4905189qhe.36.1432833694791; Thu, 28 May 2015 10:21:34 -0700 (PDT) Received: by 10.140.85.241 with HTTP; Thu, 28 May 2015 10:21:34 -0700 (PDT) In-Reply-To: <556740D6.5040004@sky-ip.org> References: <20150528120434.GA31349@savin.petertodd.org> <556740D6.5040004@sky-ip.org> Date: Thu, 28 May 2015 18:21:34 +0100 Message-ID: From: Tier Nolan Cc: Bitcoin Development Content-Type: multipart/alternative; boundary=001a11c07c72667d8205172797dd X-Spam-Score: 3.3 (+++) 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 (tier.nolan[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 2.7 MALFORMED_FREEMAIL Bad headers on message from free email service X-Headers-End: 1Yy1Uy-0006R0-Av Subject: Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers 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, 28 May 2015 17:21:44 -0000 --001a11c07c72667d8205172797dd Content-Type: text/plain; charset=UTF-8 On Thu, May 28, 2015 at 5:22 PM, s7r wrote: > In this scenario, if channel is closed, Alice is the only one who can > take the coins back after a relative locktime of 150 blocks. Bob is not > able to do this. > Yes, Alice is assumed to be the one who funded the channel. It is a single direction channel (Alice to Bob). > How is Bob protected in this scenario? Assuming the deposit is 1 BTC. When the channel is created, Alice can broadcast the refund transaction immediately and the get her money back 150 blocks later. The full scriptPubKey for the refund transaction would be OP_IF <150> OP_RELATIVE_CHECKLOCKTIME_VERIFY OP_DROP OP_CHECKSIGVERIFY OP_ELSE OP_2 OP_2 OP_CHECKMULTISIGVERIFY OP_ENDIF This means that Alice can spend the output after 150 blocks but with both signatures Bob and Alice can spend the output without the delay. She can send money to Bob by spending the non-locked output of the refund transaction (0.01BTC for Bob and 0.99BTC for Alice). Bob has a transaction that pays him 0.01BTC and pays Alice 0.99BTC from the refund transaction and is signed by Alice, but still requires his signature. Only Bob can make the transaction valid. It can be spent as soon as the refund transaction is broadcast. He has the refund transaction, so he can start the process whenever he wishes. Assume the channel runs for a while, and Alice sends 0.3BTC total. Bob has a transaction which pays him 0.3BTC and Alice 0.7BTC. He also has some that pay him less than 0.3, but there is no point in him using those ones. Alice decides she wants to close the channel, so asks bob to sign his final transaction and broadcast it and the refund transaction. If Bob refuses to do that, then Alice can just broadcast the refund transaction. If Bob still refuses to broadcast his final transaction, then Alice gets 1BTC and he gets nothing, after 150 blocks. This means he will send his final transaction before the 150 blocks have passed. This gets him 0.3 and Alice 0.7. Bob can close the channel immediately and Alice can force it to be closed within 150 blocks (~1 day). > If Alice sings a transaction > which spends the output of the refund transaction and gives it to Bob, > Bob can just add its signature and claim his slice of the output, > without necessarily shipping the goods or delivering the services to Alice. > Protection against that type of fraud isn't covered by channels. They are just to make sure money is handed over. > Can you be more explicit here? It doesn't make sense for me. > Does the explanation above help? With some risks. > As long as Bob is online and sees the refund transaction being broadcast by Alice, then there is no risk to him. Alice can close the transaction whenever she wants, so there is no holdup risk for her. > How do you apply a locktime path to a tx in the current network consensus? > I mean with OP_CHECKLOCKTIMEVERIFY. She could say that TXA pays to her in 6 months. If TXA ends up mutated after being broadcast, then she would have to wait the 6 months. It's better than nothing and maybe Bob would sign the mutated transaction. --001a11c07c72667d8205172797dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 28, 2015 at 5:22 PM, s7r <s7r@sky-ip.org> wrote= :
In this scenario, if channel is closed, Alice is the only one who can take the coins back after a relative locktime of 150 blocks. Bob is not
able to do this.

Yes, Alice is assumed = to be the one who funded the channel.=C2=A0 It is a single direction channe= l (Alice to Bob).
=C2=A0
How is Bob protected in this scenario?

Assuming the deposit is 1 BTC.

When the channel is cre= ated, Alice can broadcast the refund transaction immediately and the get he= r money back 150 blocks later.

The = full scriptPubKey for the refund transaction would be

OP_IF
=C2=A0=C2=A0=C2=A0 <150> OP_RELATIVE_CHECKLOCKTIME_VERIFY OP_DR= OP <Alice's public key 2> OP_CHECKSIGVERIFY
OP_ELSE=
=C2=A0=C2=A0=C2=A0 OP_2 <Alice's public key 3> <= ;Bob's public key 2> OP_2 OP_CHECKMULTISIGVERIFY
OP_EN= DIF

This means that Alice can spend the output after 150 blocks but = with=20 both signatures Bob and Alice can spend the output without the delay.
She can send money to Bob by spending the non-locked output of the refund= transaction (0.01BTC for Bob and 0.99BTC for Alice).

Bob has a transaction that pays him 0.01BTC and pays Alice 0.99BTC = from the refund transaction and is signed by Alice, but still requires his = signature.=C2=A0 Only Bob can make the transaction valid.

It can be = spent as soon as the refund transaction is broadcast.

He = has the refund transaction, so he can start the process whenever he wishes.=

Assume the channel runs for a while, and Alic= e sends 0.3BTC total.

Bob has a transaction which pays hi= m 0.3BTC and Alice 0.7BTC.=C2=A0 He also has some that pay him less than 0.= 3, but there is no point in him using those ones.

Alice d= ecides she wants to close the channel, so asks bob to sign his final transa= ction and broadcast it and the refund transaction.

If Bob= refuses to do that, then Alice can just broadcast the refund transaction.<= br>
If Bob still refuses to broadcast his final transaction, = then Alice gets 1BTC and he gets nothing, after 150 blocks.

This means he will send his final transaction before the 150 blocks have= passed.=C2=A0 This gets him 0.3 and Alice 0.7.

Bob can c= lose the channel immediately and Alice can force it to be closed within 150= blocks (~1 day).
=C2=A0
If Alice sings a transaction
which spends the output of the refund transaction and gives it to Bob,
Bob can just add its signature and claim his slice of the output,
without necessarily shipping the goods or delivering the services to Alice.=

Protection against that type of fraud = isn't covered by channels.=C2=A0 They are just to make sure money is ha= nded over.
=C2=A0
Can you be more explicit here? It doesn't make sense for me.
=

Does the explanation above help?

<= /div>
With some risks.

As long as Bob = is online and sees the refund transaction being broadcast by Alice, then th= ere is no risk to him.

Alice can close the transaction wh= enever she wants, so there is no holdup risk for her.
=C2=A0<= /div>
How do you apply a locktime path to a tx in the current network consensus?<= br>

I mean with OP_CHECKLOCKTIMEVERIFY.
=
She could say that TXA pays to her in 6 months.=C2=A0
If TXA ends up mutated after being broadcast, then she would h= ave to wait the 6 months.=C2=A0 It's better than nothing and maybe Bob = would sign the mutated transaction.
--001a11c07c72667d8205172797dd--