Topic: Masterchest Wallet Alpha Testing Thread - page 3. (Read 13391 times)

After reimporting the other wallet.dat again, I think I was fooled by my own perception. Both share same transactions, thus the impression of a similar transaction history as well as many addresses with tiny balances etc..

I went through every view and added a bunch of notes, you'll find the part about the floating point delimter there, too: https://i.imgur.com/lffLvCB.png


Edit: found the delimiter problem: DataTables appearingly use their own localization information and overwrite even what was defined on a thread scope. Quickfix: currencylist.Locale = System.Globalization.CultureInfo.InvariantCulture in the module file.

Zathras - Thanks for pointing this out, as I wasn't sure how the Miners fees were being handled with MSC transactions

Thanks - have been wanting to get this out (but crazy couple of days as you know!) because I knew there was some low hanging fruit for optimization (+little indexing sprinkled here and there helps a lot!).

Ah yes, been meaning to simulate that (setting a locale in a VM that has , instead of . so I can replicate myself & test).  Remind me again does it also do that on the currencies panel?

Hmm, we enumerate addresses via multiple RPC methods (because contrary to the bitcoin-core doco, listaddresses does not return all addresses - for example change) but then we check every one via the validateaddress RPC call, using the ismine:true condition before adding to the address stack.  Could you do me a favour?  In your bitcoin install run the command validateaddress address on one of your MSC addresses while in your other wallet.  I can't see any way that bitcoin would return anything other than ismine:false for that but good to check.

I'm also trying to think of other ways this could occur.

Thanks as always for testing
Zathras

P.S.  You can interchange wallet.dat as much as you like (as long as the wallet isn't running of course) - wallet.sdf holds no unique information (otherwise we'd need to encrypt it, back it up etc).  Technically calling Masterchest a wallet is a bit of a misnomer, bitcoind/qt is the wallet, Masterchest just overlays an extra layer of functionality over the top (thus allowing me to conveniently inherit the security of the bitcoin-core wallet )

FYI:

Looks good so far, the processing was indeed much much faster. And the progress bars are awesome!

What still remains is the problem with "," and "." interpretation of balances within the balance overview which shows super high amounts.

And I tested something else what normally shouldn't happen, but this may be handled nevertheless:

I'm using different wallets and I used the MSC wallet with Masterchest, then deleted all Masterchest folders, downloaded the new GitHub version, but changed the wallet.dat inbetween. After starting the new version for some reasons the addresses from the MSC wallet were still shown under addresses, but if I try to send coins, it only shows those from the new wallet. I'm actually a bit surprised, because I deleted also the wallet.sdf etc.

Hey guys,

Alpha 0.3C is up.  OP updated.

This update focuses on:
* Major improvements in processing performance - parsing is about the same but my benchmarks show 200%+ improvement in processing - thus makes an up to date client much faster to use
* Hash based chain re-org protection (upgraded from always roll-back 5 blocks to storing hashes for blocks we process DB local and then comparing with bitcoind/qt when we start scanning)
* Some UI improvements, bugfixes

Thanks
Zathras

OK, great - thanks!

I'll see if I can hunt down the bug that causes the same address to be displayed multiple times - those dropdowns have been modified in a recent change in response to some feedback from Ron (request to add the balance for each address).

Re passphrase - at the moment if you just leave the passphrase empty for an unlocked wallet it should be OK (it'll skip attempting to unlock the wallet if the passphrase is blank).  I do have a line item on my todo list which improves the UX handling of this.  If you're interested basically I can use the 'getinfo' RPC call which includes amid its JSON attribute pairs an attribute called 'unlocked_until'.  I intend to use this call to determine if the wallet is unlocked (and whether it will remain unlocked while we sign and broadcast) prior to throwing up the passphrase request.  TL:DR; it's on the list, just not massively high in terms of priority but should make it into one of the next few alphas no doubt.

Thanks
Zathras

Great ! I was worry to overwrite the wallet.sdf file, so I left the old one, that explained how he was still trying to rebuild from scratch.

Many thanks, will test the DEX right now !

edit : in the send tab, drop down menu, the same address is displayed multiple times (everytime an operation is done, it adds a clone to the list)

edit : if I unlock my bitcoin wallet, masterchest still asks for my passphrase (it is independent I guess?)

Thanks for testing  Comments in-line.

Thanks
Zathras

All current binary downloads have a pre-seeded database to avoid the need to reparse everything.  Still requires enabling the transaction index though (please see the instructions included).

Thanks
Zathras

Few issues with Alpha 0.3 on Win7 64-bit:

1. Initial draft .pdf says "NOTE: If you have customized your bitcoin installation (for example by using the --datadir flag to change the location of
your bitcoin configuration and database) you may need to specify your configuration manually. To do so simply change the four values in wallet.cfg
from empty to your chosen bitcoin RPC server configuration" but that is not true, if one is using non-default datadir than a new line must be added
to file in question. Only this one worked for me:

bitcoinrpcserv=localhost
bitcoinrpcport=8332
bitcoinrpcuser=(username_goes_here)
bitcoinrpcpass=(password_goes_here)
datadir=D:\BitcoinData

Omitting any data or line makes Masterchest complain and shutdown or keep on running but doing nothing.

2. Once Masterchest is started and starts syncing with blockchain, switching to "debug" tab and clicking on DEBUG LEVEL: LOW changes it to MED
and Masterchest becomes unresponsive including minimizing wallet window. It will start accepting user input only after syncing is fully done. Same
unresponsivness occurs once Masterchest starts to print debug text while on MED or HIGH setting. It is impossible to stop printing, it just goes worse
since user can only switch LOW to MED to HIGH level, not MED to LOW or OFF (which does not even exists).

3. Taskbar name for Masterchest is Form1

4. On "currencies" tab amount of coins is wrong, instead of 0.00125 MSC and 4.04268975 BTC it shows I have 125.00 MSC and 404268975.00 BTC

5. Right and bottom sides of main and other windows look wrong, see https://i.imgur.com/7W619QT.png

I read somewhere that one can download a "reparsed" database to speed up the parsing process. Any link available ?

Don't want to wait 24+ hours to try the DEX

Alpha 0.3 is up.  OP updated.

Thanks, your support is appreciated!

Little under 24 hours for the DEx launch! (block 290630)

Thanks,Ron. I got it. By the way, I like the MSC project very much and look forward to your Omniwallet.

The 'Escrow' is actually a multisig address. It's what we call "Class B transaction" - see the spec. You need not worry about it, it's just an implementation detail.

Regarding canceling orders - any action that changes the state of the DEx needs to be broadcast as a bitcoin transaction - there is no way to do that without paying the minimal transaction fee. Note that 0.00035BTC currently equals about 22 cents.

The DEx does not work like centralized exchanges, it has benefits and downsides. One of the downsides, unfortunately, is fees that needs to be paid per operation. However consider when buying large blocks on the DEx, you will not pay a relative fee, but rather just a fixed amount - so it should end up cheaper (not to mention you don't need to trust an exchange).

After I　bought or sold TMSC by wallet exchange when testing , I checked my address in bitcoin block  explorer, I got this message as follow
   1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P 0.00006 BTC
(Escrow 1 of 157rMRZUve... 1PJCYPLdjP...) 0.00018 BTC
I'm confused with the Escrow line,could you please tell me what does it mean,where did the 0.00018BTC go to?
In addition,when buying or selling TMSC using wallet p2p exchange,I cancel my transaction,but I　still have to pay for 0.00035BTC . I don't think it's reasonable. 

Bitcoin has one reference implementation.
I'm not opposed to there being other implementations of mastercoin, but I want to directed our resources in the right way, and speed up development.

In most cases, having all the wallets agree on the balances (=consensus) is more important than having the implementations conform to the spec. The exception is bugs that cause people to lose money - but most bugs (=places where the implementation differs from the spec) aren't exploitable, and can be fixed in future releases.

I think Bitcoin's core devs were asked once to provide a spec for Bitcoin, and they replied that the implementation is the spec. (I may be misquoting here).

Yeah, this isn't something we have completely agreed upon yet. I'm very reluctant to reduce the number of parsing engines - there are TONS of edge cases we catch because we have them.

On the other hand, it slows us down a lot, and you could argue that more strenuous testing would catch those same edge cases.

Having multiple parsing engines is essential to avoid too much centralization in my opinion.

FYI we are discussing the possibility of Masterchest using mastercoin-tools as its parsing engine.
mastercoin-tools relies on SX with Obelisk servers, which is essentially a lite client experience.

My vision for Marchest going forward:

1. When you install Masterchest, it starts working with remote Obelisk servers.
2. It asks you "Do you want to upgrade to 'Full Client' mode ?"
3. If you confirm, then a local obelisk server is installed, and starts syncing with the network. You are told that the client is working in Lite mode for the time being.
4. When the blockchain syncs and is parsed, the client automatically switches from Lite Client mode to Full Client - instead of working with remote obelisk servers, it now uses the local one.

I realize this scenario requires some delicate coding! But I think it would provide the ultimate user experience in terms of a good compromise between security and usability.