Pages:
Author

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

sr. member
Activity: 266
Merit: 250
March 10, 2014, 07:42:57 PM
#93

Reindexing the blockchain should be a one-time event Smiley  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 Smiley

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 Smiley

Thanks J.R. - if only I'd just stopped at doing masterchest.info only Tongue  Nah just kidding Smiley  The better half is surprisingly understanding actually (financial rewards no doubt help Tongue) - 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.

legendary
Activity: 1260
Merit: 1031
Rational Exuberance
March 10, 2014, 04:10:49 PM
#92

Reindexing the blockchain should be a one-time event Smiley  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 Smiley

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 Smiley
sr. member
Activity: 266
Merit: 250
March 10, 2014, 01:05:23 PM
#91
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 Smiley  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 Smiley

Thanks!
Zathras

sr. member
Activity: 266
Merit: 250
March 10, 2014, 01:01:41 PM
#90
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. http://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":

Quote
-blocknotify= Execute command when the best block changes (%s in cmd is replaced by block hash)
-walletnotify= 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. Smiley

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 Smiley
legendary
Activity: 1204
Merit: 1002
RUM AND CARROTS: A PIRATE LIFE FOR ME
March 10, 2014, 12:58:45 PM
#89
Will it be possible in the future to have a Masterchest Lite Client? I can't imagine reindexing the Blockchain everytime like this.
sr. member
Activity: 266
Merit: 250
March 10, 2014, 12:58:23 PM
#88
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 Smiley
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
legendary
Activity: 1106
Merit: 1026
March 10, 2014, 06:24:10 AM
#87
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. http://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":

Quote
-blocknotify= Execute command when the best block changes (%s in cmd is replaced by block hash)
-walletnotify= 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. Smiley
legendary
Activity: 1358
Merit: 1003
Ron Gross
March 10, 2014, 05:02:35 AM
#86
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 Smiley
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.
sr. member
Activity: 266
Merit: 250
March 09, 2014, 10:28:35 PM
#85
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 Smiley

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

Thanks
Zathras
newbie
Activity: 18
Merit: 0
March 09, 2014, 09:34:42 PM
#84
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.
sr. member
Activity: 266
Merit: 250
March 09, 2014, 06:25:57 PM
#83
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.

Smiley

Thanks!
Zathras
sr. member
Activity: 266
Merit: 250
March 09, 2014, 06:04:03 PM
#82
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.. Smiley

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". Wink

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. http://i.imgur.com/wJoZ0iy.png

The date of a transaction created by the wallet is also affected by localization, I think: http://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 Smiley
Zathras

sr. member
Activity: 266
Merit: 250
March 09, 2014, 05:16:36 PM
#81
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 Smiley
Zathras
sr. member
Activity: 266
Merit: 250
March 09, 2014, 05:01:04 PM
#80
I also understand about the alpha stage - it's just that I guess I expected something a bit more stable at this stage of development, but it's understand that this is still a bit raw around some edges since the wallet was just released.

I think proper error messages are very important for usability, too. Let's just write every one down, whenever one without nice information is found. Smiley


Edit: zathras, what is your take on the translation thing? Is it safe to start submitting translations to https://www.transifex.com/projects/p/masterchest-wallet-1/ or is not yet finalized and up to change?
I agree - if you can tee up a batch of unclear error messages I can go through and adjust the handling to provide better guidance.

On the translations I honestly haven't had a chance to look at that/think about it at this stage.  I'll try to get some time to look at it Smiley

sr. member
Activity: 266
Merit: 250
March 09, 2014, 04:57:30 PM
#79
Ron, moving that folder won't do it I'm afraid - SQLCE is just really DLLs and these will be in your GAC (global assembly cache) as well as your system folders so just moving that folder out of program files will be ineffective.  As I mentioned really it's a complete removal or an upgrade.  Best bet is simply run this http://www.microsoft.com/en-au/download/details.aspx?id=5783 to update your old SQLCE install.  Also whilst I do of course appreciate your desire to have things easy for the user, I think those expectations are perhaps a little too high.  I have put a lot of effort into this & I did indeed test both without SQLCE and with SQLCE installed, but I did not test with outdated SQLCE installed.  I can't test every possible scenario, hardware configuration and software portfolio before alpha - it's just not realistic.  This is why it's out here for the community to test and as you guys pick these things up I will of course address them and try to remove/automate resolution of problems etc.  There WILL be bugs at this stage.  Completely agree stable releases should be much better Smiley but initial alphas are inherently unstable as they're the first time code gets tested on a wide range of configurations.

Understood - I ran the SQLCE installer and this resolved the issue (you may want to link to this from your error message).

I also understand about the alpha stage - it's just that I guess I expected something a bit more stable at this stage of development, but it's understand that this is still a bit raw around some edges since the wallet was just released.

FYI - please see this error from the debug window.

Quote
ERROR: Database block appears newer than bitcoinrpc blocks - is bitcoinrpc up to date? Exiting thread.

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 Smiley
Zathras
 
hero member
Activity: 938
Merit: 1000
March 09, 2014, 02:18:04 PM
#78
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?
hero member
Activity: 511
Merit: 500
Hempire Loading...
March 09, 2014, 12:21:01 PM
#77
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?
legendary
Activity: 1106
Merit: 1026
March 09, 2014, 10:28:16 AM
#76
I also understand about the alpha stage - it's just that I guess I expected something a bit more stable at this stage of development, but it's understand that this is still a bit raw around some edges since the wallet was just released.

I think proper error messages are very important for usability, too. Let's just write every one down, whenever one without nice information is found. Smiley


Edit: zathras, what is your take on the translation thing? Is it safe to start submitting translations to https://www.transifex.com/projects/p/masterchest-wallet-1/ or is not yet finalized and up to change?
legendary
Activity: 1358
Merit: 1003
Ron Gross
March 09, 2014, 06:18:01 AM
#75
Ron, moving that folder won't do it I'm afraid - SQLCE is just really DLLs and these will be in your GAC (global assembly cache) as well as your system folders so just moving that folder out of program files will be ineffective.  As I mentioned really it's a complete removal or an upgrade.  Best bet is simply run this http://www.microsoft.com/en-au/download/details.aspx?id=5783 to update your old SQLCE install.  Also whilst I do of course appreciate your desire to have things easy for the user, I think those expectations are perhaps a little too high.  I have put a lot of effort into this & I did indeed test both without SQLCE and with SQLCE installed, but I did not test with outdated SQLCE installed.  I can't test every possible scenario, hardware configuration and software portfolio before alpha - it's just not realistic.  This is why it's out here for the community to test and as you guys pick these things up I will of course address them and try to remove/automate resolution of problems etc.  There WILL be bugs at this stage.  Completely agree stable releases should be much better Smiley but initial alphas are inherently unstable as they're the first time code gets tested on a wide range of configurations.

Understood - I ran the SQLCE installer and this resolved the issue (you may want to link to this from your error message).

I also understand about the alpha stage - it's just that I guess I expected something a bit more stable at this stage of development, but it's understand that this is still a bit raw around some edges since the wallet was just released.

FYI - please see this error from the debug window.

Quote
ERROR: Database block appears newer than bitcoinrpc blocks - is bitcoinrpc up to date? Exiting thread.

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.
hero member
Activity: 938
Merit: 1000
March 09, 2014, 05:25:08 AM
#74
Awesome; I just re-tested everything and it syncs fine now. Thanks for the quick fix Smiley
Pages:
Jump to: