Protocol /
BlockChainCommitMethod
Protocol.BlockChainCommitMethod History
Hide minor edits - Show changes to output
October 08, 2012, at 09:02 PM
by - moving stuff out
Changed lines 40-106 from:
!! Atomic exchanges of chain coins and Ripple IOUs
Bitcoins (or other proof of work chain currencies) can be traded atomically for ripple IOUs in a trust-less and p2p way. There are more ways to implement this use case. First we explain how to do it using this protocol and this commit method. Other approaches are discussed in the following sections.
1) The Ripple payer sets the "dest_address" and minimum "amount" for the blockchain commit.
2) When the rest of the ripple transaction is completed, the ripple recipient should send the agreed amount of coins to the specified address.
3) If this occurs before the block "deadline" the Ripple transaction is valid, otherwise it did't happened, it is rolled back.
Ripple nodes could be companies accepting deposits and withdrawals of the currency represented by its IOUs (which can, in fact represent many other assets), for example, USD. With this you would have a p2p bitcoin exchange, but you will always have to trust an issuer. The credit could be certified through legal contracts so that users could hold their crypto-IOUs as legal proofs.
Since btc would not need to be deposited anymore, current exchanges could offer a more secure service. With ripple, all the separate markets could be one, even if actors trust different issuers.
Consider this ripple trade, for example:
[@
A(10 mtgoxUSD) -> B(10 intrsngUSD) -> C(7 intrsngEUR) -> D(1 btc) -> A
@]
Or with people which share a trust path that doesn't involve any company, just:
[@
A(10 usd) -> B(10 usd) -> C(7 eur) -> D(1 btc) -> A
@]
!!! Ripplecoin
The [[https://en.bitcoin.it/wiki/Ripple_currency_exchange | bitcoin wiki]] describes a way to do this same thing using a blockchain implementation of ripple, very similar to [[https://bitcointalk.org/index.php?topic=3557.0 | RippleCoin]]. It has the advantage over the ripple distributed protocol described here that nodes don't need to be always connected and average users don't need to delegate in a server that's always connected like they usually do for e-mail, for example.
On the other hand, RippleCoin can't be instant as this protocol using the registry commit method and the financial infromation is published in the chain, something that never happens to this protocol (not even with this commit method). It can be obfuscated like in Bitcoin, but it is harder in RippleCoin due to the lines of credit that would need to be recycled often.
This approach of implementing Ripple inside a blockchain uses the [[https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains | trade across chains]] contracts use case to make the trust-less trade for bitcoins. The chain currency that hosts ripplecoin (a cash chain currency is still needed to pay for the chain with fees) can be traded atomically for ripple credit inside the same chain without the need of such a contract, the default SIGHASH_ALL described in the bitcoin contracts page is enough.
The public accounting may be actually an advantage too for some use cases, like a [[https://en.bitcoin.it/wiki/Smart_Property |smart propery]] car.
!!! Colored coins
Something similar to Ripplecoin can be implemented in the existing bitcoin chain without changing the protocol. You need to use a concept often reffered to as "colored coins". You use small bitcoin units (for example, a Satoshi) to represent the credit IOUs (or any other crypto-asset). The participants in the "ripple coloring protocol" trace the satoshis back to their source and each address is an issuer or a color.
This is an example of a ripple transaction using colored coins:
[@
A -> B -> C
Inputs: [10 srcA, 10 srcB, 0 srcC]
Outputs: [10 destB, 10 destC]
@]
srcA, srcB, srcC are bitcoin public keys. destB and destC are bitcoin public adresses.
A Ripple trade for bitcoins within a single transaction with each satoshis representing 1 USD could look like this:
[@
A(10 usd) -> B(10 usd) -> C(1 btc) -> A
Inputs: [10 srcA, 10 srcB, 10^8 uncolored]
Outputs: [10 destB, 10 destC, 10^8 destA]
@]
The disadvantage of colored coins compared to ripplecoin is that the underlying satoshis represent an artificial limitation to the divisibility of the crypto-assets issued. Although some argue that this can be useful to prevent spam. The obvious advantage is that there's no need to modify the bitcoin protocol.
With ripplecoin you would use bigger numbers instead of satoshis, so you could use fractions as you do with bitcoin (1 satoshi can also represent a fraction, 1 cent, for example). But the chain would enforce the coloring rules as well as keep real bitcoins separate from the credit. With the current approach, when the credit doesn't follow the coloring rules, the coins get "decolored".
You can find a project that's being developed to implement colored coins here:
https://github.com/jgarzik/pybond
For more information on colored coins, you can start with this [[https://bitcointalk.org/index.php?topic=92421.0 | thread]].
to:
This commit method can be used to perform [[atomic trades of ripple IOUs for chain coins]] like bitcoin.
Changed line 38 from:
If a Blockchain transaction occurs that matches the source public key and destination address before the deadline, then the Ripple transaction is committed. Otherwise, it is rolled back. The recipient uses the first input public key (that matches src_address) of the blockchain tx to prove that he's the only one who is able to initiate the commit.
to:
If a Blockchain transaction occurs that matches the source public key before the deadline, then the Ripple transaction is committed. Otherwise, it is rolled back. The recipient uses the first input public key (that matches src_address) of the blockchain tx to prove that he's the only one who is able to initiate the commit.
September 26, 2012, at 06:17 PM
by - ano more link
Added lines 105-106:
For more information on colored coins, you can start with this [[https://bitcointalk.org/index.php?topic=92421.0 | thread]].
September 25, 2012, at 08:19 PM
by - intrsng
Changed line 57 from:
A(10 mtgoxUSD) -> B(10 intersngUSD) -> C(7 intersngEUR) -> D(1 btc) -> A
to:
A(10 mtgoxUSD) -> B(10 intrsngUSD) -> C(7 intrsngEUR) -> D(1 btc) -> A
September 25, 2012, at 08:17 PM
by - correcting and extending "Atomic exchanges of chain coins and Ripple IOUs"
Changed lines 51-64 from:
to:
Ripple nodes could be companies accepting deposits and withdrawals of the currency represented by its IOUs (which can, in fact represent many other assets), for example, USD. With this you would have a p2p bitcoin exchange, but you will always have to trust an issuer. The credit could be certified through legal contracts so that users could hold their crypto-IOUs as legal proofs.
Since btc would not need to be deposited anymore, current exchanges could offer a more secure service. With ripple, all the separate markets could be one, even if actors trust different issuers.
Consider this ripple trade, for example:
[@
A(10 mtgoxUSD) -> B(10 intersngUSD) -> C(7 intersngEUR) -> D(1 btc) -> A
@]
Or with people which share a trust path that doesn't involve any company, just:
[@
A(10 usd) -> B(10 usd) -> C(7 eur) -> D(1 btc) -> A
@]
Since btc would not need to be deposited anymore, current exchanges could offer a more secure service. With ripple, all the separate markets could be one, even if actors trust different issuers.
Consider this ripple trade, for example:
[@
A(10 mtgoxUSD) -> B(10 intersngUSD) -> C(7 intersngEUR) -> D(1 btc) -> A
@]
Or with people which share a trust path that doesn't involve any company, just:
[@
A(10 usd) -> B(10 usd) -> C(7 eur) -> D(1 btc) -> A
@]
September 25, 2012, at 07:42 PM
by - code
Added line 68:
[@
Changed lines 73-74 from:
to:
@]
Added line 79:
[@
Added line 84:
@]
September 25, 2012, at 07:41 PM
by - missing link
Changed lines 85-87 from:
You can find a project towards implementing colored coins here:
to:
You can find a project that's being developed to implement colored coins here:
https://github.com/jgarzik/pybond
https://github.com/jgarzik/pybond
September 25, 2012, at 07:39 PM
by - chosing input instead of secret, ripplecoin separated from trades, introducing colored coins
Changed lines 5-6 from:
The Bitcoin (or other) block chain is a system for achieving distributed irrevocable consensus on transactions. It can be used as a Ripple commit method by embedding a commit token in the block chain before a deadline. Under this method, Ripple transactions are fully atomic.
to:
The [[http://bitcoin.org/ | Bitcoin]] (or other) block chain is a system for achieving distributed irrevocable consensus on transactions. It can be used as a Ripple commit method by embedding a commit token in the block chain before a deadline. Under this method, Ripple transactions are fully atomic.
Deleted line 10:
Deleted line 22:
Deleted lines 30-31:
"dest_address": "(Bitcoin address)",
Changed lines 32-33 from:
"amount": (optional),
"commit_token": "(commit token)"
"commit_token": "(commit token)"
to:
"src_pk": "(Blockchain public key)",
Deleted lines 35-36:
Changed lines 38-47 from:
If a Bitcoin transaction occurs that matches the source and destination address, and contains the commit token then the Ripple transaction is committed. Otherwise, it is rolled back. The [[https://en.bitcoin.it/wiki/Script | bitcoin script]] cointaining the the commit token would look like this:
[@
scriptPubKey: <commit token hash> OP_DROP <pubKey> OP_CHECKSIG
@]
The amount of the transactionis not important, it can be a satoshi. But probably the payer wants to add a fee to increase the changes that it gets into the chain before the deadline so that the Ripple transaction doesn't get rolled back. Note that the bitcoin transaction (with the fee) will get into the chain whether the Ripple transaction is committed or rolled back.
TODO avoid losing the fee if it's going to be rolled back and the tx has already been broadcasted somehow with sequence number?
[@
scriptPubKey: <commit token hash> OP_DROP <pubKey> OP_CHECKSIG
@]
The amount of the transaction
TODO avoid losing the fee if it's going to be rolled back and the tx has already been broadcasted somehow with sequence number?
to:
If a Blockchain transaction occurs that matches the source public key and destination address before the deadline, then the Ripple transaction is committed. Otherwise, it is rolled back. The recipient uses the first input public key (that matches src_address) of the blockchain tx to prove that he's the only one who is able to initiate the commit.
Changed lines 43-49 from:
That approach uses the [[https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains | trade across chains]] contracts use case to make the trust-less trade.
There's no need to have EURcoins. Given that the minter of such an instrument is a centralized entity, holders must already trust it for the deposit. It can just issue Ripple IOUs (on RippleCoin or on regular Ripple) representing EUR desposits (as they can represent anything else: shares, bonds...). What the users need is be able to prove that the issuers owes them a given amount of the asset, which can be described (and the IOUs legally certified) outside of the ripple protocol.
Here we discuss the way to do the same thing with the regular Ripple protocol using the blockchain commit method. It's really simple. The Ripple payer sets the "dest_address" and minimum "amount" for the blockchain commit. When the rest of the ripple transaction is completed, the ripple recipient should send the agreed amount of coins to the specified address. If this occurs before the block "deadline" the Ripple transaction is valid, otherwise it did't happened, it is rolled back.
to:
Bitcoins (or other proof of work chain currencies) can be traded atomically for ripple IOUs in a trust-less and p2p way. There are more ways to implement this use case. First we explain how to do it using this protocol and this commit method. Other approaches are discussed in the following sections.
1) The Ripple payer sets the "dest_address" and minimum "amount" for the blockchain commit.
2) When the rest of the ripple transaction is completed, the ripple recipient should send the agreed amount of coins to the specified address.
3) If this occurs before the block "deadline" the Ripple transaction is valid, otherwise it did't happened, it is rolled back.
Given that the minter of such an instrument is a centralized entity, holders must already trust it for the deposit. It can just issue Ripple IOUs representing EUR desposits (as they can represent anything else: shares, bonds...). What the users need is be able to prove that the issuers owes them a given amount of the asset, which can be described (and the IOUs legally certified) outside of the ripple protocol.
!!! Ripplecoin
The [[https://en.bitcoin.it/wiki/Ripple_currency_exchange | bitcoin wiki]] describes a way to do this same thing using a blockchain implementation of ripple, very similar to [[https://bitcointalk.org/index.php?topic=3557.0 | RippleCoin]]. It has the advantage over the ripple distributed protocol described here that nodes don't need to be always connected and average users don't need to delegate in a server that's always connected like they usually do for e-mail, for example.
On the other hand, RippleCoin can't be instant as this protocol using the registry commit method and the financial infromation is published in the chain, something that never happens to this protocol (not even with this commit method). It can be obfuscated like in Bitcoin, but it is harder in RippleCoin due to the lines of credit that would need to be recycled often.
This approach of implementing Ripple inside a blockchain uses the [[https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains | trade across chains]] contracts use case to make the trust-less trade for bitcoins. The chain currency that hosts ripplecoin (a cash chain currency is still needed to pay for the chain with fees) can be traded atomically for ripple credit inside the same chain without the need of such a contract, the default SIGHASH_ALL described in the bitcoin contracts page is enough.
The public accounting may be actually an advantage too for some use cases, like a [[https://en.bitcoin.it/wiki/Smart_Property |smart propery]] car.
!!! Colored coins
Something similar to Ripplecoin can be implemented in the existing bitcoin chain without changing the protocol. You need to use a concept often reffered to as "colored coins". You use small bitcoin units (for example, a Satoshi) to represent the credit IOUs (or any other crypto-asset). The participants in the "ripple coloring protocol" trace the satoshis back to their source and each address is an issuer or a color.
This is an example of a ripple transaction using colored coins:
A -> B -> C
Inputs: [10 srcA, 10 srcB, 0 srcC]
Outputs: [10 destB, 10 destC]
srcA, srcB, srcC are bitcoin public keys. destB and destC are bitcoin public adresses.
A Ripple trade for bitcoins within a single transaction with each satoshis representing 1 USD could look like this:
A(10 usd) -> B(10 usd) -> C(1 btc) -> A
Inputs: [10 srcA, 10 srcB, 10^8 uncolored]
Outputs: [10 destB, 10 destC, 10^8 destA]
The disadvantage of colored coins compared to ripplecoin is that the underlying satoshis represent an artificial limitation to the divisibility of the crypto-assets issued. Although some argue that this can be useful to prevent spam. The obvious advantage is that there's no need to modify the bitcoin protocol.
With ripplecoin you would use bigger numbers instead of satoshis, so you could use fractions as you do with bitcoin (1 satoshi can also represent a fraction, 1 cent, for example). But the chain would enforce the coloring rules as well as keep real bitcoins separate from the credit. With the current approach, when the credit doesn't follow the coloring rules, the coins get "decolored".
You can find a project towards implementing colored coins here:
1) The Ripple payer sets the "dest_address" and minimum "amount" for the blockchain commit.
2) When the rest of the ripple transaction is completed, the ripple recipient should send the agreed amount of coins to the specified address.
3) If this occurs before the block "deadline" the Ripple transaction is valid, otherwise it did't happened, it is rolled back.
Given that the minter of such an instrument is a centralized entity, holders must already trust it for the deposit. It can just issue Ripple IOUs representing EUR desposits (as they can represent anything else: shares, bonds...). What the users need is be able to prove that the issuers owes them a given amount of the asset, which can be described (and the IOUs legally certified) outside of the ripple protocol.
!!! Ripplecoin
The [[https://en.bitcoin.it/wiki/Ripple_currency_exchange | bitcoin wiki]] describes a way to do this same thing using a blockchain implementation of ripple, very similar to [[https://bitcointalk.org/index.php?topic=3557.0 | RippleCoin]]. It has the advantage over the ripple distributed protocol described here that nodes don't need to be always connected and average users don't need to delegate in a server that's always connected like they usually do for e-mail, for example.
On the other hand, RippleCoin can't be instant as this protocol using the registry commit method and the financial infromation is published in the chain, something that never happens to this protocol (not even with this commit method). It can be obfuscated like in Bitcoin, but it is harder in RippleCoin due to the lines of credit that would need to be recycled often.
This approach of implementing Ripple inside a blockchain uses the [[https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains | trade across chains]] contracts use case to make the trust-less trade for bitcoins. The chain currency that hosts ripplecoin (a cash chain currency is still needed to pay for the chain with fees) can be traded atomically for ripple credit inside the same chain without the need of such a contract, the default SIGHASH_ALL described in the bitcoin contracts page is enough.
The public accounting may be actually an advantage too for some use cases, like a [[https://en.bitcoin.it/wiki/Smart_Property |smart propery]] car.
!!! Colored coins
Something similar to Ripplecoin can be implemented in the existing bitcoin chain without changing the protocol. You need to use a concept often reffered to as "colored coins". You use small bitcoin units (for example, a Satoshi) to represent the credit IOUs (or any other crypto-asset). The participants in the "ripple coloring protocol" trace the satoshis back to their source and each address is an issuer or a color.
This is an example of a ripple transaction using colored coins:
A -> B -> C
Inputs: [10 srcA, 10 srcB, 0 srcC]
Outputs: [10 destB, 10 destC]
srcA, srcB, srcC are bitcoin public keys. destB and destC are bitcoin public adresses.
A Ripple trade for bitcoins within a single transaction with each satoshis representing 1 USD could look like this:
A(10 usd) -> B(10 usd) -> C(1 btc) -> A
Inputs: [10 srcA, 10 srcB, 10^8 uncolored]
Outputs: [10 destB, 10 destC, 10^8 destA]
The disadvantage of colored coins compared to ripplecoin is that the underlying satoshis represent an artificial limitation to the divisibility of the crypto-assets issued. Although some argue that this can be useful to prevent spam. The obvious advantage is that there's no need to modify the bitcoin protocol.
With ripplecoin you would use bigger numbers instead of satoshis, so you could use fractions as you do with bitcoin (1 satoshi can also represent a fraction, 1 cent, for example). But the chain would enforce the coloring rules as well as keep real bitcoins separate from the credit. With the current approach, when the credit doesn't follow the coloring rules, the coins get "decolored".
You can find a project towards implementing colored coins here:
Changed line 57 from:
Bitcoins can be traded atomically for bitcoins in a trust-less and p2p way. There are several ways to do this. The [[https://en.bitcoin.it/wiki/Ripple_currency_exchange | bitcoin wiki]] describes a way to do it using a blockchain implementation of ripple often reffered to as [[https://bitcointalk.org/index.php?topic=3557.0 | RippleCoin]]. It has the advantage over the ripple distributed protocol described here that nodes don't need to be always connected and average users don't need to delegate in a server that's always connected like they usually do for e-mail, for example. On the other hand, RippleCoin can't be instant as this protocol using the registry commit method and the financial infromation is published in the chain. It can be obfuscated like in Bitcoin, but it is harder in RippleCoin due to the lines of credit that would e recycled.
to:
Bitcoins (or other proof of work chain currencies) can be traded atomically for bitcoins in a trust-less and p2p way. There are several ways to do this. The [[https://en.bitcoin.it/wiki/Ripple_currency_exchange | bitcoin wiki]] describes a way to do it using a blockchain implementation of ripple often reffered to as [[https://bitcointalk.org/index.php?topic=3557.0 | RippleCoin]]. It has the advantage over the ripple distributed protocol described here that nodes don't need to be always connected and average users don't need to delegate in a server that's always connected like they usually do for e-mail, for example. On the other hand, RippleCoin can't be instant as this protocol using the registry commit method and the financial infromation is published in the chain. It can be obfuscated like in Bitcoin, but it is harder in RippleCoin due to the lines of credit that would e recycled.
September 12, 2012, at 05:56 PM
by - Atomic exchanges of chain coins and Ripple IOUs
Changed line 32 from:
"chain": "Chain ID", // TODO Hash of genesis block, just label or both?
to:
"chain_ID": "(Hash of genesis block)",
Added line 36:
"amount": (optional),
Changed lines 53-55 from:
TODO avoid losing the fee if it's going to be rolled back with sequence number?
TODO atomic trade btc/ripple
TODO atomic trade btc
to:
TODO avoid losing the fee if it's going to be rolled back and the tx has already been broadcasted somehow with sequence number?
!! Atomic exchanges of chain coins and Ripple IOUs
Bitcoins can be traded atomically for bitcoins in a trust-less and p2p way. There are several ways to do this. The [[https://en.bitcoin.it/wiki/Ripple_currency_exchange | bitcoin wiki]] describes a way to do it using a blockchain implementation of ripple often reffered to as [[https://bitcointalk.org/index.php?topic=3557.0 | RippleCoin]]. It has the advantage over the ripple distributed protocol described here that nodes don't need to be always connected and average users don't need to delegate in a server that's always connected like they usually do for e-mail, for example. On the other hand, RippleCoin can't be instant as this protocol using the registry commit method and the financial infromation is published in the chain. It can be obfuscated like in Bitcoin, but it is harder in RippleCoin due to the lines of credit that would e recycled.
That approach uses the [[https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains | trade across chains]] contracts use case to make the trust-less trade.
There's no need to have EURcoins. Given that the minter of such an instrument is a centralized entity, holders must already trust it for the deposit. It can just issue Ripple IOUs (on RippleCoin or on regular Ripple) representing EUR desposits (as they can represent anything else: shares, bonds...). What the users need is be able to prove that the issuers owes them a given amount of the asset, which can be described (and the IOUs legally certified) outside of the ripple protocol.
Here we discuss the way to do the same thing with the regular Ripple protocol using the blockchain commit method. It's really simple. The Ripple payer sets the "dest_address" and minimum "amount" for the blockchain commit. When the rest of the ripple transaction is completed, the ripple recipient should send the agreed amount of coins to the specified address. If this occurs before the block "deadline" the Ripple transaction is valid, otherwise it did't happened, it is rolled back.
!! Atomic exchanges of chain coins and Ripple IOUs
Bitcoins can be traded atomically for bitcoins in a trust-less and p2p way. There are several ways to do this. The [[https://en.bitcoin.it/wiki/Ripple_currency_exchange | bitcoin wiki]] describes a way to do it using a blockchain implementation of ripple often reffered to as [[https://bitcointalk.org/index.php?topic=3557.0 | RippleCoin]]. It has the advantage over the ripple distributed protocol described here that nodes don't need to be always connected and average users don't need to delegate in a server that's always connected like they usually do for e-mail, for example. On the other hand, RippleCoin can't be instant as this protocol using the registry commit method and the financial infromation is published in the chain. It can be obfuscated like in Bitcoin, but it is harder in RippleCoin due to the lines of credit that would e recycled.
That approach uses the [[https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains | trade across chains]] contracts use case to make the trust-less trade.
There's no need to have EURcoins. Given that the minter of such an instrument is a centralized entity, holders must already trust it for the deposit. It can just issue Ripple IOUs (on RippleCoin or on regular Ripple) representing EUR desposits (as they can represent anything else: shares, bonds...). What the users need is be able to prove that the issuers owes them a given amount of the asset, which can be described (and the IOUs legally certified) outside of the ripple protocol.
Here we discuss the way to do the same thing with the regular Ripple protocol using the blockchain commit method. It's really simple. The Ripple payer sets the "dest_address" and minimum "amount" for the blockchain commit. When the rest of the ripple transaction is completed, the ripple recipient should send the agreed amount of coins to the specified address. If this occurs before the block "deadline" the Ripple transaction is valid, otherwise it did't happened, it is rolled back.
September 12, 2012, at 03:32 PM
by - add field for chain
Added line 32:
"chain": "Chain ID", // TODO Hash of genesis block, just label or both?
Changed lines 39-40 from:
to:
Changed lines 44-45 from:
If a Bitcoin transaction occurs that matches the source and destination address, and contains the commit token then the Ripple transaction is committed. Otherwise, it is rolled back. The bitcoin script cointaining the the commit token would look like this:
to:
If a Bitcoin transaction occurs that matches the source and destination address, and contains the commit token then the Ripple transaction is committed. Otherwise, it is rolled back. The [[https://en.bitcoin.it/wiki/Script | bitcoin script]] cointaining the the commit token would look like this:
Deleted line 54:
September 12, 2012, at 03:25 PM
by - commit token into the chain and TODOs
Changed lines 38-39 from:
to:
TODO especify the chain (btc, nmc, frc...) in the commit message. Hash of genesis block or just label?
Changed lines 44-55 from:
If a Bitcoin transaction occurs that matches the source and destination address, and contains the commit token (TODO: explain how a Bitcoin transaction would contain a commit token), then the Ripple transaction is committed. Otherwise, it is rolled back.
to:
If a Bitcoin transaction occurs that matches the source and destination address, and contains the commit token then the Ripple transaction is committed. Otherwise, it is rolled back. The bitcoin script cointaining the the commit token would look like this:
[@
scriptPubKey: <commit token hash> OP_DROP <pubKey> OP_CHECKSIG
@]
The amount of the transaction is not important, it can be a satoshi. But probably the payer wants to add a fee to increase the changes that it gets into the chain before the deadline so that the Ripple transaction doesn't get rolled back. Note that the bitcoin transaction (with the fee) will get into the chain whether the Ripple transaction is committed or rolled back.
TODO avoid losing the fee if it's going to be rolled back with sequence number?
TODO atomic trade btc/ripple
[@
scriptPubKey: <commit token hash> OP_DROP <pubKey> OP_CHECKSIG
@]
The amount of the transaction is not important, it can be a satoshi. But probably the payer wants to add a fee to increase the changes that it gets into the chain before the deadline so that the Ripple transaction doesn't get rolled back. Note that the bitcoin transaction (with the fee) will get into the chain whether the Ripple transaction is committed or rolled back.
TODO avoid losing the fee if it's going to be rolled back with sequence number?
TODO atomic trade btc/ripple
Added lines 1-43:
! Ripple Protocol Commit Method: Block Chain
See [[Protocol/Protocol06#commit-methods | Commit Methods]].
The Bitcoin (or other) block chain is a system for achieving distributed irrevocable consensus on transactions. It can be used as a Ripple commit method by embedding a commit token in the block chain before a deadline. Under this method, Ripple transactions are fully atomic.
!!! Commit Method Name
This commit method is called @@blockchain@@.
!! Network & Routing
!!! Hub Info
The Info message also contains:
[@
"max-block-deadline-length": (# of blocks)
@]
The max block deadline length is the maximum number of blockchain blocks the hub will hold credit for a Promise. Exchange Requests with a deadline further away will likely be refused.
!! Commit Method-Specific Data
Where commit method-specific data is required, use the following:
[@
"commit": {
"method": "blockchain",
"src_address": "(Bitcoin address)",
"dest_address": "(Bitcoin address)",
"deadline": (block number),
"commit_token": "(commit token)"
}
@]
The commit token is generated by the recipient, and is omitted from the payment init message, since it is not yet known.
!! Transactions
If a Bitcoin transaction occurs that matches the source and destination address, and contains the commit token (TODO: explain how a Bitcoin transaction would contain a commit token), then the Ripple transaction is committed. Otherwise, it is rolled back.
See [[Protocol/Protocol06#commit-methods | Commit Methods]].
The Bitcoin (or other) block chain is a system for achieving distributed irrevocable consensus on transactions. It can be used as a Ripple commit method by embedding a commit token in the block chain before a deadline. Under this method, Ripple transactions are fully atomic.
!!! Commit Method Name
This commit method is called @@blockchain@@.
!! Network & Routing
!!! Hub Info
The Info message also contains:
[@
"max-block-deadline-length": (# of blocks)
@]
The max block deadline length is the maximum number of blockchain blocks the hub will hold credit for a Promise. Exchange Requests with a deadline further away will likely be refused.
!! Commit Method-Specific Data
Where commit method-specific data is required, use the following:
[@
"commit": {
"method": "blockchain",
"src_address": "(Bitcoin address)",
"dest_address": "(Bitcoin address)",
"deadline": (block number),
"commit_token": "(commit token)"
}
@]
The commit token is generated by the recipient, and is omitted from the payment init message, since it is not yet known.
!! Transactions
If a Bitcoin transaction occurs that matches the source and destination address, and contains the commit token (TODO: explain how a Bitcoin transaction would contain a commit token), then the Ripple transaction is committed. Otherwise, it is rolled back.