I uploaded to the download page previews of a bitcoinj 0.10-SNAPSHOT version of Bitcoin Wallet. It's supposed to fix or at least relax a problem with your wallet and the blockchain getting out of sync on your device, resulting in missing transactions and/or confirmations. If this still happens to you, please don't hesitate and report an issue through the app.
http://code.google.com/p/bitcoin-wallet/downloads/list
Note these previews will not be on Google Play.
I think Mike will elaborate a little bit more on bitcoinj 0.10 when its time in his sparkling new subforum:
https://bitcointalk.org/index.php?board=138.0
Topic: Bitcoin Wallet alpha and beta channels (Read 3196 times)
There is a new version 3.12 RC in the beta channel and on the download page.
http://code.google.com/p/bitcoin-wallet/downloads/list
Changes:
* direct button on main screen for scanning a Bitcoin request QR code
* extended logging
As always, if you want to participate in the beta channel, follow the instructions in the original post.
http://code.google.com/p/bitcoin-wallet/downloads/list
Changes:
* direct button on main screen for scanning a Bitcoin request QR code
* extended logging
As always, if you want to participate in the beta channel, follow the instructions in the original post.
And on to the next version 3.10 RC in the beta channel and on the download page...
It "embeds" the fee calculator directly into the send and request coins forms rather than needing to go through a separate dialog.
One positive side effect of this is when you scan a Bitcoin request (QR or NFC) including an amount, you'll immediately see how much that is in your local currency before you press send.
It "embeds" the fee calculator directly into the send and request coins forms rather than needing to go through a separate dialog.
One positive side effect of this is when you scan a Bitcoin request (QR or NFC) including an amount, you'll immediately see how much that is in your local currency before you press send.
I have uploaded 3.09 RC into the beta channel.
Main changes are
- Proper calculation of fees. In many cases, this means only 1/5th of the previous fee (0.0001).
- French translation was updated.
- It uses bitcoinj 0.9
If you want to participate in testing, follow the instructions in the original post.
Main changes are
- Proper calculation of fees. In many cases, this means only 1/5th of the previous fee (0.0001).
- French translation was updated.
- It uses bitcoinj 0.9
If you want to participate in testing, follow the instructions in the original post.
It's now in the beta channel. Whoever would like to participate, see the original post that started this thread.
I'd like to postpone discussions about both the "stalled" and the "progress bar" for now.
First, I'd like to deal only with the fallout from the decision to move blockchain progress away from the bottom of the screen and into the same space wallet balance lives in.
I decided to try out hiding progress entirely if its not a replay. Because in this case it does not really matter to the user, he can send and receive even if the chain is not up to date. Note its possible to watch blockchain progress in detail in the network monitor. The change will go into 3.08, which I will put into the beta channel probably tomorrow morning.
First, I'd like to deal only with the fallout from the decision to move blockchain progress away from the bottom of the screen and into the same space wallet balance lives in.
I decided to try out hiding progress entirely if its not a replay. Because in this case it does not really matter to the user, he can send and receive even if the chain is not up to date. Note its possible to watch blockchain progress in detail in the network monitor. The change will go into 3.08, which I will put into the beta channel probably tomorrow morning.
I'm not sure, I was updated a while ago. Perhaps I was on the alpha channel?
By the way, I think if we go the route of threshold signing updates it'd make sense to have a separate app for alpha/beta testing. Otherwise you'd have to get multiple developers to sign off on each beta update which is too heavyweight.
I think just hiding synchronisation feedback entirely if there is less than N days to catch up on makes sense, where perhaps N can be something like 7. For progress bars, yes it does work, you're already indicating progress with the "2 days left" text anyway. The progress would just be the inverse of the countdown. The bitcoin-qt way to calculate progress is a lot more complicated than what we need. But even with a threshold on it, it'd be better not to hide the balance IMHO.
If we separate "connecting" from "synchronising" then the bogus stall issue will go away. I don't think we can do better than 5 seconds in every case. The reason is that bringing up connections at the P2P level is already pretty fast, but if you aren't on wifi then the 3G/GSM protocols impose a quite high latency on using any data at all. The reason is they have significant "cold start" issue .... if no data was used for a while then the radio link has collapsed down to a low power/low resource usage state and bringing it back up to speed requires handshaking with the tower and complicated/slow state transitions in order to reserve some bandwidth. Then there's a fair amount of plain old transmission latency (500msec+ is not unreasonable) due to the interleaving and error correcting mechanisms used on older 3G protocol revisions. HSPDA improved latency a lot by reducing the transmission time interval but if you have a plain old 3G or (ugh) GPRS connection then they use very large batches to reduce the impact of interference.
Does "stalled" really have a purpose? I am trying to think of what the usefulness is but can't see any.
By the way, I think if we go the route of threshold signing updates it'd make sense to have a separate app for alpha/beta testing. Otherwise you'd have to get multiple developers to sign off on each beta update which is too heavyweight.
I think just hiding synchronisation feedback entirely if there is less than N days to catch up on makes sense, where perhaps N can be something like 7. For progress bars, yes it does work, you're already indicating progress with the "2 days left" text anyway. The progress would just be the inverse of the countdown. The bitcoin-qt way to calculate progress is a lot more complicated than what we need. But even with a threshold on it, it'd be better not to hide the balance IMHO.
If we separate "connecting" from "synchronising" then the bogus stall issue will go away. I don't think we can do better than 5 seconds in every case. The reason is that bringing up connections at the P2P level is already pretty fast, but if you aren't on wifi then the 3G/GSM protocols impose a quite high latency on using any data at all. The reason is they have significant "cold start" issue .... if no data was used for a while then the radio link has collapsed down to a low power/low resource usage state and bringing it back up to speed requires handshaking with the tower and complicated/slow state transitions in order to reserve some bandwidth. Then there's a fair amount of plain old transmission latency (500msec+ is not unreasonable) due to the interleaving and error correcting mechanisms used on older 3G protocol revisions. HSPDA improved latency a lot by reducing the transmission time interval but if you have a plain old 3G or (ugh) GPRS connection then they use very large batches to reduce the impact of interference.
Does "stalled" really have a purpose? I am trying to think of what the usefulness is but can't see any.
I was auto updated.
When exactly did that happen? I'm asking because I promoted the beta to a "staged rollout" for 20% of the users just today, so it isn't clear if you received 3.07 as a beta or a production version if you received it today.
Quote
The higher visibility of the buttons is useful, but I'm not keen on the change to how "Synchronizing with network" is displayed. It's weird to have the balance not be visible until synced, also, putting the label big up there emphasises its problems. Namely that it tends to show "Synchronization stalled" for a few seconds at the start whilst the network connections are being brought up which is confusing, and there's no obvious indication of progress if your network connection is slow. It should really be using a more standard progress bar type arrangement, and the bottom of the screen was fine for that.
But generally I don't like the way the balance is hidden until sync is done.
But generally I don't like the way the balance is hidden until sync is done.
Yeah its not ideal. The reason I was putting the message into the same space as the wallet balance is because since some months, I've already hidden wallet balance while replaying, so the space was kind of unused. Sure, updating the blockchain is not always the same as replaying, but its not that far off either.
One option to fix this is not showing blockchain progress at all as long as it is no replay. In most cases, it finishes very fast anyway so users won't miss it. Downside is, if you replay your wallet without the app knowing its a replay (e.g. because of an address import) you will see an invalid balance.
Another option could be layering the message on top of the balance as long as it's no replay. This way, it would be clear that the balance is probably not correct until the layer on top disappears.
Progress bars don't work, and the best indicator is that bitcoin-qt abandoned their old blockchain progress bar in favour of more or less what Bitcoin Wallet does.
The "stalled" indicator is an unrelated issue. I could raise the threshold, but then again we could also work on connecting to peers faster. 5 seconds is a long time.
I was auto updated.
The higher visibility of the buttons is useful, but I'm not keen on the change to how "Synchronizing with network" is displayed. It's weird to have the balance not be visible until synced, also, putting the label big up there emphasises its problems. Namely that it tends to show "Synchronization stalled" for a few seconds at the start whilst the network connections are being brought up which is confusing, and there's no obvious indication of progress if your network connection is slow. It should really be using a more standard progress bar type arrangement, and the bottom of the screen was fine for that.
But generally I don't like the way the balance is hidden until sync is done.
The higher visibility of the buttons is useful, but I'm not keen on the change to how "Synchronizing with network" is displayed. It's weird to have the balance not be visible until synced, also, putting the label big up there emphasises its problems. Namely that it tends to show "Synchronization stalled" for a few seconds at the start whilst the network connections are being brought up which is confusing, and there's no obvious indication of progress if your network connection is slow. It should really be using a more standard progress bar type arrangement, and the bottom of the screen was fine for that.
But generally I don't like the way the balance is hidden until sync is done.
I just uploaded 3.07 RC. If you want to participate, follow the instructions in the original post.
I'd appreciate feedback on any new problems with the app, and also please can you tell me if you previously have subscribed to the betas (3.05 RC and 3.06 RC), did you automatically receive 3.07 RC or do you need to re-subscribe?
Changes for 3.07:
* make request and send coins action buttons more visible
* stay connected a little bit longer if there was transaction activity on the wallet
I'd appreciate feedback on any new problems with the app, and also please can you tell me if you previously have subscribed to the betas (3.05 RC and 3.06 RC), did you automatically receive 3.07 RC or do you need to re-subscribe?
Changes for 3.07:
* make request and send coins action buttons more visible
* stay connected a little bit longer if there was transaction activity on the wallet
3.05 was released yesterday. I just uploaded 3.06 RC which merges block explorer and peer monitor into an unified network monitor. If you want to participate in testing, follow the instructions in the previous post.
I'll be using the alpha and beta channels of Google Play
for publishing release candidates and preview versions of Bitcoin Wallet.
beta = release candidates
alpha = previews
If you want to become/stay a tester, you need to be either member of
the bitcoinj mailing list or a member of the Google+ Bitcoin
community. Next, visit this link and follow the instructions:
https://play.google.com/apps/testing/de.schildbach.wallet
If you did not yet backup your private keys, now would be a good time to do.
I just published 3.05 RC to the beta channel (alpha is unpublished at
the moment). Let me know how this works for you. I'll still be uploading
versions to the download page at Google Code for users without Google
Account.
for publishing release candidates and preview versions of Bitcoin Wallet.
beta = release candidates
alpha = previews
If you want to become/stay a tester, you need to be either member of
the bitcoinj mailing list or a member of the Google+ Bitcoin
community. Next, visit this link and follow the instructions:
https://play.google.com/apps/testing/de.schildbach.wallet
If you did not yet backup your private keys, now would be a good time to do.
I just published 3.05 RC to the beta channel (alpha is unpublished at
the moment). Let me know how this works for you. I'll still be uploading
versions to the download page at Google Code for users without Google
Account.
Jump to: