1 2015-09-08 00:24:07 <midnightmagic> Sounds like strongly injective would be okay, because who cares if there is something in the hashed result that isn't represented by a possible key/hashing construction
  2 2015-09-08 00:58:15 <bedeho> are there any good test data which can be used to test a sighash computation routine?
  3 2015-09-08 00:59:42 <bedeho> found https://github.com/bitcoin/bitcoin/blob/master/src/test/data/sighash.json
  4 2015-09-08 01:34:39 <phantomcircuit> is there a convention for keys in the chainstate database that aren't utxo values?
  5 2015-09-08 01:44:15 <dcousens> is the limiting of hashtypes to 0x01, 0x02, 0x03, 0x81, 0x82 and 0x83,  a consensus rule yet?
  6 2015-09-08 01:48:29 <gmaxwell> dcousens: no, but it's not like this allows you to introduce new hashtypes. At most you could use the hashtype as a sidechannel to signal something unrelated to the hashtype.
  7 2015-09-08 01:49:16 <dcousens> gmaxwell: just noticed https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki#der-encoding it mentioned as of 0.8.0 that it enforced those relay rules
  8 2015-09-08 01:49:46 <dcousens> And then BIP66 enforced DER signatures via consensus, but, naturally didn't enforce the sig-hash restriction
  9 2015-09-08 01:49:56 <dcousens> Curious if it was done elsewhere, or not done (as seems to be the case)
 10 2015-09-08 01:50:57 <gmaxwell> No, it would be an effect of BIP62, if completed and deployed.
 11 2015-09-08 01:51:45 <gmaxwell> for safty reasons we generally need to drop stuff out of IsStandard well before killing out of consensus.
 12 2015-09-08 01:52:37 <gmaxwell> Maybe that rule would be a candidate criteria from BIP62 that could be broken out and done ahead along with other changes.
 13 2015-09-08 02:10:05 <bedeho> gmaxwell, in the test data for the sighash routine, why do the hashType values look like this: 946795545, -1960128125
 14 2015-09-08 02:10:24 <bedeho> rather than among these: 0x01, 0x02, 0x03, 0x81, 0x82 and 0x83
 15 2015-09-08 02:11:24 <gmaxwell> No idea off the top of my head.
 16 2015-09-08 02:43:35 <dcousens> (which is fine)
 17 2015-09-08 02:43:35 <dcousens> yeah,  noticed
 18 2015-09-08 02:43:35 <dcousens> you test all range of sighash numbers
 19 2015-09-08 02:53:21 <bedeho> dcousens, are you implementing a sighash computation routine?
 20 2015-09-08 02:53:48 <dcousens> bedeho: ? no,  just cleaning up some bitcoinjs-lib code,  wondered if it was enforced
 21 2015-09-08 02:58:58 <jamesob> anyone know roughly how long reindexing usually takes?
 22 2015-09-08 03:34:02 <phantomcircuit> jamesob, hello
 23 2015-09-08 03:34:16 <phantomcircuit> jamesob, it depends entirely on your computer
 24 2015-09-08 03:34:38 <phantomcircuit> currently there's a bug in reindexing and the checkpoints are ignored, so you do all the script checks
 25 2015-09-08 03:34:44 <phantomcircuit> so 12+ hours minimum
 26 2015-09-08 03:36:01 <phantomcircuit> gmaxwell, are we generally following the naming convention or is that dropped?
 27 2015-09-08 03:36:12 <phantomcircuit> ie bool obfuscated vs bool fObfuscated
 28 2015-09-08 03:51:04 <jamesob> phantomcircuit I see
 29 2015-09-08 04:04:59 <phantomcircuit> jamesob, btw i am pstratem on github
 30 2015-09-08 04:14:48 <jamesob> phantomcircuit, aaah, that makes sense :)
 31 2015-09-08 04:45:36 <phantomcircuit> jamesob, btw std::string::string(const char*) is for null terminated strings, that was a BoF
 32 2015-09-08 04:45:43 <phantomcircuit> actually
 33 2015-09-08 04:45:50 <phantomcircuit> buffer over read?
 34 2015-09-08 04:45:53 <phantomcircuit> words
 35 2015-09-08 04:59:32 <bedeho> dcousens, still around?
 36 2015-09-08 04:59:39 <dcousens> bedeho: aye
 37 2015-09-08 04:59:47 <bedeho> I cant get these tests to work
 38 2015-09-08 05:00:16 <bedeho> 2030598449
 39 2015-09-08 05:00:16 <bedeho> take this nhashtype value
 40 2015-09-08 05:00:35 <bedeho> 2030598449 & 31 == 0 , is false
 41 2015-09-08 05:00:43 <bedeho> 2030598449 & 31 == 1, is false
 42 2015-09-08 05:00:49 <bedeho> and so on
 43 2015-09-08 05:01:02 <bedeho> so none of the three main flags are set, which would make it invalid
 44 2015-09-08 05:02:02 <bedeho> are these test valus actually used? these data seems to be added in 2014, which is very late
 45 2015-09-08 05:02:21 <dcousens> bedeho: not sure,  been a while since I synced that test data
 46 2015-09-08 05:03:14 <dcousens> bedeho: when you say can't get these to work, what do you mean?
 47 2015-09-08 05:03:26 <bedeho> well that simple calculation above just really
 48 2015-09-08 05:03:35 <dcousens> they pass in the bitcoinjs-lib tests, at least,  in the sense I get the same hash
 49 2015-09-08 05:03:52 <bedeho> but what hash types do you decode from that then?
 50 2015-09-08 05:04:10 <dcousens> https://github.com/bitcoinjs/bitcoinjs-lib/blob/master/src/transaction.js#L173
 51 2015-09-08 05:04:18 <dcousens> around :236
 52 2015-09-08 05:05:18 <bedeho> well look at your tests: (hashType & 0x1f) === Transaction.SIGHASH_NONE
 53 2015-09-08 05:05:20 <bedeho> from 193
 54 2015-09-08 05:05:33 <dcousens> true that.
 55 2015-09-08 05:05:47 <bedeho> it would not be true in any of those, unless I am just brainfarting here
 56 2015-09-08 05:06:18 <dcousens> it still gets tested though
 57 2015-09-08 05:06:27 <bedeho> hmm
 58 2015-09-08 05:06:31 <dcousens> it just doesn't have a hashTypeName
 59 2015-09-08 05:07:15 <dcousens> well, it does, but it probably shouldn't
 60 2015-09-08 05:08:28 <dcousens> yeah, cheers for spotting that,  fixed the test description so it shows all the cases where its a non-standard hash type
 61 2015-09-08 05:11:20 <dcousens> eh, wait
 62 2015-09-08 05:11:22 <bedeho> no,we are misunderstanding som how
 63 2015-09-08 05:11:30 <bedeho> none of them match
 64 2015-09-08 05:13:15 <dcousens> bedeho: will take it to PM
 65 2015-09-08 05:14:04 <bedeho> ok
 66 2015-09-08 05:20:03 <jamesob> phantomcircuit; thanks for the spot. I'm pretty new and/or rusty with C++.
 67 2015-09-08 05:20:45 <dcousens> bedeho: yeah,  to conclude, SIGHASH_ALL is default behaviour, even if hashType & SIGHASH_ALL *isnt* set.  Interesting
 68 2015-09-08 05:22:07 <dcousens> (in regards to the transaction serialization step,  not the signature hash type)
 69 2015-09-08 05:48:21 <phantomcircuit> jamesob, hmm there seems to be an issue with the leveldb batching stuff
 70 2015-09-08 05:50:29 <phantomcircuit> hmm
 71 2015-09-08 05:50:39 <phantomcircuit> is leveldb::WriteBatch in memory? or does that write out partially to disk
 72 2015-09-08 05:56:26 <jamesob> phantomcircuit heh, that's what I'm trying to figure out now. not sure how the db connection information gets conveyd to WriteBatch from the Wrapper... might have something to do with the Wrapper being cited as a friend?
 73 2015-09-08 05:58:28 <jamesob> we're not using the memory environment with leveldb by default...
 74 2015-09-08 06:00:23 <phantomcircuit> jamesob, looks to be entirely in memory
 75 2015-09-08 06:01:41 <jamesob> hah, is that a bug? is it intended never to be persisted to disk?
 76 2015-09-08 06:02:47 <jamesob> oh no, check out last line of CCoinsViewDB::BatchWrite; ultimately it's written back through `db`
 77 2015-09-08 06:03:13 <phantomcircuit> jamesob, the issue is CLevelDBBatch
 78 2015-09-08 06:03:24 <phantomcircuit> CLevelDBBatch is writing to leveldb::WriteBatch
 79 2015-09-08 06:03:32 <phantomcircuit> which appears to just be constructing a string in memory
 80 2015-09-08 06:03:45 <jamesob> phantomcircuit I'm going to have to add a constructor param to CLevelDBBatch which caches the obfuscate_key
 81 2015-09-08 06:04:12 <jamesob> yeah, but ultimately that WriteBatch is written to disk through `db`
 82 2015-09-08 06:04:29 <phantomcircuit> maybe
 83 2015-09-08 06:05:22 <phantomcircuit> there should be a way to do it only when it's flushed to disk
 84 2015-09-08 06:05:40 <phantomcircuit> but the way leveldb::WriteBatch works is insane
 85 2015-09-08 06:05:45 <jamesob> haha, agree
 86 2015-09-08 06:06:03 <jamesob> but reorganizing where those writes happen will be a fair amount of work
 87 2015-09-08 06:06:26 <jamesob> err -- reorganizing where that data is serialized
 88 2015-09-08 06:07:00 <phantomcircuit> yeah
 89 2015-09-08 06:07:21 <jamesob> might be out of scope for this PR, though I completely agree it's awful and more or less of a leaky abstraction
 90 2015-09-08 06:09:17 <jamesob> still can't figure out why CLevelDBBatch cites Wrapper as a friend
 91 2015-09-08 06:10:10 <phantomcircuit> jamesob, CLevelDBWrapper needs access to CLevelDBBatch::batch
 92 2015-09-08 06:10:45 <jamesob> oh, I see, in `WriteBatch`
 93 2015-09-08 06:11:00 <phantomcircuit> yeah
 94 2015-09-08 06:11:17 <phantomcircuit> in theory you should be able to mutate the batch before writing
 95 2015-09-08 06:11:30 <phantomcircuit> but the leveldb batch thing is internally just a string
 96 2015-09-08 06:11:48 <phantomcircuit> so you'd have to rewrite CLevelDBBatch to use something that's easier to change
 97 2015-09-08 06:11:50 <jamesob> yeah, that'd get nasty fast if we were playing with that state in two places
 98 2015-09-08 06:11:58 <jamesob> I think I've got a decent fix in mind
 99 2015-09-08 06:13:16 <phantomcircuit> there should probably be a CLevelDBWrapper::GetBatch()
