Sometimes Coinbase forgets (apparently) to broadcast a transaction, even though it shows up in their own blockchain browser. It will show you the transaction in binary or json formats. Anyone know how to convert one of those formats into something that can be pasted into the Armory offline transactions window and broadcast? Here's a random example: https://coinbase.com/network/transactions/b7697479993e54eb6594d607904e3a9c65692124f9b9bcba5a16bb5affe173fcI opened the binary file in Okteta (hex editor) and tried copying it to the clipboard as a variety of formats, but none of them worked. I never got around to implementing that, because I wanted the user to be able to examine the transaction before they click broadcast, but a raw transaction doesn't have all the info it needs (refer to SIGHASH_WITHINPUTVALUE discussion). I probably should've put something in there anyway with a warning, but I never got around to it. I suggest using https://blockchain.info/pushtx |
|
|
|
The big problem is it's specific to OP_CHECKSIG, and in the future it's quite possible that OP_CHECKSIG will be changed/made obsolete/who knows? Doing this via a SIGHASH bit is inelegant because it's so specific to a single use-case.
With a v2 transaction format, with a merkle tree extending into the tx and including a hash of the CTxOut structure being spent your hardware wallets would just take that data and operate only on that. For instance this is helpful if you are signing just a small part of a much bigger combined transaction with funds from multiple parties - there might be 1000 people chipping in to pay a large bounty for instance, and with a v2 tx format and set-based SIGHASH's your hardware wallet only needs to be given the small part of the txouts you are signing for.
Interestingly in that use-case your signature can still cover all the other txouts safely. Your wallet only needs to know that you've contributed xBTC of funds, and the txouts it knows about, via the merkle paths its been provided, are for (x-fee)BTC of funds. Perfectly safe no-matter what malware is on your computer, yet the outside world only knows that you added funds to some huge txout set. This is perfect for CoinJoin tx's.
I would not dismiss offline transactions a "meh, just a single use case." That is the future of any serious Bitcoin users and HW wallets. Accommodating them is in everyone's best interest. Also, you are talking about a major protocol upgrade that is far from uncontroversial and could take months/years of debate, testing, etc. I'm talking about a very simple, modification of a couple lines of code that completely solves a problem that a lot of Bitcoin innovators having today. |
|
|
|
There are much better ways to do this than using up what limited SIGHASH bits we have, and we already have other uses for SIGHASH bits that should be implemented.
In particular it has been proposed to extend the merkle tree of transactions down into the transactions themselves, which would allow you to easily provide compact proofs of the value of the transaction outputs that a transaction is spending.
tl;dr: Strong NACK on SIGHASH_WITHINPUTVALUE
You seem to suggest there is consensus about your opinion it should not be done, and that there are seriously-considered proposals to change the meaning of the merkle root. But, if you read the rest of this thread, there is a quite a bit of high-level support for this modification, as an "add-on" to any future hard forks. Of course, we're all happy to discuss alternatives, and what other uses there are for the other SIGHASH types, but you haven't mentioned what they are or where I can go read about it. The all I see is gmaxwell: "I think the sighash with input value seems pretty inelegant." and Mike saying he likes the idea of doing something, lets talk more at the conference. The seriously-considered proposals are the UTXO commitment proposals. As for other uses for SIGHASH bits, see IRC discussions about the need to be able to specify sets of txins and txouts being committed to. I also posted a quick idea myself for txout summation. FWIW one of my main objections to this is that we really need general ways to prove fees paid by transactions for inflation fraud proofing, and short proofs of txout existence are very helpful to SPV nodes who are able to use them to check that transactions are valid - you're focusing on something very specific. On the other hand, if we were to implement such a drastic/breaking change in the protocol as you suggest, to actually change what the merkle root means in the header, we'd have no problem simply "fixing" the existing hash types to include the output values, as that would equally break all existing parsing/verification code as changing the meaning of the merkle root. If your suggestion was implemented, we could remove the "wasted" SIGHASH_WITHINPUTVALUE bit and recover it for these other use cases you mention.
Additional merkle roots can be committed to in the coinbase txout; adding them is a soft-fork just like adding additional SIGHASH bits is. The best way to do this is to put the digest of the secondary merkle root in the last txout of the coinbase (with a P2Pool style 0-value OP_RETURN) so the proof can use a SHA256 midstate of the coinbase tx to keep the size independent of the size of the coinbase tx. It's at this point that a "v2" transaction format can be defined to fix all this stuff for once. I'd be happy to pitch in on a BIP defining that transaction format, and we can do it in a way that leaves room to add the UTXO commitment digest when that is fleshed out as well. I'm all for UTXO commitment proposals. After all, I have a pretty elaborate one I'd like to see pushed forward. But that still serves a different purpose than this: sending the offline computer UTXO proofs/branches is going to be a lot more than 8 bytes per input. Part of the goal is to minimize the data sent across the online-offline channel, and the complexity of what needs to be done by the offline signing device. I'm not sure where the inelegance comes from -- we add 8 bytes to the data to be hashed and we close up a major oversight/inefficiency in the protocol. If this was some kind of epic, controversial change, I'd agree that it may not be worth it. I've already said it's not even worth its own hard-fork. But given how simple-yet-useful the change is, I see little reason not to do it if the timing is right. Unless it will be will feasibly be solved by some other major upgrade in the near future. |
|
|
|
There are much better ways to do this than using up what limited SIGHASH bits we have, and we already have other uses for SIGHASH bits that should be implemented.
In particular it has been proposed to extend the merkle tree of transactions down into the transactions themselves, which would allow you to easily provide compact proofs of the value of the transaction outputs that a transaction is spending.
tl;dr: Strong NACK on SIGHASH_WITHINPUTVALUE
You seem to suggest there is consensus about your opinion it should not be done, and that there are seriously-considered proposals to change the meaning of the merkle root. But, if you read the rest of this thread, there is a quite a bit of high-level support for this modification, as an "add-on" to any future hard forks. Of course, we're all happy to discuss alternatives, and what other uses there are for the other SIGHASH types, but you haven't mentioned what they are or where I can go read about it. On the other hand, if we were to implement such a drastic/breaking change in the protocol as you suggest, to actually change what the merkle root means in the header, we'd have no problem simply "fixing" the existing hash types to include the output values, as that would equally break all existing parsing/verification code as changing the meaning of the merkle root. If your suggestion was implemented, we could remove the "wasted" SIGHASH_WITHINPUTVALUE bit and recover it for these other use cases you mention. On a related note: TierNolan, can you link to the thread where this was reported? I'd like to see how this massive fee occurred. Was it malicious? Or just likely a bug in the way the online computer was reporting input values to the offline computer? If I had to guess, it was someone who tried to manually execute the offline signing procedure, but did not include all the supporting transactions, and ended up mis-reporting input values to the offline computer (which would've been caught if they supplied and checked the supporting tx, or SIGHASH_WITHINPUTVALUE was implemented). |
|
|
|
BTW, i had log full of this messages 2013-08-28 18:20 (ERROR) -- ArmoryQt.py:4294 - Error in checkSatoshiVersion
Traceback (most recent call last):
File "/opt/BitcoinArmory/ArmoryQt.py", line 4248, in checkSatoshiVersion
not 'SATOSHI' in self.latestVer or \
AttributeError: 'ArmoryMainWindow' object has no attribute 'latestVer'
Tens of these messages by second... That turned out to be a bug that made it's way into the released version, but doesn't affect performance or functionality at all. It should be fixed in the testing version, and will not be there for the next version ... but the worst thing it does is make the logs harder to access/read. It's unrelated to the crashing.
Just to keep things consistent, there was a reddit post asking if Armory was dead. Here's my response: Yeah, things have been slow. Lots of distractions, but still lots of development. We're actually about to replace the entire webpage with something much slicker and prettier. That should give a good indication that things are still moving forward!  As quantabytes pointed out, all development has been happening on a separate branch, which doesn't update the main github page. The changes are basically a complete overhaul of the underlying blockchain utilities, but I'm doing so to benefit about 30 different functionalities I want to implement in the future. Things like compressed keys, multi-sig, P2SH, arbitrary scripts, arbitrary balance lookup, and a [better] daemon mode. Those will all be much easier to implement when I finally finish this upgrade! You can follow the Armory thread on bitcointalk as Kupsi linked. I tend to post updates there on my progress. I actually posted a breakthrough last week about passing some really rigorous unit-tests, but then later found out that SatoshiDice crushed the new design, due to some misdirected optimizations in the first round. This second round should be complete in the next couple days, and I can start integrating the new stuff into the GUI. |
|
|
|
The software for Armory handling bitcoin-qt signatures is ready
No ETA yet though
Yeah, I was going to integrate the compatible message signing algorithm in the next release. It's just that the next release is taking far longer than I expected. Soon though! |
|
|
|
|
Grandma can't use Bitcoin yet. Still beta.
|
|
|
|
We've just started integrating armory / armoryd into our new site (for offline cold storage stuff) - is there some reference code for broadcasting a newly signed transaction? (or converting it into standard bitcoind format and then we can broadcast from there)
also - how come the github code hasnt been updated for a while - there are loads of small fixes that could have been merged - do you have a private dev branch that you work from instead?
There is a "Copy Raw Tx (Hex)" button on the "Sign and/or Broadcast Offline Transaction" window. You could look for that button in the python code and copy what it's doing. I'd look it up for you, but I'm on my phone. I believe that you have a "TxDP" object which represents the signed transaction, and you do something like "txdp.prepareFinalTx()". That should give you a raw binary transaction in the form that all other nodes on the network recognize. On that same window is the "Broadcast" button which also should lead you to how I implement broadcasting to the connected bitcoind/-qt instance. If you already have a running instance of Armory, it should be easy (because it's already connected), but it may take some work if you're writing an isolated script. I have been working in the "ramreduceleveldb" branch for the past couple months. I've been heavily distracted, so progress hasn't been as voluminous as I'd hoped, but progress is being made (see a few posts up about the most recent unit tests I passed). I ran into issues with the new DB stuff being bottlenecked by SatoshiDice addresses and 1VayNert, but I should have the updates for that soon and then will start integrating the new DB stuff into the python layer. For reference, this first version will use a lot of HDD space -- probably 1.7X the blk*.dat files -- but will provide instantaneous arbitrary address lookup (balances and UTXO sets). This was the easiest to implement, and when this is done I'll be in a good position to implement much lighter variants. |
|
|
|
But true, there's definitely no beating a hand-tuned optimized C/assembly implementation of anything!
I should add, this isn't just a hand-tuned, optimized implementation of general ECDSA signature verification: it's hand-tuned and optimized for the specific elliptic curve that Bitcoin uses (secp256k1). The curve is actually one of the simpler ones blessed by NIST, and sipa is an optimization ninja |
|
|
|
- (2) Who's going to destroy their private key that has money associated with it? Users would probably save the private key in some remarkably inconvenient form that would be difficult to recover, but possible if absolutely necessary (encrypt it with a random 50-bit key that will have to be brute-forced, and then bury it in your backyard yard?)
What is the use case? Does it require that you provably destroy the info? That's part of what this post is asking... is there a use case for it? I get a lot of people asking this question, but with only a half-baked idea of how they would use it. I posted because I realized there's a somewhat-satisfactory answer to that question now, but I'm not sure how useful it really is. There may be use cases for it that don't require proving you destroyed the key. i.e. if you actually destroyed the private key, then it cannot be compromised, and the money is truly immobile until the locktime, and only to the specified address/script. Brian mentioned "inheritance", though locking money for 30 years is potentially similar to destroying it -- part of why you have inheritance is because you don't know when you're going to die, and you want to send whatever is leftover to your next of kin. But if you time lock all your savings for 30 years, you can't use it yourself in case you live longer than you expected or you need it. More likely, someone might use it to force savings behavior. You prevent yourself from having access to it until a given time. Or you can give your kid money that they can only unlock when they are 18 years, etc. Unfortunately, it does not have the benefit you get of an offline wallet, in that you can continue to send money to it afterwards (I know someone would lose money thinking they could...). Meh. It may not actually be that useful. But it also wouldn't surprise me if it might combined with other network features (replacement, non-standard scripts), to do something very creative. |
|
|
|
So I wasn't quite sure what to search for on this topic, so this is probably a repeat. Please point me to it if it exists already. Lots of people have asked if there is a way to control the direction of money behind an address/script. Through conventional means, the answer has always been: "No, the network only defines conditions to unlock the money, but can't control what is done with it." If you have the private key(s) for the money to be unlocked, you can do whatever you want with that money. However, I realized that this is very much possible, through unconventional means. For instance, it's possible to "lock" money until a given time by doing the following. - Produce two private keys, with addresses A and B.
- Send money to address A
- Create timelocked transaction sending all outputs of A to B
- Sign it with A
- Store signed tx in a safe place
- Destroy private key A
Although I hate the idea of destroying private keys that still have money, this does achieve what was requested (as long as you can be confident that the tx is valid and can be mined). The money is locked with no way to be moved until the locktime expires, and it will only move to address B. There is also no time limit by which it needs to be broadcast, you could keep it in A until you need it, long past the lock time. The downsides include: - (1) If a crazy bug leads to a bad signature or tx, then the money is locked forever
- (2) Who's going to destroy their private key that has money associated with it? Users would probably save the private key in some remarkably inconvenient form that would be difficult to recover, but possible if absolutely necessary (encrypt it with a random 50-bit key that will have to be brute-forced, and then bury it in your backyard yard?)
- (3) If key B is compromised, trying to remove the money becomes a race: as soon as the tx(A->B) hits the network, both you and the attacker are racing to move the new output. You have an advantage though (if you know B was compromised), as you create the signature with A, so you know the OutPoint that needs to be spent by B, and can prepare a subsequent spend and broadcast it 1 microsecond after you broadcast the first tx. But that's by no means any guarantee that yours will be mined, especially if the attacker knows miners who will give him priority (and especially if replace-by-fee is standard)
Above I have only mentioned time-locking money. I bet if you combine creative scripts and multiple transactions, there's some cool stuff you could do. But you have to be careful with creating chained transactions, because the malleability of transactions means that you create A-->B and pre-prepare B-->C, but then some jerk on the network mines A-->B after adding an extra padding byte to your signature and the tx hash changes, then your B-->C tx is invalid (because it references A-->B by hash, which is no longer valid). I know we enforced canonical signatures, but I assume that's not a hard network rule (yet?). So what else can be done with this? Is it actually useful? |
|
|
|
Fantastic! Very happy to see results like that - especially measured in msecs I should mention that the timings are artificially inflated due to the fact that it destroys and rebuilds a testing database on every test. This means there's quite a bit of hard disk I/O involved in just the SetUp and TearDown procedures, and executing a small batch of writes comes with huge overhead. It will not take 0.6 seconds to add 5 blocks to the DB when doing a full database build... With re-org handling implemented, I will start benchmarking DB building on much larger data sets (more than 5 blocks). And then I'll see what has to change to hook this up to the GUI. The upside is that nearly all the interfaces are the same, so the GUI probably won't see much change (other than not having to wait for startup and importing wallets). The downside is that some stuff did change: I added C++ support for compressed keys, multi-sig and P2SH. This means I need a translation layer for the old wallets to work right until the new wallet format is complete. But yeah... progress... |
|
|
|
For anyone waiting patiently (or impatiently) for the updates, here's some good news for you:
...
[----------] 7 tests from BlockUtilsTest
[ RUN ] BlockUtilsTest.StoredScriptHistUpd
[ OK ] BlockUtilsTest.StoredScriptHistUpd (281 ms)
[ RUN ] BlockUtilsTest.HeadersOnly
[ OK ] BlockUtilsTest.HeadersOnly (280 ms)
[ RUN ] BlockUtilsTest.HeadersOnly_Reorg
[ OK ] BlockUtilsTest.HeadersOnly_Reorg (367 ms)
[ RUN ] BlockUtilsTest.Load5Blocks
[ OK ] BlockUtilsTest.Load5Blocks (603 ms)
[ RUN ] BlockUtilsTest.Load4BlocksPlus1
[ OK ] BlockUtilsTest.Load4BlocksPlus1 (545 ms)
[ RUN ] BlockUtilsTest.Load5Blocks_Plus2NoReorg
[ OK ] BlockUtilsTest.Load5Blocks_Plus2NoReorg (707 ms)
[ RUN ] BlockUtilsTest.Load5Blocks_3BlkReorg
[ OK ] BlockUtilsTest.Load5Blocks_3BlkReorg (612 ms)
[----------] 7 tests from BlockUtilsTest (3395 ms total)
...
[----------] Global test environment tear-down
[==========] 123 tests from 10 test cases ran. (6361 ms total)
[ PASSED ] 123 tests.
That's a major milestone for the new "persistent blockchain" stuff. It means that the DB successfully tracks all balances, even across reorgs. Given how little the blockchain utilities interface has changed, integrating this into the GUI may not be ridiculously difficult. Though, I won't put a timeline on it because I've been wrong so many times before... |
|
|
|
This is an interesting project for the geek factor, but I think there are other, more attractive air-gap solutions.
Perhaps a better solution would be an animated QR code with a smartphone as a go-between. Hold the phone up to computer A and record a fast-animated QR-style code. The phone then relays this to computer B, and records it's response. The phone itself could manage the communication and act as a master-key.
Anyway, a printed cold wallet and QR scanner are my current solutions, and they work fine. I've never really seen the point of dedicating an "offline computer".
I've become a big fan of the QR-video idea...partly because I have an extensive image-processing background. I used to not like any video-based solution because I'm envisioning a mess of webcams and confused users trying to figure out which camera to point where, etc. But if it's smartphone + laptop, it becomes a heck of a lot more usable. |
|
|
|
This should give you the raw transaction that can be plugged into any broadcast utility. You're right that the raw text shown in the text box is not compatible with anything else, but the raw hex should be. Let me know if that doesn't work. I didn't want to keep cluttering the main discussion thread with my scripting questions etotheipi, so i did a search and this is the only mention I found of Copy Final Tx (HEX) on this forum so I will post this final (hopefully) question here. after much sifting through sample code, I believe I have everything how I want it except I wanted to clarify my thoughts on creating a finalized raw transaction that has been signed offline. I want to have the output be saved as both armory's ascii format and also in a raw hex format that can be broadcast via any broadcast service such as blockchain's pushtx. I have the ascii format figured out and I think I have found the raw hex format while browsing GUI code: binary_to_hex(txdp.prepareFinalTx().serialize()) I've written that output to a file and I believe it is correct, but I wanted to be sure and I am unsure of how to test it without actually broadcasting the transaction (currently I do not have the coins to play with!) It seems like this is similar code to when the Copy Final Tx (HEX) button is pressed when you are about to broadcast an offline transaction from the online armory client. This is what testnet is for! Run Armory with the "--testnet" flag (two dashes), and then in the settings tell it that you will manage Bitcoin-Qt yourself. Then start Bitcoin-Qt with the "-testnet" flag (one dash). Once it's all synchronized, start Armory, and create a new testnet wallet. Once you have a wallet, you can get some free testnet coins from: http://tpfaucet.appspot.com/ Everything that you can do on the main network you should be able to do from here. So get some coins and test it! |
|
|
|
I was working on my script and everything is going well following the samples as you suggested was helpful. What I'm stuck on now is converting the createTxFromAddrList.py to make it so at the end instead of signing and checking etc, it would export the unsigned tx file that I can copy to my offline wallet. Basically everything works perfectly how I want it to build the transaction, but I am having a hell of a time finding how to export the details to a tx file. So up to and including: print 'Creating Unsigned Transaction...'
txdp = createTxFromAddrList(wlt, addrList, recipList, 50000, sendChangeTo)
txdp.pprint() works well. and it prints out a lot of details showing where the unspent outputs are coming from and where they are going etc. I am trying to do this while having a hell of a time with the documentation so finding the right functions becomes a bit more challenging. I also have the other side setup (using cli_sign_txdp.py as an example) to fit exactly how I need it to, just having trouble with the saving of the unsigned tx file. Anyone have any suggestions? Open a *.unsigned.tx file for writing and use the txdp.serializeAscii() method to dump it in the BIP 10 format which will be recognized by Armory GUI or cli_sign_txdp.py script. Also note that since the Armory GUI does most of these things, you can probably find examples of what you're looking for, by simply searching the Armory codebase. I haven't done it, but I'm sure if you search for "txdp" in the ArmoryQt.py and qtdialogs.py, there will only be a few hits, and one of them will be serializeAscii() and another one unserializeAscii(). I use ASCII/text for the encoding so that the data could theoretically be copied into emails, like ASCII-armored PGP data. |
|
|
|
When exactly does it crash? Does it not open at all? Or does it start to open then crash immediately? Do you use a native language other than English? The most recent version had an issue with non-ASCII/non-English characters. If so, you can go to the downloads page and try 0.87.2. Many users have reported that working even when 0.88.1 doesn't. (Googlecode downloads page: https://code.google.com/p/bitcoinarmory/downloads/list) As soon as I finish this RAM upgrade, I will have time to address these things. Getting closer! |
|
|
|
so could I actually load the chain and scan for up to date transaction using this script without actually loading the GUI to scan the chain? basically add a step to the beginning process of script to load/scan the chain (assuming that bitcoin-qt is currently loaded and up to date), then continue on with my previous logic? Also, were you meaning that: BDM_LoadBlockchainFile()
walletObj.setBlockchainSyncFlag(BLOCKCHAIN_READONLY)
walletObj.syncWithBlockchain() is replaced with: TheBDM.setBlocking(True)
TheBDM.setOnlineMode(True)
TheBDM.scanBlockchainForTx(wlt.cppWallet) to put armory into online mode and scan the chain? That's correct. Everything the GUI does could be done from python scripts. In fact, you could think of the GUI as one big python script that simply uses the utilities provided by armoryengine.py (and the massive set of underlying C++ utilities). I've tried to keep the bulk of the functionality in armoryengine.py so that you don't have to import any Qt libraries in order to script it headlessly like this. There's still lots of example code in ArmoryQt.py and qtdialogs.py that could be useful, but everything that Armory GUI can do, can be done through scripts without any GUI interaction. If you run the cli_sign_txdp.py script, you'll see that it does the same thing as GUI, but through a text/terminal interface. To continue discussion on this, it might be worth starting a new thread, to help aggregate this kind of information into a single place for others wishing to do scripting. |
|
|
|
well... for me it still crash on every try.
- i have 8 GB RAM
- i have 64 Bit win7
it worked fine up untill 0.85something (i think).
This is the case on my Laptop AND on my PC (both 64 + 8GB) and i pretty much gave up for now...
Have you completely uninstalled and reinstalled? Sometimes the installer doesn't replace the old files properly when you are upgrading. I've tried multiple things to fix that, but it doesn't work. |
|
|
|
|
Show Posts
