1 2014-06-25 01:08:14 <Guest________> question about compressed Bitcoin addresses. anyone home?
2 2014-06-25 01:08:55 <Guest________> sipa: ping
3 2014-06-25 02:00:22 <justanotheruser> Is this an accurate quote of Mike Hearn? "Mike Hearn interview quotes: "Progress on the bitcoin protocol has ground to a halt, complete halt. This is a crisis period for Bitcoin... Only Gavin is working on upgrades""
4 2014-06-25 02:02:14 <justanotheruser> I think the biggest problem with the quote is that lack of change in the protocol isn't a crisis
5 2014-06-25 02:02:21 <justanotheruser> at least in the short term
6 2014-06-25 02:10:47 <phantomcircuit> justanotheruser, i believe it is accurate
7 2014-06-25 02:25:13 <justanotheruser> phantomcircuit: is it a problem though?
8 2014-06-25 02:37:38 <CodeShar_> wumpus: have you had a chance to play around with CoinVault yet?
9 2014-06-25 02:38:04 <CodeShark> wumpus: have you had a chance to play around with CoinVault yet?
10 2014-06-25 02:51:21 <phantomcircuit> justanotheruser, no, indeed the premise that gavin is the only one working on the protocol is beyond ridiculous
11 2014-06-25 02:56:11 <jcorgan> where did those quotes come from
12 2014-06-25 03:03:20 <dsnrk> jcorgan: source seems to be https://epicenterbitcoin.com/eb-025/
13 2014-06-25 03:03:46 <dsnrk> jcorgan: https://www.youtube.com/watch?v=coj3uBrnxIg
14 2014-06-25 03:05:09 <dsnrk> don't know the timecode.
15 2014-06-25 03:05:57 <jcorgan> tks
16 2014-06-25 03:07:20 <jcorgan> until i hear what was said in context in the interview, i'll assume this is sensationalism
17 2014-06-25 03:08:20 <phantomcircuit> jcorgan, his proposal for bad additions to the protocol was largely rejected
18 2014-06-25 03:08:42 <dsnrk> proposing that bitcoin is tied to people's passworts, what?
19 2014-06-25 03:08:56 <phantomcircuit> dsnrk, yeah exactly
20 2014-06-25 03:09:01 <jcorgan> yeah, there was some controversy over that
21 2014-06-25 03:09:13 <phantomcircuit> jcorgan, "some"
22 2014-06-25 03:09:30 <dsnrk> yeah that's the moment I get my pitchFORK out
23 2014-06-25 03:09:55 <dsnrk> my passport doesn't even have NFC
24 2014-06-25 03:10:29 <jcorgan> i finally had to get a new passport with the NFC, but for some reason now it doesn't work at airports :)
25 2014-06-25 03:11:59 <dsnrk> receiver pays fees sounds like a terrible idea too. a sensible person would save up all their dust and make some poor fool pay $15 in fees.
26 2014-06-25 03:14:06 <jcorgan> well, he's a lot smarter than I am in many things, so i'll give him the benefit of the doubt even if I disagree with him, sometimes strongly
27 2014-06-25 03:18:37 <dsnrk> jcorgan: ah the quote is at 39:30 in the soundcloud audio stuff.
28 2014-06-25 03:18:55 <dsnrk> it's sort of not taken out of context at all.
29 2014-06-25 05:01:32 <phantomcircuit> sipa, any opinion on jgarziks comment re CMutableTransaction ?
30 2014-06-25 05:19:16 <sipa> phantomcircuit: agree it is overkill, but i like "obviously always correct", and it could some day allow a more efficient in memory representation (single malloced blod or so)
31 2014-06-25 05:30:16 <phantomcircuit> sipa, that's what i figured
32 2014-06-25 05:30:17 <phantomcircuit> ok
33 2014-06-25 05:30:24 <phantomcircuit> also
34 2014-06-25 05:30:28 <phantomcircuit> got tired of waiting for syncs
35 2014-06-25 05:30:32 <phantomcircuit> added my own checkpoint
36 2014-06-25 05:32:21 <SomeoneWeird> hax
37 2014-06-25 07:35:02 <arioBarzan> how can I sign only part of a transaction? Mike Hearn says the protocol allows one to partially sign a tx, according to his explanation for lighthouse project.
38 2014-06-25 07:36:24 <sipa> that has nothing to do with the protocol
39 2014-06-25 07:37:02 <sipa> if you need multiple people signing, they can each just sign whatever they can
40 2014-06-25 07:37:38 <sipa> but as far as the protocol is concerned, the transaction is totally invalid until it is fully signed
41 2014-06-25 07:57:14 <arioBarzan> sipa: to partially sign a tx, should I use Hashtype SIGHASH_ANYONECANPAY ?
42 2014-06-25 07:58:41 <arioBarzan> I want to sign one specific input with 1mBTC value and the tx has only one output with 2mBTC value.
43 2014-06-25 08:01:01 <arioBarzan> I am looking for a way that two persons sign only their specific inputs without knowing where the other 1mBTC comes from?
44 2014-06-25 08:02:19 <arioBarzan> it is said in bitcoin.it/wiki that Hashtype SIGHASH_SINGLE "sign one of the outputs-- I don't care where the other outputs go".
45 2014-06-25 08:02:33 <arioBarzan> and Hashtype SIGHASH_ANYONECANPAY "Let other people add inputs to this transaction, I don't care where the rest of the bitcoins come from."
46 2014-06-25 08:03:21 <arioBarzan> could anyone elaborate a little further on this matter?
47 2014-06-25 08:03:33 <sipa> sounds like you want sighash anyonecanpay
48 2014-06-25 08:16:05 <wumpus> lol @ #4378, gmaxwell keeps trying to sneak a full firewall into bitcoind
49 2014-06-25 08:17:46 <wumpus> sipa: pretty confusing, people use 'the protocol' to refer to the P2P protocol as well as the blockchain 'protocol' interchangably
50 2014-06-25 08:19:04 <sipa> neither of both has something like a partially signed transaction, still
51 2014-06-25 08:19:34 <wumpus> oh, sure...
52 2014-06-25 08:42:26 <arioBarzan> script.cpp @ #1021 CTransactionSignatureSerializer says that // In case of SIGHASH_ANYONECANPAY, only the input being signed is serialized. Does this mean that SignatureHash() would return hash of a txTmp which only covers the specified input when the hashtype has the SIGHASH_ANYONECANPAY flag set?
53 2014-06-25 08:43:52 <sipa> yes
54 2014-06-25 09:39:02 <rubensayshi> how is the blocktime in the block header validated? could you just try to mine a block with a blocktime of +2hrs, or +1week (I recall running in some 2hr constraint somewhere but I can't find it anymore) ?
55 2014-06-25 09:42:01 <rubensayshi> ah https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2239 so it can't be > 2hrs in the future when it's broadcasted or otherwise no node will accept/relay it?
56 2014-06-25 09:42:23 <jcorgan> correct
57 2014-06-25 09:44:07 <rubensayshi> so a miningpool could just always +2hrs just for laughs of blockexplorers showing weird block timestamps :) ?
58 2014-06-25 09:57:41 <damethos> rubensayshi, do that and i will hunt you down :p
59 2014-06-25 09:58:03 <rubensayshi> wish I was a pool operator :P
60 2014-06-25 11:16:39 <hearn> good afternoon
61 2014-06-25 11:19:04 <kiddouk> good afternoon
62 2014-06-25 11:19:34 <kiddouk> Anyone here playing with Obelisk server from unsystem ?
63 2014-06-25 11:20:25 <kiddouk> Looks like it's leaking memory and unresponsive at times. If anyone has experience with it. Would be happy to ask a couple of questions (already on #darkwallet chan btw)
64 2014-06-25 11:26:23 <hearn> afaik it's still under heavy development. i don't recall seeing anyone here discuss it much so #darkwallet is your best bet
65 2014-06-25 12:06:36 <wumpus> not sure where obelisk development discussion mainly happens, #darkwallet doesn't see that much traffic either
66 2014-06-25 12:08:13 <Luke-Jr> wumpus: do you plan to merge those PRs you commented on soon (when comments addressed)? rather avoid making the requested changes then it sitting months and needing rebasing if possible
67 2014-06-25 12:08:40 <wumpus> I suppose that the reason that they're still open is that they're planned to be merged
68 2014-06-25 12:08:54 <wumpus> however, the comments were never fixed
69 2014-06-25 12:09:00 <Luke-Jr> yes, eventually..
70 2014-06-25 12:09:04 <wumpus> so they linger
71 2014-06-25 12:09:47 <Luke-Jr> I tend to hit them every few months - but if it can be merged sooner, I can make it a priority to get to them
72 2014-06-25 12:11:13 <wumpus> well as I see it there is no one screaming NACK, so they should be merged, and sooner is better (it's annoying to have them open for that long)
73 2014-06-25 12:12:27 <Luke-Jr> ok, I'll put them on my priority todos then
74 2014-06-25 12:12:33 <wumpus> and after all that time I don't really expect anyone to suddenly come in and go THIS IS A BAD IDEA either :p
75 2014-06-25 12:15:02 <wumpus> people please review https://github.com/bitcoin/bitcoin/pull/1583 and https://github.com/bitcoin/bitcoin/pull/1816 and https://github.com/bitcoin/bitcoin/pull/1647
76 2014-06-25 12:15:11 <wumpus> would be nice to merge some features that would be useful for miners
77 2014-06-25 12:19:46 <Luke-Jr> https://github.com/bitcoin/bitcoin/pull/2834 would be very useful also
78 2014-06-25 12:29:52 <wumpus> codeshark reported a problem with that, did you ever figure out what went wrong there?
79 2014-06-25 12:31:18 <Luke-Jr> wumpus: sounds to me just like the usual RPC limitations?
80 2014-06-25 12:31:40 <wumpus> that's very possible
81 2014-06-25 14:32:08 <dipendra> can anybody help me in finding the coin transfer fee which is charged by coin network on transferring from one address to another one
82 2014-06-25 14:32:18 <dipendra> I observed dogecoin which sometimes applied 1 doge or 2 or 3 or null
83 2014-06-25 14:37:05 <wumpus> dipendra: the network doesn't add any fee
84 2014-06-25 14:49:46 <GAit> what set of patches/fork is best for detecting double spends the quickest? Peter's?
85 2014-06-25 14:52:59 <petertodd> GAit: mine rejects uneconomical double-spends, which is a whole class of them
86 2014-06-25 14:53:15 <GAit> ddos protection?
87 2014-06-25 14:53:43 <petertodd> GAit: for instance, a bunch of doublespends bitzillions was being hit with strongly indicate that either they or one or more miners was being sybil attacked - my replace-by-fee code was rejecting them entirely
88 2014-06-25 14:55:36 <petertodd> GAit: here's an implementation that would actually work and not be ddos vulnerable: https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370
89 2014-06-25 14:55:53 <petertodd> GAit: er, I mean, my comment could be turned into an implementation
90 2014-06-25 14:56:12 <petertodd> GAit: that actual pull-req doesn't work due to the dos protection
91 2014-06-25 15:00:46 <GAit> can't double spends be bounded?
92 2014-06-25 15:00:53 <GAit> i mean ignore after a few
93 2014-06-25 15:01:55 <petertodd> GAit: right, the problem is that the size of the double spend tx can be far larger than the size of the original tx, e.g. 250 bytes vs 100,000 bytes, even worse when you remember that any tx < 1MB is valid
94 2014-06-25 15:02:19 <petertodd> GAit: that's why I suggested relaying just scriptSigs in my comment
95 2014-06-25 15:05:00 <GAit> ok, if it gets widely used, for the time being our best bet is add a bunch of replace-by-fee nodes knowing that they can be dossed and therefore the double spends detection is purely best effort (well it always is given miners can avoid propagating some tx they are adding to a block)
96 2014-06-25 15:05:25 <GAit> or is this the wrong way of thinking about it?
97 2014-06-25 15:05:55 <petertodd> GAit: well, see replace-by-fee can't be DoS'd because because each replacement has to pay for the bandwidth it consumes as a delta fee increase
98 2014-06-25 15:06:18 <petertodd> GAit: of course, that assumes miners are using it :)
99 2014-06-25 15:07:12 <daybyter> GAit: my skype nick is daybyter
100 2014-06-25 15:07:19 <petertodd> but yeah, overall detecting double-spends is very dodgy business - that double-spends patch is completely ineffective if your attacker is sending non-standards to eligius for instance
101 2014-06-25 15:11:33 <GAit> petertodd: fair enough, thought so. as I said, best effort sounds reasonable
102 2014-06-25 15:12:22 <petertodd> GAit: well, best effort has a track record of encouraging people to use Bitcoin in ways that later lead to them losing a lot of money...
103 2014-06-25 15:12:44 <GAit> i think for the time being we are adding simple detection by the mare difference detected in a block and what we remember seeing. Will investigate more your branch and use that to add more information as we detect some double spends although we'll make sure people know this is not to be relied on
104 2014-06-25 15:12:49 <dgenr8> petertodd: mining non-standard double-spends can be detected easily after the fact though. Eligius mined a 2BTC double-spend this morning. http://bit.ly/1hR8S7s I haven't checked whether it was non-standard.
105 2014-06-25 15:12:59 <GAit> ok so are you suggesting we don't even show double spend in the UI ?
106 2014-06-25 15:13:15 <petertodd> dgenr8: and what are you going to do with that info? sue them?
107 2014-06-25 15:13:44 <dgenr8> petertodd: just publish it
108 2014-06-25 15:14:17 <petertodd> GAit: it's a hard choice. I'd show the double-spends in the UI, but also implement an attempt undo button to give users the right impression about the security properties of the system
109 2014-06-25 15:14:28 <petertodd> dgenr8: so you want a witch hunt?
110 2014-06-25 15:14:42 <GAit> undo as in increase fee?
111 2014-06-25 15:14:45 <GAit> wait
112 2014-06-25 15:14:49 <GAit> undo?
113 2014-06-25 15:14:49 <petertodd> GAit: yup
114 2014-06-25 15:15:04 <petertodd> GAit: well, I mean, both are good, but "attempt undo" gives users the right impressions
115 2014-06-25 15:15:39 <dgenr8> ACTION notes that that pattern of respends against dice sites has changed greatly since the discussion has become more visible
116 2014-06-25 15:15:49 <petertodd> dgenr8: how so?
117 2014-06-25 15:16:16 <dgenr8> petertodd: the rapid-fire ones stopped completely in late may
118 2014-06-25 15:16:31 <petertodd> dgenr8: define "rapid-fire"
119 2014-06-25 15:17:25 <dgenr8> 1 per minute or so
120 2014-06-25 15:17:43 <dgenr8> i'll construct a link that highlights that time period
121 2014-06-25 15:18:10 <wumpus> http://www.coindesk.com/mike-hearn-underfunding-leaving-bitcoin-development-crisis/ I wouldn't exactly say that nothing is happen in bitcoin core development
122 2014-06-25 15:18:35 <AssimNao> hey
123 2014-06-25 15:18:50 <AssimNao> I'm looking for some help, is it possible ?
124 2014-06-25 15:19:02 <sipa> not without knowing what the problem is
125 2014-06-25 15:19:13 <AssimNao> x)
126 2014-06-25 15:19:28 <petertodd> dgenr8: well yeah, dice sites implemented countermeasures that made the doublespends less profitable - dice sites are in a particularly good situation there because of the nature of the doublespends they're trying to defend against
127 2014-06-25 15:19:30 <AssimNao> lol I would like to know how to launch a network internally..
128 2014-06-25 15:19:46 <Apocalyptic> hearn is quitting ?
129 2014-06-25 15:19:49 <petertodd> dgenr8: I mean, I've been helping one of those sites out...
130 2014-06-25 15:19:56 <AssimNao> on testnet.
131 2014-06-25 15:20:11 <AssimNao> I can mine bitcoin on a testnet internally right ?
132 2014-06-25 15:20:18 <hearn> hmm?
133 2014-06-25 15:20:33 <AssimNao> hmm ?
134 2014-06-25 15:20:43 <hearn> Apocalyptic summoned me
135 2014-06-25 15:20:46 <AssimNao> I create a new genesis block on bitcoin and compile.
136 2014-06-25 15:20:49 <petertodd> AssimNao: you know about regtest?
137 2014-06-25 15:20:50 <AssimNao> I want mine it.
138 2014-06-25 15:20:53 <AssimNao> Im asking how to ?
139 2014-06-25 15:21:07 <Apocalyptic> hearn, sorry I misread wumpus' link
140 2014-06-25 15:21:07 <petertodd> AssimNao: altcoins are OT here
141 2014-06-25 15:21:08 <AssimNao> also look into it on cod.
142 2014-06-25 15:21:21 <AssimNao> petertodd, isnt altcoin. its bitcoin.
143 2014-06-25 15:21:23 <AssimNao> :D
144 2014-06-25 15:21:39 <hearn> wumpus: there's not very much going on given the rather large scale bitcoin operates at today. but this is not a new argument from me. i've been saying the same things for a while
145 2014-06-25 15:21:43 <AssimNao> regtest whats the diff between ?
146 2014-06-25 15:21:44 <dgenr8> petertodd: what was your solution to attacker only double-spending when he loses? anything other than wait for confirmation?
147 2014-06-25 15:22:28 <petertodd> dgenr8: you know how dice sites are now *not* using fixed addresses? that's a very important part of it
148 2014-06-25 15:22:57 <wumpus> hearn: but they are saying that there is almost nothing happening in bitcoin core development, I'm seeing it differently, there have never been as many contributors
149 2014-06-25 15:23:40 <petertodd> dgenr8: if people adopt replace-by-fee, you can very easily make doublespending uneconomical, if they don't then you just need to avoid getting rejected by a subset of the miners
150 2014-06-25 15:23:46 <hearn> you're comparing it with the historical state. i'm comparing it against other systems that manage $7.5 billion in value :)
151 2014-06-25 15:23:49 <wumpus> hearn: it's going really fast and I have to spend loads of time reviewing and commenting on changes as well as working on my own patches, so it's unfair to say that it ground to a halt
152 2014-06-25 15:23:53 <dgenr8> petertodd: yes, clearly. although they can't be using them exclusively per link i just posted
153 2014-06-25 15:24:00 <hearn> ah well i was talking specifically about the p2p protocol
154 2014-06-25 15:24:02 <wumpus> hearn: that's unfair
155 2014-06-25 15:24:04 <hearn> not the codebase as a whole
156 2014-06-25 15:24:16 <dgenr8> s/using/avoiding/
157 2014-06-25 15:24:25 <wumpus> maybe it's just coindesk that twisted your words
158 2014-06-25 15:24:32 <petertodd> dgenr8: i must be blind, which link?
159 2014-06-25 15:24:33 <wumpus> but this is really pissing me off
160 2014-06-25 15:24:39 <dgenr8> petertodd: http://bit.ly/1hR8S7s
161 2014-06-25 15:24:58 <hearn> no, i said that, but i was talking about the protocol itself. what current protocol upgrade projects are there? floating fees, maaku's utxo work, though that's some way from being finished and ...... that's about it
162 2014-06-25 15:25:06 <hearn> i didn't mean to imply people aren't working hard
163 2014-06-25 15:25:07 <petertodd> dgenr8: what do you mean by "can'
164 2014-06-25 15:25:14 <petertodd> "can't be using them exclusively"?
165 2014-06-25 15:25:35 <hearn> meanwhile lots of people think that tx malleability is solved since february, even though we know it's not. and that's only one of many things we need.
166 2014-06-25 15:25:37 <hearn> so this is what concerns me.
167 2014-06-25 15:25:54 <GAit> hearn: but you don't know everyone working on bitcoin
168 2014-06-25 15:25:59 <petertodd> hearn: we solved 95% of the problem of tx malleability
169 2014-06-25 15:26:07 <dgenr8> petertodd: sorry for the terrible wording. I meant "aren't avoiding them entirely".
170 2014-06-25 15:26:24 <wumpus> tx malleability as a problem was pretty much a red herring, and anyway it's being solved slowly but steadily
171 2014-06-25 15:26:43 <petertodd> dgenr8: sorry, what do you mean by "them" there? you mean avoiding double-spends?
172 2014-06-25 15:27:06 <hearn> i don't think it's a red herring, quite a few contract protocols require it to be fixed. but ok, i can pick many examples.
173 2014-06-25 15:27:39 <GAit> hearn: we require it to be fixed and we are working on it
174 2014-06-25 15:27:48 <dgenr8> petertodd: My point is simply that a huge 2BTC double-spend against dice crossed less than an hour ago, using one of the vanity addresses
175 2014-06-25 15:27:51 <hearn> so who is implementing the non-malleable txns BIP? anyone?
176 2014-06-25 15:27:57 <wumpus> anyhow, these kinds of articales are not motivating me
177 2014-06-25 15:27:59 <petertodd> dgenr8: remember, a dice site only needs to avoid some % of doublespends to make them uneconomical
178 2014-06-25 15:28:04 <sipa> hearn: petertodd implemented part of it already
179 2014-06-25 15:28:06 <GAit> hearn: so far we have been following the proposal by sipa
180 2014-06-25 15:28:09 <petertodd> hearn: me
181 2014-06-25 15:28:21 <petertodd> sipa, hearn: now two parts in fact
182 2014-06-25 15:28:40 <hearn> sipa's proposal was for a new tx version, no? i didn't see any patches implementing that as a new consensus rule
183 2014-06-25 15:28:51 <sipa> hearn: one step at a time
184 2014-06-25 15:28:57 <wumpus> this seems to have no other purpose than to drag bitcoin through the mud
185 2014-06-25 15:29:56 <hearn> no, i don't think it's about dragging it through the mud. it's about highlighting the difference in resources being applied to different places. bitpay alone has a larger development team than all of bitcoin core. probably the same is true for coinbase. heck bitpay have a team larger than the full time paid team of Core just doing a multi-sig wallet app.
186 2014-06-25 15:30:42 <hearn> the problem is not "existing people aren't working hard". the problem, as i see it, is that maybe by now we should have more like 10-15 people working on Core full time, if we're to fix all the ways we know it needs work
187 2014-06-25 15:30:57 <hearn> that's not anyone's fault per se. just how it is.
188 2014-06-25 15:31:16 <GAit> hearn: some companies are dedicating resources to bitcoind and more will come i think
189 2014-06-25 15:31:35 <gavinandresen> if it is anybody's fault, it is my fault-- I assumed SOMEBODY would spin up a "red hat for Bitcoin" by now.
190 2014-06-25 15:31:52 <petertodd> we don't know what the right solutions are yet. for instance my two malleability fixes will act as a IsStandard() rule, and we'll learn more about whether or not we've missed something re: sipa's work
191 2014-06-25 15:32:03 <gavinandresen> I keep hearing people saying they're going to do that, but my guess is all those project morph into something more profitable.
192 2014-06-25 15:32:04 <wumpus> well to pick bitpay, they're contributing quite a lot to bitcoin open source... not per se to bitcoin core, but i think it's unfair to ignore everything that is happening except the core protocol changes
193 2014-06-25 15:32:13 <wumpus> insight, copay, etc...
194 2014-06-25 15:32:34 <petertodd> wumpus: IMO innovation with the protocol has never moved faster
195 2014-06-25 15:32:54 <petertodd> wumpus: that we're seeing things like Reality Keys actually happen is really exciting
196 2014-06-25 15:33:05 <hearn> ok, i'm not ignoring those other projects (mine is one!), i was talking specifically about the p2p protocol itself. talking about projects like chain pruning, better resource scheduling, anti-malleability, tx v3 stuff, more unit testing etc
197 2014-06-25 15:33:18 <gavinandresen> petertodd: your opinion is wrong. Innovation happened at breakneck speed when Satoshi was God.
198 2014-06-25 15:33:22 <wumpus> unit tests are being added all the time
199 2014-06-25 15:33:43 <petertodd> hearn: three out of my last five patches were unit tests...
200 2014-06-25 15:33:50 <Jouke> hearn: maybe bitcoin-companies aren't big enough yet to free resources for bitcoin core?
201 2014-06-25 15:33:52 <hearn> sigh. i didn't say "nobody is adding unit tests"
202 2014-06-25 15:34:06 <wumpus> and hearn... why aren't YOU doing any of those things?
203 2014-06-25 15:34:19 <gavinandresen> hearn is trying to fix the meta-problem
204 2014-06-25 15:34:25 <hearn> i said compared to the number of users and amount of money handled by the system, we're not where we IMHO should be.
205 2014-06-25 15:34:40 <wumpus> that's completely arbitrary
206 2014-06-25 15:36:05 <hearn> yes, it's an arbitrary judgement call, just my personal opinion (it was an interview after all). look at it this way. in my old job tools that did nothing more exciting than displaying shopping links in a web page had much better test coverage than Core does. so it scares me a little that we have a multi-billion dollar system where large chunks of code have no coverage at all
207 2014-06-25 15:36:07 <wumpus> you can always pick some things 'hey these things are not happening' and ignore the rest and then complain nothing is hapening
208 2014-06-25 15:36:19 <hearn> i'm not complaining! i was explaining why i'm working on lighthouse
209 2014-06-25 15:36:27 <hearn> as the article says, actually.
210 2014-06-25 15:37:05 <hearn> let's assume for the sake of argument that i'm right (i might be wrong, but just for the sake of argument). so the problem is we need lots more people building decentralised infrastructure like Core, even though nobody owns it.
211 2014-06-25 15:37:17 <hearn> i could say "companies should give more money to the Foundation" and so far that solution has worked OK, sort of
212 2014-06-25 15:37:27 <Jouke> Why only companies?
213 2014-06-25 15:37:39 <hearn> but the foundation has many priorities. not all its money is spent on development. plus people don't like the idea that the Foundation does all the work and calls all the shots.
214 2014-06-25 15:37:40 <gavinandresen> Jouke: because individuals say they'll donate, but don't.
215 2014-06-25 15:38:01 <hearn> so perhaps a better solution is to do fundraising using assurance contracts. then we can fundraise for a project like chain pruning, and the Foundation doesn't carry the can for everything.
216 2014-06-25 15:38:04 <GAit> i do not think companies or people should pay a centralized entity, in that regard it makes more sense to allocate internal company resources to core
217 2014-06-25 15:38:07 <wumpus> hearn: sure I agree lighthouse is a good thing
218 2014-06-25 15:38:08 <GAit> which is what i think is more efficient
219 2014-06-25 15:38:22 <hearn> so this is the solution i would like to experiment with, to help pay more people to do more things on Core
220 2014-06-25 15:38:31 <hearn> until maybe one day it's as big as the kernel project is and you're the new linus ;)
221 2014-06-25 15:38:32 <hearn> ACTION ducks
222 2014-06-25 15:39:02 <petertodd> ACTION can't see Bitcoin Core ever becoming as large as Linux
223 2014-06-25 15:39:09 <GAit> companies have incentives to build the features and the things that bitcoin misses.
224 2014-06-25 15:39:18 <wumpus> petertodd: I wouldn't hope so, we should drop the 'core' again on the way at least :p
225 2014-06-25 15:40:06 <hearn> GAit: so where's your full time Core developer? ;) we have lots of small companies that can't really afford to pay a full time guy to work on stuff that isn't directly profitable for them. lots of tiny companies that are VC funded or only slightly profitable, etc. so the idea is, with an assurance contract, all these little companies can chip in maybe 5% each and everyone helps carry the load
226 2014-06-25 15:40:08 <petertodd> GAit: yeah, all my pull-reqs are things I'm getting paid for. heck, gavin's recent IsStandard() relaxing patch is something I had already written
227 2014-06-25 15:40:09 <wumpus> GAit: yes, although they usually have the incentive to do so in a centralized way, so they can act as gatekeepers and toll booths
228 2014-06-25 15:40:41 <GAit> hearn: I have a developer fully on core, not fulltime at the moment, preparing patches and things in our repo for a PR tomorrow
229 2014-06-25 15:40:45 <hearn> anyway, all this was discussed during the (very long i must say) interview with the podcast guys. the part where i said there weren't many people doing protocol upgrades was like 2 minutes worth
230 2014-06-25 15:41:01 <hearn> GAit: ok, that's cool!
231 2014-06-25 15:41:15 <petertodd> wumpus: it's a bit more complex than that: often otherwise centralized companies have incentives to have solid decentralized solutions too because their customers like them, something I'm seeing working with colored coins people for isntance
232 2014-06-25 15:41:30 <GAit> petertodd: not only coloredcoins :)
233 2014-06-25 15:42:01 <hearn> wumpus: actually I see coindesk quoted me as saying "almost nothing is happening on core development" which isn't what i said at all. sigh. not sure why it's so hard to transcribe an interview.
234 2014-06-25 15:42:21 <wumpus> hearn: right, so they have twisted your words, I hoped so :0
235 2014-06-25 15:42:23 <gavinandresen> GAit : tell your developer to let us know how the patch has been tested and if it is deployed already in your service, for me, at least, that carries a lot more weight than patches from Random People(tm)
236 2014-06-25 15:42:43 <petertodd> GAit: what's the patch(s)?
237 2014-06-25 15:42:50 <GAit> gavinandresen: sure thing
238 2014-06-25 15:43:45 <GAit> petertodd: so far just come clean ups, the idea was to start doing some clean up and get some relationship going, process etc and then move on to work on malleability
239 2014-06-25 15:43:51 <GAit> there's a lot of work to be done
240 2014-06-25 15:44:20 <petertodd> GAit: cool - for you guys for malleability I'd strongly suggest you look into developing a new CHECKSIG algorithm that doesn't sign txids
241 2014-06-25 15:44:36 <petertodd> GAit: I did a bit of work sketching out that stuff BTW
242 2014-06-25 15:44:45 <sipa> i'd do that as part of a larger 'script 2.0' plan
243 2014-06-25 15:45:10 <hearn> a "tx v3" project feels tractable to be in probably 2-3 months of full time work, assuming that includes development of more unit testing infrastructure
244 2014-06-25 15:45:13 <petertodd> sipa: I think part of script 2.0 is going to be figuring out how to split up the gigantic project...
245 2014-06-25 15:45:14 <hearn> *to me
246 2014-06-25 15:45:35 <hearn> where tx v3 is just the anti-malleability BIP, and putting value under the signature hash, and the consensus stuff around enforcing it when enough miners opt in
247 2014-06-25 15:45:37 <maaku> petertodd: split up what?
248 2014-06-25 15:45:51 <wumpus> petertodd: good point, huge projects where everything has to be first time right are almost impossible
249 2014-06-25 15:46:00 <maaku> hearn: value in the signature is a hard-fork, no?
250 2014-06-25 15:46:03 <petertodd> maaku: if we say everything is "script 2.0" and an entirely new system is all we're considering, we'll never do it
251 2014-06-25 15:46:06 <petertodd> maaku: no
252 2014-06-25 15:46:17 <sipa> it doesn't need to be a hard fork, no
253 2014-06-25 15:46:22 <sipa> but maybe it should be
254 2014-06-25 15:46:28 <hearn> maaku: yes txv3 has to be a hard fork. i think gavinandresen concluded a while ago we have to get over our fear of those. the block v2 fork didn't go too badly, and lots of what we need to do ends up being a fork
255 2014-06-25 15:46:35 <hearn> ok by "has" i mean "should" indeed
256 2014-06-25 15:46:40 <petertodd> wumpus: quite seriously we could get a *huge* amount of value with just CHECKSIG2 and CHECKLOCKTIMEVERIFY
257 2014-06-25 15:46:45 <hearn> it might be a bit tricky to pull that off
258 2014-06-25 15:46:45 <maaku> how is that possible? the signatures need to validate with or without the value included in the sig...
259 2014-06-25 15:46:56 <sipa> maaku: a OP_EVAL style structure
260 2014-06-25 15:46:58 <hearn> maaku: each tx has a version number attached to it
261 2014-06-25 15:47:01 <petertodd> maaku: you define a new CHECKSIG operator
262 2014-06-25 15:47:03 <sipa> with different semantics inside
263 2014-06-25 15:47:09 <hearn> maaku: so CHECKSIG can just know what the tx version is, and then change its behaviour on that
264 2014-06-25 15:47:19 <hearn> oh, ok, seems we all have different ideas about how that would work :)
265 2014-06-25 15:47:21 <maaku> ok that should really wait for script 2.0 though
266 2014-06-25 15:47:37 <sipa> well bip62 can just be a soft fork
267 2014-06-25 15:47:45 <sipa> i think everything else is a larger timeframe anyway
268 2014-06-25 15:47:51 <hearn> "script 2.0" sounds like a ground up rethink. how about txv2 or txv3 == script 1.1 :)
269 2014-06-25 15:47:55 <maaku> hearn: if you do that, old nodes won't validate the transactions though, so it's a hard fork
270 2014-06-25 15:47:58 <petertodd> sipa: and should be, there's no reason to be doing hardforks given damn near everything can be done as a softfork
271 2014-06-25 15:48:20 <sipa> especially for bip62, where the risk to clients is only when they opt in
272 2014-06-25 15:48:23 <hearn> maaku: so, for a long time i've believed soft forks are bugs. ideally all consensus changes would be hard forks.
273 2014-06-25 15:48:34 <hearn> maaku: the reason is, a soft fork effectively degrades a full node to SPV level security silently
274 2014-06-25 15:48:45 <petertodd> sipa: also, there's a huge ecosystem of alternate implementations and libraries that need to be considered, softforks don't need those libraries to be updated
275 2014-06-25 15:48:50 <gavinandresen> I'd vote for a script version 1.1. That signs input amounts, refers to previous inputs by an immutable ID, and uses Schnorr for signatures.
276 2014-06-25 15:49:00 <petertodd> gavinandresen: +1
277 2014-06-25 15:49:08 <hearn> and i'm not a huge fan of silent security downgrades .... even if it might seem to make things a bit easier.
278 2014-06-25 15:49:22 <gavinandresen> ⦠(oh, and is P2SH only)
279 2014-06-25 15:49:38 <hearn> gavinandresen: how easy is Schnorr signatures? they're a small adaptation of existing ecdsa code ?
280 2014-06-25 15:49:53 <sipa> yes, they're very easy
281 2014-06-25 15:49:54 <wumpus> I suppose the Schnorr part was a joke? :)
282 2014-06-25 15:50:07 <maaku> gavinandresen: there are *huge* improvements that can be made to script, if you are going just that far
283 2014-06-25 15:50:25 <petertodd> maaku: yes, there's also huge risk if you change a lot of stuff
284 2014-06-25 15:50:31 <hearn> someone who has been messaging me about bloom filters on the forum said today that he was scared by the large number of coins stacked up in a small number of addresses. he said a birthday attack on a 160 bit hash is probably tractable, if you don't care which of the addresses you steal you could probably build special hardware to do it
285 2014-06-25 15:50:31 <maaku> it's quite silly to have an intermediate hard-fork, or yet another template
286 2014-06-25 15:50:50 <maaku> petertodd: i'm talking about making it provably safer (e.g. strong typing)
287 2014-06-25 15:50:52 <sipa> hearn: birthday attack is irrelevant...
288 2014-06-25 15:51:06 <wumpus> oh I was confused with Lamport signatures for some reaason
289 2014-06-25 15:51:15 <petertodd> maaku: besides, we *know* that a small CHECKSIG change would be used, because we have the applications sitting right in front of us. more complex stuff we're not sure (IE, typing? so what?)
290 2014-06-25 15:51:17 <gavinandresen> maaku: okey dokey. We can't even seem to get consensus on UTXO commitments in blocks, don't know why you think we can get consensus on a complete overhaul of Script
291 2014-06-25 15:51:23 <petertodd> gavinandresen: +1
292 2014-06-25 15:51:45 <petertodd> notice how the only lack of consensus on a slightly upgraded CHECKSIG is coming from "but we're not going far enough!"
293 2014-06-25 15:51:59 <sipa> yeah, i'm all for upgrading checksig
294 2014-06-25 15:52:04 <hearn> maaku: if hard forks are easy, there's no real reason we can't get to script 2 by going script 1.1, script 1.2, script 1.3 etc
295 2014-06-25 15:52:07 <sipa> but i think it'd be a waste of effort to only do that
296 2014-06-25 15:52:32 <petertodd> sipa: well, just remember you're specifically talking about political effort here, not technical
297 2014-06-25 15:52:38 <sipa> yes
298 2014-06-25 15:52:45 <hearn> sipa: his point was basically if the world can apparently make ASICs for dogecoin, then an ASIC that brute forces hash160 (if you don't care what you steal) doesn't seem so unthinkable actually
299 2014-06-25 15:53:04 <gavinandresen> sipa: I think the sign-the-sum-of-inputs-amount is really important (SPV/hardware wallets), and we should have done that a couple years ago.
300 2014-06-25 15:53:32 <petertodd> I strongly suspect that the politics will be a lot saner if we don't make huge changes with lots of extra code in one go
301 2014-06-25 15:53:36 <hearn> anyway, i doubt it's anything to think about
302 2014-06-25 15:54:04 <Anduck> wouldn't it be better to target developing of the core system (scalability issues, dynamic fee structure, etc...) before different transaction types?
303 2014-06-25 15:54:06 <hearn> i think there are two difficult parts to getting consensus for any change. one is code review/testing. this is usually the "easy" bit assuming good programmers. the hard part is the fundamental differences over project principles
304 2014-06-25 15:54:29 <hearn> e.g. getutxo code is easy, but to what extent we care about pure-p2p SPV wallets is (apparently) not easy.
305 2014-06-25 15:54:42 <hearn> on the other hand, maybe schnorr signatures or whatever the code is hard and needs careful review, but the principles is easy
306 2014-06-25 15:54:43 <petertodd> well yeah, as I keep saying the code is the easiest part of bitcoin development
307 2014-06-25 15:56:02 <hearn> easy to say if you don't write much :p the coding part is what sucks up the hours. ultimately, implementations are much more expensive than ideas especially in a project that attracts a lot of academic attention like this one.
308 2014-06-25 15:56:10 <wumpus> hearn: the more cryptograpically difficult changes may be easier, as less people will have an opinion about them :p
309 2014-06-25 15:56:28 <hearn> wumpus: yes the politics is easier and the code review is harder :)
310 2014-06-25 15:58:17 <hearn> Anduck: the "different transaction types" we're talking about are quite minor changes, at least anything that would get implemented. they're important for tidying up various irritating problems with the protocol, improving performance, things like that.
311 2014-06-25 15:58:28 <hearn> Anduck: and gavin is already working on dynamic fee structure
312 2014-06-25 15:58:33 <wumpus> petertodd: from a high level the code may not be difficult, but there are just so many pesky details to worry about and things going on and that complicates things
313 2014-06-25 15:58:45 <petertodd> hearn: if you're time is getting sucked up in writing code you're probably not analyzing what it's doing very carefully
314 2014-06-25 15:58:46 <Anduck> hearn: alright
315 2014-06-25 15:59:28 <petertodd> wumpus: that's exactly my point - I mean, when i say "the code" I mean writing it, not the huge amount of work that needs to be done ensuring it's the right code and it actually works
316 2014-06-25 15:59:43 <hearn> the art is striking the right balance. insufficient analysis, you implement the wrong thing. too much and you get analysis paralysis where you spend all your time thinking about improbable what-ifs and your competitors zoom past you. projects have died for both reasons.
317 2014-06-25 16:00:05 <petertodd> wumpus: there's nothing in bitcoin where, for instance, the code uses complex algorithms or is difficult to understand what it's doing on the first order
318 2014-06-25 16:00:20 <wumpus> petertodd: there are just so many different concerns
319 2014-06-25 16:00:41 <gavinandresen> I dunno, the simulated annealing algorithm in SelectCoins is⦠uh⦠non-trivial
320 2014-06-25 16:00:49 <petertodd> wumpus: yup, and the second order effects of things tend to be highly subtle.
321 2014-06-25 16:00:52 <wumpus> petertodd: each in themselves may not be rocket science, but it's the sheer volume that keeps you down
322 2014-06-25 16:01:03 <petertodd> gavinandresen: yes, and that's the most complex example in the entire codebase
323 2014-06-25 16:01:13 <hearn> i remember first reading bitcoin when there was no documentation at all beyond the white paper
324 2014-06-25 16:01:41 <hearn> i'd certainly have disagreed that there was nothing that's hard to understand. these days the code is so well explored and the documentation is much better, maybe that can now be argued.
325 2014-06-25 16:02:01 <wumpus> petertodd: that's also why I'm trying to get rid of concerns (like the wallet) from bitcoin core, they just suck up a lot of attention without being our core focus
326 2014-06-25 16:02:05 <petertodd> hearn: I learned how bitcoin worked by reading the codebase you know
327 2014-06-25 16:02:12 <wumpus> hearn: it took me ages to reach the understanding of the code that I now have, and it's still not complete
328 2014-06-25 16:03:10 <petertodd> wumpus: we really should, and wallet code is something where there's going to be a lot of ways to do it that make sense. Heck, when i need input selection code, I usually just pick inputs at random. :P
329 2014-06-25 16:03:18 <gavinandresen> â¦. and that's the real problem with lack of core development. It takes a long time for even a very experienced programmer to get up to speed where they can be productive
330 2014-06-25 16:03:41 <GAit> gavinandresen: but so can be said of the kernel
331 2014-06-25 16:03:48 <gavinandresen> GAit: yes
332 2014-06-25 16:04:03 <wumpus> petertodd can easily talk about carefully analysing things, but there are just so many moving parts and subtle interactions, and at least historically the code was not very well compartimentalised/modularized
333 2014-06-25 16:04:21 <gavinandresen> That's why the Bitcoin Foundation was modeled on the Linux Foundation; similar issues. We just don't have a Red Hat yet.
334 2014-06-25 16:04:36 <wumpus> linux is very modular and well-organized, we have a long way to go :)
335 2014-06-25 16:04:37 <petertodd> wumpus: it took me ages to understand how *badly* I understood the code. it looked so simple at first compared to other codebases I'd worked on
336 2014-06-25 16:04:41 <GAit> a red hat is not enough either, you need red hat, suse, ibm
337 2014-06-25 16:04:48 <sipa> petertodd: absolutely
338 2014-06-25 16:04:52 <GAit> and eventually even microsoft contributing (i.e. amex or goldman sachs)
339 2014-06-25 16:05:08 <sipa> you often don't realize how badly you understand code until you try to modify it :)
340 2014-06-25 16:05:28 <petertodd> sipa: and with bitcoin, even after you modify it you don't realize you've introduced a subtle exploit :)
341 2014-06-25 16:05:44 <wumpus> right, there is also the pressure and fear of doing things wrong
342 2014-06-25 16:07:23 <GAit> well there should be that fear and more testing to protect ourselves as much as we can
343 2014-06-25 16:07:42 <hearn> i think gavinandresen is of the opinion that we should be less risk averse, actually
344 2014-06-25 16:08:17 <hearn> though i noticed on reddit the other day, i saw people complaining about the "bitcoin is an experiment" line. didn't see that before.
345 2014-06-25 16:08:18 <petertodd> GAit: what's hard is testing doesn't do a good job at uncovering security flaws
346 2014-06-25 16:08:23 <waxwing> gavinandresen, simulated annealing is used in bitcoin!? is that to solve the knapsack problem?
347 2014-06-25 16:08:27 <gavinandresen> yes, lots of parts of the code we could be less risk averse. Including potentially-consensus-breaking-changes, in my opinion
348 2014-06-25 16:08:31 <petertodd> GAit: e.g. gavin's fee estimation
349 2014-06-25 16:08:42 <hearn> i wonder if our community is moving into a new area where people stop accepting the idea that bitcoin could become worthless tomorrow
350 2014-06-25 16:08:46 <hearn> then it really _will_ be hard to change anything!
351 2014-06-25 16:09:02 <petertodd> gavinandresen: miners don't even want to upgrade to 0.9 in part because of fear of very expensive bugs, why make them even more afraid?
352 2014-06-25 16:09:04 <SomeoneWeird> I think that's already happened
353 2014-06-25 16:09:18 <Jouke> +1
354 2014-06-25 16:10:13 <gavinandresen> petertodd: benefits to them must outweigh the risks. And if they stay behind, they will get left behind.
355 2014-06-25 16:10:13 <hearn> why? because stagnation will ensure bitcoin never goes mainstream in any meaningful way, at this point. our competitors don't stop moving forward because they're afraid of risk, they manage it
356 2014-06-25 16:10:35 <gavinandresen> â¦as happened to that Russian mining pool that used to be the biggest (my forgetting-names-super-power is kicking in....)(
357 2014-06-25 16:10:46 <hearn> deepbit?
358 2014-06-25 16:10:52 <gavinandresen> thats it! deepbit!
359 2014-06-25 16:10:55 <Zarutian> hearn: I am eyeing etherium if bitcoin stagnates too much
360 2014-06-25 16:11:17 <hearn> Zarutian: when i say competitors, i'm usually thinking about existing financial networks actually.
361 2014-06-25 16:11:22 <petertodd> gavinandresen: good luck on that... as much as I'd like new opcodes and other fun stuff, I've found in the past that we can find work arounds to avoid changing the Bitcoin protocol an astonishingly large % of the time
362 2014-06-25 16:11:28 <hearn> Zarutian: IMHO our main competitors are not alt coins but rather credit cards
363 2014-06-25 16:11:30 <wumpus> the thing is also that for a lot of people, bitcoin already does what it should do
364 2014-06-25 16:11:41 <petertodd> heck, often those workarounds turn out to be better than our original ideas
365 2014-06-25 16:11:44 <petertodd> wumpus: +1
366 2014-06-25 16:11:58 <Jouke> hearn: do you have any idea what license lighthouse will get? It would be great to use at our local bitcoin foundation as well.
367 2014-06-25 16:12:08 <Apocalyptic> what wumpus said
368 2014-06-25 16:12:11 <wumpus> only a very small percentage of people really gets excited by, for example, what ethereum brings
369 2014-06-25 16:12:32 <petertodd> wumpus: indeed, and that % can always use ethereum :)
370 2014-06-25 16:12:37 <wumpus> cryptocurrency is still such a new thing in itself
371 2014-06-25 16:12:38 <gavinandresen> wumpus: sure, but we have to make sure it KEEPS doing what they want it to do. If transaction fees rise to $100 per transaction, I assure you people will not be happy.
372 2014-06-25 16:13:10 <hearn> Jouke: it's going to be tricky. i want to use lighthouse to raise the funds to open source lighthouse. obviously that means, it can't start out being open source, it will have to be crippled/proprietary in some way. and then we'll see how interested people are in that. it may start out restricted to only my projects. i'm not sure yet ... still planning this part out.
373 2014-06-25 16:13:13 <gavinandresen> ⦠so, in my opinion, we will need to give miners a much more efficient way to exchange very large blocks.
374 2014-06-25 16:13:13 <wumpus> gavinandresen: sure
375 2014-06-25 16:13:16 <petertodd> gavinandresen: there's *so* many solutions to that beyond changing the bitcoin protocol...
376 2014-06-25 16:14:39 <gavinandresen> petertodd: okey dokey. I look forward to reading your whitepaper about that.
377 2014-06-25 16:15:10 <petertodd> gavinandresen: thing is, I don't *need* to write One Whitepaper To Rule Them All about that, precisely because there's a diversity of solutions that other people are already working on
378 2014-06-25 16:15:36 <gavinandresen> petertodd: and that's a great thing. I like diversity. I also like simplicity and hate hard-coded constants.....
379 2014-06-25 16:15:43 <petertodd> heck, I strongly suspect in the end tree chains will go nowhere precisely because it's a One Solution to Rule Them All...
380 2014-06-25 16:16:08 <hearn> ... or because nobody implements it
381 2014-06-25 16:16:27 <petertodd> gavinandresen: the 1MB blocksize is a fundemental economic parameter of the system. Don't be surprised that changing the definition of what Bitcoin is turns out to be controversial.
382 2014-06-25 16:16:31 <hearn> i do rather disagree with your ideas about coding. the idea that all the effort is thinking and design and then the code practically writes itself does not match my experience on any real project.
383 2014-06-25 16:16:49 <hearn> oh god. not block size limits again.
384 2014-06-25 16:16:50 <petertodd> hearn: meh, we've worked on different types of projects with different risks involved
385 2014-06-25 16:17:42 <petertodd> anyway, discussing blocksize with gavin is a waste of time, later
386 2014-06-25 16:18:01 <hearn> yes, i've worked on projects that could have broken all of google multiple times. i have worked on projects where a screwup is measured in hundreds of thousands of dollars a minute. i am guessing you have not.
387 2014-06-25 16:19:39 <GAit> is there #bitcoin-previous-job-horror-stories? i can contribute a bit too!
388 2014-06-25 16:19:57 <waxwing> hearn, i worked in a company where the average tx size was ~ 1 million usd, and another where the average tx size was in the pennies. The biggest difference was in the former, the core software was basically never changed :)
389 2014-06-25 16:20:22 <hearn> i think my nightmare software scenario would be HFT software
390 2014-06-25 16:20:34 <hearn> the Knight Capital disaster was one for the history books ...
391 2014-06-25 16:20:35 <waxwing> i also briefly worked as a nuclear engineer. It was even worse there :) Codebase was 40 years old.
392 2014-06-25 16:20:45 <Jouke> hearn: maybe we can work something out like our foundation raising money for the development of lighthouse and in return be able to use lighthouse for all the other projects at our foundation?
393 2014-06-25 16:20:54 <hearn> haha ok. you win. nuclear meltdown is probably worse than google going offline for a few minutes
394 2014-06-25 16:20:59 <waxwing> or maybe 30, possibly i exaggerate :)
395 2014-06-25 16:21:00 <hearn> er, scratch the "probably"
396 2014-06-25 16:21:04 <daybyter> HFT...cool....
397 2014-06-25 16:21:07 <AndersAA> Is Bitcoin a safety-critical project, where a bug could potentially cost someone's life? Should it be treated as such?
398 2014-06-25 16:21:16 <GAit> hearn: had friends telling me about how some HFT has moved to FPGA
399 2014-06-25 16:21:26 <hearn> Jouke: Ah, you mean you get to use it if you pledge to the eventual open sourcing? neat idea ..... will definitely consider that model!
400 2014-06-25 16:22:04 <hearn> GAit: the last one i heard was the algorithms being run on the NIC firmware. so yeah i can believe FPGA
401 2014-06-25 16:22:23 <hearn> though i think there's an agility/performance tradeoff there. it's not all about speed, ability to adapt to new algorithms quickly also makes a big difference
402 2014-06-25 16:22:24 <hearn> (from what i heard)
403 2014-06-25 16:23:03 <waxwing> 'Flash Boys' is an interesting read.
404 2014-06-25 17:12:53 <phantomcircuit> AndersAA, that is exactly how it should be treated
405 2014-06-25 17:13:07 <phantomcircuit> if you consider the typical insurance value of a human life: 1-2m usd
406 2014-06-25 17:13:18 <phantomcircuit> bitcoins is worth several thousand peoples lives
407 2014-06-25 17:13:34 <phantomcircuit> (although not really of course)
408 2014-06-25 17:15:38 <andytoshi> can i translate a CWalletTx into a CCoins?
409 2014-06-25 17:18:54 <andytoshi> oh, i'm an idiot, the CCoins constructor does that
410 2014-06-25 17:22:12 <sipa> it takes a CTransaction, which CWalletTx is a subclass of
411 2014-06-25 17:22:15 <sipa> so yes
412 2014-06-25 17:38:55 <Luke-Jr> what would a CCoins(CTransaction) be useful for? it's the unspent outputs from the transaction? O.o
413 2014-06-25 17:40:14 <andytoshi> Luke-Jr: for explainrawtransaction https://github.com/bitcoin/bitcoin/pull/4226
414 2014-06-25 17:43:41 <dekalo> CCoins contains metadata about a tx and serialized data that describes it's outputs states (spent/unspent/fromcoinbase)
415 2014-06-25 17:44:01 <sipa> and height :)
416 2014-06-25 17:44:41 <dekalo> tnx sipa, i'm studing codebase to understand mine problem with signrawtransaction, but is the first time that i read c++ code
417 2014-06-25 17:45:58 <dekalo> anycase, referring back to the speech that they did before, i can say that the code is quite readable :-)
418 2014-06-25 17:46:30 <sipa> i suggest you download 0.3.17 or so, and have a look at that :)
419 2014-06-25 17:47:18 <sipa> hilights: wallet was in main.cpp, and did direct callbacks to the gui, and inside script there was a callback to the validation code to mark an input as spent :p
420 2014-06-25 17:48:39 <upb> sounds like solid software engineering
421 2014-06-25 17:49:06 <gavinandresen> sipa: I'm debugging a unit test failure related to CMutableTransaction, compiled -g3 on OSX
422 2014-06-25 17:49:38 <gavinandresen> sipa: it is the DoS_checkSig test, testing to see if the signature cache is effective.
423 2014-06-25 17:50:40 <gavinandresen> sipa: what is happening: the VerifySignature-five-times code is taking longer than the SignSignature-once code. Found a fix, but am curious about why it is failing for me
424 2014-06-25 17:51:01 <gavinandresen> Fix is: Use CMutableTransaction to sign, assign to a CTransaction before doing the 5-Verifys.
425 2014-06-25 17:51:15 <gavinandresen> ⦠which I think matches what the core code will be doing (but I haven't looked)
426 2014-06-25 17:52:23 <sipa> gavinandresen: why do we care about signing speed at all?
427 2014-06-25 17:52:50 <sipa> i think i had to remove that test in the libsecp256k1 integration, because it's not significantly slower anymore
428 2014-06-25 17:52:53 <gavinandresen> sipa: we don't⦠but Sign does a Verify as a sanity-check
429 2014-06-25 17:53:58 <gavinandresen> sipa: ok, sounds like removing that test instead of fixing it is the right thing to do
430 2014-06-25 17:54:30 <sipa> yeah, it's expected with the cmutable conversion that signing/... are slightly slower, and need more allocation/heap pressure
431 2014-06-25 17:55:08 <sipa> there's unnecessary copying, but avoiding it made the code much harder
432 2014-06-25 17:55:26 <gavinandresen> ⦠and signing is rare, so that's fine.
433 2014-06-25 17:56:28 <gavinandresen> I'll submit a patch to remove that unit test; I don't see an easy way to Sign and then Verify-first-time-which-should-be-slow but then Verify-repeatedly-which-should-use-the-cache-and-be-fast
434 2014-06-25 17:56:49 <gavinandresen> (can't time the Verify-first-time-which-should-be-slow separately from Sign)
435 2014-06-25 17:57:18 <sipa> we should benchmark how much the cache still adds with libsecp256k1
436 2014-06-25 17:57:21 <dekalo> sipa: ok, now is heaven
437 2014-06-25 17:57:36 <sipa> i expect it to be still be useful, but less than a factor 5 :)
438 2014-06-25 17:57:44 <gavinandresen> sipa: yup. If I recall, there's an obscure command-line param to disable the cache. I think.
439 2014-06-25 17:57:45 <gmaxwell> sipa: the cache is still helpful re-DOS attacks, I expect.
440 2014-06-25 17:57:57 <sipa> maybe an unordered_map for the cache helps
441 2014-06-25 17:59:03 <gmaxwell> sipa: Did you see Dettman has a new non-trivial algorithmic speedup now?
442 2014-06-25 17:59:14 <sipa> gmaxwell: of course
443 2014-06-25 17:59:24 <sipa> the co-Z technique?
444 2014-06-25 17:59:28 <gmaxwell> Yes.
445 2014-06-25 17:59:51 <sipa> i love all he is doing... except reviewing it all :)
446 2014-06-25 18:00:02 <AndersAA> phantomcircuit: I have a feeling there's not really consensus between devs on that.
447 2014-06-25 18:00:09 <gmaxwell> On the plus side, he's also reviewing a lot of your existing code.
448 2014-06-25 18:00:40 <sipa> gmaxwell: i expecially like "i think this is wrong... wait, no it isn't!"
449 2014-06-25 18:02:28 <sipa> gmaxwell: i should benchmark the pre-dettman code compared to head :)
450 2014-06-25 18:03:36 <gavinandresen> AndersAA phantomcircuit : bitcoin core is not life-or-death code. $5,000 per person spread across a million people will not kill anybody, and we repeatedly warn people to only put in what they can afford to lose.
451 2014-06-25 18:04:21 <gavinandresen> â¦. it just feels like it is life-or-death sometimes....
452 2014-06-25 18:04:55 <sipa> gavinandresen: even if every personal investor accepts that risk, we have a ton of companies that have a lot of stake in stability...
453 2014-06-25 18:05:27 <gavinandresen> yes, but companies dying is nowhere near as bad morally as people dying
454 2014-06-25 18:05:43 <sipa> couldn't agree more there :)
455 2014-06-25 18:05:54 <gavinandresen> ⦠and the comparisons being made were nuclear reactors and other "lots of people will die if you screw up" projects
456 2014-06-25 18:11:26 <AndersAA> gavinandresen: I suppose the question is more if it should be treated in the same careful and conservative manner? Do you believe there is broad consensus on how pull requests should be treated? It's hard to differentiate between "security-critical" in the ReadMe and safety-critical.
457 2014-06-25 18:13:23 <jgarzik> sipa, Do you recall the UniValue/bitcoin-tx criticism you had, besides "{" styling? I cannot find it on github
458 2014-06-25 18:13:35 <gavinandresen> AndersAA: it will always be a matter of judgement, and depends on what is being added or changed. A new RPC method needs less scrutiny than a new p2p protocol message, which needs less than a change to the core consensus code.
459 2014-06-25 18:14:18 <sipa> the most fundamental distinction is whether changes only affect the reference client as one-of-many clients, or whether it affects the network as a whole
460 2014-06-25 18:14:40 <sipa> jgarzik: not immediately, but i'll look again
461 2014-06-25 18:15:01 <gavinandresen> crap, lost my commit message because gpg timed out asking me for my passwordâ¦â¦. grumble grumble signing commits grumble grumble......
462 2014-06-25 18:15:19 <gavinandresen> git doesn't stash that commit message somewhere, does it?
463 2014-06-25 18:17:31 <AndersAA> But do most developers agree on whether a pull request should be treated as security-critical or not? There seems to be some disagreement when you look at getutxos by hearn - the general principles applied when reviewing that is.
464 2014-06-25 18:18:22 <phantomcircuit> gavinandresen, strictly speaking if we all could put on our actuary hats for a minute, bitcoin is the equivalent of life critical systems
465 2014-06-25 18:18:28 <sipa> AndersAA: security has nothing to do with that
466 2014-06-25 18:18:46 <phantomcircuit> of course i wouldn't trade someones life for bitcoin
467 2014-06-25 18:18:58 <phantomcircuit> but treating it as such isn't unreasonable
468 2014-06-25 18:19:18 <gavinandresen> phantomcircuit: we'll get into a utilitarian debate over whether tickling ten billion people with a feather is as bad morally as killing one......
469 2014-06-25 18:19:37 <sipa> depends whether i'm part of those 10 billion
470 2014-06-25 18:19:42 <phantomcircuit> sipa, :P
471 2014-06-25 18:19:44 <jgarzik> phantomcircuit, gavinandresen: RE bitcoin akin to life critical systems, https://twitter.com/petertoddbtc/status/480811790616371200
472 2014-06-25 18:20:29 <AndersAA> sipa: How so? How carefully code should be reviewed (/ACK'ed or not) must have an impact on security?
473 2014-06-25 18:20:37 <gavinandresen> jgarzik: yup.
474 2014-06-25 18:20:56 <sipa> AndersAA: not sure what you're asking?
475 2014-06-25 18:20:58 <gavinandresen> jgarzik: I mean: yup, another place where Peter and I fundamentally disagree.
476 2014-06-25 18:21:26 <AndersAA> sipa: oh, you mean the actual PR has nothing to do with security?
477 2014-06-25 18:21:31 <sipa> AndersAA: yes
478 2014-06-25 18:21:44 <sipa> AndersAA: it's a suggested addition to the protocol
479 2014-06-25 18:24:23 <AndersAA> sipa: Got it.
480 2014-06-25 18:26:56 <phantomcircuit> sipa, hmm i disagree with that actually, making something available which can be trivially used to produce supremely insecure nodes is a security concern
481 2014-06-25 18:27:09 <AndersAA> gavinandresen: Why do you disagree with petertodd's comparison to medical and avionics? (Trying to understand dev. process here - and possible disagreements)
482 2014-06-25 18:27:28 <phantomcircuit> indeed adding unnecessary and insecure method of operation was exactly how the NSA subverted a number of protocols
483 2014-06-25 18:27:35 <phantomcircuit> (ipsec being a prime example)
484 2014-06-25 18:28:11 <gavinandresen> AndersAA: because airplanes don't crash out of the sky if we screw up. Worst case is some people lose some wealth.
485 2014-06-25 18:29:35 <gavinandresen> AndersAA: not to mention the different deployment environment. We can, and do, ask people using our software to update it to fix bugs. That is much harder and more expensive if your software is embedded deep in the guts of an airplane or a defribullator-doohickey
486 2014-06-25 18:29:45 <gavinandresen> de-fribbulator.
487 2014-06-25 18:29:52 <gavinandresen> de-fubbulator.
488 2014-06-25 18:30:07 <gavinandresen> I like that word. WIsh I knew how to spell it.
489 2014-06-25 18:30:19 <sipa> defibrillator?
490 2014-06-25 18:30:24 <gavinandresen> thats it!
491 2014-06-25 18:31:41 <AndersAA> gavinandresen: So you disagree with the comparison(made by I don't know who) that Bitcoin - due to potential hardforking - is like working on a 747 mid-air?
492 2014-06-25 18:32:15 <sipa> though i agree with the distinction that no human lives are at risk... the stakes are pretty high
493 2014-06-25 18:32:16 <gavinandresen> AndersAA: I think the comparison I've made is changing the tires on a car while it is driving down the highwayâ¦.
494 2014-06-25 18:32:37 <gavinandresen> Stakes are definitely high. Just not "nuclear/medical/avionics" high.
495 2014-06-25 18:32:38 <jgarzik> I don't. Worst case is a lot of people lose a lot of wealth. Nobody will instantly die, but the change risk is very high.
496 2014-06-25 18:33:01 <jgarzik> Actuarially, the value risked is higher than human life, according to insurance standards.
497 2014-06-25 18:33:22 <waxwing> higher than *a* human life, presumably :)
498 2014-06-25 18:33:40 <jgarzik> yes :)
499 2014-06-25 18:33:41 <phantomcircuit> jgarzik, which was my point, the value risked is approximately 3500 human lives by actuarial standards
500 2014-06-25 18:33:51 <jgarzik> 9/11!!!
501 2014-06-25 18:33:52 <jgarzik> ACTION runs
502 2014-06-25 18:34:01 <gavinandresen> I don't agree with that kind of accounting, that leads to the "tickle enough people and that's the same as killing one person"
503 2014-06-25 18:34:10 <jgarzik> "This could be bitcoin's 9/11" heh heh
504 2014-06-25 18:34:23 <phantomcircuit> gavinandresen, bad analogy, lots of people really enjoy being tickled
505 2014-06-25 18:34:30 <sipa> ACTION DOES NOT
506 2014-06-25 18:34:31 <phantomcircuit> ACTION runs
507 2014-06-25 18:34:43 <AndersAA> jgarzik gavinandresen sipa: Do you believe this disagreement over how the code/project should be treated is a problem for the project?
508 2014-06-25 18:34:48 <waxwing> gavinandresen, that's what taleb means by convexity
509 2014-06-25 18:34:52 <sipa> i think it's inevitable
510 2014-06-25 18:35:06 <gavinandresen> AndersAA: you're the one writing a paper about open source projects?
511 2014-06-25 18:35:14 <AndersAA> gavinandresen: Yes.
512 2014-06-25 18:35:39 <sipa> having someone in control makes decision-making easier; it doesn't necessarily make it better
513 2014-06-25 18:36:13 <jgarzik> AndersAA, I already explained this. This is normal for all projects. It is more normal for open source projects. All disagreements are typically out in the open. Everybody has a different opinion.
514 2014-06-25 18:36:14 <maaku> AndersAA: we've already crossed a threshold where consensus is no longer possible over large enough changes
515 2014-06-25 18:36:25 <jgarzik> AndersAA, You really should research open source projects first, like Linux.
516 2014-06-25 18:36:41 <jgarzik> maaku, horseshit
517 2014-06-25 18:37:05 <maaku> jgarzik: you pay attention to the github threads?
518 2014-06-25 18:37:44 <jgarzik> maaku, no I'm completely unaware of anything that goes on on github
519 2014-06-25 18:37:45 <AndersAA> jgarzik: I'm also making a comparison to the linux kernel project, so I have to ask some of the same questions to figure out how the Bitcoin project is different(or not).
520 2014-06-25 18:40:02 <gavinandresen> Bitcoin is just smaller and less mature. And the Creator is not around to be Benevolent Dictator For Life.
521 2014-06-25 18:40:16 <jgarzik> +1
522 2014-06-25 18:40:46 <gavinandresen> Hopefully wumpus doesn't mind being Benevolent Dictator for the next little while.....
523 2014-06-25 18:41:38 <gavinandresen> At least until there are eleven different implementations, all with their own Dictators. Which is when somebody will be organizing Dictator Summits......
524 2014-06-25 18:42:07 <maaku> i'm not sure the benevolent dictator model fits here
525 2014-06-25 18:42:17 <jgarzik> gavinandresen, Reminds me of a Starship Troopers quote: "I need a corporal. You're it, until you're dead or I find someone better." http://www.imdb.com/title/tt0120201/quotes?item=qt0257102
526 2014-06-25 18:43:06 <jgarzik> maaku, Yes, not even that. The ultimate dictator is the user base, who may simply ignore any new dictator.
527 2014-06-25 18:43:47 <gavinandresen> maaku: you involved with other open source projects that work under another model? I'm always curious to hear about other ways of working that work.
528 2014-06-25 18:43:49 <jgarzik> devs are more like chief mechanics, who occasionally add in upgrades to make the car run better, or do some new thing. But devs are not the drivers/pilots.
529 2014-06-25 18:45:48 <waxwing> we no longer need drivers. google has that technology :)
530 2014-06-25 18:46:11 <phantomcircuit> gavinandresen, dictator summits
531 2014-06-25 18:46:15 <phantomcircuit> sounds like fun
532 2014-06-25 18:47:15 <sipa> everyone there will be like "No, *I* am King of the Andals and the First Men, Lord of the Seven Kingdoms and Protector of the Realm"
533 2014-06-25 18:47:23 <AndersAA> A big difference between Bitcoin- and Linux-implementations is that forking Linux has no critical consequences and Bitcoin can't fork the Core/protocol. <-- How do you view this statement?
534 2014-06-25 18:48:19 <sipa> oh, you certainly can fork the core, and protocol implementations
535 2014-06-25 18:48:27 <sipa> but you can't fork the consensus rules
536 2014-06-25 18:48:48 <sipa> and forking their implementation is hard to avoid, if you're forking the rest
537 2014-06-25 18:50:33 <AndersAA> sipa: Thank you.
538 2014-06-25 18:51:01 <phantomcircuit> sipa, ha
539 2014-06-25 18:56:04 <gwillen> 11:47:14 < sipa> everyone there will be like "No, *I* am King of the Andals and the First Men, Lord of the Seven Kingdoms and Protector of the Realm"
540 2014-06-25 18:56:07 <gwillen> sipa: bahahahahahaha.
541 2014-06-25 19:27:29 <ubuntuDoubts> yoyoyo
542 2014-06-25 19:28:38 <ubuntuDoubts> Hey mates, does its possible compile bitcoin on digital ocean VPS with 1gb ram ?
543 2014-06-25 19:28:53 <ubuntuDoubts> Failing me, memory exhausted :(
544 2014-06-25 19:29:02 <pigeons> ubuntuDoubts: ask in #bitcoin
545 2014-06-25 19:29:49 <sipa> use -j1
546 2014-06-25 19:30:29 <ubuntuDoubts> -jl ?
547 2014-06-25 19:31:36 <sipa> no, -j1
548 2014-06-25 19:31:37 <sipa> to make
549 2014-06-25 19:31:46 <sipa> to make it build single threadedly
550 2014-06-25 19:32:03 <ubuntuDoubts> so instead of use make i should use -jl ?
551 2014-06-25 19:32:31 <ubuntuDoubts> -jl -f makefile.unix ?
552 2014-06-25 19:32:44 <sipa> we don't have makefile.unix anymore