I was thinking more about the command-line signing. It will actually be super easy. I will come up with something more integrable later, but if you are running python on the offline computer and already have the wallet file and unsigned.tx file, you can make a short script like this. NOTE: I haven't tested the script, so it probably has a few bugs in it. I will test and update when I get home. Though, if you are feeling adventurous, you are welcome to try it out for me  I will edit this post when I iron it out. #! /usr/bin/python
import getpass
from sys import argv
import os
# Do not ever access the same wallet file from two different processes at the same time
raw_input('PLEASE CLOSE ARMORY BEFORE RUNNING THIS SCRIPT! (press enter to continue)')
if len(argv)<3:
print 'USAGE: %s <wallet file> <unsigned.tx file>' % argv[0]
exit(0)
if not os.path.exists(argv[1]):
print 'Wallet file was not found: %s' % argv[1]
if not os.path.exists(argv[2]):
print 'Transaction file was not found: %s' % argv[2]
wlt = PyBtcWallet().readWalletFile(argv[1])
# If the wallet is encrypted, get the passphrase
if wlt.useEncryption:
print 'Please enter your passphrase to unlock your wallet: '
passwd = SecureBinaryData(getpass.getpass())
while not wlt.verifyPassphrase(passwd):
print 'Passphrase was incorrect!'
passwd = SecureBinaryData(getpass.getpass())
wlt.unlock(securePassrphase=passwd)
passwd.destroy()
# Now read the txdp
txdp = PyTxDistProposal().unserializeAscii( open(argv[2],'r').read())
try:
wlt.signTxDistProposal(txdp)
except:
print 'Error signing transaction. Most likely this is not the correct wallet.'
raise
if not txdp.checkTxHasEnoughSignatures():
print 'Error signing transaction. Most likely this is not the correct wallet.'
exit(0)
outfile = open(argv[2].split('.')[:-2] + '.signed.tx', 'w')
outfile.write(txdp.serializeAscii)
outfile.close()
|
|
|
|
Thanks for the awesome instructions. Now I, too have Armory running on my Pi! I sent half a bitcoin to your donation address. etothepi, is it currently possible or would it difficult to implement command line transaction signing? For instance... $ python armoryengine.py --sign-tx test.unsigned.tx
Prompting for the encryption password if encrypted, and wallet ID if it can't determine that on its own. It could then either prompt to sign with information about the transaction, or just sign it and display that information. Otherwise I have to get a USB hub, because with mouse and keyboard plugged in to the Pi, I have no USB ports left for transferring the files on USB drive. That could probably be done. I already have a python script posted in the Armory on web servers thread about creating and signing transactions. It should be easy to modify it and use it for signing-only. You will have to supply the wallet file, too, since armoryengine doesn't auto-detect wallets (that's the GUI). But it's very doable. Eventually, I can add some kind of functionality like that. Is there a specific reason you link against the static python libs? On my Linux box (Arch Linux) only the dynamic libs are availble (*.so). I changed the Makefile to use the .so files and it seems to work so far.
It's because if I compile dynamically, the pre-compiled versions that I produce to distribute (the *.deb) only work on systems with the same python version as I used to compile it. If you remember, I used to have an armory_0.XX.X-alpha_python2.6.deb and _python2.7.deb. I solved that by static compiling. I have been meaning to add something to the Makefile to autodetect when you don't have the .a, and look for the .so instead. i.e. static compiling was done for me when producing the installers, but isn't necessary for those that are compiling it themselves. I'll see if I can fix that |
|
|
|
I tried to grab a ton of info from the USB key, with the write protect in both states.
idVendor 0x0b27 Ritek Corp.
idProduct 0x0165
Thank you very much. Ritek Corp. device 0x0165 is not on my shortlist of known fraudulent devices. (Fraudulent meaning: fake encryption plus maybe fake write protect and other misrepresentations.) I'm disappointed. I thought you were going to tell me how to override the write-protect. You've got me wondering how difficult it is to do it... On another note, I just ordered a male-male analog TRS cable (double-ended headphone jack). I determined that the audio coupling is now 100% perfect once you connect the headphone-out to mic-in with such a cable. The SNR should be fantastic, and if both sound cards sample at 44.1 kHz there's a lot of room to get at least 1 kB/s, which would make me happy. That's assuming that I can transmit and receive signal amplitude reliably. I don't have much experience with it, but I look forward to digging into it in the kind of near future. (I just ordered a couple double-ended audio headphone cables... whatever they are called...) The downside, is that if the user's online computer is their primary computer, they will be inconvenienced by having to swap their speakers around all the time. On the other hand, they can always get an extender, and keep both ends on their desktop, and just lean over and switch them when needed. Recommendations welcome! |
|
|
|
Crossposting this from the Armory thread:
Instead of explicitly defining the hardware layer, would it be possible to have Armory be agnostic about such things? I'm not sure how/if this would work in Windows, but I'm imagining that a *nix user could set up a device (/dev/foo) on each computer that when read from/written to would communicate with the other computer. Then in Armory, the user would just specify which device should be used for communication. The user would be liable for setting up the connection and making sure that connection was secure, and Armory would attempt to communicate with itself through that device, failing gracefully if unable.
I like the idea. I will think about how to do it, though I have little experience at the device level, but my guess is it's not terribly complicated. I might need to push-start on that, though. Can you post what "lsusb -v" says about your USB drives with write protect?
I tried to grab a ton of info from the USB key, with the write protect in both states. Here's the output of lsusb -v, and dmesg. It pretty much looks the same, except for the device number changing between inserts, and the frequent mention of "device is write-protected": Write Protection ON$ sudo mount /dev/sdc1 temp
mount: block device /dev/sdc1 is write-protected, mounting read-only
/dev/sdd1 on /media/disk-1 type vfat (ro,nosuid,nodev,uhelper=hal,shortname=mixed,uid=1000,utf8,umask=077,flush)
Bus 001 Device 011: ID 0b27:0165 Ritek Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0b27 Ritek Corp.
idProduct 0x0165
bcdDevice 1.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 98mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 8
$ dmesg | tail
[445341.912213] usb 1-3: new high speed USB device using ehci_hcd and address 12
[445342.050773] usb 1-3: configuration #1 chosen from 1 choice
[445342.053600] scsi12 : SCSI emulation for USB Mass Storage devices
[445342.054349] usb-storage: device found at 12
[445342.054353] usb-storage: waiting for device to settle before scanning
[445347.052579] usb-storage: device scan complete
[445347.053557] scsi 12:0:0:0: Direct-Access RiDATA 0.00 PQ: 0 ANSI: 2
[445347.057410] sd 12:0:0:0: [sdd] 7946240 512-byte hardware sectors: (4.06 GB/3.78 GiB)
[445347.076676] sd 12:0:0:0: [sdd] Write Protect is on
[445347.076685] sd 12:0:0:0: [sdd] Mode Sense: 0b 00 80 00
[445347.076691] sd 12:0:0:0: [sdd] Assuming drive cache: write through
[445347.090903] sd 12:0:0:0: [sdd] 7946240 512-byte hardware sectors: (4.06 GB/3.78 GiB)
[445347.091649] sd 12:0:0:0: [sdd] Write Protect is on
[445347.091656] sd 12:0:0:0: [sdd] Mode Sense: 0b 00 80 00
[445347.091661] sd 12:0:0:0: [sdd] Assuming drive cache: write through
[445347.091669] sdd: sdd1
[445347.200837] sd 12:0:0:0: [sdd] Attached SCSI removable disk
[445347.201066] sd 12:0:0:0: Attached scsi generic sg3 type 0
$ sudo mount /dev/sdd1 temp
<no output>
/dev/sdd1 on /media/disk-1 type vfat (rw,nosuid,nodev,uhelper=hal,shortname=mixed,uid=1000,utf8,umask=077,flush)
Bus 001 Device 010: ID 0b27:0165 Ritek Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0b27 Ritek Corp.
idProduct 0x0165
bcdDevice 1.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 98mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 8
$ dmesg | tail
[445812.757116] usb 1-3: new high speed USB device using ehci_hcd and address 13
[445812.890705] usb 1-3: configuration #1 chosen from 1 choice
[445812.891042] scsi13 : SCSI emulation for USB Mass Storage devices
[445812.891351] usb-storage: device found at 13
[445812.891356] usb-storage: waiting for device to settle before scanning
[445817.889043] usb-storage: device scan complete
[445817.889989] scsi 13:0:0:0: Direct-Access RiDATA 0.00 PQ: 0 ANSI: 2
[445817.893332] sd 13:0:0:0: [sdd] 7946240 512-byte hardware sectors: (4.06 GB/3.78 GiB)
[445817.915219] sd 13:0:0:0: [sdd] Write Protect is off
[445817.915228] sd 13:0:0:0: [sdd] Mode Sense: 00 00 00 00
[445817.915233] sd 13:0:0:0: [sdd] Assuming drive cache: write through
[445817.924567] sd 13:0:0:0: [sdd] 7946240 512-byte hardware sectors: (4.06 GB/3.78 GiB)
[445817.925423] sd 13:0:0:0: [sdd] Write Protect is off
[445817.925429] sd 13:0:0:0: [sdd] Mode Sense: 00 00 00 00
[445817.925435] sd 13:0:0:0: [sdd] Assuming drive cache: write through
[445817.925444] sdd: sdd1
[445818.034645] sd 13:0:0:0: [sdd] Attached SCSI removable disk
[445818.034875] sd 13:0:0:0: Attached scsi generic sg3 type 0
|
|
|
|
Quick question... I sent a transaction at roughly the same time my modem lost its connection, now it's sitting there in sent/unconfirmed status. Is there any way to force a transaction to be rebroadcast? That could be a useful advanced feature to have. Also, it just so happens the transaction in question was to address 1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv Ack! This is an unfortunate situation -- one I haven't figured out how to handle yet (gracefully) with Armory. The problem is that Armory sends the tx to Bitcoin-Qt, which then adds it to its memory pool and "forwards" it to all its peers. If that happens to be zero peers because connection is bad, then tough luck. The issue is that if Armory tries to re-send the tx, it sends it to the Satoshi client which says "Oh, I've already seen this" and drops it immediately without re-forwarding. So far, I haven't figured out a graceful way to get around this. No matter what Armory does, ibitcoind/-qt won't re-broadcast it. The non-graceful way is to restart Bitcoin-Qt (which should clear its memory pool), and stop Armory, delete armoryhomedir/mempool.bin and then restart Armory. Then try again. If you are familiar with the RPC interface to Bitcoin-Qt, I haven't tried the following, but I understand it should work: double-click on the transaction in the Armory ledger, and if you are in advanced or expert user mode, there should be a "Copy Raw Transaction" button at the bottom. You can copy this into the bitcoind/-qt RPC interface using "sendrawtransaction". I've never done it, but gmaxwell tells me that will always re-broadcast, even if the tx is already in the bitcoind/-qt memory pool. I really want to find a good way to resolve this issue, but I haven't found it yet... |
|
|
|
Well, okay. I don't want to get into another useless-or-amazing debate, but I imagine there's still some value in it. Both Linux and Windows refuse to mount in any way other than read-only. Maybe I'm a n00b. But, I just did some googling and didn't find anything, do it must not be trivial to do. Therefore, even if true hardware switches aren't 100% foolproof, it probably does it make the attacker's job much more complicated (and probably restricts it to the few people that know how to read the manual in whatever native language it's written in).
You aren't wrong. But you have to make a conscious choice whether you are trying to achieve security or security theater or cargo-cult security. I would advise you to use the means of communication between the machines that you are sure you can understand. I don't like USB flash drives because of awfull and non-obvious failure modes they create. I do like OSTA-UDF formatted CD-R / CD-RW / DVD-RAM. It makes many thing obvious, eg. that the data actually stays there after the deletion, how to completely destroy the data, documentation is in the open, there is an open-source UDF format checker, etc. The audio interface also looks like splendid idea for the near-field communication. You're right. I should focus on things I understand. Unfortunately, kernel modules and drivers are not my forte. And while USB isn't foolproof, it's something that regular users can understand, and requires a resourceful attacker to compromise (should do a good job of preventing attacks of opportunity, and require a targeted attack). Mainly because it requires analyzing the attack surface and automating a solution to run when it gets on the target system. Instead of being able to log in, dig around, and figure it out with a human-in-the-loop. The audio-coupling is looking interesting not only because there's no risk of remote code execution, but also because I'm a signal processing/statistics guy. I'm sure lots of people have already looked at this problem in general, but I think I'd have fun figuring out how to improve throughput of the audio channel. Unfortunately, there's plenty of other development for me do before I get to this, but I have some friends at work (who do signal processing with me) who might find this to be a wholly interesting problem to work on with me. |
|
|
|
Can you post what "lsusb -v" says about your USB drives with write protect?
Next time I'm at work, I will try this. I don't have any of the write-protected USB keys like we have at work. However, I noticed that just about every SD card has a switch built-into it, but the one I have in my camera doesn't work. I'll see if I can find another one and try it.. True hardware write protection doesn't really exist, and never has, outside of rare special hardware. It is always soft write protection.
Well, okay. I don't want to get into another useless-or-amazing debate, but I imagine there's still some value in it. Both Linux and Windows refuse to mount in any way other than read-only. Maybe I'm a n00b. But, I just did some googling and didn't find anything, do it must not be trivial to do. Therefore, even if true hardware switches aren't 100% foolproof, it probably does it make the attacker's job much more complicated (and probably restricts it to the few people that know how to read the manual in whatever native language it's written in). Unfortunately, I think it's still a little too clunky to have different transfer methods for each direction (not to mention the necessity to fiddle with the write-protect switch, which I've had break before from too much use). |
|
|
|
I described it quite explicitly in this post: https://bitcointalk.org/index.php?topic=106429.msg1168268#msg1168268In order for a transaction to be free, three conditions must be met:
--Transaction is less than 3.5 kB (approx)
--Transaction does not have any dust outputs (<0.01 BTC)
--Transaction inputs have priority-sum greater than 1 bitcoin-day-per-250-bytes
If the transaction cannot be free, then use the folllowing fee:
--If transaction is less than 3.5 kB, use fee 0.0005 BTC
--Otherwise, use (0.0005 * roundup(numkB))
There are more fees required to get it into the next block, if there's already a lot of transactions being included in the next block. But this fee will always get it included in one of the next blocks. So far, I haven't experienced any users (or myself) getting coins stuck in Armory. |
|
|
|
What were the drawbacks of RS232 again? The possibility of opening a terminal through the connection? I seem to remember that was fairly easily mitigated, but I can't find the thread now. I just ordered a Raspberry Pi (actually two, one from BitMit, one from Newark) to set up as an offline wallet storage box. Eventually I wanted to connect it to my main computer via RS232 and play with that idea.
That's basically it. You can say that it's easily mitigated, but it's a potential disaster if it's not. Take this for example: someone wants to do offline transactions, hearing that Armory is a super-secure way to do it. So they download Ubuntu, grab some RS232 hardware, and set everything up. The problem is they downloaded the wrong Ubuntu version, and it comes with drivers or modules that they weren't expecting. Or they're just oblivious anyway because they heard about how secure Armory is, what could go wrong? You might say: "Well, even if they get the login prompt, it would take a while for someone to figure out how to compromise it." I guarantee you that a large number of users (correlated with the same ones that do the previous part carelessly), their login and password for the offline computer and wallet will be one of the dozens of website logins&passwords they have saved in Firefox (Edit->Preferences->Security->Saved Passwords->Show Passwords). And the attacker probably got there because the user never changed their primary computer password after the same one they used at Mt. Gox got compromised last year. I don't mean to suggest that the RS232 link is useless. It's just something that I can't promote as a general solution because of the counter-risk associated with doing it incorrectly. Most of the other solutions proposed here, if you do it incorrectly, no one gets signatures from the offline computer, including the intended user. The wallet will remain secure, just inaccessible until they figure it out. As I've said in other posts: I end up with most of the blame when a compromise does happen, so while it's easy for others to say "ahh, careless users are not your problem"... well I disagree. I'd like to think that part of the reason Armory is successful is because I try really really hard to prevent newbies from shooting themselves in the foot (as evidenced by the endless warning dialogs and corner-case checking). |
|
|
|
I disagree with those articles on "air gaps". Trust me, I get it -- there's lots of ways for bad stuff to still compromise your air-gapped system. But the available attack vectors on such a network are so much more complex, you've wiped out 98%+ of the threats. Most importantly, you've removed threats to opportunity, as opposed to threats by determined attackers. You have to be targeted to be compromised, you're in much better shape than having some script kiddie stumble into your system because your mediocre IT guy forgot to re-enable the firewall/whatever after disabling it to SSH his MP3s from his home computer [insert other silly things that can go wrong]. I mean, it's worth recognizing that threats still exist with an air gap. But to brush it off as if it's useless is just someone begging for attention about how smart they are. And, by the way, there are USB keys with write-protect switches. We have to use them at work for exactly this reason. We disable write-protect to put data on it from the online computers, and enable it before plugging it into the sensitive computers. We are required to attempt to write data to the key from the sensitive system and receive an error, before removing the key. If the write succeeds for some reason, then we either destroy it or protect it the same as the sensitive systems. This could be useful for Armory, though in increases the CONOPs complexity a bit. But it works because the data you're moving from online to offline is the bulkiest (could be 100kb+, not quite right for QR codes). But the data that has to come back is only a couple hundred bytes. There's a lot more options for moving 100B vs 100kB (like audio-coupling). In another direction, can't someone recompile the kernel and a few of the programs like nautilus, to basically remove all the USB key risks? Basically turn it into a smart serial port? Maybe that's an oversimplification (and I'm sure 2112 will let me know just how much). But there's clearly a lot of stuff that goes on under the hood when you plug in a USB key, and I'm sure most of it is completely unnecessary if you know you are going to use the USB drive for exactly one purpose: to move a few kB of text back and forth. For instance, what would it take to modify/setup nautilus to just not do icons? I guess GDM would need to be modified, too? Skip the whole process of ever reading icons from files and just display a boring square. Don't process anything on the USB key, just mount it and let me copy files back and forth. It seems that such a modified system could solve a lot of solutions. It doesn't stop employees from bringing virus-laden porn onto their secure system, but at least you've removed one vital piece of the attack surface. |
|
|
|
This concept is clear and this are basic safety elements of a service. Still imagine a single person that has the single key to most mtgox bitcoins. if he goes nuts the whole network will loose faith in the system. Also building larger, more reliable project will be problematic if all funds can just disappear due to a "malfunction" of one individual. This will not happen in real world as there, transactions can be reverted. In the current bitcoin network it is not the case and any claim that a service is reliable is exaggerated due to human errors.
If we want to make the system more reliable we have to introduce additional safety. Having the option to require 3 signatures from 3 (out of 3+x) people to confirm a transaction enables me to setup a system where a single person will not take off with substantial amount of other peoples money. If there is one administrator, he can have an accident and forget the passphrase :-) ... it is pointless of course to give more examples ... You know all this. But to be able to build something like a bitcoin bank that can not just evaporate due to a glitch the network needs to provide mechanisms that give at least the option to add safety.
- fallback account is great ... provides tools to identify malicious attempts and tools to defend it
- independent multiparty sign off of transactions needed for special accounts is also some solution that I could live with
Of course one can try to decentralize large services like forex exchanges but it is difficult to decentralize the interfaces between bitcoin and the real world unless we convince banks to accept interactions with the bitcoin network.
We're in agreement. I'm just making sure you understand what tools exist, currently, for avoiding theft (as is the title of this thread). If I was managing a multi-million dollar cashflow, you'd be using combinations of things. 3 people, in different place, with three different offline wallets. Need 2-of-3 or 3-of-3 signatures to unlock any funds. And as D&T pointed out, this is part of the network already, it's just not entirely accessible yet. However, Armory provides a fairly convenient cold storage capability, and it won't be long before someone (Armory, too?) will get some useful multi-sig interfaces. Then these kinds of ideas can actually thrive. And many business owners still won't use them and will still lose people's money. But we can't force it on them... we can only offer them the right tools... |
|
|
|
There's plenty of theft-protection that is already available, and will be available if users are willing to put in the time to use it. It prevents theft in the first place, rather than recovering from successful theft.
(1) Cold storage (see my sig). Online threats become nil once you have your private keys offline, then only physical access can compromise the keys
but the service must be able to do the transaction automatically. Most online services will need some degree of automatic transactions, but that usually accounts for only a fraction of the total holdings of that company. Probably 90% of their funds can and should be kept in cold storage. Transferred manually when needed. Additionally, the business owner can keep the keys in a safe-deposit box or even at home. If the "hot wallet" is running low, he can manually refill it from cold storage when he goes home for the night. |
|
|
|
First time I see info in a sound file, that's a really nice idea
Aphex Twin (band) actually did this a while ago. I don't know if they pioneered it, but it is pretty cool: http://www.bastwood.com/?page_id=10 |
|
|
|
|
There's plenty of theft-protection that is already available, and will be available if users are willing to put in the time to use it. It prevents theft in the first place, rather than recovering from successful theft.
(1) Cold storage (see my sig). Online threats become nil once you have your private keys offline, then only physical access can compromise the keys
(2) Multi-sig: all funds can be setup to require 2 or 3 signatures, which can be kept in geographically separate places, or one of the keys can be based on a passphrase.
With both in place, only the select few that are supposed to have access will be able to use it. Cold-storage by itself is a 99% fantastic solution that many of these services are not leveraging, either enough, or at all.
|
|
|
|
The blog article you linked is old, but it is good discussion. There's definitely no more $80/yr special, it looks like $180/yr to get a signing certificate. It's probably worth swallowing my pride, and paying into the system and move on with life. After all, I did receive a lot of donations, I guess this is an appropriate thing to spend that on Why not specifically ask the windows-crowd to donate for that. They're used to paying for proprietary bloated shit. They should cough up the bill for using the crap. Sorry for the rant, this shit still gets to me. Meh, I've already received a ton of donations from a vast array of users, well in excess of the cost of the certificate. It's not only unnecessary to ask for it, it seems kind of beggar-y. Really, that was part of the original intent of the donations anyway -- not just to help me work less at my job, but cover related expenses. And this is purely a software project (no hardware), so I hardly have to spend money on anything else. So, while I won't turn down any donations, I don't need to solicit any. After all, I do still have a real job And now that you bring it up, maybe I should stop procrastinating and actually do it! I figure I'll do it at some point... |
|
|
|
I checked BouncyCastle/bitcoinj and AFAICT it's doing the right thing here. The R and S components are written out as BigInteger.toByteArray which will encode in twos-complement notation with a leading zero byte appended only if necessary. At least that's what it's supposed to do.
I'm sure you checked it, but does it produce smaller encodings if the integer values are smaller? Armory uses cryptopp which will spit out 32-byte (r,s) value pairs regardless. I have to manually trim the leading zero bytes. |
|
|
|
So does that mean that I need to check for leading zero bytes and remove them, in the case that the R or S values happen to be that small by chance?
Exactly. So R and S are not always supposed to be 32 or 33 bytes?
Certainly not, but fewer bytes becomes exponentially less probable. Well then, the fix I just committed to Armory master branch is wrong... |
|
|
|
It's certainly incorrectly padded (according to DER).
Neither R and S can start with a zero byte, unless the value would otherwise represent a negative value, in which case exactly one zero byte is required.
So does that mean that I need to check for leading zero bytes and remove them, in the case that the R or S values happen to be that small by chance? So R and S are not always supposed to be 32 or 33 bytes? |
|
|
|
Are you talking about the 5 hex zeros leading the R value? That's not incorrectly padded, is it? Aren't all R and S values supposed to be padded out to 32-bytes, or 33 only if it would be interpretted as negative? It is suspicious that the R value has such leading zeros, I just want to make sure I implement it correctly myself (if Armory (r,s) values are low, I still pad out to 32 bytes, right?). I suppose someone could keep signing their transaction over and over (with a different random k every time) until they get the leading zeros. It might take a while, though... |
|
|
|
|
They're probably all Armory signatures. It's a shortcut I took early on in armoryengine when creating transactions, and I left it because the network didn't seem to care. Now Armory is getting 1,500 downloads a month, and even if 10% of those downloads are producing transactions, you're bound to run into dozens of them. I'm surprised there aren't more...
On that note, I specifically remember mentioning it to roconner on IRC (or rather, he asked me about it), and was amazed when I told him that it works. Maybe he went and started doing it, too...? Heh, probably not. Just blame it on me, for now.
|
|
|
|
|
Show Posts
