Trustless, instant, off-the-chain Bitcoin payments

[Serith]

You should rely on Mike Hearn's proposal.  As far as I know it's the one that already partially implemented.

To me it looks identical to hashcoin's, what am I missing?

The difference is what they mean when saying  - "set sequence number to zero"

3) To start off, Tx B has seq 0 and gives all coins in TxA back to you.  When you need to give mtgox money, you send him a signed replacement of
TxB that is final, and sends some of TxA to him and the rest back to you.  These are all offline, not sent to network.

• Create, but do not sign, another transaction (T2) that has two outputs, one to the access point's key and another that goes back to you. The initial value is 0.001 BTC to the access point and the rest back to you. Use a sequence number of zero on the input and a lock time in the future (e.g., 1 day).

hashcoin and Mike Hearn argued about necessity of transaction replacement protocol.

Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.

As hashcoin says, tx replacement is indeed designed to be used along with multi-sig outputs. If you look at the contracts that use it on the wiki, you can see that it's most often used to prepare a default/fallback option that closes the contract if one of the parties goes away or stops agreeing to changes in the primary contract.

What I was asking/wondering is where you actually need replacement rather than just locktime.  I don't understand the utility of the TX replacement mechanism.  It seems to me to serve no purpose.

locktime is what is needed for the escrow, not replacements.  In general, if a transaction is going to be "updated" it must not be finalized or else nothing prevents a miner from including it.  Either it should be missing required signatures, or future-dated.  In any case, the first valid TX incorporated into a block gets to spend a given output.

Replacements are pointless because to a miner, a TX is either ready-to-include-in-a-block-right-now, or not.  If not he should just ignore it.  There's no reason to hold invalid TX around.  The party who broadcast the TX should just hold onto it themselves and broadcast it when the time is right.

This confusion comes up again and again and seems to be the reason many people object to enabling locktime, because replaceable TX are hard to reason about.  I agree, which is why I suggest Enable nlocktime only, NOT replaceable TX.  Locktime is easy for everyone to understand: it's just a post-dated check.

If I take a post-dated check to deposit at a bank, they should turn me away and tell me to come back in the future.  They should not hold onto it in their "memory pool" and agree to deposit on that date, provided it is not "updated".

[1714170753]

1714170753

[1714170753]

1714170753

[1714170753]

1714170753

[1714170753]

1714170753

[1714170753]

1714170753

[theymos]

Replacement isn't needed for this. The two parties can communicate their tx versions directly.

[Meni Rosenfeld]

Ok, now I'm confused. You don't need a replacement for every new version of transaction 2; but you do need a replacement for the first version. Alice won't sign transaction 1 before she is sure she can get the money back in the end; this happens after Bob signs the first version of transaction 2. But after that Bob needs the power to replace this first version with the version that pays him; for that he needs replacement.

[Serith]

Replacement isn't needed for this. The two parties can communicate their tx versions directly.

That was the major point of the thread: Rapidly adjusted micropayments and multisig/P2SH,

and that seems to be the resolution:

I see now why you argue replaceable TX are needed.  I'd argue this memory pool policy is a bug.

Well, you can certainly argue for alternative designs but Satoshi designed it to work this way, the software is working as designed, therefore it's not a bug.

[Mike Hearn]

The writeup on the wiki is identical to hashcoins initial proposal, I think, except with a motivating example (wifi hotspots) to illustrate why it's useful.

The reason for nLockTimed transactions to stay in the memory pool and be replaceable is to provide a kind of predictable "negotiating table" for the parties. This is a common point of confusion. Hashcoin eventually understood this and decided he still didn't like it but that's more because it got disabled at some point and we'll need to reactivate it. Preferably ASAP but we're all busy with other projects right now, it seems.

