Masterchest Wallet Alpha Testing Thread

[zathras]

So I have some difficulty running this simply because running the Bitcoin client is not very friendly with my computer, will it ever work from a light weight wallet like Multibit?

No, Masterchest probably won't. It needs the specific API calls from bitcoind, Multibit (as far as I know doesn't supply these calls). You can however still use a web-wallet like https://masterchain.info/, this could be considered light.

Zath, I'm trying to send the payment for an accepted DEx offer but I get the following error after filling in my password.



Translated: "Value can't be null", parameter name: Value

Any idea what I'm doing wrong there? Is the offer perhaps already expired?

Hmm, in the send payment window is everything populated (all fields on the left)? - Also I've just committed a quick addition of exception trapping on encoding functions in the library - perhaps that'll give some more visibility to the issue (just pull the bin archive again).  Otherwise I can throw you a custom build with a bunch of extra debugging.

Thanks
Zathras

[1714677517]

1714677517

[1714677517]

1714677517

[1714677517]

1714677517

[1714677517]

1714677517

[zathras]

Hey zathras,

chart is fixed. You need to set the culture info at the beginning of the workthread_DoWork() method, too. I think that's also the only section where anything multithreaded is, right? So it should be fine then..

I'm not sure, if CurrentThread.CurrentCulture is enough or if CurrentUICulture needs also to be set. But make sure you use CultureInfo.InvariantCulture instead of creating your own with only the decimal change.

Re: font size, this seems to be somewhat messy and there are some reports that users have problems with it, even when trying to change the element's size on the fly. Some said that the AutoScaleMode should set to .Dpi instead of .Font, but after testing the tables were still misplaced. Maybe you should use fixed font sizes all over the wallet and simply force a specific size, if this is possible. Less usability is still preferred over a broken interface imho.

It would also be nice, if the form is not entitled with "Form1".

By the way, do you scan and refetch the block chain on the fly?


Edit: The balances in the "address overview" are accurate, but the "currencies overview" displays the balances as if the decimal limiter was ignored. https://i.imgur.com/wJoZ0iy.png

The date of a transaction created by the wallet is also affected by localization, I think: https://i.imgur.com/kUBEteZ.png + http://pastebin.com/raw.php?i=ad6HcMDR (log was super long, so I hope this is relevant part)

Hey Dexx,

The culture stuff was added to the dowork method in https://github.com/zathras-crypto/masterchest-wallet/commit/e324be03d62e002fdb8fcd38ec731f6e889e00b0 but I need to spend more time understanding this to do it properly.

Haha on the form name - yeah all the others are named but this one kind of grew out of nothing, I'll rename it 'main' or something at some point.

Fetching the blockchain is left up to the local bitcoin instance, we just query that over RPC.  We currently roll back 5 blocks every time the scanning thread starts (every 5 minutes) and rescan to pick up new transactions.  Transaction state processing is completely redone on every completion of the scanning run start to finish.  There are a lot of inefficiencies/performance improvements I can fix up when time allows too.

Re dates, notice how the colour is blue - that's because it's an unconfirmed transaction (and thus has no blocktime) - we spoof a date in the year 9999 until confirmed so I don't think that's localization (just the zany way my brain thinks!).

The currencies overview is obviously not right - if you go to the exchange panel and click on 'sell', then select one of your addresses - does the 'available balance' show correctly?

Thanks
Zathras

[zathras]

I've just committed a new version with output to the debug panel when encoding transactions - this should help in diagnosing where things aren't working.

Polite reminder, this is alpha software, do not test it with wallets containing any significant amount of bitcoins/mastercoins.



Thanks!
Zathras

[pplwjd]

