buggy but interesting

One of the additional best reasons for going with Go is an existence of almost fully functional bitcoin fully validating node in Go language: https://github.com/conformal/btcd   

Watch a video about it here:  http://www.youtube.com/watch?v=d1IYvJs5GGw

new blog post

INTRODUCING THE FIRST TWO FULL-TIME MASTERCOIN DEVELOPERS

http://blog.mastercoin.org/2013/12/31/introducing-first-two-full-time-mastercoin-developers/

Blockexplorer.com is stuck at block 277595.  That is where I get data.

  Is there a way to get exodus trans using bitcoind?

The maximum amount  userA can send is 35 (since 5 and 10 are withheld from the 50 balance).  When the purchase offer expires it max is 45.

Bitoy - this doesn't seem right to me, it seems like this approach could end up harming users.

To frame this example using slightly different values:

1. UserA has 50 MSC
(Balance 50)

2. UserA lists 30 MSC for sale
(Balance 20 available, 30 reserved)

3. UserB sends purchase offer for all 30 MSC
(Balance 20 available, 30 reserved for purchase offer)

4. UserA changes offer to 20 MSC for sale
(Balance TBC1 available, TBC2 reserved, 30 reserved for purchase offer)

5. UserC sends purchase offer for 20 MSC
(Balance TBC3 available, TBC4 reserved, TBC5 reserved for purchase offer)

So UserA has attempted to reduce the size of a listed offer, this can't be allowed to result in a scenario in which the revised offer is treated as new and unreserved (and could result in all 50 of UserA's coins being sold).

The amount remaining available to UserA should be: Unsold balance - the greater of (all reserved purchases OR the revised offer amount).

So in the example above:

1. UserA has 50 MSC
(Balance 50)

2. UserA lists 30 MSC for sale
(Balance 20 available, 30 reserved)

3. UserB sends purchase offer for all 30 MSC
(Balance 20 available, 30 reserved for purchase offer)

4. UserA changes offer to 20 MSC for sale
(Balance 20 available, 30 reserved, 30 reserved for purchase offer)

5. UserC sends purchase offer for 20 MSC
(Balance 20 available, 30 reserved, 30 reserved for purchase offer)

Now - what if UserA was actually trying to sell the other 20 MSC?  I would expect them to increase the sell offer to 50 (although we still need to be sure this interpreted as an adjustment and not another 50, which is quite possible the same problem in reverse!).

Does this make any sense? Cheers

UserA has a balance of 50 tmsc

UserA sends a offer to sell 30 tmsc

UserB sends a purchase offer 10 tmsc (not yet paid)

UserA changes sell offer to 5 tmsc

What is the maximum tmsc can  UserA simple send to UserC?

A lot of stuff J.R. said.

Have we had a conversation already about allowing/disallowing based on whether output amounts are the same?

Has all output values equal & above the 'dust' threshold (currently 0.00005430 BTC). An additional output is permitted for the remainder of the input (the 'change' address).

I'll have to look a bit further into that one (ecb77ee990de29745de949462e1f6e44584c310a0da12c9fbdf86dbe6ffabcfc) - it's detected as a simple send but fails decoding.  To be continued...

EDIT: Are you falling back to peek & decode on this one?  I make the data address 15efTnSCG13druGmetEp1AULCEqudtCSwq and the reference address 15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby.  The data address has sequence number 51 while the reference address has sequence number 50.  It should be the other way around.  This should have fallen to peek & decode, but I have a feeling since the sequence numbers don't look ambiguous, my implementation is taking seqnum 50 (the ref address) and trying to decode it probably resulting in a trapped exception.

Need to set this up as a dummy transaction to watch the decoding in action - I'll try and get some more time to look at this tomorrow.

Thanks

D, [2013-12-16T13:41:18.347691 #3558] DEBUG -- : Found data for address 15efTnSCG13druGmetEp1AULCEqudtCSwq
D, [2013-12-16T13:41:18.348294 #3558] DEBUG -- : Looking for data sequence 51 +1 == 52
D, [2013-12-16T13:41:18.349347 #3558] DEBUG -- : Sequence: 148 for 1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P
D, [2013-12-16T13:41:18.349637 #3558] DEBUG -- : Sequence: 50 for 15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby
D, [2013-12-16T13:41:18.349896 #3558] DEBUG -- : Sequence: 51 for 15efTnSCG13druGmetEp1AULCEqudtCSwq
D, [2013-12-16T13:41:18.349940 #3558] DEBUG -- : Target address not found attempting peek & decode.
SimpleSend transaction from 1Q1sFqsi8S5DxV5hz6sWLamGBp9To93iG7 for 5.00000000 Mastercoin to 15a4XCuWmx2cCQVf8wZK7mqdvj5uwo1vby.

masterchain interpretation is a bitcoin payment:
https://masterchain.info/btcpayment.html?tx=a497e4fd11d2223e2129828e44b0d2110b2bb0ec3cb8a0f36bbd28f37a15ceef&currency=MSC

The reason is that the values are different:
0.00006 to 1EXoDusjGw...
0.00006 to 1Mt1tCGyJn...
0.0006   to 1MnZ4jmQ3E..
0.00668292 to 17oDj9dvFL...

I thought all values except for the change have to be the same, or else the tx is invalid for mastercoin protocol.