Pages:
Author

Topic: MasterCoin: New Protocol Layer Starting From “The Exodus Address” - page 97. (Read 448462 times)

legendary
Activity: 1260
Merit: 1031
Rational Exuberance
A request for whoever maintains the wiki, can we have a full wiki with all the technical details in one place? I know there is a whitepaper but shouldn't all of that be on the wiki along with updates to the specification? It is changing too fast and is becoming hard to keep up with where Mastercoin is now or is going.

Better organized documentation will make it easier to write code for this project.

@dacoinminster
dillpicklechips mentioned that a potential threat to Mastercoin is that a bunch of alt clones could be made which offer free Mastercoins, piggybacking off the infrastructure and development of the original Mastercoin in an attempt to drive the value of Mastercoins down to 0. Is this attack feasible and can anything be done to prevent it if it is?

My understanding of the Mastercoin protocol is that initial value has to be in the Mastercoins in order for the escrow to work.


MasterCoin is very vulnerable to copycats technically, but much less vulnerable socially. There is nothing to prevent somebody from forking our code and doing their own thing. However, in order to be successful they would have to offer something that MasterCoin does not offer. As soon as they did that, MasterCoin would almost certainly add that feature too.

Potential investors will have to decide for themselves how likely a copycat is to be successful. The thought experiments involved in such scenarios are almost entirely social, not technical, and are heavily influenced by network effects (the reason it is so darn hard to unseat eBay as the king of auctions, even though making an auction website is fairly trivial).

edit: And yes, you need something of value stored in escrow for the escrow-backed currencies to work. You couldn't use a "free" currency for this.
hero member
Activity: 994
Merit: 507

@dacoinminster
dillpicklechips mentioned that a potential threat to Mastercoin is that a bunch of alt clones could be made which offer free Mastercoins, piggybacking off the infrastructure and development of the original Mastercoin in an attempt to drive the value of Mastercoins down to 0. Is this attack feasible and can anything be done to prevent it if it is?

My understanding of the Mastercoin protocol is that initial value has to be in the Mastercoins in order for the escrow to work.

Thank you. That is really my main concern with the whole idea. I like it and would like to invest maybe but I don't see how you can keep the value of Mastercoins high with time. As you have seen earlier in my arguments the cost of cloning is zero. The cost of security of Mastercoin is also zero because it piggy backs on top of BTC. BTC keeps it's momentum because of all the miners. It would be hard to switch. That is not the case with Mastercoin. Once the project is mature what is to stop someone from cloning the project and offering something way cheaper than the old Mastercoin? Or even a Mastercoin that uses a "generation address" where there is no limit on Mastercoins. The exact same concept but pegging the coins to BTC and keeping it consistent. Then the businesses know their exact costs without worrying about Mastercoin speculation and can actually participate with the new Mastercoin without worrying about trading first for the mastercoins.
hero member
Activity: 714
Merit: 510
A request for whoever maintains the wiki, can we have a full wiki with all the technical details in one place? I know there is a whitepaper but shouldn't all of that be on the wiki along with updates to the specification? It is changing too fast and is becoming hard to keep up with where Mastercoin is now or is going.

Better organized documentation will make it easier to write code for this project.

@dacoinminster
dillpicklechips mentioned that a potential threat to Mastercoin is that a bunch of alt clones could be made which offer free Mastercoins, piggybacking off the infrastructure and development of the original Mastercoin in an attempt to drive the value of Mastercoins down to 0. Is this attack feasible and can anything be done to prevent it if it is?

My understanding of the Mastercoin protocol is that initial value has to be in the Mastercoins in order for the escrow to work.
hero member
Activity: 938
Merit: 1000
Moved it to the new thread Smiley
legendary
Activity: 1260
Merit: 1031
Rational Exuberance
I've updated our official contest thread with the rules for the next contest: https://bitcointalksearch.org/topic/300-btc-coding-contest-distributed-exchange-mastercoin-developer-thread-292628

My intention is that thread should become our hub for development-related discussion, while this thread will remain for general MasterCoin discussion.

For instance, the discussion with dillpicklechips about MasterCoin's value would stay here, while just about anything by tachikoma, zathras, grazcoin, retep, and other devs would go in the other thread.

I won't be a jerk about it on this thread (I'll just give gentle reminders if needed), but I may be more of a jerk about it on the development thread, as I want to keep it focused on development.

I see a couple dev-related things (especially the stuff related to multi-sig) which I need to reply to. I'll do that shortly on the other thread.

Thanks!
hero member
Activity: 938
Merit: 1000
I've ran double the amount just to be sure but the longest sequence number I needed was 15 iterations in order to make it work. One more thing I want to check is not use random looking hex keys but random looking Mastercoin data since that data looks different the results might be different as well.

If we already run brute force iterations to make the pubkey valid, we could consider doing the same for the non-compressed pubkeys (MIP1) and have 2 outputs instead of 4, plus extra place for future required data. I didn't check how much more iteration that would take, but it would add much less contamination to the blockchain.



