Topic: MasterCoin: New Protocol Layer Starting From “The Exodus Address” - page 112. (Read 448462 times)
September 30, 2013, 12:50:45 PM
Forgive my ignorance but could you explain what 'off blockchain script-messaging' is in this context?
September 30, 2013, 12:15:05 PM
I know it might be a bit late and also off-topic, but why don't you guys try to use the off blockchain script-messaging based possibility to include and handle all transactions of the higher levels (expect the one when somebody sends bitcoins to buy some mastercoins)
Since the number of mastercoins are constants (well there will be 10% gradually being added, but at any known interval the total is a constant number), we can use a list of all mastercoin wallets with > 0 ballance, plus a modular arithmetic way of encoding every and each tx in a standard binary number (chiness remainder theorem can produce these numbers easily) to be dealt and then to be added and modified in the wallets list.
As the decentralized handling of this scheme may be questioned, there could be two ways:
1- Using several gradually increasing number of info wallets, as seeders, to just keep the wallets balance list+ recent script-based tx.
2-Making use of random double-spending-check functioning nodes, that is: for each tx, two or three random online wallet>0 will be chosen to check the tx correctness due to their list and if they all permit it, tx can be finalized and included in their balance lists (and new one be informed to others as well)
*Or rather an optimal combination of 1,2.
Since the number of mastercoins are constants (well there will be 10% gradually being added, but at any known interval the total is a constant number), we can use a list of all mastercoin wallets with > 0 ballance, plus a modular arithmetic way of encoding every and each tx in a standard binary number (chiness remainder theorem can produce these numbers easily) to be dealt and then to be added and modified in the wallets list.
As the decentralized handling of this scheme may be questioned, there could be two ways:
1- Using several gradually increasing number of info wallets, as seeders, to just keep the wallets balance list+ recent script-based tx.
2-Making use of random double-spending-check functioning nodes, that is: for each tx, two or three random online wallet>0 will be chosen to check the tx correctness due to their list and if they all permit it, tx can be finalized and included in their balance lists (and new one be informed to others as well)
*Or rather an optimal combination of 1,2.
September 30, 2013, 11:51:32 AM
I've added links to mastercoin.org and masterchest.info to the OP. Not sure why I didn't have a masterchest link there already - sorry Zathras.
If anybody knows of links that should be in the OP or on the MasterCoin.org page or in the reddit sidebar, please let me know!
-J.R.
If anybody knows of links that should be in the OP or on the MasterCoin.org page or in the reddit sidebar, please let me know!
-J.R.
September 30, 2013, 11:42:05 AM
Selling Mastercoin for Bitcoin spec
Now that multiple wallet releases are coming closer it seems like a good time to look ahead. One of the things that I think we should build next is the option to buy Mastercoins with Bitcoin via the spec.
I have a couple of problems with the current plan laid out by the official spec. For those who are unfamiliar the current idea is that somebody can create an offer transaction that will list how many Mastercoins he or she is selling and how many Bitcoins should be send in return. If I would want to take somebody up on that offer I would first send a 'accept offer' transactions followed by a transaction of the actual Bitcoins.
Fake offers can be a real problem with this implementation. Currently fake offers are discouraged by setting a high transaction fee required for the 'accept offer' transactions, however this is not a perfect solution. For one; people who have coins to burn can still spam accept offer transactions without ever sending them and if two legitimate offers come in and there are not enough coins available the last person will have paid this steep transaction fee without having actually bought the coins.
My solution has other problems and I am not even sure it's better but I wanted to provide an alternative.
The idea is that we cut out the 'accept offer' transaction and that in order to accept an offer you send the actual transaction with the required Bitcoin amount using a 2-out-of-3 multisig transaction. This multisig transaction will have three public keys. One public key will be the key of the person that broadcasted the offer. One public key will be that of the person accepting the offer. The third public key will be of a escrow party. For now I consider this escrow party to be the Mastercoin foundation.
Let's see how this would work in practice.
* User A broadcasts an offer of 100 Mastercoins for 20 Bitcoin.
* User B and User C both accept this offer in the exact specified quantity.
Once these transactions are included in the blockchain it shows that User C's transaction was included before User B's and this the winner of these coins.
User A now wants to spend his just received Bitcoins. He creates a transaction to send the multisig transaction he received to a address he solely owns and signs it with his key. He then uploads/transmits the partly signed transaction to a site/application owned by the Mastercoin foundation that checks if User A is allowed to spend those 20 Bitcoins. The application will verify that User A did indeed sell User C Mastercoins and that he is allowed to spend these coins, the app will automatically sign the transaction and broadcast it (or return the signature transaction).
The same can be done for User B, who's offer lost. The middleman app will recognise that User B did indeed lose the race and will sign his transaction as well.
However if User C now tries to use this service the app will recognise that he was actually a winner and won't sign his transaction.
The main problem with this implementation is that it requires trust, something I think we should try to avoid as much as possible. However this solution does solve all the points I addressed in the opening. I hope somebody can come up with a way to further decentralise this solution. If not we should probably decide if it's worth it to centralise a bit in order to have a better user experience.
Feedback welcome, as always
Now that multiple wallet releases are coming closer it seems like a good time to look ahead. One of the things that I think we should build next is the option to buy Mastercoins with Bitcoin via the spec.
I have a couple of problems with the current plan laid out by the official spec. For those who are unfamiliar the current idea is that somebody can create an offer transaction that will list how many Mastercoins he or she is selling and how many Bitcoins should be send in return. If I would want to take somebody up on that offer I would first send a 'accept offer' transactions followed by a transaction of the actual Bitcoins.
Fake offers can be a real problem with this implementation. Currently fake offers are discouraged by setting a high transaction fee required for the 'accept offer' transactions, however this is not a perfect solution. For one; people who have coins to burn can still spam accept offer transactions without ever sending them and if two legitimate offers come in and there are not enough coins available the last person will have paid this steep transaction fee without having actually bought the coins.
My solution has other problems and I am not even sure it's better but I wanted to provide an alternative.
The idea is that we cut out the 'accept offer' transaction and that in order to accept an offer you send the actual transaction with the required Bitcoin amount using a 2-out-of-3 multisig transaction. This multisig transaction will have three public keys. One public key will be the key of the person that broadcasted the offer. One public key will be that of the person accepting the offer. The third public key will be of a escrow party. For now I consider this escrow party to be the Mastercoin foundation.
Let's see how this would work in practice.
* User A broadcasts an offer of 100 Mastercoins for 20 Bitcoin.
* User B and User C both accept this offer in the exact specified quantity.
Once these transactions are included in the blockchain it shows that User C's transaction was included before User B's and this the winner of these coins.
User A now wants to spend his just received Bitcoins. He creates a transaction to send the multisig transaction he received to a address he solely owns and signs it with his key. He then uploads/transmits the partly signed transaction to a site/application owned by the Mastercoin foundation that checks if User A is allowed to spend those 20 Bitcoins. The application will verify that User A did indeed sell User C Mastercoins and that he is allowed to spend these coins, the app will automatically sign the transaction and broadcast it (or return the signature transaction).
The same can be done for User B, who's offer lost. The middleman app will recognise that User B did indeed lose the race and will sign his transaction as well.
However if User C now tries to use this service the app will recognise that he was actually a winner and won't sign his transaction.
The main problem with this implementation is that it requires trust, something I think we should try to avoid as much as possible. However this solution does solve all the points I addressed in the opening. I hope somebody can come up with a way to further decentralise this solution. If not we should probably decide if it's worth it to centralise a bit in order to have a better user experience.
Feedback welcome, as always
I'd definitely like to experiment with some alternate implementations of the distributed exchange at some point. Tachikoma is correct that the suggested changes here would reduce the cost overhead while increasing centralization. I'd make one major change: the MasterCoin Foundation should not play middle-man, for legal reasons. We need to stay out of the money flows lest we be held liable for them. Allowing users to choose their own middleman would fix that problem and make the solution less centralized, but we would end up with multiple middle-man apps, and therefore multiple exchanges with multiple order books.
Another potential problem is keeping the middle-man secure. It would be a potential attack vector to compromise the middle-man account and then set up situations that allow stealing of BTC from market participants.
I'd like to stick with the existing implementation described in the spec for now, which is decentralized but marginally more expensive to users (it should only be expensive when the exchange is under attack, and since attackers lose money and can't actually shut down the exchange, I don't expect any attack would last very long or be effective).
If we find that fees rise unreasonably high, we can play around with middle-man apps, but I expect that fees will not be very high long term, except for brief periods when hostile forces decide to burn some bitcoins. During those periods, we'll always have the option of using escrow just like we do today.
Keep in mind that the decentralized exchange can't be burdened with fees in this way when exchanging between MasterCoins and other MasterCoin-derived currencies. This only affects MasterCoin/bitcoin exchange.
September 30, 2013, 11:29:48 AM
Now as far as I am concerned this is not hitting the output dust threshold.
Dust threshold depends on the size of the output:
Code:
bool IsDust(int64 nMinRelayTxFee) const
{
// "Dust" is defined in terms of CTransaction::nMinRelayTxFee,
// which has units satoshis-per-kilobyte.
// If you'd pay more than 1/3 in fees
// to spend something, then we consider it dust.
// A typical txout is 34 bytes big, and will
// need a CTxIn of at least 148 bytes to spend,
// so dust is a txout less than 54 uBTC
// (5460 satoshis) with default nMinRelayTxFee
return ((nValue*1000)/(3*((int)GetSerializeSize(SER_DISK,0)+148)) < nMinRelayTxFee);
}
It is 5460 satoshis for a typical output, but is larger for your multi-sig one.
Yeah I was just about to post that; I will see if I can calculate the needed size to prevent the dust limit whilst creating the transaction.
Can anybody verify that in the code example above; nValue is the (Bitcoin) amount and (int)GetSerializeSize(SER_DISK,0) the bytesize of the output script.
September 30, 2013, 11:25:01 AM
Tachikoma, regarding your test transactions...
My understanding of the discussions so far provides for the following requirements for what I guess you could call a properly formatted Mastercoin transaction:
* Without multisig, all 3 address/output amounts must be the same
I wouldn't even make it that strict (unless J.R. already wrote that in the spec) if I want to send more bitcoins then I should be free to do so and it should not invalidate the Mastercoin transaction. My understanding of the discussions so far provides for the following requirements for what I guess you could call a properly formatted Mastercoin transaction:
* Without multisig, all 3 address/output amounts must be the same
I believe this is actually already explicitly defined by JR both in his comments and the spec. It's less about the value of the amount, more that all outputs have the same amount.
All protocol transactions should have the same output amount. If one output is different, that is the change address.
Quote
(From the spec)
All transaction outputs should be for the same amount, which should be above the “dust” threshold, and should include an appropriate fee to ensure that miners include them in the block chain in a timely manner. For instance, the first MasterCoin transactions had three outputs of 0.00006 BTC each, with a 0.0001 BTC transaction fee.
All transaction outputs should be for the same amount, which should be above the “dust” threshold, and should include an appropriate fee to ensure that miners include them in the block chain in a timely manner. For instance, the first MasterCoin transactions had three outputs of 0.00006 BTC each, with a 0.0001 BTC transaction fee.
Based on the above those rules are applied in my implementation and I require all outputs to be for the same amount. The exception is multisig where I've temporarily allowed the multisig output amount to be ref/exodus amount * 2 while we firm up the discussion.
Having all the outputs be the same amount is merely a convenience for identifying the change address. I'm fine with a less strict implementation as long as it is still possible to identify the change address.
September 30, 2013, 11:21:44 AM
Now as far as I am concerned this is not hitting the output dust threshold.
Dust threshold depends on the size of the output:
Code:
bool IsDust(int64 nMinRelayTxFee) const
{
// "Dust" is defined in terms of CTransaction::nMinRelayTxFee,
// which has units satoshis-per-kilobyte.
// If you'd pay more than 1/3 in fees
// to spend something, then we consider it dust.
// A typical txout is 34 bytes big, and will
// need a CTxIn of at least 148 bytes to spend,
// so dust is a txout less than 54 uBTC
// (5460 satoshis) with default nMinRelayTxFee
return ((nValue*1000)/(3*((int)GetSerializeSize(SER_DISK,0)+148)) < nMinRelayTxFee);
}
It is 5460 satoshis for a typical output, but is larger for your multi-sig one.
September 30, 2013, 11:10:58 AM
My transactions were being flagged as non-valid whenever I used 0.00006 for the multisig output, changing this to 0.00006 * 2 fixed this for some reason.
Do you happen to recall/have notes on what error was returned?I think I got a very non-informative tx-reject (error 22). I think the debug log mentioned something about it being a non-standard transaction. I will check it out tonight if I can find some time
That's because the amount is below the dust threshold (0.000534 or thereabouts).
This transaction is getting flagged as invalid.
Code:
{
"txid" : "88b32ad8a0b9181c97ce1cab49ea745621c05ac20fe90364b72bb18c4f88896b",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "9de348c35488f4142f4e080a80737a3965d6de473360d974d361dd8ca107152a",
"vout" : 0,
"scriptSig" : {
"asm" : "3045022100a5a61491ee0682342140dbe7846be08e1ce1f0361fb3fc758ef66ee434a83e8a02203aaea5ba9cacb3e9ec7eff736436882258add92f17b09c58b11b6c4296b10b5a01 04e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee3419a40b939c24ac813c692a323ca5207a6fb387ffe28e48f706c95dbf46648f",
"hex" : "483045022100a5a61491ee0682342140dbe7846be08e1ce1f0361fb3fc758ef66ee434a83e8a02203aaea5ba9cacb3e9ec7eff736436882258add92f17b09c58b11b6c4296b10b5a014104e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee3419a40b939c24ac813c692a323ca5207a6fb387ffe28e48f706c95dbf46648f"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 0.00938000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 19fd7459d1c21227f3e87582fa1de350b1549ae2 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a91419fd7459d1c21227f3e87582fa1de350b1549ae288ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"13NRX88EZbS5q81x6XFrTECzrciPREo821"
]
}
},
{
"value" : 0.00006000,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 bad510ef5889498cc9340ec00d71733440817b77 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914bad510ef5889498cc9340ec00d71733440817b7788ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B"
]
}
},
{
"value" : 0.00006000,
"n" : 2,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 946cb2e08075bcbaf157e47bcb67eb2b2339d242 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P"
]
}
},
{
"value" : 0.00006000,
"n" : 3,
"scriptPubKey" : {
"asm" : "1 04e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee3419a40b939c24ac813c692a323ca5207a6fb387ffe28e48f706c95dbf46648f 02010000000000000002000000000000000e000000000000000000000000000000 2 OP_CHECKMULTISIG",
"hex" : "514104e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee3419a40b939c24ac813c692a323ca5207a6fb387ffe28e48f706c95dbf46648f2102010000000000000002000000000000000e00000000000000000000000000000052ae",
"reqSigs" : 1,
"type" : "multisig",
"addresses" : [
"13NRX88EZbS5q81x6XFrTECzrciPREo821",
"1BByZwb4cTUL3mWzNE4XqJXCZiFTX7Z48f"
]
}
}
]
}
Now as far as I am concerned this is not hitting the output dust threshold. The dust limit is 0.0000534 (I think you forgot a zero). An all outputs are larger then this limit.
Bitcoind debug.log reports "ERROR: CTxMemPool::accept() : nonstandard transaction type".
September 30, 2013, 10:16:24 AM
Mastercoin is the friendliest hostile fork I've seen in a long time.
Maybe implementing this in one of the alternate blockchains would be an idea for consideration.
Apparently there's a colored coin launching using Florin today.
September 30, 2013, 09:49:32 AM
Mastercoin is the friendliest hostile fork I've seen in a long time.
Maybe implementing this in one of the alternate blockchains would be an idea for consideration.
Apparently there's a colored coin launching using Florin today.
September 30, 2013, 09:32:54 AM
Mastercoin is the friendliest hostile fork I've seen in a long time.
September 30, 2013, 07:43:45 AM
This would mean I used a very small output to begin with, sadly I did not keep my rejected transactions around. I will see what I can find out tonight, thanks for the suggestion.
September 30, 2013, 05:36:26 AM
My transactions were being flagged as non-valid whenever I used 0.00006 for the multisig output, changing this to 0.00006 * 2 fixed this for some reason.
Do you happen to recall/have notes on what error was returned?I think I got a very non-informative tx-reject (error 22). I think the debug log mentioned something about it being a non-standard transaction. I will check it out tonight if I can find some time
That's because the amount is below the dust threshold (0.000534 or thereabouts).
September 30, 2013, 03:24:53 AM
My transactions were being flagged as non-valid whenever I used 0.00006 for the multisig output, changing this to 0.00006 * 2 fixed this for some reason.
Do you happen to recall/have notes on what error was returned?I think I got a very non-informative tx-reject (error 22). I think the debug log mentioned something about it being a non-standard transaction. I will check it out tonight if I can find some time
September 29, 2013, 06:08:27 PM
Tachikoma, regarding your test transactions...
My understanding of the discussions so far provides for the following requirements for what I guess you could call a properly formatted Mastercoin transaction:
* Without multisig, all 3 address/output amounts must be the same
I wouldn't even make it that strict (unless J.R. already wrote that in the spec) if I want to send more bitcoins then I should be free to do so and it should not invalidate the Mastercoin transaction. My understanding of the discussions so far provides for the following requirements for what I guess you could call a properly formatted Mastercoin transaction:
* Without multisig, all 3 address/output amounts must be the same
I believe this is actually already explicitly defined by JR both in his comments and the spec. It's less about the value of the amount, more that all outputs have the same amount.
All protocol transactions should have the same output amount. If one output is different, that is the change address.
* With multisig, ref & exodus address/output amounts must be the same and multisig output should be (ref amount * 2) to avoid a rejected tx. The amount of the multisig output should be clarified (defined in the spec) - perhaps as (ref amount * num pub keys in multisig)?
Well the problem is that I picked the ref amount * 2 pretty random. The only reason I did it was that if I used just the ref amount the transaction would not be accepted by a bitcoind instance and I still can't for the life of me figure out why. I was hoping that your quest for building multisig transactions could perhaps shed some light on it. I think we should figure out why the normal ref amount is not enough for a valid transaction and only update the spec once we find that out.
As you note you found during testing that your transactions were rejected using the same output amount and thus you had to double it. I was under the impression this was proposing that we amend the spec to state multisig outputs = ref amount * n (so ref*2 for 1-of-2, ref*3 for 1-of-3 etc). I had not realized you'd chosen the *2 amount just as a value to get the transaction through (I shouldn't make assumptions!). Without an amendment to the spec we're basically saying all multisig transactions thus far are invalid (as they don't meet the 'All protocol transactions should have the same output amount' requirement).
In a nutshell we either need to amend the spec to allow the multisig output to be different to ref/exodus outputs (eg ref*2 for 1-of-2, ref*3 for 1-of-3 etc) or identify/resolve whatever problem it was you had keeping the multisig output amount the same as the ref/exodus outputs.
I'll do some testing with my implementation and start sending some transactions to dig a bit deeper into this to see what I can come up with.
Thanks, and well done on the wallet alpha
EDIT:
My transactions were being flagged as non-valid whenever I used 0.00006 for the multisig output, changing this to 0.00006 * 2 fixed this for some reason.
Do you happen to recall/have notes on what error was returned? September 29, 2013, 11:53:12 AM
Wallet Alpha
The first alpha version of my wallet implementation is available and I need some testers to help me out
For now I want to ask people that are comfortable with Bitcoin and Linux/OS X to step forward and try it out (Windows won't work and might never work. Luckily we have Zathras for that . For now there is no single executable that can be run so you will have to be comfortable around a terminal to run it. To the other developers please peer-review the code and make sure vital things such as private key encoding in the config-file is secure.
This version will still allow you to create and relay transactions even if the address does not own Mastercoins this makes testing easier and reduces the risk of sending transactions you did not intent to send. So feel free to use a brand new address when testing it out.
The main dependencies are the Qt framework (most distributions have it in their package managers, make sure you get a version >= 4) and Ruby >= 1.9.2. Once these dependencies are satisfied you can install the app using the rubygems package mastercoin-wallet (gem install mastercoin-wallet).
Selling Mastercoin for Bitcoin spec
Now that multiple wallet releases are coming closer it seems like a good time to look ahead. One of the things that I think we should build next is the option to buy Mastercoins with Bitcoin via the spec.
I have a couple of problems with the current plan laid out by the official spec. For those who are unfamiliar the current idea is that somebody can create an offer transaction that will list how many Mastercoins he or she is selling and how many Bitcoins should be send in return. If I would want to take somebody up on that offer I would first send a 'accept offer' transactions followed by a transaction of the actual Bitcoins.
Fake offers can be a real problem with this implementation. Currently fake offers are discouraged by setting a high transaction fee required for the 'accept offer' transactions, however this is not a perfect solution. For one; people who have coins to burn can still spam accept offer transactions without ever sending them and if two legitimate offers come in and there are not enough coins available the last person will have paid this steep transaction fee without having actually bought the coins.
My solution has other problems and I am not even sure it's better but I wanted to provide an alternative.
The idea is that we cut out the 'accept offer' transaction and that in order to accept an offer you send the actual transaction with the required Bitcoin amount using a 2-out-of-3 multisig transaction. This multisig transaction will have three public keys. One public key will be the key of the person that broadcasted the offer. One public key will be that of the person accepting the offer. The third public key will be of a escrow party. For now I consider this escrow party to be the Mastercoin foundation.
Let's see how this would work in practice.
* User A broadcasts an offer of 100 Mastercoins for 20 Bitcoin.
* User B and User C both accept this offer in the exact specified quantity.
Once these transactions are included in the blockchain it shows that User C's transaction was included before User B's and this the winner of these coins.
User A now wants to spend his just received Bitcoins. He creates a transaction to send the multisig transaction he received to a address he solely owns and signs it with his key. He then uploads/transmits the partly signed transaction to a site/application owned by the Mastercoin foundation that checks if User A is allowed to spend those 20 Bitcoins. The application will verify that User A did indeed sell User C Mastercoins and that he is allowed to spend these coins, the app will automatically sign the transaction and broadcast it (or return the signature transaction).
The same can be done for User B, who's offer lost. The middleman app will recognise that User B did indeed lose the race and will sign his transaction as well.
However if User C now tries to use this service the app will recognise that he was actually a winner and won't sign his transaction.
The main problem with this implementation is that it requires trust, something I think we should try to avoid as much as possible. However this solution does solve all the points I addressed in the opening. I hope somebody can come up with a way to further decentralise this solution. If not we should probably decide if it's worth it to centralise a bit in order to have a better user experience.
Feedback welcome, as always
The first alpha version of my wallet implementation is available and I need some testers to help me out
For now I want to ask people that are comfortable with Bitcoin and Linux/OS X to step forward and try it out (Windows won't work and might never work. Luckily we have Zathras for that
. For now there is no single executable that can be run so you will have to be comfortable around a terminal to run it. To the other developers please peer-review the code and make sure vital things such as private key encoding in the config-file is secure.This version will still allow you to create and relay transactions even if the address does not own Mastercoins this makes testing easier and reduces the risk of sending transactions you did not intent to send. So feel free to use a brand new address when testing it out.
The main dependencies are the Qt framework (most distributions have it in their package managers, make sure you get a version >= 4) and Ruby >= 1.9.2. Once these dependencies are satisfied you can install the app using the rubygems package mastercoin-wallet (gem install mastercoin-wallet).
Selling Mastercoin for Bitcoin spec
Now that multiple wallet releases are coming closer it seems like a good time to look ahead. One of the things that I think we should build next is the option to buy Mastercoins with Bitcoin via the spec.
I have a couple of problems with the current plan laid out by the official spec. For those who are unfamiliar the current idea is that somebody can create an offer transaction that will list how many Mastercoins he or she is selling and how many Bitcoins should be send in return. If I would want to take somebody up on that offer I would first send a 'accept offer' transactions followed by a transaction of the actual Bitcoins.
Fake offers can be a real problem with this implementation. Currently fake offers are discouraged by setting a high transaction fee required for the 'accept offer' transactions, however this is not a perfect solution. For one; people who have coins to burn can still spam accept offer transactions without ever sending them and if two legitimate offers come in and there are not enough coins available the last person will have paid this steep transaction fee without having actually bought the coins.
My solution has other problems and I am not even sure it's better but I wanted to provide an alternative.
The idea is that we cut out the 'accept offer' transaction and that in order to accept an offer you send the actual transaction with the required Bitcoin amount using a 2-out-of-3 multisig transaction. This multisig transaction will have three public keys. One public key will be the key of the person that broadcasted the offer. One public key will be that of the person accepting the offer. The third public key will be of a escrow party. For now I consider this escrow party to be the Mastercoin foundation.
Let's see how this would work in practice.
* User A broadcasts an offer of 100 Mastercoins for 20 Bitcoin.
* User B and User C both accept this offer in the exact specified quantity.
Once these transactions are included in the blockchain it shows that User C's transaction was included before User B's and this the winner of these coins.
User A now wants to spend his just received Bitcoins. He creates a transaction to send the multisig transaction he received to a address he solely owns and signs it with his key. He then uploads/transmits the partly signed transaction to a site/application owned by the Mastercoin foundation that checks if User A is allowed to spend those 20 Bitcoins. The application will verify that User A did indeed sell User C Mastercoins and that he is allowed to spend these coins, the app will automatically sign the transaction and broadcast it (or return the signature transaction).
The same can be done for User B, who's offer lost. The middleman app will recognise that User B did indeed lose the race and will sign his transaction as well.
However if User C now tries to use this service the app will recognise that he was actually a winner and won't sign his transaction.
The main problem with this implementation is that it requires trust, something I think we should try to avoid as much as possible. However this solution does solve all the points I addressed in the opening. I hope somebody can come up with a way to further decentralise this solution. If not we should probably decide if it's worth it to centralise a bit in order to have a better user experience.
Feedback welcome, as always
September 29, 2013, 09:53:30 AM
Quick update to say the wallet is progressing well & I've now implemented multisig support Support for multisig transactions has been added to mastercoin.info also.
Support for multisig transactions has been added to mastercoin.info also.Awesome!
Tachikoma, regarding your test transactions...
My understanding of the discussions so far provides for the following requirements for what I guess you could call a properly formatted Mastercoin transaction:
* Without multisig, all 3 address/output amounts must be the same
My understanding of the discussions so far provides for the following requirements for what I guess you could call a properly formatted Mastercoin transaction:
* Without multisig, all 3 address/output amounts must be the same
I wouldn't even make it that strict (unless J.R. already wrote that in the spec) if I want to send more bitcoins then I should be free to do so and it should not invalidate the Mastercoin transaction.
* With multisig, ref & exodus address/output amounts must be the same and multisig output should be (ref amount * 2) to avoid a rejected tx. The amount of the multisig output should be clarified (defined in the spec) - perhaps as (ref amount * num pub keys in multisig)?
Well the problem is that I picked the ref amount * 2 pretty random. The only reason I did it was that if I used just the ref amount the transaction would not be accepted by a bitcoind instance and I still can't for the life of me figure out why. I was hoping that your quest for building multisig transactions could perhaps shed some light on it. I think we should figure out why the normal ref amount is not enough for a valid transaction and only update the spec once we find that out.
The other test transactions you did had the multisig output amount as (refaddress amount * 2) but not in this particular tx (https://blockchain.info/tx/cf0edfdd0a9e4d8aea2f87fc2cec6a367e1686a1fe066390ac195a797d76c0f1).
I realize one reason it's invalid is because the sending address didn't have sufficient funds.
In my implementation the transaction is not even queued for processing/validity checking at all due to the amount on the multisig output not being (ref amount * 2) so even if the sending address did have sufficient funds I'd still throw the tx out.
I guess to summarize, would you have considered it an otherwise valid tx if the sending address would have had enough coins? Or would your implementation also throw it out based on the multisig output amount?
Appreciate your thoughts on this. Thanks.
I realize one reason it's invalid is because the sending address didn't have sufficient funds.
In my implementation the transaction is not even queued for processing/validity checking at all due to the amount on the multisig output not being (ref amount * 2) so even if the sending address did have sufficient funds I'd still throw the tx out.
I guess to summarize, would you have considered it an otherwise valid tx if the sending address would have had enough coins? Or would your implementation also throw it out based on the multisig output amount?
Appreciate your thoughts on this. Thanks.
Yeah the only reason my system flags it as invalid is because it was sent from an account that did not hold coins.
If you could do some tests with your transaction creation process and see if you can send multisig with a normal amount and not * 2 I would highly appreciate it
September 29, 2013, 07:50:21 AM
Quick update to say the wallet is progressing well & I've now implemented multisig support Support for multisig transactions has been added to mastercoin.info also.
Tachikoma, regarding your test transactions...
My understanding of the discussions so far provides for the following requirements for what I guess you could call a properly formatted Mastercoin transaction:
* Without multisig, all 3 address/output amounts must be the same
* With multisig, ref & exodus address/output amounts must be the same and multisig output should be (ref amount * 2) to avoid a rejected tx. The amount of the multisig output should be clarified (defined in the spec) - perhaps as (ref amount * num pub keys in multisig)?
The other test transactions you did had the multisig output amount as (refaddress amount * 2) but not in this particular tx (https://blockchain.info/tx/cf0edfdd0a9e4d8aea2f87fc2cec6a367e1686a1fe066390ac195a797d76c0f1).
I realize one reason it's invalid is because the sending address didn't have sufficient funds.
In my implementation the transaction is not even queued for processing/validity checking at all due to the amount on the multisig output not being (ref amount * 2) so even if the sending address did have sufficient funds I'd still throw the tx out.
I guess to summarize, would you have considered it an otherwise valid tx if the sending address would have had enough coins? Or would your implementation also throw it out based on the multisig output amount?
Appreciate your thoughts on this. Thanks.
Support for multisig transactions has been added to mastercoin.info also.Tachikoma, regarding your test transactions...
My understanding of the discussions so far provides for the following requirements for what I guess you could call a properly formatted Mastercoin transaction:
* Without multisig, all 3 address/output amounts must be the same
* With multisig, ref & exodus address/output amounts must be the same and multisig output should be (ref amount * 2) to avoid a rejected tx. The amount of the multisig output should be clarified (defined in the spec) - perhaps as (ref amount * num pub keys in multisig)?
The other test transactions you did had the multisig output amount as (refaddress amount * 2) but not in this particular tx (https://blockchain.info/tx/cf0edfdd0a9e4d8aea2f87fc2cec6a367e1686a1fe066390ac195a797d76c0f1).
I realize one reason it's invalid is because the sending address didn't have sufficient funds.
In my implementation the transaction is not even queued for processing/validity checking at all due to the amount on the multisig output not being (ref amount * 2) so even if the sending address did have sufficient funds I'd still throw the tx out.
I guess to summarize, would you have considered it an otherwise valid tx if the sending address would have had enough coins? Or would your implementation also throw it out based on the multisig output amount?
Appreciate your thoughts on this. Thanks.
September 28, 2013, 01:20:35 AM
I have a happy announcement to make - mastercoin.org website is launched!
(DNS propagation might take a while)
If you have suggestions for improving the content of the website, please post them here.
I'd like to thank Mich Palmer for taking the time to setup the site, just in time for my talk today
(DNS propagation might take a while)
If you have suggestions for improving the content of the website, please post them here.
I'd like to thank Mich Palmer for taking the time to setup the site, just in time for my talk today
Good Job! The website has all the relevant information on MSC. I shall add it to my MSC Blog resources.
September 27, 2013, 04:50:15 PM
"..Mastercoin is a layer on top of bitcoin allowing creation or trades of escrow backed currencies and commodity without the licensing or regulatory limitation..."
sounds safe like mr pirates' pipedream ?
+ ( escrow and bitcoin don't mix*per satoshiWP) LMAO
sounds safe like mr pirates' pipedream ?
+ ( escrow and bitcoin don't mix*per satoshiWP) LMAO
You have a good record of adding absolutely nothing of substance to the dialogue around here. Congratulations.
our group has been rooting for bitcoins since they traded at mear $zzz PPC !!! and i own MST Mastercoins investor and i'm alarmed by hijack blockchain UXTO collision!!!
wow! Jump to: