From: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers
Date: Thu, 28 May 2015 18:21:34 +0100 [thread overview]
Message-ID: <CAE-z3OX+eNfjyXw3MKOktLz4vDdep7qCG8dkJEUDRp5RyGq9MQ@mail.gmail.com> (raw)
In-Reply-To: <556740D6.5040004@sky-ip.org>
[-- Attachment #1: Type: text/plain, Size: 3215 bytes --]
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. 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 <Alice's public key 2>
OP_CHECKSIGVERIFY
OP_ELSE
OP_2 <Alice's public key 3> <Bob's public key 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.
[-- Attachment #2: Type: text/html, Size: 4948 bytes --]
next prev parent reply other threads:[~2015-05-28 17:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-27 1:50 Mark Friedenbach
2015-05-27 7:47 ` Peter Todd
2015-05-27 8:18 ` Gregory Maxwell
2015-05-27 10:00 ` Tier Nolan
2015-05-27 10:58 ` Peter Todd
2015-05-27 17:07 ` Jorge Timón
2015-05-27 8:04 ` Telephone Lemien
2015-05-27 10:11 ` Mike Hearn
2015-05-27 15:26 ` Mark Friedenbach
2015-05-27 17:39 ` Mike Hearn
2015-05-28 9:56 ` Mark Friedenbach
2015-05-28 10:23 ` Mike Hearn
2015-05-28 10:30 ` Tier Nolan
2015-05-28 12:04 ` Peter Todd
2015-05-28 13:35 ` Tier Nolan
2015-05-28 16:22 ` s7r
2015-05-28 17:21 ` Tier Nolan [this message]
2015-05-28 14:59 ` Mark Friedenbach
2015-05-28 15:18 ` Tier Nolan
2015-05-28 15:38 ` Mark Friedenbach
2015-05-28 15:57 ` Tier Nolan
2015-06-10 2:40 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAE-z3OX+eNfjyXw3MKOktLz4vDdep7qCG8dkJEUDRp5RyGq9MQ@mail.gmail.com \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox