Happy to peer review. I dont fully understand the inbuilt betting.
The layer, lays a bet such as Gold Price @ 2:1. These odds then remain fixed? So the backer could then wait n days, if gold prices raise the backer is getting better odds?
Any odds/offers published would need to be maintained and updated or removed if no longer valid, in the same way as anyone offering betting services online has to keep on top of the odds they offer. This is a necessary and vital facility. Where it gets interesting is if a major event occurs which significantly changes the odds of an event occurring whilst an offer is live, we might see the bet provider racing to close/adjust an offer whilst a flood of bet matches are submitted - with the outcome (bet filled or bet adjusted) potentially being determined by nothing more than the order of transactions within the next block. That is absolutely correct  It will be interesting to see all the repercussions. |
|
|
|
GO AWAY
It's Bitcointalk not Altcoin or freelancer or some coding central forum.
Doesn't this belong in the alt-coin forum with the rest of the alt-coin stuff?
Thanks for your interest in my project. MasterCoin is a bitcoin project built on top of bitcoin, making bitcoin more valuable and useful. The mods have (so far) allowed MasterCoin to stay here, where I believe it belongs. I hope you'll forgive me for deleting your posts - I don't want to distract from the purpose of this thread. |
|
|
|
Now, breaking down the transaction data, we have:
81 = sequence number, which is one less than the same byte of the reference address, which is 0x82
In spec 1.1 you say: "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". On your first ever transaction (quote above) I see that the data has sequence number (81) which is lower than the one of the reference (82). How come? Because the spec has an error which I need to fix in the next rev Here's my explanation of how that happened which I gave to maraoz a couple days ago when he asked me the same thing: Why does Mastercoin Advisor use a data sequence number lower than the recipient sequence number? Shouldn't it be the successor of the recipient sequence number, as the protocol specifies? recipientSequenceNum = ord(recipientBytes[1])
dataSequenceNum = recipientSequenceNum - 1
if dataSequenceNum < 0:
dataSequenceNum = dataSequenceNum + 256
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. Any
additional data packets can continue to use up sequence numbers n+2, n+3, and so on until all sequence
numbers are used except for n-1.
As an example of how this works, let's imagine a MasterCoin transaction that has two data packets. If
the reference address happens to have a sequence number of 62, then the first data packet has a
sequence number of 63 and the second has a sequence number of 64. Note that sequence number 255
is followed by 0.
Aw crap. I meant to update the spec to change how the sequence numbers worked. Thanks for catching that. When I was writing the code for MasterCoin Adviser, it occurred to me that it might be easier to parse MasterCoin transactions if the first data packet had the first sequence number, then additional data packets following, and then the reference packet last, with the last sequence number. But I never went back and updated the spec to reflect that change. I made that change because I thought it might help if we ever had transactions with data but no reference address. |
|
|
|
I added some sidebar links to our subreddit: http://www.reddit.com/r/mastercoin/If I missed anything important, please let me know. I can't offer a bounty for it, but if somebody wants to take a crack at a reddit-style logo for MasterCoin, that would be fun to have. Usually such a logo would have the reddit alien in it. Maybe the reddit alien getting irradiated by MasterCoin, since our logo looks kind of like the radiation symbol  Maybe that's too unprofessional. I dunno . . . |
|
|
|
I won't be surprised. Parasites always morph and change as the host evolves.
Yes, that's something like what I have in mind, although long-term, we hope to be mitochondria, not tape worms |
|
|
|
I'm totally cool with stuffing the data in alternate places once we have our own client. I see using unspendable transactions as a "crutch" so that the protocol works until we get to that point. For instance, right now none of the existing bitcoin clients has functionality that will let an average user hide data in OP_CHECKMULTISIG.
It is inevitable that in the future, bit coin does prevent the permanent storage of arbitrary data in the blockchain. If you rely on such features now, there could be colossal consequences later. #bitcoin wont care about you or your bitcoin-bloat. BE WARE, YOU HAVE BEEN WARNED. MasterCoin hopes to be symbiotic with bitcoin, not parasitic, and we plan to morph and change to whatever degree is needed as bitcoin morphs and changes. If our old data gets pruned out of the block-chain used by most bitcoin clients, our clients will have to be modified to keep different parts of the block chain, and use different pruning techniques. Nothing I can foresee leaves MasterCoin completely stranded or unusable. |
|
|
|
I just got this interesting PM from an interested party (I've removed their name since they chose to share this concern privately): Hey J.R. Something is bothering me about the contest and I wanted to discuss this with you. Although the contest is a great thing I'm afraid that without a proper way of encoding Mastercoin data a lot of the time and energy of developers is going to waste. People will probably build all sorts of cool stuff based on the current encoding standard (Bitcoin address for data) but once a new way, hopefully multisig, of encoding is in place all these projects become obsolete unless the author is going to keep supporting it. The question is if they will continue to support their code after they already received the bounty. Going to encode data in multisig transactions is harder because you need to dive a level deeper into the Bitcoin protocol leaving the address codebase behind and diving into scripting. The amount of people who can solve this problem is significantly smaller then the amount who can use a library that does the multisig encoding and build awesome stuff on top of it. I would have advised you to hold off on the contest until a developer came forward with a new encoding spec so that all the tools build in the contest would be here to last. I can imagine that you don't want to pause the contest anymore at this point, although I hope you might consider it. An other option might be to set a specific bounty for multisig encoding to try and make sure this is the first thing that gets released so other tools can build on top of this. I know maraoz is working on multisig encoding and you might poke him to see if he is making progress on this. If so this whole pm might be moot Anyway; just my two cents! Regards, ----- This is definitely a concern. However, there are a number of things I am counting on to hopefully mitigate this risk: - We will always support simple-send using the current method, because people need a way to move money out of standard bitcoin wallets into full-featured MasterCoin wallets
- We will NOT be accepting projects which implement new features using the existing methods
- Since all projects must have their source-code released, even if the developer abandons the project, someone else can pick it up
- If somebody releases a library with a method for better encoding of our data early on in the contest, and lots of people use it, that person will definitely be rewarded for their efforts (hint hint)
- Since the rewards will be distributed according to our impression of the overall value of each project, projects which store our data in a new way and projects which build on that method get a pretty big bonus over those which don't. People who put a lot of effort into elaborate systems using the old method may be disappointed with what they get
- This is probably, hopefully, not our last coding contest
I hope that helps. I'm definitely open to modifying the contest rules to make sure the right work gets done! |
|
|
|
Heh. I was originally thinking 6 years when I calculated that number, then decided that nobody needed a reversibility period quite that long. I changed the number of days but didn't recalculate the number of seconds. Thanks for catching that! |
|
|
|
Coding Contest LAUNCHED on this separate thread: https://bitcointalk.org/index.php?topic=292628.0Here's the quote from the OP of that thread, although note that I'm not planning on updating this quote if I update the OP of that thread: If you've been living under a rock, you may not know that we recently raised over half a million dollars to build a new protocol layer on top of bitcoin. The new layer is NOT an alt-chain currency - it's built right on top of bitcoin, and is called "MasterCoin" (not to be confused with the alt-chain currency of the same name). You can read all about it here: https://bitcointalk.org/index.php?topic=265488.0A few days ago, I pre-announced that we would be doing a major coding contest, with total prizes adding up to $25000 ( https://bitcointalk.org/index.php?topic=265488.msg3065262#msg3065262). The goals of the contest are to spur development on the MasterCoin protocol layer, and to hopefully find at least one person to be our first full-time hire. This thread is devoted to that contest. Following are the official rules, subject to change if deemed necessary: - ALL serious entries will win a prize (although some prizes may be very small)
- Prize money will be divvied up by myself, with input from the community and the board of the MasterCoin Foundation, based primarily on how useful and valuable your code is to the success of our protocol layer
- In addition to the overall impact and value of your code, other important things will be taken under consideration:
- How often you post updates in this thread or the main project thread. Ideally, you should post what you plan to do, and then post extremely frequent updates as you make progress.
- Ease of use and testability. If you just dump some source code on me at the end of the contest with a bunch of grandiose claims, you may not get much. Ideally, you should be posting demos, screenshots, and/or set up a website demonstrating your code.
- Collaboration. If you are helping other people working on MasterCoin projects, that will weigh favorably on how much you win. If you release your source code early and other people build on it, that will weigh even more favorably.
- Breaking new ground, or being redundant. Doing something new is awesome, but you will NOT be penalized for implementing the same thing as someone else. We need redundancy for cross-checking. We have the following feature needs:
- Better ways to store (and then retrieve) MasterCoin data. Gavin has told us there are multiple better ways, and there has been some discussion of how to do it on this thread: https://bitcointalk.org/index.php?topic=284178.0
- Reusable libraries for parsing MasterCoin transactions in the block chain, and for generating them
- PC wallets for MasterCoin
- Web wallets for MasterCoin
- Implementing advanced features, as defined in the spec. (But please don't implement new features using the existing "data address" method of storing data in the block chain - we need to look for a better way to store our data first)
- Only open-source projects will be considered for a prize. You must release your source code before the end of the contest to be eligible.
- Getting the biggest prize in this contest does NOT guarantee you a job, but having some kind of entry in this contest will help your chances a lot.
- Contest ends October 15th, 2013, with prizes paid out once the dust settles.
- Prizes will total $25000 USD, payable in bitcoins according to the exchange rate at that time.
- Contestants may elect to take some or all of their prize money in MasterCoins if desired. (We'll purchase them on the open market for you, using the bitcoins we would have paid you)
You should be aware that multiple projects eligible for entry into this contest are already started, and have made amazing progress. When I first contemplated a $25000 payout, it seemed like a huge sum, but given how many people are enthusiastically working on MasterCoin projects, you may be disappointed with the prize you get for your efforts. There is a lot of amazing work going forward extremely rapidly, as you can see on the project thread. By the end of the contest, I doubt that anybody's prize will be "fair" for the effort they put in. We'll have to just hope that it is a nice bonus for working on a fun project. I'll update this post soon with a link to a job description of the full-time job we will be hoping to fill, hopefully we'll fill the position with someone who enters this contest. . . . and true to form, I'm now going offline for awhile. I'll try to catch up on any questions about the contest tomorrow. |
|
|
|
This thread has MOVED to MastercoinTalk: http://mastercointalk.org/index.php?topic=297.0Thread is now locked. Please join us on the Mastercoin Forum!! If you've been living under a rock, you may not know that we recently raised nearly 5000 BTC to build a new protocol layer on top of bitcoin. The new layer is NOT an alt-chain currency - it's built right on top of bitcoin, and is called "MasterCoin" (not to be confused with the alt-chain currency of the same name). You can read all about it here: https://bitcointalk.org/index.php?topic=265488.0A few days ago, I pre-announced that we would be doing our second major coding contest, with total prizes adding up to 300 BTC ( https://bitcointalk.org/index.php?topic=265488.msg3358444#msg3358444). The goal of this contest is to implement a distributed bitcoin/mastercoin exchange. NOBODY has ever made a distributed exchange between two digital currencies, and we aim to do it first. We are also still looking for our first full-time hire, hopefully recruited from among the contestants. This thread is devoted to the current MasterCoin contest (this thread was originally for contest #1). Following are the official rules of the current contest, subject to change if deemed necessary: Official Rules- ALL serious entries will win a prize (although some prizes may be very small)
- Prize money will be divvied up by myself, with input from the community and the board of the MasterCoin Foundation, based primarily on how useful and valuable your code is to accomplishing the goals of the contest
- In addition to the overall impact and value of your code, other important things will be taken under consideration:
- How often you post updates in this thread. Ideally, you should post what you plan to do, and then post extremely frequent updates as you make progress.
- Ease of use and testability. If you just dump some source code on me at the end of the contest with a bunch of grandiose claims, you may not get much. Ideally, you should be posting demos, screenshots, and/or set up a website demonstrating your code.
- Collaboration. If you are helping other people working on MasterCoin projects, that will weigh favorably on how much you win. If you release your source code early and other people build on it, that will weigh even more favorably.
- Note that contest contestants will give me feedback on each other, and that feedback will be heavily considered when making payouts (so be nice to each other!)
- If somebody forks your code, and builds on it, you will get some consideration at payout time, even if you did nothing in the current contest.
- Breaking new ground, or being redundant. Doing something new is awesome, but you will NOT be penalized for implementing the same thing as someone else. We need redundancy for cross-checking.
- Only open-source projects will be considered for a prize. You must release your source code before the end of the contest to be eligible.
- Getting the biggest prize in this contest does NOT guarantee you a job, but having some kind of entry in this contest will help your chances a lot.
- Contest ends once all acceptance criteria have been met (see below), with prizes paid out once the dust settles.
- Prizes will total 300 BTC, regardless of the current price of bitcoins
- 200 BTC will be split up among contributing developers
- 100 BTC will be split up among anybody who helped by doing code reviews, testing, and bug reporting (this may be the same people as the developers, or different people)
- Contestants may elect to take some or all of their prize money in MasterCoins if desired. (We'll purchase them on the open market for you, using the bitcoins we would have paid you)
Acceptance criteria:- Minimum one PC wallet (for both Linux and Windows) which can generate simple sends and the buy/sell messages required for the distributed exchange, using agree-upon multisig format
- Minimum two websites parsing such messages, and the resulting balance transfers
- Minimum one website showing BTC/MSC price charts derived from these messages
- Minimum 10 days of real-world usage with no major problems
- High bar for usability. (Current heavy traders like maxmint, lishbtc, and buymastercoin should be happy with the final product, if at all possible)
This thread is for development-related discussion ONLY. If you want to discuss MasterCoin in ways not related to our development effort, please do so here: https://bitcointalk.org/index.php?topic=265488.0Posts immediately below are from the first contest. Discussion regarding work on the current contest starts here: https://bitcointalk.org/index.php?topic=292628.msg3381794#msg3381794Thanks, and good luck! Important update: We'll be paying out half of this bounty early (on 1/22/2014). Details here: https://bitcointalk.org/index.php?topic=292628.msg4398023#msg4398023Another important update: the remainder of this bounty will be paid out in monthly chunks until we are done. Details here: https://bitcointalk.org/index.php?topic=292628.msg4921986#msg4921986 |
|
|
|
In the interest of full transparency, here is the updated expenditure list I sent to the board just now. Hopefully I can process refunds tomorrow. We've decided to set the cutoff date for investments a couple blocks later in order to accommodate some people who sent before the deadline, but did not get included in a block until after the deadline. Consequently, the expenditure list has changed slightly. Here's the final list of transactions which I hope to execute soon, probably tomorrow: 13.279 BTC in refunds to investors who missed the deadline (addresses and details here: https://docs.google.com/spreadsheet/ccc?key=0AnnInaIJVqrtdGMteFNOWjBpWTNqd3BYbWUzdGVLMmc#gid=0) 3 BTC bounty to bytemaster (1Nou27Zt2k3yTFHw6yePg3A1df2ohCTFFb per his PM to me) as a bounty for their work exposing a flaw in my spec. (details here: https://groups.google.com/d/msg/mastercoin/EQgEHvKJBh4/4VeE3a02I3QJ) 3 BTC to d'aniel as part of the same bounty. D'aniel requested that his prize go to forum member gmaxwell: 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB, request is here: https://bitcointalk.org/index.php?topic=284178.msg3041300#msg3041300) 2 BTC to mich for the awesome logo (13x2dka6tVhjsNNNomGJjUPi2iJQCb67bw, verified by him) 0.1 BTC to Ron to reimburse his purchase of MasterCoin.org (1HfXDX3ALapNebQC8stTdd5zK7kiCgvX9n) Total expenditures: 21.379 BTC Aside from the changes to the refund list, this is the same list of expenditures as before, so I don't expect comments - I'm just keeping you guys in the loop. Thanks! -J.R. If you are expecting a refund, please check the spreadsheet linked above and make sure it looks correct. Thanks! This transaction has now been broadcast. Considerable money left the Exodus Address, but most of it came back to the same offline wallet as change (14JnZjp1HXgVKy8CKo2VkiD4vQM69nQrFN) TX can be viewed here: http://blockchain.info/tx/99160b37b3294eebc83bd8ff44849c813d2e9da986a25fb127b0c5915e799c0a |
|
|
|
No thank you. I think your unsolicited self promotion is of benefit to this project, regardless of what the other forum members may say. I too am an entrepreneur. I think we all are. In fact, this whole project is based on "hiding MasterCoin Protocol Data in the Block Chain" which other people disagree with doing.
Cheers.
I was confused by this post, and read it like 10 times before I finally figured out that that I was reading the first sentence with the wrong emphasis. "No thank you!" vs "No, thank you" |
|
|
|
But test mastercoins were released together with real mastercoins simultaneously. As far as I understand, you can do the same thing with test coins as with real coins. So, if there will be an exchange trading them in the future, they WILL be useful, and you can trade them back to bitcoins or whatever and buy something with it.
Still not different from testnet bitcoins. There are so many other cryptocurrencies with hardly any innovation in them, but still they have some value, because you can exchange them with other currencies.
These alts have people advocating their use, which results in people speculating they have a chance to catch on (and they still capture only a small percentage of Bitcoin's market cap). For test coins you have no such thing. Actually, what you're doing right here is a form of advocacy that testcoins should be used. Keep doing that and you might fulfill your prophecy. I just wanted to mention this possibility, because ultimately, test coins might lower the value of real coins because of more supply. So it might be good to destroy them at some point, before it's too late. And of course let people know early enough about that action. I think this helps, because people can actually treat them as test coins and therefore also 'waste' them for testing purpuses.
Test mastercoins are effectively a clone of mastercoins. If you fear that mastercoins can lose their value due to the existence of a clone, and clones are trivial to create, why do you think mastercoins can have any value at all? We already have existing test cases for all of this. For instance, bitcoin has testnet coins, which do have some value (while they are frequently given away, they CAN be bought and sold). And bitcoin has plenty of clones. I don't see any reason things won't play out any differently for MasterCoin, although I actually expect we are more vulnerable to clones than bitcoin, since MasterCoin is just so darn easy to understand and implement and improve upon. You don't need to understand cryptography to improve on MasterCoin (I still have a lot to learn myself in fact). All you need is to be able to think of nifty things to do with messages. That's it. The distributed exchange described in our spec is ridiculously, stupidly simple. The distributed betting on data feeds are equally simple. It took me about 20 minutes and less than a page to describe how to create smart property for IPOs and titles/deeds in our most recent spec. That's one reason I'll be watching clones closely, looking for good ideas to steal I've said this many times before: I just can't understand why someone hasn't done this already. It just seems too easy. (Although maybe it just seems that way to me since I have been thinking about it constantly for a couple of years now) |
|
|
|
Regarding using 0.0006 instead of 0.00006, that is a perfectly valid transaction. The only real constraint is that the amounts must all be the same in the transaction, and be above the dust threshold. The guys on the buyer/seller thread came to the same conclusion, and I confirmed it there too. Requiring the amounts to all be the same is important, since it reduces the likelihood that the change address will get confused with the reference address or the data address and make an invalid transaction. Speaking of that situation, I don't know if current implementations do this, but if there is any ambiguity about which address is change, the transaction should be treated as invalid. Otherwise we risk making a different transaction than intended! It might be interesting to try to set up some transactions which have change coming back in the amount of 0.00006 BTC, to see what happens |
|
|
|
Yeah that transaction should be fine, for all the reasons you guys worked out -J.R. |
|
|
|
According to the discussion I had with J.R. the address that spend the most coins for a given transactions receives the coins.
such an agreement should go to the spec, but generally I see no problem with dividing the mastercoins in a fair way between the contributing addresses. This solves the theoretical problem of few addresses that sent the same amount of bitcoins. I agree, but this is what J.R. told me. Could we get a clarification on this J.R.? Yup, biggest contributor gets the coins. I believe the latest rev of the spec now says this explicitly. This is a convenience for the user, especially those that bought from twenty different addresses at once. I know it makes the parsing a bit trickier . . . |
|
|
|
I approve this thread Here's a copy of my question from the MasterCoin project thread: I'm trying to understand your suggestion about a package with a live update. Are you suggesting that MasterCoin clients should decouple from the block chain completely and rely on a vetted record of transactions? If so, that would seem to lose our decentralization. If not, what are you suggesting? Thanks! |
|
|
|
In the interest of full transparency, here is the updated expenditure list I sent to the board just now. Hopefully I can process refunds tomorrow. We've decided to set the cutoff date for investments a couple blocks later in order to accommodate some people who sent before the deadline, but did not get included in a block until after the deadline. Consequently, the expenditure list has changed slightly. Here's the final list of transactions which I hope to execute soon, probably tomorrow: 13.279 BTC in refunds to investors who missed the deadline (addresses and details here: https://docs.google.com/spreadsheet/ccc?key=0AnnInaIJVqrtdGMteFNOWjBpWTNqd3BYbWUzdGVLMmc#gid=0) 3 BTC bounty to bytemaster (1Nou27Zt2k3yTFHw6yePg3A1df2ohCTFFb per his PM to me) as a bounty for their work exposing a flaw in my spec. (details here: https://groups.google.com/d/msg/mastercoin/EQgEHvKJBh4/4VeE3a02I3QJ) 3 BTC to d'aniel as part of the same bounty. D'aniel requested that his prize go to forum member gmaxwell: 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB, request is here: https://bitcointalk.org/index.php?topic=284178.msg3041300#msg3041300) 2 BTC to mich for the awesome logo (13x2dka6tVhjsNNNomGJjUPi2iJQCb67bw, verified by him) 0.1 BTC to Ron to reimburse his purchase of MasterCoin.org (1HfXDX3ALapNebQC8stTdd5zK7kiCgvX9n) Total expenditures: 21.379 BTC Aside from the changes to the refund list, this is the same list of expenditures as before, so I don't expect comments - I'm just keeping you guys in the loop. Thanks! -J.R. If you are expecting a refund, please check the spreadsheet linked above and make sure it looks correct. Thanks! |
|
|
|
1404.27673743 would be too low. I assume you mean mastercoin-tools calculates 1504.27673743 instead of 1504.69444445? I'm trying to understand your suggestion about a package with a live update. Are you suggesting that MasterCoin clients should decouple from the block chain completely and rely on a vetted record of transactions? If so, that would seem to lose our decentralization. If not, what are you suggesting? edit: I also posted this question to your mastercoin-tools thread |
|
|
|
|
Show Posts
