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

[dacoinminster]

That still doesn't answer the main question though.

Should multiple transaction be accumulated and should the sum be used to match the purchase order
 or
Should the highest transaction be counted and matched to a purchase order

If we're talking about attempts to reserve MSC for purchase, the latest attempt replaces any earlier ones. I doubt the spec says that explicitly, but it should.

If we're talking about attempts to pay for MSC which has been reserved, then definitely accumulate, otherwise the buyer potentially loses money!

A pull request clarifying all this would be most welcome

[Tachikoma]

Good, I was hoping for that answer. I am about to head to bed but will write up a PR in the morning. If somebody disagrees let me know.

[Super T]

Developers; I've been thinking about invalidating Purchase Offers which want to buy from a Selling Offer when the Selling Offer is exhausted. Normally you adjust the amount bough to the total amount for sale. But it's not stated what to do when the amount is actually zero. Technically it doesn't matter anyway because both transactions have zero impact on the balance but just to let people know what's going on, and make sure they don't end up paying I would still like to invalidate these type of transactions.

Just an example to make sure everybody understands me.

User A sells 10 MSC
User B buys 8 MSC and gets them
User C buys 2 MSC and gets them
User D sends his request for 5MSC just a little after C and gets added behind him in the block.

Right now user D's transaction would come through but the accepted amount would be 0 MSC. I would propose to invalid this transaction so it's clear this offer is sold out.

+1
User D's transaction should be invalid.

Hi - i'm a few weeks our of date on progress here, but have just read the last few pages, if there is a quick answer why this is the preferred approach i'd love to hear it, but considering a "late" buy offer as invalid seems a bit non-sensical to me.

Does this suggest orders must be individually matched against counter-party offers?  If so, how will support high volume trading scenarios?

I would expect any confirmed order (including an order attempting to fill a currently open offer) to remain valid until filled or cancelled - is there a reason why this model is not appropriate here?

Similarly I would expect an order for more than an offered amount to result in an open order for the outstanding quantity - no?

[zathras]

That still doesn't answer the main question though.

Should multiple transaction be accumulated and should the sum be used to match the purchase order
 or
Should the highest transaction be counted and matched to a purchase order

Can you clarify accumulation? 

Currently I look at things like this; say for example User A agrees to buy 5 MSC for 1 BTC.  User A then sends 5x 0.2 BTC in separate payments within the time limit.  My interpretation would be 5 separate purchases of 1 MSC each.  Net result buyer +5 MSC seller +1 BTC.

If you accumulated all those payments into one single payment of 1 BTC, this purchases 5 MSC.  Net result buyer +5 MSC seller +1 BTC.

Apologies I might be missing the point here but if the net result is the same, why try to handle accumulation at all?

[Tachikoma]

That's fine as well. I'm just saying that it specified nowhere how Purchase Orders should be paid. I just think the spec should be clear on the fact that you don't have to pay everything in one go. I've added some clarification it in this pull request.

[zathras]

While I'm on I'll also just note that the upload I did for a sneakpeek is not handling exchange transactions properly - I'm working on a fix - also I just want to be super clear about this, the sneakpeek is for the other devs to compare so we can pick up differences, everyone else please DO NOT trust it for any real usage, it's simply not ready yet.    

[zathras]

That's fine as well. I'm just saying that it specified nowhere how Purchase Orders should be paid. I just think the spec should be clear on the fact that you don't have to pay everything in one go. I've added some clarification it in this pull request.

Great sorry I missed the pull I'll head on over and check it out now. 

[Tachikoma]

Haha no I just updated it, we were on at the same time, you didn't miss it

[malefice]

Hi Mastercoiners,

I would like to devote some of my spare time to help with the Mastercoin project, that is because I want to be part of what it feels for me the right direction for bitcoin.
I presented bitcoin the first time at a local Barcamp in March 2013 and try be an advocate of it since then.

---
My Skills:

* I coded for food for over 15y in Java and am currently in a position of project manager and software architect in a governmental innovation center in Italy.
* I am a Scrum Master and experienced project manager
* I further have a academic background in Economics and Computer Science, and think of myself as a hobby data scientist.
--

I'm interested in the distributed exchange development.
To get in touch write to malefizer@ymail.com

[grazcoin]

while updating my parsing for less standard tx, I see BIP11->BIP11 tx like:
https://blockchain.info/tx/6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf
We never really said anything about more complicated addresses holding MSC (e.g. BIP11 or BIP16).
Until we say otherwise, I suggest that invalidate these tx:
http://masterchain.info/tx/6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf.json

That's how you parse it:
https://masterchest.info/lookuptx.aspx?txid=6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf
http://mastercoin-explorer.com/transactions/6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf

Respecting these addresses is not too difficult, so it is mainly a decision issue.

[grazcoin]

I propose the following for specifying how an unexpected purchase offer should function:

Late payment:

• User A broadcasts a sell offer, 1 MSC @ 0.2 MSC/BTC, time of 10 blocks
• User B broadcasts a purchase offer for 1 MSC at @0.2 MSC/BTC
• User B stars at the BTCChina charts for a couple hours, finally remembers his purchase offer, and broadcasts his payment which gets confirmed in block 12.
  
  

The transaction is valid because even though the payment was late, no other purchase offers had been confirmed in the time between blocks 10 and 12. Had a purchase offer been confirmed in block 12 as well, the transaction still would have been valid because a payment transaction moves value, not information. The circumstances under which a late payment wouldn't be valid are if 1.) a different valid purchase offer was confirmed in block 11 (because it's greater than 10, less than 12), 2.) the sell offer has been completely filled.

-1
This is not according to the contract that the seller offered.
If the buyer already sees that he might be late - he better not send the tx (and lose only the fee).
No need to complicate further the already complicated distributed exchange rules.

Multiple payments and of incorrect size

• User A broadcasts a sell offer, 1 MSC @ 0.2 MSC/BTC, time of 10 blocks
• User B broadcasts a purchase offer for 0.6 MSC at @0.2 MSC/BTC
• User B broadcasts a purchase offer for 0.25 MSC at @0.2 MSC/BTC
• Both of user B's purchase offers are confirmed in block 3, and are valid.
• User B broadcasts a payment transaction of 0.1 BTC which is confirmed and valid in block 5 - receives 0.5 MSC
• User B broadcasts a payment transaction of 0.07 BTC which is confirmed and valid in block 6 - receives 0.25 MSC

The first payment transaction of 0.1 BTC was valid despite not completely filling the purchase offer for 0.6 MSC. This is because payments must be able to accumulate up to the value specified in the purchase offer. The second payment was valid, however user B lost some BTC because a payment exceeding the value remaining on a purchase offer will not "roll over" to any other open purchase offers. The 0.25 MSC purchase offer was filled with the payment of 0.07 BTC. The purchase offer that has the larger value remaining to be purchased should be filled in these circumstances, to as to minimize lost BTC.

Just as payment transactions are cumulative, so are purchase offers. Two (or more) purchase offers from the same person may be "active" at the same time. There's no guarantee that one will be confirmed before the other - once broadcast it's out of your hands. If "latest one counts" then this requires an association of data across multiple purchase offers, in different blocks, and is drastically more complicated than treating them as just separate purchase offers. Also, it brings up questions like: If 2 purchase offers from the same address are confirmed in different blocks, but within the time range does this extend the reservation out?

Since we allow only one sell offer for an address, we could consider only one purchase offer for an address to simplify the protocol.
I don't see a real reason to complicate the logic here too much, so if we do keep multiple purchase offer option, let it follow the basic rules, ignoring the fact that these are purchase orders from the same address.

[Tachikoma]

I propose the following for specifying how an unexpected purchase offer should function:

Late payment:

• User A broadcasts a sell offer, 1 MSC @ 0.2 MSC/BTC, time of 10 blocks
• User B broadcasts a purchase offer for 1 MSC at @0.2 MSC/BTC
• User B stars at the BTCChina charts for a couple hours, finally remembers his purchase offer, and broadcasts his payment which gets confirmed in block 12.
  
  

The transaction is valid because even though the payment was late, no other purchase offers had been confirmed in the time between blocks 10 and 12. Had a purchase offer been confirmed in block 12 as well, the transaction still would have been valid because a payment transaction moves value, not information. The circumstances under which a late payment wouldn't be valid are if 1.) a different valid purchase offer was confirmed in block 11 (because it's greater than 10, less than 12), 2.) the sell offer has been completely filled.

-1
This is not according to the contract that the seller offered.
If the buyer already sees that he might be late - he better not send the tx (and lose only the fee).
No need to complicate further the already complicated distributed exchange rules.

Multiple payments and of incorrect size

• User A broadcasts a sell offer, 1 MSC @ 0.2 MSC/BTC, time of 10 blocks
• User B broadcasts a purchase offer for 0.6 MSC at @0.2 MSC/BTC
• User B broadcasts a purchase offer for 0.25 MSC at @0.2 MSC/BTC
• Both of user B's purchase offers are confirmed in block 3, and are valid.
• User B broadcasts a payment transaction of 0.1 BTC which is confirmed and valid in block 5 - receives 0.5 MSC
• User B broadcasts a payment transaction of 0.07 BTC which is confirmed and valid in block 6 - receives 0.25 MSC

