Topic: Rapidly adjusted micropayments and multisig/P2SH - page 2. (Read 5327 times)

Unless the provider decides to hold the deposit for ransom by refusing to sign and broadcast until the client pays 50% of the remaining balance...

In Mike's scenario, the client retains control of his money until he has proof that his deposit will be returned.

The output of the setup TX should require *both* parties signatures to spend.  The user can't broadcst anything himself.  Rather, every so often, the user makes a new TX spending that output, splitting it between himself and the provider.  These are not updates; they are separate TX that happen to all spend the same output in different ways.  The user signs them and then sends to the provider.  Again, the user can't broadcast them because they lack the providers sig.

Now the provider just maintains the user-signed TX giving him the most money(the most recentvone).  When he's ready, the provider takes the most favorable TX he's seen, adds his sign, and then broadcasts.

Bear in mind a replacement must have the same inputs. It's allowed to have different outputs. Perhaps Satoshi can explain better than I can. Here is a quote where he discusses nLockTime:



Miners have an incentive to keep a transaction that will become valid around so they can include it when it's valid and thus claim the fees.

Replacements are not pointless. You need to have the combination of timelocked transactions and replacement to ensure security in some cases. Look again at the example I gave above. For the wireless access example, if you don't do replacements, then you cannot sell access:

• User makes a transaction of 10 BTC to a 2-of-2 output with the access point. He sends the hash of this transaction to the AP, which then creates a tx that spends the given output back to the user and signs it.
• User gives tx 1 to the AP which broadcasts it, thus locking in the money.
• The AP and user co-operate to resign versions of the second transaction in which the balance between the APs output and the users output is the amount to pay. Because it's just a signature and there's no need to broadcast/wait, the value can be rapidly adjusted, like for every kilobyte of data transferred.
• To be secure this scheme must create the transactions timelocked and use sequence numbers so each adjustment to the value of the contract has a higher version number. Otherwise the user can broadcast the initial payment tx (the one when they hadn't bought much/any bandwidth) before the trade is finalized, thus taking back their money and leaving the AP out of pocket.

Is it clearer now? With replacements the AP doesn't have to worry about the latter scenario. If the user broadcasts the initial payment tx even after payments of greater value were signed, it just broadcasts the last transaction it saw which overrides the users broadcast. The time locking gives a window in which there is time for the network to be presented with newer versions of the same transaction.

And of course wills are pointless for similar reasons. You should just tell people what you want done with your stuff now you're dead.

ByteCoin

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".

I think nodes shouldn't have any requirement to actually hold a transaction in the memory pool, at least not for a long period of time. Miners will be incentivized to do so for any transaction with a fee: sorting the memory pool by fee or allowing them to be swapped to disk might make sense.

Scaling the memory pool isn't very important right now, but once timelocking becomes common it would become interesting. I don't see why having hundreds of thousands of transctions in the "memory" pool should be a bad thing if the software can handle it in a graceful manner, and there is some incentive to keep them.

For the contractual case, it's usually enough to just have the timelocked transaction around. You don't actually need to broadcast it, unless you see a competitor transaction be broadcast as well. If you notice that you would immediately broadcast the replacement. It's racy but would likely work well enough most of the time.

RE: tx replacement:

Somebody aught to start experimenting with transaction replacement with testnet-in-a-box.

Put together a test plan, modify the code and try to break it.

Assuming it all works, submit a pull request to enable transaction replacement on testnet (with a pointer to your test plan and results of testing, please).

Then we can start trying to break transaction replacement on testnet; again, assuming no bugs/hacks/issues turn up after "enough" testing, and if there's general consensus that the benefits outweigh the risks, it could be rolled out to the production network.

We just pulled a DoS fix involving filling up memory with orphan transactions; one concern with transaction replacement is DoS (could I fill up the memory pool by spamming "will be replaced" transactions?)

The way TX replacement was disabled only impacts the memory pool, it doesn't change the block validation rules. I don't think it'd be a big deal for miners to upgrade because the change is relatively small (just delete one line) compared to something much more involved like P2SH where backporting it is harder.

I agree that it'd take a while to roll out (as do any changes to the network rules), but Bitcoin is a long term project. A few months here or there isn't a big deal given that nobody has actually ever implemented any non-trivial contract anyway. Certainly for something as complicated as on-the-fly bandwidth trading you could add back nLockTime support and whilst you write the rest of the software ecosystem required, people will be upgrading. You can measure the utility by broadcasting simple locked transactions to yourself then attempting replacement. Measure how often the first vs second version gets into the chain.

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.

This isn't only about griefing. Without timelocking, the purchaser of the bandwidth can take back their coins before the provider has had a chance to broadcast the latest version of the transaction, thus they get free bandwidth. That seems like a fatal problem for automated negotiation.

If a party broadcasts it early, as far as I understand it, nLockTime makes it stay in the memory pool but not make it into a block until nLockTime is expired.  I assume blocks are checked to make sure that the transactions within them don't violate nLockTime (though with the allowance for clock skew in block timestamps, you wouldn't have a guarantee that this is accurate for any smaller an amount of time than the clock skew allowance).

The problem is that even if everyone respects nLockTime, you'd need nearly 100% of the hash power to allow transaction replacement before it's safe to do.  This would necessitate several months of pleading with mining pools; worse, when Bitcoin mining is hopefully more decentralized, it'll require getting hundreds of thousands or even millions of miners to upgrade their Bitcoin software.


To be clear, my scheme above doesn't require replacements at all.  Mike's scheme requires it.  Mike's scheme requires nLockTime to also be used to prevent the TX from making it into a block until the lock time expires.  The vendor, in the scheme, actually broadcasts the non-finalized transaction with an nLockTime in the future.  The deadline to finalize that transaction is nLockTime; only two versions (the original and the final) are broadcast to the network.

I believe the idea of using nLockTime and transaction replacement in his scheme is to prevent griefing where the griefer allows the customer to send coins to a multisig address, but then never signs any transaction that redeems those coins.  It'd be a free exploit if not for the way Mike had set it up.

Again, in my scheme, neither nLockTime nor transaction replacements are used and it's done exactly as you suggest: there's no finalized transaction until the very end.  The difference is that in my scheme, griefing is prevented by forcing the vendor to put up collateral equal to the amount put up by the customer.  Griefing is still possible but costly, forcing the griefer to lose more money than any individual customer would lose.


You make great point:  it's possible to include the earlier version not only due to the miners not updating their software to accept replacements, but because miners will have two equally valid versions of a transaction and may have an incentive to commit the earlier one.  That's why I said that enabling replacement could create a blockchain fork.  If you're to force the latest version of the transaction to be the only valid one, you have to reject any blocks that uses an earlier version.

Since transaction replacement isn't enabled right now, it would make sense to change the incentives slightly if it's ever re-enabled so that a newly version of a transaction must include higher fees or it'd be invalid.  This would incent miners to both upgrade and to wait until the last possible version of the transaction to commit it.  Then there would also need to be additional restrictions to prevent double-spending by replacing transactions.  All in all, I'm with you on not being sure that transaction replacement is a good idea or even safe to re-enable.

This is why TX replacement seems useless to me.  Either the current TX is already fully valid, in which case some party may broadcast it early.  Or it is not valid, and thus to miners/clients it might as well not exist.

Typically when one "updates" some TX, that update will be to the benefit of one party and detriment of another.  So it seems to me wherever one would use TX replacement, they actually need a 2-signature-required TX so that one of those parties can't go and immediately broadcast it.
 
What I meant is, are you sure you need tx replacement?  The reason I ask is I don't know of any good example that requires TX replacement, and TX replacement semantics are weird anyway for quoted reason.

I suspect I'm missing something or else Satoshi wouldn't have included tx replacement functionality at all.
What is TX replacement being used for?

edit Not articulating question well; to be more precise: why would the bitcoin network ever be interested in knowing/caring about if a TX is updateable/replaceable or not.  Even if it is, the old version is valid and hence must be accepted in a block by clients/miners.  E.g. if an updated TX reduced a fee, a miner could just decide to include the older TX in the block, ignore the update, and that must be perfectly OK.  So it seems to me replacements accomplish nothing.  What am I missing?

From the point of view of a miner/tx verifier, a TX is either valid right now (has signatures for all inputs, nLockTime has passed) or it's not.   If not, it should have absolutely no meaning to me.  If valid, I am free to put it in a block right now.

I think this is to give the vendor a deadline (nLockTime) to broadcast a finalized transaction before losing all the money.  In my scheme, if the vendor disappears, she loses the money that she put up as collateral for finalizing the transaction but the customer also loses her change.  The vendor can always redeem the transaction in the future, and that gives the customer back her change.  In Mike's scheme, only the vendor loses money and it's only the money owed.  The customer gains the money owed and gets her change back; the vendor never puts up collateral.  In my scheme, there's the potential for the permanent loss of money if the vendor loses her key.

Why are sequence numbers/replacements needed?  To do this kind of thing securely, redeeming the "micropayments" should require a secret only the person being payed knows, so that the payer may not broadcast it early.  Thus, there should never be a fully valid non-final transaction anyway (the person being payed won't sign any of the other half-signed TXs he got).

Is the only place relevant to transaction replacement in main.cpp, in CTransaction::AcceptToMemoryPool?  I'm not yet as familiar with the Bitcoin code as I'd like to be so I could be wrong about most of the following but if I'm right, there are probably additional changes to be made.

Assuming not all miners agree that this is a good thing and upgrade/patch their systems at the same time, this could be as difficult an implementation as P2SH.  The way I understand it, transaction replacement won't work if nLockTime expires before any miners include the updated transaction in a block and one of the big pools that runs a customized version of the software and hasn't yet implemented the new feature (like Deepbit with P2SH) puts the earliest version of your transaction in a block, thus stealing funds from the recipient.  If you modify Bitcoin to reject as invalid blocks that contain a transaction for which you have a newer version, you risk a fork; either way, I think this involves more effort and community coordination than just writing unit tests and working with Gavin.

This doesn't even take into account some of the other things that people may want enabled beyond just removing the disabling line (currently 496 in main.cpp).  It looks like both CTransaction::AcceptToMemoryPool and CTransaction::FetchInputs should be updated to allow adding new inputs.  In addition, when replacing the transaction, I don't see any code that updates/deletes transactions dependent on the old version of the transaction.

In any case, I'm less interested in Wi-Fi payments (not that I'm disinterested, I think the idea could even be extended to a Wi-Fi mesh network) than applicability to other P2P networks like an overlay payment network described above and networks that let you purchase ad-hoc computing resources such as relay bandwidth, processing time, storage, etc. from the other nodes on the network using micropayments.  At least some of these things are easier than modifying Bitcoin and getting miners to accept the changes.


With the hotspot owner (or other funds recipient) putting their own funds as performance collateral into the P2SH address, they'll have incentive to store the latest version of the transaction and sign/broadcast it eventually to get their own funds back.  Such griefing (intentional or not) is one of the reasons I put that in there.  The way it's structured means you don't have to worry about an unknown peer refusing to sign a multisignature transaction just to prevent you from getting your own change back.

I'm not saying enabling transaction replacement isn't worth it; this is just one scenario where it would be useful.  I'm saying I'm interested in exploring the full potential of P2SH, which we're about to finally have available to us.

Re-activating tx replacement isn't all that hard. It just takes somebody to write unit tests and convince Gavin it won't cause any problems. If you are capable of implementing contracts for wifi payments you are capable of doing that too.

The versioning is useful for the case where the wifi hotspot you were trading with vanishes.

the escrow mechanism in the OP looks pretty cool. And it's not from those contracts in 'smart money' examples.

it could be used to make a P2P market.

Right, I just wanted to make sure I'm getting it right in the way it'd be implemented because it might matter for the application ideas I have.

ETA: One reason I'm interested in whether this would work is that it would make possible a system similar to what I describe below.

TL;DR version: This would make possible a distributed Ripple-like network where nodes wouldn't have to trust each other because they could pay each other as they go with adjustable transactions.  Such a network would support only transactions denominated in BTC, which would reduce the need for complicated routing/distributed transaction commitment inside the network by eliminating inter-asset trade and allowing any node to trade with any other node without intermediaries.  It could reduce blockchain bloat, increase anonymity, and enable instant payments without having to trust proprietary "banks" or "eWallets" with your money, and due to the collateral requirements of such a network, it could actually increase the BTC-to-fiat exchange rate as it gets more use.

Long version:  Imagine a set of independent "payment processors" that forward payments from their customers to other payment processors' customers and vice versa.

To establish a "connection" (think of a pair of IPSec SAs, one for each direction of flow), two payment processors would decide on a "lifetime" L (or maximum transaction amount before settlement) for the connection.  Then they would establish two transactions as in the framework above, one for payments from processor A to processor B and the other for payments from processor B to processor A.  The collateral from each processor into each P2SH address would be L, so in reality 2L in each direction or 4L in total is locked into the pair of transactions that make up the connection.

A merchant would establish a unidirectional connection (only one transaction, from payment processor to merchant) with her preferred payment processor, and L is set to the expected maximum transaction volume before settlement.  The merchant puts up L BTC as collateral for the ongoing transaction and the payment processor puts up L as well, locking 2L into the unidirectional connection.  Likewise, a customer would establish a unidirectional connection with her preferred payment processor as well, and probably only the customer would put up the expected lifetime amount.

When a merchant requests a payment from a customer, the merchant gives the customer their receiving account information and their payment processor (almost like an e-mail address, merchant@paymentprocessor or something similar, probably identified by a public key), a transaction ID and the amount.  The customer sends a message to their payment processor including the information from the merchant and a signed updated transaction with a higher amount going to the payment processor and a lower amount going back to the customer.  The customer's payment processor then sends a similar message to the merchant's payment processor (assuming they already have a connection) and the merchant's payment processor to the merchant, which then gives the customer their merchandise.

Negotiation of the connections is an important part of the implementation; my first idea would be scaling up L from a multiple of the size of the first transaction to start with, to the maximum total transaction amount in an hour; implementations can also scale L differently in each direction (assuming some processors are more merchant-friendly and some are more consumer-friendly).  Fees can be charged on all sides (payment processors can charge merchants, customers and other payment processors) and while merchants and customers can shop around, it'd be more difficult for payment processors to auto-negotiate fees with each other and guarantee connectivity.  In this idea, I've tried to avoid the hassle of trying to design payment routing (and all-at-once commitment) through more than two payment processors by forcing direct connections between payment processors since unlike Ripple, all transactions would be denominated directly in BTC.

This type of infrastructure would function as almost an overlay network over Bitcoin that could make instant irreversible payments possible, though settlement would take a while longer (at the option of the funds recipient).  It would also reduce blockchain bloat and potentially improve anonymity of transactions with respect to information contained in the blockchain, as the only visible transactions from this network will be aggregated and thus correlating payments from customers to merchants will be impossible without the cooperation of the payment processors (and I'd expect at least some payment processors to pop up as Tor hidden services or eepsites and refuse to log, etc).

One more interesting effect is that merchants, customers and payment processors would all need to hold more BTC (and "lock it up" in ongoing transactions), meaning bitcoins would have value as collateral for such instant bitcoin transactions and this may increase the exchange rate of BTC vs. fiat.

There have been a couple other threads with more-or-less this idea. Micro-payments make pay-as-you-go seem much less intimidating. I hope it catches on and that Bitcoin fills that niche.

So I've been curious about uses for the two-party escrow mechanism enabled by multisignature transactions and P2SH.  I'm interested in replacing Contracts example 7 with something that doesn't require nLockTime or transaction versioning.

As I understand it, a two-party escrow mechanism would work as follows for minimized-trust transactions:

1. Alice wants to buy a widget worth X BTC from Bob
2. Alice creates two public keys, A1 and A2.  Bob creates two public keys, B1 and B2
3. Together, Alice and Bob create a 2-of-2 multisignature address C1 from A1 and B1
4. Alice signs a partial transaction T1 with an input of 2X BTC and an output of 3X BTC to C1 and passes it to Bob
5. Bob adds an input of X BTC to T1, signs it, and broadcasts T1 to the network
5a. The result is that Alice paid 2X BTC and Bob paid X BTC to the address, so they both have a stake in agreeing about how to release the money and griefing/fraud are prevented by both Alice and Bob by making those actions more expensive than playing honestly. In addition, both Alice and Bob are protected from fraud in the initial transaction as T1 is invalid unless both inputs are valid unspent outputs from previous transactions.
6. Bob sends Alice the widget
7. Upon receipt of the widget, Alice signs a transaction T2 from C1 paying 2X BTC to Bob at key B2 and X BTC back to herself at key A2 and passes T2 to Bob
8. Bob signs T2 and broadcasts it to the network, receiving his payment and "security deposit" and sending Alice's "security deposit" back to her

In the event that Alice and Bob can't agree on who should get how much money based on partial/complete nonperformance of the contract, they can both pick an arbitrator Trent, who generates three public keys, R1, R2 and R3.  A new 3-of-4 multisignature address is created for A1, B1, R1 and R2 so that Trent can only spend the money with agreement of either Alice or Bob, and this turns into a third-party escrow situation if the parties desire.  Eventually, some amount is sent to A2, some to B2 and some to R3.

Would this work in rapidly-adjusted microtransactions as well?  For example:

1. Alice wants to buy about 100MB of transfer from a Wi-Fi access point operated by Bob and pay .0001 BTC per 10kB
2. Alice and Bob create a transaction T1 to C1 as in previous steps 1-5, with Alice paying in 2 BTC and Bob paying in 1 BTC
3. Alice signs a transaction T2 from C1 with 1.0001 BTC going to Bob at key B2 and 1.9999 BTC going back to herself at key A2, sending T2 to Bob who does not broadcast it
4. Alice continues to use 10kB of bandwidth at a time, signing a new version of T2 each time with an ever-increasing amount going to Bob and ever-decreasing amount going back to her
5. Alice notifies Bob when she is done, at which point Bob stops providing services to Alice and signs and broadcasts T2, thereby completing the exchange

This would enable such rapidly-adjusted microtransactions without relying on transaction versions or nLockTime, which means they're practical as soon as P2SH is available on the network.

I would like to know whether this would actually work as I described it, as I have some other ideas relying on transactions like this.

Edit: Changed Trent's keys from T1, T2, T3 to R1, R2, R3 so they aren't confused with transactions T1 and T2.