300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread)

[TKeenan]

Can anyone explain why this transaction is marked 'invalid': 02a3b6d6d189da0e50c528312158dd36495e752de4f3a56498afd8231211451a

I tried this about an hour ago.  Maybe it needs more time.  Maybe something is wrong.  I can't tell which.  Can someone check and let me know if they see something wrong?

[Tachikoma]

Because the sender address doesn't own any Mastercoins.

[TKeenan]

Tachi -

From inside Armory one wallet has many addresses.  How do I force the transaction to choose the address having the MSC on it?  I can't seem to find any way to use that address as the source of the transaction funds.

[Tachikoma]

I'm not sure Armory has coin control. Can you freeze addresses? If so you could freeze everything but your MSC address.

An other option is to use mastercoin-explorer to create the transaction for you and then sign it using Armory and broadcast it.

[Tachikoma]

Zathras, or an other dev could you double check my Exodus vesting. The code is online now but I want to triple check I'm doing it right since I kept messing up the math earlier in the thread

Code:

    it "should generate coins based on the time since exodus" do
      tx = FactoryGirl.create(:simple_send, tx_date: Time.parse("2013-12-01 00:00:00"), address: "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P")
      tx.balance.should eq(8842.012600662521)
    end

[zathras]

Zathras, or an other dev could you double check my Exodus vesting. The code is online now but I want to triple check I'm doing it right since I kept messing up the math earlier in the thread

Code:

    it "should generate coins based on the time since exodus" do
      tx = FactoryGirl.create(:simple_send, tx_date: Time.parse("2013-12-01 00:00:00"), address: "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P")
      tx.balance.should eq(8842.012600662521)
    end

I calculate the generated dev MSC as at 1385856000 (01/12/2013 00:00:00) to be 8932.02250394.

Code:

Console.WriteLine((1 - (0.5 ^ ((1385856000 - 1377993600) / 31557600))) * 56316.23576222)
8932.02250394725

[Tachikoma]

Ah sorry. Rails automatically parses the date with my timezone and adds an hour. That explains the diff. Thanks!

[zathras]

Are you still using this (or similar) code?

EDIT: Post went in at the same time, cool If you take the timezone into account do we match?

[Tachikoma]

Actually, no. 8932.02057119

[Bitoy]

Actually, no. 8932.02057119

I have almost the same number
8932.0225039472534


(1 - (0.5 ^ (  (1385856000 - 1377993600)    / 31557600))) * 56316.23576222

[Bitoy]

Tested the new peek and decode algorithm.   This transaction looks valid.

fd093d901c4baf20ea2525fe3b36b2519b9a7915683b45b996023fe2b5dd04e6


Date: 11/15/2013 12:57:28 PM      
Sender: 14hm8rTdknVCDpqXGY5nFqVWruU9UBeuHd      
Amount Sent: 0.20000000 MSC      
Recipient: 1P8GMhC3qYkuvRRBsS5gqGegT7GvQoxAwY    

[zathras]

Actually, no. 8932.02057119

I've run some test cases and I can get your number - same as before mate, you're using 9 decimal places in your dev MSC total.

In this part of your formula

Code:

* 0.1 * 563162.23576222

you are effectively multiplying by 56316.223576222 - note the additional decimal.  You can fix your code by changing:

Code:

(1-(0.5**time_difference)) * 0.1 * 563_162.23576222

to either of:

Code:

(1-(0.5**time_difference)) * 56316.22357622

Code:

(1-(0.5**time_difference)) * (0.1 * 563_162.23576222).round(8)

I've been hammered with the day job this last week but I can see there is some stuff I need to catch up on the main thread (eg Luke's patch).  I'm determined to get the Masterchest update out today, at least to the website - once I've got that finished I'll catch up on what's been happening.

Thanks!

[Bitoy]

https://bitcointalk.org/index.php?topic=334316.0

I am hereby announcing the first release of a the first patch for miners to filter address reuse:
unique_spk_mempool for bitcoind 0.8.5
For now, since this is still somewhat common, this just deprioritises it to one reuse per block.
If I have time, I plan to write patches to be more and less aggressive that miners can choose between (or maybe others will beat me to it!).

This is an interesting problem to solve.

Without the exodus address, we can just parse the block looking for .000006 transactions.  (Right now I just check the exodus address for transactions)