The first payment transaction of 0.1 BTC was valid despite not completely filling the purchase offer for 0.6 MSC. This is because payments must be able to accumulate up to the value specified in the purchase offer. The second payment was valid, however user B lost some BTC because a payment exceeding the value remaining on a purchase offer will not "roll over" to any other open purchase offers. The 0.25 MSC purchase offer was filled with the payment of 0.07 BTC. The purchase offer that has the larger value remaining to be purchased should be filled in these circumstances, to as to minimize lost BTC.

Just as payment transactions are cumulative, so are purchase offers. Two (or more) purchase offers from the same person may be "active" at the same time. There's no guarantee that one will be confirmed before the other - once broadcast it's out of your hands. If "latest one counts" then this requires an association of data across multiple purchase offers, in different blocks, and is drastically more complicated than treating them as just separate purchase offers. Also, it brings up questions like: If 2 purchase offers from the same address are confirmed in different blocks, but within the time range does this extend the reservation out?

Since we allow only one sell offer for an address, we could consider only one purchase offer for an address to simplify the protocol.
I don't see a real reason to complicate the logic here too much, so if we do keep multiple purchase offer option, let it follow the basic rules, ignoring the fact that these are purchase orders from the same address.

I completely agree with Grazcoin on this one. There is enough difficult logic already involved even without making things harder to parse. We should keep it as simple as possible and add more interesting options when we mature enough.

while updating my parsing for less standard tx, I see BIP11->BIP11 tx like:
https://blockchain.info/tx/6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf
We never really said anything about more complicated addresses holding MSC (e.g. BIP11 or BIP16).
Until we say otherwise, I suggest that invalidate these tx:
http://masterchain.info/tx/6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf.json

That's how you parse it:
https://masterchest.info/lookuptx.aspx?txid=6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf
http://mastercoin-explorer.com/transactions/6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf

Respecting these addresses is not too difficult, so it is mainly a decision issue.

I agree with you on this mainly because I don't want to spend anytime going back to the beginning to support this one edge-case. We can add support for those addresses in later.

[Bitoy]

-1
This is not according to the contract that the seller offered.
If the buyer already sees that he might be late - he better not send the tx (and lose only the fee).
No need to complicate further the already complicated distributed exchange rules.


Since we allow only one sell offer for an address, we could consider only one purchase offer for an address to simplify the protocol.
I don't see a real reason to complicate the logic here too much, so if we do keep multiple purchase offer option, let it follow the basic rules, ignoring the fact that these are purchase orders from the same address.

I agree with you on simplifying the system.  Allowing only one purchase offer for an address per currency.

[Bitoy]

Hi Zathras,

