|
15XJoDF4xCUrWX3ES9ftWq3wnGhuRsqrLk
a497e4fd11d2223e2129828e44b0d2110b2bb0ec3cb8a0f36bbd28f37a15ceef
Transaction is invalid in mm. It is an msc purchase offer which should be invalid.
|
|
|
|
|
23f77b6caedd9d5ebbdc56f0d688bee0cf5fd41d19f2aba71f989237326da4b4
Invalid in mymastercoins sender has not enough msc to send. Valid in mastercoin explorer
|
|
|
|
|
1DDhPhsydLh6dDgAg7GVT3xZuYd93tjqtp
Master explorer has no generated msc coins but it has 100 generated test msc
Mymastercoins 60.56 generated coins.
|
|
|
|
|
a497e4fd11d2223e2129828e44b0d2110b2bb0ec3cb8a0f36bbd28f37a15ceef
Simple send in masterexplorer. Transaction is a purchase offer in mymastercoins.
|
|
|
|
I wan't to test the "MyMastercoins Wallet" features,
anyone can send me few Test MSC?
1AN1HQxgSxjz1y3Pe5tVT7zmg1FtqD8pN
Many thanks!
Please wait for the next version. I'll release it by Friday. |
|
|
|
There are transactions where the change address is the highest value.
Ex.
58effd6afc7980392b17ba012943915a9be1db3a6d025969e5d5a197a3e25bc3
Reference address
195NyMnCNF8GQYN6gKLuf5LsArgoi5NCW7 (0.00056 BTC - Output)
Out
195NyMnCNF8GQYN6gKLuf5LsArgoi5NCW7 - (Spent) 0.00028 BTC
1BaMPFdqMUQ4DLtPtRbfHkEFScBGmyvYA - (Unspent) 0.00006 BTC
1LdgFp2gLvWfkPnyTYAtH7ENnzgBDdNwfd - (Unspent) 0.00006 BTC
1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P - (Unspent) 0.00006 BTC
Should this transaction be valid or invalid?
The data can be read using peek and decode.
Sorry to nitpick but for clarity reference address = recipient, not sender  Yep this fits peek & decode without ambiguity I believe (the sequence numbers are way off, but since the change output has a different amount & we ignore Exodus & peek the data address, there is only one address left which has to be the reference) Sender (thanks for clarifying reference = recipient) 195NyMnCNF8GQYN6gKLuf5LsArgoi5NCW7 will be happy he still has 15 msc but someone won't be. We have to sync ASAP. |
|
|
|
Why shouldn't this be a valid transaction? Sorry I think I'm not seeing something.
58effd6afc7980392b17ba012943915a9be1db3a6d025969e5d5a197a3e25bc3 Is not in master-explorer and masterchest, and invalid in masterchain . It's valid in mymastercoins. I think it is valid because user sent it first. Balance 215 msc 58effd6afc7980392b17ba012943915a9be1db3a6d025969e5d5a197a3e25bc3, block. 273217 200 msc Balance 15 Then sent 4c70f475496beac289e1db74204e0a3501aa920bafe8f618375aa88715e702a1, block 273231. 215 msc Which is invalid because he doesn't have enough msc. |
|
|
|
|
There are transactions where the change address is the highest value.
Ex.
58effd6afc7980392b17ba012943915a9be1db3a6d025969e5d5a197a3e25bc3
Reference address
195NyMnCNF8GQYN6gKLuf5LsArgoi5NCW7 (0.00056 BTC - Output)
Out
195NyMnCNF8GQYN6gKLuf5LsArgoi5NCW7 - (Spent) 0.00028 BTC
1BaMPFdqMUQ4DLtPtRbfHkEFScBGmyvYA - (Unspent) 0.00006 BTC
1LdgFp2gLvWfkPnyTYAtH7ENnzgBDdNwfd - (Unspent) 0.00006 BTC
1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P - (Unspent) 0.00006 BTC
Should this transaction be valid or invalid?
The data can be read using peek and decode.
|
|
|
|
3. Nobody has decided "who will implement mastercoind". Anybody is welcome to do it. We can do this as a bounty (tell us how much you need to get this done, preferably email info@mastercoin.org), or we can do this as part of our Role Based Bounty program once we secure a hire or two. Also we haven't decided on a technology, although Go does seem like a good choice. If its a bounty, I will be interested to join. (Go looks challenging) Now, if you'll excuse me, I'm off to the Future of Money conference, where I'll be in a panel with Vitalik from Colored Coins, Chris Larsen from Ripple, and Dave Sterry from Litecoin. ttyl
Good luck in the conference. Very interested to hear what everyone has to say. But I hope you win |
|
|
|
If the transaction has at least 1 confirmation. It will appear in mymastercoins.com. |
|
|
|
|
For transaction
725210a6bfea06e4aa9a582602d758db920eff9c720aca380d6e77c08a4108ac
The reference address is 18jArgoK7EPRaozSN6Eprtnjb1LMQQ3McF
The largest output is the change address which is also 18jArgoK7EPRaozSN6Eprtnjb1LMQQ3McF
1NK1rJSkMeDtg5SXfXaSbD14QxAqQbqAr6 - (Unspent) 0.00006 BTC
18jArgoK7EPRaozSN6Eprtnjb1LMQQ3McF - (Spent) 0.00046 BTC
1KgwXKs6TBRExnC7tswfzf5rg66HUEpsh5 - (Unspent) 0.00006 BTC
1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P - (Unspent) 0.00006 BTC
Is this transaction valid?
(For my implementation I disregarded output addresses that are the same as the Reference address. Then used "peek and decode". )
|
|
|
|
Mymastercoins differences with Masterexplorer. List is getting shorter MM=6.283E-05 1Mt1tCGyJnD6SHzBgxtg6GRJLUhqQrc4ff ME=5.00006283 MM=10 1EAuHj8Z6rTCHPxXfaGzzPsZevC2mg1XAj ME=10.2 MM=10.55548942 15XJoDF4xCUrWX3ES9ftWq3wnGhuRsqrLk ME=5.55548942 MM=501.60166005 16rUg4eijBqM6oYrSrUzvghe6QM9CHvTYW ME=500.60166005 |
|
|
|
|
Here is the difference between mymastercoins mm and masterchain mc. I'll look at each address trans and report back.
MM=227.23987298 1Q1sFqsi8S5DxV5hz6sWLamGBp9To93iG7 MC=232.23987298
ecb77ee990de29745de949462e1f6e44584c310a0da12c9fbdf86dbe6ffabcfc not in mc
MM=470 1PJbt9HQJwvcpLqnK2xA7xaukpUENjeRn2 MC=270
607dd8939d9a108e54229597bc26756588c1987fb9969d3256320c858572c998 not in mc
MM=0.2065 1P8GMhC3qYkuvRRBsS5gqGegT7GvQoxAwY MC=0.0065
9a11be500211dd92f2caaa7678779aba11d0e5ef0e017190c10a9621f6c492b9 not in mc
MM=334 1NK1rJSkMeDtg5SXfXaSbD14QxAqQbqAr6 MC=284
725210a6bfea06e4aa9a582602d758db920eff9c720aca380d6e77c08a4108ac not in mc
MM=400 1LdgFp2gLvWfkPnyTYAtH7ENnzgBDdNwfd MC=200
58effd6afc7980392b17ba012943915a9be1db3a6d025969e5d5a197a3e25bc3 not in mc
MM=347 1HN4XivkzGfZdwKU9tgW7NffCbiR8otAr9 MC=160
4583689089dc9cca48bed67f8e9ab35e6356c21290fcdfc3b0b6e9a9b2fa4acf not in mc
MM=10 1EAuHj8Z6rTCHPxXfaGzzPsZevC2mg1XAj MC=9.99999991
MM=110 1DoG8JupeK8y7jCHe9C92eEvJhmrJm3Xe9 MC=60
MM=0 1AMfFzbrhhizKDpqebYVYFGaTwdtSt5ux2 MC=9E-08
MM=15 195NyMnCNF8GQYN6gKLuf5LsArgoi5NCW7 MC=0
MM=187 18jArgoK7EPRaozSN6Eprtnjb1LMQQ3McF MC=0
MM=380.84328263 15og4WXZPwkMnnsb3dj6HqgTUfcRLx4J9b MC=379.07493056
MM=235 15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby MC=230
MM=380 15YmJ5UmEWWsE83kASiiwrTJvc394dRRn8 MC=470
MM=0 14hm8rTdknVCDpqXGY5nFqVWruU9UBeuHd MC=0.2
MM=1E-08 139Dx25QXHBJD1tfLQMwASAAJrWFiM4BPz MC=510.00000001
Dev msc from exodus address
MM=625.21848545 1Fq37GNfyxSvnmye3QdxH6GpPAQ3enarfs MC=250.21848545
MM=1569.63027669 13NRX88EZbS5q81x6XFrTECzrciPREo821 MC=1194.63027669
MM=376.4046 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL MC=1.4476
|
|
|
|
|
I see. In order for the transaction to work
Instead of
An additional output is permitted for the remainder of the input (the 'change' address)
To
Additional outputs are permitted for the remainder of the input (the 'change' address)
Good work on the strict implementation. However the "peek and decode" gave "class A" a lot of flexibility. If we are for flexibility then allowing multiple change output should also be included.
|
|
|
|
OK transactions: f0862dda475d17383e7c3c63ad5a015e8dfd77d627ca45ec2e1ba2579c29e0f9 8175fcd0221ee5cda1808f48861bef5c2d5e8b9acf91a7b0fade5768d35f6665 Are not considered Mastercoin transactions by my implementation. This is because my implementation enforces a literal interpretation of the spec, being that only one additional output is allowed for change in Class A. Both those transactions are attemping Class A but have two additional change outputs. Technically speaking I can allow those through, but I'm trying to take myself out of the equation as I really don't think it's right for an individual developer to decide whether someone gets their money or not. This is why I'm very literal with the spec. We can perhaps do a pull that changes the spec for Class A to allow multiple change addresses as follows: An additional output is permitted for the remainder of the input (the 'change' address)
to Multiple additional outputs are permitted for the remainder of the input (the 'change' addresses)
But before saying yay/nay to that I'd want to do some due diligence to see if that has any other impact I'm not seeing at first glance (ie like all of a sudden validating other past transactions that may previously have been seen as invalid and thus resent etc). Thanks! Isn't the transaction covered by "peek and decode"? |
|
|
|
Hey bud, My implementation would look at this in the literal sense of the spec. So 1NZC9Pk4Rt1mVe5dL8w2fShXJppyJU7Vq8 would be the sender since it was the largest single input. It could be argued that this is not a mastercoin transaction (no data packets) so doesn't need to abide by the same rules, but I'm not sure we want to open that proverbial door! Has a single or the largest input signed by the sending address.
Sendmany is not a great way to do this as we have no control over the inputs used (and would have to work around bitcoind 'account' handling (a concept internal to bitcoind/qt, not the protocol). Would it help if I built an encodedexpayment function into the lib that handles this? Thanks! EDIT: Sorry, I see you already asked for an encodedexpayment-style function a few days ago - must have missed that somehow. Yep no problems, I'll let you know when it's ready Zathras, My code is missing "the largest single input is the reference". I will update it and reparse everything. I'm also trying to build encodedexpayment so that i can remove the "sendmany" from the wallet. Thanks again! |
|
|
|
Ok. It's a Go z0mbie, looking forward to see your work in Go. |
|
|
|
|
Go will be used to listen to the exodus address (and probably other addresses)
it parses and saves the transactions (block number, date, reference address, transaction type currency etc ) in LevelDb.
All developers can then access Go via api or json to get the transactions.
Is this correct?
|
|
|
|
What use case scenarios are we enabling here? To date we have always applied the logic that the sender is the address with the largest input - I'm trying to see where the value is in deviating from that. Thanks! It is a Payment transaction 5697c55a0fb5ee61f6e9c78cb9c84cef23e11c84c68cd6e2821b8869489b808c 1BKpa19m5Xy9SvSzC5djPWtCfbuynSDwmb (0.00006 BTC - Output) n=2 1BKpa19m5Xy9SvSzC5djPWtCfbuynSDwmb (0.00006 BTC - Output) n=2 1NZC9Pk4Rt1mVe5dL8w2fShXJppyJU7Vq8 (0.00009 BTC - Output) n=1 1BKpa19m5Xy9SvSzC5djPWtCfbuynSDwmb (0.00006 BTC - Output) n=2 If its the largest input, 1NZC9Pk4Rt1mVe5dL8w2fShXJppyJU7Vq8 (0.00009) is the reference. Is it is the largest total input, 1BKpa19m5Xy9SvSzC5djPWtCfbuynSDwmb (0.00018) is the reference. The sender is really 1NZC9Pk4Rt1mVe5dL8w2fShXJppyJU7Vq8. It is payment for a purchase offer. But using the sendmany method it created the input transaction above. |
|
|
|
|
Show Posts
