Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) - page 4. (Read 129205 times)

http://mymastercoins.com/viewaddresstrans.aspx?address=182osbPxCo88oaSX4ReJwUr9uAcchmJVaL

Although in same block 289755 the payment came first before the purchase offer 9ecd.  I didn't consider the block number only the order.

42f470   3/9/2014 8:43:46 PM   289755   Valid   Payment: 0.0005 btc for 0.005 TMSC
36ef61   3/9/2014 8:43:46 PM   289755   Valid   Payment: 0.001 btc for 0.01 TMSC
df3b38   3/9/2014 8:43:46 PM   289755   Valid   Payment: 0.002 btc for 0.01 TMSC
9ecd7a   3/9/2014 8:43:46 PM   289755   Valid   Purchase Offer: 0.05 TMSC

Hi Zathras,

Sorry, but I couldn't join at that time.
Although I think for protocol beauty reasons, there shouldn't be rules against buying from specific addresses ("self address"), I don't mind adding this rule if it takes us in a smoother way closer to consensus. It doesn't have any affect of balance consensus - only on transaction consensus.
I do insist on the option to send coins to one self - as I think it is important (having in mind a 3rd level protocol on top of mastercoin one day - but I think you support send to self anyway).

So bottom line:
If you see that it makes your life much easier, I'll code the change and request mymastercoin to follow.

Hey Graz,

Shame we couldn't have you on the dev sync this morning

Re the same block discussion, I actually agree with your logic but it's not how Masterchest is coded.  I put forward your case for allowing different parts of a DEx transaction to occur same block & as much as it means extra changes for me we suggested that it's the better way to go.  This has been accepted by J.R. & Craig, so I will now (attempt) to code to match you guys.

Re an address buying coins from its own sell order, it's been agreed there is no use case for this so it doesn't matter one way or the other - it's a question of what's easiest to get consensus - me allowing it or you guys disallowing it.  I'm taking a look over my code now.

EDIT: OK, Class B requires that change is returned to sender, so where the sender is an output that output is determined to be change.  This transaction https://blockchain.info/tx/a4be2bc89c0b11977ed907605993680ea893ebe316878586f05bd755275f559b has effectively two change outputs and no reference address.  As I start to review my code I'm thinking an address buying coins from its own sell will raise problems and solve none.  Can you guys disallow this?

Thanks
Zathras

I fully agree with grazcoin. Rejecting transactions because they are in the same block is not intuitive and I don't see any real reason why this should be enforced in the first place. How do you handle payments for accepts that are in the same block?

An advanced and somewhat risky play could be for example: I send an accept offer transaction and use it's change output to send the payment right after. In this case both transactions will most likely be in the same block (but ordered) and I get my MSC as fast as possible - though I run into the risk that I pay for something that was not accepted and already sold/canceled, but that may be acceptable.

Re the case above: worst case I see right now could be that users start to spam accept offers, but in this case they still need to pay all MSC related fees (the DEX fee + Exodus anti spam fee), so this should be allowed in my opinion.

In general: by using the change of the previous transaction the order within a block can be enforced and given the fact that most MSC wallets probably only have dust outputs and one large unspent output available for the next transaction, the order is given very naturally.

In the last 2 weeks I see 4825 entries of wallet with uuid, of which 1501 were unique.
You have to remember that until now the cloud part is not deployed, so all wallet usage is done locally inside the browser.

You should subscribe to our blog, we post regular updates there.
We are not pushing out Omniwallet too strongly yet because unlike the other wallets it is not operational yet (however it is ready for testing, there are bounties for bug reports and of course development).


I am the first to agree that there is a lot more to be done in terms of usability.
Adding a bundled bitcoind with MasterChest is a good idea and is on our plans.
I opened an issue to track that on github.

It does take a bit of pain to setup a.t.m, but it's honestly not that hard (you can ask in our skype group for help - ping me (ripper234 on skype) and I'll add you to the group.


A big part of the problem IMO is that we had a lot of duplication of effort here until now between the different developers.
That is going to change moving forward.

Thanks for the reply. You seem to have a very hands on approach which can only help going further.

I didn't even know about this OmniWallet https://test.omniwallet.org/ which seems to be closer to blockchain.info in terms of design and usability.

I own some MSC because I see lot of potential here, but so far the exchange wallet is best one and only one and could actually use. I've tried the My Mastercoins V2 wallet as it seemed most user friendly and got errors during installation. Masterchest I didn't even bother using when I saw the huge instruction list and dependencies. Perhaps you should put this OmniWallet at the landing page, not this overcomplicated to use Masterchest. Why not make an installation bundle for this Masterchest that also includes Bitcoin qt wallet if that's really required, that does the settings automatically like those old codec packs? Don't see why this is so hard to make. Most other coins have straight and forward "click next next done" type wallets and many users expect something like this on a landing page, not something with dependencies and dozen of steps. For eg I don't even use the Bitcoin qt wallet and have to install it separately.

Nice to see you're changing your bounty policy. I assume different devs worked on these wallets and they might not be around to finish them and bring into a polished product, unless they take on another bounty. It's much better, from what I've heard from coder friend that works for Google, to get a decent product done yourself instead of patching someone else's work, which might be worst than starting from scratch.

masterchain does not enforce the limitation you suggested, and I suspect that mymastercoins does not enforce such a limitation either.
Payments following an accept, are not invalidated due to being in the same block.
This may cause problem you may not expect:
Imagine a case where a reorg of the blockchain causes an accept/payment from current block to belong to the next.
Masterchain shouldn't be concerned by this technical bitcoin issue, but according to your suggestion, on one fork the payment would be invalid where on the other it would be valid.
I think that as long as the payment is after the accept - the common sense would say it is valid.


General rule is to let users decide to do what they want, and not enforce extra limitations.
A normal user would not even see the accept on masterchain.info until the block is long confirmed, parsed and validated.
If some advanced user listen to the bitcoin network stream and sees the need to send accept or even pay unconfirmed sell offer - I don't want to stop him. Maybe he has a good reason to do that. Why should we close this option by artificial rules?

I fully agree with the your point, even though I disagree with the action items.
I don't see sloppy job here, I see job that needs to be continued and refined.

The action items that we will be taking:

1. We are knee-deep in development of the Omniwallet - a wallet designed with usability in mind from the get go. It's not ready for production use yet, but you can check out the current state of affairs on the test server, and follow the development on github.
2. We will changing our development/bounty methodology significantly very soon. Please expect a blog post about this in the coming days.
3. However - we are going to respect any obligation that we made. We committed to giving out $100,000 + extra Dev MSC in bounties for both February and March, divided between any contributors according to the work they did - and we are honoring that commitment.

The DEx itself is going to be live on March 15, even though the UX is less than optimal.
Improving the user experience of the wallets is a major priority for us and me personally.

Please do your bit by trying out the wallets and reporting on github any issues you find (all github repos are linked to from mastercoinwallets.org)

I appreciate your viewpoint but I don't think that's necessarily true.  We already observe block boundaries for separating stages in a DEx transaction - for example you have to wait until an accept is confirmed in a block before sending payment (ie an accept and its associated payments can't be in the same block).

When a client transmits these transactions there is no guarantee that the miner who eventually mines the next block will include the transactions in the same order they were originally broadcast.  The different transactions will end up taking disparate routes to the miner that ends up mining the block and when relaying through the various hops is complete the miner may receive the first transaction after the second.  Thus it's possible even though the payments were broadcast before the accept, that when the block is mined the accept is before the payments in the block.  Thus when you mention random chance allowing this does exactly that - whether the accept would be valid is entirely dependent in what order the eventual mining node received them/added them to the block.

Forcing things (like accepts and payments) to be confirmed in a block before moving on to the next stage I think is actually pretty core to the way our DEx operates

The mastercoin protocol is not aware of anything outside the blockchain and has no perception of "time" - only order. Users are allowed to send whichever transaction they like, and the parsing implementations enforce the protocol (e.g. sometimes by invalidating transactions).
Although we think of transactions as "transmitted", we should keep in mind that they can also get included in a block by the miner without ever being transmitted. It happens very often that nodes get to know about a tx only when they get it in the next block.

Those splits into blocks are random, and actually masterchain protocol could ignore them and only look on the order of the transactions in the blockchain (except for the accept timeout feature that measures expiration time using the block height).
Introducing a "time" component is wrong and may cause bugs. You never know what is before or after - the blockchain order is the only consensus out there.

Also a user - he has no idea when his accept gets included in the blockchain. Do you want a randomly fact like mined block to determine if his accept is valid or not? A more intuitive usage would be to fully pay his last accept, and when he is done to create a new accept. If that happened to be in the same block (as there are sometimes 1h gaps between blocks), the accept shouldn't be affected.

Bottom line - I think the change you suggest is wrong.
To implement it should be possible, but again - it would be another testing deployment cycle that I would rather avoid, also since we're so close to deadline.

Hey Graz,

Agree that in this case the next accept offer is ordered after the payments in the same block.

But at the time the accept was transmitted, the previous payments inherently had to have been unconfirmed (for them both to be in the same block) so the sender has no way of knowing if that accept would be before or after the payments.  It's much cleaner to say they're not allowed same block.  I'll have to go through and add more code to support a scenario I thought we'd all agreed was not allowed (broadcasting a new accept before the previous accept has been confirmed closed).

How hard is it for you guys to enforce that users can't send new accepts while the payments for the previous accepts are still unconfirmed? (ie invalidate accepts in the same block as payment for previous accept)

Hi Zathras,

I think this accept should be valid, and I explain below.

we're talking about sell offer https://masterchain.info/selloffer.html?tx=ccc6c0ed758c42a950b1f54956d74db0a84783908fe41427a540b1221f5887e5¤cy=TMSC

The first valid accept is at block 289750 index 137:
https://masterchain.info/sellaccept.html?tx=8e12e87dc2a04f10115726dfe385b6744b8721bc4ffc08a6e1089c5c22271897¤cy=TMSC
With payments -
on block 289755 index 119
https://masterchain.info/btcpayment.html?tx=42f470a5c00be4e434055fd63515d14d7fdd6d96e0eedea6a494620a5818554b¤cy=TMSC
on block 289755 index 120
https://masterchain.info/btcpayment.html?tx=36ef617e944bfad6b5d43f9faccc8ead27c33d54e07f2793fe13f1980846488b¤cy=TMSC
on block 289755 index 121
https://masterchain.info/btcpayment.html?tx=df3b38afcfc1fe20d065d58e5d02360d9150e0e1d9f5f7691c33d84c07e3acc4¤cy=TMSC

The the next valid accept is at block 289755 index 425:
https://masterchain.info/sellaccept.html?tx=9ecd7a40eba06ea425554fa42dadca1c4c94dc301040d656484a85c45d68d80963a¤cy=TMSC
with payments -
on block 289757 index 153
https://masterchain.info/btcpayment.html?tx=5eea7fcad063871ece3404237fb2b5d66cf79b51e371c2f8aef6e7061aacd197¤cy=TMSC
on block 289761 index 120
https://masterchain.info/btcpayment.html?tx=8c61c5e7903f82908b18cbcc83681834c2b299f1c80cffa39d42e946da6c2a72¤cy=TMSC

I see no problem with that.

order is set by block and then by index in the block.
For users, there is no difference between getting the next index or the next block - this is randomly set by a miner finding a block.

Grazcoin

I also think a4be2bc89c0b11977ed907605993680ea893ebe316878586f05bd755275f559b should be invalidated.

An address buying coins from itself is invalid IMO, I can't see any use cases for it (boggles the mind actually ) - just adds unnecessary complexity to support it and throws up questions around how we'd handle this.

Thanks
Zathras

https://masterchain.info wallet here is not intuitive at all. I have no clue how to use it without looking for some documentation. Quite frustrating for someone expecting something resembling Blockchain.info. It should be average user friendly if not retard friendly.

Out of the 3 existing wallets, not one of them is user friendly or without weird errors during installation. Perhaps you shouldn't pay bounties to any sloppy job and demand more quality and polished products, be more demanding in general to those who take on these bounties.

Graz/Bitoy,

Closing in on consensus - but I think you guys have a problem in the way you're handling the blocking of simultaneous accepts from the same buyer.

You guys have accept 9ecd7a40eba06ea554fa42dadca1c4c94dc301040d656484a85c45d68d80963a as valid.

However that accept above was in block 289755.  

All the payments for the previous accept took place in block 289755.

As all the payments took place in block 289755 the previous accept is thus closed in block 289755.  A new accept should not be allowed until the next block, 289756 - otherwise we are encouraging new accepts while payments are still unconfirmed (which means we then need to go to checking whether the payments occurred 'earlier in the block' than the new accept etc)

Therefore accept 9ecd7a40eba06ea554fa42dadca1c4c94dc301040d656484a85c45d68d80963a should be invalid as its in the same block as the payments for the previous accept.

Thanks
Zathras

Great stuff Graz!
Do you have details on how many people created a wallet?
Any statistics you can share would be interesting.

I just checked the logs of masterchain.info now, and it is already 3 days that I get more than 350 unique visits daily (not including wallet).
This number is generated by http://goaccess.prosoftcorp.com/
Grazcoin

Reserved is taken from the available balance, until it is no longer reserved.
I think it is clear from the UI, e.g. https://masterchain.info/Address.html?addr=182osbPxCo88oaSX4ReJwUr9uAcchmJVaL¤cy=TMSC

Devs,
Some general questions that don't require an immediate reply. I'm not looking to distract you.

I'm just curious -

When you show a coin balance for an address, does it include or exclude any reserved/committed/escrowed amount (is it the available balance)? Is this clear to the user? Is it easy for the user to see the reserved/committed/escrowed amounts and related details?

Is the user able to see why coins were returned to the available balance, e.g. when a sell offer is updated or canceled, a buyer underpays or doesn't pay at all?