In my case it appears to be utf8/codepage confusion: After setting: DEFAULT_ENCODING = locale.getpreferredencoding() in armoryengine.py:89, it no longer complains about non-existent --satoshi-datadir Furthermore, popen works as expected: import sys
import locale
from subprocess import *
Popen(['msg.exe', '*', '/server:127.0.0.1', sys.argv[1].decode(locale.getpreferredencoding()).encode(sys.getfilesystemencoding())])
Shows it exactly in popup as on commandline. I was able to get it to work in some contexts but not others. When I got it to work from the command line, I wasn't able to get it working from the settings file, when set from the File->Settings menu. But also I wasn't sure if the encoding was hitting the file correctly. There was just so many combinations... Also, it worked with some unicode, and not others. |
|
|
|
You're going to have to work awful hard to convince me that hashing data on the fly as it comes in and storing a single integer out of the middle is so insanely burdensome that it's worth the considerable risk of an incompatible change to the bitcoin protocol, requiring upgrading hundreds of thousands of machines.. etc.
It's certainly not happening in two weeks.
I wasn't recommending this as worthy of its own hardfork. But it's a pretty darned simple and useful modification if we're planning to make incompatible, hard-forking changes anyway. If we're going to be implementing something that is "latent-now-but-required-in-12-months" then this should be seriously considered. The complexity of the process is not the only reason, it's also about the bandwidth. The less data there is to transfer across a channel, the more secure options you have to construct that channel. Right now, if you're going to make an offline signer, you have to accommodate many megabytes going across that channel, even if the vast majority of transactions don't require it. By implementing this, you also leave the transaction sizes up to the user, not the people that sent him coins. |
|
|
|
Hi etotheipi,
I don't have access to a PC right now but I did have to deal with this kind of annoyances in the past...
Can you simply try to add the below comment as the first line of your test file?
#encoding=utf-8
Does this fix the issue? If not, I'll dig some more into it tomorrow evening...
The problem is not the source-file encoding. I think that's what you're talking about, and would only matter if the source file itself had non-ASCII in it. Is this correct? The problem is not the source file, but rather, strings and filesystem objects that are handled by the code. |
|
|
|
|
For reference, QuantumFoam might have found the answer already. He pointed me to using the win32process::CreateProcessW method which actually looks like it will work. I haven't tried it yet, but I did a little googling about it and it looks like it's the correct answer. I just want to get his answer here so no one posts "first", instead of him.
|
|
|
|
|
This has been proposed a couple times. Yes, it's a poor-man's 2-of-2 transaction. It suffers from two big problems though:
(1) Requiring uses to reveal private keys, and/or managing secrets separately from the existing wallet infrastructure
(2) There is no mechanism for partial payouts. One user or the other user gets it all. Partial refunds are not "possible" in a zero-trust environment, and there's no room for a third-party to save you if one party loses the key (not that third-parties are required, but they should be optional).
Of course, multi-sig transactions solve all this. But it's not implemented anywhere yet (in a usable way). However, the effort to actually implement this would be better spent just implementing the multi-sig approach, which is enabled on the network.
But yeah, it does "work". Yay for EC math.
|
|
|
|
FYI, the way I deal with this issue today (specification update pending), to make things easier :
- A new "trusted input" type is added. A trusted input is : transaction hash + index (prevout) / amount / signature of the previous data (using a key known only by the device)
- The device can generate a trusted input from a transaction output, by parsing a transaction, at any time (so it can be done in a batch before actually using it)
- When creating a new transaction, prevout is replaced by the trusted input.
Another idea would be to have a separate smartcard device that is plugged into an online machine and only generates trusted inputs from outputs (just like you do now). It signs them with its private key and your offline device knows the public key. Your offline device could require that all inputs are trusted inputs, without ever being online. This way, if the online computer is compromised, it still can't lie to the offline computer about the value of an input - the connected smartcard verifies the transaction before certifying the value of its outputs. It seems a bit excessive to bring in an extra piece of hardware to try solve this problem. Not to mention there's too many ways for this to go wrong: the compromised system could exploit the presence of the smartcard when you do a legitimate transaction, and pre-sign inputs that are likely to be used on future transactions, etc. I recognize you're proposing workarounds to the fact that SIGHASH_WITHINPUTVALUE is not implemented. But I'd much rather require supporting-transactions until something like this new SIGHASH can be implemented. Adding extra public keys and authentication of that sort to the offline device is considerably less than ideal. |
|
|
|
Had a question about the on screen keyboard. I noticed the number keys which are labeled "#1, #2" etc, input 2 characters into the textbox when using them. The passcode fails from this. I'm guessing I'm doing something wrong when entering numbers using the on screen keyboard? Is there a special way to get them to just print the number itself and not two characters?
Well, I'll be damned. I did screw that up. I added the "#" symbols late in the design of that in order to help with quick identification when using the scrambled keyboard. My test password on my testnet wallet doesn't have numbers, so I guess I missed that. Luckily (?) I never implemented the OSD for password creation, so the user can be sure that they set the password they thought they did (because they have to type it). But you're right, that the numbers are messed on OSD entry. I'll fix that and make it part of the next release. Thanks for catching that! |
|
|
|
So, lots of reports of unicode issues on non-US systems trying to run Armory. I had tested unicode support by setting my Satoshi datadir to "Bitcoiné" and then letting Armory try to figure out the rest. This was tested both in Windows and Linux. But now I have reports of this failing. I realize that I didn't do parts of it right, but now I see that parts of it I can't figure out at the slightest. If I instead use this directory name: Bitcoinéś , everything now falls apart. The ś is apparently un-convertable to the encoding used by subprocess.Popen, even though it succeeds everywhere else. Having that filename in pure unicode works fine for os.path.exists() and I can even open a file inside and write data to it. I think it's because the os module knows how to talk to Windows. But I don't. So here I am: import os
import sys
import locale
pathUni = u'C:\\Users\\vbox\\ArmoryCheckout\\Bitcoin\xe9\u015b\bitcoin.conf'
os.path.exists(pathUni) # true
open(pathUni, 'w').write(...) # works
print locale.getpreferredencoding() # cp1252
print sys.getfilesystemencoding() # mbcs
# Errors out trying to convert to ASCII
subprocess.Popen(['something.exe', pathUni])
# Fails to find path
subprocess.Popen(['something.exe', pathUni.encode( 'utf-8')])
# Fails to find path
subprocess.Popen(['something.exe', pathUniencode( locale.getpreferredencoding() )])
# 'charmap' codec can't encode u'\u015b': character maps to <undefined>"
subprocess.Popen(['something.exe', pathUni.encode( sys.getfilesystemencoding() ])
, was resolved by modifying "something.exe", because it was an app they controlled. That doesn't solve my problem, where I don't have control of it. I don't even know how to ask for help. But if someone has experience with this and can help me fix it, it's worth 2 BTC to me. I've wasted almost a full day on this! (p.s. this doesn't seem to be a problem in Linux, for which preferred and fs encoding are all UTF-8... it's only a problem in Windows). I suppose you can just create a directory or file in Windows with a ton of crazy unicode characters, and then attempt to run a Popen command using that file or directory as an argument. It will fail. |
|
|
|
|
Armory will definitely have to be modified to get it usable on such a small screen, but I bet I could do it.
|
|
|
|
Would there be any risk If I make a backup of my encrypted Armory wallet on Dropbox? Thanks.
I liked the analogy someone else made on the forums: Backing up your wallet to a shared service like Dropbox is like buying a bullet-proof vest, and then asking a random person to shoot you in the chest. Yes, there's a very good chance your bullet-proof vest will survive, especially if you got a good one (strong passphrase), but if they happen to be hardcore and have military-grade firearms, you might be in trouble. You'd be best not to test it. If you don't have a lot of money, it's not so terrible. But if it would make you cry to have it stolen, I recommend making paper or hard-digital backups (CD/USB). Or at least put it somewhere that isn't so accessible -- Dropbox doesn't have the best history of securing your data. It wouldn't surprise me if there were employees at dropbox who go digging for wallet files backed up by users. |
|
|
|
|
Did you forget to send the log file?
There's no compromise. Armory bugs like this simply prevent you from using the program, but do not expose any private key (security-sensitive) data. The log files are intentionally constructed to not include such information, even if it would be helpful to me to debug. I take the security aspect seriously. You are still encouraged to look through it if it calms your nerves, though most users may not have the background to know what' they're looking for.
After I see your log file, I would like to try to fix it and send it to you to try it. I have not had this problem before, so I can't recreate the error to know if I've fixed it. But based on what you already copied, I'm pretty sure I know what to do.
Your wallets are safe, just inaccessible. Can you try something? Can you go to the Start menu and find where Armory was installed, and then select "Armory (Offline)". Tell me if that loads or if you get the same error. If it loads, you can at least get access to your wallets where you could theoretically export the private keys to pull into a different applications. But hopefully I'll get a fix for you shortly!
|
|
|
|
I've been meaning to put together a short how-to about getting setup with armoryengine, which is the base of Armory. Anything Armory does, armoryengine can do. But it can be pain to setup in Windows, and some people need a little push with some example code to make it happen. So I'm going to explain how to get into the interactive environment in both Windows and Linux, then some sample code to see how you can access armoryengine.py functionality:
Setting up in Ubuntu: This is just five commands as posted on the Building Armory from Source page. It works on a fresh boot Ubuntu, as long as you have an internet connection: $ sudo apt-get install git-core build-essential pyqt4-dev-tools swig libqtcore4 libqt4-dev python-qt4 python-dev python-twisted python-psutil
$ git clone git://github.com/etotheipi/BitcoinArmory.git
$ cd BitcoinArmory
$ make
$ python
$ >>> from armoryengine import *
Now you have access to all armoryengine has to offer.
Setting up in Windows: Quite a bit more involved, because you need to install all the python dependencies manually, and install Armory itself to get a .dll you need (but which isn't bundled in the git repo). But I just tested this on a fresh Windows VM, so this should work reliably. (1-7) Follow the Windows instructions on the Building Armory from Source page, but only through installing zope.interface. Stop once you get to the SWIG step (you don't need swig or anything else there) (  Grab the latest 64-bit version of Armory. You need two files from it to run the python utilities. (9) Copy _CppBlockUtils.pyd and CppBlockUtils.py from "C:\Program Files (x86)\Armory\Armory Bitcoin Client\" into your cloned git repo. (10) Open "Git Bash" put on your desktop and "cd" your way to the git repo. (11) Type "/c/Python27/python.exe" (12) Type "from armoryengine import *"
Some simple things you can do with armoryengine.py: Here's a simple script showing a bunch of things you can do. You can use it to play with addresses, transactions, binary strings, hex, binary, base58, etc. from armoryengine import *
print 'Current time is: ', RightNow()
print 'Current time is: ', unixTimeToFormatStr(RightNow())
print 'Easy display of times and bytes: "%d"B is "%s"' % (10**7, bytesToHumanSize(10**7))
strBinary = '\x00\x00\x03\x0a'
strHex = binary_to_hex(strBinary)
print ''
print 'Original binary string in hex: ', strHex
print 'Switch endianness of a result: ', hex_switchEndian(strHex)
print 'Integer (little-endian is default):', hex_to_int(strHex)
print 'Integer (force big-endian): ', hex_to_int(strHex, BIGENDIAN)
print 'Convert numbers to hex or binary: ', int_to_hex(251)
print 'Convert numbers to hex or binary: ', int_to_hex(251, widthBytes=4)
print 'Convert numbers to hex or binary: ', int_to_hex(251, widthBytes=4, endOut=BIGENDIAN)
print ''
print 'Also convert Base58<-->Binary: ', binary_to_base58(strBinary)
print 'Also convert Base58<-->Binary: ', binary_to_hex(base58_to_binary('1ArmoryX'))
print 'Also convert Base58<-->Binary: ', binary_to_base58('\x00\x57\x60\xd5\xde\x82')
print ''
print 'Pack and unpack VAR_INTs: (158): ', binary_to_hex(packVarInt(158)[0])
print 'Pack and unpack VAR_INTs: (1883): ', binary_to_hex(packVarInt(1883)[0])
print 'Pack and unpack VAR_INTs: (2^53): ', unpackVarInt('\xfd\x5b\x07')
print 'Pack and unpack VAR_INTs: (2^53): ', binary_to_hex(packVarInt(2**53)[0])
print ''
print 'Make sure to only has binary strings, never hex! Always returns binary!'
print 'sha256(strHex): ', binary_to_hex( sha256(strBinary) )
print 'sha256(sha256(strHex)): ', binary_to_hex( hash256(strBinary) )
print 'ripemd160(sha256(strHex)): ', binary_to_hex( hash160(strBinary) )
print ''
print 'Play with transactions:'
txHex = ('01000000012cd3dbb674a379211607838af7caa165f36f5823367208c51fc1a0'
'344e96a3f1010000008b483045022100d857839cd7f2da84c8993f4c72afbe07'
'4a5c77a44b2b43b1f8df4601df71e54602207a2647d11c7bafa03345dd41298e'
'2d5b54f524fcbe846dd8114ed1ed7cc2d34e0141043753f29064339c7f616b3e'
'baa27873be06bde832a603f014421f6270de0371aed18bf82ac65ec26eef758e'
'452fd30dee1d43d34d452b030ccbb8bc777664e6d5ffffffff0200e1f5050000'
'00001976a91416b31981c5aed9fcb85c863b9f808638a8bab72288ac806e5a43'
'000000001976a914ac4e0288884f2ca6866ccd5085c3e6e85c53bbf788ac0000'
'0000')
print 'View large blocks of hex conveniently (a full tx):',
print prettyHex(txHex)
tx = PyTx().unserialize( hex_to_binary( txHex ))
tx.pprint()
print 'Printing all inputs:'
for txin in tx.inputs:
txin.pprint()
print 'Printing all outputs:'
for txout in tx.outputs:
txout.pprint()
print ''
print 'Play with addresses: (note private and public keys are SecureBinaryData objects)'
privKey = SecureBinaryData('\xfa\xb3\x00\x39'*8)
addr = PyBtcAddress().createFromPlainKeyData(privKey)
print 'FullPrivKey:', binary_to_hex(addr.binPrivKey32_Plain.toBinStr())
print 'FullPubKey: ', binary_to_hex(addr.binPublicKey65.toBinStr())
print 'Hash160: ', binary_to_hex(addr.getAddr160())
print 'AddrStr: ', addr.getAddrStr() The output of this script is: Current time is: 1367089117.34
Current time is: 2013-Apr-27 02:58pm
Easy display of times and bytes: "10000000"B is "9.5 MB"
Original binary string in hex: 0000030a
Switch endianness of a result: 0a030000
Integer (little-endian is default): 167968768
Integer (force big-endian): 778
Convert numbers to hex or binary: fb
Convert numbers to hex or binary: fb000000
Convert numbers to hex or binary: 000000fb
Also convert Base58<-->Binary: 11ER
Also convert Base58<-->Binary: 005760d5de82
Also convert Base58<-->Binary: 1ArmoryX
Pack and unpack VAR_INTs: (158): 9e
Pack and unpack VAR_INTs: (1883): fd5b07
Pack and unpack VAR_INTs: (2^53): [1883, 3]
Pack and unpack VAR_INTs: (2^53): ff0000000000002000
Make sure to only has binary strings, never hex! Always returns binary!
sha256(strHex): 666945b30a69280a62d9c5215ff1417edb86c538669b497f62c35d2e66b388f3
sha256(sha256(strHex)): df4279ed267b3541eb5dcbb328219d3d409e6e1d22256ddf5b0ea2fb608ea47c
ripemd160(sha256(strHex)): 57e4edbd695ca33612537f4a62fde541bd65a1f3
Play with transactions:
View large blocks of hex conveniently (a full tx):
0x0000: 01000000 012cd3db b674a379 21160783 8af7caa1 65f36f58 23367208 c51fc1a0
0x0020: 344e96a3 f1010000 008b4830 45022100 d857839c d7f2da84 c8993f4c 72afbe07
0x0040: 4a5c77a4 4b2b43b1 f8df4601 df71e546 02207a26 47d11c7b afa03345 dd41298e
0x0060: 2d5b54f5 24fcbe84 6dd8114e d1ed7cc2 d34e0141 043753f2 9064339c 7f616b3e
0x0080: baa27873 be06bde8 32a603f0 14421f62 70de0371 aed18bf8 2ac65ec2 6eef758e
0x00a0: 452fd30d ee1d43d3 4d452b03 0ccbb8bc 777664e6 d5ffffff ff0200e1 f5050000
0x00c0: 00001976 a91416b3 1981c5ae d9fcb85c 863b9f80 8638a8ba b72288ac 806e5a43
0x00e0: 00000000 1976a914 ac4e0288 884f2ca6 866ccd50 85c3e6e8 5c53bbf7 88ac0000
0x0100: 0000
Transaction:
TxHash: d33a63e76e6ccb4783a1c843191ce3c317df8a0390eee4a91405802b1ab7dd00 (BE)
Version: 1
nInputs: 1
nOutputs: 2
LockTime: 0
Inputs:
PyTxIn:
PrevTxHash: f1a3964e34a0c11fc508723623586ff365a1caf78a8307162179a374b6dbd32c (BE)
TxOutIndex: 1
Script: (483045022100d857839cd7f2da84c8993f4c72afbe074a5c77a44b2b43b1f8df)
Sender: 1Gi4gDcPbUU2RiET5dNgZFVdj1Zyw3pdyM
Seq: 4294967295
Outputs:
TxOut:
Value: 100000000 ( 1.0 )
Script: OP_DUP OP_HASH (1352RHJqxaY8zF6S41drgYSqHNqYXJsYMq) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 1130000000 ( 11.3 )
Script: OP_DUP OP_HASH (1Gi4gDcPbUU2RiET5dNgZFVdj1Zyw3pdyM) OP_EQUAL OP_CHECKSIG
Printing all inputs:
PyTxIn:
PrevTxHash: f1a3964e34a0c11fc508723623586ff365a1caf78a8307162179a374b6dbd32c (BE)
TxOutIndex: 1
Script: (483045022100d857839cd7f2da84c8993f4c72afbe074a5c77a44b2b43b1f8df)
Sender: 1Gi4gDcPbUU2RiET5dNgZFVdj1Zyw3pdyM
Seq: 4294967295
Printing all outputs:
TxOut:
Value: 100000000 ( 1.0 )
Script: OP_DUP OP_HASH (1352RHJqxaY8zF6S41drgYSqHNqYXJsYMq) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 1130000000 ( 11.3 )
Script: OP_DUP OP_HASH (1Gi4gDcPbUU2RiET5dNgZFVdj1Zyw3pdyM) OP_EQUAL OP_CHECKSIG
Play with addresses: (note private and public keys are SecureBinaryData objects)
FullPrivKey: fab30039fab30039fab30039fab30039fab30039fab30039fab30039fab30039
FullPubKey: 04b5bdd137eb8001c3478402b04e2a5536af8511aa9e40c2c058e6af6470181130e28deff4fc5e9689f95e10410657c89dad9a5bbae4f5a081d6185a796d5b2600
Hash160: 12788165043cbd1bb914ae4c74f400531c5101d6
AddrStr: 12gfXKTYd1gqmyJCg7Sj36GQyt8KGuVsEz
|
|
|
|
|
Interesting, I thought I had solved that unicode issue in this release. Can you please send me the full log file so I can see what's going on? My screenname, @gmail.com
The underlying error that I thought I fixed was that your path to the Bitcoin homedirectory has lots of non-ASCII characters (what is on the English(US) key board). I'm surprised the old one stopped working. Have you changed your Bitcoin-Qt datadir recently?
Armory never paid good attention to unicode issues before, and I finally made an effort in this last release. Apparently I didn't quite get there...
|
|
|
|
I don't know if this has been proposed, but it's an app I would love to create if I wasn't so terrified of going near gambling apps. I'll let someone else steal the idea. Note: this could be Intrade-style betting, too. It doesn't have to be sports betting. CONOPS (CONcept of OPerationS):Two guys at a sports bar are watching a featured event and argue about which team is going to win. They want to make a bet, say 3:1 on the outcome of the match. They've never met each other, and in fact they're quite drunk so there's no guarantee that they'll ever see each other again. But they don't need to see each again, as long as the winner comes back to the bar the next day to collect the "payment code." (there's a variant that doesn't even require that; see "Extra Credit") The house is "passive" here because they do not have any active role in any individual bet. They just post a QR code on the wall for each event going on. The QR code has the following information (concatenated together): ["Team A" || Hash(SecretA) || "Team B" || Hash(SecretB)]The guys each scan the code with their phones, then touch their phones together (or do the QR exchange), and the app pops up and says: "Are you betting on Team A or Team B? What odds? How much?" If you both put complimentary information into the phone (one picks A and puts in X BTC, and the other puts in B and 3X BTC), then it accepts it and the bet is made. Both users' phone wallets are deducted coins (because they were sent to this funky script), and they can now wander off and never see each other again. The next day, or later that night, the winner goes back to the bar and the house will have posted a new QR code based on the output of the event. It's either SecretA or SecretB (unhashed), depending on who won. (There could be a third option for "no-contest-everyone-gets-their-money-back" scenario, but this will dramatically increase complexity). The guy scans the bar code with his phone, and his phone instantly recognizes it and completes the transaction to send the money to himself. Done. I have a fun modification that could even make redemption automatic without going back to the bar (as long as his phone is on), but that's an "add-on" to this idea at the end. How it works:Once they have exchanged public keys and scanned the QR code, they construct the following transaction: Inputs: Bettor A: X BTC Bettor B: 3X BTC Outputs: Non Std-Script: [HashOfSecretA and PubKeyA] OR [HashOfSecretB and PubKeyB] Redeem by signing and supplying the correct preimage of your hash. Drawbacks: --Non-standard. App probably needs to have direct connection to a miner that is willing to support these transaction types, and bets need to be made well in advance of the event to ensure time to get into the blockchain. --Patron has to go back to the bar after the event. Not ideal if he doesn't remember he made the bet (he was drunk), or he's traveling and in town only for the night. Both of these could be resolved by putting the data on the net. Or my extra credit, below. --House gets nothing. They would have to do this purely as a perk for customers without any compensation -- besides the fact that people love betting, and might go there for the perk. However, if it were popular, you only need one third-party, anywhere willing to do it for free, and all apps/devices could connect to it for major events. However, if the house could still do it for local events.
Extra Credit:How could we automate this so that neither party actually has to go back to the bar to get the redeem code? The bar could actually "signal" through the blockchain, but not in the normal way that everyone hates! The reason I used OP_HASH160 above, is because "SecretA" and "SecretB" could actually be unspent TxOuts (UTXOs) owned by the house. It doesn't matter how big the UTXOs are, or where they ultimately go. All that matters is they haven't been spent and these are the addresses have never been used: i.e. the public keys are not public yet! Before the event, both UTXOs are in the house's wallet, but "locked": artifically prevented from being spent. When the event is over, the house unlocks the correct UTXO and it will be spent on their next transaction that would've been executed by the house, anyway. The patron's phones used the HASH160 of those UTXOs as the secrets, and the act of the house spending the coins puts the public key into the blockchain. The device only has to store the address and watch the blockchain for any transactions spending coins owned by the address. When it sees it, it can automatically complete the transaction. And, he doesn't even need to put in his password. Because he already had to put it in when signing the original transaction... he can pre-sign the return transaction to himself, and the app can just plug in the public key into the redeem script to complete it. The only catch is that the house not spend the other output for 30 days. After that, they spend the other output, and if the winner never claimed the money, then the loser can. No coins lost!
The actual output script for the transaction is complicated, but here it is (because it was fun figuring out the script  ):
OP_HASH160
OP_PUSHDATA(<Hash160(SecretA)>)
OP_EQUAL
OP_SWAP
OP_PUSHDATA(<PubKeyA>)
OP_CHECKSIG
OP_BOOLAND
OP_ROT
OP_ROT
OP_HASH160
OP_PUSHDATA(<Hash160(SecretB)>)
OP_EQUAL
OP_SWAP
OP_PUSHDATA(<PubKeyB>)
OP_CHECKSIG
OP_BOOLAND
OP_BOOLOR
OP_VERIFY
Redeem script: BettorA: 0 0 SigA PreimageA or BettorB: SigB PreimageB 0 0 I don't know if that's exactly right, but it's probably close. |
|
|
|
|
Wait, what's wrong with the merchant saying "You bill is 5.0 BTC. We cover up to 0.01 fee, so you can send us 4.99".
|
|
|
|
If I want the output script to look like: <pubKey> OP_CHECKSIG
By looking at the code I see no way if doing it.
Is there a way?
Thanks, Sergio.
I don't know what you mean by "is there a way to do it?" Yes, it's a valid script. In fact, it used to be the standard script for coinbase transactions: miners would actually use the script instead of the hash160 form for the generation output. I don't know why, but that's what showed up in this diagram because that's what all coinbases looked like when I made the diagram (two years ago). As for whether it's standard, I don't know. It didn't matter back then because it didn't need to propagate. It was only used by miners for their own reward, so the only person that needed to see it before it showed up in a block was themselves. So propagation was irrelevant, as long as it was valid. I wonder if the general perception that "hidden" public keys is a more long-term viable security position, has something to do with it (i.e. in case those coins aren't moved for the next 30 years, then they don't have to worry about QCs). |
|
|
|
I created a command-line tool for splitting your Armory wallet into M-of-N pieces, for backup purposes, only. You can find the description and instructions here: https://bitcointalk.org/index.php?topic=149820.0I am in the process of integrating it into the GUI so that M-of-N (using Shamir's Secret Sharing) will be a default backup option. However, this is only intended for backup. If you want to split the signature-scheme across multiple computers (i.e. to use it for every new transaction), you want multi-sig. Unfortunately, no clients support multi-sig yet  Armory will, hopefully in the near future. Until then, I am hoping to get this "fragmented backup" thing integrated so people can at least backup their single-sig wallet securely (i.e. 2-of-4, put one piece in safe-deposit box, put one in your home, give one to each of two trusted friends without telling them anyone else has any pieces). If your offline computer dies, go fetch. |
|
|
|
While BTC is still the king-of-the-hill, there are a number of altCoins popping up these days that often use the same core code for their wallets (since they have essentially the same structure). Can Armory support these as a mix of 'wallets'?
I've offered to give folks advice on how to adapt Armory, though only one person has really tried. A lot of coins may only need changing some constants. And in the case of LTC, updating a hash function. I know there will be some other hurdles, but it may not be a ton of code. It's just that alt-currencies are nowhere near the top of my priority list. |
|
|
|
Update for anyone with strange connection problems. I just spent 2 hours debugging Armory on my fiancee's computer (which has no dev environment). Because her system installed Armory and then was stuck perpetually at "Initializing Bitcoin Engine". After a painful battle with Windows I finally extracted this strange error: {"result":null,"error":{"code":-1,"message":"CWallet::GenerateNewKey() : AddKey failed"},"id":1}
{u'id': 1, u'result': None, u'error': {u'message': u'CWallet::GenerateNewKey() : AddKey failed', u'code': -1}}It turns out that Armory couldn't communicate with Bitcoin-Qt, because Bitcoin-Qt was reading an old, corrupted wallet. I never asked it for a new key, but it spits out that error anyway. The solution was to remove the C:\Users\username\AppData\Roaming\Bitcoin\wallet.dat! Of course, don't completely delete it if you have money in Bitcoin-Qt. But even if you don't plan to use Bitcoin-Qt again, apparently a bad wallet can really cause Armory to misbehave! So frustrating that a Bitcoin-Qt error can make Armory look so bad!
@smith1023 Woah it has been a fast answer! I was expecting a different answer. I meant what kind of info does it require from the blockchain. Looking through the code (lines 600-630 armoryd.py) I understand that it is required for an unsigned transaction to include not only the origin wallet, the receiver wallet, and the amount, but all the transactions of that wallet. utxoList = self.wallet.getTxOutList('Spendable')
utxoSelect = PySelectCoins(utxoList, totalSend, fee)
txdp = PyTxDistProposal().createFromTxOutSelection(utxoSelect, outputPairs)So if I were to send a transaction for which I have balance, but I used an old version of the blockchain for the input of "utxoList" it would get refused by the network? Kind of. When you create a transaction, Armory has to collect unspent-TxOuts from previous transactions, to put TxIn references into the transaction to be signed. It has to collect enough of them to cover all the outputs. However, the TxIn only includes the hash and index of the unspent output. Armory has no way to know how big each of those outputs are, so it has got to send the entirety of those transactions along with it, so the offline computer can verify "Okay, tx a3f3b198 txOut #2 really does have 1.53 BTC". You can read more about why you have to do that at this thread I started recently (where I also proposed a solution). So the "supporting transactions" are necessary for verification, but not the answer to your question. The answer is that two things can go wrong (in a safe way), if you don't have the updated blockchain: (1) Armory will try to spend unspent TxOuts (UTXOs) that have already been spent. Your blockchain is up to block 200,000. You have a UTXO created at 150,000 and spent on 210,000. You would create a transaction assuming it's unspent, and then the network will reject it because you're attempting to spend alread-spent coins. (2) You are just missing UTXOs. If someone sent you bitcoins and the tx was included in block 215,000, your offline system will never see it to be able to know it exists, much less be able to spend it. This is why your online computer needs to be in the loop: it maintains a completely-up-to-date list of your UTXOs, and does the coin selection for you, even thought it can't sign it. It picks valid UTXOs, bundles them into a tx, and the only thing it's missing is the authorized signatures. That's what your offline computer is. |
|
|
|
Great, I thought your deadline would have been shorter. I'm ok to look at it if you're ok.
I just want to be sure I understand: you want to sign a message with a private key? I thought Armory already signed messages
Armory's signmessage is not compatible with Bitcoin-Qt. Their signatures cannot be cross-verified (not even the same format). I didn't want to follow Bitcoin-Qt because I hate bare signatures. So I proposed I would become compatible if they started to support "proper" signatures: which is the original, properly encoded text, along with the signature. I didn't even get any commitment from them on this but someone suggested that RFC2440 was the way to go, and if I lead, I might get them to follow. Especially if it builds off an existing standard. "Version 0" will be compatible with the existing Bitcoin-Qt, so that bare-signatures will cross-verify. I know some people still want the backwards compatibility. "Version 1" implements the target behavior: copy this base64 block of text into and it pops up a windows saying "The following message has a verified signature from Address X: <message>". This is how message signing should be. Not multiple copy&paste ops which fail if you miss a whitespace character. |
|
|
|
|
Show Posts
