I think perhaps it is time to convert more of our BTC to MSC. I'd rather have MSC in a rainy day fund than BTC anyway. As you say, giving away BTC attacts people more interested in BTC, and I'd rather the foundation hold MSC than BTC. Here's my crazy proposal: 1) Keep only the 1000 BTC we've already moved into offline wallets 2) Use the remainder of our BTC to purchase MSC over the next few months on the distributed exchange 3) Pay all future bounties exclusively in MSC 4) Keep half of our MSC money for a rainy day and/or future distributed bounty system 5) If our rainy day fund becomes excessive, we can always vote to lower the ratio later I realize that this would potentially make all of our existing investors absurdly wealthy, but, well, the stated purpose of the Mastercoin Foundation is to serve the holders of Mastercoins, and I'm having a hard time seeing this course of action as anything but a huge positive for them, as long as we do it transparently and over a long enough period of time that nobody who wants to sell to us is left out. Also, MSC prices would probably go up to the point where I'd sell 1% and quit my job to work on MSC, which I hope would also be in the best interests of our investors.  I do like the "eating your own dogfood" type ethos of this idea, but I share some of Kyune's well-stated concerns as well. This may make sense IF devs are willing to work for MSC (which I doubt, at least at this point, since it's so new and unstable, even compared to BTC). This, right here. I wouldn't even feel comfortable getting paid in BTC let alone a currency that's just a few months old. I have a feeling that we sometimes forget how fragile MSC still is. There are so many things that will or could happen that will have a great influence on the perceived value of the coin itself. It would be seriously irresponsible to use most of the Bitcoins from Exodus to buy more Mastercoin. J.R., if you want to leave your job, do you really need to sell Mastercoins to do this? I'm sure a part of the 3000 BTC currently sitting in Exodus could be exchanged for non-internet money so your family has the security that for the foreseeable future they don't have to worry about anything while you work on Mastercoin. Having you on board as a developer would solve a lot of problems and speed up the process. I'm currently often waiting on votes on the way how the spec should be interpreted before continuing on. Having you in the trenches would surely speed this up. |
|
|
|
|
Would you be willing to pm me your address? It's seems to be related to your transactions.
|
|
|
|
|
I think the community should get involved in this discussion, they are the ones we are doing this for. Also like Zathras said we might not be the best people to make a unbiased contribution to this topic.
I would however also like to keep some funds as backup like J.R. suggested. No need to burn through all the funds all at once.
|
|
|
|
|
I'm not against formalising the distribution of Dev Mastercoin, it makes a lot of sense but was this the intended purpose? I was unaware that the dev coins would be attached to bounties. One big difference with the current implementation however is that we attach the generation to block generation and not on a monthly basis. This makes more sense since this gives us an easy point to validate transactions that are spending these coins. Would that also work for you?
|
|
|
|
+1000
Thanks for all the +1's people. The thing is I'm not stuck in a dead-end job at the moment. I have a pretty awesome job already, although perhaps not as awesome as Mastercoin, so getting me to work fulltime on Mastercoin would require a pretty awesome offer. It's a good thing there is more talent attached to this project Once we have a solid mastercoin API library that can work across multiple languages (optimally do basic parsing in C, then use swig, etc to take out to Python, Perl, Ruby, etc) then the skill bar level is DRASTICALLY lowered. At that point, you can get generic webdevs and generaic devs that have a good mid-level understanding of bitcoin/mastercoin to do the work. Parsing transactions is an easy part. Maintaining the state is the hard part. You need some means of representing the state, i.e. balance, pending orders and so on for each address. Then you read a stream of messages and apply them one by one according to certain rules. E.g. for simple send you need this: 1. check if sending address balance is sufficient 2. decrease balance of sending address by X 3. increase balance of receiving address by X To implement more complex rules you need more state variables for each address. Now, the question is, are you going to implement it in C? How? Implementing only parsing in C and rules in high-level language won't have an effect you're aiming for: parsing itself is straightforward, but rules aren't. Example: An address marked as savings can only do simple transfers (transaction type=0). All other transaction types require addresses without a reversibility time window. This definitely makes sense: we do not want to define how savings feature interacts with all types of transactions But what happens if I declare an address as savings after I have submitted an offer? Does it cancel a pending order? Or is this 'mark as savings' command ignored? Different implementations might implement it in different ways, and getting it right is very, very tricky. On the other hand, deserialization is something a monkey can implement when it has the right tools I +1 Killerstorm's explanation. We absolutely need different Mastercoin implementations from the get-go to compare our interpretation of the spec. I already wrote an addition to the spec that should make comparing implementations very easy. For those interested you can read the initial draft of the verification API here. I enjoyed it as well. I was a bit sad though that none of the slides mentioned anything developed by me or the other developers. We all worked very hard to make Mastercoin more then an idea, to create something tangible. People who watched the presentation might have the idea that there is nothing yet. |
|
|
|
No problem. If there is anything else please let me know. I'm working so much on the internals of everything that I become blind for the externals. |
|
|
|
Just a small suggestion: the "Send transactions" section for an address currently shows the source address for each transaction. To me it would make much more sense to show the destination address instead. Annotated screenshot: https://i.imgur.com/BGq4vtL.pngThis should now be the default for addresses pages, please let me know if this works for you. Just a small suggestion: the "Send transactions" section for an address currently shows the source address for each transaction. To me it would make much more sense to show the destination address instead. Annotated screenshot: https://i.imgur.com/BGq4vtL.pngYeah, I agree. And possibly show them both on that main page itself (maybe not the address page), and truncate, using tooltips on hover. ...I find myself pulling up a bunch of tabs for each transaction just to look at the destination addresses...the transaction ID (currently truncated) could be a tooltip as well. Easy with twitter bootstrap (good choice ). http://getbootstrap.com/javascript/#tooltipsI thought it had a css-only way to do this as well...but I guess that might have been taken out in v3.... Yeah I originally had that on the main page but because not all messages had recipient addresses I changed it. I brought it back now by condensing the table and replacing the tx id with an icon to make space. Let me know what you think. Your tooltip idea is in there |
|
|
|
|
Yeah good suggestion. I think currently I share a partial that can be used everywhere. I will fix that up next time I have a spare moment.
Keep it coming!
|
|
|
|
Sorry about that. I have very little time this week and something in the distributed exchange validation is messing up. I have reverted the changes and I think the transaction should be valid again. I made a topic for Mastercoin-explorer and other tools I wrote if you ever want to discuss such things they are better of there. |
|
|
|
|
Yup, theoretically it's possible to show unconfirmed transactions but since block position is a big thing in deciding whether a transaction is valid the results won't be correct until it's actually included in a block.
|
|
|
|
The biggest problem is that Mastercoin always works on block delay. So having live charts are always less interesting on Mastercoin then they are on Bitcoin. There is no instant change, change only happens when a new block is found. However yes, I plan to add these features even if they are not part of a bounty |
|
|
|
|
Yeah something is up with Mastercoin-explorer. I rewrote the validations to allow one big sequence of events based on block height and block position and all my specs pass but it seems the real life is different then my tests. Although the transactions display as valid now I'm missing some Test Mastercoin transactions. Can't say more about what's causing it at this time.
|
|
|
|
Hmm that is not expected. The reimport should be finished by now. I will check it out once I'm off work |
|
|
|
Fixed this transaction. I think the best thing to do at the moment is re-parsing all Exodus transactions with the new code. This will be time costly but at least it will hopefully fix all transactions Edit: Re-import running. I will check out if this fixes the issues. FYI these type of things is why I wrote this addition to the spec. Myself and Bitboy already implemented the API but I just need time to finish the verification site itself. |
|
|
|
|
I'm 99% sure it's a bug. As you know I'm constantly updating the code and sometimes this introduces new issues. I will check it out when I have the time.
|
|
|
|
I might be missing something but it doesn't seem a live one? One of the great points of bitcoinity/bitcoinwisdom is that the chart update in live fashion, giving that "professional" feeling and legitimation to the trading. There is not enough data to warrant live data. However it's a few minutes work to make it live |
|
|
|
For somebody who did his homework the 'Master-coin' thing kinda bothers me  |
|
|
|
I propose the following for specifying how an unexpected purchase offer should function: Late payment: - User A broadcasts a sell offer, 1 MSC @ 0.2 MSC/BTC, time of 10 blocks
- User B broadcasts a purchase offer for 1 MSC at @0.2 MSC/BTC
- User B stars at the BTCChina charts for a couple hours, finally remembers his purchase offer, and broadcasts his payment which gets confirmed in block 12.
The transaction is valid because even though the payment was late, no other purchase offers had been confirmed in the time between blocks 10 and 12. Had a purchase offer been confirmed in block 12 as well, the transaction still would have been valid because a payment transaction moves value, not information. The circumstances under which a late payment wouldn't be valid are if 1.) a different valid purchase offer was confirmed in block 11 (because it's greater than 10, less than 12), 2.) the sell offer has been completely filled. -1 This is not according to the contract that the seller offered. If the buyer already sees that he might be late - he better not send the tx (and lose only the fee). No need to complicate further the already complicated distributed exchange rules. Multiple payments and of incorrect size - User A broadcasts a sell offer, 1 MSC @ 0.2 MSC/BTC, time of 10 blocks
- User B broadcasts a purchase offer for 0.6 MSC at @0.2 MSC/BTC
- User B broadcasts a purchase offer for 0.25 MSC at @0.2 MSC/BTC
- Both of user B's purchase offers are confirmed in block 3, and are valid.
- User B broadcasts a payment transaction of 0.1 BTC which is confirmed and valid in block 5 - receives 0.5 MSC
- User B broadcasts a payment transaction of 0.07 BTC which is confirmed and valid in block 6 - receives 0.25 MSC
The first payment transaction of 0.1 BTC was valid despite not completely filling the purchase offer for 0.6 MSC. This is because payments must be able to accumulate up to the value specified in the purchase offer. The second payment was valid, however user B lost some BTC because a payment exceeding the value remaining on a purchase offer will not "roll over" to any other open purchase offers. The 0.25 MSC purchase offer was filled with the payment of 0.07 BTC. The purchase offer that has the larger value remaining to be purchased should be filled in these circumstances, to as to minimize lost BTC. Just as payment transactions are cumulative, so are purchase offers. Two (or more) purchase offers from the same person may be "active" at the same time. There's no guarantee that one will be confirmed before the other - once broadcast it's out of your hands. If "latest one counts" then this requires an association of data across multiple purchase offers, in different blocks, and is drastically more complicated than treating them as just separate purchase offers. Also, it brings up questions like: If 2 purchase offers from the same address are confirmed in different blocks, but within the time range does this extend the reservation out? Since we allow only one sell offer for an address, we could consider only one purchase offer for an address to simplify the protocol. I don't see a real reason to complicate the logic here too much, so if we do keep multiple purchase offer option, let it follow the basic rules, ignoring the fact that these are purchase orders from the same address. I completely agree with Grazcoin on this one. There is enough difficult logic already involved even without making things harder to parse. We should keep it as simple as possible and add more interesting options when we mature enough. I agree with you on this mainly because I don't want to spend anytime going back to the beginning to support this one edge-case. We can add support for those addresses in later. |
|
|
|
|
Show Posts