Replacement is required because otherwise as you increase the value sent via the channel, one party (the paying party) can always reclaim any value sent on it by broadcasting the first transaction to the network. It doesn't matter that the receiver has a signed, valid transaction giving them more value, the miners memory pool is already full with the earliest tx and the later versions of the transaction will be treated as double spends. With replacement, if the payer tries that, the receiver has a window of time (until nLockTime) to broadcast the later versions and override the senders broadcast. As long as you cleanly terminate the channel shortly before the end of the lock period, this protocol is safe for both parties.

[genjix]

This system has a flaw lol.

Merchant: fuck you, you are not getting your 8 BTC. Sign & Take 2 BTC or 0.

[Meni Rosenfeld]

This system has a flaw lol.

Merchant: fuck you, you are not getting your 8 BTC. Sign & Take 2 BTC or 0.

I'm not sure what you are talking about, but did you actually read how the system works? The receiver can't confiscate funds he wasn't specifically paid, he could die and the sender still receives the tied up funds at the end of the term. You might be confusing this with an escrow transaction, where this could be an issue.

[CodesInChaos]

This scheme clearly needs working replacement and time-locks. So unless replacement gets implemented in some form, it's unusable.

Personally I think the replacement counter as it is in the specification doesn't make much sense, since it doesn't coincide with miner interests. A natural system uses the value of the time-lock as primary version number, and the transaction fee(per byte) as tie breaker.

Btw with a better scripting language you could trust the processor even less. You'd need a signature verification operation that takes the message it should validate as an additional parameter, instead of implicitly using the current transaction. That way the processor can only redeem the money you sent him by producing a signature that unlocks a transaction from him to the receiver.

----

On important point you didn't mention is that the receiving end can terminate the channel at any time. So the bindup effect isn't as severe as some think. This also allows terminating the bidirectional channel when both sides cooperate.

----

One thing this system lacks is strong untraceability. I didn't find a way that offers anonymity while not entrusting the bank with any money, so untraceable  transactions still need to trust the bank a bit. But at least this scheme allows relatively low trust together with few on-chain transactions.

[Meni Rosenfeld]

On important point you didn't mention is that the receiving end can terminate the channel at any time. So the bindup effect isn't as severe as some think. This also allows terminating the bidirectional channel when both sides cooperate.

He can? Transaction A has LockTime, so even if transaction B sending the coins back is released, the sender can't use them.

One thing this system lacks is strong untraceability. I didn't find a way that offers anonymity while not entrusting the bank with any money, so untraceable  transactions still need to trust the bank a bit. But at least this scheme allows relatively low trust together with few on-chain transactions.

For untraceability you could use a different method (or combination) with a different set of tradeoffs, such as oblivious mixing transactions, Open Transactions, etc.

[CodesInChaos]

On important point you didn't mention is that the receiving end can terminate the channel at any time. So the bindup effect isn't as severe as some think. This also allows terminating the bidirectional channel when both sides cooperate.

He can? Transaction A has LockTime, so even if transaction B sending the coins back is released, the sender can't use them.

The step 3 transaction is not timelocked. The receiver can (and if he wants his money, even must) broadcast it before the timelock expires. At that point the receiver gets all spent coins(or less if he so chooses) and the sender gets back his unspent coins instantly.

The sender can't terminate the channel by himself, but he can ask the receiver to terminate the channel. There is no reason for the receiver not to comply.

One thing this system lacks is strong untraceability. I didn't find a way that offers anonymity while not entrusting the bank with any money, so untraceable  transactions still need to trust the bank a bit. But at least this scheme allows relatively low trust together with few on-chain transactions.

For untraceability you could use a different method (or combination) with a different set of tradeoffs, such as oblivious mixing transactions, Open Transactions, etc.

I'm just lamenting that you can't combine the trustless nature of this scheme with the untracability of chaumian cash. My planned project requires strong anonymity, so I need to trust the bank more than I'd like to.

[Meni Rosenfeld]

On important point you didn't mention is that the receiving end can terminate the channel at any time. So the bindup effect isn't as severe as some think. This also allows terminating the bidirectional channel when both sides cooperate.

He can? Transaction A has LockTime, so even if transaction B sending the coins back is released, the sender can't use them.

The step 3 transaction is not timelocked. The receiver can (and if he wants his money, even must) broadcast it before the timelock expires. At that point the receiver gets all spent coins(or less if he so chooses) and the sender gets back his unspent coins instantly.

The last transaction isn't timelocked, but its input is the output of the first transaction, which is timelocked, so it can't be executed before the timelock expires.

I'm just lamenting that you can't combine the trustless nature of this scheme with the untracability of chaumian cash. My planned project requires strong anonymity, so I need to trust the bank more than I'd like to.

Mixing transactions don't require you to trust anyone. Though that by default doesn't give you instant/scaleable transactions.

[Mike Hearn]

The last transaction isn't timelocked, but its input is the output of the first transaction, which is timelocked, so it can't be executed before the timelock expires.

A transaction that has not yet reached its nLockTime but which has finalized sequence numbers is finalized. See the code:

Code:

    bool IsFinal(int nBlockHeight=0, int64 nBlockTime=0) const
    {
        // Time based nLockTime implemented in 0.1.6
        if (nLockTime == 0)
            return true;
        if (nBlockHeight == 0)
            nBlockHeight = nBestHeight;
        if (nBlockTime == 0)
            nBlockTime = GetAdjustedTime();
        if ((int64)nLockTime < ((int64)nLockTime < LOCKTIME_THRESHOLD ? (int64)nBlockHeight : nBlockTime))
            return true;
        BOOST_FOREACH(const CTxIn& txin, vin)
            if (!txin.IsFinal())
                return false;
        return true;
    }

So if you have an open micropayment channel, if both sides sign a transaction with UINT_MAX sequence numbers and broadcast it, it will replace the timelocked transaction and the transaction will confirm immediately.

[CodesInChaos]

Not sure if you or me misunderstand hashcoin's scheme. But I independently designed a scheme which looks equivalent to me. Perhaps the description from my design docs is a bit clearer:

1. Create a multi sig address `Escrow` co-owned by `Alice` and `Bob`.
2. Create an unsigned transaction `T2` with amount `n` from `Alice` to `Escrow`.
3. Create a transaction `T3` with amount `n` that consumes the output of `T2` that transfers everything to `Alice`. This transaction is timelocked. Both `Alice` and `Bob` sign it.
4. Alice signes `T2` and executes it. (This step takes about an hour)
5. Now Alice can create transactions `T5` which consume `T2` and send an amount `m` to `Bob` and an amount `n - m` to `Alice`. She signs those transactions and sends sends them to Bob.

This means Alice can send a slowly increasing amount of money to bob, without incuring the overhead of a transaction each time.

Still these transactions can't be reversed, and Alice is guaranteed to get the remaining amount `n - m` back once the timeout transaction `T3` can be executed. If Bob waits for the timeout he won't get anything, so it's in his interest to executed the variant of `T5` most benefitial to him (i.e. the latest one).

While the amount can only ever increase, that's no problem in practice. One can simply execute the same scheme, with Alice and Bob reversed, and have Bob increase the amount he gives Alice, instead of decreasing the amount Alice gives Bob.

Transactions `T5`, and their input `T2` aren't time-locked. So Bob can claim his money at any time, giving the remainder to Alice at the same time.

[Meni Rosenfeld]

Not sure if you or me misunderstand hashcoin's scheme. But I independently designed a scheme which looks equivalent to me. Perhaps the description from my design docs is a bit clearer:

You're right, I misunderstood/misremembered the method.

[Serith]

I believe developers underestimate how transaction replacement feature is important, e.g. utilizing this proposal a business dealing with customers bitcoins wouldn't be required to hold private keys with a substantial balance and the Bitcoinica hacks (I stumbled on typing the word "hack" in plural) wouldn't have such devastating results.

