JR, the spec doesn't mention anything about confirmations - have you put much thought into when we would consider a mastercoin transaction confirmed? 3 blocks? 6 blocks? Thanks
I expect the number of confirmations should be the same as bitcoin - no more, no less. This is because we are relying on bitcoin to solve the double-spending problem for us, and the purpose of waiting for confirmations is to avoid double-spending.
I'd like to seek further validation of my transaction engine so I've opened up the block explorer component of Masterchest @
https://masterchest.info.
This is very
alpha so there may be bugs, errors, mistakes and so on present - feedback is most welcome so please post about any errors or unexpected behaviour.
I am VERY pleased to see this. Note that Tachikoma hasn't decided to release the source code to MasterCoin explorer yet (just the library that runs behind it), and the contest only pays for projects that have source code released. Obviously Tachikoma will have a big payday for releasing that library, but an open-source MasterCoin explorer would win some money too. If he does release source code, you'll have to share.
I'm really excited that you are working on making this into a web wallet. That will be a huge boon to our project (and obviously will be worth some money too).
I'm back in action after being tied to the bed for the last week.
I've released '
Masteroin-ruby' which is the library behind
mastercoin-explorer.com. I am trying to keep the
readme up-to-date whenever I update it.
The latest version supports sending multisig Mastercoin-transaction via Bitcoin-Qt (or Bitcoind). However as always please be very careful what you do. It's very basic but the same logic could be used by any full-fledged Mastercoin client. Mastercoin-explorer will also recognise multsig transactions now.
I've send three (invalid, because the sending address did not buy from Exodus, did not want to send real coins until spec is finalised) multisig transactions,
one,
two and
three.
As always I hope all you other developers working around can also try my implementation so we can finalise the spec. A few things I came across.
- Sequences for multisig public keys need to start with 01 instead of 00. If you don't do this more often then not the public key won't be a valid ECDSA point.
- My transactions were being flagged as non-valid whenever I used 0.00006 for the multisig output, changing this to 0.00006 * 2 fixed this for some reason.
- Bitcoin-qt doesn't recognise multsig-transactions as outputs ready for spending. You will have to manually redeem those outputs.
Thanks! This should now be fixed.
I'd like to seek further validation of my transaction engine so I've opened up the block explorer component of Masterchest @
https://masterchest.info.
This is very
alpha so there may be bugs, errors, mistakes and so on present - feedback is most welcome so please post about any errors or unexpected behaviour.
Woops; grats! Diversity is a good thing
Everybody working on MasterCoin projects should either be looking closely at Tachikoma's source code for his library, or just using it
I've added a quick JSON-API on top of mastercoin-explorer. You can find the
documentation here.
Nice! This will help a lot of other projects move forward faster.
Is JR the one assigning the winner of the contest, or is it the board? Seems like it should be the board.
I'll be soliciting feedback from the contest participants about how they would distribute the funds to the other participants if they weren't in the contest. I'll combine that feedback with my own, and take those numbers to the board, who may have their own feedback. Once the board is happy, we'll pay out.
We'll probably start another contest of some sort immediately after the current one. Possibly instead of having an end date for the next contest, we'll have an end-feature. Once the feature is fully implemented (web wallet, PC wallet, and library), we'd pay out to everyone who helped us get there. What do you guys think of that idea?