1 2012-08-23 01:08:53 <jgarzik> phantomcircuit: just checked in the s/Crypto.Hash/hashlib/ change here
2 2012-08-23 02:15:35 <jgarzik> well, damn. my cPickle caching trick was actually slower than manually copying a CTransaction, attribute by attribute
3 2012-08-23 02:15:59 <jgarzik> git checkout -f
4 2012-08-23 06:09:35 <phantomcircuit> jgarzik, ps i've found the serialize/deseralize type operations in python are roughly 200x slower than the equivalent in c++
5 2012-08-23 06:09:38 <phantomcircuit> sad panda
6 2012-08-23 09:44:53 <Eliel> http://www.explosm.net/db/files/Comics/Rob/office-worker.png it's too silent in here :)
7 2012-08-23 10:12:45 <t7> heh
8 2012-08-23 10:12:52 <t7> at least he has a nice view
9 2012-08-23 11:35:21 <jgarzik> phantomcircuit: you know what is the slowest operation during signature checking?
10 2012-08-23 11:35:28 <jgarzik> phantomcircuit: creating a CTransaction() copy
11 2012-08-23 11:35:46 <jgarzik> not the actual sigcheck
12 2012-08-23 11:48:11 <jgarzik> phantomcircuit: pynode is quite fast, though, if you turn off sigchecks
13 2012-08-23 11:50:27 <gmaxwell> sipa: a slightly unforuntate result of pull 1720 is that an attacker could network isolate old pre-bip16 nodes by constantly flooding invalid transactions.
14 2012-08-23 11:50:46 <gmaxwell> sipa: if there are any pre-bip16 miners remaining, the attacker will be able to force the creation of a forked network.
15 2012-08-23 12:19:14 <jgarzik> pynode script verification enabled in main node
16 2012-08-23 12:19:31 <jgarzik> pynode now does chain reorg and script verf by default... it's slow, but fully validating
17 2012-08-23 12:23:17 <sipa> jgarzik: nice!
18 2012-08-23 12:24:09 <sipa> jgarzik: by the way, ultraprune does not keep the utxo set in RAM (though it should be small enough to remain cached entirely)
19 2012-08-23 12:24:22 <jgarzik> sipa: interesting
20 2012-08-23 12:24:58 <sipa> i have a test branch that does keep it in RAM, for benchmarking, and maybe i can make that optional to enable it at runtime too
21 2012-08-23 12:25:41 <jgarzik> sipa: post update
22 2012-08-23 12:25:42 <sipa> but the time difference between bdb with large enough cache, and just storing in ram is not very large (20% difference for IBD or so)
23 2012-08-23 12:25:44 <jgarzik> *updated
24 2012-08-23 12:25:59 <jgarzik> sipa: I think it is probably better to store on disk for DoS reasons
25 2012-08-23 12:26:42 <sipa> it also reorganizes automatically if the block database contains more recent blocks than the coin database
26 2012-08-23 12:26:46 <jgarzik> pagedb directly mmaps the data, so it should be quite fast and cacheable
27 2012-08-23 12:27:24 <sipa> so if you miss commits to the coindb (by keeping them in memory, and only dumping occassionally for example), there is no problem
28 2012-08-23 12:36:41 <jgarzik> ACTION hasn't made up his mind on undo records yet
29 2012-08-23 12:37:21 <jgarzik> ACTION plans on storing block data, so might as well just regenerate the data from the old blocks being reorg'd
30 2012-08-23 13:18:51 <sebicas> Guys, thanks for your help the other days??? I was able to do what I wanted to do..
31 2012-08-23 13:19:25 <sebicas> And since I thinks it could help others??? here is my code: https://github.com/sebicas/bitcoin-sniffer
32 2012-08-23 13:19:43 <sebicas> I am calling it Bitcoin Sniffer :)
33 2012-08-23 14:02:56 <sebicas> [ANN] BTC Sniffer: Bitcoin P2P Network Sniffer & Events Trigger
34 2012-08-23 14:02:58 <sebicas> https://bitcointalk.org/index.php?topic=102740.0
35 2012-08-23 14:06:04 <jgarzik> sebicas: note that that code is maintained as a branch, https://github.com/jgarzik/pynode/tree/mini-node
36 2012-08-23 14:06:13 <jgarzik> sebicas: if you have fixes to the base code, I'd appreciate a pull request
37 2012-08-23 14:06:50 <sebicas> jgarzik: I am not a python developer, so the code may not very clean..
38 2012-08-23 14:07:30 <sebicas> jgarzik: I didn't know you have a branch??? I will check it and see if I can contribute with something...
39 2012-08-23 14:07:32 <jgarzik> sebicas: I'm not either!
40 2012-08-23 14:08:30 <jgarzik> sebicas: just saying if you find bugs etc., we should make sure all projects know about it
41 2012-08-23 14:08:50 <jgarzik> share the knowledge, share the fixes for the benefit of all projects
42 2012-08-23 14:09:36 <sebicas> jgarzik: Sure! If I would it know what you have this branch I would just fork and make the changes on that :)
43 2012-08-23 14:09:56 <jgarzik> sebicas: yeah, sorry, that's my fault
44 2012-08-23 14:10:28 <sebicas> jgarzik: when I checked pynode it had a lot of features I didn't need.
45 2012-08-23 14:10:38 <sebicas> But this mini-node is great.
46 2012-08-23 14:10:53 <sebicas> It could have save my a few hours :)
47 2012-08-23 14:11:09 <jgarzik> sebicas: yeah, a fully validating node is too much for some monitoring needs
48 2012-08-23 14:12:03 <sebicas> jgarzik: Now I see: "See the "mini-node" branch for a single-file, non-chaindb node." didn't see it before :(
49 2012-08-23 14:12:26 <jgarzik> sebicas: the goal with pynode was to create a "python-bitcoin" where you simply use what pieces of the lib you need, and ignore the rest, just like the python standard lib. that is true for basic code like serialization... but not true for the P2P node itself, making the python-bitcoin useless for your network sniffer project.
50 2012-08-23 14:12:56 <jgarzik> eventually python-bitcoin should be useful to your project... but right now, forking mini-node is far easier
51 2012-08-23 14:14:03 <jgarzik> sebicas: PS I just plugged your project with a link, in the pynode thread: https://bitcointalk.org/index.php?topic=94645.msg1126803#msg1126803
52 2012-08-23 14:14:26 <sebicas> jgarzik: yes totally I wanted to have independence from the node itself, so I could write extensions with out needing to modify the bitcoind code??? so if a new version is released I can just upgrade with with need to change my extensions code
53 2012-08-23 14:14:47 <sebicas> Thanks jgarzik!
54 2012-08-23 14:16:56 <sebicas> jgarzik!: I can create a fork an push some changes..
55 2012-08-23 14:17:08 <sebicas> jgarzik!: the main two changes are:
56 2012-08-23 14:17:24 <sebicas> jgarzik!: Use hashlib instead of Crypto.Hash, the latter is mostly not installed
57 2012-08-23 14:17:42 <sebicas> jgarzik!: Adding new_tx_event
58 2012-08-23 14:17:57 <sebicas> jgarzik!: Passing block or tx info to events
59 2012-08-23 14:20:55 <jgarzik> sebicas: sure, sounds good
60 2012-08-23 15:54:27 <jgarzik> ACTION pokes an absent gavin about 0.7rc1
61 2012-08-23 15:57:19 <gmaxwell> What are we going to do with https://github.com/bitcoin/bitcoin/pull/1393 ? It's been in luke's 'next' and 'next-test' for some time, and so it's had a least some real world testing. It resolves some somewhat frequent complaints/questions with the wallet behavior.
62 2012-08-23 16:01:44 <jgarzik> gmaxwell: don't care. no objection, if others want it.
63 2012-08-23 16:02:44 <sipa> gmaxwell: same; i have too little experience with real use to comment, but I don't object
64 2012-08-23 16:03:52 <gmaxwell> Luke-Jr: plz rebase. I'll give it one more test and then pull.
65 2012-08-23 16:04:06 <Luke-Jr> k..
66 2012-08-23 16:04:51 <Luke-Jr> ACTION wonders if there's a way to disable the automatic git gc that doesn't work <.<
67 2012-08-23 16:11:09 <Luke-Jr> sipa: I thought mere users weren't supposed to +1 on github? ;)
68 2012-08-23 16:11:25 <Luke-Jr> shall I put out a call for first-class messaging users to back me up? :P
69 2012-08-23 16:13:49 <gmaxwell> Luke-Jr: meh, why do you care about an option? Aruging for a better default layout makes sense, but an option?
70 2012-08-23 16:14:36 <Luke-Jr> gmaxwell: because there are more people with the opposing layout opinion at the moment
71 2012-08-23 16:15:05 <gmaxwell> Luke-Jr: What are the behaviors (you know I hardly use the GUI) with and without it now?
72 2012-08-23 16:15:46 <Luke-Jr> gmaxwell: second-class messaging: you have to go to the File menu and select "Sign Message" or "Verify Message", and get a dialog to do that in
73 2012-08-23 16:16:11 <Luke-Jr> gmaxwell: first-class message: the tab bar has a "Signatures" item with a panel in the main window like everything else
74 2012-08-23 16:16:27 <Luke-Jr> messaging*
75 2012-08-23 16:19:07 <gmaxwell> hm. 'meh'. I don't think adding tools to tabs makes a ton of sense. Why don't we have a tools menu? Where are we going to put tools for escrows and custom transactions, when we get gui for them?
76 2012-08-23 17:03:05 <vegard> is 0.6.3 safe against the merkle thingy exploit?
77 2012-08-23 17:03:12 <gmaxwell> Yes.
78 2012-08-23 17:03:19 <gmaxwell> Luke-Jr: any idea whats going on here? https://github.com/bitcoin/bitcoin/pull/898
79 2012-08-23 17:04:49 <vegard> thanks.
80 2012-08-23 17:10:57 <Luke-Jr> gmaxwell: not really
81 2012-08-23 17:24:51 <Mqrius> A friend of mine is still running 0.6.0, and sent a transaction with it. It doesn't show up on the blockchain, even now that his client finished downloading the most recent blocks
82 2012-08-23 17:24:58 <Mqrius> What's the next thing I should have him try?
83 2012-08-23 17:25:55 <Mqrius> Oh it just came through.
84 2012-08-23 17:25:56 <Mqrius> Weird.
85 2012-08-23 17:49:10 <Luke-Jr> Mqrius: 0.6.0 has known exploits
86 2012-08-23 17:49:45 <Mqrius> Luke-Jr: DoS exploits, right?
87 2012-08-23 17:49:51 <Mqrius> He's updating now, anyway :)
88 2012-08-23 17:50:24 <Luke-Jr> Mqrius: he could see over 6 confirmations on a bogus double-spend
89 2012-08-23 17:50:54 <Luke-Jr> although that takes a lot of work assuming all the miners are updated..
90 2012-08-23 17:51:36 <Mqrius> I'm not entirely sure if he saw confirmations at all (troubleshooting over phone chat :x)
91 2012-08-23 17:52:15 <Mqrius> It seems the transaction didn't reach the network at first, and then took some time for a re-send after he was fully connected/synchronized. Not sure if that's normal.
92 2012-08-23 17:52:42 <Luke-Jr> re-send is random
93 2012-08-23 18:19:51 <BlueMatt> TD: redid part of bloom branch:
94 2012-08-23 18:19:58 <TD> cool
95 2012-08-23 18:20:00 <BlueMatt> TD: MSG_FILTERED_BLOCK is now separate
96 2012-08-23 18:20:18 <BlueMatt> now actually cache txes for relayblocks
97 2012-08-23 18:20:46 <BlueMatt> (but Im not a big fan of it, as it has to throw the txes away after 15 minutes (as it is now))
98 2012-08-23 18:21:06 <BlueMatt> also, automatically relay txes when sending filtered blocks if its not in setInventoryKnown
99 2012-08-23 18:24:43 <TD> sounds like it'll be ready for a pull req soon, if not already
100 2012-08-23 18:25:37 <BlueMatt> well, need to decide on how, exactly, to cache txes when relaying blocks with hashes, but thats the only marked TODO left I think
101 2012-08-23 18:25:49 <BlueMatt> but...yea
102 2012-08-23 18:40:13 <sebicas> How can I do to decode CTxIn(prevout=COutPoint(hash=9dbc7e3b8f74be6e26dab1018bb2d91d79dace2cfd3e174cf9065275712f1c2d n=0) scriptSig=473044022031ae489dabb2e4fc111667e03dc5d5be95674669b5651acf84a5e2b54ad7eafe022041dc0dcaba90f54d21cc2a416f72eb8da701d6a3e96d812d378bc717fcb9d6660121036a4468d1425a38fbd4e7bd9b5658be3310df401261c8161b5209d90ca8119692 nSequence=4294967295)
103 2012-08-23 18:40:23 <sebicas> To an address and amount?
104 2012-08-23 18:57:53 <gmaxwell> 'rev' doesn't do what I expected. 0_o ... what the heck is the use of that command?
105 2012-08-23 18:58:21 <gmaxwell> man, am I the only person mining testnet3 right now?
106 2012-08-23 19:03:32 <Diapolo> gmaxwell: I do sometimes :) but via CPU and only very rarely
107 2012-08-23 19:09:50 <forrestv> sebicas, you have to lookup the amount and script in the referenced txout
108 2012-08-23 19:10:14 <jgarzik> gmaxwell: I have a core mining on testnet3
109 2012-08-23 19:10:22 <sebicas> forest any easy way to do that?
110 2012-08-23 19:10:34 <sebicas> forrestv: any easy way to do that?
111 2012-08-23 19:11:09 <forrestv> sebicas, look at http://blockexplorer.com/tx/9dbc7e3b8f74be6e26dab1018bb2d91d79dace2cfd3e174cf9065275712f1c2d . it's output #0
112 2012-08-23 19:11:14 <jgarzik> "balance" : 3150.00000000,
113 2012-08-23 19:11:22 <jgarzik> gmaxwell: block count correct?
114 2012-08-23 19:11:36 <gmaxwell> "blocks" : 21020,
115 2012-08-23 19:12:08 <sebicas> This is what I have http://blockexplorer.com/rawtx/9dbc7e3b8f74be6e26dab1018bb2d91d79dace2cfd3e174cf9065275712f1c2d
116 2012-08-23 19:12:13 <sebicas> The raw transaction
117 2012-08-23 19:13:10 <sebicas> And from that I need to know http://blockexplorer.com/tx/9dbc7e3b8f74be6e26dab1018bb2d91d79dace2cfd3e174cf9065275712f1c2d
118 2012-08-23 19:13:45 <jgarzik> sebicas: you have to look up the previous transaction via the info in CTxIn. then, inside prev_tx, you look at the referenced CTxOut
119 2012-08-23 19:14:04 <sebicas> Ahh ok..
120 2012-08-23 19:14:31 <sebicas> What about OP_DUP OP_HASH160 6575f6a169c8bdc2d27ba4ef23f63e9c5b36e56d OP_EQUALVERIFY OP_CHECKSIG
121 2012-08-23 19:14:41 <sebicas> How do I convert that to an actual address?
122 2012-08-23 19:15:36 <forrestv> sebicas, you have to pattern match it, then base58encode that long number, packed with a few other things
123 2012-08-23 19:15:40 <forrestv> (version, checksum)
124 2012-08-23 19:16:02 <sebicas> Ok.. great.. I think I got it??? thanks so much!
125 2012-08-23 19:16:18 <forrestv> sebicas, read https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses
126 2012-08-23 19:16:40 <forrestv> that number in the script is the 160 bit hash of the public key
127 2012-08-23 19:16:56 <sebicas> Great thx forrestv!
128 2012-08-23 19:20:50 <midnightmagic> gmaxwell: I mine t3 occasionally.
129 2012-08-23 19:21:27 <midnightmagic> gmaxwell: With GPU, I might add. Perhaps 1GH? you should be able to locate a percentage of my blocks, and I haven't done it in a while.