Pardon my confusion. I don't use Twitter. What's "tagged"? It's more a github term than a twitter term, it just means the source code has been finalized and the installers are just around the corner. Congrats!! |
|
|
|
Is it displaying the correct top block now?
Yes. |
|
|
|
This looks like a benign symptom of the same general issue. Did you make sure Armory was displaying the proper top block?
I didn't, sorry, but I would guess it wasn't. I shut down Armory just before sending out those log files. I started it back up shortly after (and the symptom did not reoccur). Here's the log from that start: -INFO - 1425231061: (..\BlockUtils.cpp:1597) Reading headers from db
-INFO - 1425231062: (..\BlockUtils.cpp:1623) Found 345730 headers in db
-DEBUG - 1425231062: (..\Blockchain.cpp:211) Organizing chain w/ rebuild
-WARN - 1425231063: (..\BlockUtils.cpp:1285) --- Fetching SSH summaries for 417 registered addresses
-INFO - 1425231063: (..\BlockUtils.cpp:1298) Left off at file 237, offset 47797915
-INFO - 1425231063: (..\BlockUtils.cpp:1301) Reading headers and building chain...
-INFO - 1425231063: (..\BlockUtils.cpp:1302) Starting at block file 237 offset 47797915
-INFO - 1425231063: (..\BlockUtils.cpp:1304) Block height 345607
-DEBUG - 1425231063: (..\Blockchain.cpp:211) Organizing chain w/ rebuild
-INFO - 1425231065: (..\BlockUtils.cpp:1339) Looking for first unrecognized block
-INFO - 1425231065: (..\BlockUtils.cpp:1488) Loading block data... file 237 offset 47797907
-ERROR - 1425231065: (..\BlockUtils.cpp:536) Next block header found at offset 47797915
-INFO - 1425231065: (..\BlockUtils.cpp:564) Reading raw blocks finished at file 237 offset 86249538
-INFO - 1425231065: (..\BlockUtils.cpp:1356) Wrote blocks to DB in 0.029s
-WARN - 1425231065: (..\BlockUtils.cpp:1074) Scanning from 345607 to 345717
-INFO - 1425231065: (..\BlockUtils.cpp:1450) Scanned Block range in 0.86s
-INFO - 1425231065: (..\BlockUtils.cpp:1453) Finished loading at file 237, offset 86249538
-INFO - 1425231065: (..\BlockDataViewer.cpp:155) Enabling zero-conf tracking
The unscanned block numbers 345607 to 345717 roughly correspond with the timestamps in the log file I sent you, that's why I'm guessing it wasn't on the top block. Edit: sorry I'm wrong, 345607 was the most recent block after initially starting Armory (in the logs I sent). The odd logging symptom didn't start until a couple of hours later, so I'm not sure how to interpret the log pasted in above. |
|
|
|
I've no idea if it's related to this branch, but I sent you the full logs just in case.
In the support channel? Ticket #? Or did you add a link to this thread, or asked for me by name? The migration to the new ticket system left the support channel in a weird state. Sorry, I should have been more specific. Ticket: ARMORY00000469, I did mention your name in the ticket body. |
|
|
|
|
I don't have any of the "repair" messages yet, but something odd did happen. I've no idea if it's related to this branch, but I sent you the full logs just in case. The only thing odd was the content of the armorycpplog file, there were no other symptoms.
|
|
|
|
(Slightly OT) FYI BIP39 wordlists aren't guaranteed to use unique words wrt each other; in particular the two Chinese word lists share over 50% of their words so you'd probably need to choose one over the other (or neither). |
|
|
|
|
I don't know the first thing about ASIC programming.... but if you're writing software that requires a large iteration count (PBKDF2, etc.) I'd probably take the "easy" way out and just do the first iteration in software, and do the rest with a single hash block and a hard-coded data length in the ASIC (what I lazily do with GPU/OpenCL-based stuff).
|
|
|
|
Solo miners generally need to run a full node in order to mine effectively. How does it allow them to mine more effectively? If you convince a miner to accept an invalid tx, and it includes it in a block, the block will be ignored by all full nodes, wasting the miner's time. Although you could (probably?) create a client that validates transactions w/o a full copy of the blockchain, it seems pretty inefficient to me (you'd have to query other nodes for each new tx you intend to place in the new block I'd imagine?). they believe it makes their wallet more secure. It seems it would make it less secure… There are known weaknesses and attacks against SPV clients. Although they don't appear easy to pull off in practice, if you're dealing in high value transactions then you can afford to run a full node and be "better safe than sorry." (Cold vs hot wallets is a different issue. There's no reason you can't use a cold wallet with a hot watching-only full-node-based wallet.) |
|
|
|
updated the fix some more, people running this fix please pull and build again.
Thanks, done. You can quick search for the word "repair". If that shows up, you had the issue again, and the fix worked.
Will do (nothing yet). |
|
|
|
I think such a mechanism for Bitcoin would be great, but I'm skeptical that any such mechanism would meet a reasonable set of minimum requirements. My own set of requirements would include:
Easy to remember
Easy to set up/maintain
Decentralized
No address re-use It does everything above, since the proof is a simple partial merkle tree (no trust relationship), that can reference a BIP70 address, as opposed to a fixed address, all data is stored on the blockchain. I thought we agreed that it didn't meet both "Easy to set up/maintain" and "No address re-use" at the same time, given that BIP70 isn't easy to run on your own (or it fails "Decentralized" if you use a 3rd-party processor which implements BIP70)? |
|
|
|
breadwallet is compatible with Hive-JS (their web interface which stores keys locally in your browser encrypted.) or Hive-iOS.
Hive for Android and Hive for MAC OSX are not HD.
FYI Hive for Android has been HD for a few months now. It shares the same (Cordova-based) JavaScript source as the iOS version. |
|
|
|
|
There are no bitcoin-payout incentives for operating a full node, but that are less tangible ones.
Operating a full node means you can do full bottom-up validation of all transactions, instead of relying on height-based validation. It also prevents evil nodes which you may connect to from withholding transactions from your view.
In other words, if you're regularly dealing in high-value transactions, running a full node is definitely a good idea. If not, than the only other incentive I can think of is that warm-fuzzy feeling from helping out a good cause.
|
|
|
|
Would you memorize your bank account number? I won't.
Why should I memorize by bitcoin address?
I don't think that's a fair analogy. (I think) OP's desire was to make it easy to create or reference a receive address in informal situations without carrying anything with you (e.g. splitting a bill with a friend). Traditional transaction mechanisms do that just fine today (cash: don't need to remember anything; checks: just need to remember your own name; centralized e-money (e.g. PayPal), just need to remember your email address/account ID). I think such a mechanism for Bitcoin would be great, but I'm skeptical that any such mechanism would meet a reasonable set of minimum requirements. My own set of requirements would include: - Easy to remember
- Easy to set up/maintain
- Decentralized
- No address re-use
If you can't achieve all of the above, than you need to prioritize. I'd nix either the first or the second, and that's what we already have today (base58check or BIP70). I think nixing either of the other two would be a worse idea, but that's subjective. |
|
|
|
|
I hit the BDM error yesterday. I'm running the 0.93-bugfix branch as of this afternoon. The initial rebuild finished without issue.
I'll post back if I see any of the new log messages in armorycpplog (none so far).
|
|
|
|
Nothing special is when they rename it, use a source which they are not made and then add some salt in it.
OP specifically said he wasn't interested in altcoins, but in interesting forks which haven't been merged into Bitcoin (and presumably have some chance of being merged in the future): Regarding my original question: I mostly wanted to know about interesting extensions to the original code (and no, not altcoins).
Read the whole thread... the referenced forks are interesting. Making something new from the bottom is the real thing and I support only that.
The original idea, not stolen one.
If Satoshi had agreed with that point of view, it seems unlikely he would have released Bitcoin under the MIT License. 'Course it's hard to disagree with your sentiment regarding the quality of most altcoins.... |
|
|
|
Except you can't expect average Joe to manage his own domain name, and host his own payment server.
Average Joe can create an account on a third party payment server though.
That's kind of the point though. If Joe can't run his own payment server (and wants to avoid address re-use), then he's stuck with a centralized solution anyways. And if he's stuck being centralized, there doesn't seem to be much reason to use the blockchain to look up some account ID if the centralized provider he's chosen can do it instead. But such server : either provide an url that can't be remembered and easily spelled. ( http://payment.com/u/dzopUDZiziK) Either use the user's name ( http://payment.com/u/toto), but in such case, you can easily get misspell the user name or domain, resulting to money sent to someone else. If the payment processor implements an easy URL scheme with a short checksum, than that's great. It doesn't require encoding anything on the blockchain, though. Maybe there's more merit to the static-address solution you've described. I'm skeptical that it offers much improvement over firstbits, but I could be wrong. |
|
|
|
 R.I.P.  |
|
|
|
If the blockchain address references a TxOut that is a OP_RETURN, then, it checks if the content is a Bitcoin Payment URL. (fix the address reuse problem, because if it is BIP70, a new address will be evaluated each time)
It sounds like your scheme (in the BIP70 case) is simply a URL shortener, except that in some cases it will end up being more of a URL lengthener.... remembering a few random English words seems harder to me than simply remembering a domain name that one creates for that purpose. It would be useful if services provided the option for a user to provide an extended pubkey. For example since people love change addresses a forum like this could have a field on the profile where the user provides an extended pubkey. The site would not display the address publicly but would compute the next address from the extended pubkey and display that. When a transaction is detected it would increment and display the next address.
At least one online wallet does this, for example if you'd like to send me a tip, visit here: https://greenaddress.it/pay/GAMiQ3yzZFD6djdqpYo4YGdRHrMot/ (they have only my xpub, assuming of course that you trust their client software isn't malware). |
|
|
|
Exactly. By the way, are you the developer of that software?
That depends... do you like it?  (yes, I am) Yes, I found it great. I did run into that google error, but It might have been fixed when I do a .key. I know that it would of found the password had I not remembered... Thanks! Also, your setup tutorial is pretty idiot-friendly It's way too long, though... I'm thinking of breaking it up into smaller pieces so it at least doesn't seem so intimidating. Haven't decided yet. In any case, thanks for the kind words, they're much appreciated! |
|
|
|
|
Show Posts
