Topic: Instant TX for established business relationships (need replacements/nLockTime) (Read 6081 times)

You would need 2 BRSs to make the relationship bidirectional.


So you think it could work. A ripple-like network could be establish between payment processors to enable instant payments (the merchant must trust its instant payer).

Now, probably a little off-topic...
If the bitcoin protocol (or a fork) allowed to issue IOUs from one address to another, payment of these IOUs to other addresses and destruction of the IOUs by sending them to the original issuer public key's (this would be a receipt). Could you use this technique to have instant ripple payments inside a chain?
I've have a proposal to implement ripple in a chain, but I'm not sure it could have instant ripple payments.
Can this technique be applied there with IOUs instead of cash?
I have to think more about it but anyone have some thoughts on it...

Ah, I didn't realize you were wanting to use BRSs one-way.

Note that the trust needed for this could be spread out using OP_CHECKMULTISIG.

No, the payers would have money in escrow to pay the payment processor and not the reverse. The payment processors would need an account in escrow for every other payment processor they want to use to pay through.
The merchant must trust their payment processor (green addresses?), the payment processor won't have an escrow for each of his merchants.
But, yes, the same coins can't be used for multiple BRSs.

I don't think this is feasible since payment processors would have to tie up bitcoins in so called BRSs with every single one of their clients, and because the same coins can't be used for multiple BRSs.

This could be used for decentralized instant POS payments too !!
These escrow accounts could be used to form a web of trust like ripple uses lines of credit.
Imagine A has an account to pay B and B to pay C.
A can pay C instantly through B. But you need to make the payment from A to B, and the one from B to C to occur atomically.
Can this be combined with the technique used to exchange currencies of a different chain to attain atomicity?
I still have to think how.

If so, the instant payment could have multiple hops. Payer -> Intermediary 1 -> ... -> Intermediary n -> Recipient.
This would increase the liquidity of a given payer and the number of payers a merchant can trust.
Maybe even payment processors can be avoided if there's a "trust path" between the payer and the recipient.

Really interesting idea! I was thinking that this might be a good technique to combine with a payment processor. Customers would then only have to form a single one of these "business relationship sessions" - namely with the payment processor - and could still pay instantaneously everywhere where the payment processor is accepted. Merchants would accept standard, zero-confirmation transactions from the payment processor on the assumption, that the payment processor is honest.

If the changes to Bitcoin necessary for this would be made, I would probably try to adopt something like this for Instawallet. Combined with the green address technique, that seems to me like a pretty workable solution for instant payments to any number of merchants without the customer having to risk depositing coins in an e-wallet.

Er, just to clarify, the original scheme, which bitcoin supports now modulo scripts and locktime, also has the property that the people can transact between themselves without touching the network, without needing any confirmations, and without paying any fees except to settle.  That much does not require variable-output TX.  But, an ECDSA sign/verify is required for each payment (offline between the two parties).

The purpose of Rivest-Shamir Paywords is to lower that cost to a single hash computation.  A single hash is reasonable for a payment on every internet packet; an ECDSA sign/verify is not.  This is why OpenSSL uses pubkey crypto for the initial handshake, but after that uses HMACs which are very fast.

I was referring to the problems solved by hashcoin's "Paywords" scheme. A sender and recipient touches the network once to set up a transfer and once to finalize it. Between those network transactions, they can do transactions between themselves safely, without touching the network at all. They don't have to worry about confirmations or transaction fees on microtransactions, and no ECDSA signing/verification is required.

I'm pretty sure it would work if Bitcoin supported variable values for outputs and loops in script. While variable output values are probably possible to do safely, it's probably too big of a change to ever be implemented in Bitcoin.

For future reference, could you please outline the other problems it would solve?

ByteCoin

Really great idea, following this thread!

julz,

Even though settlement is not occurring immediately on the block chain, there is never any counterparty risk in these exchanges, so I don't see why anyone should ever feel rushed into "settling the balance of a BRS" (it's always "settled" in the meaningful sense).

If the USD/BTC exchange rate drops then people would just find they've maxed out the BRS faster than they expected, but then they would simply start a new one with a higher limit.  Conversely, if it increases and people find they want to use the resulting excess of value locked up in the BRS for something else, then they can just settle it on the block chain and start up a new BRS with a lower limit.

If I understand this correctly, then for the duration of this 'Business Relationship Session' (I'll call it BRS for want of a better term), the merchant will be delivering micro-services because they know they will ultimately be paid - but are unable to access the money for these intermediate spends until settlement of this BRS.

This means that if the exchange rate is volatile - as it is today, the merchant won't know how much value in his relevant fiat currency each spend is worth. 
Presumably, especially if the exchange rate is tumbling, a merchant would want to settle the balance of the BRS very quickly, and immediately establish a new BRS.
Wouldn't this mean that the duration of these things is more likely to be minutes than even hours or days?

Also - if the merchant is a reseller or service aggregator of some sort, they may need to onpay the intermediate spends as they go. Would they need to hold a balance equivalent to all their active BRSs, or could they somehow spend parts of another unsettled BRS? 

These factors suggest to me that a very short settlement time would be the norm. Would all this setup/teardown cause delays, or would the parties be setting up a replacement BRS in advance of settling the previous so that it's seamless? 

Maybe as a merchant who wants to establish long-running BRSs with clients - I would have to establish a separate BRS with some financial provider who allows me to show evidence of BRSs in progress and lock in current exchange rates?

Sorry - these questions are perhaps a bit premature when you're discussing more low level mechanics.. but then understanding the higher level ramifications is surely part of getting the design right.

Couldn't you just add 10000 more words to the scripting language: OP_SHA256X1, OP_SHA256X2, ... , OP_SHA256X10000?

What problems are introduced by allowing this?  Is it that it would make it too easy to DoS the network?  Could a special exception be made for scripts of this type, since hashing 10000 times is only as difficult as checking a single ECDSA sig?

Holy shit.  If this is doable then it'd be insane not to do it, and somebody else surely will.

Tying direct economic incentives into packet routing would be revolutionary for the Internet.  Extreme micro-payments would provide the incentives necessary for wireless mesh networks to form spontaneously, as well as geographically close distributed storage (using this https://bitcointalksearch.org/topic/m.304888).  They'd incentivise participation in Bittorrent and Tor.  Easily Bitcoin's "killer app" if it's possible.

Allowing variable output values would be a pretty major change. It might be worth thinking about, though, since it would solve many problems.

Right, see where I said "you can't do this in bitcoin now".  There is a more important issue than no loops, namely that output value can't be set by scripts.


Er no you misunderstood the scheme then.  Take a look again at the OP.  Note that all those TX replacements occur *offline*.  There is only ONE TX ever actually settled in the blockchain.  So in addition to being instant, all of those TXs only end up paying one fee at the very end to settle!


Indeed, this is true.  But I think it would be much cheaper, since CPU time is cheaper than permanently adding to the blockchain.

You can't have for loops in script, so hashing 10000 times would require that you have 10000 opcodes.

There is a limit on the number of opcodes per script, so it wouldn't be extendable.


You have to pay a tx fee to spend coins.  If you have 1000 coins each with value of 0.00000001, then they can't be spent very easily.

You would have to send the transaction with 100 inputs and 1 output.  With the way things are set up, that would cost more than the value of the coins in tx fees.

However, miners might start charging on the basis of CPU time to verify, rather than the length of the transaction.  A verification that only requires hashing could have lower tx fees.

Also, if you don't care to much about double spending (and that seems reasonable for micro-payments), then hashing 10000 times is probably overkill.

You could just create 1 transaction which has 1 input and 1000 micro coins as outputs.  The requirement to spend the outputs would just be to provide a string that hashes to the given hash.

The seller can then combine lots of those coins into a large transaction and protect the output with the standard ECDSA signature system.

With extra TX script magic this can be done even more efficiently, so that sending a new payment merely requires a hash computation, rather than an ECDSA sig.  (This is a huge difference: a CPU can do about 5M Hash/sec [remember, single hash, not double like mining], but only maybe 500 ECDSA sigs/second).

The scheme is Rivest-Shamir Paywords[1].

The paywords scheme is basically a really efficient way of doing what I suggest above, with hashes instead of signatures.
Say I want to do this scheme with you for $100, and I want to transfer to you in increments of $0.01.

I pick a random message X_0 and hash it 10,000 times, generating X_10000. (i.e., hash X_0 to get X_1, then hash X_1 to get X_2, etc).
I send you the following signed promise:
"If you know a string that hashes to X_10000 after K iterations, you may collect $0.01 * K from me".

Now to pay you I send you X_9999, X_9998, etc.  You need only keep track of the last one, and you can check that X_k indeed hashes to X_k+1.

This doesn't fit quite as nicely into bitcoin unfortunately because it needs TX that can have variable output depending on the script.
You would need to be able to write a script saying something like:
"This tx is spendable with a signature from party B, plus a value Y.  If Y hashes K times to X_10000, then the output is K * something to output B, and rest to output A".

To get an idea of how powerful this is, with this kind of scheme you could include a payment on every packet going over the internet, or all kinds of extreme micro-payments.

[1] http://people.csail.mit.edu/rivest/RivestShamir-mpay.ps

Ah, I missed that the fully-signed intermediate versions would be kept private. This would be safe. Great idea!