Thoughts?

[LOL]

https://bitcointalk.org/index.php?topic=334316.0

I am hereby announcing the first release of a the first patch for miners to filter address reuse:
unique_spk_mempool for bitcoind 0.8.5
For now, since this is still somewhat common, this just deprioritises it to one reuse per block.
If I have time, I plan to write patches to be more and less aggressive that miners can choose between (or maybe others will beat me to it!).

This is an interesting problem to solve.

Without the exodus address, we can just parse the block looking for .000006 transactions.  (Right now I just check the exodus address for transactions)

Thoughts?

Anybody who is using the bitcoin protocol for anything other than shuffling money is going to use the smallest standard transaction. Parsing for an output of a specific value would narrow it down, sure, but I don't know if it'd be worthwhile as the "flag" that identifies a mastercoin transaction - it would only do a decent job at separating transactions where moving bitcoin is the main intent from transactions associated with blockchain-notary, colored coin, mastercoin, and of course the losing rolls of Satoshi Dice.


I have an idea that may actually solve the concern with mastercoin that the exodus address is "privileged" due to receipt of bitcoin for every mastercoin transaction. It should work conceptually, however I'm not sure how it would affect mastercoin explorers and if the implementation of validating the mastercoin transactions would be feasible.

At a predetermined blockchain height (by which time the exodus will have unspent outputs totaling 0.0 BTC) the private key of the exodus address is made public. Any mastercoin transaction above the height at which the exodus address's private key is revealed will be identified as follows:

The output of a mastercoin transaction that currently goes to the exodus address will be replaced with an address that is generated on-the-fly in a manner that allows the movement of mastercoin to be publicly verified, yet the bitcoin output claimable only by the sender. The "identifying" output will be to the address that is generated by combining the public key of the change address with the private key of the exodus address (see Casascius's "Key Combiner" in the bitcoin address utility). The way this works is that an address is generated with the private key of the exodus address with the public key of the change address - however in order to spend the bitcoin sent to that address, BOTH private keys are required. The result:

1.) Mastercoin transactions no longer make donations to any entity (and not at the expense of creating unspendable outputs).
2.) Mastercoin transactions would not be deprioritized (or left unconfirmed) due to reuse of the exodus address.
3.) Potentially very good for mastercoin's image. Maybe it would feel much less centralized?
4.) Significantly more difficult to calculate balances (correct me if I'm wrong here - speculation)
5.) Requires a change/4th output.


Few other notes while I'm thinking about it:

