rbdrbd



Offline



Activity: 462

Merit: 250









Sr. MemberActivity: 462Merit: 250 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) November 10, 2013, 05:57:11 PM #442 Quote from: Tachikoma on November 10, 2013, 05:51:42 PM



My implementation is based on Bitcoin-ruby, Zathras uses Bitcoin and Grazcoin Obelisk, loads of different backends

I'm already writing an rspec test-suite for my Rails implementation. It won't have 100% coverage but it will give you a good explanation of what to test for and how to implement it.My implementation is based on Bitcoin-ruby, Zathras uses Bitcoin and Grazcoin Obelisk, loads of different backends

Sounds great. Maybe it may make sense for your test suite cases to be standardized at some level eventually (and possibly maintained independently), so that other library implementations can use those same test cases. That would make debugging differences between implementations (and their bugs) more apples-to-apples, and give a good "baseline" point for new library/backend implementations.



Sounds great. Maybe it may make sense for your test suite cases to be standardized at some level eventually (and possibly maintained independently), so that other library implementations can use those same test cases. That would make debugging differences between implementations (and their bugs) more apples-to-apples, and give a good "baseline" point for new library/backend implementations.

Tachikoma



Offline



Activity: 938

Merit: 1000









Hero MemberActivity: 938Merit: 1000 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) November 11, 2013, 01:48:47 PM

Last edit: November 11, 2013, 06:09:55 PM by Tachikoma #446 Something has been bothering me when coding up my Mastercoin implementation these last few weeks. There is one thing in the spec that makes coding up Mastercoin implementations a lot harder and, because of this, less reliable then it has to be.



The position of a certain transaction in a given block. You constantly have to do two separate checks, 'is there a transaction in this block that has a position lower then the current one that can influence this message?' if not 'query all previous blocks for the information' that you need. It also contributes to the 'random chance' effect I already spoke about. Depending on the position of your transaction in a given block it might be either invalid or valid.



I hate chance, and I would like to eliminate it as a factor for Mastercoin.



My proposal would make everything a lot cleaner and easier to work with but would introduce a 1 block lag.



Current situation

User A creates a 'Selling Offer' of 1 MSC for 0.1 BTC in block 25

User B creates a 'Purchase Offer' of this 1 MSC while User A modifies it's original order to now sell 1 MSC for 0.9 MSC. Both transactions end up in block 26 but the modified 'Selling offer' ends up above the 'Purchase Offer'.



If user B still wants to buy user a's offer he now needs to pay 0.9 while if luck was different he could have paid 0.1 BTC.



Artificial 1 Block lag

User A creates a 'Selling Offer' of 1 MSC for 0.1 BTC in block 25

User B creates a 'Purchase Offer' of this 1 MSC while User A modifies it's original order to now sell 1 MSC for 0.9 MSC. Both transactions end up in block 26.



However to get all information this time we skip checking the current block and only look at what happend before this block. The offer gets matched up to the original one regardless of which position the changed 'Selling Offer' ended up with.



I understand if this is a controversial topic but I want to bring it up anyway because I really believe this will make everything better.



Opinions!?

Electrum : the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported

Bitoy



Offline



Activity: 449

Merit: 250







Sr. MemberActivity: 449Merit: 250 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) November 11, 2013, 02:42:19 PM #447 Quote from: Tachikoma on November 11, 2013, 01:48:47 PM Something has been bothering me when coding up my Mastercoin implementation these last few weeks. There is one thing in the spec that makes coding up Mastercoin implementations a lot harder and, because of this, less reliable then it has to be.



The position of a certain transaction in a given block. You constantly have to do two separate checks, 'is there a transaction in this block that has a position lower then the current one that can influence this message?' if not 'query all previous blocks for the information' that you need. It also contributes to the 'random chance' effect I already spoke about. Depending on the position of your transaction in a given block it might be either invalid or valid.



I hate chance, and I would like to eliminate it as a factor for Mastercoin.



My proposal would make everything a lot cleaner and easier to work with but would introduce a 1 block lag.



Current situation

User A creates a 'Selling Offer' of 1 MSC for 0.1 BTC in block 25

User B creates a 'Purchase Offer' of this 1 MSC while User A modifies it's original order to now sell 1 MSC for 0.9 MSC. Both transactions end up in block 26 but the modified 'Selling offer' ends up above the 'Purchase Offer'.



If user B still wants to buy user a's offer he now needs to pay 0.9 while if luck was different he could have paid 0.1 BTC.



Artificial 1 Block lag

User A creates a 'Selling Offer' of 1 MSC for 0.1 BTC in block 25

User B creates a 'Purchase Offer' of this 1 MSC while User A modifies it's original order to now sell 1 MSC for 0.9 MSC. Both transactions end up in block 26.



However to get all information this time we skip checking the current block and only look at what happend before this block. The offer gets matched up to the original one regardless of which position the changed 'Selling Offer' ended up with.



I understand if this is a controversial topic but I want to bring it up anyway because I really believe this will make everything better.





We can give priority to purchase offer over selling offer is they have the same block time.

That way user b will get the price at .1 We can give priority to purchase offer over selling offer is they have the same block time.That way user b will get the price at .1

grazcoin



Offline



Activity: 284

Merit: 250









Sr. MemberActivity: 284Merit: 250 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) November 11, 2013, 08:23:56 PM #456 Quote from: Bitoy on November 11, 2013, 02:42:19 PM Quote from: Tachikoma on November 11, 2013, 01:48:47 PM Something has been bothering me when coding up my Mastercoin implementation these last few weeks. There is one thing in the spec that makes coding up Mastercoin implementations a lot harder and, because of this, less reliable then it has to be.



The position of a certain transaction in a given block. You constantly have to do two separate checks, 'is there a transaction in this block that has a position lower then the current one that can influence this message?' if not 'query all previous blocks for the information' that you need. It also contributes to the 'random chance' effect I already spoke about. Depending on the position of your transaction in a given block it might be either invalid or valid.



I hate chance, and I would like to eliminate it as a factor for Mastercoin.



My proposal would make everything a lot cleaner and easier to work with but would introduce a 1 block lag.



Current situation

User A creates a 'Selling Offer' of 1 MSC for 0.1 BTC in block 25

User B creates a 'Purchase Offer' of this 1 MSC while User A modifies it's original order to now sell 1 MSC for 0.9 MSC. Both transactions end up in block 26 but the modified 'Selling offer' ends up above the 'Purchase Offer'.



If user B still wants to buy user a's offer he now needs to pay 0.9 while if luck was different he could have paid 0.1 BTC.



Artificial 1 Block lag

User A creates a 'Selling Offer' of 1 MSC for 0.1 BTC in block 25

User B creates a 'Purchase Offer' of this 1 MSC while User A modifies it's original order to now sell 1 MSC for 0.9 MSC. Both transactions end up in block 26.



However to get all information this time we skip checking the current block and only look at what happend before this block. The offer gets matched up to the original one regardless of which position the changed 'Selling Offer' ended up with.



I understand if this is a controversial topic but I want to bring it up anyway because I really believe this will make everything better.





We can give priority to purchase offer over selling offer is they have the same block time.

That way user b will get the price at .1

We can give priority to purchase offer over selling offer is they have the same block time.That way user b will get the price at .1

Giving priority to purchase offer over selling offer in the same block is a better name for "Artificial 1 Block lag".

This solution means that any increase in price (or even a try to cancel the offer), could be easily attacked by listening to unconfirmed tx, and sending accept immediately.

I still like the original "random" way that Bitcoin imposes, but I will not insist on it



Giving priority to purchase offer over selling offer in the same block is a better name for "Artificial 1 Block lag".This solution means that any increase in price (or even a try to cancel the offer), could be easily attacked by listening to unconfirmed tx, and sending accept immediately.I still like the original "random" way that Bitcoin imposes, but I will not insist on it

GPG key ID: B29A528142A29BF9 , and OTC ID:

* Check My BTC Tip Jars: https://blockchain.info/address/1GRazCon4gDqTh1pMNyh1xHVWnbQEVPfW8 GPG key ID: B29A528142A29BF9 , and OTC ID: http://bitcoin-otc.com/viewgpg.php?nick=grazcoin * Check https://masterchain.info

Tachikoma



Offline



Activity: 938

Merit: 1000









Hero MemberActivity: 938Merit: 1000 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) November 11, 2013, 08:28:57 PM #457



The thing I might not have explained enough is that I think this artificial lag should be protocol wide if we would even consider doing it. This would mean that Simple Sends that receive and send coins in the same block would also be invalid if the proper amount of the outgoing coins was not sufficient before this block, etc.



Grazcoin, Zathras, Bitboy could you please join the discussion on PR #1 here I'm not even sure I'm 100% behind it, but it would make parsing much more straight forward.The thing I might not have explained enough is that I think this artificial lag should be protocol wide if we would even consider doing it. This would mean that Simple Sends that receive and send coins in the same block would also be invalid if the proper amount of the outgoing coins was not sufficient before this block, etc.Grazcoin, Zathras, Bitboy could you please join the discussion on PR #1 here https://github.com/mastercoin-MSC/spec/pull/1 Electrum : the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported