weex (OP)
Legendary
Offline
Activity: 1102
Merit: 1014
|
|
April 01, 2013, 05:31:43 AM |
|
I have been downloading the chain for a few hours and have triggered the label change bug on a Motorola Atrix but also didn't send a report. I'm a little confused as to how the app is named. Am I correct in assuming more than one app can exist with the same com.example.sub.app identifier?
|
|
|
|
|
|
|
|
The Bitcoin network protocol was designed to be extremely flexible. It can be used to create timed transactions, escrow transactions, multi-signature transactions, etc. The current features of the client only hint at what will be possible in the future.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
Simran
|
|
April 01, 2013, 05:42:28 AM |
|
[qulongweex link=topic=157932.msg1713123#msg1713123 date=1364794303] I have been downloading the chain for a few hours and have triggered the label change bug on a Motorola Atrix but also didn't send a report. I'm a little confused as to how the app is named. Am I correct in assuming more than one app can exist with the same com.example.sub.app identifier? [/quote]
As long as the the sub and app variables are different, there shouldn't be an issue.
|
*Image Removed* Donate LTC: LRgbgTa3XNQSEUhnwC6Ye2vjiCV2CNRpib Donate BTC: 1AGP6xPTRvsAVhsRsBX13NUH6p6LJjyeiA
|
|
|
Andreas Schildbach
|
|
April 01, 2013, 09:46:14 PM |
|
Note that in the Bitcoin Wallet repo there is a bitcoinj-0.8 branch that will become version 3.0 soon. I'd cherry-pick some of the commits, like support for checkpoints. Ah yes, and please replace my wallet@schildbach.de email address by something you own. I'm already starting to receive reports...
|
|
|
|
EtherDais
Member
Offline
Activity: 60
Merit: 10
|
|
April 01, 2013, 11:27:35 PM |
|
|
|
|
|
msm595
|
|
April 02, 2013, 12:03:07 AM |
|
https://play.google.com/store/apps/details?id=de.schildbach.wallet.litecoinThe app is live - feel free to try it out! Let me know if anything's broken. There shouldn't be too many bugs that don't also apply to Bitcoin Wallet for Android and/or bitcoinj since this app is completely derivative. As far as bounty goes, I vote that msm595 gets half for litecoinj. It was exactly what I've been waiting for in order to do this project! Awesome, and thank you very much
|
|
|
|
ralree
|
|
April 02, 2013, 12:35:03 AM |
|
I can't be bothered fixing the drivers today, so I'll do that tomorrow. Meanwhile, I figured out how to send the report, it will however not send it to you but to schildbach. Here's a snippet from the report: IllegalArgumentException:Unknown URL content://de.schildbach.wallet.litecoin.address_book/*address* Not sure if that helps at all. Ah I think I know how I can fix that. I'll try and do that some time this week, and I'll post here when it's fixed. Thanks!
|
1MANaTeEZoH4YkgMYz61E5y4s9BYhAuUjG
|
|
|
ralree
|
|
April 02, 2013, 12:36:05 AM |
|
Note that in the Bitcoin Wallet repo there is a bitcoinj-0.8 branch that will become version 3.0 soon. I'd cherry-pick some of the commits, like support for checkpoints. Ah yes, and please replace my wallet@schildbach.de email address by something you own. I'm already starting to receive reports... Sorry about that - I'll get on that ASAP.
|
1MANaTeEZoH4YkgMYz61E5y4s9BYhAuUjG
|
|
|
ralree
|
|
April 02, 2013, 12:40:31 AM |
|
Syncing is definitely an issue - it takes a REALLY long time and heats up the phone (performing scrypt constantly is probably a great way to drain your battery!). Solutions to this problem are welcome, and should probably be directed at litecoinj instead of the app. msm595: Is there any way we can speed this up?
|
1MANaTeEZoH4YkgMYz61E5y4s9BYhAuUjG
|
|
|
ralree
|
|
April 02, 2013, 12:50:45 AM |
|
If everyone having trouble would file bugs here, I'd appreciate it: https://github.com/hank/litecoin-wallet/issuesI added the ones I know about. Thanks! Also, I just changed the email in the Constants.java file to my own, and uploaded the APK to play, so in a while 1.02 will be available. Please upgrade.
|
1MANaTeEZoH4YkgMYz61E5y4s9BYhAuUjG
|
|
|
msm595
|
|
April 02, 2013, 01:23:41 AM |
|
Syncing is definitely an issue - it takes a REALLY long time and heats up the phone (performing scrypt constantly is probably a great way to drain your battery!). Solutions to this problem are welcome, and should probably be directed at litecoinj instead of the app. msm595: Is there any way we can speed this up? I've noticed the same problem, but unfortunately I don't see a way that could dramatically speed it up without skipping the scrypt (and therefore skipping the check to see if the block has valid proof of work). We could assume that every block has a valid proof of work up to a certain recent checkpoint, but I don't know what the fully ramifications of that could be. There is a checkpoint mechanism in place for SPVBlockStore, let me play around.
|
|
|
|
wtogami
|
|
April 02, 2013, 02:54:26 AM |
|
Syncing is definitely an issue - it takes a REALLY long time and heats up the phone (performing scrypt constantly is probably a great way to drain your battery!). Solutions to this problem are welcome, and should probably be directed at litecoinj instead of the app. msm595: Is there any way we can speed this up? I've noticed the same problem, but unfortunately I don't see a way that could dramatically speed it up without skipping the scrypt (and therefore skipping the check to see if the block has valid proof of work). We could assume that every block has a valid proof of work up to a certain recent checkpoint, but I don't know what the fully ramifications of that could be. There is a checkpoint mechanism in place for SPVBlockStore, let me play around. Skipping scrypt up to the last checkpoint seems entirely reasonable as you are already relying upon the client to be trustworthy?
|
If you appreciate my work please consider making a small donation. BTC: 1LkYiL3RaouKXTUhGcE84XLece31JjnLc3 LTC: LYtrtYZsVSn5ymhPepcJMo4HnBeeXXVKW9 GPG: AEC1884398647C47413C1C3FB1179EB7347DC10D
|
|
|
ralree
|
|
April 02, 2013, 03:01:56 AM |
|
Syncing is definitely an issue - it takes a REALLY long time and heats up the phone (performing scrypt constantly is probably a great way to drain your battery!). Solutions to this problem are welcome, and should probably be directed at litecoinj instead of the app. msm595: Is there any way we can speed this up? I've noticed the same problem, but unfortunately I don't see a way that could dramatically speed it up without skipping the scrypt (and therefore skipping the check to see if the block has valid proof of work). We could assume that every block has a valid proof of work up to a certain recent checkpoint, but I don't know what the fully ramifications of that could be. There is a checkpoint mechanism in place for SPVBlockStore, let me play around. Skipping scrypt up to the last checkpoint seems entirely reasonable as you are already relying upon the client to be trustworthy? Maybe it would be acceptable to users to allow faster blockchain syncing by downloading a signed (with my developer key) base block to start with, let's just say block 320,000. That way, if I understand correctly, they could start from there and verify everything after it, still strengthening the network once they catch up. The signed data could be distributed embedded in the app (which is also signed). This feature could be defaulted to OFF to allow the user to elect this behavior. Thoughts?
|
1MANaTeEZoH4YkgMYz61E5y4s9BYhAuUjG
|
|
|
wtogami
|
|
April 02, 2013, 05:19:20 AM |
|
Skipping scrypt up to the last checkpoint seems entirely reasonable as you are already relying upon the client to be trustworthy?
Maybe it would be acceptable to users to allow faster blockchain syncing by downloading a signed (with my developer key) base block to start with, let's just say block 320,000. That way, if I understand correctly, they could start from there and verify everything after it, still strengthening the network once they catch up. The signed data could be distributed embedded in the app (which is also signed). This feature could be defaulted to OFF to allow the user to elect this behavior. Thoughts? The trouble is off-by-default means the majority of users won't use it. Off-by-default also means many users who try the app too easily give up because first sync is too slow, then proceed to leave an unwarranted nasty rating. Also see Goonie's note that is important to this issue.. ad 4: Protocol version 70001 (Bitcoind/bitcoin-qt 0.8.x) contains a very important enhancement for SPV clients called Bloom Filters. It saves a huge amount of traffic, RAM and CPU cycles. Without these optimizations, mobile clients simply can't scale.
This SPV wallet will be a whole lot faster and more network efficient in syncing only after Litecoin upgrades to 0.8. The team plans on making this a reality a few months from now. There will be a separate fundraising effort for Litecoin-0.8.
|
If you appreciate my work please consider making a small donation. BTC: 1LkYiL3RaouKXTUhGcE84XLece31JjnLc3 LTC: LYtrtYZsVSn5ymhPepcJMo4HnBeeXXVKW9 GPG: AEC1884398647C47413C1C3FB1179EB7347DC10D
|
|
|
weex (OP)
Legendary
Offline
Activity: 1102
Merit: 1014
|
|
April 02, 2013, 08:45:29 AM |
|
Maybe it would be acceptable to users to allow faster blockchain syncing by downloading a signed (with my developer key) base block to start with, let's just say block 320,000. That way, if I understand correctly, they could start from there and verify everything after it, still strengthening the network once they catch up. The signed data could be distributed embedded in the app (which is also signed). This feature could be defaulted to OFF to allow the user to elect this behavior. Thoughts?
Checkpointing is a decent idea to help with initial sync speed. For maximum safety, the checkpoint should be based on a block that is a few hundred blocks behind the current block.
|
|
|
|
ralree
|
|
April 02, 2013, 01:29:31 PM |
|
Skipping scrypt up to the last checkpoint seems entirely reasonable as you are already relying upon the client to be trustworthy?
Maybe it would be acceptable to users to allow faster blockchain syncing by downloading a signed (with my developer key) base block to start with, let's just say block 320,000. That way, if I understand correctly, they could start from there and verify everything after it, still strengthening the network once they catch up. The signed data could be distributed embedded in the app (which is also signed). This feature could be defaulted to OFF to allow the user to elect this behavior. Thoughts? The trouble is off-by-default means the majority of users won't use it. Off-by-default also means many users who try the app too easily give up because first sync is too slow, then proceed to leave an unwarranted nasty rating. Also see Goonie's note that is important to this issue.. ad 4: Protocol version 70001 (Bitcoind/bitcoin-qt 0.8.x) contains a very important enhancement for SPV clients called Bloom Filters. It saves a huge amount of traffic, RAM and CPU cycles. Without these optimizations, mobile clients simply can't scale.
This SPV wallet will be a whole lot faster and more network efficient in syncing only after Litecoin upgrades to 0.8. The team plans on making this a reality a few months from now. There will be a separate fundraising effort for Litecoin-0.8. Good point about off-by-default - I could have a first-time-use popup that asks "Would you like to use a checkpoint to speed up blockchain sync or verify the entire blockchain?" Bloom filter optimization would be awesome, so I'm looking forward to that. This app is just a simple first step that will get people using litecoins day to day, which I think was the entire point (or at least it was for me). I'll look into implementing checkpointing soon.
|
1MANaTeEZoH4YkgMYz61E5y4s9BYhAuUjG
|
|
|
Andreas Schildbach
|
|
April 02, 2013, 04:18:16 PM |
|
Maybe it would be acceptable to users to allow faster blockchain syncing by downloading a signed (with my developer key) base block to start with, let's just say block 320,000. That way, if I understand correctly, they could start from there and verify everything after it, still strengthening the network once they catch up. The signed data could be distributed embedded in the app (which is also signed). This feature could be defaulted to OFF to allow the user to elect this behavior. Thoughts?
Checkpointing is a decent idea to help with initial sync speed. For maximum safety, the checkpoint should be based on a block that is a few hundred blocks behind the current block. The BuildCheckpoints tool from bitcoinj-tools does exactly that, although the threshold is based on time (currently one month). There is no benefit in opting out of checkpointing - you already trust the app to do the right thing. If anything, a couple of developers should audit the checkpoints file that goes live with a release.
|
|
|
|
weex (OP)
Legendary
Offline
Activity: 1102
Merit: 1014
|
|
April 02, 2013, 10:58:08 PM |
|
Well I've had a chance to test this wallet out and was able to receive and send funds out again.
I am ready to award the bounty so need an LTC and BTC address for both ralree and msm595 as I will split it evenly between you two.
|
|
|
|
msm595
|
|
April 02, 2013, 11:14:31 PM |
|
The BuildCheckpoints tool from bitcoinj-tools does exactly that, although the threshold is based on time (currently one month).
There is no benefit in opting out of checkpointing - you already trust the app to do the right thing. If anything, a couple of developers should audit the checkpoints file that goes live with a release.
Awesome. I was not able to see or verify if/where checkpoints are acknowledged in SPVBlockChain, even though this is mentioned in CheckpointManager.java: "Checkpoints are used by a {@link BlockChain} to initialize fresh {@link com.google.bitcoin.store.SPVBlockStore}s". Well I've had a chance to test this wallet out and was able to receive and send funds out again.
I am ready to award the bounty so need an LTC and BTC address for both ralree and msm595 as I will split it evenly between you two.
LTC: LQz2pJYaeqntA9BFB8rDX5AL2TTKGd5AuN BTC: 1LSbhxShMmymNQ1Li5qd7pYUgrMUcVTokc Thanks
|
|
|
|
ralree
|
|
April 03, 2013, 01:23:36 AM |
|
Well I've had a chance to test this wallet out and was able to receive and send funds out again.
I am ready to award the bounty so need an LTC and BTC address for both ralree and msm595 as I will split it evenly between you two.
LerikguvK4nTvhk5XUp8ofg2JgLqAGnBV3 1MANaTeEZoH4YkgMYz61E5y4s9BYhAuUjG Thanks for putting this together!
|
1MANaTeEZoH4YkgMYz61E5y4s9BYhAuUjG
|
|
|
ralree
|
|
April 03, 2013, 01:25:44 AM |
|
Awesome. I was not able to see or verify if/where checkpoints are acknowledged in SPVBlockChain, even though this is mentioned in CheckpointManager.java: "Checkpoints are used by a {@link BlockChain} to initialize fresh {@link com.google.bitcoin.store.SPVBlockStore}s".
If you figure that out, let me know what I have to do to implement it. The blockchain fully synced and the app is working great for me now.
|
1MANaTeEZoH4YkgMYz61E5y4s9BYhAuUjG
|
|
|
|