Instant TX for established business relationships (need replacements/nLockTime)

[jtimon]

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.

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.

[d'aniel]

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.

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.

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.

[jtimon]

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

You would need 2 BRSs to make the relationship bidirectional.

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

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

[d'aniel]

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

You would need 2 BRSs to make the relationship bidirectional.

I understood that.

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

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

I'm not sure.  But it'll be really cool if you can decentralize Ripple this way.  Don't forget to allow for smart property to be used as loan collateral https://bitcointalk.org/index.php?topic=41550.0

[jtimon]

I'm not sure.  But it'll be really cool if you can decentralize Ripple this way.  Don't forget to allow for smart property to be used as loan collateral https://bitcointalk.org/index.php?topic=41550.0

Thank you! Although ripple doesn't need collateral to function, this could allow bigger business trust each other. Well, this would allow more trust to get into the network in general. The idea seems interesting outside ripple too, I'm going to read it better.