This thread has MOVED to MastercoinTalk: http://mastercointalk.org/index.php?topic=297.0
Thread is now locked. Please join us on the Mastercoin Forum!!
Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) (Read 129136 times)
March 31, 2014, 06:30:43 PM
March 31, 2014, 04:39:41 PM
Just emailed this to our dev@ and info@ mailing lists:
Quote
Hey Friends,
As usual, you are slammed, but if you want to get paid for the work you have done during March 2014, you need to fill out the work submission form:
https://docs.google.com/forms/d/1uKkQDfJF0MxRQZB_1mdqWugjsyHPYRK39qG5sLXCZxM/viewform
DUE MONDAY 4/7/2014!!!
After lots of discussion with Ron and Craig, I have streamlined this submission form to just have two fields: milestone work ($85k) and general innovation ($15k).
ALL dEX work, spec work, smart property work, wallet development and testing is expected to go under the first submission form. Only work outside the scope of our current milestones should go in the general innovation box.
So, what about the 300 BTC coding contest for the distributed exchange? Well, so far we have paid out 150 BTC in a lump sum, plus 50% of the February's milestone bounty which is another ~47 BTC for a total of ~197 BTC paid.
It turns out that at current prices, the remaining ~103 BTC of that contest is worth ~$46,000, and since March was mostly finishing up the dEX, I consider it paid in full once we give out the $85k milestone bounty for March. However, I may have to adjust the March milestone bounty upwards a bit if bitcoin prices spike way up before payout.
Please let me know if there are any questions. I hope the feedback form will be similarly streamlined this time around, with fewer categories to divvy up.
Thanks!
As usual, you are slammed, but if you want to get paid for the work you have done during March 2014, you need to fill out the work submission form:
https://docs.google.com/forms/d/1uKkQDfJF0MxRQZB_1mdqWugjsyHPYRK39qG5sLXCZxM/viewform
DUE MONDAY 4/7/2014!!!
After lots of discussion with Ron and Craig, I have streamlined this submission form to just have two fields: milestone work ($85k) and general innovation ($15k).
ALL dEX work, spec work, smart property work, wallet development and testing is expected to go under the first submission form. Only work outside the scope of our current milestones should go in the general innovation box.
So, what about the 300 BTC coding contest for the distributed exchange? Well, so far we have paid out 150 BTC in a lump sum, plus 50% of the February's milestone bounty which is another ~47 BTC for a total of ~197 BTC paid.
It turns out that at current prices, the remaining ~103 BTC of that contest is worth ~$46,000, and since March was mostly finishing up the dEX, I consider it paid in full once we give out the $85k milestone bounty for March. However, I may have to adjust the March milestone bounty upwards a bit if bitcoin prices spike way up before payout.
Please let me know if there are any questions. I hope the feedback form will be similarly streamlined this time around, with fewer categories to divvy up.
Thanks!
March 31, 2014, 03:44:10 AM
statistics update for masterchain.info during March (which ends in few hours):
Total Requests 529107 Unique Visitors 11112
Total Requests 529107 Unique Visitors 11112
March 30, 2014, 02:07:27 AM
Looks like JR is closing all Mastercoin threads. That's a shame because the only place people can reasonably learn about Mastercoin is in these fora. Therefore, I've started a new thread which JR cannot force people to stop using...
https://bitcointalksearch.org/topic/m.5978864
https://bitcointalksearch.org/topic/m.5978864
March 26, 2014, 05:16:55 AM
Does anyone have an example of how to create op return raw tx?
https://bitcointalksearch.org/topic/m.5302717
Take a look at this. If you need further help, I'll assist.
March 26, 2014, 04:34:07 AM
@grazcoin: When trying to do a payment after I accepted an offer I got "Transaction error" after hitting send, when in fact the transaction went through. I tried it two more times and the last one showed Transaction sent
Check transaction: https://blockchain.info/tx/a4197db8c2c9a2d9b1f9985f6b7a5bd0595a82a2533672c6b276971df1df4c60 ,
but actually all 3 transactions went through.
Check transaction: https://blockchain.info/tx/a4197db8c2c9a2d9b1f9985f6b7a5bd0595a82a2533672c6b276971df1df4c60 ,
but actually all 3 transactions went through.
The part of the "Send" is currently implemented in an external way using api of blockchain.info
Transaction error is not under my control. I may re-implement it soon as internal service so I don't have to rely on external components.
Creating multiple payments and sending them all makes not much sense. It is like paying again and again to the same purchase in the supermarket
This transaction you mention is parsed also by masterchain.info:
https://masterchain.info/btcpayment.html?tx=a4197db8c2c9a2d9b1f9985f6b7a5bd0595a82a2533672c6b276971df1df4c60¤cy=MSC
but it is not associated with any purchase.
The seller you tried to pay to is:
https://masterchain.info/Address.html?addr=14Q2NNiF5YzDZCjo7vrBuHdbZcmHRJyW3j¤cy=MSC
and it had only one relevant sell offer:
https://masterchain.info/selloffer.html?tx=574b7eb6a81d825a996170720573c2092e1cb5355c5a2fd36515621e5d849d54¤cy=MSC
This sell offer was accepted (block 292463) and paid (block 292470):
https://masterchain.info/sellaccept.html?tx=b309bab09282216697f1db77cdb86421aa95a977ea0f54f569452ec9c9d9a145¤cy=MSC
and left the sell offer with no more coins to sell - in status "done".
The payment you refer to is on block 292471, and at that time point, the sell offer as well as the accept were already closed.
The seller should at least thank you for getting free coins from you.
I hope this is clear.
Grazcoin
March 26, 2014, 02:57:35 AM
Does anyone have an example of how to create op return raw tx?
March 25, 2014, 07:14:32 PM
Can you point me to discussions had on this subject? I'm interested to know if any discussed ideas allow a snapshot to be referenced without developer involvement.
https://github.com/mastercoin-MSC/spec/issues/69
This is from where I got the idea. You have a fair point. Snapshots should only be necessary for times of actual changes.
Quote
I was thinking about something similar as I was submitting my pull request. Maybe it's not necessary to revise the entire specification if only one or two small changes are made. If different sections are broken out one can submit pull requests for items that don't warrant an entire specification revision, and changes can be discussed in a context more relevant to the issue at hand.
If we consider the specification a dataset instead of a specific document, it may be reasonable to precisely define a type of transaction as a data point and discrete unit, and consequently revise that definition independently of any other definition. This also allows all changes to a specific definition to be queried, and a "timeline" built of changes relevant to a specific transaction type.
If we consider the specification a dataset instead of a specific document, it may be reasonable to precisely define a type of transaction as a data point and discrete unit, and consequently revise that definition independently of any other definition. This also allows all changes to a specific definition to be queried, and a "timeline" built of changes relevant to a specific transaction type.
Good idea, this is what I have in mind, too. The current specification is more like a description than a short down-to-the-point set of formal definitions about the protocol.
Quote
Maybe a crazy idea, but why not use Master Protocol itself to store the specification? For the sake of opening up a discussion on the subject, consider if a transaction definition could be stored in the blockchain. Not only is it universally publicly accessible and immutable, but a standardized dictionary could theoretically allow a client to programatically and dynamically verify the validity of a transaction based on the relevant definition at the time. I have experience designing and implementing relational databases and would be thrilled to contribute if others think that this may be worth pursuing. I'm not under the impression that it's an easy task, but then again, neither was a distributed exchange.
Hahaha. I like the way you think. This is nothing that can be done in a short timeframe though. You'd need a) a agreed upon format to publish the data, b) define who is allowed to push changes, c) a way to fetch the data and d) an interpreter.
Quote
IMO, this is unnecessary. I don't see any reason why a properly formed transaction definition shouldn't be able to determine validity of all applicable transactions. Archival could imply more limitations than the benefit gained by ease of gathering examples. Maybe your concern here could be appeased with the ability to prove a transaction types definition at block x?
What I was thinking about was something to reduce the need of multiple parsing engines or the need of processing all MSC transactions. Say there are three specification revisions. Newer clients don't necessarily need to implement the older ones, if they could simply import all historical data up until point X.
You may join the developer group/mailing list. I can't really comment on the rest, because I neither have an insight about what happens behind the curtain nor do I have the authority and general knowledge about how "things are done here". Rephrased: I think you have great ideas, but I don't know how you should and could convert them.
March 25, 2014, 06:44:13 PM
@grazcoin: When trying to do a payment after I accepted an offer I got "Transaction error" after hitting send, when in fact the transaction went through. I tried it two more times and the last one showed Transaction sent
Check transaction: https://blockchain.info/tx/a4197db8c2c9a2d9b1f9985f6b7a5bd0595a82a2533672c6b276971df1df4c60 ,
but actually all 3 transactions went through.
Check transaction: https://blockchain.info/tx/a4197db8c2c9a2d9b1f9985f6b7a5bd0595a82a2533672c6b276971df1df4c60 ,
but actually all 3 transactions went through.
March 25, 2014, 04:46:18 AM
Hi again.
It's clear to me that there is significantly more emphasis placed on development of features and progress towards functional goals than there is on the fundamentals of the Mastercoin system (is Master Protocol applicable here?).
It's clear to me that there is significantly more emphasis placed on development of features and progress towards functional goals than there is on the fundamentals of the Mastercoin system (is Master Protocol applicable here?).
Johnston - could you please set this guy straight? David has all the answers for you.
It is easy to sit around and point to all the shortcomings. Big deal. I can detail all the places I'd like MSC protocol to be better too. But, with the resources they have, they are too busy building the thing.
Imagine a Ferrari - a high performance serious piece of gear. They are busy making the drive train balanced. Then some dick comes up and says: "Hey guys, the paint isn't very nice!" Dude? What are you thinking? "Documentation"? Who's got time for that now? They are all very freaking busy staying up all night to get the thing balanced. They don't care about the paint. That is why Masterchest is so ugly. If you want nice paint, go to NXT. That is all they have.
March 25, 2014, 01:13:39 AM
Hi again.
It's clear to me that there is significantly more emphasis placed on development of features and progress towards functional goals than there is on the fundamentals of the Mastercoin system (is Master Protocol applicable here?). What I mean by this is the development of, for example, the distributed exchange and smart property has been prioritized over providing 1.) comprehensive and accurate documentation, 2.) a method of proof of transaction validity, and 3.) a structure for responsible Master Protocol implementation. I feel like this is primarily a matter of responsibility of the Mastercoin Foundation rather than any particular issue in specific. The funds held by the Mastercoin Foundation place it in an interesting position of responsibility. By creating financial incentive, the Mastercoin Foundation acts like an authority, in certain ways, regarding development and direction. The ability to create (significant) financial incentive in an open source project can have huge benefits, however also appears to carry the implication that potentially critical items, for which incentive is not provided, may not be developed at a satisfactory pace. Thus, a state of fundamental financial security in Mastercoin is deferred to an indefinite point in time because the project has been driven by development, because the specification could not be used as a specification.
This lack of preparedness is now framed by the Mastercoin infrastructure, and all bitcoin used in Mastercoin transactions. The bitcoin developers have been said to be patching the bitcoin-plane in mid flight, if you'll allow me to paraphrase Andreas Antonopoulos. I don't think the state of Mastercoin is far off from this description - in fact may be far worse considering that there is no provable method of transaction validation. The application has far outpaced the fundamentals. As the Shepard to Mastercoin development, it should be the primary goal of the Mastercoin Foundation to establish a structure from which the various implementations and features can flourish. Instead, it seems as if the development of the current implementations was sponsored at the unintentional expense of the core framework.
I've made offers to contribute significant amounts of time towards core work on a structure that defines Mastercoin in a manner that is "hard enforceable." The offers have gone unrecognized, my requests for links to discussion unanswered, and my concerns largely blown off. I recognize that I'm not talking to any single entity that represents Mastercoin, however it stands that the community has largely not responded to any of my concerns in any meaningful fashion. I maintain that I would like to work on a structure that will enable the Mastercoin specification to be "hard enforceable." This is an open offer to enter that conversation with anybody who's interested, and to coordinate with any developers/the Mastercoin Foundation if they find that it may be beneficial.
I've put together the following list to address some items that I believe are currently misrepresenting the state of the project.
Thoughts and input are welcome.
EDIT:
Thanks dexX7. I appreciate your discussion and ideas.
It's clear to me that there is significantly more emphasis placed on development of features and progress towards functional goals than there is on the fundamentals of the Mastercoin system (is Master Protocol applicable here?). What I mean by this is the development of, for example, the distributed exchange and smart property has been prioritized over providing 1.) comprehensive and accurate documentation, 2.) a method of proof of transaction validity, and 3.) a structure for responsible Master Protocol implementation. I feel like this is primarily a matter of responsibility of the Mastercoin Foundation rather than any particular issue in specific. The funds held by the Mastercoin Foundation place it in an interesting position of responsibility. By creating financial incentive, the Mastercoin Foundation acts like an authority, in certain ways, regarding development and direction. The ability to create (significant) financial incentive in an open source project can have huge benefits, however also appears to carry the implication that potentially critical items, for which incentive is not provided, may not be developed at a satisfactory pace. Thus, a state of fundamental financial security in Mastercoin is deferred to an indefinite point in time because the project has been driven by development, because the specification could not be used as a specification.
This lack of preparedness is now framed by the Mastercoin infrastructure, and all bitcoin used in Mastercoin transactions. The bitcoin developers have been said to be patching the bitcoin-plane in mid flight, if you'll allow me to paraphrase Andreas Antonopoulos. I don't think the state of Mastercoin is far off from this description - in fact may be far worse considering that there is no provable method of transaction validation. The application has far outpaced the fundamentals. As the Shepard to Mastercoin development, it should be the primary goal of the Mastercoin Foundation to establish a structure from which the various implementations and features can flourish. Instead, it seems as if the development of the current implementations was sponsored at the unintentional expense of the core framework.
I've made offers to contribute significant amounts of time towards core work on a structure that defines Mastercoin in a manner that is "hard enforceable." The offers have gone unrecognized, my requests for links to discussion unanswered, and my concerns largely blown off. I recognize that I'm not talking to any single entity that represents Mastercoin, however it stands that the community has largely not responded to any of my concerns in any meaningful fashion. I maintain that I would like to work on a structure that will enable the Mastercoin specification to be "hard enforceable." This is an open offer to enter that conversation with anybody who's interested, and to coordinate with any developers/the Mastercoin Foundation if they find that it may be beneficial.
I've put together the following list to address some items that I believe are currently misrepresenting the state of the project.
- Purpose of the specification The purpose of the specification is not currently clear. There are sections that clearly identify supported/recognized functions, and sections that specify transaction types and requirements. There are also sections that are much more "fluffy," with the apparent intent of appealing to readers, or otherwise painting a picture outside the direct goal of defining the Mastercoin ecosystem. Though it may be nice to have an accessible "overview" of Mastercoin, the specification should be largely technical, with verbiage kept to a minimum so as to maintain a focus on the protocol instead of the opinions of the authors.
- State of the specification With implementation largely driven by the results of coordinated development, the specification does not currently serve the purpose of defining either the various implementations, or determining the validity of a Mastercoin transaction. Despite this, the specification is maintained to a certain degree, however the arbiter appears to be consensus. It should be clearly noted what the intent of the specification is, and what purpose the specification currently serves (i.e. documentation trailing development; not to be confused with the previous bullet).
- The term "specification" The word "specification" does not accurately describe the function of the specification. The document should be titled to fill the purpose it is defined as.
- Definition of consensus Until the specification can fill the role of a specification, the factors that determine the validity of a Mastercoin transaction should be identified and detailed. As far as I understand, this is currently consensus between various implementations. Given the decision to discontinue support for the MyMastercoins Wallet, there may soon be one less entity to participate in this consensus. It may prove valuable to define consensus (including any circumstances in which the Mastercoin Foundation does not recognize that which has achieved consensus), and detail a plan to act on in the event of loss of consensus.
- Specification vs. whitepaper Any item that is not recognized as "enabled" or will not be considered valid should be explored in a document more similar to a whitepaper. The specification should define the Mastercoin ecosystem, though that not currently being the case, should act as reference for that which is recognized as valid.
- Risk given flux in specification Holding or transacting in or with Mastercoin can pose a financial risk, due to the fluid nature of that which is considered "valid." A statement should be made or included in documentation regarding the possibility that a transaction will retroactively change states of validity. This statement should also acknowledge the fact that if validity is determined by consensus, there may be circumstances in which the Mastercoin Foundation (or any other party) may not be able to "fix" actions which represent a financial loss in either that of Bitcoin or Mastercoin.
Thoughts and input are welcome.
EDIT:
@LOL: I'll appreciate your feedback very much and will respond soon!
Thanks dexX7. I appreciate your discussion and ideas.
March 23, 2014, 04:31:16 PM
blockchain.info is currently 6 blocks behind.
This is most likely not a reason to worry, because blockchain.info had multiple problems similar to this one in the last weeks.
@LOL: I'll appreciate your feedback very much and will respond soon!
This is most likely not a reason to worry, because blockchain.info had multiple problems similar to this one in the last weeks.
@LOL: I'll appreciate your feedback very much and will respond soon!
March 23, 2014, 03:53:02 PM
this transaction is not yet confirmed in blockchain.org (0 confirmation)
https://blockchain.info/tx/4db98b7d610ed1b7170c7c8e3cd165298801e098e12314004b4d1f25676cc06f
But is already in MasterChain (and MasterChest)
https://masterchain.info/btcpayment.html?tx=4db98b7d610ed1b7170c7c8e3cd165298801e098e12314004b4d1f25676cc06f¤cy=MSC
https://blockchain.info/tx/4db98b7d610ed1b7170c7c8e3cd165298801e098e12314004b4d1f25676cc06f
But is already in MasterChain (and MasterChest)
https://masterchain.info/btcpayment.html?tx=4db98b7d610ed1b7170c7c8e3cd165298801e098e12314004b4d1f25676cc06f¤cy=MSC
It seems blockchain.info is wrong, http://blockr.io/tx/info/4db98b7d610ed1b7170c7c8e3cd165298801e098e12314004b4d1f25676cc06f
TX is confirmed.
The tx is indeed on the blockchain. Also on blockchain's.info, it says that the tx got included on block 291918, but the page claims zero confirmations.
I must say that in the last week or so, I see many problems on blockchain.info, and often they are few blocks behind the real state.
March 23, 2014, 01:26:22 PM
this transaction is not yet confirmed in blockchain.org (0 confirmation)
https://blockchain.info/tx/4db98b7d610ed1b7170c7c8e3cd165298801e098e12314004b4d1f25676cc06f
But is already in MasterChain (and MasterChest)
https://masterchain.info/btcpayment.html?tx=4db98b7d610ed1b7170c7c8e3cd165298801e098e12314004b4d1f25676cc06f¤cy=MSC
https://blockchain.info/tx/4db98b7d610ed1b7170c7c8e3cd165298801e098e12314004b4d1f25676cc06f
But is already in MasterChain (and MasterChest)
https://masterchain.info/btcpayment.html?tx=4db98b7d610ed1b7170c7c8e3cd165298801e098e12314004b4d1f25676cc06f¤cy=MSC
It seems blockchain.info is wrong, http://blockr.io/tx/info/4db98b7d610ed1b7170c7c8e3cd165298801e098e12314004b4d1f25676cc06f
TX is confirmed.
March 23, 2014, 12:36:48 PM
this transaction is not yet confirmed in blockchain.org (0 confirmation)
https://blockchain.info/tx/4db98b7d610ed1b7170c7c8e3cd165298801e098e12314004b4d1f25676cc06f
But is already in MasterChain (and MasterChest)
https://masterchain.info/btcpayment.html?tx=4db98b7d610ed1b7170c7c8e3cd165298801e098e12314004b4d1f25676cc06f¤cy=MSC
https://blockchain.info/tx/4db98b7d610ed1b7170c7c8e3cd165298801e098e12314004b4d1f25676cc06f
But is already in MasterChain (and MasterChest)
https://masterchain.info/btcpayment.html?tx=4db98b7d610ed1b7170c7c8e3cd165298801e098e12314004b4d1f25676cc06f¤cy=MSC
March 22, 2014, 05:37:55 AM
Hello,
I have been recommended by Ron and Dominik to post here and suggest my contribution to the monthly bounty contest for March.
I'm one of the developers behind CoinsManager, a free and Open-source Portfolio. It's very easy to use, and sexy.
All you need is to add your public address, and it will automatically detect everything else: The related coin, the coin balance, and its value in your favorite cryptocurrency. Because Mastercoin shares the same address format as Bitcoin, if you try adding a Mastercoin address, it will ask you to choose the correct coin, here Bitcoin or Mastercoin.
Read more about the project in the press releases.
The beta version is already very usable! Here is an example of a user dashboard:
We started this project a few months ago, because it was hard for us to manage our assets (how much my coins were worth), and we wanted a place to list all our public addresses, easy place to find and copy them instead of re-opening our wallets everytime. After looking up to existing online portfolio, I was very disappointed that they required us a lot of manual input (adding the transactions, or manually adding the number of coins you possess), when it could all be automatized by reading the blockchain.
We have a lot of plans for the futures, you can look into our trello board for all the ideas/features we plan to develop (eg gamification elements). The most ambitious idea is to host our own ledgers for all implemented coins, and build a reactive api on top of those ledgers for a blazingly fast application (basically, the server will tell clients when to update their values, there won't be anymore need for the client to query the server at regular intervals to ask for changes).
Because we like free and open-source, and do not like ads, we completely rely on donations to pay for the infrastructure and support the developers, and contributions (cf our online doc and youtube screencasts).
A bounty from the Mastercoin foundation would be very welcome. You can send coins to 1CoinsMPAy5Mz5SVzeAmU6qNmUThiLXYv1 and give extra visibility to Mastercoin in our application.
Thank you for your interest and support!
I have been recommended by Ron and Dominik to post here and suggest my contribution to the monthly bounty contest for March.
I'm one of the developers behind CoinsManager, a free and Open-source Portfolio. It's very easy to use, and sexy.
All you need is to add your public address, and it will automatically detect everything else: The related coin, the coin balance, and its value in your favorite cryptocurrency. Because Mastercoin shares the same address format as Bitcoin, if you try adding a Mastercoin address, it will ask you to choose the correct coin, here Bitcoin or Mastercoin.
Read more about the project in the press releases.
The beta version is already very usable! Here is an example of a user dashboard:
We started this project a few months ago, because it was hard for us to manage our assets (how much my coins were worth), and we wanted a place to list all our public addresses, easy place to find and copy them instead of re-opening our wallets everytime. After looking up to existing online portfolio, I was very disappointed that they required us a lot of manual input (adding the transactions, or manually adding the number of coins you possess), when it could all be automatized by reading the blockchain.
We have a lot of plans for the futures, you can look into our trello board for all the ideas/features we plan to develop (eg gamification elements). The most ambitious idea is to host our own ledgers for all implemented coins, and build a reactive api on top of those ledgers for a blazingly fast application (basically, the server will tell clients when to update their values, there won't be anymore need for the client to query the server at regular intervals to ask for changes).
Because we like free and open-source, and do not like ads, we completely rely on donations to pay for the infrastructure and support the developers, and contributions (cf our online doc and youtube screencasts).
A bounty from the Mastercoin foundation would be very welcome. You can send coins to 1CoinsMPAy5Mz5SVzeAmU6qNmUThiLXYv1 and give extra visibility to Mastercoin in our application.
Thank you for your interest and support!
March 22, 2014, 04:00:07 AM
So did something go wrong with the dev-mastercoin send? Because all bounty addresses seem to be out of consenus.
@masterchain.info: When trying to add another address to my wallet, my wallet got deleted. I think the UUID is still the same(815369f9-6558-4a30-b29e-04e413bd64f5), but no addresses are shown anymore. 'Sync with server' doesn't seem to do anything.
@masterchain.info: When trying to add another address to my wallet, my wallet got deleted. I think the UUID is still the same(815369f9-6558-4a30-b29e-04e413bd64f5), but no addresses are shown anymore. 'Sync with server' doesn't seem to do anything.
March 21, 2014, 09:45:49 PM
Quote
1. Snapshots
After a specification change, a time span, a number of transactions or whatsoever the current state of the Mastercoin ecosystem should be stored in an agreed upon format. This should include all balances and may include open orders, if a snapshots is going to allow to restore a state. The correctness of a snapshot must be confirmed by several parties and finally sealed by some higher authority. The data provided by a sealed snapshot shall never be challenged and has the highest power of ruling. No user shall ever fear that a change affect the past. (note: this is always high priority and nothing new!)
After a specification change, a time span, a number of transactions or whatsoever the current state of the Mastercoin ecosystem should be stored in an agreed upon format. This should include all balances and may include open orders, if a snapshots is going to allow to restore a state. The correctness of a snapshot must be confirmed by several parties and finally sealed by some higher authority. The data provided by a sealed snapshot shall never be challenged and has the highest power of ruling. No user shall ever fear that a change affect the past. (note: this is always high priority and nothing new!)
Can you point me to discussions had on this subject? I'm interested to know if any discussed ideas allow a snapshot to be referenced without developer involvement.
Ideally a system could be implemented that only requires a single snapshot at the implementation of a specification revision control system, to validate transactions occurring before that point in time. Of course, more may be necessary if a disaster situation ever occurs in which consensus is violated, or a revision has unintended consequences etc. Regardless, I'd imagine that snapshots are far less manageable than a set of rules that could define validity of transactions in prior revisions, and I fear that snapshots may pose scalability issues.
Quote
2. Checkpoints
Snapshots should be explicitly used to verify an application.
Snapshots should be explicitly used to verify an application.
I feel like this may be challenging in terms of upkeep, and scalability.
Quote
3. Reference documentation
The specification is great, but I'm not yet sure how it could be used as some kind of reference for different versions of specific transaction types and similar. Commit numbers may be used, but I think in the best case there were some additional isolated and very short formal definitions which precisely define the different transactions at a given version and the changes made to previous ones. If I'd like to lookup something of the past, I'd probably need to invest some time for extracting all details from different places. Pseudo code or isolated reference implementation snippets may be used. Use-case and goal: "I want to lookup the policies applied prior snapshot 123.. ah, input is defined as.., only Exodus output allowed, otherwise invalid, 1-of-3 multisig, second and third multisig output is encoded data, ...".
The specification is great, but I'm not yet sure how it could be used as some kind of reference for different versions of specific transaction types and similar. Commit numbers may be used, but I think in the best case there were some additional isolated and very short formal definitions which precisely define the different transactions at a given version and the changes made to previous ones. If I'd like to lookup something of the past, I'd probably need to invest some time for extracting all details from different places. Pseudo code or isolated reference implementation snippets may be used. Use-case and goal: "I want to lookup the policies applied prior snapshot 123.. ah, input is defined as.., only Exodus output allowed, otherwise invalid, 1-of-3 multisig, second and third multisig output is encoded data, ...".
I was thinking about something similar as I was submitting my pull request. Maybe it's not necessary to revise the entire specification if only one or two small changes are made. If different sections are broken out one can submit pull requests for items that don't warrant an entire specification revision, and changes can be discussed in a context more relevant to the issue at hand.
If we consider the specification a dataset instead of a specific document, it may be reasonable to precisely define a type of transaction as a data point and discrete unit, and consequently revise that definition independently of any other definition. This also allows all changes to a specific definition to be queried, and a "timeline" built of changes relevant to a specific transaction type.
Maybe a crazy idea, but why not use Master Protocol itself to store the specification? For the sake of opening up a discussion on the subject, consider if a transaction definition could be stored in the blockchain. Not only is it universally publicly accessible and immutable, but a standardized dictionary could theoretically allow a client to programatically and dynamically verify the validity of a transaction based on the relevant definition at the time. I have experience designing and implementing relational databases and would be thrilled to contribute if others think that this may be worth pursuing. I'm not under the impression that it's an easy task, but then again, neither was a distributed exchange.
Quote
4. Define how changes are pushed
Process.md describes the process of making changes to the Mastercoin specification. This document may be expanded to a more detailed "step-by-step" process guide similar to Bitcoin's release-process.md but related to sealing snapshots and pushing updates.
Process.md describes the process of making changes to the Mastercoin specification. This document may be expanded to a more detailed "step-by-step" process guide similar to Bitcoin's release-process.md but related to sealing snapshots and pushing updates.
I agree. The specification feels too easy to manipulate right now, IMO. The revision procedure should detail the steps taken to ensure that the implications of a change are known, and that there are no unforeseen consequences that could compromise funds or security. This would be a great place to discuss results of test cases which you discuss below.
Quote
5. Test cases
With clear implementation guidelines it may be easier to run wide scale tests. I'm not sure, if this is done at the moment, but I'm thinking about things like "scan the chain for all transactions with unordered data-packages to get an overview about what the implications were, if an order would be enforced". (I'm not good at making up examples - ) Rephrased: if a change is pushed, evaluate all consequences. Run different settings, create test-snapshots etc.
With clear implementation guidelines it may be easier to run wide scale tests. I'm not sure, if this is done at the moment, but I'm thinking about things like "scan the chain for all transactions with unordered data-packages to get an overview about what the implications were, if an order would be enforced". (I'm not good at making up examples - ) Rephrased: if a change is pushed, evaluate all consequences. Run different settings, create test-snapshots etc.
I think there's a lot of value in a program/script that could scan the blockchain and output a list of x based on parameters y, and z. For example, transactions with outputs to the Exodus address, or more complex, transactions with outputs to Exodus address with a multisignature output that is not definitively spendable by the sending address or 2nd key pair created from associated (hex) private key. A tool of this nature would allow one to determine how "ready" various implementations are to transition to a new transaction definition, for example.
If a functional and usable language could be used to write a query, a tool of this nature could be revolutionary for bitcoin protocol layers, let alone for blockchain data analysis.
Quote
6. Transaction archival
Instead of storing only a current state, historical transactions may be stored and sealed similar to snapshots, e.g.:
Instead of storing only a current state, historical transactions may be stored and sealed similar to snapshots, e.g.:
Code:
[{
"basetx": "98419d8b3056ce50aa63d1f464555e038ae517996ac6ec13bfd8c26689f5bece",
"input": "1NqkqJkGCA7HJkBQqJrRvJCDCLAnQndw7",
"reference": "1MaStErt4XsYHPwfrN9TpgdURLhHTdMenH",
"datahex": "0000000000000001000000012a05f200"
}, {
"basetx": "cc70f686b1402d092da400f817133b07d774b3d9791564dc6efee8dbd0a54a1d",
"input": "1Foh78nqSDzrAncvTCCqtFSzz143CsGdcz",
"datahex": "00010014000000010000000023c346000000000005e69ec0020000000000003a9801"
}]IMO, this is unnecessary. I don't see any reason why a properly formed transaction definition shouldn't be able to determine validity of all applicable transactions. Archival could imply more limitations than the benefit gained by ease of gathering examples. Maybe your concern here could be appeased with the ability to prove a transaction types definition at block x?
March 21, 2014, 12:24:49 AM
I was thinking about all this a bit more. Some of this was suggested earlier:
1. Snapshots
After a specification change, a time span, a number of transactions or whatsoever the current state of the Mastercoin ecosystem should be stored in an agreed upon format. This should include all balances and may include open orders, if a snapshots is going to allow to restore a state. The correctness of a snapshot must be confirmed by several parties and finally sealed by some higher authority. The data provided by a sealed snapshot shall never be challenged and has the highest power of ruling. No user shall ever fear that a change affect the past. (note: this is always high priority and nothing new!)
2. Checkpoints
Snapshots should be explicitly used to verify an application.
3. Reference documentation
The specification is great, but I'm not yet sure how it could be used as some kind of reference for different versions of specific transaction types and similar. Commit numbers may be used, but I think in the best case there were some additional isolated and very short formal definitions which precisely define the different transactions at a given version and the changes made to previous ones. If I'd like to lookup something of the past, I'd probably need to invest some time for extracting all details from different places. Pseudo code or isolated reference implementation snippets may be used. Use-case and goal: "I want to lookup the policies applied prior snapshot 123.. ah, input is defined as.., only Exodus output allowed, otherwise invalid, 1-of-3 multisig, second and third multisig output is encoded data, ...".
Some more lower priority stuff:
4. Define how changes are pushed
Process.md describes the process of making changes to the Mastercoin specification. This document may be expanded to a more detailed "step-by-step" process guide similar to Bitcoin's release-process.md but related to sealing snapshots and pushing updates.
5. Test cases
With clear implementation guidelines it may be easier to run wide scale tests. I'm not sure, if this is done at the moment, but I'm thinking about things like "scan the chain for all transactions with unordered data-packages to get an overview about what the implications were, if an order would be enforced". (I'm not good at making up examples - ) Rephrased: if a change is pushed, evaluate all consequences. Run different settings, create test-snapshots etc.
6. Transaction archival
Instead of storing only a current state, historical transactions may be stored and sealed similar to snapshots, e.g.:
1. Snapshots
After a specification change, a time span, a number of transactions or whatsoever the current state of the Mastercoin ecosystem should be stored in an agreed upon format. This should include all balances and may include open orders, if a snapshots is going to allow to restore a state. The correctness of a snapshot must be confirmed by several parties and finally sealed by some higher authority. The data provided by a sealed snapshot shall never be challenged and has the highest power of ruling. No user shall ever fear that a change affect the past. (note: this is always high priority and nothing new!)
2. Checkpoints
Snapshots should be explicitly used to verify an application.
3. Reference documentation
The specification is great, but I'm not yet sure how it could be used as some kind of reference for different versions of specific transaction types and similar. Commit numbers may be used, but I think in the best case there were some additional isolated and very short formal definitions which precisely define the different transactions at a given version and the changes made to previous ones. If I'd like to lookup something of the past, I'd probably need to invest some time for extracting all details from different places. Pseudo code or isolated reference implementation snippets may be used. Use-case and goal: "I want to lookup the policies applied prior snapshot 123.. ah, input is defined as.., only Exodus output allowed, otherwise invalid, 1-of-3 multisig, second and third multisig output is encoded data, ...".
Some more lower priority stuff:
4. Define how changes are pushed
Process.md describes the process of making changes to the Mastercoin specification. This document may be expanded to a more detailed "step-by-step" process guide similar to Bitcoin's release-process.md but related to sealing snapshots and pushing updates.
5. Test cases
With clear implementation guidelines it may be easier to run wide scale tests. I'm not sure, if this is done at the moment, but I'm thinking about things like "scan the chain for all transactions with unordered data-packages to get an overview about what the implications were, if an order would be enforced". (I'm not good at making up examples - ) Rephrased: if a change is pushed, evaluate all consequences. Run different settings, create test-snapshots etc.
6. Transaction archival
Instead of storing only a current state, historical transactions may be stored and sealed similar to snapshots, e.g.:
Code:
[{
"basetx": "98419d8b3056ce50aa63d1f464555e038ae517996ac6ec13bfd8c26689f5bece",
"input": "1NqkqJkGCA7HJkBQqJrRvJCDCLAnQndw7",
"reference": "1MaStErt4XsYHPwfrN9TpgdURLhHTdMenH",
"datahex": "0000000000000001000000012a05f200"
}, {
"basetx": "cc70f686b1402d092da400f817133b07d774b3d9791564dc6efee8dbd0a54a1d",
"input": "1Foh78nqSDzrAncvTCCqtFSzz143CsGdcz",
"datahex": "00010014000000010000000023c346000000000005e69ec0020000000000003a9801"
}] March 20, 2014, 12:06:50 AM
Say the protocol would adapt a more strict output policy (e.g. only a valid pub key of the sender + data-packages are allowed)
Sorry for another post.
A few different things going on here. This is in response to Class B "output policy."
First of all, it's unclear to me which Class B transactions are valid because the mastercoin implementations do not follow the requirements of the specification. Second, it doesn't matter what the policy is regarding the validity of a Class B transaction, it's only necessary that implementations have consensus, and that consensus is modeled after the specification. Third, despite the overarching importance of that which is described in my previous point, policy regarding validity of Class B transactions should be specified in a manner which is beneficial to the user or minimizes the detrimental impact on the user.
Fourth, the flexibility of Class B transactions directly affects the ability to spend a P2SH output, and the likelihood that it will be spent. Fifth, policy regarding valid Class B transactions should be based on the balance struck between the Mastercoin Foundation's willingness to recognize transactions that are, or may be, directly detrimental to the blockchain, and whatever benefit is found in flexibility. Finally, however valid Class B transactions may be defined, a wallet should always create P2SH outputs that will be spent by the wallet from which it originated.
tl;dr Flexibility is okay. Wallets that create outputs that it cannot or will not spend are not okay.
Jump to: