but for what purpose?
So as to allow for the use of compressed pubkeys at roughly the same cost as compressed P2PKH, without murdering the Python wallet code over it. |
|
|
|
2018-01-08 09:44:53 (INFO) -- ArmoryQt.py:5456 - BDM is safe for clean shutdown
2018-01-08 09:44:53 (INFO) -- SDM.pyc:459 - Called stopBitcoind
2018-01-08 09:44:53 (WARNING) -- SDM.pyc:509 - bitcoind exited, bitcoind STDOUT:
2018-01-08 09:44:53 (WARNING) -- SDM.pyc:511 -
2018-01-08 09:44:53 (WARNING) -- SDM.pyc:512 - bitcoind exited, bitcoind STDERR:
2018-01-08 09:44:53 (WARNING) -- SDM.pyc:514 -
2018-01-08 09:44:53 (INFO) -- SDM.pyc:465 - ...but bitcoind is not running, to be able to stop
bitcoind is choking on start. Turn off auto bitcoind in File > Settings, then run BitcoinQt manually. Let it sync in full. Once that's done, delete you databases folder (C:\Users\Dov\AppData\Roaming\Armory\databases) and start Armory the usual way. |
|
|
|
|
PhoenixFire, idoB: I cannot reproduce your issue on either my setup nor fresh Win7 & Win10 VMs. Are you using the installed version or the .zip standalone? If you are using the installed version, can you try with the .zip?
|
|
|
|
goatpig, would it be possible for you to list a sequence of bitcoin-cli commands
I don't think such a thing exists. You need to craft the TxIn manually basically. I'll give you a little run down so you understand what's going on. At the binary level, a legacy bitcoin tx looks like this: version (4 bytes)
TxIn count (varint)
TxIns
TxOut count (varint)
TxOuts
LockTime (4 bytes)
TxIns looks like this: Outpoint (32bytes txhash + 4bytes txout index)
scriptsig
sequence (4bytes)
And TxOuts look like this: value (8 bytes)
scriptPubKey
Whenever you want to redeem an output, you have to point at it in your input as an outpoint (hash + index), and the scriptSig field of your input has to satisfy the scriptPubKey script of the outpoint. The fundamental difference between P2PKH and P2SH is this: - P2PKH always refers to a public key hash, therefor a fulfilled scriptSig will always look like this: (pubKey|sig) - P2SH refers to the hash of any valid script. The scriptSig needs to reveal the hash preimage (the actual script itself) and also fulfill the execution of that script. Typically a scriptSig for P2SH looks like this: OP_PUSHDATA | (P2SH script) | OP_PUSHDATA | (script fulfillment) In the case of P2SH-P2PK used in Armory, the P2SH script is just this: https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/Wallets.cpp#L2673So the scriptSig would look like this: OP_PUSHDATA | (33 | compressed pubkey | OP_CHECKSIG) | OP_PUSHDATA | sig
------------------------------ In order for bitcoin-cli to generate this unsigned tx for you, it would have to have some sort of interface where you can import a P2SH address with the underlying P2SH script. I don't think such interface exists right now (I remember discussing with other devs how that would be the way forward for importing custom scripts a few months ago). This leaves having to craft the unsigned tx manually, then getting bitcoin-cli to sign for it (which I believe is pretty straight forward). Basically you'd have to spend a couple hours learning about Bitcoin transactions and how to get Core to sign a raw tx. Then you have to craft the tx and get it signed. Just be careful about overspending on fees. The testnet is there for trying stuff around anyways. |
|
|
|
|
NUCs can actually fit full sized desktop CPUs, they're pretty cool =D. AFAIK, the gcc4.7 build will run on anything x86 that can operate at least Debian Wheezy and equivalents (Ubuntu 12+). Celerons and other low profile CPUs (think 5W laptop chips) are fine for signing. The only thing you have to look out for is ARM CPUs, as I don't really bother building for those (you can cross compile yourself though).
Your primary security concern is not with the CPU but with making sure your signer is effectively air gapped.
|
|
|
|
Not sure if this is worth even worth a mention, but I was playing around with fragmented backups to test and found something.
I figured I would try to make a backup with a mix of everything. First paper, w/o secureprint, then paper w secureprint, then file w/o secureprint and finally file with securerint. As this was only a test, I didn't take a very close look other than seeing the wallet name (obviously) and the secureprint code staying the same after toggling the latter on/off. After saving and printing the backups, I deleted the wallet and tried to restore them. When I did, the message "If any of the fragments require a SecurePrint code, you will only have to enter it once" (emphasis mine) made me confident the mix would not be a problem.
When I realized none of the backups fragment matched what was stated on the paper/file I realized something was wrong and went back to create a new one. Toggling secureprint on/off shows that this creates a completely new set. However, 3/4 fragmented backups I made have the same fragment-ID (not the 4th), and all 4 obviously the same wallet ID (this was with 0.96.3).
This was just me playing around, and I would have been a lot more careful before depositing anything. Still, there could perhaps be a warning that:
1. you can't mix and match secureprint
2. each time you toggle on/off you create a new set of fragments.
With 0.96.3.99, none of the fragments got the same ID, but the SecurePrint code stayed the same through each toggle.
Based on the initial text of the previous SSS being deterministic, I'm guessing this wasn't a problem before this fix was made?
I see what you mean, toggling secureprint cycles the fragments. I'll look into it. |
|
|
|
|
I figured something out. Wait for the next RC.
|
|
|
|
01d9d0cb000100000000004100000018000004ff0000031f0000000000000000fffffffefffffff e000000000200
What OS is this on? Clearly this part is off: |
|
|
|
|
There's no encryption of public data, so public keys, chaincode and user input are always visible. Maybe I'll do something about that in the future, but that's another topic entirely. Private key data is encrypted more often than not, as it's basically impossible to create a wallet in Armory without setting a password.
|
|
|
|
Does it mean that by using an P2SH-P2PK address I indissolubly and irrecoverably bound my chances to recover forked funds to the fate of Armory?
You're making it sound dreadful on purpose. To spend from a script, you need to create a valid transaction and sign it. Nothing is stopping you from creating and signing that transaction outside of Armory. The private keys are in your control the whole time, that's what matters in the end. It is true that if you are not technical and wish to withdraw coins from an Armory specific script type on whatever air drop fork, you would have to wait for someone else to make that code available to you. If you're aggressively after the airdrops, I suggest you stick to legacy P2PKH, as it is the most widely accepted script type. |
|
|
|
|
Are you trying to turn your Pi into some sort of automated hardware signer?
|
|
|
|
the redeem script?)
No, there's no such thing in private key exporting. The target wallet has to know what to do with the private key. I somehow thought that being able to export private keys in a standard way was a regular feature of Armory, so that we could use them elsewhere in case of need.
It's not. There is no standard for interoperability between wallets, this is a free for all. P2SH-P2WPKH is a standard SW script type described in the BIP, any SegWit compliant wallet is expected to support that script type to claim compliance. What you need to figure out is how to instruct the receiving wallet to instantiate the associated address as nested SW. |
|
|
|
|
This is a question for the recipient wallet, not the origin wallet, i.e. ask Core. I have no experience with the Core wallet, so I can't help you there.
|
|
|
|
|
I've put a lot of efforts in purging all external networking from Armory's GUI by default. This had to be done because that's the binary that handles all the wallet crypto. I will not introduce any piece of code that will break this fundamental segregation of mission critical processes. In the future I plan on moving all wallet and crypto code to a stand alone, headless binary that the GUI will interface with. Only with this extra step will I tolerate code that accesses the WAN from within the GUI.
|
|
|
|
|
Post dbLog.txt
Nvm, the dbLog looks fine. What's your issue exactly? From the looks of your screenshot, you just need to let Core fully sync first before starting Armory and you should be fine. Start Core manually, let it sync, they start Armory.
Delete this folder and start from scratch:
C:\Users\chowa\AppData\Roaming\Armory\databases
|
|
|
|
OK. Does Armory have any bounty system at all so that other contributors could help get features implemented and you can verify/merge?
You can start one on your own if there is a feature you're really after. I'm wouldn't take charge on that stuff atm, too busy. |
|
|
|
|
The ZC parser only processes tx that it gets from your node. The tx your broadcast through Armory are pushed as is to your node. The DB will then requests the tx by hash from your node. This sets in motion the inv packet and subsequent tx fetching that happens for all ZC your node sees. Only after that process is the tx parsed and added to the DB's mempool (if it's relevant to your wallets).
In other words, there's a unified pipeline that's only ever triggered by your node pushing a tx to the DB (which for all intents and purposes, mimics itself as a node to your actual Bitcoin node).
This gives you 2 ways of getting a ZC to appear in your GUI:
- Carry over the zeroconf db to your new db folder and cycle ArmoryDB.
- Successfully push your tx again to your node. If that tx is already in your node's mempool, you'll have to clear, or it won't let your broadcast it again.
|
|
|
|
|
Show Posts