• Mastercoin transaction identified as a transaction in which the change address, when combined with the private key of the exodus address, produces an address that also received bitcoin in that transaction.
• Probably some interesting things that can be done with redeeming the bitcoin sent to the "identifying" address. Spending the bitcoin from that address can be defined as some option/feature/choice that the sender can make. (or maybe a game, the sender bets x mastercoin and sends it to the opponent. The opponent has to spam this address with the intent of keeping the sender from confirming a transaction to retrieve his deposit. If address emptied before agreed upon time limit/# of blocks, mastercoin is "charged back" and sender keeps extra bitcoin in identifying address. If address isn't emptied, opponent wins the mastercoin minus anything sent to the identifying address.)

[Luckybit]

I'm not sure Armory has coin control. Can you freeze addresses? If so you could freeze everything but your MSC address.

An other option is to use mastercoin-explorer to create the transaction for you and then sign it using Armory and broadcast it.

Armory has coin control. It's one of the expert features.

[maxmint]

Question to all devs working on creating a distributed exchange: in your opinion, what's a realistic timeframe for a decentralized MSC <> BTC exchange? 1 week? 2 weeks? 1 month?

Together with Pouncer I'm running the Mastercoin order book. Adding and editing entries is done manually and takes quite a lot of time.
So I was thinking about setting up a self-service order book where people could add, edit and remove orders on their own. This would be done by signing messages with their Mastercoin addresses so there would be no fake orders (balance of addresses can be easily checked using the Mastercoin-explorer API).

Creating such an improved order book would take some time and effort and I'm wondering if it makes sense to do this at this point in time. If we have a working decentralized exchange within a week or two it might be better to continue with the current order book. But if we're talking about a month then I guess it would make sense to invest time in an improved order book. After all, Mastercoin trades are really booming right now.

So what's your estimates, when will we see a decentralized MSC <> BTC exchange?

[Luckybit]

Question to all devs working on creating a distributed exchange: in your opinion, what's a realistic timeframe for a decentralized MSC <> BTC exchange? 1 week? 2 weeks? 1 month?

Together with Pouncer I'm running the Mastercoin order book. Adding and editing entries is done manually and takes quite a lot of time.
So I was thinking about setting up a self-service order book where people could add, edit and remove orders on their own. This would be done by signing messages with their Mastercoin addresses so there would be no fake orders (balance of addresses can be easily checked using the Mastercoin-explorer API).

Creating such an improved order book would take some time and effort and I'm wondering if it makes sense to do this at this point in time. If we have a working decentralized exchange within a week or two it might be better to continue with the current order book. But if we're talking about a month then I guess it would make sense to invest time in an improved order book. After all, Mastercoin trades are really booming right now.

So what's your estimates, when will we see a decentralized MSC <> BTC exchange?

It's not just you. Traffic has increased dramatically for Mastercoin. The Giveaway thread has had more traffic this past week than ever before. It's only a matter of time before I will not be able to keep up. These are good things but it I suspect our services will be replaced soon by automated techniques which will be better for us because there is a lot of other contests and jobs to do now.

[zathras]

Question to all devs working on creating a distributed exchange: in your opinion, what's a realistic timeframe for a decentralized MSC <> BTC exchange? 1 week? 2 weeks? 1 month?

Together with Pouncer I'm running the Mastercoin order book. Adding and editing entries is done manually and takes quite a lot of time.
So I was thinking about setting up a self-service order book where people could add, edit and remove orders on their own. This would be done by signing messages with their Mastercoin addresses so there would be no fake orders (balance of addresses can be easily checked using the Mastercoin-explorer API).

Creating such an improved order book would take some time and effort and I'm wondering if it makes sense to do this at this point in time. If we have a working decentralized exchange within a week or two it might be better to continue with the current order book. But if we're talking about a month then I guess it would make sense to invest time in an improved order book. After all, Mastercoin trades are really booming right now.

So what's your estimates, when will we see a decentralized MSC <> BTC exchange?

It's difficult to estimate - there's a lot of effort going into it but we want to make sure we do it right. 

I've hardcoded for test MSC only in my wallet (which I haven't even released yet) & I think Tachikoma has done the same - we'll need to see reliable and repeatable test MSC distributed exchange transactions happening that we all agree on - only then would we allow exchange of real MSC.

Speaking of which - Tachikoma, I'm keen to identify why our orderbook states don't match.  I've taken a quick look at Bitoy's site and his orderbook state looks like mine - I'll look into each transaction to see if I can figure out where we differ.  Is your orderbook on mastercoin-explorer your latest? 

I've uploaded the working copy of my next update to https://masterchest.info/sneakpeek - it looks a little different as I skinned it to look more like my wallet.  You can see my order book & current parsing of exchange transactions there.  Note this is not the completed update, just a WIP but it'll at least allow you to see what my engine is doing with the transactions.  Oh and on the subject of the dev MSC calculations you can use https://masterchest.info/sneakpeek/lookupadd.aspx?address=1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P to check your dev MSC numbers against mine (as at time of latest block).

Thanks!

[superfluouso]

I've uploaded the working copy of my next update to https://masterchest.info/sneakpeek - it looks a little different as I skinned it to look more like my wallet.  You can see my order book & current parsing of exchange transactions there.  Note this is not the completed update, just a WIP but it'll at least allow you to see what my engine is doing with the transactions. 
Thanks!

Wow! That looks awesome!  I can't wait.  Any eta on releasing your wallet for testing?

[zathras]

I've uploaded the working copy of my next update to https://masterchest.info/sneakpeek - it looks a little different as I skinned it to look more like my wallet.  You can see my order book & current parsing of exchange transactions there.  Note this is not the completed update, just a WIP but it'll at least allow you to see what my engine is doing with the transactions. 
Thanks!

Wow! That looks awesome!  I can't wait.  Any eta on releasing your wallet for testing?

Thanks   Re my wallet, not too long I hope - I want to make sure we all (the devs) are seeing exchange transactions the same way first.