Probably best not to solely use the URI link method for payments though. Best to mix it with QR codes and copy and paste addresses.
Exactly. Never assume what technology the client will have access to a checkout page with a text address that is a link to the bitcoin uri and a qr code covers all your bases and doesn't take up much more space than just one method. Hopefully, this will be ubiquitous across Bitcoin clients, and then it will be just like regular URLs : for most people it will just work, and if not, they know how to copy it into the browser. For now, that's why the Armory URL creator encourages you to include the plaintext info too, when creating and sending such links.  |
|
|
|
Btw, I finally got around to posting a version with windows networking issues fixed: https://github.com/etotheipi/BitcoinArmory/downloadsIt appears to affect a very few number of users. If you're not having a problem, there's no reason to upgrade to 0.82.3 (though, I might have fixed a bitcoin: URL-handling issue, too... I don't remember if that was fixed in the last version or this one) |
|
|
|
So I made this super simple for people. I'm sure etotheipi will eventually do this himself, but if you want Armory up and running fast and right now. brew tap WyseNynja/bitcoin
brew install wysenynja/bitcoin/bitcoind
brew install --HEAD wysenynja/bitcoin/armory-qt
You don't need to install bitcoind, but I like to. I might eventually add a startup service for bitcoind. Just tried to get an updated version of bitcoind from your forumula and got this error: $ brew install bitcoind
Error: No available formula for berkeley-db4 (dependency of bitcoind)
Did you do a keg for that from somewhere? Btw, I finally removed bsddb, so that dependency should be gone... Though, in the future, I might add it back if the devs don't move on this new wallet format. Luckily, I am pretty sure they won't be using BSDDB for the new wallet format, but if they procrastinate much longer past when I get compressed public keys, I might have to do this. |
|
|
|
I don't think it is as big a deal as it seems. The same laws apply to any donations: cars, boats, airplanes, apples, carrots... Pretty much anything that can be sold for fiat currency.
Yes, but so far there has never been legal recognition of bitcoin as being equivalent to "property" that has "value" that someone "can own." Given that Bitcoin's are really just a figment of the digital imagination of millions of GPUs and CPUs, it remains uncertain how they might be recognized in the legal system. This is the first legal context that it has been recognized as property with value. It's not the biggest legal context there can be: exactly where it falls in the world of securitys, stocks, FOREX, etc, remains to be seen. But it's still a first step among many. And the important part, is that it's first foray into a beaurocrat's lap has been positive: if it had been shot down for whatever reason, Bitcoin would start off at a disadvantage. We'd be fighting an uphill battle. So, this is a very positive thing, and enables others to jump on board because now there is a bit of precendence that they can leverage. |
|
|
|
If it needs intermediaries like bitpay to be "totally-compliant", then bitcoin failed. Bitpay deserves honor for all they are doing for bitcoin and there are many businesses that I guess are better off using their service for now but if you really need this middle man to do a donation (hey, here there is no danger of double-spends or volatility to eliminate.) then I can't cheer for joy. Bitcoin doesn't require that people forgo third-parties to be successful, it only enables it. If Bitcoin users, especially ones with high legal liabilities (such as political candidates that can be ruined by the appearance of shady financing practices) want to pay third parties to help them do it right, then let them do it! The important part is that they have a choice to do it without third parties. And other candidates can do it. Don't call it a failure just because someone was willing to pay a fee to simplify their own operations. |
|
|
|
It is a bit "1980s" but it is the data rate which I could not quite get there. I could only get up to 500 baud which is too slow.
Tantalisingly close though. Say 2000 baud and you are around 250 bytes per second. 1KB per 4 seconds.
Maybe it is something that "would do for 2012" i.e use it and then rip it out and put in a drop in replacement when something better came along. It is the ubiquity of microphones and loudspeakers that made me look at it.
Whatever codec / data transmission route you go please make the protocol nice and open as then it brings the possibility of:
1) Multibit creates a transaction with a watch only wallet of a particular private key (not implemented yet)
2) Multibit passes it over using the "data exchange protocol" to Armory to an offline wallet with the same key in to sign.
3) Armory signs the tx, transmits it back to Multibit
4) Multibit broadcasts.
You know what?! I think this idea is perfect, after all. Given all the problems with so many of the other techniques described... I will accept a speed bottleneck if it comes with all the other security and convenience features desired. A user that really wants security and convenience can wait for it! Most transactions will only be a couple-hundred bytes. Some of them are bigger. If you get 100 bytes per second that's a few seconds for most transactions. 1-2 minutes for somewhat larger transactions. And the most extreme case? Well they can wait 10 minutes. Oh well, they wanted security and convenience, go respond to some emails and come back. So a couple other comments about this: - The speed issue is only in one direction -- for sending data back to the online computer, only signature data has to be sent. Even with 20 inputs being signed, the signatures are only about 70 bytes, so 1.5 kB, so 15 seconds.
- I bet you could use a double-ended headphone cable to connect the output of one system to the microphone of the other. In this case, I bet your baud rate could go way up. Though, the convenience factor is reduced if the user wants to use their speakers for other things...
- I have a signal processing background... I would have a lot of fun with this
- All the problems with other techniques generally have to do with the ubiquity of using those communication channels for stuff. There's already subsystems of code and drivers for auto-operating on signals over ethernet, USB, IR, bluetooth. This is not true for audio -- I plug in a mic, worst case a program on that computer records it, but it's not executing any code with that as input. I mean, it's an analog signal, how could it? (unless it was specifically designed to know what it was looking for, like Armory will have when I'm done)
This isn't in my immediate future, but I think I want to put it on my list of "awesome things to do" after Armory beta. I think this could work... tell me I'm wrong! |
|
|
|
The rainbow attack would be huge, and sneaky. You are using 32 bits for the chain, so find one collision and 2 billion operations later (on average) you've got the entire rest of the sequence, forever. I know you care enough to carefully generate high quality a and c values, but a brain wallet using this system starting with a and c derived from user input is a disaster waiting to happen.
The first private key and chaincode are each 32 bytes. Even if the chaincode was smaller, it wouldn't matter much. The purpose of it is simply to add entropy to the iterative process. And in Armory, the chaincode is actually calculated from the hash(PubKey ) so it changes on every step. In the end, the chaincode only protect your privacy, not your security... I had recommendations to shorten it considerably for this reason: it doesn't need to be a full 32 bytes to accomplish its purpose.
Ahh, so it is bytes. I read your chart wrong. Hmm, that makes your scheme (very!) slightly less secure against rainbow tables. Yeah, I know, rainbows for this are totally impractical because you have a good initial a, but a (very!) lucky hit would reveal the rest of the sequence without the bother of having to search for the c that generates the next one. And just to be clear to people following along at home, the level of "very lucky" that I'm talking about is probably along the lines of an attacker being saved from Death By Meteor when another meteor hits the first one at the last second, knocking it aside. In practice, it isn't much better than brute force, as long as a is strong. If some idiot modifies it to accept a weak a from the user, all bets are off. The security drawbacks of a deterministic wallet like this are basically insignificant. A common complaint is that someone could compromise your seed, and then wait for your to make a big deposit and steal it at a later time. The Satoshi wallet, "unsteals" itself after some time. I think this argument is bogus: they still have 100 addresses in your address pool to wait for some juicy coins to come in with your Satoshi wallet, and frequently there's enough there to be worth taking it right away. There's very few situations where the deterministic wallet compromise is actually non-negligibly worse than a Satoshi-wallet compromise. You're screwed in both cases. On the other hand, the security benefits of the deterministic wallets are so dramatic, they far outweight anything else (and hence why the Satoshi client wants to switch to deterministic wallets in a future version). -- One-time backup -- many more users are going to accidentally delete their wallet or have a failing disk drive, than those who will suffer because the deterministic nature of the wallet enabled a very unique attack on their already-compromised wallet. Backup your wallet one freakin' time, ever. Generate milllions of addresses, you're always protected. This is the biggest fear users have with the Satoshi wallet, and regular, persistent backup solution will fail for the average user... they may keep it up for a whlie, but they swap their backup drive, and forget to set-up their backup system again, or just too lazy. Nay -- print off your wallet once, put it in a safe-deposit box, and live merrily knowing that you won't lose them. -- Offline wallets -- you don't need me to tell you the benefits of it. You already know. The ability to store the private seed offline and never touch the internet is why the attacker won't get the seed to compromise you. |
|
|
|
Interesting thread. Nice to have all these great math minds on this topic.
Can I get your thoughts on doing SHA256(rfc1751)?
From a very brief glance at sipas demo looks like we want to ask people to remember 11 or 12 words. If that is the case can we make a standard with a bigger word list where people would only need to remember 5 words but still have 128 bits of entropy?
The only thing I don't like about rfc1751 is that short words are actually less memorable. Not to mention a 2048 word dictionary is pretty small. You can use a 65,536 word dictionary (16bit) if you include plurals and conjugations, which I think is fine -- even if the user forgets the exact conjugations, they will remember the base words, and will be able to recover their key with enough attempts. 8 words will get you a 128-bit key like this: "inverse speaker ameliorate floated platypuses yearns conjugate nullified" The user knows all the words in their key: and if they remember the acryonym "isaf pycn" it will help them recover all the words. Theoretically, it would be possible to make this even easier if the app that was generating the key was willing to sacrifice a few bits of entropy for the purposes of finding sequences that have nice, memorable acronyms: such as "mime type". Then, even if the user can only remember 6 of the words, there's a limited amount of remaining entropy that they can cycle through with a program. Of course, I still hate brainwallets: I don't like the idea of users taking their Bitcoins to their own grave when they get hit by a bus, but so many people are so passionate about it, it's tough to ignore. |
|
|
|
The rainbow attack would be huge, and sneaky. You are using 32 bits for the chain, so find one collision and 2 billion operations later (on average) you've got the entire rest of the sequence, forever. I know you care enough to carefully generate high quality a and c values, but a brain wallet using this system starting with a and c derived from user input is a disaster waiting to happen.
The first private key and chaincode are each 32 bytes. Even if the chaincode was smaller, it wouldn't matter much. The purpose of it is simply to add entropy to the iterative process. And in Armory, the chaincode is actually calculated from the hash(PubKey ) so it changes on every step. In the end, the chaincode only protect your privacy, not your security... I had recommendations to shorten it considerably for this reason: it doesn't need to be a full 32 bytes to accomplish its purpose. |
|
|
|
What is the public key? new_P = (c*a)*G = c*(a*G) = c*P That's pretty cool. The EC multiplication routine doesn't look like it should associate and cancel like that. ECDSA "multiplication" doesn't exactly resemble the multiple that most folks are familiar with, but it's still associative. a*G is just "adding" G to itself a times. Then c*(a*G) is just adding P to itself c times, which was just adding G to itself a times. So it makes sense (to me) that it's associative, but I've been doing this stuff for a long time...
I guess that means that if Moore's law holds for a bit longer (heh), it will become possible to attempt rainbow tables attacks on schemes like this if they don't start with a good entropy source for a and c. Brainwallets come to mind.
That's the basis for this thread: https://bitcointalk.org/index.php?topic=102349.0The idea is to make the standard clients only accept certain kinds of seeds, thus requiring brainwallet users to add X bits of hard entropy to their [probably crappy] brainwallet seed. I'm not a fan of brainwallets, but we know that folks insist on it, so we want to try to be responsible about it. What issues could be presented just by monitoring the balance on a public address in a watch-only wallet?
You have a watching-only wallet on your system monitoring your offline coins. Then through some feat, either through unauthorized access, or exploiting users' ignorance of how Bitcoin works, they import one of their own addresses into your wallet. You don't know, because you don't pay attention to every address that is in your wallet at all times. Now they offer to buy something from you for 1000 BTC, send the coins to their own address -- and it shows up in your offline wallet watcher! Snugly, you believe that the coins have been sent, because there's 3000 confirmations by now. You send the merchandise, and then they sweep the address. SCAM! What I was considering doing was the following: (1) Create a special kind of watching-only wallet just for this, and it's balance will never be included in your master balance (2) Allow a user to import a watching-only address if it is signed by one of their offline private keys. Part (2) sounds inconvenient, but it actually isn't that bad. Most people would import their private key to the offline computer, first, anyway. The program can sign the public key with one of your existing addresses, so that it can be imported to your online computer. It's just one of those things where I'm putting security above convenience. The vast majority of users could do all this responsibly without hand-holding, but while Bitcoin is still immature, it's my integrity on the line when they screw up. So I want to help them avoid this... |
|
|
|
Question about watching wallets...
Someone is saying that with your deterministic wallet you can create a watching wallet that generates a sequence of public keys that matches the sequence of private keys generated elsewhere. Is that true? And if it is, how the heck do you do it?
Generating a list of (pseudo)random numbers to use as private keys is easy enough, and deriving public keys from them is also pretty simple. But I can't figure out how to write a generator for a sequence of public keys that doesn't involve generating the list of private keys and then deleting them.
It's the same process as diffie-hellman key exchange: here's the simplest way to do it: a: Private Key (32-byte integer) P: Public Key (a point on the secp256k1 curve) G: Public "generator" for ECDSA curve (another point on the curver) A public key is just a "multiple" of the generator of the group: P = a*G (ECDSA special multiplication) Note that ECDSA multiplication cannot be reversed. This is secure. Let's pick another point, c, which is our chaincode. I create a new private key: What is the public key? new_P = (c*a)*G = c*(a*G) = c*P So if you have a keypair and a chaincode, you can make the publickey+chaincode the watching-only wallet, and the privatekey+chaincode is the private wallet: a[i+1] = c*a[i] (this is the full wallet)
P[i+1] = c*P[i] (this is the watching-only wallet)
What Armory does has a few more details, but that's it. Note that this is necessarily secure for the same reason that your private key isn't compromised by your public key: ECDSA "multiplication" can't be reverse (efficiently) |
|
|
|
Slightly different point also, you cannot in general assume that paying to an address is equal to paying a person unless they explicitly agree it will count as payment because they may have lost the private key or not be looking there anymore or sold it to someone in a foolhardy firtsbits collecting scheme.
Given the situation Mark is in it is impossible to return the coins to the senders, he's not accomplishing the desired undonating. But since he's only trying to convince bureaucrats who won't understand anything that comes with a sentiment of "I'm sorry I did something strange regarding money and I tried my best to undo it" will probably work unless they hate him.
Everything you mentioned is crazy corner cases. It would be extremely rare that someone would lose their private key or somehow lose it in a scam. Even things like Casascius physical BTC are usually swept to your wallet (or imported) before you can send it on. That's not to say that it doesn't happen, but we shouldn't let extreme corner cases dominate what is otherwise a perfect solution. Put up the appropriate warnings, and if the donor absoloutely insists that the sending coins back to the addresses would result in permanent loss or theft, Mark can donate them to charity. |
|
|
|
The old PyBtcEngine project (the precursor to Armory), had a pure-python implementation of all the ECDSA math. Granted, that was based on an old post by Russian forum user "Lis", in which he released the pure-python-ECDSA code to public domain. I just wrapped it up. If you clone the PyBtcEngine project, you will probably only need to to "from pybtcengine import *" and then run the relevant calls. Here's some sample code that showing how to convert private key to address in the first four lines (in bold). Then it does a ton more. This is in unittest.py, where I created a private key ('aa'*32) and an empty transaction and tested signing then verifying it. print 'Testing PyCreateAndSignTx'
AddrA = PyBtcAddress().createFromPrivateKey(hex_to_int('aa'*32))
AddrB = PyBtcAddress().createFromPrivateKey(hex_to_int('bb'*32))
print ' Address A:', AddrA.getAddrStr()
print ' Address B:', AddrB.getAddrStr()
# This TxIn will be completely ignored, so it can contain garbage
txinA = PyTxIn()
txinA.outpoint = PyOutPoint().unserialize(hex_to_binary('00'*36))
txinA.binScript = hex_to_binary('99'*4)
txinA.sequence = hex_to_binary('ff'*4)
txoutA = PyTxOut()
txoutA.value = 50 * (10**8 )
txoutA.binScript = '\x76\xa9\x14' + AddrA.getAddr160() + '\x88\xac'
tx1 = PyTx()
tx1.version = 1
tx1.numInputs = 1
tx1.inputs = [txinA]
tx1.numOutputs = 1
tx1.outputs = [txoutA]
tx1.locktime = 0
tx1hash = tx1.getHash()
print 'Creating transaction to send coins from A to B'
tx2 = PyCreateAndSignTx( [[ AddrA, tx1, 0 ]], [[AddrB, 50*(10**8 )]])
print 'Verifying the transaction we just created',
psp = PyScriptProcessor()
psp.setTxObjects(tx1, tx2, 0)
verifResult = psp.verifyTransactionValid()
More than you asked for... but maybe you'll be interested in all of it later  Btw, Armory has the same functionality, but I outsourced all the crypto to C++, where it's a hell of a lot faster. If you want to use the latest, you can do that, but it will require compiling... but the crypto itself hasn't really changed. |
|
|
|
|
Just a comment:
Addresses and keys are usually expressed as Base58. This doesn't have to be the case.
Take your regular key, and instead of encoding it as base 58, encode it as Base26, with [A-Z] ~ [0-25]. Or Base36: [A-Z,0-9]~[0,35]. Add an extra line or in parentheses "BASE26" to the plate, to identify how it was created. Regardless of whether it is Base58 or Base26, it still needs to end up in Base256 before it is interpreted by the computer. If someone knows it's a private key, it will be recoverable...
Also, if you are etching this in metal, the checksum isn't quite as important: I imagine this is going to be extremely resilient, so the extra checksum characters won't make much of a difference -- you're much more likely to lose the whole thing, or have it completely destroyed by accident, than somehow losing only one or two characters. But you can add it anyway: just start with your binary (Base256) private key, add the four-byte checksum, then convert all 36 bytes to Base26. Done.
|
|
|
|
Yeah, sorry, I keep forgetting to look at the pull requests. I thought the last changes I made to the Makefile were good...? Did I never merge that to the master? I can't change the Makefile yet, without risk of breaking my debian package build. It uses DESTDIR, so I need to do some testing on it before committing the change. My guess is that it won't work right, but I guess I can always branch the makefile based on detected OS. It doesn't need to get done right away, anyway. No major bug fixes to master that aren't already in dev. So you can stay on dev and everything will be fine... |
|
|
|
Another question: Is it possible to choose inputs in Armory -- e.g. if I want to spend coins from a specific address?
I haven't implemented coin-selection yet, though it's on my list of things to do. There is demand for it, but I have some other priorities that need to happen first. Glad you are enjoying the program I suppose if I really needed to I could create a new wallet, export/import the relevant private key(s) to that wallet, use the new wallet for the spend, and delete it afterwards. Aside from the obvious warning when importing duplicate keys, is there any reason this workaround wouldn't work? I haven't done much testing with duplicate wallets, so it's kind of: "use at your own risk". That said, the risks are mainly that it won't work, not that you'd lose coins. But last time I played with duplicate addresses, I seem to remember that it did work... Btw, the "Backup Individual Keys" dialog gives you a list of private keys. The "Import Multiple Keys" dialog was designed to import that list directly (among other formats). You can just cut-and-paste to a text file, and then close the dialog and open the import dialog. Copy them in and delete all the keys you don't want before importing. Just be aware that when you cut/copy text, it goes to the clipboard which is accessible from lots of different programs. There's not a good way to protect against that, but perhaps you just do it on the offline computer, bring the new watching-only wallet back, and then execute your offline transaction. It's a lot of work, but it's the best I can do right now. |
|
|
|
Found a bug...  Either your labels are swapped or my squirrel successfully created Yesterday Mail™ That is a bug! Not sure why that happened, though... Also, not sure how you got version 0.82.5... I had a lapse of version numbering judgment when creating a test-installer for wachtwood to help with network debugging. I guess I left that running on the "dev" branch. If you know how, I would suggest switching to the master branch (this goes for anyone else compiling from github). I'll look into what caused the version number issue... obviously that shouldn't happen! EDIT: looks like the same issue with 0.82.3... I just didn't notice because I had clicked on "Don't remind me again". Maybe I should reset my settings to default so that I find stupid things like this . It appears I didn't consider the case where I don't have version entries for the current version... I assumed you are either at the latest version, or behind. This should be an easy fix.EDIT2: Just fixed it in the master branch. I was doing a really dumb version comparison check. Now, it's much more intelligent! |
|
|
|
Completely random update about Armory because I was "bored" on a Sunday night (trying to figure out this multi-threading...) - (1) Armory has had a steady stream of 1,500 downloads per month for the last three months
- (1a) Many downloads might be duplicates -- users downloading for online and offline
- (1b) Many other users checkout the project from github and don't use the installers -- I don't know how many (probably offsets 1a a bit)
- (2) Using the "wc" command gives me a raw 37,000 newlines in all of code files I've written myself (*.py, *.cpp, *.h)
- (2a) Empty lines make up about 15% of that
- (2b) Comments make up about 20% of the remaining (yes, I write a lot of comments!)
- (3) My first commit to PyBtcEngine was July 11, 2011. So I have been working on Armory for 13.5 months
So: - It's probably fair to say Armory is getting at least 1,000 per month.
- So, I have written about 25,000 lines of executable code! (Approx 17k python, 8k C++)
And here's a random assortment of commit messages from the history that amuse me: - Endianness disaster averted
- Major Thunderstorm! Backup push!
- Another thunderstorm!
- Working engine without any known memory bugs!
- Got a useless GUI on screen
- DO NOT use list[:] to copy a SWIG vector<type>!
- Working donation button (most important feature!)
- 'ff'*32 is not a valid private key! Whoops! [I was using 'aa'*32 and 'bb'*32 for months, and then I use 'ff'*32 and Armory started crashing...hard. I wasted 2 days trying to figure out why seg faults started spontaneously occurring everywhere]
- I think zero-conf is fixed!
- I think zero-confirmation tx's are fixed!
- Almost fixed zero-conf (I know I keep saying that...)
- Okay, I think it's finally fixed! All ledgers correct!
- I swear, I think it's fixed now, 100%!
- Polishing... in the wrong branch... gah!
- Added extra bytes to sign/verify to prevent evil
- Nasty Merge: Probably broke everything...
- Crisis! Rescan on every new block?!? Fixing...
- FINALLY figured out the lpcwstr BS that all these windows.h functions use. Multi-byte, long-pointers, wide strings. WTF [seriously, windows.h blows]
- Fixed table sorting bugs! All of them!
- Destroying everything. Putting back together...
I hope you enjoyed this posting... EDIT: I should just start a blog |
|
|
|
Another question: Is it possible to choose inputs in Armory -- e.g. if I want to spend coins from a specific address?
I haven't implemented coin-selection yet, though it's on my list of things to do. There is demand for it, but I have some other priorities that need to happen first. Glad you are enjoying the program |
|
|
|
Unofficial Version 0.82.3I just committed two minor fixes (major for some) to the master branch. I'm not going to do an official release of it, because most users don't have a problem with it. Fixes: - URI handling: The new logging system broke another feature... complex "bitcoin:" URIs. Basic URIs were handled correctly, but anything requiring percent-encoding was failing. It's fixed.
- Rare networking issue: Wachtwood helped me track down a rare networking issue. He confirmed that it's fixed. If you have networking problems, use this version!
Armory 0.82.3 *.deb for 64-bit Linux
This seems to have worked! I'm new to hex editing so it took me a bit to figure out what to do. Some comments:
-The public key info seemed only about 10% into the file. Maybe I'm misunderstanding "The imported key will be at the end of the file"? After browsing around a bit I used a search to find it.
-There was an Address20 + Address20 + 4 so I changed both Address20's and then the 65 + 4. I used an online tool to do binary checksums.
Many thanks!
Wow. You are very resourceful I didn't expect you to dig into, and succeed, so quickly! All I was trying to say is that when you import a key, it will append it to the end of the wallet file. You should then be able to look at the binary map on the link I sent, and see exactly how many bytes offset from the end you need to seek to, to change the relevant fields. It seems you figured it out, anyway. P.S. - What do you use for editing binary files as hex?
|
|
|
|
|
Show Posts
