I think we diverged here. I was kind of under the impression that we were coming up with a BIP 10+ that was more versatile (like, having a compact binary representation) so it could also be implemented in your device.
The protocol which I proposed is built on top of Protocol buffers. Having a separate parser for another format just to comply with BIP10 doesn't look smart enough. I'd really like to see this "protocol" standardized across devices and applicaitons -- which was the original goal of BIP 10, but I was the only one using it, so it never really got the versatility of a real "standard"... I stopped developing it when it worked for Armory, knowing it would be expanded later.
The conversion from BIP10 to something built on top of PB can be quite straightforward, so even BIP10-compatible software might convert the format for the device easily. To be honest, I didn't study internals of the BIP10 protocol yet, I just watched the protocol format. ...that there won't need to be any special conversion for your device to be able to understand it
You still need some desktop software to work with the device. As far as Armory or Electrum will support this device and Armory or Electrum implements BIP10, there's really no need why device itself must understand BIP10. Or any simple desktop (command line) tool can convert BIP10 format and pass the transaction into the device over USB. It sounded like you said the device could regenerate all of its addresses/public keys from the root ... but given the other limitations of the device
It will be computed by the computer, not by the device. I don't see problem here. The protocol can easily be unified with all other devices/applications (i.e. BIP 10+) if you can have the device recognize its own addresses/pubkeys. I was hoping for that unification, but it may not be achievable/efficient to do so.
This protocol is low-level layer for communication between the device and desktop software. This protocol must be optimized for low-resource devices and must be really minimal. There's no need why this should use BIP10 at all. So the real divergence here was that I assumed the device would be somewhat "independent." It sounds like, instead, your device will be wholly dependent on a host computer to do most of the work for it, and the device will literally only sign. There will always be a computer-in-the-loop with your watching-only wallet to reformat the thing-to-be-signed into this low-level format for the device. I had anticipated the device take, from any computer anywhere, a BIP10-like data stream, recognize it's own public keys/addresses, and get user confirmation to sign it. Okay, we're on the same page now. My point is valid, that a BIP10+ could potentially serve this purpose if we added extra complexity to accommodate devices that don't even know their own address pool, but it's not necessary. So, if you have some enormous transaction to sign, let's say with 100 inputs and the transaction data was 100 kB, can you at least hold 100 OutPoint-Value pairs in RAM? i.e. you feed in first supporting transaction and output index (because your transaction will be spending that output from that tx) and the device will hash it and confirm that the hash and then store the hash and output value in RAM. Then repeat for all supporting transactions to collect a list of "verified" outpoint-value pairs. Then when you feed in the transaction to be signed, it can go through it's local memory to confirm each outpoint that belongs to you to be signed. Then, it sounds like, if that transaction is actually 100 kB, then you can't even hold the whole thing at once. If you have to sign 30 inputs, you would pass it in 30 times, each time with a different txin-script-in-txout-script-place-and-all-others-blanked. The thing can accumulate the hash as it goes, and then pass out the signatures one at a time when it's done reading the final transaction. Is that too crazy? Or should the device be limited to handling transactions that will fit nicely into its cache? It could be a requirement of the software that interfaces it (Armory, Electrum, etc), that it will prevent the user from sending tx bigger than X kB...? However, even if this tx is within the size limit, there's no guarantee that any of your supporting transactions is within the size limit. |
|
|
|
|
I think we diverged here. I was kind of under the impression that we were coming up with a BIP 10+ that was more versatile (like, having a compact binary representation) so it could also be implemented in your device. I'd really like to see this "protocol" standardized across devices and applicaitons -- which was the original goal of BIP 10, but I was the only one using it, so it never really got the versatility of a real "standard"... I stopped developing it when it worked for Armory, knowing it would be expanded later.
So, I was hoping that your device would simply implement the same BIP 10+, and everyone is happy. I'm looking for the possibility that someone who creates a TxDP on their desktop, and requiring 3 other signatures, some of which may come from regular desktops, offline computers and/or your devices, that there won't need to be any special conversion for your device to be able to understand it, recognize its own keys, and sign it (after user confirmation).
With that in mind, I think someone42 mentioned the device won't hold its own address list, and thus this protocol requires telling the device which keys belong to it and what address index those keys are in the wallet. I really wanted to avoid that, if possible, since it complicate other use cases. It sounded like you said the device could regenerate all of its addresses/public keys from the root ... but given the other limitations of the device, I would think that calculating 200 public keys from a root private key every time would take a while. And once you've used it a lot, 200 may not be enough. If this is an unavoidable implementation, then we may be required to split the use cases into different "standards", but I hope you recognize the value of aiming for a single standard.
tl;dr The protocol can easily be unified with all other devices/applications (i.e. BIP 10+) if you can have the device recognize its own addresses/pubkeys. I was hoping for that unification, but it may not be achievable/efficient to do so.
|
|
|
|
Implementing NTP directly in the device is without a chance, it is completely out of the focus.
However there can be some API for storing/retrieving timestamp to/from the device. But it will be just a dumb storage of the value and it will be up to the computer's software if it will use it or not. I cannot imagine anything useful what can be done with the timestamp by the device.
You're right that timestamps will be probably more and more in the future as people typically use recent wallets. Except that the device is designed more like a cold storage, so that timestamp optimization won't improve user experience for most of the users. Still, if storing timestamp of the seed generation will be useful, we can include it.
Yeah, we don't need to get too sidetracked on that topic. I was just stating that even if you could store timestamps with each address, I'm not sure you're getting too much value out of it. However, let me get back to the previous topic I brought up -- what's the chance you could store a raw addr160 list on the device? Here's what I said before: I don't know how the HW device will be dealing with addresses (or what is possible memory-wise), but I have found it extremely useful to store the keys even though they are derived from the root. Not only does it allow me to store birthdays and comments/labels, but (most importantly) I can search for an address and know if it's in my wallet without re-doing all the computation. If it's possible to at least maintain addr160 list in non-volatile memory, it will make everything quite a bit easier.
I am hesitant to "endorse" requiring key-indexes to be included in the TxDPs (as I call them in BIP 10, perhaps another phrase+acronym would be better). The reason is to do with multi-sig, which makes sense to accommodate here -- since there's like 90% overlap between what's needed for offline wallets and multi-sig. There will be situations where the TxDP will be created by another party who doesn't have your watching-only wallet, they are only supplied a public key to include in the transaction. They don't know how to specify what your address index is, and your offline device will have no way to detect what public keys belong to you. I guess you could have an optional field so that your online computer could "amend" the TxDP with your address index, but that sounds complicated.
I know it sounds premature to think about multi-sig for your HW device, but I don't think it makes sense to over-complicate that use case if it can be avoided. If we must accommodate devices that can't even store their own address list, then we have to deal with it, but it's worth trying to avoid. And in the end, even with 5000 addresses, that's only about 100 kB to store a raw addr160 list...
If the hardware device can only store the root, then it's going require either: (1) a computer holding the watching-only wallet for the offline device to create the TxDP to be signed, or (2) When you give someone your public key for a multi-sig tx you gotta supply an address index with it somehow so they can include it, or (3) The TxDP must pass through the computer holding the watching-only wallet so that it can be amended with the correct address index. |
|
|
|
The clock might be wrong... but it's not gonna days or weeks wrong.
Hardcore Americanism detected!  The month-day-year versus day-month-year ambiguity with dates is an endless source of the errors that stick is thinking about. People in USA don't see is as often because most of the BIOSes and other low-level tools use the American layout. But it trips over many Europeans. Wait till Americans start importing Czech-made wallets that use day-month-year order... I personally hate the American system. It doesn't make any sense. Though, I'm not sure how relevant it is here: UTC unix time is the "path of least resistance" for storing timestamps in binary files, and thus wouldn't have that problem. Part of the reason I avoided this is because there's a lot that can go wrong with offline computers. The clocks could be totally wrong with no access to the internet, and thus they don't know the block height at birth, either. I could insert special cases where I know one or the other based on what information is available at the time it was recorded in the log file. But then I have to treat all conditions of {have/donthave} {block/time}. And as I said... I think getting it wrong and silently missing parts of the user's wallet could be a disaster -- those could literally be lost forever, because no program that ever reads the file would check before the recorded time. The end result is that users would just want to scan everything anyway, just to be sure. |
|
|
|
The clock might be wrong... but it's not gonna days or weeks wrong.
That's wrong assumption. If the battery on your motherboard is empty the date would be 1.1.1970. I can come up with some other scenarios where the date/time is seriously incorrect. You're stretching. Anything is "possible" but using a 0.01% case to justify giving new users a bad experience is not reasonable. I'm not sure. The "cost of misclassification" is not symmetric. It takes 5 minutes to do it right 99.9% of the time, but it takes 7 min to do it right 100.0% of the time. And given the heartache associated when it's done wrong, why not just take the 7 minutes? At least, that's been my attitude, even if you don't agree with the trade-off. |
|
|
|
First, wallet creation date is much different than individual key creation dates.
...except the device doesn't with the keys, but with the seed (BIP32/Electrum). Device don't store private keys or any metadata for particular addresses. However such metadata can be stored on the computer, using master public key as a wallet identifier. Edit: Device can teoretically store timestamp of the seed generation, as some quick-and-dirty workaround. However this still must be provided by the computer, which will probably just ask the user. I've been battling this concept in Armory with its deterministic wallets, for a while. I implemented "blockCreated" and "timeCreated" variables for each address, but I have been hesitant to actually use them for anything. Because, I determined that getting it wrong was not worth the performance benefit of when it is right: if you trust the timestamps are created and stored correctly, but it turns out that something was wrong (incorrect clock when it was stored), the user could be missing a big chunk of their wallet and it could be a mess trying to figure out what happened (during recovery of a deterministic wallet, that is). Plus, even if it is right, unless the user knows exactly how much they had they don't know that it's right unless you do the full scan anyway. At least for right now, doing the full scan isn't that much more cumbersome than a partial scan, so it's easier to just do it. I don't know how the HW device will be dealing with addresses (or what is possible memory-wise), but I have found it extremely useful to store the keys even though they are derived from the root. Not only does it allow me to store birthdays and comments/labels, but (most importantly) I can search for an address and know if it's in my wallet without re-doing all the computation. If it's possible to at least maintain addr160 list in non-volatile memory, it will make everything quite a bit easier. I am hesitant to "endorse" requiring key-indexes to be included in the TxDPs (as I call them in BIP 10, perhaps another phrase+acronym would be better). The reason is to do with multi-sig, which makes sense to accommodate here -- since there's like 90% overlap between what's needed for offline wallets and multi-sig. There will be situations where the TxDP will be created by another party who doesn't have your watching-only wallet, they are only supplied a public key to include in the transaction. They don't know how to specify what your address index is, and your offline device will have no way to detect what public keys belong to you. I guess you could have an optional field so that your online computer could "amend" the TxDP with your address index, but that sounds complicated. I know it sounds premature to think about multi-sig for your HW device, but I don't think it makes sense to over-complicate that use case if it can be avoided. If we must accommodate devices that can't even store their own address list, then we have to deal with it, but it's worth trying to avoid. And in the end, even with 5000 addresses, that's only about 100 kB to store a raw addr160 list... |
|
|
|
For reasons described somewhere in the last 72 pages, I static compile python into the C++ utilities, ....
This makes me wonder if I am doing something wrong. I have compiled the git source on Mac OS X, and start the program with Am I missing an executable I should run instead? If I am starting the Python executable that will load libpython - if Armory then has the same library built-in, that should be asking for trouble. Picobit, it's complicated. Python libraries are needed for "swig" in order to compile the C++ utilities. But Armory itself still needs python on your system in order to run. Don't worry, nothing is wrong  For reasons described somewhere in the last 72 pages, I static compile python into the C++ utilities, but not all systems have the static libraries. However, if you modify the Makefile to look for .so instead of .a, it will work. I should try to add an autodetect branch in the Makefile to automatically do that. Alternatively, if you are using Ubuntu, installing python-dev should resolve it.
I'm on Arch. I did a quick work around of symlinking it instead. First use of "threading" branch: Very nice work etotheipi, it's great! Having Armory starting instantly is great. I'll have a play around with it to see if I can find any bugs, and report back. Hope you can incorporate it to the master branch soon. Edit:
I got a seg fault after a few minutes of starting Armory - threading branch. (I presume just as it had finished scanning the blockchain). Executing numBlocksToRescan
Finishing numBlocksToRescan
Executing rescanBlocks
Segmentation fault And here's the log: http://pastebin.ca/2253021Whoops, it looks like I left the makefile in debug mode. I will recommit it not in debug... There is a known bug that I just isolated, that has to do with creating addresses while Armory is scanning, and then it attempts to rescan right away. I just isolated it (and prints the same message you showed), and will be examining it in the debugger later this evening. This is what I was referring to in my previous message about "gotta figure this out sometime". Life is hard... |
|
|
|
So my hot wallet causes a segfault. Armory crashes with both the full and watching-only wallet when online. I've tested in both OSX and Ubuntu 12.04.
Should I send the watching-only to you, or do you have some logs you want me to send?
Send a log first. If I can't get what I need, I'll ask for the hot wallet. Well the log is just "Segmentation fault (core dumped)"  OH! I forgot I added another feature. Under "Help-->Revert All Settings". This will delete your settings file and your mempool file. This should be like a fresh install of Armory (but it will keep your wallets). I doubt that is your problem, specifically, but it is worth trying in these strange situations. I guess I better take the watching-only wallet, if you don't mind. Send it to me via email. |
|
|
|
So my hot wallet causes a segfault. Armory crashes with both the full and watching-only wallet when online. I've tested in both OSX and Ubuntu 12.04.
Should I send the watching-only to you, or do you have some logs you want me to send?
Send a log first. If I can't get what I need, I'll ask for the hot wallet. |
|
|
|
I'm a newbie who has been playing with Armory for a couple of days and I really like it. Thanks etotheipi!
The messages, instructions, and explanations are all very clear and reassuring for someone with my level of newbieness.
The following issues did come up though (I'm not sure if they've already been mentioned in the previous 72 pages):
1) I connected my offline/cold storage computer to my printer via a USB cable but then realized that my printer does have a wireless network connection. I'm not sure if this could theoretically compromise my wallet somehow.
2) While getting comfortable deleting wallets I inadvertently restored my online watching-only wallet with the backup of my offline cold-storage wallet. Perhaps some type of warning could pop up in the future to alert me that I'm about to restore a non-watching wallet. Alternatively, I could use my brain and be more careful.
3) I noticed that when scrolling over the wallet icons with the green or red arrow in the ledger a "bitcoins received" textbox pops up for both icons. There is no "bitcoins sent" textbox.
Thanks again.
(1) I'm sure there's a vulnerability there... but luckily I don't think the printer drivers were designed to forward traffic. I bet if someone on the other side of the network was really good, they could detect when an Armory backup is printing and figure out how to extract it... But I would put that low on my list of serious concerns (at least, for regular users) (2) I can't really prevent that. There's nothing that flags the wallet as having the intention of being online or offline, and a lot of times, the user may just be tired of using offline wallets and want to bring it online-encrypted. I mean, an "offline wallet" is just a regular wallet. What makes it "offline" is the system on which it is loaded. (3) That should be an easy fix. I'll check on it. Not had a chance to try it yet, I keep getting an error during compilation I've not been able to fix. g++: error: /usr/lib/libpython2.7.a: No such file or directory For reasons described somewhere in the last 72 pages, I static compile python into the C++ utilities, but not all systems have the static libraries. However, if you modify the Makefile to look for .so instead of .a, it will work. I should try to add an autodetect branch in the Makefile to automatically do that. Alternatively, if you are using Ubuntu, installing python-dev should resolve it. I just refreshed my offline laptop (Ubuntu 12.04.1 with no blockchain and no network connection), and I was getting an error when opening Armory. I get "UnboundLocalError: local variable 'lblText' referenced before assignment" on line 2957 of ArmoryQt.py
I needed to change the first "+=" to " =" and it worked!
Oh yeah. Whoops. Will be fixed in the next attempt of a release... I'm testing wallet imports and new wallets and such. I'll let you know if I find anything else. I'm in offline mode, but it looks like it still tried to check http://bitcoinarmory.com/versions.txt. You should also sign versions.txt, and maybe check https instead. EDIT: Wallet imports went well! Detected and corrected my typos perfectly! Although a loading screen while the wallet is being created would be nice. After I enter my new passphrase it just sits for a little bit. It would also be nice if it asked me for a name. Yeah, I'm not that advanced yet. I don't have an SSL cert for the site, and I intentionally did not do any kind of automatic updates so that if it was hijacked, the user still has a chance to figure it out. I should do all this, but it's not my priority, yet. The waiting screens are tough to implement, not because I don't know how, but because I don't always know what's going to take a while. I guess it doesn't hurt to just always have it, and worst case it will pop up for a fraction of a sec...
So, right now my Achilles heel is modifying wallets and/or messing with the BDM while it is scanning. I thought I had accommodated that in the multi-threaded design (every request just gets added to a queue to be processed next time the BDM isn't busy), but it's been causing seg faults -- I think because things keep getting called out of order relative to how I intended. I've been trying to work around it... but I think I need to just buckle down and figure it out once and for all. It would be nice to re-enable key importing/sweeping and creating wallets while the user is waiting for that initial scan. There's only so long I can work around it! |
|
|
|
Nice work with the effort you've been putting in etotheipi.
I did switch back to BitCoin-Qt because of the specific bug I was having, but it lacks so many features which I never knew I needed that I've gone back to armory. Looking forward to the updates.
One thing I would like to see would be having the armory interface appear straight away, and it loading the blockchain (and what ever else it does during startup) in the background, informing the user that only basic operations are available until armory has fully loaded.
It would be useful so you can do basic things, like creating a new address, whilst you wait for it to become ready for full use.
That's exactly what I've spent the last couple months doing! Download the new version and try it! Fantastic! Compiling it now. Make sure to switch to the threading branch. As I alluded to in my previous post, some operations don't quite work when scanning, but I've disabled most of it. Trying to fix the rest, now... |
|
|
|
Nice work with the effort you've been putting in etotheipi.
I did switch back to BitCoin-Qt because of the specific bug I was having, but it lacks so many features which I never knew I needed that I've gone back to armory. Looking forward to the updates.
One thing I would like to see would be having the armory interface appear straight away, and it loading the blockchain (and what ever else it does during startup) in the background, informing the user that only basic operations are available until armory has fully loaded.
It would be useful so you can do basic things, like creating a new address, whilst you wait for it to become ready for full use.
That's exactly what I've spent the last couple months doing! Download the new version and try it! |
|
|
|
I'm trying to run Armory on Windows Vista but it takes about 30 minutes or more to load in the online mode.
I have no problems loading in the offline mode. My Bitcoin-qt client is running and all caught up.
Any suggestions are welcome!
Thanks a lot.
Unfortunately, I don't have a good solution for you. I've noticed that some systems are better than others ... I get 1-2 min on my primary computer, and 6-7 min on my Windows 7 VM. Haven't seen 30 min, yet, that does sound extreme. What kind of HDD is the blockchain on? What are the system specs? I suppose it could take a really long time for Armory to go digging through 4GB of blockchain on an Athlon64 or something...
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.84.2-almost-beta_windows.msihttp://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.84.2-almost-beta_i386.debhttp://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.84.2-almost-beta_amd64.debIf you have a problem with the Windows version running 64-bit Windows, try the naive 64-bit version, but only do so if you have issues. Of course, just as I released this, I discovered there is an issue creating new wallets while the blockchain is scanning... about the worst thing that could happen for new users! I'm working on that now, but for you veterans, it shouldn't be an issue :-/ One day... I'll get all these kinks worked out... |
|
|
|
Good news! I stumbled on a pretty significant bug, which has only popped up because of the increased network traffic in recent months (probably due to SatoshiDice). It turns out that tx that were showing up in bundles were eating each other, and Armory wasn't actually processing half of the zero-confirmation transactions it received (and this only happens when there's high network load). If you've been wondering why Armory doesn't always show your zero-conf transactions, that's why! I was tipped off by sending a tx to my Armory wallet while Armory was connected, and it didn't get the zero-conf tx. That seemed bizarre, since I know that Bitcoin-Qt always broadcasts to all its peers. I even checked the Armory log and saw the "inv" message for my tx... but Armory somehow never actually got the tx itself (only a notification that it exists). Anyways, it's fixed now. Just a little more internal testing and I'll make a real testing release BTW, I sent out an email to about 15 people about 1 week ago, to request testing of 0.84. If you did not receive this email, and you are willing to be put on the list, please PM or email me. |
|
|
|
|
In defense of EFF: I too was disappointed by them not accepting BTC early on. But consider what kind of resources they are going to spend defending Bitcoin against the torrent of legal gray areas it falls. They could've put in millions of dollars and defended Bitcoin, just to have it fizzle a month later because of network security issues, or some other doomsday scenario. In that sense, they're probably more concerned about getting the most value out of their limited resources -- why spend millions of dollars to protect the rights of 12 nerds from some transient internet phenomenon when they can be protecting thousands of other people from other issues with the same resources. Especially if there's no direct indication yet that freedom is threatened.
Now that Bitcoin is gaining momentum, it's no longer a handful of nerds -- it's a lot of people and quite a few businesses, too. And if those people and businesses look like they will be threatened, I imagine the EFF will start to take it more seriously. Perhaps we're starting to reach that point, now. But I don't blame them for their stance last year.
|
|
|
|
Indeed. I actually almost sent the tx again, but fortunately I was paranoid enough to actually test - and if I had done it, it would probably have been saved by being a double-spend.
Perhaps when sending a tx failed, the error message should be that the tx "appears to have failed, but please check by waiting to the next block appear (or check in blockchain.info [link to tx]" or something like this.
Gah, you guys win. I'll bump up the priority... And unfortunately, I just hit a seg fault!  So many different conditions to test! (this was from starting Armory in offline mode, extending the keypool while offline, then switching to online mode). Okay, more internal testing before a testing release... |
|
|
|
It sounds like even if I don't get it right, this is an okay bug to have: tell the user it didn't work, but it actually did. Better than telling them it did work when it didn't, and the ensuing confusion...
I think this could cause some of its own problems, though. If you have a user that simply trusts what the software tells them (which would be 90% of the normal population if/when bitcoin/armory gets extremely popular, luckily it's much lower while bitcoin is a niche market) they may send coins again if it says that it failed, without even looking at the history or manually checking if it really did go through. It may be a lower priority bug for the time being, but in the long run, it's something you would want to try to find if at all possible, in my opinion. But that's just my two cents.  That's an excellent point. And I didn't mean to suggest the bug was "okay", but simply that it was better than the inverse bug. I'd still like to find a good way to resolve it... but Armory's mechanism for sending transactions does not make this totally deterministic |
|
|
|
but i was fully synced. otherwise the tx wouldn't have gone thru.
I'll put this behavior in the category of "undefined." There's actually a good chance it would go through, unless the transaction being spent was very recent. I could elaborate, but I don't think it's too important. I'll apply my same not-sync-detect logic to the sending of transactions to warn the user that they should wait until full synchronization before spending. It sounds like even if I don't get it right, this is an okay bug to have: tell the user it didn't work, but it actually did. Better than telling them it did work when it didn't, and the ensuing confusion...
Teaser: the beta testing version will be out very soon. I think I just finished the final feature, which is sometimes necessary for restoring very active wallets, both offline and online. This is mainly for people who are restoring offline wallets from paper backup, where the offline wallet was used more times than the keypool size (100-200). Since the wallet is offline it, has no way to know how many addresses were used, and will not recognize address 300 in its own wallet. The mechanism for resolving this has been haunting me for a while -- I want to make it possible for users to extend the keypool, but 98% of the time, they don't need to be bothered with this concept because Armory succeeds silently without input. So, I have added it to the "Expert" interface, wallet properties now tells you how many addresses have been generated. You can click on it, and extend the address pool manually. If you think you used 1000 addresses in this wallet, put in 1,500 and it will extend the wallet for you. If you supply a number greater than 1000, it will warn you that computation may take a while (this is another reason to switch to the new BIP 32 wallets -- address "chaining" is much quicker).  As far as I can tell, all my multi-threaded features work -- offline-to-online, rescanning, importing, sweeping, wallet restore, wallet import, all in different modes, etc. I have to do a final testing pass on everything and then I will compile testing versions. I can't wait to finally get this thing out there! |
|
|
|
Or when you tried to actually broadcast it (you were able to broadcast it, it showed up on the ledger, but said it failed?)
this Interesting... haven't seen that one before. Perhaps I just need to bump up the time that Armory that waits before declaring that it failed... I have seen that once, when I broadcasted the tx before the Satoshi client had caught up. I should of course have reported it, but somehow felt it was only to be expected. Oh, definitely evidence of my own testing bias... I wouldn't ever send a tx before satoshi is caught up, because I know in the back of my head what the result would be. This is why I need other people to test and find stuff like this The newest version (which I'm still battling), detects when Bitcoin-Qt is still synchronizing, and pops up a warning. I should add to the warning that tx will not be broadcast right away, and perhaps add that same detection to the broadcast button to disable the message (or give a different one), when they do this. |
|
|
|
|
Show Posts