100 2015-09-08 06:13:26 <jamesob> that's exactly what i'm doing :)
101 2015-09-08 06:17:37 <jamesob> phantomcircuit I'm sneaking in a little bit of cleanup ;)
102 2015-09-08 07:16:58 <wumpus> lmdb relies fully on memory mapping, so with our data sizes it would be 64-bit only. Could be an alternative backend, I guess, but it's no a full replacement for leveldb for our usecase.
103 2015-09-08 07:20:45 <wumpus> also it has no internal integrity protection as leveldb has, so to ward against corruption we'd have to add our own checks
104 2015-09-08 07:25:46 <wumpus> I'm somewhat afraid performance gains would be offset by that, then again, it's still a fun project for someone to tryand benchmark
105 2015-09-08 07:27:55 <gmaxwell> wumpus: yea, there were some posts by lmdb authors about supporting non-mmap, but I don't know if they have plans to move forward.
106 2015-09-08 07:29:45 <wumpus> there's a barely maintained 32-bit branch that may implement some of those plans. It doesn't seem like a priority for their own usecase.
107 2015-09-08 07:34:23 <gmaxwell> wumpus: leveldb interal checks are for naught if it manages to corrupt often; or when the performance is so poor at the database size we have we need to cache most of the UTXO set in ram to avoid reading from it.
108 2015-09-08 07:35:39 <wumpus> it's very likely that the leveldb corruption is not caused by leveldb itself, it's just very good at detecting third party corruption due to its paranoid checks
109 2015-09-08 07:36:46 <wumpus> e.g. so far every time I've seen it on my own devices, it was due to the harddisk or flash drive actually corrupting data. Other programs tend to bear e.g. bitflipping silently until they catastrophically fail at some point.
110 2015-09-08 07:37:34 <wumpus> I do think it's important but okay...
111 2015-09-08 07:38:25 <midnightmagic> You've seen an SSD corrupt data..?
112 2015-09-08 07:39:32 <LeMiner2> I'm looking at corruption every single time QT crashes
113 2015-09-08 07:39:54 <wumpus> midnightmagic: just flash, not 'ssd'
114 2015-09-08 07:40:04 <LeMiner2> I should rephase, my PC turns off without rebooting
115 2015-09-08 07:40:25 <midnightmagic> wumpus: As in SDHC-type?
116 2015-09-08 07:40:36 <wumpus> yes
117 2015-09-08 07:40:47 <midnightmagic> Ah. Yeah. Me too then. :(
118 2015-09-08 07:41:40 <buZz> ssd is flash aswell
119 2015-09-08 07:42:03 <wumpus> buZz: we all know, but SSD adds some smart controller logic and is generally the high-end performance-oriented segment
120 2015-09-08 07:42:19 <buZz> fyi all SD cards also have a controller builtin for wearlevelling etc
121 2015-09-08 07:42:29 <wumpus> yes, I know that, but a crappy one usually
122 2015-09-08 07:42:38 <buZz> well, arm cortex
123 2015-09-08 07:42:46 <buZz> flashable firmware
124 2015-09-08 07:42:55 <bedeho> can anyone answer why the nHashType values used in the tests data for the sighash computation are not valid? : https://github.com/bitcoin/bitcoin/blob/master/src/test/data/sighash.json
125 2015-09-08 07:42:55 <wumpus> the type of chip is not relevant, just the algorithms :)
126 2015-09-08 07:44:41 <wumpus> LeMiner2: CPU overheating?
127 2015-09-08 07:45:15 <LeMiner2> @wumpus, no, I'm more referring to power cuts
128 2015-09-08 07:45:19 <buZz> sounds like a dead or dying PSU to me
129 2015-09-08 07:45:34 <LeMiner2> when it happens, I have to rebuild the block database
130 2015-09-08 07:45:44 <wumpus> definitely get an UPS if it's an important machine
131 2015-09-08 07:46:15 <LeMiner2> It's not that important, just a desktop running QT
132 2015-09-08 07:46:34 <LeMiner2> Jus annoying having to rebuild after a crash
133 2015-09-08 07:46:49 <LeMiner2> just*
134 2015-09-08 07:46:58 <buZz> or add battery backed storage
135 2015-09-08 07:47:04 <wumpus> would be nice to have a built-in way to backup/restore the utxo database
136 2015-09-08 07:47:09 <buZz> and run sync every minute ;)
137 2015-09-08 07:48:05 <wumpus> well, just copying the chainstate folder works, I suppose, but not while bitcoind is running
138 2015-09-08 07:48:10 <LeMiner2> In the DC we have backup gens
139 2015-09-08 07:48:12 <phantomcircuit> wumpus, i've not actually seen it, but leveldb's journal code seems to simply ignore failures
140 2015-09-08 07:48:21 <LeMiner2> I'll try that wumpus
141 2015-09-08 07:48:35 <phantomcircuit> and the lack of a sequence number means that journal writes can be lost without notice
142 2015-09-08 07:49:31 <wumpus> maybe even a periodic auto-backup
143 2015-09-08 07:49:48 <wumpus> then if it detects corruption it can go back to that
144 2015-09-08 07:53:55 <wumpus> utxo data format could be database-independent, so if we add e.g. a lmdb backend, could just re-import into that
145 2015-09-08 07:57:16 <wumpus> bedeho: which ones? (that file is just a big hex dump)
146 2015-09-08 07:57:38 <bedeho> wumpus, e.g. first one 1864164639
147 2015-09-08 07:57:49 <bedeho> none of the standard bits are set, all,single, none
148 2015-09-08 07:58:05 <bedeho> also, its bigger than 1 byte so you cant fit in postfix of signature
149 2015-09-08 07:58:34 <wumpus> wut those numbers look crazy
150 2015-09-08 07:58:39 <bedeho> I talked to somone who said they suspected it was just junk test data,
151 2015-09-08 07:58:40 <bedeho> yes
152 2015-09-08 07:58:52 <bedeho> they are all insane: -882306874
153 2015-09-08 07:59:20 <bedeho> if you actually use those, then the you cannot capture full value in 1 byte, and no one can verify your signature
154 2015-09-08 08:00:11 <phantomcircuit> wumpus, eh? it is database independent
155 2015-09-08 08:00:18 <bedeho> It was a bitpay guy (maroaz) who added it
156 2015-09-08 08:00:26 <wumpus> phantomcircuit: what is database independent?
157 2015-09-08 08:00:30 <phantomcircuit> er
158 2015-09-08 08:00:33 <phantomcircuit> the format is
159 2015-09-08 08:00:36 <phantomcircuit> *words
160 2015-09-08 08:00:47 <phantomcircuit> it's key/value with the normal serializer
161 2015-09-08 08:01:02 <phantomcircuit> any database that supports atomic batch set/delete operations will work
162 2015-09-08 08:01:08 <wumpus> what I meant is: to be able to export the entire utxo database in a database-independent format, so just a flat file
163 2015-09-08 08:01:19 <wumpus> so you can switch to a different database, and import it
164 2015-09-08 08:01:21 <phantomcircuit> wumpus, ah
165 2015-09-08 08:01:29 <wumpus> that would make sense for backups
166 2015-09-08 08:01:30 <phantomcircuit> yes i was about to say that we could do that pretty easily
167 2015-09-08 08:01:37 <phantomcircuit> ... if it's to a single file :P
168 2015-09-08 08:02:03 <wumpus> yes
169 2015-09-08 08:02:15 <phantomcircuit> wumpus, read all the keys and values and pass one giant blob to serializer
170 2015-09-08 08:02:20 <wumpus> I understand
171 2015-09-08 08:02:23 <phantomcircuit> heh
172 2015-09-08 08:05:59 <bedeho> wumpus, if it was only a few cases, then I could just thin it was some sort of edge case testing, but almost all of them are like this
173 2015-09-08 08:05:59 <wumpus> bedeho: looking at sighash_test.cpp: int nHashType = insecure_rand() <- it's just a random 32-bit integer
174 2015-09-08 08:06:25 <bedeho> ok, so they are not sensible values which should be used in real txs then
175 2015-09-08 08:06:51 <wumpus> phantomcircuit: could probably even save a bit of space by compressing it, due to sorted, partially repeating keys
176 2015-09-08 08:08:09 <wumpus> bedeho: I don't think that'd even be possible - isn't it just 1 byte?
177 2015-09-08 08:08:25 <wumpus> bedeho: of which only the lower 5 bits are used
178 2015-09-08 08:08:58 <bedeho> yes, so you would loose the rest, which means no one could actually reproduce the sighash to check the signature for
179 2015-09-08 08:09:24 <bedeho> since sighash depends on full 4byte nhasttype code
180 2015-09-08 08:10:53 <wumpus> agreed. Most of those couldn't exist in actual transactions.
181 2015-09-08 08:12:00 <bedeho> ok, good, thank you :)
182 2015-09-08 08:12:03 <wumpus> the point of that test seems to be to check that the old and new SignatureHash functions are equivalent, so the whole range of nHashType is exercised, not just the sane range of 1-byte values
183 2015-09-08 08:12:27 <bedeho> ok, I have never heard of the hold sighash types
184 2015-09-08 08:13:22 <wumpus> hold sighash types?
185 2015-09-08 08:14:32 <bedeho> old :)
186 2015-09-08 08:14:47 <bedeho> I guess perhaps it was just old functions you meant, but same types...
187 2015-09-08 08:15:14 <wumpus> yes
188 2015-09-08 08:15:24 <bedeho> ok
189 2015-09-08 08:15:44 <wumpus> the functions need to be *equivalent*, that wouldn't be the case if the interpretation of any value changed
190 2015-09-08 09:44:17 <Cryo> finally figured out why my database was never staying up-to-date:  http://cryo.ws/images/bcvs.PNG
191 2015-09-08 09:46:01 <Cryo> would have thought clamav would have knocked it off with the false positive of stoned, but apparently there's more
192 2015-09-08 09:48:19 <wumpus> ouch
193 2015-09-08 09:50:42 <wumpus> see also https://github.com/bitcoin/bitcoin/pull/6650  https://github.com/bitcoin/bitcoin/issues/6613
194 2015-09-08 09:54:17 <wumpus> that's a nice collection of viruses though. And it did that in the background without even warning you?
195 2015-09-08 09:54:27 <wumpus> s/viruses/fake virus signatures/
196 2015-09-08 09:55:31 <gmaxwell> wumpus: other people had previously reported AV deleting or moving the files without notice.  Hopefully we'll have that fixed soon.
197 2015-09-08 09:56:44 <Cryo> your "Considering how much data corruption problems we currently have with LevelDB on windows already" leaves me with the 'fix that' before 'fix this' feeling
198 2015-09-08 09:57:09 <Cryo> yeh, it was doing it all in the background for ages, and I just now paid attention to the logs doing a RAID rebuild
199 2015-09-08 09:57:51 <Cryo> on a mac, so it's not often anything burps anyway since it's my dev box and I'm not whoring around too much on the interwebs
200 2015-09-08 09:58:44 <gmaxwell> Cryo: yea, we know about the AV corruption and there is now a PR to fix it.
201 2015-09-08 09:58:54 <Cryo> it was just serendipitous that it happened at the same time there was discussion happening recently about it
202 2015-09-08 09:58:56 <gmaxwell> Well, make a best effort work around, it's not clear that its fixable! :)
203 2015-09-08 09:59:53 <Cryo> everything is fixable... you keep beating until it's fixed and morale improves!
204 2015-09-08 10:00:03 <gmaxwell> I wonder if you made webpages with virus signatures in their titles if AV software would end up deleting chrome's data. Maybe thats how you fix this. :P
205 2015-09-08 10:00:53 <Cryo> write an article with them encoded in it.. wait.
206 2015-09-08 10:01:07 <gmaxwell> our pullreq will obfscuate the chainstate data which should make it much less likely to trigger bug some of the triggering signatures were very short, and who knows one might be invariant to xor with a repeating 64 bit key.
207 2015-09-08 10:01:23 <Cryo> and make sure to title it so buzzfeed or register picks it up
208 2015-09-08 10:01:38 <buZz> NUMBER 3.14 WILL BLOW YOUR MIND
209 2015-09-08 10:03:28 <wumpus> re: "Considering how much data corruption problems we currently have with LevelDB on windows already", this may be the primary reason
210 2015-09-08 10:03:54 <wumpus> very few people on other OSes runs virus scanners, certainly not 'real-time' ones
211 2015-09-08 10:05:01 <wumpus> and periodic virus scanners tend to give a report with that they've found instead of secretly abducting files
212 2015-09-08 10:06:41 <Cryo> unless they're set to quarantine by default (which I think most do these days).  but the good news is it's only part of the chain, so it doesn't need to fetch the whole damned thing again.
213 2015-09-08 10:06:52 <Cryo> or in my case, I'll just mv those files back
214 2015-09-08 10:08:22 <wumpus> it's the utxo database not the chain. A -reindex would be enough to reconstruct it. I've never seen a virusscanner croak on the block files themselves, probably because they're bigger than a certain threshold value.
215 2015-09-08 10:08:28 <Cryo> I remembered the dos block virus a while back, but didn't know there was more (shouldn't be surprised) or that it was one of the later ones.
216 2015-09-08 11:34:53 <da2ce7> hello.  Is there any interest for making a TLS port 443 transport plugin for the Bitcoin P2P network. So that the bitcoin connections can masquerade as HTTPS content.  Including having perfect-forward-secrecy.  Of course. Not having any of the certificate-chain infrastructure.  Just setting up and tearing down the P2P connections in the same manner as TLS.
217 2015-09-08 11:35:17 <da2ce7> I was thinking about such things making Bitcoin much harder to detect/block.
218 2015-09-08 11:37:31 <da2ce7> also, would such a system still work with the dns seeding?
219 2015-09-08 11:37:33 <wumpus> easiest way to get TLS support is to tunnel it using e.g. stunnel. I also have had some success running bitcoin over a VPN, even cjdns
220 2015-09-08 11:38:08 <wumpus> (tor is also an option, but if you want to hide that you're running bitcoind you probably don't want to be seen running tor either)
221 2015-09-08 11:39:50 <da2ce7> wumpus, I suppose the aim here isn't anonymity, rather resistance to passive spying, and censorship. TOR's onion routing is always going to be less-performant.
222 2015-09-08 11:41:54 <wumpus> I run various nodes behind tor, and it isn't noticably slower in getting new blocks and transactions. The biggest hit would be during initial sync.
223 2015-09-08 11:42:25 <da2ce7> ideally, we would want any adversary to require active work to tell the difference between a HTTPS server, and a Bitcoin Node. (as-in they need to actively connect to the node to tell)
224 2015-09-08 11:42:48 <da2ce7> stopping passive attacks is the low-hanging fruit.
225 2015-09-08 11:42:59 <da2ce7> stopping active attacks is much much harder.
226 2015-09-08 11:44:52 <wumpus> there have been various bugs in OpenSSL in recent times, so just slapping that in may, counter-intuitively, reduce security
227 2015-09-08 11:45:41 <wumpus> (not arguing that optional authentication/encryption in the P2P is necessarily a bad idea though)
228 2015-09-08 11:46:43 <da2ce7> wumpus, there is more implementations of TLS than just OpenSSL.
229 2015-09-08 11:46:55 <wumpus> dns seeding is not a problem; could have a START_TLS kind of protocol
230 2015-09-08 11:48:12 <da2ce7> hmm... tho OpenSSL's implementation is quite well audited and tested now.  -  We would want to strip out anything that isn't strictly necessary. (aka, all the certificate stuff).
231 2015-09-08 11:48:35 <wumpus> yes, I'm sure, I just mean that adding the bloated beast called TLS could increase attack surface. OpenSSL may be the worst offender, but other implementations are not necessarily safer (I'm not sure)
232 2015-09-08 11:49:17 <da2ce7> just do the key exchange, and then setup an AES channel. - We should just do it in the same way as OpenSSL - so a passive observer cannot tell the difference between that and say Firefox connecting to a HTTPS server.
233 2015-09-08 11:50:18 <da2ce7> since we are doing no authentication; the vast majority of the TLS code is redundant.
234 2015-09-08 11:54:07 <da2ce7> I suppose it doesn't need be TLS, it just need to 'look' like a very common TLS session to a passive observer.
235 2015-09-08 11:55:14 <da2ce7> I have real interest in improving Bitcoin against active attackers; when we haven't first addressed the low-hanging fruit to defend passive attackers.
236 2015-09-08 11:56:27 <da2ce7> anyway, if this idea is plausible - and headed in the right direction. Then I will float it up to the mailing list.
237 2015-09-08 12:26:35 <da2ce7> http://pastebin.com/Z21cBQ6B
238 2015-09-08 12:27:05 <da2ce7> comments welcome:  before sending to mailing list.
239 2015-09-08 12:54:14 <jonasschnelli> da2ce7: For 1) Diffie-Hellman, do you had ECDH in mind?
240 2015-09-08 12:55:25 <jonasschnelli> Not sure about 4. Don't see why it should collide with a potential https running on 443. Do you wan't to prevent from port blocking?
241 2015-09-08 12:56:58 <jonasschnelli> da2ce7: Why not wrapping the traffic through CurveCP (http://curvecp.org)?
242 2015-09-08 12:57:14 <jcorgan> seems like all the advantages you are hoping for can be had by using Tor with entry nodes on 443, and with bitcoind only exposed as a hidden service
243 2015-09-08 12:57:44 <wumpus> tor also masquerades as TLS, doesn't it?
244 2015-09-08 12:58:13 <jcorgan> i think, yes
245 2015-09-08 13:00:08 <wumpus> yes they do, not only that but they try very hard, interesting: https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/TLSHistory
246 2015-09-08 13:00:50 <wumpus> esp "If you're running a protocol that an external censor would like to detect and block, it is not enough to simply use your TLS library in a sensible way. Instead, you need to pick a popular application that the censor doesn't want to block, and your clients need to emulate its clients, and your servers need to emulate its servers"
247 2015-09-08 13:27:38 <da2ce7> jonasschnelli it will only collide if the bitcoin node is also running a HTTPS server;  that is somewhat against best-practices anyway; one option would be to accept incoming connections from 8443 also.
248 2015-09-08 13:28:56 <jonasschnelli> da2ce7: Have you looked at CurveCP (http://curvecp.org)?
249 2015-09-08 13:29:04 <da2ce7> so if you are running a HTTPS server AND a bitcoin node on the same IP, then you will not be able to make a publicly accessible node, however you can still connect to other nodes via 8443
250 2015-09-08 13:29:55 <da2ce7> jonasschnelli, CurveCP is good, however doesn't look like common internet traffic.  - I would like to make Bitcoin censorship resistant to passive attackers as-well.
251 2015-09-08 13:30:14 <da2ce7> thus masquerading as TLS is a must.
252 2015-09-08 13:30:45 <da2ce7> It should be very hard for a static firewall to block bitcoin.
253 2015-09-08 13:31:03 <jonasschnelli> da2ce7: http://curvecp.org/httpcurve.html
254 2015-09-08 13:31:52 <jonasschnelli> not sure if this is an alternative,... but with curveCP you could route a nodes (encrypted) traffic through a UDP port.
255 2015-09-08 13:31:54 <da2ce7> even with the best deep-packet-inspection.  Curve CP HTTP port 80 is easily detected.
256 2015-09-08 13:32:47 <jonasschnelli> da2ce7: Okay. I see, you main concern is hiding the service.. yes. This would require TLS over 443.
257 2015-09-08 13:33:36 <wumpus> see the tor project link I pasted above - masquerading as HTTPS, even against passive attackers, is extremely hard, even the tor project wrote a whole page about it, and still hasn't completely succeeded
258 2015-09-08 13:34:23 <da2ce7> jonasschnelli, I wish to harden Bitcoin against passive attackers.  Privacy via Perfect-Forward-Secrecy, and deep-packet-inspection.
259 2015-09-08 13:34:59 <da2ce7> wumpus, tor dose lots of other stuff, and is trivially detected.
260 2015-09-08 13:35:20 <wumpus> so does bitcoin.
261 2015-09-08 13:35:51 <wumpus> (eg, you would want to disable DNS seeding at the least)
262 2015-09-08 13:36:37 <da2ce7> wumpus, hmm... just 8 to 16 connections to HTTPS servers, ideally.  - You want to make the attacker do something active, or have to connect to something to detect you.
263 2015-09-08 13:37:36 <da2ce7> that is what it should *look* like;  of course timing attacks will make it still trivially detected.
264 2015-09-08 13:37:40 <wumpus> and besides that, but using packet timing/statistics it's possible to distinguish various services behind TLS
265 2015-09-08 13:37:46 <wumpus> exactly
266 2015-09-08 13:38:08 <da2ce7> but, we want to make it hard as possible for a 'dumb' firewall to block.
267 2015-09-08 13:38:44 <da2ce7> aka, the 'dumb' firewall needs to do quite a bit of specialised work to detect that it isn't just a user streaming from youtube.
268 2015-09-08 13:39:08 <wumpus> it's a cat and mouse game
269 2015-09-08 13:39:50 <da2ce7> forever, however atm we are playing it with the cards face-up on the table.
270 2015-09-08 13:40:48 <wumpus> unless you hide behind something else that is not bitcoin like a ssh tunnel, VPN, Tor, cjdns
271 2015-09-08 13:41:34 <da2ce7> I'm just gunning for the most *bang for buck*.  - While not changing performance.  (or maybe increasing performance by making traffic shaping much harder).
272 2015-09-08 13:42:04 <wumpus> anything created specifically for bitcoin will have a harder time staying covert, by definition, as it's not possible to hide in the noise of other traffic
273 2015-09-08 13:42:30 <da2ce7> unfortunately, TOR doesn't have the property of being similar performance,  - an important consideration for the large population of nodes that don't run 24/7
274 2015-09-08 13:44:12 <wumpus> on the other hand, it provides other privacy properties as well, also resists quite a few active attacks
275 2015-09-08 13:45:46 <da2ce7> sure, and is certainly going to be needed by many people.  However TOR isn't 'free'.  While pretending to be TLS is very low cost.
276 2015-09-08 13:49:08 <wumpus> hm if your goal is to be covert, a more through solution would be to request (and possibly serve) blocks and possibly other data over https. E.g. an alternative transport. In that case there's no need to even hide the protocol.
277 2015-09-08 13:50:08 <da2ce7> nothing is gained by that other than needing a full TLS and HTTPS stack.
278 2015-09-08 13:50:11 <wumpus> and existing web servers in 443 wouldn't be a problem, it could just reverse proxy
279 2015-09-08 13:50:47 <jonasschnelli> +1 for http p2p
280 2015-09-08 13:50:51 <wumpus> mah, 'a full TLS and HTTPS stack' could be a simple python script these days
281 2015-09-08 13:50:59 <da2ce7> just masquerading as TLS means you only need to pretend up-to the point that the connection is established.
282 2015-09-08 13:51:48 <wumpus> I'm just trying to expand the discussion
283 2015-09-08 13:52:12 <wumpus> in many cases, bitcoiners tend to come up with a solution first, then think about the problem they want to solve :)
284 2015-09-08 13:52:18 <da2ce7> it sounds like lots more work, and would increase the attack surface area.
285 2015-09-08 13:53:13 <jonasschnelli> the REST interface could also listen for invs and request the data from the inv-source-node. Add a apache/reverse-proxy over TLS.
286 2015-09-08 13:54:48 <da2ce7> I think that increasing Bitcoin's dependancies is not a good idea. - We already depend on OpenSSL, we can take the very minimal needed to pretend to run TLS connections.
287 2015-09-08 13:55:05 <wumpus> we're working on dropping OpenSSL from the dependencies
288 2015-09-08 13:55:25 <helo> doesn't bitcoin traffic actually need to look like http traffic? i.e. mostly ephemeral short-lived connections
289 2015-09-08 13:55:51 <wumpus> at the moment it's only used for a) random number generation b) ecdsa verification . a) will move to an internal implementation, b) will use secp256k1
290 2015-09-08 13:56:18 <wumpus> helo: don't forget keep-alive, as well as newer bidirectional http2.0-ish protocols
291 2015-09-08 13:56:28 <wumpus> and websockets
292 2015-09-08 13:56:53 <wumpus> http is certainly not always only short-lived connections anymore
293 2015-09-08 13:57:41 <da2ce7> wumpus, agreed the most minimal TLS masquerading I think isn't such a huge amount of code, we could start a libpretendtls.  - However working toward removing the OpenSSL dependancy is very important as well.
294 2015-09-08 13:59:10 <jgarzik> jonasschnelli, +2 http p2p
295 2015-09-08 13:59:34 <jgarzik> tls p2p seems like a lot of work
296 2015-09-08 13:59:51 <jgarzik> on the positive side, it would punch through more firewalls, and work with DNS seeding
297 2015-09-08 13:59:55 <jonasschnelli> if there would be http p2p, nodes could create tunnels
298 2015-09-08 14:00:11 <wumpus> nodes can already create tunnels
299 2015-09-08 14:00:12 <jonasschnelli> or TLS reverse proxies
300 2015-09-08 14:00:16 <jgarzik> jonasschnelli, "could" - yes    "would" - the important question
301 2015-09-08 14:00:27 <jgarzik> What are users most likely to deploy in the field by default with minimal configuration?
302 2015-09-08 14:00:36 <jonasschnelli> wumpus: right... but current tunnels would not masquerade.
303 2015-09-08 14:01:42 <da2ce7> jgarzik, it should be less work if we only implement one handshake procedure, and reject anything else. - it certainly isn't a full tls stack.
304 2015-09-08 14:02:18 <wumpus> in any case, I'd prefer an alternative transport that can run as a process outside bitcoind. I don't like to burden bitcoind with different kinds of transport protocols. Certainly not if it imports a TLS dependency.
305 2015-09-08 14:03:07 <dcousens> wumpus: the simpler we can make the bitcoin transport protocol,  the simpler (and more standard, hence, tooling + instructions/tutorials) it will be to tunnel IMHO
306 2015-09-08 14:03:08 <jonasschnelli> jgarzik: did you found time to check https://github.com/jgarzik/univalue/pull/6?
307 2015-09-08 14:04:06 <da2ce7> no certificates, no authentication, just 'hello', 'Diffie-Hellman please', do DH, establish AES, then just use the p2p we have now.
308 2015-09-08 14:05:26 <wumpus> dcousens: yes, the P2P is pretty simple at the moment. Alternative transports don't have to support the entire protocol, anyhow. Something that only provides blocks could already be useful.
309 2015-09-08 14:07:22 <wumpus> (and there could be more bizarre cases, e.g. make data available a content-addressable network e.g. freenet, in which case it wouldn't look like the current P2P protcol at all)
310 2015-09-08 14:21:06 <da2ce7> hmm... I don't know if it is even possible to masquerade as TLS without having valid certificates.
311 2015-09-08 14:21:25 <da2ce7> since it seems to me that the certificates are sent quite early. :(
312 2015-09-08 14:21:42 <da2ce7> I have know idea why they designed it like that.
313 2015-09-08 14:22:06 <wumpus> you need a valid certificate. Would be possible to use a cookie-cutter one.
314 2015-09-08 14:22:22 <wumpus> e.g. hardcode it, unless the user overrides it
315 2015-09-08 14:24:02 <da2ce7> wumpus, it is crazy that the designed the certificate transfer *after* DH/AES. One would always think to first setup a perfect forward secrecy - > then do authentication.
316 2015-09-08 14:24:26 <da2ce7> *it wasn't designed like that.
317 2015-09-08 14:25:12 <wumpus> you wouldn't be the first to call TLS's design 'crazy'
318 2015-09-08 14:25:47 <da2ce7> it should be:  1. lets make a secure connection:  2. lets check that this connection is well authenticated.
319 2015-09-08 14:27:21 <jgarzik> IMO it's only worth doing if we are going to phase out the P2P protocol, and make TLS-lite-lite the primary protocol (and there are good arguments for doing so)
320 2015-09-08 14:27:50 <jgarzik> As an alternate transport, it makes sense as a separate process as wumpus implies -- unless of course it is widely adopted by users
321 2015-09-08 14:28:32 <jgarzik> That is the least impact way of introducing a new protocol - wrapper.  If widely adopted, it can be moved into bitcoind.
322 2015-09-08 14:29:38 <jgarzik> jonasschnelli, I know how to libtoolize a project...  I was just hoping to avoid it :)
323 2015-09-08 14:29:58 <da2ce7> wumpus, the problem with the 'cookie cutter' certificate is that one can easily make a firewall "drop any connection with this cookie cutter cert"
324 2015-09-08 14:30:16 <jonasschnelli> jgarzik: It looks like it's unavoidable...
325 2015-09-08 14:30:52 <da2ce7> so it would need to be pseudo-random; at least forcing the firewall do a full certificate-chain-lookup for each certificate.  (much much more expencive)
326 2015-09-08 14:31:18 <jgarzik> jonasschnelli, many other details are needed to do it properly.  Take a look at the stuff in https://github.com/jgarzik/hail/blob/master/configure.ac
327 2015-09-08 14:31:30 <jgarzik> Getting library versioning and other details correct is a pain
328 2015-09-08 14:32:32 <jonasschnelli> hmm...
329 2015-09-08 14:33:18 <jonasschnelli> jgarzik: libsecp256k1 seems to go a relatively easy way: https://github.com/bitcoin/secp256k1/blob/master/configure.ac
330 2015-09-08 14:33:43 <jgarzik> jonasschnelli, They have never versioned a library before :)
331 2015-09-08 14:34:27 <jgarzik> The hail/.../configure.ac is widely used because it supports multi-version, multi-arch, multi-{32,64} simultaneous installation
332 2015-09-08 14:35:08 <jonasschnelli> jgarzik: i'll try to adapt that for UniValue...
333 2015-09-08 14:35:19 <wumpus> da2ce7: but if nodes generate their own certificate, they can be identified by it. Now you see the problems the Tor team encoutered :)
334 2015-09-08 14:35:23 <jgarzik> jonasschnelli, In any case, the smartest, simplest thing is probably to manually add -fPIC or -fPIE to the build as needed
335 2015-09-08 14:35:57 <jgarzik> jonasschnelli, maybe we can pass bitcoin cflags to univalue subtree?
336 2015-09-08 14:36:18 <jgarzik> that would be useful possibly - capture  -fPIC,-pthread and any other necessities
337 2015-09-08 14:36:25 <da2ce7> wumpus, well for one handshake only, if every handshake has a new random cert.
338 2015-09-08 14:36:36 <wumpus> jgarzik, jonasschnelli: should probably ask cfields when he's back re: build system
339 2015-09-08 14:36:41 <jonasschnelli> jgarzik: the configure args are already passed (including a forced -fPIC), but without libtool we don't listen to -fPIC over configure on the UniValue side.
340 2015-09-08 14:37:02 <da2ce7> wumpus, I'm not a conspiracy crazy, but really, TLS. It is like it is designed to be monitored.
341 2015-09-08 14:37:14 <jonasschnelli> jgarzik: agreed, maybe capture -fPIC only and pass it to the compiler/linker
342 2015-09-08 14:37:19 <wumpus> da2ce7: generating a new RSA key for every connection sounds heavy
343 2015-09-08 14:37:56 <da2ce7> wumpus, it doesn't need to be a 'key' it just needs to be random; it can be super weak as all we care.
344 2015-09-08 14:37:56 <jgarzik> jonasschnelli, Wonder if this is helpful?   http://www.gnu.org/software/automake/manual/html_node/Subpackages.html#Subpackages
345 2015-09-08 14:38:20 <da2ce7> RSA is heavy in checking the quality of the Primes rite?
346 2015-09-08 14:38:28 <jgarzik> jonasschnelli, tl;dr   LT_INIT is a possible solution but really want to avoid it...
347 2015-09-08 14:38:30 <wumpus> and TLS setup in itself is already quite compute intensive
348 2015-09-08 14:38:48 <jonasschnelli> jgarzik: Yes. In Bitcoin we use this already (AC_CONFIG_SUBDIRS).... sure, let me try to only capture and pass -fPIC
349 2015-09-08 14:39:36 <da2ce7> wumpus, well you can skip every step that is related to authentication.
350 2015-09-08 14:39:37 <jonasschnelli> keep it small is probably a good approach. wumpus: and right, we should also get cfields opinion.
351 2015-09-08 14:40:15 <da2ce7> we don't care if the certs are junk, only that they are 'plausible' junk.
352 2015-09-08 14:42:31 <wumpus> I'd really recommend reading the tor writeup, they followed the same path "So we switched to an approach where we would begin by sending a list of ciphers hacked to match the list sent by Firefox, a server would reply with a single certificate, and then the client would immediately renegotiate. Upon the renegotiation, the server and client would pick the ciphersuites they really wanted to use, and exchange their real certificates."
353 2015-09-08 14:44:29 <da2ce7> wazzza, TLS is bat-insane-crazy.
354 2015-09-08 14:45:42 <jgarzik> The best solution for blending in is... to look like what most everybody else is using.  That implies that highest value is obtained by (a) using [what appears to be] real TLS (b) over 443
355 2015-09-08 14:46:09 <jgarzik> If your traffic can be trivially fingerprinted, TLS-lite doesn't help.
356 2015-09-08 14:46:24 <jgarzik> fingerprinting can work even in the presence of encryption
357 2015-09-08 14:47:51 <wumpus> "In 2011, Iran blocked Tor based on our choice of Diffie-Hellman parameters"
358 2015-09-08 14:48:21 <da2ce7> jgarzik, AES with a good IV shouldn't have mathematical fingerprints tho... it is timing other sorts.   It is how you *get* to that point that is the problem.
359 2015-09-08 14:48:48 <jgarzik> not all fingerprints operate mathematically
360 2015-09-08 14:49:02 <da2ce7> *timing fingerprints, and other sorts of attacks (that apply).
361 2015-09-08 14:49:03 <jgarzik> packet size and timings/delays provide lots of metadata
362 2015-09-08 14:50:27 <wumpus> yes, we already went over that (scroll back :)
363 2015-09-08 14:50:30 <da2ce7> jgarzik, however that forces you attacker to have an entire Statistical model of the connection; and probabilistically fingerprint it.
364 2015-09-08 14:51:09 <jgarzik> no & yes, in that order :)
365 2015-09-08 14:52:18 <wumpus> it is a cat and mouse game already played by Jacob Appelbaum and friends, I don't think we should be repeating it as part of bitcoin
366 2015-09-08 14:53:15 <da2ce7> ok, so just take the tls-lite code from TOR and go 'we don't need onion routing'?
367 2015-09-08 15:02:14 <da2ce7> well guys I'm off to sleepy time :) thanks for chatting.
368 2015-09-08 15:14:44 <jonasschnelli> jgarzik: i think this works: https://github.com/jgarzik/univalue/pull/7
369 2015-09-08 15:15:15 <jonasschnelli> If you consider merging, i'll could trigger a travis build over the univalue subtree PR.
370 2015-09-08 15:16:01 <jgarzik> jonasschnelli, it is OK to merge, yes
371 2015-09-08 15:32:10 <wumpus> instead of taking code from tor, my recommendation would be to just use tor :) But never mind me.
372 2015-09-08 15:54:33 <cfields> back. discussion above is about univalue integration?
373 2015-09-08 15:55:07 <wumpus> cfields: or univalue disintegration? :)
374 2015-09-08 15:55:45 <cfields> ah, heh, the inevitable completely separate lib discussion?
375 2015-09-08 15:56:41 <wumpus> yes, and then adding it back as a subtree: https://github.com/bitcoin/bitcoin/pull/6637
376 2015-09-08 15:58:30 <cfields> fwiw, libsecp256k1 already uses libtool. So if there's an objection to that (looks like there might've been one above), it doesn't really add any cost compared to what we already have
377 2015-09-08 15:58:58 <cfields> ah nm, jonasschnelli pointed that out in his last comment
378 2015-09-08 16:00:35 <cfields> it's worth asking: is it realistic that other projects will find libunivalue useful enough to use outside of bitcoin?
379 2015-09-08 16:01:39 <wumpus> well it's a nice alternative to boost::json_spirit
380 2015-09-08 16:02:44 <wumpus> apparantly we didn't find any other lightweight C++ JSON implementation that suited our requirements, so others may have the same issue
381 2015-09-08 16:04:57 <cfields> hmm, looking at the subproject's build changes, i don't see any obvious actual uses of autoconf/autoheader. jonasschnelli: sure that isn't overkill?
382 2015-09-08 16:12:08 <cfields> also, it looks like it'd take a pretty big effort to get a stable abi out of it. I'm wondering if going for a header-only approach would be more useful all-around
383 2015-09-08 16:31:09 <jonasschnelli> cfields: you mean the #include changes?
384 2015-09-08 16:31:45 <cfields> jonasschnelli: i mean the buildsystem in general
385 2015-09-08 16:32:52 <jonasschnelli> In the last univalue PR it sounded like a git subtree is what we like to achieve.
386 2015-09-08 16:33:34 <jonasschnelli> It would leverage univalue to get more focus of keeping it independent
387 2015-09-08 16:34:53 <jonasschnelli> LT_INIT / libtool PR will be closed and is replaced by https://github.com/jgarzik/univalue/pull/7
388 2015-09-08 16:36:05 <cfields> mmm, that seems like overkill though, if the autoconf/autoheader features aren't actually used
389 2015-09-08 16:36:47 <cfields> jonasschnelli: was a header-only lib ever considered?
390 2015-09-08 16:37:26 <jonasschnelli> cfields: wouldn't this end up with similar issues like we had with JSON spirit (compile time)?
391 2015-09-08 16:38:09 <cfields> jonasschnelli: well that brought in a ton of boost, this is much more contained
392 2015-09-08 16:38:42 <jgarzik> cfields, it's silly to embed JSON parsing and output in multiple places
393 2015-09-08 16:40:33 <jonasschnelli> header only lib is probably out of scope. I just think, if UniValue would be independent (and it's a decent flexible JSON parser), it might get maintained/improved independent from bitcoin.
394 2015-09-08 16:40:44 <cfields> jgarzik: seems equally silly to me to split a lib out with an unstable abi
395 2015-09-08 16:40:45 <jonasschnelli> Like we saw with a recent PR.
396 2015-09-08 16:44:39 <cfields> jonasschnelli: no reason for those to be mutually exclusive. a header-only lib can live in an external repo just fine. I've used jsoncons in the past that way. PR'd a fix to it as well, as a matter of fact :)
397 2015-09-08 17:01:28 <nwilcox_Afk> 09:38 < jgarzik> cfields, it's silly to embed JSON parsing and output in multiple places
398 2015-09-08 17:01:40 <nwilcox> What are those multiple places currently?  ---^
399 2015-09-08 17:03:22 <Luke-Jr> cfields: why would it need an unstable ABI?
400 2015-09-08 17:04:04 <cfields> Luke-Jr: its external interface is c++
401 2015-09-08 17:04:26 <Luke-Jr> so is Qt's..?
402 2015-09-08 17:05:29 <cfields> Luke-Jr: yes, see the tricks they use to cope with it
403 2015-09-08 18:31:51 <jonasschnelli> maybe we should rewrite UniValue in C...
404 2015-09-08 18:40:36 <jgarzik> jonasschnelli, bleh :)  Part of the nice part is RAII
405 2015-09-08 18:41:08 <jgarzik> jonasschnelli, Just Works(tm) with no allocation hassles
406 2015-09-08 20:34:03 <Maciej72> Hello all ! I need help. I am new to bitcoin and need to program a short skript which triggers an action when an address received some bitcoins. Do some one has an example in python?