Can you post again how to send a multisig using your library (You posted this before but I can't find it =).

Thanks.


(I'm trying to build a thin client windows wallet rpc blockchain.info but blockchain.info doesn't support "listunspent".  )   

[zathras]

while updating my parsing for less standard tx, I see BIP11->BIP11 tx like:
https://blockchain.info/tx/6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf
We never really said anything about more complicated addresses holding MSC (e.g. BIP11 or BIP16).
Until we say otherwise, I suggest that invalidate these tx:
http://masterchain.info/tx/6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf.json

That's how you parse it:
https://masterchest.info/lookuptx.aspx?txid=6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf
http://mastercoin-explorer.com/transactions/6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf

Respecting these addresses is not too difficult, so it is mainly a decision issue.

I agree we should invalidate for now.  I'll add some code to invalidate these.

Since we allow only one sell offer for an address, we could consider only one purchase offer for an address to simplify the protocol.
I don't see a real reason to complicate the logic here too much, so if we do keep multiple purchase offer option, let it follow the basic rules, ignoring the fact that these are purchase orders from the same address.

I completely agree with Grazcoin on this one. There is enough difficult logic already involved even without making things harder to parse. We should keep it as simple as possible and add more interesting options when we mature enough.

My view sits with Grazcoin and Tachikoma, we're complex enough already.  Future revisions can add features to the base implementation, but we need to walk before we run.

Hi Zathras,

Can you post again how to send a multisig using your library (You posted this before but I can't find it =).

Thanks.

(I'm trying to build a thin client windows wallet rpc blockchain.info but blockchain.info doesn't support "listunspent".  )  

You are of course welcome to use any of my code (though I'll need to push up the latest version of the library, it's out of date on git).  With that said though, I don't think it's going to help you in this case.  My library depends on a bitcoind/qt instance to loop through the unspent outputs for a given address and select inputs to use as vins for the send transaction.  It's not really suited to a thin client.

I had intended to modify my wallet to support thin client functionality way, way down the track - it's not high on my priority list though (since Tachikoma has taken point on thin client to date) - my primary focus is on a local implementation with no centralized source of truth for now.  Once we all have compatible APIs (and thus multiple sources of truth) thin client functionality will likely get pushed up my priority list more.

Thanks!

[TKeenan]

For a brief moment yesterday - the bounty on this coding contest exceeded $270,000 in value.  That is far more than JR originally anticipated (around Aug 10) would be spend on the entire project - start-to-finish.  Glad you guys are working hard on this.  You sure are going to earn one hell of a lot of money.  

[Bitoy]

You are of course welcome to use any of my code (though I'll need to push up the latest version of the library, it's out of date on git).  With that said though, I don't think it's going to help you in this case.  My library depends on a bitcoind/qt instance to loop through the unspent outputs for a given address and select inputs to use as vins for the send transaction.  It's not really suited to a thin client.

I had intended to modify my wallet to support thin client functionality way, way down the track - it's not high on my priority list though (since Tachikoma has taken point on thin client to date) - my primary focus is on a local implementation with no centralized source of truth for now.  Once we all have compatible APIs (and thus multiple sources of truth) thin client functionality will likely get pushed up my priority list more.

Thanks!

Thank you for the heads up. My only problem now is how to send a multisig (rpc).   

Agreed, once we have compatible api we can easily check double check transactions. 

[Bitoy]

For a brief moment yesterday - the bounty on this coding contest exceeded $270,000 in value.  That is far more than JR originally anticipated (around Aug 10) would be spend on the entire project - start-to-finish.  Glad you guys are working hard on this.  You sure are going to earn one hell of a lot of money.  

Yes, crazy bitcoin price the last few days.  Now coding contest is around 150k. That is still a lot of money

[zathras]

You are of course welcome to use any of my code (though I'll need to push up the latest version of the library, it's out of date on git).  With that said though, I don't think it's going to help you in this case.  My library depends on a bitcoind/qt instance to loop through the unspent outputs for a given address and select inputs to use as vins for the send transaction.  It's not really suited to a thin client.

I had intended to modify my wallet to support thin client functionality way, way down the track - it's not high on my priority list though (since Tachikoma has taken point on thin client to date) - my primary focus is on a local implementation with no centralized source of truth for now.  Once we all have compatible APIs (and thus multiple sources of truth) thin client functionality will likely get pushed up my priority list more.

Thanks!

Thank you for the heads up. My only problem now is how to send a multisig (rpc).   

Agreed, once we have compatible api we can easily check double check transactions. 

If you're using blockchain.info have a look at http://blockchain.info/unspent?active=$address - I could (fairly) easily give you a new function in the library that only returns the transaction hex for the vouts (ie the juicy multisig bits - which can be done offline, no need for bitcoind/qt).

You could construct the first part of the transaction hex (vins) using the info from blockchain.info's unspent API and then put the two together prior to signing.

Without looking at what you're trying to do further I don't know if this will help, but just a thought

[dexX7]

while updating my parsing for less standard tx, I see BIP11->BIP11 tx like:
https://blockchain.info/tx/6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf
We never really said anything about more complicated addresses holding MSC (e.g. BIP11 or BIP16).
Until we say otherwise, I suggest that invalidate these tx:
http://masterchain.info/tx/6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf.json

That's how you parse it:
https://masterchest.info/lookuptx.aspx?txid=6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf
http://mastercoin-explorer.com/transactions/6d68b101c8b92b38c02595a084aa5c8b0308c4f2f5714070d7656251075dbbcf

Respecting these addresses is not too difficult, so it is mainly a decision issue.

Hi,

I made those tx as a test, because I was looking into ways to reduce transportation cost for the faucet, but switched over to regular multisig tx, because they were marked as invalid on mastercoin-explorer, if I recall correctly.

But I noticed that all outgoing transactions of 14hm8rTdknVCDpqXGY5nFqVWruU9UBeuHd are rendered as invalid on mastercoin-explorer.com since some hours:

http://mastercoin-explorer.com/addresses/14hm8rTdknVCDpqXGY5nFqVWruU9UBeuHd

mastercoin.info and masterchest.info still declare them as valid.

Is this in anyway connected? The above quoted tx are derived from this address.