When I　started my wallet client today,I have this error messages and my client displayed not  syncronized. When I restarted the client,it still hung at the block 289803 and got the same messages.
DEBUG: Block Analysis for: 289789
DEBUG: Block Analysis for: 289790
BLOCKSCAN: Found MSC transaction (simple send): b30c0a6a6c753dc7d1cce3580aa28258a75748f32de8e9f5dd4567524c94a280
DEBUG: Block Analysis for: 289791
DEBUG: Block Analysis for: 289792
DEBUG: Block Analysis for: 289793
DEBUG: Block Analysis for: 289794
DEBUG: Block Analysis for: 289795
DEBUG: Block Analysis for: 289796
DEBUG: Block Analysis for: 289797
DEBUG: Block Analysis for: 289798
DEBUG: Block Analysis for: 289799
DEBUG: Block Analysis for: 289800
DEBUG: Block Analysis for: 289801
DEBUG: Block Analysis for: 289802
DEBUG: Block Analysis for: 289803
BLOCKSCAN: Found MSC transaction (simple send): 464245fb57cf539fd4a2d987d9abed0c820add5bb304a9ee752711f829a8fe41
BLOCKSCAN: Found MSC transaction (simple send): 53d75f221fad5a497bc8c5c1fe942345d51851ec4850cda733e491263be7ecb6
BLOCKSCAN: Found MSC transaction (simple send): 2751409e5ac3acf2f76a4b8723816567ebda0188054272921ce73b126e64981e
BLOCKSCAN: Found MSC transaction (simple send): 9480f5fb41d8d477df89093947cf293e11266867d4b97eb7d0c10d2c0dc89b50
DEBUG: Block Analysis for pending transactions
BLOCKSCAN: Transaction processing starting...
ERROR: Blockchain scanning thread threw exception : The column name is not valid. [ Node name (if any) = ,Column name = ADDRESS ]
DEBUG: Thread exited with error condition.

[zathras]

When I　started my wallet client today,I have this error messages and my client displayed not  syncronized. When I restarted the client,it still hung at the block 289803 and got the same messages.
DEBUG: Block Analysis for: 289789
DEBUG: Block Analysis for: 289790
BLOCKSCAN: Found MSC transaction (simple send): b30c0a6a6c753dc7d1cce3580aa28258a75748f32de8e9f5dd4567524c94a280
DEBUG: Block Analysis for: 289791
DEBUG: Block Analysis for: 289792
DEBUG: Block Analysis for: 289793
DEBUG: Block Analysis for: 289794
DEBUG: Block Analysis for: 289795
DEBUG: Block Analysis for: 289796
DEBUG: Block Analysis for: 289797
DEBUG: Block Analysis for: 289798
DEBUG: Block Analysis for: 289799
DEBUG: Block Analysis for: 289800
DEBUG: Block Analysis for: 289801
DEBUG: Block Analysis for: 289802
DEBUG: Block Analysis for: 289803
BLOCKSCAN: Found MSC transaction (simple send): 464245fb57cf539fd4a2d987d9abed0c820add5bb304a9ee752711f829a8fe41
BLOCKSCAN: Found MSC transaction (simple send): 53d75f221fad5a497bc8c5c1fe942345d51851ec4850cda733e491263be7ecb6
BLOCKSCAN: Found MSC transaction (simple send): 2751409e5ac3acf2f76a4b8723816567ebda0188054272921ce73b126e64981e
BLOCKSCAN: Found MSC transaction (simple send): 9480f5fb41d8d477df89093947cf293e11266867d4b97eb7d0c10d2c0dc89b50
DEBUG: Block Analysis for pending transactions
BLOCKSCAN: Transaction processing starting...
ERROR: Blockchain scanning thread threw exception : The column name is not valid. [ Node name (if any) = ,Column name = ADDRESS ]
DEBUG: Thread exited with error condition.

Hey

Please update to the latest binary which should have that bug resolved.

Thanks
Zathras

[ripper234]

1. Should the thread really exit at this point? Bitcoin-qt is still syncing, should the code just wait for it to sync rather than give up? Or perhaps it is doing that and the message just threw me off?
2. Actually the wallet doesn't show any sort of progress bar, so the user does't know if the wallet is waiting for sync, or gave up. I think that adding something like that would be good for the user to know that something is going on.

Hey Ron,

1.  Yes, the scanning thread needs to exit here.  Your database is at lets say block 288000 (because it's pre-seeded), and bitcoin-qt is at lets say block 240000 (maybe because it's still resyncing/reindexing for example).  The wallet cannot analyze its next block (288001) because bitcoin-qt doesn't have that block available yet via RPC.  Thus we have to exit the thread and wait until bitcoin-qt has the block data available.  I wouldn't want to just wait the thread while we wait for bitcoin-qt to finish syncing as that is an indeterminate time period.  The scanning thread restarts every 5 minutes anyway so once bitcoin-qt has the block data available the wallet simply starts syncing itself.

2.  If you're getting that error the wallet state should be a red cross with 'not synchronized' (unless there is a bug).  Once the wallet starts syncing the status should change including showing progress through the blocks.  I can certainly add a '% remaining' or similar.

Not sure what you mean by give up, but if I catch your meaning the wallet will never 'give up' as it were.  Yep the scanning thread might exit if there are conditions it doesn't like, but it'll just try again in 5 minutes time.  It continues like this until you close the wallet.  The overview should always be in one of three states:
* Not synchronized
* Synchronizing
* Synchronized

Thanks
Zathras
 

I understand - I was afraid that when the thread exists it doesn't revive again.
5 minutes is a long time - can you test this every 5-10 seconds instead for better responsiveness? Is the test resource intensive?

Also, in this state (live block < pre-seed block), it would still be useful to have some progress/status on the blocks parsed/that remain to be parsed.
Right now it's not clear to the user whether the process is stuck or not.

[dexX7]

The currencies overview is obviously not right - if you go to the exchange panel and click on 'sell', then select one of your addresses - does the 'available balance' show correctly?

Yup, those numbers are correct.

I have an older sell order stuck which I can't delete. Sent more than one cancel offer already. At the same time there is an unpaid order, which is actually expired. https://i.imgur.com/l8Kv6X8.png (wallet.sdf, started with the latest GH version, used seeded /debug wallet.sdf, tried to cancel the order)

Ah, 5 minutes, I see. Maybe include a button to update manually, e.g. replace the sync icon which pops up while syncing with a "force update" icon/button? You may check out the command line options "blocknotify" and "walletnotify":

-blocknotify=<cmd> Execute command when the best block changes (%s in cmd is replaced by block hash)
-walletnotify=<cmd> Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)

As far as I know cmd can be replaced by a path or script to which the hash is passed, but I'm not sure, how easy or difficult it would be to combine this with the wallet.

[zathras]

1. Should the thread really exit at this point? Bitcoin-qt is still syncing, should the code just wait for it to sync rather than give up? Or perhaps it is doing that and the message just threw me off?
2. Actually the wallet doesn't show any sort of progress bar, so the user does't know if the wallet is waiting for sync, or gave up. I think that adding something like that would be good for the user to know that something is going on.

Hey Ron,

1.  Yes, the scanning thread needs to exit here.  Your database is at lets say block 288000 (because it's pre-seeded), and bitcoin-qt is at lets say block 240000 (maybe because it's still resyncing/reindexing for example).  The wallet cannot analyze its next block (288001) because bitcoin-qt doesn't have that block available yet via RPC.  Thus we have to exit the thread and wait until bitcoin-qt has the block data available.  I wouldn't want to just wait the thread while we wait for bitcoin-qt to finish syncing as that is an indeterminate time period.  The scanning thread restarts every 5 minutes anyway so once bitcoin-qt has the block data available the wallet simply starts syncing itself.

2.  If you're getting that error the wallet state should be a red cross with 'not synchronized' (unless there is a bug).  Once the wallet starts syncing the status should change including showing progress through the blocks.  I can certainly add a '% remaining' or similar.

Not sure what you mean by give up, but if I catch your meaning the wallet will never 'give up' as it were.  Yep the scanning thread might exit if there are conditions it doesn't like, but it'll just try again in 5 minutes time.  It continues like this until you close the wallet.  The overview should always be in one of three states:
* Not synchronized
* Synchronizing
* Synchronized

Thanks
Zathras
 

I understand - I was afraid that when the thread exists it doesn't revive again.
5 minutes is a long time - can you test this every 5-10 seconds instead for better responsiveness? Is the test resource intensive?

Also, in this state (live block < pre-seed block), it would still be useful to have some progress/status on the blocks parsed/that remain to be parsed.
Right now it's not clear to the user whether the process is stuck or not.

Hey Ron,

It's a very intensive thread, but the test for what block bitcoin is at itself isn't resource intensive.  5 minutes was chosen for a refresh on the scanning thread as it's half of the average bitcoin block so by and large the wallet will always be working from the latest block.

Re progress, the debug panel should state that quite clearly, for example on first run you may see:
* Database blocks 288000, Bitcoin RPC blocks 240000 - is bitcoinrpc up to date (or similar text)

Then on the next run you'd see:
* Database blocks 288000, Bitcoin RPC blocks 250000 - is bitcoinrpc up to date (and so on)

At the moment we don't do any processing until fully synced.  I'll have a think about how I can handle the appearance to the end user.

Thanks
Zathras

[crazy_rabbit]

Will it be possible in the future to have a Masterchest Lite Client? I can't imagine reindexing the Blockchain everytime like this.

[zathras]

The currencies overview is obviously not right - if you go to the exchange panel and click on 'sell', then select one of your addresses - does the 'available balance' show correctly?

Yup, those numbers are correct.

I have an older sell order stuck which I can't delete. Sent more than one cancel offer already. At the same time there is an unpaid order, which is actually expired. https://i.imgur.com/l8Kv6X8.png (wallet.sdf, started with the latest GH version, used seeded /debug wallet.sdf, tried to cancel the order)

Ah, 5 minutes, I see. Maybe include a button to update manually, e.g. replace the sync icon which pops up while syncing with a "force update" icon/button? You may check out the command line options "blocknotify" and "walletnotify":

-blocknotify=<cmd> Execute command when the best block changes (%s in cmd is replaced by block hash)
-walletnotify=<cmd> Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)

As far as I know cmd can be replaced by a path or script to which the hash is passed, but I'm not sure, how easy or difficult it would be to combine this with the wallet.

Great, thanks.

Any transaction you broadcast should automatically kick off the scanning thread to update, but yeah I have been toying with the idea of a manual sync button.  I have some plans around a better model for checking for new blocks, just requires time to implement splitting off the actual scanning thread from blockcount checks so that they can be run more frequently

[zathras]

Will it be possible in the future to have a Masterchest Lite Client? I can't imagine reindexing the Blockchain everytime like this.

Reindexing the blockchain should be a one-time event   However I have considered that yep - it would be a 'consensus based' thin client - so a thin client in the traditional sense, except that it only works on matching transaction data retrieved from multiple sources.  It all depends on the direction the project takes

Thanks!
Zathras

[dacoinminster]

Reindexing the blockchain should be a one-time event   However I have considered that yep - it would be a 'consensus based' thin client - so a thin client in the traditional sense, except that it only works on matching transaction data retrieved from multiple sources.  It all depends on the direction the project takes

Thanks!
Zathras

That would be sweet!

On a side note, I know you've been working through the weekends lately. Don't push yourself too hard!!

On the other hand, I hope the financial rewards of all this work will also make your wife very happy in the long run

[zathras]

Reindexing the blockchain should be a one-time event  However I have considered that yep - it would be a 'consensus based' thin client - so a thin client in the traditional sense, except that it only works on matching transaction data retrieved from multiple sources.  It all depends on the direction the project takes

Thanks!
Zathras

That would be sweet!

On a side note, I know you've been working through the weekends lately. Don't push yourself too hard!!

On the other hand, I hope the financial rewards of all this work will also make your wife very happy in the long run

Thanks J.R. - if only I'd just stopped at doing masterchest.info only  Nah just kidding  The better half is surprisingly understanding actually (financial rewards no doubt help ) - I can just push it a bit far without thinking sometimes (like this morning I had a idea to fix a bug so got up & started coding around 4AM lol) - this is all new so it's a bit of an adjustment that's all.

[ripper234]

Will it be possible in the future to have a Masterchest Lite Client? I can't imagine reindexing the Blockchain everytime like this.

Reindexing the blockchain should be a one-time event   However I have considered that yep - it would be a 'consensus based' thin client - so a thin client in the traditional sense, except that it only works on matching transaction data retrieved from multiple sources.  It all depends on the direction the project takes

Thanks!
Zathras

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.

[dexX7]

FYI we are discussing the possibility of Masterchest using mastercoin-tools as its parsing engine.

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

[dacoinminster]

FYI we are discussing the possibility of Masterchest using mastercoin-tools as its parsing engine.

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

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.

[ripper234]

FYI we are discussing the possibility of Masterchest using mastercoin-tools as its parsing engine.

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

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.

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).

[pplwjd]

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. 

[ripper234]

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. 

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).

[pplwjd]

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

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. 

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).