Topic: Trustless, instant, off-the-chain Bitcoin payments (Read 9729 times)

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

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.

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.

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.

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.

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

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:

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.

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


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.

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.

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

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.

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.

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

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

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.

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.

This system has a flaw lol.

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

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.

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

and that seems to be the resolution:

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.

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

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

No. If the lock time is extended after the channel is established, transactions after the lock time is extended can be easily reversed by the sender.