I'm confused by what should be added/replaced. This is what my Makefile looks like: 25 SWIG_INC += -I"/usr/include/python$(PYVER)"
26 STATICPYTHON += "/usr/lib/python$(PYVER)/config/libpython$(PYVER).a"
27 else
28 SWIG_INC += -I"$(DEPSDIR)/include/python$(PYVER)"
29 STATICPYTHON += "$(DEPSDIR)/lib/libpython$(PYVER).a"
30
31
32 # A failed attempt at auto-detecting .a file and using .so if .a DNE
33 #PYTHONA = "$(DEPSDIR)/lib/libpython$(PYVER).a"
34 #ifeq ($(wildcard $(PYTHONA)),)
35 #STATICPYTHON += "$(DEPSDIR)/lib/libpython$(PYVER).so"
36 #else
37 #STATICPYTHON += "$(DEPSDIR)/lib/libpython$(PYVER).a"
38 #endif
39 endif
40
Can you give me a replace code with code for simplicty? Sorry. Modify line 29 at the end to .so instead .a |
|
|
|
No that's not it. It's a one-line makefile fix, but I needed someone who had this problem to help me test the fix for it. I'll commit something to the "armoryd" branch (which is my current development branch), in about 10 minutes. If that doesn't work, I'll just tell you how to fix it  Gah! Why's it so damned hard to check whether a file exists from within a makefile? I can't use my old bash trick because it's a dynamic filename based on DEPSDIR. The solution is to change "STATICPYTHON" to point to the libpython2.x.so file instead of the libpython2.x.a. I want something like (Makefile:28) -- SWIG_INC += -I"$(DEPSDIR)/include/python$(PYVER)"
STATICPYTHON += "$(DEPSDIR)/lib/libpython$(PYVER).a"
ifneq (exists, $(shell [ -d $(STATICPYTHON) ] && echo exists ))
STATICPYTHON = "$(DEPSDIR)/lib/libpython$(PYVER).so"
endif
But it doesn't seem to like the $(VAR) inside the shell... You know the fix. If you know a good way to resolve this, then please let me know. |
|
|
|
Fedora 64 bit make command gives me this error. I know this issue was addressed by mac osx builds, but was it ever addressed for linux builds? $ make
cd cppForSwig; make swig
make[1]: Entering directory `/home/seth/BitcoinArmory/cppForSwig'
g++ -shared -lpthread UniversalTimer.o BinaryData.o FileDataPtr.o BtcUtils.o BlockObj.o BlockUtils.o EncryptionUtils.o libcryptopp.a "/usr/lib/libpython`python -c 'import sys; print str(sys.version_info[0]) + "." + str(sys.version_info[1])'`.a" CppBlockUtils_wrap.o -o ../_CppBlockUtils.so
g++: error: /usr/lib/libpython2.7.a: No such file or directory
make[1]: *** [swig] Error 1
make[1]: Leaving directory `/home/seth/BitcoinArmory/cppForSwig'
make: *** [all] Error 2
install python? No that's not it. It's a one-line makefile fix, but I needed someone who had this problem to help me test the fix for it. I'll commit something to the "armoryd" branch (which is my current development branch), in about 10 minutes. If that doesn't work, I'll just tell you how to fix it |
|
|
|
I was thinking rather than use a Merkle tree at each trie node for verifying the presence of a child, we could use a bitwise trie instead, since it would have faster updates due to always being balanced and not having to sort. This would also speed up lookups, since we wouldn't have to traverse through a linked list of pointers at each node.
But then we've just arrived in a roundabout sort of way at the whole trie being essentially a bitwise trie, since the nodes in the original trie with 256 bit keysize overlap exactly with subtries of the bitwise trie.
Was there a reason for not proposing a single bit keysize from the start? I thought about it a while back, but disregarded it for some reason I can't recall.
I thought about the same thing, and disregarded it for some reason, as well. I don't remember though. Though, working with raw bits is a bit more complicated than bytes, especially when you have skip strings that are like 13 bits. But I see the benefit that you don't even really need linked lists at each node, only two pointers. But you end up with a lot more total overhead, since you have the trienode overhead for so many more nodes... I'll have to think about this one. I think there is clearly a benefit to a higher branching factor: if you consider a 2^32-way Trie, there is a single root node and just N trienodes -- one for each entry (so it's really just a lookup table, and lookup is fast). If you have a 2-way (bitwise) Trie, you still have N leaf nodes, but you have a ton of other intermediate nodes and all the data that comes with them. And a lot more pointers and "hops" between nodes to get to your lefa. It leads me to believe that you want a higher branching factor, but you need to balance against the fact that the branching adds some efficiency (i.e. in the case of using linked lists between entries, it would obviously be bad to have a branching factor of 2**32). |
|
|
|
I can't believe I posted in the wrong thread! A couple days ago, I observed a pretty large, successful, double spend against SD (25 BTC). Please see my post in the statistics thread. I have raw data if anyone wants to analyze it. It is not related to the vulnerability retep posted. But it does look like a miner may have helped them. tl;dr: The original bet, B, was made using an input from transaction A. A was 7 kB and had 43 inputs. I don't know what the transaction fee was (but I all zero-conf tx I received that entire day with timestamps, so all this information could be reconstructed... I can make it available to anyone who wants to dig into it). Transaction A never made it past zero-conf, and was replaced by a block with transaction A'. Thus, bet B was invalidated. The curious part is that A' was 14 kB, with 83 inputs, and paid zero fee!. 14kB is clearly over the allowFree limit, thus it would only be accepted (even without a conflicting tx in the memory pool) by a miner with non-standard rules. Now given that there was a public, conflicting transaction... hmmm |
|
|
|
Anyone still having persistent crashing problems in Windows? (or Linux?)I finally fixed the two readBlkFileUpdate() bugs. I made an elaborate test by taking slices of blk files, and copying them into a fake blkfile directory between readBlkFileUpdate calls. In the end it was a tiny fix, but it should've resolved a variety of issues -- I'm hoping also the Windows crashing issue... I created a testing version with the fix and even took it to the offline system to get signatures on the sha256 hashes. As usual, if you are testing in Linux, just switch to the "testing" branch. Testing version 0.87.1-testing for Windows 64-bitTesting version 0.87.1-testing for Windows 32- and 64-bitTesting version 0.87.1-testing SHA256 hashes of installersI've had Windows crashing before, but it has sometimes taken days between crashes, so I need someone who has more-frequent crashes to help test it. I'd say there's a 50-50 chance it's fixed... but if not I have another idea...
|
|
|
|
edit3: I had a crack at getting the listtransactions data for the various scenarios you describe (and thus the 'way it works'), however I couldn't get any results. Frustratingly, I got raw transactions to sign (which is the second-last step of many) and then the last step is to broadcast the transaction, but my transactions were always getting rejected. I've got my progress thus far well documented and is definitely repeatable so I might try to work it out later in the week. It's worth asking on the development subform for clarification on the way the listtransactions call works, they will hopefully be able to answer it. Anyway I was creating raw transactions to match your scenarios based off this guide and testnet-in-a-box - https://people.xiph.org/~greg/signdemo.txtI'm not sure I understand what you tried. Were you trying to test creating unsigned transactions and then sign and broadcast with Armory? Here's what I would do to test (and maybe this is what you did): open ArmoryQt.py, create a new wallet, send it some money (testnet would be fine). Create watching-only copy and save it in a different directory. Now run armoryd.py on that wallet, and use the "sendtransaction" or "sendmany" to create the unsigned transaction. Then you can go back to ArmoryQt and use the "Offline Transactions" button and select "Sign and/or Broadcast". You can copy it into the window* and it should immediately recognize it, and allow you to examine and sign it. Since you're online, you can also broadcast it right away, but I'm not sure why I didn't try that. I got through signing with my testnet wallet while testing, and everything looked perfect, up to that point. Also, I will integrate the cli_sign_script.py code into armoryd.py so that signing can be enabled, too. My only question is how to send the passphrase to JSON-RPC... is it sent cleartext over the socket/JSON interface? I looked at the Bitcoin code, and it appears that's what they do, though I'm not positive. This seems okay for localhost (though I don't like it), but not for any remote connections. Or maybe it just shouldn't be allowed on remote connections (actually, for now there are no remote connections, so I guess it doesn't matter). *What I found is that if you use armoyd to send the command, it spits out the python-formatted string: you cannot just copy this into ArmoryQt, because it has "\n" raw characters in there, etc. You can open python and type "pring <copy string here>" and it will print it out with proper formatting. Then you can copy it into ArmoryQt. |
|
|
|
I would have thought there's away to convert those floats to the correct decimal values, although maybe that was just a client... I'll look into it tonight cause those floats are horrid! Also I'll look at bitcoind listtransactions output if I get a chance.
Sounds like it's going well so far for the most part.
The problem is that those values should be transferred as either long-integer (satoshis) or string... in which case the value can be coded exactly. But someone decided that they'll have bitcoind should transfer them as non-exact floating point (doubles), and 0.0005000000001 for the fee is the closest float that can be encoded. I'm fairly confident it's really just a display issue, not an armoryd.py issue. Luckily, round()'ing will always work because doubles have enough bits to represent 8 places without rounding errors. But I wouldn't mind if we can find a way to have the json library print out the rounded version. I noticed in the few lines of code I stole from jgarzik (and now part of armoryd.py), he defined a "UniversalEncoder" and was able to pass it to the json.dumps() method to explain how to handle decimal.Decimal objects. Though I mostly removed that in favor of following Proper money handling in JSON-RPC, even though it should all give the same answers (it's less characters and more readable). Either way, maybe there's a hint there about how to tell UniversalEncoder to print "float" values. Anyone think it's a bad/good idea to do what I recommended: "python armoryd.py setamountencoding COIN" or "python armoryd.py setamountencoding STRING" to set the daemon to transfer long-int-satoshis or exact strings, respectively? That way default behavior matches bitcoind that most are expecting, but they have the option to change it with one line at the top of their script. ----- By the way (mostly for mav), I added the capability for armoryd.py to detect if there's already an instance of armoryd.py running, and if there is, it will connect to it, pass the command line arguments to it, print the reply, then disconnect. I believe that's exactly what bitcoind does. Also for anyone who wants to use this, you need to have a "/home/username/.armory/armoryd.conf" file or "C:\Users\username\AppData\Roaming\Armory\armoryd.conf" in order to use it. The file contains a single line: "username:password". Make sure to "chmod 600 armoryd.conf" |
|
|
|
I implemented a crappy version of listtransactions that probably doesn't behave much like the bitcoind version, but it is just as confusing (so at least there's something in common). For each incoming transaction it gives one entry per txOut you own. For each outgoing transaction, it gives one entry for the total output value (i.e. for your own contributions minus change) and one entry for each non-change receiving address (which can be sending or receiving depending on whose/howmany outputs there are). I'm sure people will try to use it and complain. Then I'll fix it to match what they were expecting... However, I added my own version of listtransactions called " getledger" and " getledgersimple". It has one entry per transaction and is a pure partition of your wallet activity. For each transaction "getledgersimple" returns: - "direction" is {'send', 'receive', 'toself'}. To self is any tx for which you own all inputs and outputs.
- "amount" is the total BTC exchanged (inputs - outputs + change + fee)). It is always positive. For example, if I send someone 10 BTC with 0.05 BTC fee and 5 BTC change to myself, "amount is 10". For to-self tx, change address is assumed to the be the address with the higher generation order (since the wallets always generate change addr after recipients are selected)
- "netdiff" is the change in your wallet balance induced by the transaction. For the above transaction, netdiff would be -10.05. If you send money to yourself, netdiff will be the negative of the fee paid. Summing all returned "netdiff" values returned will give you your wallet balance
- "fee" is the fee paid for the transaction. It is always positive, and the caller only has to pay attention to it on outgoing tx if they want (and make it negative). Or they may want to know how much fee was paid to determine how safe an incoming tx is. (returns zero in bitcoind for incoming transactions)
- "txsize" is size in bytes of the tx (included for same reason as fee)
- "firstrecip" is the first "target" of the transaction. For simple transactions this is your own address for incoming tx, or the other person's address for outgoing tx
- "changerecip" is the first address that may reasonably be interpretted as change. Someone sending you money as part of a multi-output tx, this will return the first output address that isn't yours. Or if the transaction is outgoing, it's the first txout with address in your wallet.
For each transaction "getledger" returns the same as the simple one, but with the following additional output. This accommodates users that want to handle more-complex, multi-recipient transactions and kind of just want all the information: - "senderme": list of all [address,value] pairs on the input side that are part of this wallet
- "senderother" list of all [address,value] pairs on the input side that are not part of this wallet
- "recipme": list of all [address,value] pairs on the output side that are part of this wallet
- "recipother" list of all [address,value] pairs on the output side that are not part of this wallet
mav originally setup the thing to handle watching-only wallets only. I will eventually upgrade it to work on any wallet, and maybe even multiwallet. But for now it's actually starting to have usefulness, and I'll hold off digging into too many more calls until I get some feedback. For now, I want to dig into fixing the instability issues I referred to earlier with blocksplits and simultaneous blocks. P.S. -- This is all on the armoryd branch, and you must have a armoryd.conf file in your Armory home dir specifying "username:password", then use that in the URL for the connecting client.
Example of simple and nonsimple getledger calls: getledgersimple$ python armoryd.py --testnet getledgersimple
[
{
"amount": 10.0,
"blockhash": "00000000067a1fb9e9634cf2b39f1728392882475c7fcda32db30724584707b6",
"blocktime": 1357795104,
"changerecip": "mqMK7xSkrNK5auTzHEJBndtxJiRZW6HMHK",
"comment": "",
"direction": "received",
"fee": 0.00050000000000000001,
"firstrecip": "mreAZm1osfLWZTKMcaAaQuUqZW59Ysikr5",
"netdiff": 10.0,
"txid": "e6582b82cf24888a86aee8b819a8e32f34033f2870d399dd0bcc1b9331331370",
"txsize": 292,
"txtime": 1357795104
},
{
"amount": 0.25,
"blockhash": "000000004a769f6db14bdff5374ce3790d756d4f49770a0f2203087133d3ec3a",
"blocktime": 1358106188,
"changerecip": "mzDVubTfVQGfxncSSajjxaRYttXfGJrWdQ",
"comment": "",
"direction": "sent",
"fee": 0.00050000000000000001,
"firstrecip": "n1NWE4QPX7FbxeBQaPhbr6rEwvHR1RjBWT",
"netdiff": -0.2505,
"txid": "747f357c8287da26fcd423e45974e2e1ba367216f0115d15eb2cdd66c4abc767",
"txsize": 258,
"txtime": 1358106188
},
{
"amount": 13.5,
"blockhash": "00000000db486e1907269bdff3fd0b62b1a8c7c51f214e89e57650403922bab9",
"blocktime": 1358113003,
"changerecip": "n1Q3DWs7pH5uvME4o3rDYDTd4ZgiqSPCUx",
"comment": "",
"direction": "toself",
"fee": 0.00050000000000000001,
"firstrecip": "mgdsaZL9WKbKrfxGRw8Rpi9FdRuaMMyyYJ",
"netdiff": -0.00050000000000000001,
"txid": "f53bdc6f3a1b573d2efa892591140caf5c88739c42248efdacfb0fd97da4287b",
"txsize": 618,
"txtime": 1358113003
}
]
{
"amount": 10.0,
"blockhash": "00000000067a1fb9e9634cf2b39f1728392882475c7fcda32db30724584707b6",
"blocktime": 1357795104,
"changerecip": "mqMK7xSkrNK5auTzHEJBndtxJiRZW6HMHK",
"comment": "",
"direction": "received",
"fee": 0.00050000000000000001,
"firstrecip": "mreAZm1osfLWZTKMcaAaQuUqZW59Ysikr5",
"netdiff": 10.0,
"recipme": [
{
"address": "mreAZm1osfLWZTKMcaAaQuUqZW59Ysikr5",
"amount": 10.0
}
],
"recipother": [
{
"address": "mqMK7xSkrNK5auTzHEJBndtxJiRZW6HMHK",
"amount": 14.499499999999999
},
{
"address": "mi6hyHi3zVPx8sgB6wuf6cKkXPswa5NFDf",
"amount": 0.5
}
],
"senderme": [],
"senderother": [
{
"address": "mqy7NzHrcFLu32YK1ow6L4V2YC4PFCChHB",
"amount": 25.0
}
],
"txid": "e6582b82cf24888a86aee8b819a8e32f34033f2870d399dd0bcc1b9331331370",
"txsize": 292,
"txtime": 1357795104
},
{
"amount": 0.25,
"blockhash": "000000004a769f6db14bdff5374ce3790d756d4f49770a0f2203087133d3ec3a",
"blocktime": 1358106188,
"changerecip": "mzDVubTfVQGfxncSSajjxaRYttXfGJrWdQ",
"comment": "",
"direction": "sent",
"fee": 0.00050000000000000001,
"firstrecip": "n1NWE4QPX7FbxeBQaPhbr6rEwvHR1RjBWT",
"netdiff": -0.2505,
"recipme": [
{
"address": "mzDVubTfVQGfxncSSajjxaRYttXfGJrWdQ",
"amount": 9.7494999999999994
}
],
"recipother": [
{
"address": "n1NWE4QPX7FbxeBQaPhbr6rEwvHR1RjBWT",
"amount": 0.25
}
],
"senderme": [
{
"address": "mreAZm1osfLWZTKMcaAaQuUqZW59Ysikr5",
"amount": 10.0
}
],
"senderother": [],
"txid": "747f357c8287da26fcd423e45974e2e1ba367216f0115d15eb2cdd66c4abc767",
"txsize": 258,
"txtime": 1358106188
},
{
"amount": 13.5,
"blockhash": "00000000db486e1907269bdff3fd0b62b1a8c7c51f214e89e57650403922bab9",
"blocktime": 1358113003,
"changerecip": "n1Q3DWs7pH5uvME4o3rDYDTd4ZgiqSPCUx",
"comment": "",
"direction": "toself",
"fee": 0.00050000000000000001,
"firstrecip": "mgdsaZL9WKbKrfxGRw8Rpi9FdRuaMMyyYJ",
"netdiff": -0.00050000000000000001,
"recipme": [
{
"address": "n1Q3DWs7pH5uvME4o3rDYDTd4ZgiqSPCUx",
"amount": 1.7490000000000001
},
{
"address": "mgdsaZL9WKbKrfxGRw8Rpi9FdRuaMMyyYJ",
"amount": 13.5
}
],
"recipother": [],
"senderme": [
{
"address": "mzDVubTfVQGfxncSSajjxaRYttXfGJrWdQ",
"amount": 9.7494999999999994
},
{
"address": "n34NnSRwMTUaHnx4R5ykmcjecoDn8uVXUA",
"amount": 3.25
},
{
"address": "n34NnSRwMTUaHnx4R5ykmcjecoDn8uVXUA",
"amount": 2.25
}
],
"senderother": [],
"txid": "f53bdc6f3a1b573d2efa892591140caf5c88739c42248efdacfb0fd97da4287b",
"txsize": 618,
"txtime": 1358113003
}
]
P.S -- As far as I can tell, the ultra-high-precision values/amounts are due to the python-JSON library display. It's a display issue caused by the fact that someone a long time ago decided the JSON interface should transport floats for amounts, instead of strings or satoshis, and the JSON library just prints the raw floats. Luckily, double-precision values have enough precision that this will never screw up from a simple round() call. But clearly, this is sub-optimal. And since I'm using a built-in json.dumps call in python, I can't really modify the behavior. I'm thinking I could add a "setamtcoding COIN" or "setamtcoding STRING" to tell the RPC server to always encode values as longs (in Satoshis) or string values with at most 8 decimal places. I could also make the last argument to every RPC call be "COIN" or "STRING" to tell the server what to output for that particular call. But that seems kind of messy. |
|
|
|
Someone's been getting creative! I just saw a zero-conf reversal/double-spend on SD for a 25.6 BTC around 4pm today! Who wants to come clean? Honestly, I don't have time to dig into to it too much right now, but I can post the info I do have: Transaction A gave 13.268 BTC as an input to Transaction B that send 25.6 BTC to SD. Transaction A was "reversed" (by tx A'), which caused Transaction/Bet B to be invalidated as well. Transaction A was about 7 kB with 43 inputs, was replaced by A' which is a zero-fee 14kB transaction with 83 inputs?!? I haven't dug into the receive times yet, but I do have the raw tx data to share: (P.S. -- I have a ton of raw data, including broadcast-received time... let me know if you want)
Transaction A (was replaced which led to bet B becoming invalid) Tx Hash: 28c9d1308eb998621b798998d74f26fba6f4df8f978e25b712b09ff8f4c7c54b (you won't find it on blockchain.info or blockexplorer because it was never part of any block) Transaction:
TxHash: 28c9d1308eb998621b798998d74f26fba6f4df8f978e25b712b09ff8f4c7c54b (BE)
Version: 1
nInputs: 43
nOutputs: 1
LockTime: 0
Inputs:
PyTxIn:
PrevTxHash: 77ba3bfe72bb25c4b83813ddaf47e1673151ab2d91717eb0ccda5f26bdaf9b67 (BE)
TxOutIndex: 0
Script: (48304502200af08c0fe70da4faac0aab9e45f5116de8470588c30709521326db)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: fd89830300d6eeae9edb44a173ff48fb9d56dc56836234e3672434e7eefb141e (BE)
TxOutIndex: 1
Script: (47304402206940447107aad4cc534d1adace5a8a49ce192d6e73c7af3c4368cd)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: c23e376fa065f6d61a1ef8ec6531270bb6e8e3addde4964a492444db31d2fa84 (BE)
TxOutIndex: 0
Script: (483045022100d7564b1c867c2101ccdae79d92dcc7fdd277e44289e58e005146)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 95912fb3bdd9d3044ac660101bb6132117fc2518450771fceac4905641850ae5 (BE)
TxOutIndex: 1
Script: (483045022041a56080ed54bf1c51247425a2a9453e5228a85628012756e314e3)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 3069de42f3948f4b3b103055334e2b24ae762bd2d2c25a2fd35e2b2ead531b17 (BE)
TxOutIndex: 0
Script: (493046022100d53d8d4ad6bb51488b0b3be6ac046e2c53bd0571bb0de3ff5b2a)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 5a6c10457e5c68504a7957aa47e406a373ef79022550e1534a6ab447b7f9e1d7 (BE)
TxOutIndex: 1
Script: (493046022100c6aeb590b4c75da5768944c63358f821c03940521d3744c71cbe)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 9ac3420e432298fbfa4ace9aab750aeb724209e053132519a1a36a9dfc08e427 (BE)
TxOutIndex: 0
Script: (4730440220606fb0e71f1f02e26b8d1d700a4048fd1172e59f85fbff1d40441a)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 01757c52d181dbfb125ab34448ec50aadcd6e095f207909452005392319fa911 (BE)
TxOutIndex: 1
Script: (473044022026e17f05c603bce1735495613ce4cbc87329d6977b803331e507b4)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 5c1e8de39ab2c2048503f5907aed9a81fa87913256ab437bd5d997d082d04a9f (BE)
TxOutIndex: 0
Script: (47304402206b74cb894808b06263bda99a79b3801b584ab31e15e25b470da3bf)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 2900feaf2e8d05abd262e4319f49e0bce31b8606a4b958292e2eb52a71550434 (BE)
TxOutIndex: 1
Script: (473044022056d6093711dbf073982913935a88d4f11e03ce23eed86ed5997324)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 77a472976ee0a3b768f3f4b7a38c5dd645d39c1a7775f4654360521ea76d935b (BE)
TxOutIndex: 0
Script: (493046022100b6fa9ea373b50a0e9bb2d6835bcc33a7e894f322bf599e0761cf)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: b0aa145c1304c5df4d39fcf46c2ed1152cd906492dbde62eb9d01c499d3fc648 (BE)
TxOutIndex: 1
Script: (483045022100c46bdee8b4d333c98c5513233cc07c386765f9ae005376b5801e)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 76472692e02a240f0be34c3cc3d1057589cf47941d982e55a6c69447d1a96467 (BE)
TxOutIndex: 0
Script: (493046022100df136ebb464e0568cd7438257de7869d3d7a7ba604b12635b0c0)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 7c5cef6bc4da2c96ea31792a7beab840b32418abdf57a200db003e14e581e060 (BE)
TxOutIndex: 1
Script: (4930460221009492baa3c5db99e4586fc993996bac7e78c8b5aa7692848567ee)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: e70abb60f69bf1a05627755318b6ca2ba030dfbcae0acc218807fcc832903305 (BE)
TxOutIndex: 1
Script: (483045022100e93f68b4b1d6ae473e6c098e6dfe0875e2dcacb08f8985eebbb2)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: df7ec1450d9879f5aae1486e7da5e6a975c123306ad4e1436c6784a28d2888a5 (BE)
TxOutIndex: 0
Script: (483045022100940eef7745b165f325926051507990a96cfa2e6cd97dff2a5c23)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: d3c539003b40239379ae1113794fa4e466d2fba5dd8ae03501027c63c83de4fe (BE)
TxOutIndex: 1
Script: (483045022056bba747157feec762d84228a07f8c9139e12ddfbb8e6186778ca5)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 2123b6674e86b1bf69baba082936f2883543599c6687c23cdef9c31b662e1893 (BE)
TxOutIndex: 0
Script: (493046022100c1f8cefe037aa5197ff113238e40644f2daee98cf212ce08b667)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 36505e7b6265cef77d8599bff1dae7459feeb5cdd4b9ae80e59c518e90bbbb3b (BE)
TxOutIndex: 1
Script: (483045022002c386d6b597a06be7bf9ba08bb357a696b6ce0b50e3f32e48b881)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: c37ed4e171999f2edc2dd6704c214142f033bbac04af5e60e4d093b0c50b68cf (BE)
TxOutIndex: 1
Script: (483045022100fbc2a50069885b2bceb9c3edae1256591c856cfc689c00b27464)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: bc50e71d6db284901f0058b630b9f20a3691461b48b8d95453b6fa3cf46637cd (BE)
TxOutIndex: 1
Script: (483045022100ed19932130150df9126c5f7db716a04682e0167e14f25f669868)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 7e563551914b67331f1abdb4f33b1a4308d958c7d1b0afff8a293c86ddd4e684 (BE)
TxOutIndex: 0
Script: (483045022002d03b1399f60fcbef14a939d74e00ee79fefc378567f6a6567a8d)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: dd6f1617dc4b64a730f3a9c416784164ae766f784aa2044eea6a27b24b8c04b7 (BE)
TxOutIndex: 1
Script: (483045022012050638122feae8460ccbda44252709c0425a6c70a95d2ba383b8)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: f3d3abe1a517e036f4c8ba506abbc0b61cd098d15d5df599ad39af9134d9d30e (BE)
TxOutIndex: 0
Script: (47304402207f5ed54f407506f77c3943988acd0265456ae4df2096a16a6e0061)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: a3119c864e9867f930912a3ae50075f5c354c7cb846b1c1e919a90362e69b7b9 (BE)
TxOutIndex: 1
Script: (4930460221009b5b4a9023d610d5ffbb98df7e0d8d7e91c6360eb32dd6939329)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: ba5a607c877faba2792f7a12f7793cac5a0c3f7aedac7b1daa1f3df9ea0e705c (BE)
TxOutIndex: 0
Script: (4830450220328671de141da7e4ae5309344d6227b54c3baf91a647a1639e2413)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 71d9bc6d6c31eb7bcd6643f06644591ee8da304eec7349b4e0e4ad255a080d28 (BE)
TxOutIndex: 0
Script: (483045022100df3c700290d1d654d457f1dd399283b8030db55c9a9b4dce7820)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 4e480d4b20be3527bd5e3e0dff6f74b0d0d5f3af200af8e8dc9422d3264ac5b4 (BE)
TxOutIndex: 1
Script: (4830450221009e238b31beedf119a1c00ceae95e86ace880b4a23cadb34eb9f1)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: d2a840434a6f7ed0a2fda3764d28f765ba4ddbc8dbc45ae0fff308315c99ebf3 (BE)
TxOutIndex: 0
Script: (483045022100b4533aa8c4b5ef7bbfa6398a061a2443529fdeb25bbea649b3db)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 0b7adee00ebe4f60995d28ca7aadc4ab87c4865c34e448ca631de50c391d3264 (BE)
TxOutIndex: 1
Script: (483045022100c82576cda49d284810c60e9885399fe17203fdc0c13606645f81)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 12c6947940a2bc17b3756350a1b70e1225edeed85f82f986677540947e7bf65c (BE)
TxOutIndex: 0
Script: (493046022100c04b7efce276bd52d75ba7d845409d3e2364b8228a2c2d3f77eb)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 8174c3b8d531a638587aa5131f53e9d11dcb24ad8a00fd74b74afac6e1394b94 (BE)
TxOutIndex: 1
Script: (483045022034ffa7d323da3827c9f11d32baf52a7021f4e3adec76ed066061d4)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 00133cf21990d2923b56e002e3c1e33661ccedeb0ef1fb8bf6c7ab715b6c52a1 (BE)
TxOutIndex: 0
Script: (473044022032f0afc98ceed00f6160ff96143fcd50bbb7ff12bd858832bd1e37)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: efec84bfa3f4bdebdc88c425fb26f8887cad2a49c48de1e82c9ed0969bf1bcb3 (BE)
TxOutIndex: 0
Script: (48304502207e503b192f6fb034ed57383f3fb9b6b7500d54b89dade4a30a1176)
Sender: 1BWT3RqzmbpmyxGMHb5Sg2SNijJkFZUTYK
Seq: 4294967295
PyTxIn:
PrevTxHash: 915563faffe645062e98ec209e7d53e0dd88dece3b4dca8ce3ac70c5db119389 (BE)
TxOutIndex: 1
Script: (493046022100be524466e739e76adc0694f5f7cbd1ad334caf0858726fe6b4e7)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 73a84945652324b1c267ff3a1ccf1e09c2273995e2657fe89d552f6b64c27fc7 (BE)
TxOutIndex: 0
Script: (48304502202111bd16798cac9b19b27d683dcecbaa99d135d3f612cfa912ac54)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: 29e4c13b41e718265d4fc1faa54ff659a137f8f66bae1abb8fd523dab6e82db3 (BE)
TxOutIndex: 1
Script: (4830450220547b9a718adb0ec03ea2f4a893791ba8ffc6ce4490a4faa9717ef7)
Sender: 1BWT3RqzmbpmyxGMHb5Sg2SNijJkFZUTYK
Seq: 4294967295
PyTxIn:
PrevTxHash: 91cceea99bc146d3a21029d7ca49436e1ca848dbeeddf7d82b7cd432888d0b38 (BE)
TxOutIndex: 0
Script: (483045022053f995f8d6bb032440449158c7e1cac6695849d9a9f3b65bebdedd)
Sender: 1BWT3RqzmbpmyxGMHb5Sg2SNijJkFZUTYK
Seq: 4294967295
PyTxIn:
PrevTxHash: 596d70bd2a86726fd9612a33ee0368cc64d8f8bc0902399eec8632c5c4cacfb7 (BE)
TxOutIndex: 1
Script: (49304602210084656cbd0bbebd5fbc0fcb7f36e5d110916443165ff8d69beec3)
Sender: 1P7Xd4vqEMbYDnFbzroeUVSAwpoAhZkzNX
Seq: 4294967295
PyTxIn:
PrevTxHash: 780df928d6534f85a912ddc3d4985b04e18fb7414023c79a6ad5b79babf38c3c (BE)
TxOutIndex: 1
Script: (47304402202487700eb30a87b7773e48b059410f1752e135cb45cc095100070b)
Sender: 1BWT3RqzmbpmyxGMHb5Sg2SNijJkFZUTYK
Seq: 4294967295
PyTxIn:
PrevTxHash: 078cb9f0deaca6634a6635c1f0d66c0c140462b9e2638c7bdeef7b9f485e39ae (BE)
TxOutIndex: 1
Script: (473044022041b54da125192706cd91a52c59728c54852f66cdba17e74efc71da)
Sender: 1P7Xd4vqEMbYDnFbzroeUVSAwpoAhZkzNX
Seq: 4294967295
PyTxIn:
PrevTxHash: ebee78b0e9c2161e1fa46426d9c8d30a35081fce9f44883035b95839623228a0 (BE)
TxOutIndex: 1
Script: (4830450221009b4afa5f81219a1e1993fb45d419457fe88bdd4f7da8e4444c78)
Sender: 1L9HDTjYyBE2PKpz5ycbE8HATBdoCYgn83
Seq: 4294967295
PyTxIn:
PrevTxHash: d4f5f5bf0c794a4eb561be6c542a704b121893286fc4f03bd73da0cea09b5088 (BE)
TxOutIndex: 0
Script: (48304502210083d253e14bf41c6aa8c019a2d88087c15623c600b6dea2a04b0b)
Sender: 1BWT3RqzmbpmyxGMHb5Sg2SNijJkFZUTYK
Seq: 4294967295
Outputs:
TxOut:
Value: 1326869240 ( 13.2686924 )
Script: OP_DUP OP_HASH (1Pie7ZujioasX61UwtbGJdxXHyPjgcnkPZ) OP_EQUAL OP_CHECKSIG
Transaction A' (which replaced A) Tx Hash: 04d7d2795ec9f473d74f414f15f35f19107bc1626c40a4095319a8336d84a188 Transaction:
TxHash: 04d7d2795ec9f473d74f414f15f35f19107bc1626c40a4095319a8336d84a188 (BE)
Version: 1
nInputs: 83
nOutputs: 1
LockTime: 0
Inputs:
... <removed because too much text for forums>
Transaction B (was a bet to SD for 25.6) Tx Hash: aa133e5c5515c08b5dbba384fbb9bc3402c952b8b33d67ae726942c646322b2e (invalidated, so you won't see it) Transaction:
TxHash: aa133e5c5515c08b5dbba384fbb9bc3402c952b8b33d67ae726942c646322b2e (BE)
Version: 1
nInputs: 3
nOutputs: 2
LockTime: 0
Inputs:
PyTxIn:
PrevTxHash: 5a0797c05be28c6dca7171629f6c59f7f38742eeb13c16772138e826770d3c65 (BE)
TxOutIndex: 0
Script: (493046022100e5defeb9be42358cd4434147fc932dece6e31cb58760514ab6e4)
Sender: 1Pie7ZujioasX61UwtbGJdxXHyPjgcnkPZ
Seq: 4294967295
PyTxIn:
PrevTxHash: bc3c46e96d338f5529f9380e292e2846b77cb87b847c4fd399ecba18fe080629 (BE)
TxOutIndex: 1
Script: (49304602210090b42e22b06ab7b29e01f67b1222a830007fcf5317aead6d6e9f)
Sender: 1Pie7ZujioasX61UwtbGJdxXHyPjgcnkPZ
Seq: 4294967295
PyTxIn:
PrevTxHash: 28c9d1308eb998621b798998d74f26fba6f4df8f978e25b712b09ff8f4c7c54b (BE)
TxOutIndex: 0
Script: (48304502205fb4891bdb21efdd460af81ff143279b884e889ae3b936bdf52427)
Sender: 1Pie7ZujioasX61UwtbGJdxXHyPjgcnkPZ
Seq: 4294967295
Outputs:
TxOut:
Value: 2560000000 ( 25.6 )
Script: OP_DUP OP_HASH (1dice97ECuByXAvqXpaYzSaQuPVvrtmz6) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 279670414 ( 2.79670414 )
Script: OP_DUP OP_HASH (1Pie7ZujioasX61UwtbGJdxXHyPjgcnkPZ) OP_EQUAL OP_CHECKSIG
It looks to me that a miner must've helped replace it. The replacement tx does not look like the kind of tx that an "standard" miner would mine anyway, because of no fee. And it replaced one that was annoying (I don't know the fee) but was below the 10kB limit. (BTW, EclipseMC was the miner for that block).
|
|
|
|
|
Can someone please help me out understanding how listtransactions really works in Bitcoin-Qt? This is weird and non-intuitive, and I've spend ungodly amounts of time trying to figure out what they're doing when I just want to spit out my pre-computed ledger (which is what I would expect users to want). I'm going to add my own version (probably "listledger"), but I feel like I need to have some matching behavior to Bitcoin-Qt, if I don't go insane first.
I'm going to give some hypothetical transactions, and maybe someone can tell me how to break them into outputs of the RPC call "listtransactions". I'll pay 1.0 BTC for the answers because I've wasted way too much time on this already (1 BTC for all answers, not each)! It's easily worth that much to have someone tell me (or do the research for me) and save my sanity! I'm not looking for "the gist", I need details! Mainly it has to do with transactions that have multiple outputs. Specifically, how many "results" are produced by listtransactions for each one of these tx, and what are the {"address", "amount", "category", and "fee"} (and signs on them).
Addresses A, B, C and D are in my own wallet. X,Y,Z are other addresses.
Transaction #1 (SIMPLE Out, No Fee)
------
IN: A 10
IN: B 5
---
OUT: X 3
OUT: C 12
-----
Transaction #2 (SIMPLE Out, With Fee)
-----
IN: A 10
IN: B 5
---
OUT: X 3
OUT: C 11
--
FEE: 1
-----
Transaction #3 (SIMPLE In, No fee)
-----
IN: X 10
IN: Y 5
---
OUT: A 3
OUT: Z 12
-----
Transaction #4 (SIMPLE In, With Fee)
-----
IN: X 10
IN: Y 5
---
OUT: A 3
OUT: Z 11
--
FEE: 1
-----
Now the not-so-simple ones (Multi output)
Transaction #5
-----
IN: A 10
IN: B 5
---
OUT: C 3
OUT: D 5
OUT: Z 6
--
Fee: 1
-----
Transaction #6
-----
IN: A 10
IN: B 5
---
OUT: C 3
OUT: X 5
OUT: Z 7
-----
Transaction #7
-----
IN: X 10
IN: Y 5
---
OUT: C 3
OUT: D 5
OUT: Z 6
--
FEE: 1
-----
Transaction #8
-----
IN: A 10
IN: B 5
---
OUT: C 3
OUT: D 12
-----
Transaction #9
-----
IN: A 10
IN: B 5
---
OUT: C 3
OUT: D 10
OUT: D 1
--
FEE: 1
-----
Transaction #10
-----
IN: A 10
IN: B 5
---
OUT: C 15
-----
|
|
|
|
Armory version 0.87-beta is released. You should get notifications next time you restart. If not, Get it here!@justusranvier: this time I remembered to tag and sign the repo on this release. "git tag -v v0.87-beta" should give you a thumbs up. However, I have found two subtle bugs that trigger rarely, but clearly need to be fixed. I don't think it's critical, but since I'll be setting up a JSON-RPC server and it will be expected to run reliably, I'm going to have to fix them. They are: (1) Armory crashes just after a blockfile split -- the logic to handle a split in real-time was working at one point, but the upgrade to accommodate Bitcoin-Qt 0.8+ seems to have broken it. (2) If Armory receives two blocks in the same heartbeat (2 sec), it apparently loses sync and no longer see new blocks. If you leave Armory running long enough, it will happen just by chance. If you have tx that are stuck at X confirmations, then you can right click on the tx and "Show on Blockchain.info" to see if you are out of sync. If you are hit by (2), simply restart. Though, you should still be able to send and receive coins in this state, but none of the transactions will get past 0 zero confirmations. Spent the day yesterday exercising and socializing, so I'm sore and introverted today. I plan to spend most of the day hiding in my office and fixing these bugs, and hopefully also get a working RPC server going. Thanks again to mav, who gave me an excellent template for the RPC server, and also got it setup with authentication. Looks like I just gotta fill in the RPC commands and fix those bugs! THEN back to the new wallets
|
|
|
|
|
Whoa, didn't the allow-free criteria for transaction size used to be like 4 kB? I have definitely been using 4 kB ever since Armory was first released...
I'll go ahead and update that...
|
|
|
|
Yes, I think that casascius's goals might be a bit too far off. If a usable Bitcoin transaction transfer system over audio comes out of it that's plenty cool though...
He's injecting a healthy dose of skepticism based on extensive previous experience. I don't think it's as crazy as he makes it out to be, but he's rightfully pointed out a lot of issues that we will run into. I am definitely much better prepared for having nothing come out of this, though. Artificially-lowered expectations always make for a better experience when it does work Right, I forgot about that and totally agree. IMO, public domain is a bit too out there for something that could be useful. Is something like MIT OK? I would also be willing to go the copyright transfer route as well if that is clearer for future use.
MIT license is fine. I don't mind giving attribution for others' work that I'm using, but I just don't want my project to end up tethered to a bunch of other strangers on the internet that had tiny contributions compared to the entire project (no offense to all those strangers ). I should probably set a reasonable goal for the bounty so there is some checkout criteria, though I will be flexible if someone is close. (1) It should work with "standard" audio cables (or attenuated). I don't want users to have to buy expensive stuff... but buying something is okay. I'm guessing that $20 or less would be ideal, but if it's in the $50 range it might have to do (and it looked like USB-to-Serial adapters were going to cost in the $30 range, maybe casascius can chime in about how to do it cheaper). (2) The solution should achieve at least 1/3 the rate of RS232 on one audio channel (I'm assuming that a reasonable baud rate for RS232 is 115.2k, so this solution should get about 36k). If it can optionally expand to two channels, that would be great but I expect most platforms to support one. (3) Final baud rate should be what you get after all the error correction. (4) The solution would preferably auto-calibrate itself: most importantly it would probably have some mechanism for determining an appropriate output level (which is an interesting problem when neither side knows if the other side can hear them yet...) We can negotiate the remaining terms of the bounty a bit later... it's late!
@Casascius One other thing I meant to ask you that I hadn't resolved yet about RS232: even if I succeed as detecting and forcing the user to disable TTY logins, is there a way to determine if any other processes are listening on the channel? Beyond simply turning off OS auto-operations, it wouldn't surprise me if there were older applications that try to "help out" by listening and auto-processing serial information... |
|
|
|
OK, you got me really interested in this, but I haven't done any DSP stuff in a long time... So tonight I coded up an extremely rough 16-QAM modulator/demodulator (& in python too!) Right now it just writes to and reads back the samples in a file, but pyaudio is already working on the speakers side so you can hear the data. Currently I'm in the mid 1980s, at 4 kbits/second. It wouldn't work at all in the real world though, maybe kinda through a cable. But the proof of concept is there. The code is at https://github.com/notespace/python-scripts/tree/master/python-qam, and you can run it: (apt-get install python-pyaudio python-matplotlib)
python send.py (you might need to turn the volume down?)
python receive.py
And it should show a nice diagram of the received constellation. I'll release it under AGPL-3, just like Armory. There is still a ton of work to do to make it robust of course, and huge amounts of cleanup; not to mention choosing some standard data rates and implementing handshaking for real bidirectional comms. We'll see if I get any time to work on it.  Great! I'm excited to see someone taking a serious shot at this, and hopefully something will come out of it. Admittedly, Casascius has significantly lowered my expectations, so any positive progress seems all that much exciting By the way, if you are going to not put it into public domain, please do realize that part of the reason I'm doing this as a bounty is in exchange for giving me unrestricted rights to the code to use in Armory. Armory is AGPLv3, but if I ever decided to do some kind of closed-source add-on (or, say, corporate version), I don't want to have to get approval from other copyright holders who have less than 1% contribution (no offense). Therefore, if you are going to put it under a license and still want the bounty, I request some kind of verifiable statement of transfer (GPG email is probably fine). We'll deal with it when there's bounty-ready code to transfer, but I just wanted to throw that out there so that there's no surprised. A 20 BTC bounty is a lot (for me) but that's why I'm offering it. |
|
|
|
Speaking of storing wallets - how many bits is the seed?
It's ultimately 64 bytes: 32-bytes for the root key and 32 bytes for the chaincode. It's not necessary to have that much entropy, but that's how I designed it a year ago and then it stuck. The new wallets will probably use 24 bytes of entropy (192 bits) for the root seed, and then you back that up instead of the rootkey&chaincode (those still exist, but they will be derived from the 24-byte seed). Oh, and the new testing build has raw txs working fine. Thanks
Wow, that was fast! Glad to see that fixed the problem for you |
|
|
|
@mavYou're amazing! You made that look so easy... I guess you just have experience with this to realize that I didn't need all that extra garbage to do something so simple. Thanks so much -- now I can get around to actually implementing all the RPC commands. Ideas are welcome for how to deal with it for things that aren't the same for bitcoind and Armory: for instance, bitcoind has accounts, Armory has wallets. I was thinking it could be a multi-wallet interface, instead of accounts and you give it the wallet ID where you would otherwise put an "account" in the JSON interface. Mapping other functionality over for watch-only wallets may be kind of fuzzy. There's also things where Armory can provide a bit more than bitcoind could -- for instance, the ability to sweep or import private keys could be added (I'm thinking I could have that happen in another thread so that it wouldn't have to go offline... [wait, I could do that in Armory GUI, too... ...?]). I'm looking to generate a raw plain hex signed tx that's ready to push later via blockchain/pushtx or bitcoind/sendrawtx.
I've noticed that copy raw tx returns the same value pre and post signing, which i presume to be the unsigned data. Is this a bug?
@PlooYes! I actually was just messing with something and found this bug and fixed it. I don't know if I fixed it in the testing branch yet, but I'll definitely try to get it in, soon. I was annoyed, myself, that I couldn't get the raw tx out of it... 1) Do you agree this configuration is equally secure as a configuration in which a dedicated offline system?
2) The biggest risk here (but also in the proposed configuration with the dedicated offline system) is keeping the offline wallet files physically secure. Especially as you will want to keep backups (flash storage is frail). Do you agree?
3) Why do you recommend making a paper backup? Personally I really do not trust paper (it decays even faster than any other sort of media). I would like to hear your thoughts because you have obviously put more thought into this than I.
4) Finally, atm I already use Armory (although not yet for the majority of my funds) in a configuration with 1 (hot) wallet on a system connected to the internet. I have encrypted the wallet with a very long pass-phrase (>50 characters to give an indication). Will using a offline configuration with a real and watch only wallet really improve my security? What exact use cases do I protect myself against?
@wachtwoordThe alternative you describe is really not much better than just maintaining an encrypted wallet on your hot computer. What it prevents is someone who has gotten remote access to your machine and manually digging around your filesystem looking for wallet files. That's not to say that such things don't happen, but I believe the real threats are viruses that get on your computer and siphons off data and send it back to "home base" when it finds it (it will farm the data and send it back the next time it's online). In this case it probably doesn't even have to send any data back... it just reads your wallet when decrypted and creates a transaction sending all BTC to its owner the next time it's online. Any computer with access to the internet is vulnerable to these viruses. You can get them from various exploits usually relating to your browser, or opening PDF/.xls documents with embedded exploits, etc. However, in order to compromise a truly-offline computer, there's a couple orders-of-magnitude more work for the attacker to do. They must (1) find a way to hide data on your USB key that (2) exploits an auto-run vulnerability when plugged into the offline computer, and then (3) be able to automatically find the data and copy it back, hidden, on the USB key to get it back to the offline computer. And these exploits are much more complicated when they don't even know what OS the offline system is. And if I can find another way to transfer data between systems not using USB keys, then this would even an order of magnitude better... I would look into this idea posted by N.Z.. It's a bit more work but is definitely a very reasonable solution for a single-computer setup (in fact, I've been thinking about bundling the tails packages like N.Z. suggested, to make this easier). This means that your wallet only ever touches this sandbox that has no access to internet, and is reset to default configuration on every boot. As for question 3 (paper backups), you just said in question 2 that you believe flash storage is frail. This is exactly why you make paper backups. If you print a paper backup and put it in a safe-deposit box or fold it into a book on your bookshelf, it will still be readable 20+ years from now . It doesn't even have to survive "well", as you could pull the data out of a terribly-faded copy with a bit of work. I mean, you've seen books that are 50+ years old and their pages are still readable. Now compare that to any kind of digital media. You can drop a flash drive, or sit on it or bend it, or put it too close to a magnet, or it just decays and it's no longer usable. What's your confidence level that even a well-treated USB drive sitting in a metal box will still work 5 years from now? 20 years? Even CDs and DVDs have expected lifetimes of 2-10 years, but that varies widely depending on lots of factors. With the paper backup, unless it physically burns to ash, you know it will still provide the data you need to recover your wallet in 20 years.... probably much longer than that. Another possibility would be to have the offline wallet in a virtual machine without internet access. Of course a virus could still get access to the file in which the virtual machine harddisk is placed, and thus the "offline" wallet, but the virus would more or less need to be tailored to attack your personal configuration. So if you keep thousands of bitcoins, you definitely want a dedicated offline machine, but for anything less I would guess that the virtual machine - or even the setup you suggested above - would for all practical purposes be secure.
@picobitThis is probably strictly better than just having an encrypted hot wallet, since it definitely much more complicated to automatically find data in a VM. It's not as good as an offline solution, but I bet a lot of viruses sit around scanning directories looking for wallets, and it would have to be kind of advanced to be able to pick apart the VM filesystem and/or memory space. It's definitely doable, but probably not deterministic (especially if you use some obscure OS in your VM). (EDIT: though, I'd still place this at substantially less-secure than a real offline solution)
|
|
|
|
Downloaded, previous version removed in full (all directories and registry entries). New version started in offline mode, switched to Expert, shutdown. Another start in offline mode, just to import MultiBit keys - the same ones I'm using since testing started - than shutdown again. Set Bitcoin datadir and started Armory, it synced and all seemed fine. With some other things to do, I just left it to run, with Bitcoin-Qt running as well, and than after like 5 minutes Armory lost connection than reconnected to Bitcoin-Qt. Than one more disconnect, reconnect, silence. After few minutes, I went to check the wallet - balances shown properly and immidiately upon opening, great! - than went to clicking around not doing anything specific. After a while, "Transactions" tab went blank even though Armory was in online mode. Than it crashed, same module in question as shown here - that is one of older screenshots, not new one. This time I managed to grab more crash details - in .zip there are Armory log and WinXP crash log, that is created and normaly submitted to Microsoft than deleted. Since I have reporting disabled, in previous crashes mentioned log file was gonne faster than I acted. http://www.sendspace.com/file/gfmeewUhh. I've always known that Windows XP is the least reliable for Armory... but geezuz. I see in the log file that crazy "500k blocks added in the last 5 sec" stuff again. I have absolutely no idea how that is triggered, or how to reproduce it. Obviously, it doesn't do that on my Win XP VM, or else I wouldn't be releasing it... By the way, what version of Bitcoin-Qt are you using? |
|
|
|
|
Show Posts
