|
We have shied away from tackling this problem, because it's really out of scope for us (the core devs have too). There's so many different filesystem types that have their own ways of handling data on disk. We could do a PhD on how secure-delete files on each one, and it still would probably not be perfect, and only handle a subset of the filesystems out there.
My recommendation is that if you really want to wipe it, you shred the entire drive from a live CD and then reinstall your OS. Alternatively, one thing that theoretically should work, would be to make sure the wallet is deleted, and then do something like "dd if=/dev/urandom of=tempfile.bin" (if linux), which will create a single file full of random bits that will eventually consume all unused space on your disk. This will force the OS to overwrite all sectors marked as deleted. Then, if the system is still functional, you can remove the file. Repeat a few times to enforce "shredding". Though, depending on the OS, strange things can happen when you literally fill your last byte of free space.
|
|
|
|
Oh ok perfect. good to know, was getting crazy the last 3 days  Do You go to notify here on this thread when got news about the fix? Do you think it will get fixed before release of 0.91? Or directly within 0.91? Thanks! Probably 0.91. |
|
|
|
Yeah thats exactly what I am doing.
I am creating a queue for pending Tx's
I Get tge first Item (when no other Tx is in Work)
create a unsigned -> pass it to another worker make it Signed -> and get back to the other woker to make the broadcast.
after the broadcast I get the next item in queue and so on.
It works if the queue waits to start with next item (to create unsigned) until it gets at least 1 confirmation then there is no problem
but if I get on to the next item to mak an unsigned (1 minute after previous broadcast) then this happens:
The exact error occurs here:
class PyTxIn(object):
def __init__(self):
self.outpoint = UNINITIALIZED
self.binScript = UNINITIALIZED
self.intSeq = 2**32-1
self.isCoinbase = UNKNOWN
def unserialize(self, toUnpack):
if isinstance(toUnpack, BinaryUnpacker):
txInData = toUnpack
else:
txInData = BinaryUnpacker( toUnpack )
self.outpoint = PyOutPoint().unserialize( txInData.get(BINARY_CHUNK, 36) )
scriptSize = txInData.get(VAR_INT)
if txInData.getRemainingSize() < scriptSize+4: raise UnserializeError
#values: ? txInData.getRemainingSize() = 45
# ? scriptSize + 4 = 95
it raises an UnserializeError.
It does not happen if I select another Address of the wallet.
It should be something with the txoutlist (staying out of sync)??
Coincidentally, I just ran into a problem with this in another context. It does seem that the new code sometimes fails to get the tx properly from TheBDM when the tx is not yet in the blockchain. It should work, and has worked before (before 0.90), but it may have broken during the upgrade and I didn't notice it. I will have to verify that the zero-confirmation transactions can be properly retrieved from TheBDM before they are mined. |
|
|
|
Hi!
First of all: Amazing work done by Armory Dev's!
I am working with the Daemon (extending it at moment to support Tx Offline Signing, and Broadcasting)
And i got a Little problem at the moment, maybe some of the Devs can point me to the right direction to get it working.
The Broadcast is nearly ready to use in ArmoryD, the problem I got is:
New Transaction Requests over the same SourceAddress of the previous Tx will fail until the BDM gets notified about Confirmations
from BitcoinD.
Its like he want to spent the same TxInputs and then the Tx will fail in Broadcast. I saw ArmoryQT maintaining a combinedLedger.
(appending ZeroConf Ledger Entries to the combinedLedger)
But I have not see any relation to the BDM with the combinedLedger (maybe i am missing something, Its the first Project i am touching python.)
Or How ArmoryQT get it working to not fail on next Tx’s when the previous Tx’s isn’t already +1 Confirmation?
It seems to me that ArmoryQt “makes in some way a manual sync” to be able to realize a next TX.
Any point to direct me where I can follow the needs?
Thanks!
poOkie, I'm not sure what exactly the problem. It sounds like you might be running into the issue of making multiple offline tx and trying to sign them without first broadcasting one of them. Armory currently can't handle this situation, and you will have to create-sign-broadcast a tx before you can create the next tx (you can create the next tx, though it will probably be invalid). Btw, there's a script the in extras directory called "cli_sign_txdp.py" which has example code for you. You may have found that, or may have already reimplemented it. Just wanted you to see it. |
|
|
|
So, I know the Armory developers are working on Trezor integration, etc. But I was wondering if stealth addresses and CoinJoin via the Armory client are in any sort of planning stage? Rather than doing these things manually, which is a hassle, it would be nice if it was EZ button type of implementation.
Appreciate all the hard work on Armory!
I can't speak for the Armory devs, but one nice thing about implementing stealth addresses in Armory is that it already has the machinery to scan the blockchain; you could easily use stealth at the highest privacy level where any stealth tx that's sent could be going to you. (zero-filtering) It's something to consider about Armory in general: because it can work so easily with a local full-node you always have excellent privacy with regard to the contents of your wallet. All the queries are local, so info on what coins are in your wallet never leaves your machine. That's much better than SPV clients like Android Wallet where every peer you connect to learns statistical info narrowing down your addresses to within about one in 10,000 or so, or Electrum which currently just tells peers what addresses are in your wallet. I'm very interested in this feature. It's just that it still sounds very theoretical at the moment. I'm also concerned about how much computation it will be to track the addresses ... ECDH calculations aren't cheap. I guess I'm still in a waiting mode, implementing other things while I wait for this to be ironed out (I don't have much to contribute to the discussion, though I have spent a lot of time thinking about how to get the same benefits without all the ECDH calcs). Peter: Btw, I'm working on P2SH support right now. You will be able to test it on 0.91-dev in the next couple days. In fact, it seems to be working right now, on the p2shout branch -- you can try it right now, though I wouldn't do anything other than testnet. As part of the update, I modified the PyTxDistProposal::createFromTxOutSelection() method to take any arbitrary list of script-value pairs, instead of just hash160 values. Right now, it will error out if you supply it something other than an P2PubKeyHash or P2SH, but that could be modified locally to create a tx with any arbitrary output scripts. As long as all the inputs are standard UTXOs, you can create such a tx and sign it no problem (have fun getting it mined, though). |
|
|
|
Just a general update: 0.91-dev is mostly broken. But that's because we've got 3 people pushing changes that require a little bit of interoperation to work properly. We'll have it sorted out soon. After all, this is the development branch for a reason. But if you want a 0.91-dev that works, you'll have to go about a week back in the repo... On the other hand, lots of great stuff has already been merged/updated in 0.91-dev. Most of this isn't actually functional yet on 0.91-dev, but will be shortly. - (Goatpig) MSVS project will now compile with WinXP support if MSVS 2010 Express is installed
- (Goatpig) Should have fully operational unicode support throughout the app. Wallets themselves will not support it until the 0.92-beta, but then we'll finally be able to start full internationalization
- (Goatpig) Got a solid instructions ironed out for cross-compiling an offline Raspberry Pi build. Yes, I can now compile the RPi binaries on my Ubuntu system and create the offline bundles from there!
- (Goatpig) Progress bars for a variety of long-running operations
- (Goatpig) Integrated wallet-recovery tool from the menu.
- (CircusPeanut) Full code refactoring. No more 20k line armoryengine.py
- (CircusPeanut) A plethora of armoryd.py upgrades. Includes the ability to setup email notifications if you have a source email address
- (CircusPeanut) Upgraded send-bitcoins dialog to include wallet selection
- (CircusPeanut) Fixed occasional send-bitcoins failure on wallets with lots of tiny inputs that was driving some users insane
- (etotheipi) Making Armory P2SH-aware. Will enable sending to P2SH addresses
- (etotheipi) Improved efficiency in wallet scanning and zero-conf tx handling. Some improvement already, will be doing more.
Very shortly, I will finally get back to the new wallet format, which will do all sorts of cool new things. Including multi-sig, which has become my number one priority after 0.91 (especially since we now have employees holding down the other forts ). |
|
|
|
The change was simple enough I just updated it in my working branch. It will appear in the next push of 0.91. |
|
|
|
I was just talking to goatpig about this, and figured out a secure way to do the payment without the race. I guess this is a more-general pattern for doing any type of information exchange where you want the payer to be able to recover the funds if the data is not revealed. What I originally proposed was a this single transaction type, but it does create a race: OP_DUP
<PubKeyUser>
OP_CHECKSIG
OP_NOTIF
<PubKeyBruteForcer>
OP_CHECKSIGVERIFY
OP_HASH256
<SHA2562(encryptionkey)>
OP_EQUAL
OP_ENDIF
, create a tx sending the finder's fee to a 2-of-2 between user and brute-forcer. But before that is broadcast, create two spending tx, and get both parties to the sign the tx before the user broadcasts the escrow tx. Escrow: Input: User: 10 BTC Output: 2-of-2: (user, bruteforcer) (10 BTC) Tx1 (refund): Input: 2-of-2: 10 BTC Output: User (10 BTC) LOCKTIME: 30 daysTx2 (finder's fee): Input: 2-of-2: 10 BTC Output: <PubKeyBruteForcer>
OP_CHECKSIGVERIFY
OP_HASH256
<SHA2562(encryptionkey)>
OP_EQUAL
(no locktime) That gives the brute-forcer 30 days to reveal the key and claim the funds. But if he disappears, the user can broadcast the locked tx after 30 days to get the money back. Note: this depends on malleability being fixed, in order to be truly trustless. |
|
|
|
Does your wallet have lots of addresses? Are you on a slow system? The error basically indicates that the interthread communication timed out... which can happen when you have 10k+ addresses. Also, when your mempool.bin file gets too big (there's a fix for the mempool thing in the next version). In the meantime, you can use "Help"->"Clear all unconfirmed" to clear the mempool.bin file and then restart. That may make a difference. Until this fix is in, you may have to do that periodically if your system is slow. Can you use "File"->"Export Log File" and email to support@bitcoinarmory.com so we can double-check? |
|
|
|
|
Armory uses almost entirely P2P. The RPC is only used if you have Armory manage Bitcoin-Qt/bitcoind for you, in which case it basically only uses it to determine & report synchronization state. Beyond that, everything goes through P2P. This makes it agnostic to the backend Bitcoin engine... if someone wants to use a different engine (which doesn't really exist yet), then they can swap it no problem.
That's an overstatement at the moment, since Armory does still rely on the blk*.dat files, but even that will be removed (hopefully soon).
I'm not sure if there's a way to reserve a connection for a given IP address. I bet there is. You could probably find out pretty quickly on the #bitcoin-dev IRC channel. Or just post in the parent forum. Make sure you report back here with the answer, since I'm kind of curious myself.
|
|
|
|
Hi there, I just signed and broadcasted an offline transaction from my Armory wallet to send to a blockchain.info wallet. The transaction was recognised by Armory and the amount was deducted from my wallet. However, when I check blockchain.info the transaction is not there, as if it has not happened. Is this just a delay? Only getting slightly worried as last time I did this the transaction appeared on the blockchain almost instantly. Thanks and sorry if there is an obvious answer to this.
If you're using the latest version of Armory (0.90) you can go to "Help"-->"Clear All Unconfirmed". Then restart Armory (and Bitcoin-Qt/bitcoind, if running it manually). When it's restarted and connected, broadcast your transaction again. If you're using the older version of Armory, then do what prezbo said. If that doesn't work, upgrade Armory |
|
|
|
|
Armory already achieves the same security properties of BIP 38, just with a different algorithm. If BIP 38 becomes a real standard, I'll be happy to implement, though I don't see any deficiencies in my current algorithm except for interoperability with other apps. If everyone else is committed to BIP 38, I can be too.
|
|
|
|
Do you have a lot of addresses in Armory? This frequently occurs when Armory hits the 10-20 sec timeout during an operation... it happens most frequently when there is network burp, or you have 10k+ addresses and it's trying to update all of them after a new block comes in. If it's an address problem, we'll have a fix for it soon ... the 0.91-dev branch already has updates that make Armory operate much better with 50k+ addresses, though there's still more work to do. |
|
|
|
|
Currently Armory does duplicate all the blockchain data. But it's because we just did a huge overhaul of the blockchain management system, and it was easiest to do it this way. It will be fairly "easy" to reduce the amount of data managed by Armory and rely on Bitcoin-Qt for bulk blockchain data. We just haven't gotten to that point yet, because we're still ironing out the bugs in the full-duplication version.
Stay tuned.
|
|
|
|
what do you mean by "both are needed"? what's the use of printing anything out if you're going to handwrite out the chain code and seed anyways?
The SecurePrint code is substantially smaller than the rest of the data that was printed. I struggled with this a bit, because I needed the code to be long enough to be secure, but not so long that the user might as well just copy the rootkey & chaincode by hand anyway. So I struggled with this balance and settled for 8 bytes with super key-stretching. So that's 64 bits, plus approximately 20 bits of stretching (since the stretching will slow down guessing by about a factor of 1,000,000. Additionally, it requires 16 MB of RAM so it should be difficult for GPUs to parallelize it. It's not as strong as I'd prefer, but it's infeasible for any system to brute force right now. If you are ultra ultra-paranoid, you can just just copy everything by hand. Just make sure to use the backup tester before you store it. |
|
|
|
Updates to 0.91-dev branch: (just pushed) - I have drastically reduced the tracking and handling of zero-conf transactions. This solves 80% of the speed issues using Armory with wallets with 10k+ addresses. I now run with 30k addresses and it runs fine, although it freezes for about 1-3 sec after every new block. Better than 10-15 sec, though (which was causing inter-thread timeouts). I will be working on the per-block scanning ops to reduce it even further (Armory code base should be able to handle 1mil+ addresses, I just haven't optimized the operations to do it)
- Updated "Send Bitcoins" dialog, with wallet selection directly in the dialog. Coin control still works, though the interface updates for that broke. Fixing that soon.
- Added paranoid-extension of address chains and logging of multipliers. All address chain extensions are now performed twice and answers are compared to make sure it's consistent. Additionally, the final multiplier/exponent applied is logged.
- There are still situations where an unclean shutdown will induce a rescan. I have further reduced those situations, though it's not perfect. I will see if the operations are efficient enough to make more reliable.
- armoryd.py updates -- a bunch of functions that broke in the update to 0.90 have been fixed. Most importantly, "listtransactions" and "getledger" now work. CircusPeanut is working on building a better test environment for it to improve the reliability.
- Updated leveldb block size to 32kb. This seems to improve scan speed on Linux/Mac, without breaking build speed on Windows. Be sure to --rebuild if you want the benefits of the new block size.
|
|
|
|
In any case, the 0.91 database changes look good.
Although the initial sync subjectively seemed a lot slower than the 0.90 version, it meant I could close the program in the middle and it would pick up again in the same spot without losing progress.
So far Armory recovers perfectly from an unclean shutdown (via kill -9).
The "synchronizing with network" (bitcoin-qt/bitcoind), and "Building databases" really won't be any faster. It's the "Scanning Blockchain" step that should be faster. It's almost double speed on Ubuntu/Linux. However, we've been having some Windows SNAFUs, so I'm not sure yet what's going on with Windows... |
|
|
|
On a related note, changing the name of the development branch makes keeping our ebuilds up to date particularly difficult. This kind of branching and tagging model would help us, and is probably a good idea in general: http://nvie.com/posts/a-successful-git-branching-model/Now that we have a team, we just agreed to start naming the dev branches after the version they will become. Hence "0.91-dev" will eventually be 0.91-beta, and then we'll start 0.92-dev, etc. I know we had been inconsistent before and that's why we just decided on this. However, I really like that link you sent. As he says, there's nothing groundbreaking, it's just a nice, consistent way to get everyone to cooperate and work the same git styles. We'll definitely discuss adopting that or something very close to it. The "--no-ff" flag is a good tip too. I was wondering how to t avoid that information loss. |
|
|
|
|
I just pushed some changes to the 0.91-dev branch. Small changes in terms of code, big changes in terms of effect:
--I now save wallet histories after every block, not just on clean shutdown. It should not require rescanning except on loading new wallets
--I tweaked the DB optimizations, and it looks like I cut the scan times down to about 2/3 or 1/2 of what they were before.
Especially justusranvier: Checkout the "0.91-dev" branch and do a make clean and make. You must "--rebuild" the databases for the new scan speeds to be realized... it has to do with the way the DB is constructed, not the way it is read. And check that the crashes
@armoryd users
I just updated armoryd.py along with the changes above. The history saving became a complete PITA since there is no way to do a clean shutdown with armoryd, and thus I was rescanning every time. Then I was able to upgrade all the logic in listtransactions and getledger which broke between 0.88.1 and 0.90. It seems to work now.
My next task is to improve performance with a large number of addresses. There's some very clear areas of improvement I missed and haven't gotten around to fixing.
|
|
|
|
Windows 7 64-bit version.
I am trying to reinstall the Armory wallet and get this crash alert:
Problem signature:
Problem Event Name: APPCRASH
Application Name: ArmoryQt.exe
Application Version: 0.0.0.0
Application Timestamp: 49180193
Fault Module Name: _CppBlockUtils.pyd
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 5294de6a
Exception Code: c0000005
Exception Offset: 001080a3
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
I tried to reinstall with the 0.89 and 0.90 versions but no love.
Can you post any relevant errors in the log file? That "alert" is 0% useful for us... it looks the same no matter what went wrong. Can you also try going to your C:\Program Files (x86)\ folder and deleting the "Armory Bitcoin Client" folder? Then reinstall. |
|
|
|
|
Show Posts
