|
Linked here from the old thread.
Thanks!
|
|
|
|
|
I have received this list and I will pay this with the next payment I make from project funds. Sorry, it may be a couple weeks, as I am currently behind on everything!
I intend to do this payment in a big batch along with some security bounties we owe.
|
|
|
|
Just emailed this to our dev@ and info@ mailing lists: 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/viewformDUE 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! |
|
|
|
We have our own forum now which is now getting a lot of traffic ( http://www.mastercointalk.org) so I'm locking this thread so our discussions are less spread out. Feel free to discuss Mastercoin and the Master Protocol there! |
|
|
|
I think it's time to close down this thread now that our own forum is getting some good traffic. Please move any discussion of Mastercoin price and trading here: http://mastercointalk.org/index.php?board=3.0Thanks! This thread is now locked. |
|
|
|
Quote from: https://bitcointalk.org/index.php?topic=292628.msg5795861#msg5795861If the specification is accurate it also follows that, because there is no implementation that recognizes Class B transactions with P2SH outputs to uncompressed public keys as invalid, no implementation can be trusted to display the correct mastercoin balance of an address.
Further, a significant sum of bitcoin has been unknowingly traded with parties which may not even know how much mastercoin they have. Given the possibility that this party has a mastercoin balance to cover the trade, there's no guarantee that it was actually sent to the buyer.
It's really tragic for mastercoin if the spec is accurate, because the loss of bitcoin in invalid mastercoin transactions cannot be recovered, and every single wallet/implementation is useless as a method of sending, receiving, trading, or otherwise interacting with the mastercoin network. What does this mean? Is there now a possibility mastercoins bought from exchanges / users are not valid? Mastercoin balances can be trusted. Our friend appears to have some complaints that some of our bitcoin outputs are (temporarily) unspendable, but I haven't seen any evidence of a way to get a Master Protocol client to display an incorrect balance. |
|
|
|
<snip> Mastercoin, - uses irresponsible implementations of Class B transactions.
- creates outputs that aren't spendable by any wallet.
- greatly privileges Windows users.
- and doesn't have a specification that describes current implementations.
I feel strongly enough about these items that I'd rather see some sort of resolution than sleep like a normal person. I don't feel like it's my place to offer unsolicited solutions to the problems I'm posing, however would be happy to discuss my ideas on the subjects. And if consensus is that the items I bring up are not problems, take this as feedback from a "long time mastercoin user" that the project feels out of touch, lacks on the PR front, and has direction at the expense of overall quality. I'll let one of the devs weigh in on the class B stuff. We do plan to have better options for non-windows users soon. Omniwallet should be a good solution, and for those who want to run a full node, we want to have a full desktop client too (possibly a port of Masterchest using mono). We hope to greatly improve usability on all wallets which we sponsor. I think the spec is accurate right now, but if you've found something that is out of date, we welcome pull requests  Thanks for weighing in. |
|
|
|
Guys, Here are the addresses I plan to use for February, based on what I have from each of you: | Who | BTC Address | MSC Address | | Faiz | 1JJ6e9iWjGgEnCQRivKvdfNjRTgYVaKtWy | 1MMF42zk8f4TqoV1QFeia18bb14rBHXzAU | | Colbert Lau | 1MnPcdUFDYnTz3jz9n3erfWbd7JZfPunxL | ?? | | Grimentz | 128MGmQKtKUPf66w2w9eaGc7YBqLrcnLx5 | 1rM1oMEFMfhPBo4kRaf2CMXf9XQCHyYWi | | Adam Chamely | 18hFjy7CWvX7FgZEXEW3bgz35KpYAzFR1c | 18hFjy7CWvX7FgZEXEW3bgz35KpYAzFR1c | | Bitoy | 14cn7BiyzUeMcddC3RUFk77Z2k8NcP66yf | 14cn7BiyzUeMcddC3RUFk77Z2k8NcP66yf | | jeroenn13 | 15EMewc1nH8Cqzsx8hrFNNdbQBjVTEWahp | 15EMewc1nH8Cqzsx8hrFNNdbQBjVTEWahp | | Marvshneider | 1ACsaXeqiPwZVzEuWXa2vwe9etxaet6QWg | 1PKKRfHgvfZi2ToZDKkKrCUFpvuVKHz9WV | | Ryan Keenan | 1PyQbHr3ywRdbkcq3sZKpkkJNBJUXbGXJH | 13NzZ7nwzEzLfuCEtfC1iQv5mJzs4PsFoW | | grazcoin | 1CZ5WRYj48vWV7cYRRdheyhiodMVP3EMi3 | 1CZ5WRYj48vWV7cYRRdheyhiodMVP3EMi3 | | Tesca | 16BurP5f7n5RqjWGQ44Lj5NX6GzxaoAaqU | 16BurP5f7n5RqjWGQ44Lj5NX6GzxaoAaqU | | Craig | 17xr7sbehYY4YSZX9yuJe6gK9rrdRrZx26 | ?? | | MasterXchange | 1zobh1SwsVdk3uMjEHeGV86hjNZeJ5CwC | 1zobh1SwsVdk3uMjEHeGV86hjNZeJ5CwC | | Curtis | 19TwBziBeCb4VnrZgJasJukwRKNSVvDp7Y | 13pm7cmA5vVpKkDLJCvqh26kcp6V6PJ1Aq | | dexX | 11NiSNoGYomEA3ZHEN4R9ne4kwDjECsAy | 11NiSNoGYomEA3ZHEN4R9ne4kwDjECsAy | | Marin(Bebopzzz) | 15AnM1gg5HAAnRPPBUXFX1N6mbTt4cLyZJ | 1GmsjoERUACUwAsjKSLhSekH8EeXLRWKku | | Shannon Code / Genecyber | 1N6vMzy46RNGny7u5BYMFGpPin7uW3cTKK | 1DMH2jezmNha2ShBhq3ogsXGviPBRppmwX | | jakecnn | 1HXsrKJHbJCdWThFQL14tQ2ThuUhKUzmsf | 1HXsrKJHbJCdWThFQL14tQ2ThuUhKUzmsf | | Patrick | 1EdtK7EkErgeU17qRuifxASA2yMoxibxYv | 1AQBeWsRfbHst7NojYdt42MZThcR4jy8fk | | Zathras | 1DrYXscsbMxhQMvvCmK7aVppbJGhr3RRSN | 1Px5ruEuWdtvkG3AJ1sJ8Q7ckV8B1f3us5 |
Please check your address to make sure it is correct. Speak now, or forever hold your peace!! |
|
|
|
I think I could take a pretty good shot at guessing most of your portfolio allocations just based on comments in this thread @ Mastercoin
You need to create another count down,
such as for
the Metacoin distributed exchange,
or smart property
or distributed e comerce (my favourite)
Yeah, we definitely should do a countdown to the Smart Property launch. That was fun! |
|
|
|
|
Regarding UI:
Yes, you need to read the instructions (tutorial) to use Masterchain web wallet. Sorry, it simply works differently than what you may be used to. This is mostly because Masterchain chose an unusual security model. However, within a few minutes, you'll have an "a ha!" moment and be off to the races. I have personally found it to be quite usable once I understood what was going on.
Please DO open issues on each of the github repos. We're devoting the remainder of March to making these wallets easier to use. Like Ron, I hope that omniwallet will be easier for casual users to use (won't require you to skim a tutorial before you can get started).
Regarding dEX:
Bitcoin/MSC trading is one-sided because posting a MSC buy order means nothing (it is unenforceable at best, spam at worst). Sure, you can signal your intention to buy MSC with BTC, but nobody can actually make you do it.
Once you are in the MSC ecosystem, order books are two-sided, and are automatically matched as you would hope.
Regarding speed of progress:
We've chosen to be more decentralized, with more implementations, and that means more time. Consequently we have a lot of beneficial cross-checking and redundancy (both technical and legal redundancy). However, we are narrowing down our number of officially supported implementations as we go forward to one PC wallet and one web wallet, as we have realized that the time sink of maintaining all these implementations is just too high.
I'm personally very happy with our progress. I realize it looks slow from the outside, but we are simply doing more, and our final product will be better for it.
You all know (or should know) that venture capital groups have lined up millions of dollars to pour into MSC-based initiatives. The Houstan hack-a-thon was completely dominated by Mastercoin projects. Probably 90% of the projects being worked on were targeted at MSC. Our competitors consist of several systems which have a long way to go to catch up with us, and one knock-off which literally forked our spec and rushed some half-baked stuff out the door.
I'm not saying that our project can rest on our laurels, but rather that we have the momentum right now, and we don't intend to lose it.
|
|
|
|
J.R can comment his perspective on this. Here is mine:
We have a bit of a mixup here. On the one hand, I do believe that the "High bar for usability" goal has not been met, and doubt it will be met this month.
On the other hand, we moved to paying out monthly bounties in February, and .
I hope it is clear that the DEx bounties paid in Feb, and the March monthly bounty, count towards the 300 BTC bounty (out of which 150 BTC has been previously paid).
So after March I don't think that a lot of money will remain in the original 300 BTC money pool (J.R needs to reply with some numbers).
I expect the bulk of the money remaining from the DEx to be divided in March's monthly payout.
Perhaps if there is only a tiny amount left after that, we will decide to increase March's payout and pay out the full remainder of the 300 BTC bounty this month, in order to avoid the accounting/judging headache. We will wait for J.R's number regarding February's payout (due any day now), and see what makes sense.
Yup. February numbers are nearly ready. They are my top priority once I catch up on urgent emails. edit: I think we are close on usability. If we spend the next couple weeks fixing things that make the various wallets hard to use and trade with, I don't see any barrier to finishing the payout at the end of March. |
|
|
|
And the official changeover block to trade MSC on the distributed exchange is . . . (drumroll) 290630History suggests that our target date of 2014-03-15 00:00:00 GMT should fall somewhere between blocks 290607 and 290630. I chose the later number because I want to make sure we get every last ounce of testing we deserve |
|
|
|
And the official changeover block to trade MSC on the distributed exchange is . . . (drumroll) 290630History suggests that our target date of 2014-03-15 00:00:00 GMT should fall somewhere between blocks 290607 and 290630. I chose the later number because I want to make sure we get every last ounce of testing we deserve |
|
|
|
FYI we are discussing the possibility of Masterchest using mastercoin-tools as its parsing engine. Having multiple parsing engines is essential to avoid too much centralization in my opinion. Yeah, this isn't something we have completely agreed upon yet. I'm very reluctant to reduce the number of parsing engines - there are TONS of edge cases we catch because we have them. On the other hand, it slows us down a lot, and you could argue that more strenuous testing would catch those same edge cases. |
|
|
|
|
I guess I'd like to hear the other devs comment about these packets with "junk" in them which are there already. Can you point a couple of them out?
I'd like to know what logic currently makes them valid. That is what will probably end up in the spec, just to avoid changing anything.
|
|
|
|
Didn't receive the mail you quoted, but including the pubKey shouldn't be required, at least on the spec level, and as you said, it's not validated at the moment anyway. Keep also in mind that the number of n-of-m multisig parts will rise and won't be limited to 3. Actually those are already "accepted", but the standard client refuses to send them.
dexx, are you suggesting something other than what is described in your github issue? :https://github.com/mastercoin-MSC/spec/issues/78 There you say: I suggest to temporarily insert a line in the spec that Mastercoin data packages should be in order within an output: Sender's pubKey Mastercoin data-package 1 Mastercoin data-package 2 It appears that data-packages are only parsed correctly, if this order is given and allowing unordered data packages is probably not trivial. See the discussion here: https://bitcointalk.org/index.php?topic=292628.msg5646781#msg5646781 (and a few posts earlier) I think that is the current behavior, and the spec just needs a note about it. |
|
|
|
We simply can't afford the time, and we believe we can rely on the order of outputs not changing in the transaction, so sequence numbers are probably redundant for class B transactions. Well, they offer also some further insight in form of "this is indeed a MSC data-package". How about something like: "use the longest sequence of MSC data-packages within transaction outputs with ascending sequence numbers, starting from 01"? This gives some space to allow junk packages, even if amigiousness exists for the first package. Not that I encourage to include some, but I mention it in light of potentially not-exactly-the-input-pubKeys and unknown packages as listed a few posts earlier. Currently all those transactions are "valid". Anything that is valid now probably needs to stay valid. We're going to try to keep the current logic and formalize that in the spec. I plan to add a note in the spec in the section about class B transactions: "Note that current implementations do not allow out-of-order sequence numbers, but rely on the immutability of transaction output ordering instead." |
|
|
|
|
We had a productive meeting today, and Craig and I were able to make some decisions regarding the last remaining consensus issues:
1) Minimum fees must be respected, as has been in the spec since the beginning. I believe Bitoy and Grazcoin both need to make this change. Without this change, someone can shut down the whole dEX with spam transactions. The fix is simple: if someone tries to accept coins without paying the minimum fee, invalidate that transaction.
2) We're going to have to disable multiple accept offers. This was a harder decision to make, but it boils down to reducing complexity. Also, since graz and bitoy both need to make the minimum fee change, we can't keep the parsing libraries static. This should also be a simple fix: only one accept offer from a buyer to a seller. Additional accept offers are invalid.
3) Zathras is going to have to drop his change to respect packet sequence numbers in class B transactions. We simply can't afford the time, and we believe we can rely on the order of outputs not changing in the transaction, so sequence numbers are probably redundant for class B transactions. If we do packets out-of-sequence someday, we'll have to change the version number of all transaction types.
Sorry that further changes must be made, but we needed to choose a direction and stick with it. Both Craig and I are committed to this direction, and I'll be updating the spec to reflect #2 and #3.
Thanks guys!
|
|
|
|
|
Show Posts
