For logging-in scenarios you are definitely right, however in this case this is a one-time action. This is not about loggin in, this is only to link an anonymous player to another account. This is only possible once in a players lifetime, so i think it is not really necessary to add a nonce or similar. Right?
Well again, what you are currently doing is having them sign something self-evident. All that signature proves is that "The owner of address X agrees with the following statement: 'I own address X'". Instead, you should have them sign something like "The email address someone@email.com is the address that should be associated with username <username>". I don't know exactly what you're having them authorize with their signature, but it should be explicit. |
|
|
|
|
Remember, signatures don't "prove ownership", they prove that the person holding the private key agrees with the statement being signed.
As such SignWithPrivateKey(X, "I confirm that I own address X") is something that the owner of address X always agrees with. I don't have to own X... I just have to ask the owner of X to sign that statement, and he may not object, because he really does own X -- then I use that signature to unauthorized login to your website.
Even if your way did "work", you have a serious problem: you are having them sign the same string every time: an attacker only needs to get the signature from any one login, and then they can use it to sign in, too. There must be a unique "challenge" for them to sign, such as a 128-bit random number generated everytime. Or something like:
"Please sign the following with address X: My IP address is 103.38.271.18 and I am signing into this service at 10:43am EST on Feb 12, 2013. 38201844".
It's still not high-quality crypto/security, but it's at least more closely-related to your goals.
|
|
|
|
|
I have one lingering, serious issue with this solution as I work to implement it... creating bitcoin.conf in Windows with a username and password, and then setting read permisison on that file only for that user. Permissions on Windows is pretty darned ugly. On the other hand, I think Windows blocks off users' directories by default, so maybe this isn't so important -- but I need to be diligent in making sure this is done right. I don't want to induce security holes in Bitcoin-Qt because of this!
So in both Windows and Linux:
(1) I check to see if the /home/username/.bitcoin directory is there (or equiv on Windows).
(2) If not (because they've never run Bitcoin-Qt), I create it.
(3) Check whether .bitcoin/bitcoin.conf file exists
(4) If not (because they've never used RPC interface), then I create it with simple username and a random 128-bit password
(4a) If we just created the file, set the permissions on it so no other users can read it! In Linux, it's trivial to use os.chmod(...). Windows, not so simple!
(5) Start bitcoind as a separate process
(6) Start up "guardian" process (as recommended by picobit), pass it the PID of both bitcoind and the PID of Armory.
(7) Read bitcoin.conf file and extract username and password
(8) Connect to bitcoind RPC, and monitor synchronization status
(9) On clean shutdown, kill bitcoind, then kill guardian.
(9a) If Armory is killed, then the guardian will see the PID disappear (or change names), and it will kill the bitcoind instance and exit.
There's a lot of complexity with #8, because there is not a hard definition of "synchronized", but I think I have something sufficient figured out for that (estimating when bitcoind is sync'd, and only then starting the Armory BlockDataManager). My main concern is making sure that 4a is done correctly.
In Linux, it seems like default behavior is for users to be able to read each other directories (including malicious system processes can, too), and thus it is very important to set the permissions on that file. In Windows, it looks like default is for users to not even be able to open the home directories of other users. I tried digging into the Windows permissions on the file, and it's not even clear to me how those permissions are supposed to be set.
Anyone here even use bitcoind.exe in Windows? Do you do anything to secure your bitcoin.conf file?
|
|
|
|
I was thinking how the "change addresses" thing will cause problems eventually. Why? Well because 99% or more of bitcoin users do not know about that, they think that if they have BTC in the address A and they spend some of them, then they will just have less btc in address A. They make a paperwallet, backup, or whatelse and meanwhile use it.
Then when one day they will use the paperwallet they will notice that the btc are no more in that address but in a new one due to how the "change" works.
Or not?
Would it be possible for the client to let the user designate the change address? Like have the send money dialog pop up, you imput the amount and receiving address, and there is a checkbox with "Send change to new address", which if you uncheck, then you can input a change address (or choose between address in your wallet). This could be something which is turned on/off in the settings. If you are interested in coin-control and/or not having problems with change with a "paper wallet", then use Armory Bitcoin Client. Every time you import/restore your paper backup, you get the same infinite chain of Bitcoin addresses, and you can use a new address for every tx. And all change is sent to addresses on that chain, too. There's no risk of coins going somewhere that's not backed up. But if you really want, Armory will let you specify the change address/behavior. You can either specify an address to use, or have it send all change back to one of the input addresses. The second one is particularly useful if you want to have a wallet with a finite number of imported addresses, and cycle through them. But this is all in the same vein as Coin-Control -- users that actually understand how Bitcoin works like these options, but it's just confusing as hell to everyone else. That's why this is only available in Expert usermode in Armory. From the main menu, click on "User"-->"Expert" then restart Armory. Customizable Change: Coin Control: |
|
|
|
Thanks for your prompt reply. New wallets on the way? Could you point me where I can find some info about these new wallets?
The new wallets are based on BIP 32. This is a standard that was developed with the Bitcoin-Qt core devs, and planned to be adopted by Bitcoin-Qt, Multibit, Electrum, and I'm sure others. It's a solid "deterministic wallet" algorithm that is secure and extremely flexible. And soon "standard." This means that you will have a root key and chaincode that can be plugged into any program and you'll get the same wallet (the programs most likely won't have the same wallet file format, but the addresses will all be derived the same way from the same seed data). There's a lot of cool things I'm doing with the new wallets, but it'll be some time before I get them done. And some other priorities popped up. But the important part is that since it's based on BIP 32, it will be easier to switch to and from Armory without having to create and maintain different wallets. Would it be possible to guarantee that the wallet can be restored even for someone with absolutely no skills? My main concern, and one of the reasons I chose Armory and the offline wallet option, was to ensure that in the event of my sudden demise, my family would still have access to my wallet. I'll try to keep up with Armory as the years go on, but I'd like to know that even in the worst-case scenario timing-wise, my kids would be able to access them.
This really isn't possible. The algorithm for generating addresses is based on elliptic curve cryptography, which is "complicated" and critical to the security of the scheme. No matter how you look at it, you're going to need an app that understands the input data and knows how to apply the algorithm (though, for a cryptographer, the algorithm is dead simple). However, in the event of your demise, if your family finds your paper backup, they will see "Armory" and the logo on it, and only a little bit of googling should lead them to my website. Once they are there, they will eventually recover your coins. Also, as mentioned previously, brainwallet.org also generates that address chains for you, though you have to import them into an app (like Armory) in order to use them, so you might as well just get Armory and recover the wallet. And as mentioned -- even if Armory was discontinued -- if Bitcoins are valuable enough to be worth recovering, any prior version of Armory will be sufficient for recovering the coins. On that note, maybe I will add a screenshot of a paper backup to the front page, so in an event like you are talking about, the person who shows up at the website will immediately see they're at the right place. |
|
|
|
Imagine I create an offline wallet with a Linux LiveCD. I print a paper backup (or save an encrypted copy of the PDF), and I send all my savings to the addresses in that wallet.
In 10 years I need to access my funds. Imagine that Armory was discontinued, I don't have any copy of the old Armory I used to produce the paper backup, and I only have the piece of paper with me. Can I import that wallet to the standard Bitcoin-Qt? Is any way to retrieve the private keys in the Armory wallet using the paper backup, but without using Armory?
You have to know the algorithm that was used to recreate the keychain from the data on the paper backup. This has been the same ever since the very first release of Armory, and it's not complicated. Brainwallet.org has the algorithm implemented in javascript. Even when I update Armory to the new wallets, it will still have support for the old ones. I find it difficult to believe that even in 20 years, it would be impossible to find any copy of Armory that ever existed. Information persistence on the internet is pretty good. If you are still concerned about it, it you can write down the algorithm yourself. It will fit in the corner of the piece of paper. Or you could print off the piece of code, which is a bit more verbose, but will still fit on one piece of paper: SecureBinaryData CryptoECDSA::ComputeChainedPrivateKey(
SecureBinaryData const & binPrivKey,
SecureBinaryData const & chainCode,
SecureBinaryData binPubKey)
{
if( binPubKey.getSize()==0 )
binPubKey = ComputePublicKey(binPrivKey);
// Adding extra entropy to chaincode by xor'ing with hash256 of pubkey
BinaryData chainMod = binPubKey.getHash256();
BinaryData chainOrig = chainCode.getRawCopy();
BinaryData chainXor(32);
// XOR hash of pub key and chain code
for(uint8_t i=0; i<8; i++)
{
uint8_t offset = 4*i;
*(uint32_t*)(chainXor.getPtr()+offset) =
*(uint32_t*)( chainMod.getPtr()+offset) ^
*(uint32_t*)(chainOrig.getPtr()+offset);
}
// Hard-code the order of the group
static SecureBinaryData SECP256K1_ORDER_BE = SecureBinaryData().CreateFromHex(
"fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141");
CryptoPP::Integer chaincode, origPrivExp, ecOrder;
// A
chaincode.Decode(chainXor.getPtr(), chainXor.getSize(), UNSIGNED);
// B
origPrivExp.Decode(binPrivKey.getPtr(), binPrivKey.getSize(), UNSIGNED);
// C
ecOrder.Decode(SECP256K1_ORDER_BE.getPtr(), SECP256K1_ORDER_BE.getSize(), UNSIGNED);
// A*B mod C will get us a new private key exponent
CryptoPP::Integer newPrivExponent =
a_times_b_mod_c(chaincode, origPrivExp, ecOrder);
// Convert new private exponent to big-endian binary string
SecureBinaryData newPrivData(32);
newPrivExponent.Encode(newPrivData.getPtr(), newPrivData.getSize(), UNSIGNED);
return newPrivData;
}
That function is how to get from one private key n to private key n+1. The only other thing you need to know is how the "easy-type-base64" alphabet maps to hex: NORMALCHARS = '0123 4567 89ab cdef'
EASY16CHARS = 'asdf ghjk wert uion'
The mapping was chosen to make slightly obfuscate the data, but also because it's easier to type than raw hex (most people don't touch-type numbers well). |
|
|
|
By the way... My multi-wallet operation, it worked amazing. I ran 103 wallets  Though, it's really small, had some trouble scrolling all the time  Glad the wallets worked out! I really should make the main window into a "splitter" so that you can configure how much vertical space is used for the wallet list vs ledger. What I will do in the near future is add to my TODO list: make the wallet table sortable. I imagine that might make it a bit easier to navigate... I would love the option to have a sound play when receiving/sending Bitcoin, in addition to the system tray notification.
About once every six months I decide I'm going to do this. I look up examples of how to do it, and it seems really simple. So I do it. And it doesn't work. I look for more examples, but the only thing I find is the super-simple thing that doesn't work for me. So I give up. And forget about it for 6 months. I remembered now, because I tried it again just before I left for my two week vacation and failed again. Perhaps it's a problem with my particular setup and it wouldn't fail for everyone else. Since I just reinstalled my OS, I will try again soon! |
|
|
|
Okay! Finally returned from two weeks in Thailand! Of course I had to leave just as we were changing webhosts and the DNS wasn't setup properly. I couldn't seem to get it fixed while I was away, but it should be fixed now. There should be no more website issues from here forward! (except for the version checking, but I made sure that a failed version check doesn't bother the user). I see a lot of big news in the BTC world since I left. 50% increase in value is nothing to sneeze at! It's making me a little anxious to get some of these usability upgrades implemented. Soon! I have to pick some priorities, and just tackle them at full speed. I think the resource usage and load times are the big ones. And if I can get the auto-manage-bitcoind-in-background going, then Armory would actually be not much more inconvenient than running Bitcoin-Qt 0.8. It's a shame because I actually made quite a bit of progress on the new wallets while sitting on trains, planes and buses in Thailand. But I think SD is putting too much pressure on me and I have to push the resource usage up on the priority list. On a related note: I was thinking of upgrading my primary system before getting too comfortable in my old work environment. When trying to download Ubuntu, I ran into this:  Besides the non-obvious "you are not actually required to give us money, just download here" button, this seems like a good model for me to copy. Add a new tab to the main window very much like this. Have a running list of major features, and let users contribute to the ones they would like to see completed first. If the total contribution amount is above X, then they will have the opportunity to enter their address and I'll send them the appropriate gift from my website (T-Shirt, Casascius coin, USB key, etc). |
|
|
|
It is too bad that you've activated your "reading between the lines" skill and started writing emotional responses. I never called you "inadequate".
2112, You're still missing the point. As I've said in other threads -- I get a sense that you know what you're talking about, but you provide nothing actionable -- only criticism. Yet, threads like this would benefit from actual experience and advice you might have instead of just criticism. I'd like to have a rational conversation with you, but I can't because the only tool in your toolbox is for insulting people's intelligence. Here's how this thread could've gone: etotheipi: Hey, how's this database structure look? 2112: Have you considered using a relational DB engine instead of LevelDB? It looks like that's what you're trying to recreate and LevelDB isn't production quality. etotheipi: Possibly. LevelDB has properties A,B,C,D and E all of which fit perfectly into my app. My use case is simple enough that I don't mind the lack of relation-handling. 2112: You really shouldn't use LevelDB because it's a toy. Take a look at SomeDB1, it's got properties A,C,D, and E, and also adds F and G etotheipi: But I really want property B for some reason, and G is not that important to me 2112: Try SomeDB2, it has properties A,B,C,E,F. You could change your structure to storing blocks like <> and headers and merkle roots like <> and you'd have everything you want. etotheipi: I've never heard of SomeDB2, I'll look into it. Thanks! See how pleasant that is? No one has to be insulted, and you're experience/expertise is pleasantly communicated in a way that I don't have to lose face to even begin to agree with any of your points. It's not that avoiding "losing face" is my number one priority, it's that your writing style (which I still can't tell if it's intentional or not) immediately turns the whole thread hostile. You seem to want to insult more than help. You could have a constructive relationship with the users on this forum that you are trying to help. |
|
|
|
LevelDB is very simple, the code has a permissive license and can be bundled directly into the codebase, and it creates very space efficient databases that are encapsulated in isolated directories that are easy to bundle and move around. And it's also damned fast. Accessing the data in key-sort order is about twice as fast as I have been able to achieve with raw, low-level operations. Some benchmarks with favorable performance. (though, while looking up those links, I see some benchmarks for BangDB which are even better, but it sounds new and I've never heard of it) I'm not saying other DB engines can't do that. I'm saying that LevelDB meets my needs and has all the properties I want. The fact that it isn't relational doesn't bother me because I don't really need it -- the data it is storing is rather simple. So, instead of simply criticizing my ideas and telling me how inadequate I am at developing applications, why don't you make recommendations for how you would do it? If you are familiar with other DB engines that have a permissive licence, will not result in terrible linking problems, create nice encapsulated DBs in directories, and still has very good performance, I'll look into it. You seem awfully good at criticizing, but you'd be much more credible & useful if you actually contributed to the discussion. |
|
|
|
So how can I further improve this? Am I missing use cases? Am I crazy?
About two months ago you had this discussion with Inaba: https://bitcointalk.org/index.php?topic=56424.msg1387216#msg1387216The two of you have gotten really close to reinventing the data-bound control from Visual Studio. When you were talking about search & filtering functionality it sounded like you wanted to reinvent the visual query builder from Microsoft Access or Microsoft SQL Server. I know that you have a copy of Visual Studio and you theoretically could prototype your design using the dirty, grimy, foul-smelling, ...ugh... relational ...ouch... SQL database engine really quick. I also know that this wasn't a feeback you are looking for, therefore I voluntarily jump into your "ignore" file making the "plonk" sound while hitting the bottom. I just need to say things once to be able to say "I told them so" in the future. Relevant posts from about half-a-year ago about playing the open-source poker at the NonSQL table: https://bitcointalk.org/index.php?topic=94453.msg1046848#msg1046848https://bitcointalk.org/index.php?topic=94453.msg1046473#msg1046473I actually have no clue what you're talking about. Storing transactions comments for display in the transaction ledger is completely unrelated to this thread. That was a case of something that was really simple, turning into something still really simple, but the code wasn't optimized for the worst case. I'm not going to bring in bulky, complicated relational database engines just to store some tx and address comments when I didn't need it for anything else. As for the comment that a relational database engine might be good -- well yes, that is a valid suggestion. And one I'm not oblivious to. There's a lot of value in keeping things simple, and dependencies to a minimum. LevelDB is remarkably fast, and its databases are extremely efficient (space-wise), maintained in standalone directories (easy to zip/tar and distribute), and the source code can be bundled directly into the project. These are all very valuable properties for me. There is some relational nature to the data being stored, but it's really not that complicated, and I'd prefer the fine-grained control using a DB engine that is simple and I know how to optimize for it. On the other hand, if there's a good reason to believe that it won't work, or that there's so many other reasons a relational DB engine would be preferred... I would appreciate that discussion. But within the scope of what I've describe, the theoretical capability of LevelDB is perfectly fine. As long as there is not some underlying vulnerabilities/problems with the implementation that will cause heartache later. |
|
|
|
This is just a brain-dump to get a sanity check on my logic before going and basing future versions of Armory on it. The idea here is to have Armory start managing its own blockchain data, but in a manner that is optimized for all forseeable use-cases. Keep in mind, this is LevelDB, and part of my design is based on how LevelDB works best (which is probably common to a lot of DB engines). LevelDB is a very simple but highly-optimized DB engine, which simply stores (key,value) pairs, where both keys and values are any string. LevelDB handles some degree of "ACID" operations, and it should behave very much like a disk-based version of a C++ std::map<string,string>. So here's my list of considerations in designing the new database: - (1) LevelDB has key-order-optimized access: if you access lots of data in key-sort order, it's super fast. If you do lots of random access... well it's not optimized for that. Here's how this matters: if you have (TxID, TxSerialized) pairs in a database, and you want to scan all transactions in a given block, you are going to be accessing data all over the DB. Each tx is retrieved from a different part of the disk and LevelDB doesn't know what data to prefetch for your next request. On the other hand, if you were to prefix each TxID with the 4-byte block height, then doing a full blockchain scan would be very optimized because each the next tx you will be requesting is the next key when sorted. LevelDB will be loading the subsequent blocks as you process the previous ones. However, this particular example isn't useful, since this doesn't let you do random lookup of tx without knowing the block number -- this is just an example of how we might shape our data to leverage LevelDB optimizations.
- (2) The structure should accommodate a clean transition to lite client mode (i.e. not have to redesign it)
- (3) The structure should accommodate a clean transition to pruned-blockchain operations
- (4) The structure should accommodate a clean transition to maintaining an address-indexed view of the blockchain
- (5) Minimal duplication of tx data -- ideally we'd only ever have TxIDs in the database once. Duplicating header data is not so bad, since that's strictly linear as a function of time, but tx data isn't (consider that there are 10 million tx, meaning that each extra copy of txids in the DB is another 320 MB).
With all this in mind, I have decided on the following set of databases (use || to represent concatenation of data): HeaderHashDB: key=HeaderHash(32), value=BlockHeight(4)
TxHashDB: key=TxID(32), value=BlockHeight(4)||TxIndex(4)
BlockDataDB: key=BlockHeight(4)||TxIndex(4) value=SpecialSerializedTx(VAR)
key=BlockHeight(4)||FFFFFFFF value=RawHeader(80)
MerkleDB: key=MerkleRoot(4) value=TxID0(32)||TxID1(32)||...||TxIDN(32) (optional, not sure if it's really necessary)
OrphansDB: key=HeaderOrTxHash(32) value=RawHeaderOrTx(80orVAR)
A few things about this: (1) BlockDataDB can store a variable amount of data -- full nodes will have one entry for every tx, but you don't have to have every tx: you can store just the ones you need. The TxHashDB for a lite node only needs to store the transactions that are relevant to that node, and BlockDataDB only needs to have those particular transactions available (and the BlockHeight||TxIndex keys will be non-existent for those other tx). You will have the 0xFFFFFFFF entry for each block height to maintain those headers. (1a) The structure of BlockDataDB achieves the goal of #1 above -- the sort-order for the all the keys in the BlockDataDB is the tx-order in the blockchain. If you're going to do a full scan, you only need to do a simple iteration over the entire database, and LevelDB will pre-fetch subsequent data for you. I have tested this with some experimental LevelDB code and it's stupid fast... much faster than my own low-level, highly-optimized blockchain scanning code in C++. (2) TxIDs and HeaderHashes are only stored exactly once (unless you also store the merkle DB, which I'm not sure is needed). If you need to verify the TxID, look it up in the TxHashDB know where to fetch the full Tx from the BlockDataDB and hash it to make sure it matches. (3) SpecialSerializeTx: this is a special way of serializing the transactions to allow for variable amount of data depending on the node type. This satisfies #3 above while still allowing for full reconstruction of the tx if you happen to have all pieces of it. NormalSerializedTx: Version|| N||TxIn0||TxIn1||...||TxInN|| M||TxOut0||TxOut1||...||TxOutM||LockTime SpecialSerializedTx: FFFFFFFF||(NormalSerializeTx-with-blank-TxOuts)|| TxOutIndex0(4)||TxOut0 || TxOutIndex1(4)||TxOut1 ||...|| TxOutIndexM(4)||TxOutM (3a) Just like (1a) above, this serialization accommodates any storage level: full nodes will have the full-tx-with-blank-txouts and every TxOut. Super pruned-and-lite nodes can skip FFFFFFFF entry, and exclude TxOuts it doesn't care about. So if you know that you own a TxOut in Tx X, then you can lookup Tx X and there will only be one entry: the TxOut that you own. (4) The orphans DB is simply for juggling data that does not yet have a home -- i.e. if you just re-org'd you want to keep the old block/tx data around, but you don't have a blockheight to attach it to, so you put it in the orphans DB until you need it again. The downside of this is that to get from a header hash to header data you have to do two DB lookups (HeaderHashDB to get blockheight, then go look up blockheight||FFFFFFFF in the BlockDataDB). Same for looking up Tx hashes. But I don't think it will be so bad -- at least the header map will probably be fully cached because it is small. Haven't tackled #4 (address-indexed database view), but I think it can be just a separate database that piggybacks on the structures of the DBs described above. I know it won't be simple, but it's also out of scope for now. I just want to make sure I don't end up having to redesign this structure when I finally do decide to tackle #4. So how can I further improve this? Am I missing use cases? Am I crazy? |
|
|
|
|
If it looks like the sparse, lower-level nodes have 256 pointers, you're looking at the wrong picture (or I didn't explain it well enough). The Brandais part is where the list of pointers is compressed to a linked list and thus there is only as many pointers as there are nodes (well, a little more, for the linked-list forward-pointers). This does increase search time to have to forward-traverse the linked list at each node, but they will be ordered, which means that it can be further optimized, and those kinds of lookups should be fast (in fact, they can be easily stored as simple lists, replacing the list on every update, since it's probably just as fast to do that with disk-based DB accesses). The important part is that if a parent has 5 children, those 5 children are in lexicographical order, and only their 5 "fingerprints" will be used in the computation of the parent's "fingerprint."
I don't think a hashmap works for this. I guess it depends on the kind of hashmap you're talking about -- but if it's a "simple" one where there are lots of collisions, you end up with some non-determinism based on insert order, and removing elements is complicated. But maybe I don't totally understand what you're proposing.
|
|
|
|
Since the last time I upgraded (0.87.2) I've noticed that Armory only runs for a few days before crashing. I finally ran it from the console so that I could get the error message. This most recent time I started up at block 220285 and it ran fine until this: New Block: 220990
Added new blocks to memory pool: 1
New Block: 220991
Added new blocks to memory pool: 1
New Block: 220992
Added new blocks to memory pool: 1
New Block: 220993
Added new blocks to memory pool: 1
New Block: 220994
Added new blocks to memory pool: 1
New Block: 220995
Added new blocks to memory pool: 1
New Block: 220996
New block file split! /home/justus/.bitcoin/blocks/blk00042.dat
Segmentation fault Yeah, the funny thing about that is I just completed a pretty exhaustive set of unit-tests using the 0.87.2-beta code base, to make sure that shouldn't happen. I set up the test with complicated blockfile splits and it runs flawlessly. But on the real network, it still segfaults... Unfortunately, I noticed it the night before I went out of town for two weeks so there was nothing I could do. If you've seen some of my other threads about Armory managing its own blockchain, that is in my immediate plans and will make this problem go away entirely -- in fact a lot of problems will go away, since most are related to colliding with bitcoind/-qt file management. I am going to start the new blockchain management stuff (using leveldb), and get a feel for how long it's going to take. If it's going to be smooth, I might just skip fixing this, since it's strictly an artifact of "the old way." Or maybe I'll do both ... I'll run Armory in the debugger while writing the new code and see if I can catch the segfault and put out a temporary fix. |
|
|
|
The benefit of using PATRICIA/Brandais hybrid is that it's a "standard" datastructure. And it's one that seems to fit this use case pretty perfectly. I just followed you pseudocode and I think you are basically proposing the same thing as the PATRICIA tree, but using implicit skip strings, instead of explicit ones. It can be reasonably argued that the skip strings are not necessary to authenticate the structure, but I think you are introducing extra complexity into the algorithms for inserting and deleting nodes, in exchange for simplifying authentication. It's very difficult to describe without a well-thought-out example, but you can probably see it yourself if you try to work out the logic for worst-case-logic-complexity of an insert or delete operation. It involves uncompressing, inserting/removing nodes, recompressing on both sides, and then rearranging a ton of pointers. If the skip strings are not attached to the nodes, you have to recompute it from the children which involves a lot of string compares, and probably a bit slower. I had to program the insert function for a patricia tree in as a homework assignment in college, once. It was a mess... and kinda fun  As for the comment about node overhead: I couldnt' follow your math (looks like you were missing 256-way trienodes with binary trie nodes), but I think something you're overlooking is the linked-lists for the pointers at each node (assuming some power of 2 branching factor more than 2^1). This means that nodes with only one child, only store one pointer. It is wasteful for the top levels where you have linked-list overhead for super-dense nodes, but the majority of data is near the leaves where the optimization saves you a ton of space. Plus, because the top nodes are constantly changing, you can optimize them in code pretty easily to be more pleasant for both query-time and space-consumption. I need to think a little harder about the benefits of using a binary-PATRICIA tree... it pretty much removes the necessity for the Brandais aspect of it (compressing node children into linked lists), and certainly adds a bit of compute-efficiency to it at the expense and taking more space (I think the binary trie will be faster at updating the authentication data, but will have more intermediate/branch nodes to be stored). Unfortunately, I have too many super-high priority things on Armory in the next month or two, so there's no way I can get around to playing with this, yet. However, I may eventually be doing some kind of electrum-style version Armory, in which I will split Armory both ways -- into an Armory supernode and Armory litenode. The supernode will do something like we're discussing here, and the lite nodes will depend on having access to a trusted supernode. It sounds like a good time to prototype this idea... |
|
|
|
Let's say, 30 wallets and 2 addresses used in each one. I'll be OK?
That would actually be 102 used in each one, because Armory maintains a lookahead list of addresses 100 beyond the last used (for a variety of reasons). Either way, that's still only 3k addresses. I believe that the number of transactions combined among all addresses is the more important factor... having 1 address with 1,000,000 transactions (like an SD address) will be far more stressful than 10,000 addresses with 1 tx each. On the other hand, I'm mostly speculating based on how I designed it. But speculations aren't always right. Try it out and let me know! Though, because of what I said before, you should consider whether you can get by with fewer wallets using more addresses each, solely due to the way the GUI is designed. |
|
|
|
32GB RAM your just playing Call of Duty. But ok from now there is really no reason for me to be running constantly anyway. Glad to know you're on it.
I don't play many games anymore. The 32 GB of RAM is because I usually have 3+ virtual machines running at the same time, all running Bitcoin-Qt and Armory. It's for testing its performance on multiple OS. Plus, if I spend a lot of time digging into the C++ code, it's really nice to have a Windows VM with MSVS to do debugging of C++ ... nothing beats it... What's the maximum amount of wallets that can be loaded at the same time?
There's no arbitrary maximum. It ultimately comes down to how many addresses you have combined in all your wallets. I can tell you that I have run with tens of thousands of addresses, and there is no problem (but as we just noted, I also have 32 GB of RAM). But the number of addresses is not really the bottleneck -- the size of the blockchain is. So unless you are doing crazy stuff, like generating millions of addresses for research/experimental purposes, there should be no problem. Note that each wallet generates the next 100 addresses by default... so a new wallet will have the number of addresses actually used, plus 100. One thing you might find annoying is that the interface isn't designed very well for lots of wallets -- for instance, you can't sort or resize the wallets table, and you can't do arbitrary filtering of the ledger (i.e. -- only show transactions from wallets A, E, F and Q). Other than that, it should work... |
|
|
|
I apologize if this is discussed in this thread already, I could not find the search thread function here.
I have also just upgraded to Bitcoin 0.8 RC1. I can not say for sure this wasn't the case before that but should Armory.exe be using over 2GB memory and it crashes quite regularly on my system.
Unfortunately, this is real. A real consequence of SatoshiDice growing the blockchain much, much faster than I anticipated. The original Armory used to hold the entire blockchain in memory, requiring the user to have more than 2 GB. This was resolved by switching from storing the blockchain itself, to just storing file pointers to the tx/block data in RAM. Unfortunately, with 10+ million transactions in the blockchain, even this tx index is too big for RAM. That's why one of my major upgrades in the near future (besides new wallets) consists of switching everything to LevelDB databases. Armory RAM usage should drop by an order of magnitude and run much more smoothly on less-powerful computers. It comes with a few other nice benefits, too. But at the expense of duplicating all the blockchain data (but it is needed anyway, if I'm going to ever have Armory connect to remote Bitcoin-Qt/bitcoind instances). For now, you'll just have to hold on until I get the chance to replace the RAM usage with HDD usage. A lot of users are getting shut out... so this has become a very high priority... and one I tend to forget about because I have 32 GB of RAM on my development computer |
|
|
|
Not much time to respond now, but I wanted to point out the the PATRICIA tree concept has no balancing issues -- if it looks like it does, it's strictly an illusion. The reason is this: Take a standard, non-level-compressed trie, as shown in my previous post. There is no question that this is a O(1) data structure: if you use 256-way trie, it always takes exactly 20 hops to get from root to the leaf of a 20-byte address string. It has O(1) query, O(1) insertion, O(1) deletion. All operations on a PATRICIA tree are strictly less than the equivalent implementation of a trie. Basically, the upper bound of computation time for any PATRICIA tree operation is that of the non-level-compressed trie. It's just that the number of hops that you shortcut as a benefit of level-compression, is variable depending on the data in the tree/trie. The amount of operations you get to skip can be altered by an "attacker", but the worst they can do to you is require the performance of a trie -- which is O(1). Re: skip strings: there's no way you can use a basic trie for this -- the space overhead of all the intermediate (and unnecessary) nodes would overwhelm the data that is being stored. In fact, even with level compression and linked-list nodes, I'm still very concerned about the space overhead -- I suspect we may be storing something like 3x the size of the underlying UTXO set just to store this DB. I just pulled that number out of nowhere (3x), because I haven't rigorously explored it for various branching factors ... but it was one of the downsides of the trie-based structures compared to the BSTs. |
|
|
|
I have just upgraded to Bitcoin 0.8 RC1 and I find that my Armory 0.87 beta would sometimes stop updating. The block count in the right bottom corner shows "Connected (220817 blocks)" but Bitcoin-qt is already showing 220903. Armory stills shows new tx, but the number of confirmation remains 0 despite it has been confirmed. Everything was back to normal for a while after Armory is restarted, but it would somehow stop updating again. 2013-02-12 20:34 (INFO) -- ArmoryQt.py:3205 - Dashboard switched to fully-online mode
2013-02-12 20:34 (INFO) -- ArmoryQt.py:3205 - Dashboard switched to fully-online mode
2013-02-12 20:37 (INFO) -- ArmoryQt.py:3410 - New Block! : 220809
2013-02-12 20:37 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 20:37 (INFO) -- armoryengine.pyc:9372 - Received new block. 0000000000000074a783b4427337c720ddc63727dea306f7fc5bb90c17d470bc
2013-02-12 21:18 (INFO) -- ArmoryQt.py:3410 - New Block! : 220810
2013-02-12 21:18 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 21:18 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000003688e6effc415f0551dc8452da8ba8dec22d6035f1559618649
2013-02-12 21:25 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 21:25 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000004829f8ec992570ad67a07c21d0ac188895446c6908a3ec77ce3
2013-02-12 21:25 (INFO) -- ArmoryQt.py:3410 - New Block! : 220811
2013-02-12 21:28 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 21:28 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000043751773e28d37e5b1628ef08bfde6bdbe13131cf4b1129a8b7
2013-02-12 21:28 (INFO) -- ArmoryQt.py:3410 - New Block! : 220812
2013-02-12 21:35 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 21:35 (INFO) -- ArmoryQt.py:3410 - New Block! : 220813
2013-02-12 21:36 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000004a2e96fc0e15cba01f0570c1aece435c11e3ec11d24a8ee9804
2013-02-12 21:36 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 21:36 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000002b4f3f0538deddecf04d7dad72402331977c76576283a8d1f4d
2013-02-12 21:36 (INFO) -- ArmoryQt.py:3410 - New Block! : 220814
2013-02-12 22:07 (INFO) -- ArmoryQt.py:3410 - New Block! : 220815
2013-02-12 22:07 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 22:07 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000002bbfbe339f3dd48316c20b21be7ce1bdb5b5f131f0db296036a
2013-02-12 22:27 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 22:27 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 22:27 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000004667e989a5ad255d6baa7f59db4db3906b02dc128634bf95a18
2013-02-12 22:27 (INFO) -- ArmoryQt.py:3410 - New Block! : 220817
2013-02-12 22:27 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000003200a65a5146f8e894704976bd21d1cf209e2dc8c7f3d0d40ea
2013-02-12 22:34 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 22:34 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000015142450a030a8641e9a70290027eaaa8f8d52a6bd9d2afcac4
2013-02-12 22:42 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 22:42 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000038600b771887da5b3830947bb3ea129f8fc571cec43990410d3
2013-02-12 22:42 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 22:42 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000001a5964a6deca4a1b842889652e4c301f10a311de51d7a3d2e7
2013-02-12 23:04 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 23:04 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000000c9de2b7ce3bd605cfed4dbbbcd3b3498c9e0946fe5dd0f2296
2013-02-12 23:08 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 23:08 (INFO) -- armoryengine.pyc:9372 - Received new block. 0000000000000412718fa5a1984a5a675746cf26199bf6cca60a501eaf842382
2013-02-12 23:18 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 23:18 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000003e6afbd5a7215acedbc023c1749a2718145dae1a6c35feb4d71
2013-02-12 23:33 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 23:33 (INFO) -- armoryengine.pyc:9372 - Received new block. 0000000000000426c1c65d6b80deac16358d74c342724ef1ecfa9a1e0dc00e0e
2013-02-12 23:39 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 23:39 (INFO) -- armoryengine.pyc:9372 - Received new block. 0000000000000481f700e78826444fc7cc621dd31026b0e48fa2237289284414
2013-02-12 23:42 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 23:42 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000022ac4a92fe52d54369a983bd6a317761af0c81dbee919798271
2013-02-12 23:54 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-12 23:54 (INFO) -- armoryengine.pyc:9372 - Received new block. 0000000000000219272cdf8221744445a5dad573b31407b9a880d0118f714ba9
2013-02-13 00:25 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 00:25 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000003cc8969bd449abd4e4e2dcf519a0110982748f00ca2db5753a4
2013-02-13 00:33 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 00:33 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000002ce1618afdb84ebfd380049e1afa889ffe25f1b454e07a78039
2013-02-13 00:34 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 00:34 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000001954c5d59d02efe184b1519afed0b00b12586fb5aff9e7c8310
2013-02-13 00:47 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 00:47 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 00:47 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 00:47 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000004f958de0219d509e8ba156d9893f4903f9fa6c23edfed5ef565
2013-02-13 00:47 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000000eb3c170ca260e1dffa2b1a91772dcae18a4df3446f377bd1b4
2013-02-13 00:47 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000040681ba05ed54daa23667b2673d3ef6acbabd2dc36c95d66ab7
2013-02-13 00:48 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 00:48 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000001f94f1644dfd3d056e5098d325b4b2bf4cb3c2690d7006c1a87
2013-02-13 01:03 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 01:03 (INFO) -- armoryengine.pyc:9372 - Received new block. 0000000000000379de774e67d9bdb305af68a956f891c548f0da19c538a79071
2013-02-13 01:10 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 01:10 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000001cfaf40b52daf78d4cf9c0e93e427c242b90386ea6aae9d079b
2013-02-13 01:23 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 01:23 (INFO) -- armoryengine.pyc:9372 - Received new block. 0000000000000437a3ec102cf9050b7a26c0d986acf74cf9b3d6eff8ad7959de
2013-02-13 01:42 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 01:42 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000004af3c30dac15e153941696c078a8e5c968bfe364de9a858e7c0
2013-02-13 01:57 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 01:57 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000000576ea85bd5de07bdbc81a00549f6d20f8549b04a7597f5d64a
2013-02-13 02:00 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 02:00 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000002bc74b17eb31d45dcac53ec1ba082c0bc7113e73ec32bae952f
2013-02-13 02:09 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 02:09 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000015bd9e602c027f1eb2367ec7a8c8d4d70baa44cb27e86c6af81
2013-02-13 02:18 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 02:18 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000003ac4741d68090c24d6b7c3fd201a20f781c97759d472fec49a5
2013-02-13 02:45 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 02:45 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000029b96bec10dc57876c04c434af46751d6cc472c06cd1c92feec
2013-02-13 02:48 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 02:48 (INFO) -- armoryengine.pyc:9372 - Received new block. 0000000000000043808648eabbeda3022a41cb311bfb6d9af9fc1520b8061ec8
2013-02-13 02:53 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 02:53 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000003b45a22c6e1959fd0e79061998e4c2ac5147fb9a99751fa5576
2013-02-13 03:00 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 03:01 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000000c32ac05e662ee9bd4d222b549abe10178fb544d6e6f26e93c9
2013-02-13 03:21 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 03:21 (INFO) -- armoryengine.pyc:9372 - Received new block. 0000000000000334d1548d2423a37efd06ace379021b2b8385e483964fffa300
2013-02-13 03:44 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 03:44 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000013255a453dde9658c72a6e0f25d305554448361f35b529b2b73
2013-02-13 03:44 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 03:44 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000004cbe8d606dc4ba12dbd5cb1341aebac36d7865b5114c8eee0d
2013-02-13 03:51 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 03:51 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000020bcc1e59ce644505748582a62f4459b94a5f882fafbfbb3ba3
2013-02-13 03:52 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 03:52 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000004b3cd2392613cfc92956e0e7a0031f61bc2f7df29734f5d5ea8
2013-02-13 04:02 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 04:02 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000024553030a164723359019d23ad199392f8a0a15a5e0099db2fd
2013-02-13 04:02 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 04:02 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000034daa0096eeded10790f95d5818abfb25c51f1fcbe7e2bb355d
2013-02-13 04:08 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 04:08 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000003900a5672134b4cf28e6644aa8910f4ac6949cf7f4a261cc026
2013-02-13 04:25 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 04:25 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000004af9c6b6a73d0070f174565ba88b5b0c08e752684f28ee6c716
2013-02-13 04:36 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 04:36 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 04:36 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000039ca2e3e0878ed6a01ab21dac204e542bc30a1a2f3dacbe254a
2013-02-13 04:36 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000046667582296b65fe3aa46b381ac1721529641a131a23f0b8cc5
2013-02-13 04:42 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 04:42 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000001d7ff7cd8e0b0dd99d98a240a3a46600542fa8d5971a88450c
2013-02-13 04:45 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 04:45 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000004142fb1be064fbecac5aa5f2425e3e8ac81c2983774119f5df7
2013-02-13 05:01 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 05:01 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000028e922fc468545b37d57384bad8bf0e8865608a00db449c399e
2013-02-13 05:18 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 05:18 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000002d58bea826565a1c18bab38cef66dbb574c3bc50720af4d3644
2013-02-13 05:37 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 05:37 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000042ad6a204886aab4a988a8a93a88c11db279cc2245b76d29742
2013-02-13 05:42 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 05:42 (INFO) -- armoryengine.pyc:9372 - Received new block. 0000000000000040bd33ab8464677122f1c549a7993c67b3fb5d22365c84d961
2013-02-13 05:45 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 05:45 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000003eb48fbc7e7f17f49977b7938b5430459ce98821a3f81af360c
2013-02-13 05:48 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 05:48 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000031547d290a9f4b59cdfaebc82560c0da63ccf0ef435b547fcb6
2013-02-13 05:56 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 05:56 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 05:56 (INFO) -- armoryengine.pyc:9372 - Received new block. 0000000000000431d261f1612e14e5dd6f92f66fe27faabce1bd5e1a3ae53e1d
2013-02-13 05:56 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000003371e40ad12f89d6f2f23a8b3e2df23f19ca75d4ac082e04d68
2013-02-13 06:24 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 06:24 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000003df0f60971ba1a88de2fd3a89a203dbcf5862629bd0920d3a2c
2013-02-13 06:34 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 06:34 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000002284bc9ab5c6fe33f7941a98a175f028c8643ce61fcbb4311d8
2013-02-13 06:40 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 06:40 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000006d7aaf3feeecda7e3f12bfabe4848ff866e391d2460a8dc35c
2013-02-13 06:46 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 06:46 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 06:46 (INFO) -- armoryengine.pyc:9372 - Received new block. 0000000000000492908d9d0271cc1655799c04bbfe1145c18683f67b8627c04b
2013-02-13 06:46 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000002a5c33e8eefbfc2912dcb1109f4ce4ed19abd708d3de921907
2013-02-13 06:49 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 06:49 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000028283a043aab59527db4e040e4cf551d6ef35811726e33e0733
2013-02-13 07:09 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 07:09 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000036770a969c85cea0f7fe3c2779032bc90aecfb0a71dd6cbc7fa
2013-02-13 07:35 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 07:35 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000001dcce624bb3d76337c1f7c4e8c1ed5b18a6f82f99b3ce8da7d
2013-02-13 07:49 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 07:49 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000000abb59be4be356bf9bb9b9935c220aa6993c871985925416320
2013-02-13 08:05 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 08:05 (INFO) -- armoryengine.pyc:9372 - Received new block. 0000000000000038e39a10defe06fef9f21d07556b54ae13aa57156dab628417
2013-02-13 08:17 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 08:17 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000005c6d7b6836836cdd5b01b0a37363befff5eb715ea063615ef1
2013-02-13 08:24 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 08:24 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000003759bee816c1839bb0d045e73c9565f121e51a66627be4291cc
2013-02-13 08:25 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 08:25 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000015a0d2846f580d3f02763480bddd88a3f5f28a6e67620f47809
2013-02-13 08:45 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 08:45 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000004673b271204959ac69f294ee6eeb179ff1568b3b072205e140
2013-02-13 08:49 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 08:49 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000004415cfdfdec7dd9ce8bbe57cc63bbdd565256b9dc2bd952ed2
2013-02-13 08:56 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 08:56 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000002b2c2816eede3e5094bce80d28e410ebc994315862210ac00da
2013-02-13 09:06 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 09:06 (INFO) -- armoryengine.pyc:9372 - Received new block. 0000000000000022bf19f7191a0752402bf6ac5d078fdcc2c4ec19a461414bec
2013-02-13 09:24 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 09:24 (INFO) -- armoryengine.pyc:9372 - Received new block. 0000000000000321aa510c47e67cd9ec69a0c748b5fc619fe647e9bafbcd7cba
2013-02-13 09:30 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 09:30 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000001494a50cdf8052692eb3b835ccb0e0ea74ff278da755fb418bf
2013-02-13 09:37 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 09:37 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000051a25052e0699c1f7295b9c7ebd4999ac99498c462d32d1f632
2013-02-13 09:48 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 09:48 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000001dcca7d765f095078af64cb1553833335bef676fc74db85283c
2013-02-13 09:49 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 09:49 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000001f5fd9e3877102f68641d95308b1088cd4367eb1958be6492c0
2013-02-13 09:56 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 09:56 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000017e1883d4266c0faf4789436b7eda06a8c77e7b9d624fa80b52
2013-02-13 09:58 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 09:58 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000004ebb76cb1d8db0ea1eb9dd48919fb8dfe78a0dfdbc8730ebf60
2013-02-13 10:03 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 10:03 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000001faa5f06c81b98ef9d008b5853243fa8449c1b4b1f2e6c76194
2013-02-13 10:07 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 10:07 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000023ba949750231780415d8f78d417a3f31f4582ca0cdc94c61f1
2013-02-13 10:40 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 10:40 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000001cd76584294b036573375f69242add97919c617913bd11b0e13
2013-02-13 10:45 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 10:45 (INFO) -- armoryengine.pyc:9372 - Received new block. 00000000000000da7e927f6836ab33d59b2d178058287450aaeccb4294f6f628
2013-02-13 10:52 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 10:52 (INFO) -- armoryengine.pyc:9372 - Received new block. 000000000000013b888d5d830863e5ecf719cd66b6042405186bed59c434d500
2013-02-13 10:58 (INFO) -- armoryengine.pyc:9355 - New block broadcast received
2013-02-13 10:58 (INFO) -- armoryengine.pyc:9372 - Received new block. 0000000000000443f105fb58797a444555e52626eb5dbc170ae026693a4c67c3 This is the log. It seems armoryengine.pyc keeps receiving new blocks, but ArmoryQt.py is stopped at 220817 (and somehow 220816 is missing) My system is Windows Server 2008 R2 x64 I'm fairly certain this was resolved in 0.87.2. I noticed this happening too, and I think it had to do with re-organization handling and/or multiple blocks coming in at the same time. Both ofwhich were fixed in that newer version. I didn't trigger notifications for 0.87.2 because I had just released 0.87 and didn't want to spam users with non-critical updates. |
|
|
|
|
Show Posts