Uncompressed public keys have an added problem, the x and y coords need to be correct in order to be on the same curve.


In the wrong order where exactly?
sr. member
Activity: 284
Merit: 250
I've ran double the amount just to be sure but the longest sequence number I needed was 15 iterations in order to make it work. One more thing I want to check is not use random looking hex keys but random looking Mastercoin data since that data looks different the results might be different as well.

If we already run brute force iterations to make the pubkey valid, we could consider doing the same for the non-compressed pubkeys (MIP1) and have 2 outputs instead of 4, plus extra place for future required data. I didn't check how much more iteration that would take, but it would add much less contamination to the blockchain.

hero member
Activity: 938
Merit: 1000

Thanks! Re-indexed. I will probably do a full re-index soon but I am currently scattering my attention between the library, the site, the wallet and the theory so it's all spread very thin. Sorry about these mixups.

I ran up 20,000 compressed pubkeys from random, then used the last byte rotation method to try and make them valid ECDSA points.  

Seems to have worked for all 20,000 - but my ECDSA point validity testing is being done with code from the Casascius Bitcoin Address Utility and there is a line in there that is making me wonder whether the validatePoint() and other check functions are giving me the whole picture on whether the keys are valid:

Code:
// todo: ensure X and Y are on the curve

You can find the results here.  Tachikoma, when you're back and have a bit of time would you mind taking the '*RAW' file and running some of those pubkeys through your Mastercoin::Util.valid_ecdsa_point? function and see what results you get?  They are the corrected keys with the last byte rotated and all 20,000 are supposed to be valid.


I've ran double the amount just to be sure but the longest sequence number I needed was 15 iterations in order to make it work. One more thing I want to check is not use random looking hex keys but random looking Mastercoin data since that data looks different the results might be different as well.
legendary
Activity: 2898
Merit: 1017
hero member
Activity: 938
Merit: 1000
Found the problem, the official spec is still not updated. This makes it a lot harder for new developers (and developers who forget stuff...)

J.R. Could you please update the spec with all the new data packet order stuff and the new validation rules? (broken sequence, ambiguous sequence etc.)

Rolling out fix in the next few minutes.

Edit:

Transaction should be fixed.

I somehow missed part of the sequence discussion.

Quote
If there is a broken sequence (i.e. 3,4,8), then the odd-man-out is the change address (8 in this example)
If there is an ambiguous sequence (i.e. 3,4,4), then the transaction is invalid!
If there is a perfect sequence (i.e. 3,4,5), then the transaction is invalid!

Is this really necessary? We have no control over the sequence number for a change address, is it fair to disregard a transaction based on random luck? I would like to propose to do a sanity check before invalidating a transaction based on sequence. You could try to decode the address and see if the transaction_type and the other options based on that transaction_type make sense. If one of the addresses with the same sequence for instance does that, but an other does not you know which one is the data address and which one the target. If that also fails it seems safe to flag it as invalid but I think we should try harder before falling back to invalid.
sr. member
Activity: 284
Merit: 250
I think I'm doing something wrong with sequences so I would appreciate a second pair of eyes on this.

This transaction: https://blockchain.info/tx/32962c6254a8c48459ca9c729509272f02e291a326c43a106cfb108f00cd5570

According to Maximt the target address is 1NADJn7sackXPKxS94DiB9geu3mS5Me1Uw however this address has a sequence of 232 according to my code. The data address, 1N4R6K9MHmZQewYRdATUT849Gm2XSc2fZ2, has a sequence of 231 instead of 233.

Quote
In order to distinguish data packets from the reference address, the data packet sequence numbers start at n+1 where n is the sequence number of the reference packet if it were treated as a data packet.

According to this logic 1N4R6K9MHmZQewYRdATUT849Gm2XSc2fZ2 is the target and 1NADJn7sackXPKxS94DiB9geu3mS5Me1Uw the data packet. What am I doing wrong or is this an invalid transaction. How was this transaction created?

In order to be in sync with the project (which is obviously required for the next contest), I have added parsing using Tachikoma's multisig and disabled mine.
You can use my API to help debugging, e.g.:
http://dev.masterchain.info/tx/28ffa93e3d3091f7c501585fd741327d3c58ef3f45bcd94f72166889798283cf.json will tell you that this transaction is invalid since there is ambiguous sequence [119, 119, 120]



and the tx you asked for is just fine:
http://masterchain.info/Transaction.html?tx=32962c6254a8c48459ca9c729509272f02e291a326c43a106cfb108f00cd5570¤cy=MSC

sr. member
Activity: 284
Merit: 250
I think I'm doing something wrong with sequences so I would appreciate a second pair of eyes on this.

This transaction: https://blockchain.info/tx/32962c6254a8c48459ca9c729509272f02e291a326c43a106cfb108f00cd5570

According to Maximt the target address is 1NADJn7sackXPKxS94DiB9geu3mS5Me1Uw however this address has a sequence of 232 according to my code. The data address, 1N4R6K9MHmZQewYRdATUT849Gm2XSc2fZ2, has a sequence of 231 instead of 233.

Quote
In order to distinguish data packets from the reference address, the data packet sequence numbers start at n+1 where n is the sequence number of the reference packet if it were treated as a data packet.

According to this logic 1N4R6K9MHmZQewYRdATUT849Gm2XSc2fZ2 is the target and 1NADJn7sackXPKxS94DiB9geu3mS5Me1Uw the data packet. What am I doing wrong or is this an invalid transaction. How was this transaction created?

In order to be in sync with the project (which is obviously required for the next contest), I have added parsing using Tachikoma's multisig and disabled mine.
You can use my API to help debugging, e.g.:
http://dev.masterchain.info/tx/28ffa93e3d3091f7c501585fd741327d3c58ef3f45bcd94f72166889798283cf.json will tell you that this transaction is invalid since there is ambiguous sequence [119, 119, 120]

hero member
Activity: 938
Merit: 1000
I think I'm doing something wrong with sequences so I would appreciate a second pair of eyes on this.

This transaction: https://blockchain.info/tx/32962c6254a8c48459ca9c729509272f02e291a326c43a106cfb108f00cd5570

According to Maximt the target address is 1NADJn7sackXPKxS94DiB9geu3mS5Me1Uw however this address has a sequence of 232 according to my code. The data address, 1N4R6K9MHmZQewYRdATUT849Gm2XSc2fZ2, has a sequence of 231 instead of 233.

Quote
In order to distinguish data packets from the reference address, the data packet sequence numbers start at n+1 where n is the sequence number of the reference packet if it were treated as a data packet.

According to this logic 1N4R6K9MHmZQewYRdATUT849Gm2XSc2fZ2 is the target and 1NADJn7sackXPKxS94DiB9geu3mS5Me1Uw the data packet. What am I doing wrong or is this an invalid transaction. How was this transaction created?

Edit: Looks like this is a problem with mastercoin-explorer, in all likely hood the transaction is correct.
legendary
Activity: 2898
Merit: 1017
So is this still a legit transfer ? Did the target address got the Mastercoins ?
hero member
Activity: 938
Merit: 1000
We have a small discrepancy between Masterchest and Mastercoin-explorer regarding this transaction:
https://blockchain.info/tx/32962c6254a8c48459ca9c729509272f02e291a326c43a106cfb108f00cd5570

http://mastercoin-explorer.com/transactions/32962c6254a8c48459ca9c729509272f02e291a326c43a106cfb108f00cd5570
https://masterchest.info/lookuptx.aspx?txid=32962c6254a8c48459ca9c729509272f02e291a326c43a106cfb108f00cd5570

It looks like the "To" address on Mastercoin-explorer (1N4R6K9MHmZQewYRdATUT849Gm2XSc2fZ2) actually is the data address.
The correct receiving address should be 1NADJn7sackXPKxS94DiB9geu3mS5Me1Uw – any idea what's going on here?

Sorry I'm working on checking this out right now.
hero member
Activity: 700
Merit: 500
We have a small discrepancy between Masterchest and Mastercoin-explorer regarding this transaction:
https://blockchain.info/tx/32962c6254a8c48459ca9c729509272f02e291a326c43a106cfb108f00cd5570

http://mastercoin-explorer.com/transactions/32962c6254a8c48459ca9c729509272f02e291a326c43a106cfb108f00cd5570
https://masterchest.info/lookuptx.aspx?txid=32962c6254a8c48459ca9c729509272f02e291a326c43a106cfb108f00cd5570

It looks like the "To" address on Mastercoin-explorer (1N4R6K9MHmZQewYRdATUT849Gm2XSc2fZ2) actually is the data address.
The correct receiving address should be 1NADJn7sackXPKxS94DiB9geu3mS5Me1Uw – any idea what's going on here?
legendary
Activity: 1666
Merit: 1010
he who has the gold makes the rules
Frankly I think that's awful advice in the case of Mastercoin and similar systems, precisely because they can get away with using standard transaction to achieve their goals.

Why risk having the reference client maintainers reject your transaction standard if you don't have to?

That presumes additional checks on pubkeys are not coming down the pipe, which is also awful presumption / advice.



Basically what this means, to me, is that the Mastercoin Foundation would need to ensure that there is at least one developer interfacing with the core bitcoin development process.  Sort of like a lobbyist...it should not be left to chance encounters on this forum.

Anyway like salesforce has appexchange, facebook has fb apps, and apple has appstore, bitcoin will need to be friendly to its "partner ecosystem" at least if it is to mushroom... not sure that is in the vision, or who is leading the vision on that.

Mastercoin is to bitcoin, as zynga is to facebook, as angrybirds is to iphone, etc. Btc holders and miners should be happy about vendor lock in lol.
Pages:
Jump to: