ripper234
Legendary
 Offline
Activity: 1358
Merit: 1003
Ron Gross
|
 |
March 13, 2014, 09:13:54 AM |
|
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. 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) |
|
|
|
|
|
|
|
|
|
|
The grue lurks in the darkest places of the earth. Its favorite diet is adventurers, but its insatiable appetite is tempered by its fear of light. No grue has ever been seen by the light of day, and few have survived its fearsome jaws to tell the tale.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
grazcoin
|
|
March 13, 2014, 10:24:33 AM |
|
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).
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. 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  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? |
|
|
|
|
Herp
|
|
March 13, 2014, 10:33:04 AM |
|
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. 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) 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. |
|
|
|
ripper234
Legendary
Offline
Activity: 1358
Merit: 1003
Ron Gross
|
|
March 13, 2014, 12:18:24 PM |
|
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/ but apparently is closer to blockchain.info in terms of design and usability. 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 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 over complicated 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?
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. Don't see why this is so hard to make. Most other coins have straight and forward "click next next done" type wallets and expect something like this on a landing page, not something with dependencies and dozen of steps. For example I don't even use the Bitcoin qt wallet.
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.
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. |
|
|
|
|
grazcoin
|
|
March 13, 2014, 07:13:23 PM |
|
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 Great stuff Graz! Do you have details on how many people created a wallet? Any statistics you can share would be interesting. 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. |
|
|
|
dexX7
Legendary
Offline
Activity: 1106
Merit: 1024
|
|
March 13, 2014, 08:06:36 PM |
|
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.
|
|
|
|
|
zathras
|
|
March 13, 2014, 09:20:19 PM |
|
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 |
|
|
|
|
grazcoin
|
|
March 14, 2014, 12:04:23 PM
Last edit: March 14, 2014, 01:24:36 PM by grazcoin |
|
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 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. |
|
|
|
|
Bitoy
|
|
March 14, 2014, 01:45:16 PM |
|
http://mymastercoins.com/viewaddresstrans.aspx?address=182osbPxCo88oaSX4ReJwUr9uAcchmJVaLAlthough 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 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
|
|
|
|
|
|
Bitoy
|
|
March 14, 2014, 01:52:23 PM |
|
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.
Send to self works well in bitcoins because it consolidates the coins into one transaction. Which will save space next time you send. In mastercoin there is no small change coins. But we already allowed sending to ones address so it's ok now. Please advise the changes to that I can update the codes. (Ps Busy preparing for vacation will update it soon as I get back |
|
|
|
|
|
zathras
|
|
March 14, 2014, 06:54:54 PM |
|
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 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. So... Tired... Doing a chunk of rewriting and taking far longer than I expected - have added a 'btcpayment' mastercoin transaction type and am rewriting the lib & engine to make each bitcoin payment a separate coin purchase transaction (so changing the logic/architecture to be the same as you & Bitoy)... This will then allow me to process payments in blockchain order regardless of block boundaries. Will keep you guys updated... Thanks Zathras |
|
|
|
|
|
|
Bitoy
|
|
March 15, 2014, 12:59:31 AM |
|
Grazcoin,
Please take a look at
1BKpa19m5Xy9SvSzC5djPWtCfbuynSDwmb
We are in consensus before I sent a Cancel Sell Offer.
MM=46.63879623 1BKpa19m5Xy9SvSzC5djPWtCfbuynSDwmb MCHAIN=47.72567223
Difference 1.086876
Was there a change in your code (ie invalidating some transactions discussed earlier)?
|
|
|
|
|
|
zathras
|
|
March 15, 2014, 05:19:55 AM |
|
Hey guys, Been a crazy 24 hours, but pleased to say the rewrite is done - just in the nick of time Whilst payments don't carry Master Protocol messages they are nonetheless now treated as MP messages and queued along with them. Payments can now be used as independent entities (rather than metadata for the accept transaction). This should align me with Masterchain & sort the remaining consensus issues, though I think I have to clear up a potential rounding issue. New code is straight to live (I've done limited bug fixing myself). Wallet alpha with real MSC enabled will be up in the next hour or so. Remember, this is alpha software so test with tiny amounts. Thanks Zathras |
|
|
|
|
zathras
|
|
March 15, 2014, 08:00:11 AM |
|
OK. Finally got alpha 0.3 up ( here). Transaction processing is a bit slow in this build as I haven't had a chance to optimize the new DEx payment stuff yet (please be patient). I'll continue to work on optimizing and UX improvements over the coming days Thanks Zathras |
|
|
|
ripper234
Legendary
Offline
Activity: 1358
Merit: 1003
Ron Gross
|
|
March 15, 2014, 09:35:56 AM |
|
Great job zathas pulling it off like that - I know it wasn't easy!
Get some rest over the weekend, I know you need it...
|
|
|
|
|
|
ripper234
Legendary
Offline
Activity: 1358
Merit: 1003
Ron Gross
|
|
March 15, 2014, 12:54:50 PM |
|
Thanks for reporting! I opened an issue on this - in the future can you just open an issue directly on https://github.com/zathras-crypto/masterchest-wallet/issues ? Can you add to the issue I opened steps to reproduce / screenshots? (Including a screenshot is easy - just alt-printscreen to capture the current window, and paste directly into github) Thanks again for reporting, sounds like a high priority issue. |
|
|
|
|
jeroenn13
|
|
March 15, 2014, 01:01:08 PM |
|
Thanks for reporting! I opened an issue on this - in the future can you just open an issue directly on https://github.com/zathras-crypto/masterchest-wallet/issues ? Can you add to the issue I opened steps to reproduce / screenshots? (Including a screenshot is easy - just alt-printscreen to capture the current window, and paste directly into github) Thanks again for reporting, sounds like a high priority issue. Done, thank you for responding |
|
|
|
|
jeroenn13
|
|
March 15, 2014, 03:58:04 PM |
|
So there is no way to cancel my selling order?
|
|
|
|
|
