Topic: Rapidly adjusted micropayments and multisig/P2SH (Read 5327 times)

OP_CODESEPARATOR is a holdover from a previous buggy design, it was an implementation detail of how scripts were run (not intended to be actually placed in a tx).

It isn't usable for the same reason - inserting a signature to a transaction changes its hash and thus invalidates any other transactions that depended on it.


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.


Bitcoin isn't completely resistant to miners that don't care about the wider ecosystem. For instance nothing stops you claiming the inflation even if you don't ever include any transactions. Not validating transactions is certainly cheaper than doing so, but we see that miners generally do it anyway.

If you wanted to allow time locked transactions to not be kept in the memory pool, you would have to explain why your design is better than Satoshis. I'm not seeing it - the only rationale presented for no-replacement based protocols is that re-activating tx replacement would take some work, but it's not any more work than changing the rules around nLockTime.

If this is the case, then my dominant assurance contract scheme also needs TX replacement to work.  Without it, the contributors can just broadcast the timelocked transaction and have the vendor's collateral for free when nLockTime expires regardless of whether the vendor can get enough contributions to make the contract succeed.

This should be doable with proper OPCODESEPARATOR.


I see now why you argue replaceable TX are needed.  I'd argue this memory pool policy is a bug.  Fortunately, its in miners incentives to fix it (get fees others wouldn't), and as mentioned above, only a small fraction need make this change.  Miners should greedily pack whatever they can into blocks, not wait on other TX.

I can wave it away, because as I said, only a small fraction need make this change.  That memory pool policy makes no sense: those same miners who are rejecting TXB'  absolutely MUST accept a block that contains a TX conflicting with it.  So such a policy puts oneself at a disadvantage.

Signing TXA changes its hash, which invalidates the connection on TXBs input. So you can't do that.

What you can do is sign TX A and then send only the hash to the provider.


The bandwidth purchaser can continue signing and adjusting TXB' until they decide they are done, and then broadcast the first TX B, the one that spends everything back to themselves with a lock time. It enters the memory pool and won't commit for some time, but because there are no replacements, that doesn't matter. The buyer has taken back their coins.

For this protocol to work, the access point must be able to override the users broadcast transaction.


The semantics of nLockTime are that transactions that have it set are kept in the memory pool until that time is reached. Double spends against that transaction are dropped. That's the point of the feature - Satoshi designed timelocked transactions to be replaceable.

You can't just handwave this away and say well, the software should be changed, because if you're going to change all the nodes behavior you might as well just re-activate tx replacement and be done with it.

TXB is invalid until the date, so miners should just ignore it.

If memory pool is buggy and miners are keeping TXB, then some subset of miners must run a fixed version.  Nomatter what, TXB can't get into a block, and even miners holding TXB must drop it if they see a block with TXB' mined by someone else.

So worst case, timelock period must be longer and provider must broadcast TXB' early enough that a patched miner will find a block before TXB goes live.   E.g.  if only 5% of miners are patched, and provider broadcasts 20 blocks before deadline, he has a roughly even (actually 1/e) chance of losing.   For strong security, he should aim for a e^-k probability of loss for k=80 or so.  He can do that by leading by k times as long.

(Obviously since block times are stochastic, the analysis is a bit more but you get the idea)

Is there specific documentation about how nLockTime is handled?  Because if the customer does broadcast (and possibly continues to broadcast) TXB before the provider broadcasts TXB', there is a chance of TXB' never making it to miners' memory pools.

Basically, I'm saying that I'm not sure how (or even if!) nLockTime is currently implemented and that would affect the security of both this scheme and my dominant assurance contract scheme.

Customer and vendor decide they hate each other's guts and go to arbitrator to solve it.  The arbitrator comes up with a solution they can both live with.

If the funds are behind a 2-of-3 lock, the customer and vendor can then sign a version of the transaction that gives the arbitrator no fees but splits the transaction the way the arbitrator has decided.

If the funds are behind a 3-of-4 lock with the arbitrator having 2 keys and the customer and vendor each having 1 key, the arbitrator must consent to having that money sent anywhere and must have the agreement of at least one party in the dispute.  I'd say this is exploitable by the arbitrator to maximize fees by colluding with either customer or vendor to get them to bid up fees against each other but this is easily fixable by ensuring the arbitrator has a standard fee schedule.  Since all such transactions are public due to being in the blockchain, the arbitrator can show its history of sticking to the fee schedule to demonstrate that it does not accept bribes.

The provider never needs to wait.  TXB is timelocked, but no TXB' are.

The user must wait until either the deadline or the provider to close out early.

In my scheme TXB should never be broadcast, unless no payments were made.  The provider must broadcast TXB' long before TXB is valid to be safe.  In that case TXB will be rejected like any other doublespend.

I don't get it... can you elaborate? give me use case

True.  Also, instead of doing it that way (where you always have to do 2-of-3), you can make it 2-of-2, and both parties pre-sign but don't broadcast a transaction to a 2-of-3 address including an arbitrator.  That way, in case of catastrophe or otherwise, either party has the option to take it to an arbitrator at any time without having to involve the arbitrator from the start.  The extra transaction fees are then only paid when there's an actual conflict and will be smaller than the fees for arbitration, and the blockchain may be less bloated assuming arbitration isn't used so often that the extra transactions take more space than having every such transaction add a 3rd key.

Also, when 2-party escrow disputes go to arbitration, 3-of-4 addresses may be useful to prevent the parties from accepting the arbitrator's decision but signing off on it themselves and cutting the arbitrator out of her fees.  I don't think that's possible with P2SH since AFAICT, its max is n-of-3.


I thought nLockTime is already enabled, but transaction replacement is not?

But if you are putting nLockTime back into the system, why not sequence numbers too?  And why should the provider have to wait out the lock on TxA to collect his earnings?  Wouldn't the lock make more sense on the transaction that can be replaced than on the transaction that is fixed?

Currently, how would the network handle a transaction like TXB where nLockTime isn't for some time in the future? If you perform a few "instant" transactions by signing later versions of TXB and then broadcast the original version to the network, is the provider guaranteed that broadcasting her non-timelocked version will replace the timelocked version?

Also, I like your modification of my OP scheme that prevents the user from locking up the provider's coins.  I'm probably less worried about a provider locking up coins (losing reputation and money with each such event is bound to add up for providers) than about hordes of users locking up the coins of a merchant they don't like.

Seems as a very nice idea if we are talking about joint participation in collateral. txB can be 2-of-3 with 3rd party involved in case of dispute resolution ( provider\client was hit by bus)

Also to address the OP scheme: my scheme doesn't need replacement either.  What your scheme is trading is, having both parties put up collateral in exchange for not requiring nlocktime.  It's an interesting idea, both ways seem to have some advantages and disadvantages.  I was aiming to minimize collateral but this alternate scheme might have some merits.

The scheme is exactly the same after initial setup, it's just TXA is slightly different.  It would go like this:

1.  I write a transaction TXA with two inputs and one output.  The output is two-party multisig with my key and providers key.  But rather than just my coins, TXA now has an input from the provider too.  So X coins from me, Y coins from the provider.
2. I write TXB spending TXA splitting the coins back up, X to me and Y to you.
3. I sign my halves of TXA and TXB and send them to provider.
4. Provider, seeing TXB gives him a way to get his coins back nomatter what, signs TXA and gives it back to me.  He keeps the half-signed TXB safe.

Now to pay, I make new transactions TXB' spending TXA as before, except adjusting the split from X me Y you to X-1 me, Y+1 you etc.

Now to settle, provider broadcasts something spending TXA.  Presumably, he will broadcast the one giving his output the most.

Since provider saw TXB before signing TXA, user can never lockup providers coins.

The provider, however, can lock up both parties coins.  I.e., the provider may  lock up X coins of the user forever if he's willing to lockup Y of his own coins forever.

The initial TX is designed to handle that; I was discussing what happens after.  The full scheme I originally described here:

https://bitcointalksearch.org/topic/instant-tx-for-established-business-relationships-need-replacementsnlocktime-25786

Note that thread says it uses replacements.  That's a mistake, as I myself was confused about the need for replacements, but later in the thread I mentioned they aren't needed.  The contracts wiki example looks to be copied from my thread, and it looks like they copied my confusion about replacements along with it.

The full protocol, no replacements, no DOS:

1. Write a transaction TXA spending some coins I have to a two-party owner: my key and provider's key.  Don't sign TXA.
2. Write a transaction TXB spending TXA entirely back to myself but with a locktime in the future.  Sign it.
3. Present unsigned TXA and half-signed TXB to provider, requesting they add their signature to TXB.
4. After provider has added signature to TXB, it is now safe to sign TXA.  Sign,Broadcast TXA and hold TXB in a safe place.

Now if I want to give the provider money, I make a new transaction TXB' spending TXA splitting output between myself and the provider, and proceed as I described above.

The point, which makes this protocol easy to reason about, is there are only ever two valid transactions possibly spending TXA.  The very first one, which won't be valid until sometime in the future.  And the very last one, which the provider will sign and broadcast.  Any intermediate TXB' are missing the providers signature and therefore invalid.

There's no known way to do this and it's likely impossible.  That is, simultaneously having instant TX payable to anyone and preventing double-spending.  The intuition/thinking for my scheme is that you can make a tradeoff;  if Alice is willing to temporarily mark some of her coins as "this coin may only be spent to Bob for the next 5 days", then Bob may safely accept such coins with zero confirmations, without even broadcasting it to the network, because he can be sure there isn't some other TX spending the same coins to someone else.  But this is only possible if Alice really can't spend the coins to someone else, i.e., they are "locked up" for a bit as collateral.

The one that doesn't require collateral isn't possible without transaction replacement and I don't have the ability at this point to champion transaction replacement to make it possible.  I mainly started the thread to see if my idea was viable, not to see if it was better than Mike's.  If it is viable, then application developers have a way of doing it without the Bitcoin software having to be modified beyond the current short-term plans.  I do see transaction replacement as being difficult to enable for reasons I stated above, but my C++ is rusty-ish and I'm not very familiar with the code so I could've missed things that answer my concerns with it.

Why not just stick with the solution that doesn't require anyone to put up collateral?

I agree that transaction replacement is useful to prevent coins from getting lost/nuked.  This is why my version of the scheme requires the vendor/provider/AP/etc. to also put up collateral.  It's motivation for both sides to eventually get a transaction signed.  If the two parties don't agree, they both lose money and all our coins end up more valuable.  AP operators would quickly notice if their bandwidth sales software started losing money rather than making it.

Yes, or (not just ransom) due to bugs/incompetence simply goes away.

I think it's important that your phone can just automatically set this up without any intervention on your part, like how a phone roams onto a new cell tower automatically. Otherwise it's not really more convenient than regular wifi. It means there can't be any scope for malicious or messed up providers nuking your money.

Eg, imagine somebody taking an access point that offers a very cheap rate to a bitcoin conference. Lots of peoples phones might try to buy access from it automatically, and after having the multi-sig output be broadcast that AP simply connects you to a page that says "if you want any of your money back, here is a tx you can sign". Such an access point could be hidden in somebodies pocket or bag, you would never find it or know who did it.