Another thing about transaction replacement is that it would enable a lot of unique uses of Bitcoin e.g. mesh network where every node has monetary incentive to provide bandwidth, new business model for hostings and web sites where a user pays per kilobyte of downloaded content, ability to pay for extra bandwidth on ToR network which would explode the amount of nodes.

[Gavin Andresen]

I believe developers underestimate how transaction replacement feature is important, e.g. utilizing this proposal a business dealing with customers bitcoins wouldn't be required to hold private keys with a substantial balance and the Bitcoinica hacks (I stumbled on typing the word "hack" in plural) wouldn't have such devastating results.

Relevant recent IRC discussion: http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/07/11/6#l3981048

Bottom line: I think transaction replacement is important, but if we just enable it as-is then I think we open up the entire network to an easy DoS attack.

And I think the incentives for miners aren't right. I think the rule for what version of a transaction will be included in blocks has to be something like "the one that pays miners most OR the one that pays miners first (if there are several with the same fee)."

So I think a scheme where transaction fees are increased, or lock times are decreased, with every transaction replacement is the right way to go.

[Mike Hearn]

There are several discussions in parallel in that IRC log.

To summarize, Gavins concerns are

a) That being able to replace transactions could allow attackers to DoS the network by constantly replacing transactions (you still need to check the signatures each time).
b) That miners have an incentive to not perform the replacement if the new tx has lower or equal fees to the version currently in the memory pool.

My responses were

a) We should rethink/rework DoS protection as a prioritization problem. TX replacements should be prioritized lower than new transactions and compete for whatever CPU time is available. Replacements of transactions that were recently replaced get prioritized lower than others. The result would be that you could drive CPU usage on the network to 100% for a while but it wouldn't achieve the "denial" part of DoS, making such an attack worthless.

b) Miner incentives are already not entirely aligned with pure selfishness, as we see sometimes with miners who drop fee-paying transactions or don't include any at all. Despite that Bitcoin still works. If miners routinely broke the rules and rolled back transactions to claim higher fees, the feature would simply become worthless and nobody would rely on it anymore, wiping out entire classes of applications that depend on micropayment channels (and other constructs that need replacement to work).  That wouldn't kill Bitcoin but would reduce its utility a lot. So I don't think miners will routinely start to do this, even if there were easy patches available. It'd be a very short term strategy.

[blueadept]

And I think the incentives for miners aren't right. I think the rule for what version of a transaction will be included in blocks has to be something like "the one that pays miners most OR the one that pays miners first (if there are several with the same fee)."

So I think a scheme where transaction fees are increased, or lock times are decreased, with every transaction replacement is the right way to go.

Minor nitpick: I think it's better to mine the transaction with the earliest lock time over the transaction with the highest fee. That increases the probability the miner gets any fee at all.

Combining that with Mike's suggestion of prioritization, I think there's no need for any increase in fees at all for any transaction replacement that isn't actually trying to flood the network. As long as there's any fee at all, miners should mine the earliest expiring transaction. If the sender is unwilling/unable to make the lock time earlier, she would have to increase the fee.

[Mike Hearn]

Yes, that makes sense. But it's only necessary if there's a large conspiracy of miners who are trying to do this all at once.

If you're just worried about your counter-party trying to mine a rollback block, it's not really a concern because they'd have to get very lucky to mine the next block after the lock time expires. And for micropayments, well, who cares.

I'd probably start by just using a constant lock time for simplicities sake. If miners do all start modifying the code to allow rollbacks to higher-fee-paying transactions, the micropayment channel code can be updated to count-down nLockTime (I guess it'd be specified in terms of blocks to make this easy), which should change the incentives again, at a small cost of complexity and perhaps inconvenience/efficiency. But the fact that this adaptation exists means hopefully that conspiracy should never occur.

Good. I'm happy now

Looks like the work boils down to:

a) Writing unit tests
b) Doing work prioritization for tx verification