1 2013-11-05 00:00:34 <MC1984> well not more urgent than all the other issues
  2 2013-11-05 00:01:24 <gmaxwell> MC1984: I mean, I don't know if its actually pratically exploitable in any degree, if it is exploited it would be very visible (creating lots of orphans)
  3 2013-11-05 00:01:46 <MC1984> would it even matter
  4 2013-11-05 00:04:17 <MC1984> maybe it would. Maybe people would get angry.
  5 2013-11-05 00:05:57 <MC1984> maybe p2pool would start being a thing then
  6 2013-11-05 00:08:20 <MC1984> welp time for bed
  7 2013-11-05 00:18:14 <HaltingState> is anyone doing the selfish miner attack yet lol
  8 2013-11-05 00:22:06 <HaltingState> gmaxwell, one solution is to time stamp the blocks and have the honest miners continue on blocks based upon time stamp
  9 2013-11-05 00:22:23 <gmaxwell> ...
 10 2013-11-05 00:22:33 <HaltingState> and just ignore the blocks that would cause orphans if they are within 2 blocks of last public
 11 2013-11-05 00:22:39 <gmaxwell> ...
 12 2013-11-05 00:23:23 <gmaxwell> HaltingState: Neither of these are remotely sensible proposals.
 13 2013-11-05 00:23:59 <gmaxwell> HaltingState: I don't have time to play distributed systems 101 today, sadly. But I'm sure you'll figure out why I'm giving you a wtf look if you think about it for a while. :)
 14 2013-11-05 00:26:50 <HaltingState> gmaxwell, your right; hmm however, simplier attack is just having mining pools agree to mine each others blocks and attempt to orphan blocks from other pools when possible
 15 2013-11-05 00:26:57 <HaltingState> and i dont think that can be prevented
 16 2013-11-05 00:27:20 <HaltingState> the problem here is that an individual pool can do this attack with coordinating with other pools; but dont think it matters
 17 2013-11-05 00:32:21 <gmaxwell> HaltingState: that doesn't do anything useful unless the cartel is a majority hashrate.
 18 2013-11-05 00:32:36 <gmaxwell> (unless I misunderstood what you were saying there)
 19 2013-11-05 00:32:41 <HaltingState> ah; they have to keep the blocks secret
 20 2013-11-05 00:32:49 <HaltingState> in order to derive the advantage
 21 2013-11-05 00:33:15 <gmaxwell> not just secret, secret and then they have to announce as late as possible and still beat compeating blocks.
 22 2013-11-05 00:35:05 <brocktice> do yourselves a favor, don't read the slashdot discussion on that paper...
 23 2013-11-05 00:35:17 <Sorcier_FXK> :D
 24 2013-11-05 00:42:46 <Apocalyptic> Sorcier_FXK, are you involved in bitcoin developpement somehow ?
 25 2013-11-05 00:42:53 <Sorcier_FXK> no
 26 2013-11-05 00:43:02 <Sorcier_FXK> just a farmer
 27 2013-11-05 00:43:42 <Apocalyptic> your nick looks familiar, i may have seen it during some CTFs
 28 2013-11-05 00:44:13 <Sorcier_FXK> maybe ^^
 29 2013-11-05 00:44:23 <sipa> gmaxwell: for the key derivation, you don't need them
 30 2013-11-05 00:44:39 <sipa> gmaxwell: there is a link to a page with intermediate results for the test vectors
 31 2013-11-05 00:47:34 <sipa> brocktice: thanks for the advice
 32 2013-11-05 00:48:19 <gulli_> Could you guys look at this picture and give me some pointers. There is probably a lot wrong and I need to think more about it, just trying to see how I could orginize things. I am, as I said before, creating a bitcoin <-> Game currency exchange
 33 2013-11-05 00:48:23 <gulli_> https://notendur.hi.is/~glf/plan.png
 34 2013-11-05 00:52:15 <Apocalyptic> gulli_, i wouldn't go with Java
 35 2013-11-05 00:52:32 <gulli_> why not?
 36 2013-11-05 01:50:37 <Evilmax> ;;blocks
 37 2013-11-05 01:50:38 <gribble> 267999
 38 2013-11-05 01:54:26 <HaltingState> brocktice, "Indeed, the built-in deflation ensures an eventual collapse, especially in the presence of alternatives currencies." they are smoking crack
 39 2013-11-05 01:54:42 <HaltingState> the coin supply inflates and then it becomes fixed
 40 2013-11-05 01:54:50 <HaltingState> and that is somehow "deflation"?
 41 2013-11-05 01:55:07 <beethoven8201> HaltingState: coins also get destroyed
 42 2013-11-05 01:55:08 <HaltingState> you could say "google stock is deflationary"
 43 2013-11-05 01:55:20 <HaltingState> and therefore google stock must collapse!
 44 2013-11-05 01:55:26 <HaltingState> but people are buying it because they expect it to go up
 45 2013-11-05 01:55:41 <HaltingState> what does "its deflationary and therefore must collapse" even mean!?
 46 2013-11-05 01:55:57 <HaltingState> "it goes up and therefore must go down?" i cant understand what he is trying to communicate
 47 2013-11-05 01:57:27 <HaltingState> people used to use sea shells and beads as currency... *sigh*
 48 2013-11-05 01:59:02 <HaltingState> gmaxwell, https://bitcointalk.org/index.php?topic=324413.msg3476697#msg3476697 good post
 49 2013-11-05 01:59:34 <HaltingState> sybil attack should not be issue; just have the large mining pools direct connect with each other and RSA sign communications etc.. then non-issue
 50 2013-11-05 02:00:29 <Apocalyptic> RSA sign ?
 51 2013-11-05 02:01:08 <HaltingState> can authenticate nodes http://en.wikipedia.org/wiki/RSA_(algorithm)#Signing_messages
 52 2013-11-05 02:01:53 <HaltingState> have node for your mining and pool and say "only these people can connect to it" and they have to prove identies, or could use simple password etc but then each mining pool has to exchange information with every other pool
 53 2013-11-05 02:01:53 <sipa> HaltingState: adding trusted links between miners is something they'll probably do anyway
 54 2013-11-05 02:01:55 <Apocalyptic> I know about RSA thank you very much
 55 2013-11-05 02:02:19 <sipa> supported for authentication on P2P is certainly a useful improvement, but be careful to call it the solution
 56 2013-11-05 02:02:20 <HaltingState> so you add the rsa key to the "trusted node" list
 57 2013-11-05 02:02:33 <Apocalyptic> i just don't know where that came from, and for auth purposes i would use another crypto  than RSA
 58 2013-11-05 02:02:35 <sipa> as relying on it decreases the ability to mine anonymously
 59 2013-11-05 02:02:53 <sipa> yeah, we use ECDSA for everything already; better stick with just one
 60 2013-11-05 02:02:59 <Apocalyptic> HaltingState, by design there shouldn't be such things as "trusted node" to even begin with
 61 2013-11-05 02:03:02 <sipa> it's far superior to RSA also
 62 2013-11-05 02:03:05 <Apocalyptic> and what sipa said
 63 2013-11-05 02:03:15 <HaltingState> the problem in altcoins with the orphaned blocks could probably be solved if network propagation of blocks was improved; i think the alt coins are being sybil attacked for economic advantage, expecially at launch
 64 2013-11-05 02:03:16 <sipa> in performance and size of signatures
 65 2013-11-05 02:03:59 <gmaxwell> HaltingState: those "altcoins" have screwed up their settings and have blocks far too close togeather.
 66 2013-11-05 02:04:00 <sipa> miners probably are already establishing trusted links between eachother
 67 2013-11-05 02:04:09 <sipa> (though not authenticated)
 68 2013-11-05 02:05:05 <HaltingState> gmaxwell, i dont see why 15 second blocks should not be possible; with the network propagation so slow because of sybil attacks.. its ratio of block time to time to propagate blocks across network i think
 69 2013-11-05 02:05:43 <sipa> HaltingState: the block interval should be >> average propagation delay through the network
 70 2013-11-05 02:06:00 <sipa> HaltingState: i'm sure large blocks already take more than 15s to propagate
 71 2013-11-05 02:06:04 <gmaxwell> HaltingState: because no matter how awesome the software is the speed of light and bandwidth of links is finite.
 72 2013-11-05 02:06:09 <sipa> without any attacks
 73 2013-11-05 02:06:19 <gmaxwell> and it's not good enough to be less it must be much less.
 74 2013-11-05 02:08:30 <Vinnie_win> Anyone wanna work on rippled with me?
 75 2013-11-05 02:08:34 <HaltingState> instead of 15 minute blocks, make the blocks 10 times as frequent but 1/10th the size; then the bandwidth/s is constant and block chain growth constant
 76 2013-11-05 02:09:17 <gmaxwell> man I shouldn't have mentioned bandwidth. I need to learn never make two arguments because people will go after the weaker one.
 77 2013-11-05 02:09:25 <gmaxwell> HaltingState: speed of light.
 78 2013-11-05 02:09:26 <HaltingState> capping block size would force people to pay higher transaction fees and make people bid to get into the block, which might be interesting for the end game
 79 2013-11-05 02:10:05 <sipa> HaltingState: maybe, but irrelevant to this discussion
 80 2013-11-05 02:10:23 <HaltingState> gmaxwell, the speed of light issue is not too bad; i wrote video game in C++ and I am in california and playing someone in Australia on other side of world almost and ping is 280 ms
 81 2013-11-05 02:10:37 <HaltingState> so round trip around planet cant be more than a second
 82 2013-11-05 02:10:38 <sipa> HaltingState: but it's not just one link
 83 2013-11-05 02:10:51 <phantomcircuit> HaltingState, dear god 280ms on a real time game is unplayable
 84 2013-11-05 02:10:55 <gmaxwell> HaltingState: 18:06 <@gmaxwell> and it's not good enough to be less it must be much less.
 85 2013-11-05 02:11:11 <sipa> HaltingState: it's a random graph, sending blocks and transactions from one peer to another
 86 2013-11-05 02:11:21 <sipa> we're not talking about the time from one node to another
 87 2013-11-05 02:11:33 <sipa> we're talking about the time from _any_ miner to _every_ node
 88 2013-11-05 02:11:34 <HaltingState> phantomcircuit, no; you do physics updates 15/second and you interpolate between physics updates and you do client side prediction and you add a 150 ms lag between when player pushes button and when it does it
 89 2013-11-05 02:12:09 <HaltingState> and you dont even notice it; latency is not as much a problem as "jitter"; as long as latency is constant people adapt (if its implemented correctly)
 90 2013-11-05 02:12:38 <sipa> and as gmaxwell says, that propagation delay (including processing done at every step, going through kernel and application buffers, processing queues, ...) must be much smaller still than the average block time
 91 2013-11-05 02:13:13 <sipa> otherwise you're going to create an incentive for miners or attackers to collude (as colluding nodes don't have the orphaning disadvantage from latency)
 92 2013-11-05 02:13:14 <HaltingState> gmaxwell, is correct; i am not disagreeing/
 93 2013-11-05 02:13:20 <phantomcircuit> HaltingState, lol i notice anything more than 80ms lag playing css
 94 2013-11-05 02:13:27 <sipa> 15s is way too low
 95 2013-11-05 02:13:35 <phantomcircuit> and that's with valves fairly sophisticated hitbox stuff
 96 2013-11-05 02:13:36 <sipa> maybe 2-3 minutes would have been doable
 97 2013-11-05 02:13:50 <sipa> but meh, not even an order of magnitude difference with what we have
 98 2013-11-05 02:14:40 <HaltingState> i think 15 second is possible and lower limit is probably 5 seconds; but would require direct links between all the major mining pools; might also require just sending the PoW header and block information to validate block and then sending the data/payload asynchronously
 99 2013-11-05 02:14:42 <phantomcircuit> sipa, i've seen observed propogation delay to nodes that are remotely connectable of 60 seconds
100 2013-11-05 02:15:51 <sipa> HaltingState: if we're relying on direct links between miners, something is fundamentally broken
101 2013-11-05 02:16:42 <sipa> 
ACTION zZzZ

102 2013-11-05 02:17:13 <HaltingState> 60 seconds delay is interesting; if there is a cartel of miner pools with direct links who is also sybil attacking to delay other blocks from propagating then everyone in the cartel pools makes more money and everyone else suffers, but its still secure and still works; just a bit unfair to smaller pools
103 2013-11-05 02:17:37 <sipa> "unfair to smaller pools" == centralization
104 2013-11-05 02:17:43 <gmaxwell> HaltingState: go compute the orphaning rates for that even if you assume the network has a one second delay, they're enormous and that results in huge dillution which is advantagious for hashrate consolidated attackers.
105 2013-11-05 02:18:32 <gmaxwell> E.g. 1 sec in lambda = 1/5 seconds is some thing like 18%
106 2013-11-05 02:18:54 <HaltingState> ahhh i see. orphan rate is ratio of propagation time to block time and you want block time to be many multiples of propagation time
107 2013-11-05 02:19:18 <sipa> HaltingState: not ratio, but close to it
108 2013-11-05 02:19:58 <gmaxwell> HaltingState: it's an exponential function, not a ratio but yea. It needs to be many multiplies to prevent high orphaning (and dillution, and centeraization advantages) from being an isuse.
109 2013-11-05 02:20:24 <phantomcircuit> gmaxwell, anyways i think the general conclusion is that they dont fully understand the incentives for mining pools and have largely gotten the model wrong by oversimplifying
110 2013-11-05 02:20:28 <gmaxwell> if you're too close the network will just stop converging for large spans and you'll get these great big reorgs.
111 2013-11-05 02:20:49 <gmaxwell> phantomcircuit: I don't think thats the case but you may not have spent more time thinking about it than I have.
112 2013-11-05 02:20:52 <HaltingState> if i were running a mining pool; i would be doing direct connects to mining pools and sybil attacking with a botnet to delay propagation of blocsk from others; so i assume someone is doing that. its not major issue however except for minors
113 2013-11-05 02:21:44 <phantomcircuit> gmaxwell, substantially they ignore that mining pools have an incentive in bitcoins remaining valuable; their attack necessarily makes them less valuable
114 2013-11-05 02:22:04 <sipa> phantomcircuit: imho, that is not a good argument
115 2013-11-05 02:22:14 <phantomcircuit> gmaxwell, additionally while on average it would result in a higher return for pools with substantial hashing power it would also increase the variance
116 2013-11-05 02:22:28 <sipa> if you continue that into the extreme, nobody will ever try attacking the system as it decreases the long term value
117 2013-11-05 02:22:45 <sipa> it's of course a valid argument in practice
118 2013-11-05 02:22:55 <phantomcircuit> and finally and i suspect most significantly they dont answer the question of what happens when two selfish pools are operating at roughly equivalent hashing rates
119 2013-11-05 02:22:58 <HaltingState> its ripple's security model :)
120 2013-11-05 02:23:01 <sipa> but we should aim for a system that doesn't need such assumptions to be secure
121 2013-11-05 02:23:06 <phantomcircuit> i suspect that they both lose out in the end
122 2013-11-05 02:23:08 <HaltingState> "nobody will ever try attacking the system as it decreases the long term value" <-- ripple ahaha
123 2013-11-05 02:24:17 <phantomcircuit> sipa, it's the combination of all of them that has the largest impact
124 2013-11-05 02:24:25 <phantomcircuit> by itself that's not a significant consideration
125 2013-11-05 02:24:41 <phantomcircuit> but if they tried and only were able to increase their revenues 25%
126 2013-11-05 02:24:45 <phantomcircuit> well that's just pointless
127 2013-11-05 02:25:16 <HaltingState> if one mining pool increases revenue against another; does not affect bitcoin; mining is just unfair now, but security is same and does not affect anyone except miners
128 2013-11-05 02:26:25 <gmaxwell> phantomcircuit: not just a little more variance, a LOT, this was elu's almost instant comment on the subject.
129 2013-11-05 02:29:56 <phantomcircuit> gmaxwell, yeah i assumed as much but wasn't sure
130 2013-11-05 02:30:17 <phantomcircuit> either way it's pretty clear to me that their conclusion is wrong
131 2013-11-05 02:31:51 <gmaxwell> phantomcircuit: when successful it makes you get more blocks by orphaning the other guys more, but you get less blocks (because you get orphaned more too) so you don't really enjoy _gains_ until the difficulty drops.
132 2013-11-05 02:34:40 <phantomcircuit> gmaxwell, ah i hadn't thought of that
133 2013-11-05 02:34:49 <phantomcircuit> im sure it's much easier to just ddos everybody :/
134 2013-11-05 02:48:44 <gulli> Anyone know what language mtgox is using server side?
135 2013-11-05 02:48:52 <BlueMatt> magic
136 2013-11-05 02:48:56 <BlueMatt> and some brainfuck
137 2013-11-05 02:49:43 <petertodd> Magic BrainFuck - Enterprise Edition
138 2013-11-05 02:51:01 <petertodd> hmm... I think that needs a "2013 XP" at the end
139 2013-11-05 02:51:49 <gulli> https://github.com/MtGox
140 2013-11-05 02:51:58 <gulli> is this official?
141 2013-11-05 02:52:18 <petertodd> probably?
142 2013-11-05 02:52:22 <BlueMatt> try #mtgox?
143 2013-11-05 02:52:43 <gulli> its all in php and python
144 2013-11-05 02:52:49 <gulli> but surely they arent using that
145 2013-11-05 02:52:50 <BlueMatt> MagicalTux does love php
146 2013-11-05 02:52:54 <BlueMatt> it used to be all php
147 2013-11-05 02:53:15 <gulli> lol really? the #1 exchange?
148 2013-11-05 02:53:18 <gulli> shit
149 2013-11-05 02:53:35 <gulli> do you know what they changed to?
150 2013-11-05 02:53:42 <BlueMatt> in case you didnt notice, none of the bitcoin sites are particularly professional (yet)
151 2013-11-05 02:54:26 <gulli> yeah I know
152 2013-11-05 02:55:09 <gulli> but I really find it hard to believe that they use php for anything at all now
153 2013-11-05 02:55:19 <BlueMatt> no idea, ask on #mtgox
154 2013-11-05 02:55:23 <gulli> since there is such a high volume of transactions there
155 2013-11-05 02:55:34 <gulli> I asked, playing the waiting game now
156 2013-11-05 03:44:04 <copumpkin> is there much to this? https://twitter.com/el33th4xor/status/397569695164792832
157 2013-11-05 03:45:20 <BlueMatt> copumpkin: no
158 2013-11-05 03:45:39 <copumpkin> is there a summary of the current thoughts on that paper somewhere I can read it?
159 2013-11-05 03:45:47 <BlueMatt> check the bitcoin-development thread
160 2013-11-05 03:46:27 <BlueMatt> mostly its all predicated on a miner having very strong network connectivity (ie incredibly low latency to many other miners and some knowledge of which nodes are behind how much hashpower)
161 2013-11-05 03:46:35 <BlueMatt> which, to be fair, is somewhat possible today
162 2013-11-05 03:46:44 <BlueMatt> but as miners get better peering with each other, that will go away
163 2013-11-05 03:46:57 <BlueMatt> 
ACTION goes back to coding a high-speed relay nodes to give miners a better peering system to break such things

164 2013-11-05 03:47:05 <copumpkin> :) thanks
165 2013-11-05 03:47:31 <petertodd> BlueMatt: No it won't though: speed of light fundementally limits latency, and for more money you can reduce that latency. If a pools spends that money, they get large rewards that a smaller pool can't duplicate.
166 2013-11-05 03:48:12 <BlueMatt> petertodd: afaiu, a few ms worth of decreased latency wont help much on this kind of attack
167 2013-11-05 03:48:48 <petertodd> BlueMatt: even a few ms worth helps a lot, because you only need to see a peers block header to trigger you releasing the block you withheld.
168 2013-11-05 03:58:18 <BlueMatt> petertodd: "meh", its mostly a geography thing at that point, I suppose if you had lots of "evil" miners you may be able to make some geographic area more profitable, but you still have to have some ridiculous peering setup
169 2013-11-05 03:59:38 <petertodd> BlueMatt: right, which is why I said on the email list that this is quite reminiscent to high-speed trading, where you optimize where you place your nodes, and even mining hardware, by geography, and that an optimal large-scale mining effort pursuing this strategy would do exactly that.
170 2013-11-05 04:00:10 <petertodd> Again, if someone is willing to make that investment, they get significantly greater return on investment than those who don't, which encourages centralization.
171 2013-11-05 04:00:15 <BlueMatt> except that in this case if you fuck up and are a ms late, you lose a block's worth of money
172 2013-11-05 04:00:21 <BlueMatt> so its quite a large bet that you will always win
173 2013-11-05 04:00:27 <gavinandresen> petertodd: …. so what if three people make that investment ?
174 2013-11-05 04:00:53 <gavinandresen> If it is rational to make that investment, then multiple people will do it.
175 2013-11-05 04:00:59 <petertodd> gavinandresen: That's where it gets really interesting: then whoever managed to get the best balance of low-latency to cost wins, again, just like in high-speed trading!
176 2013-11-05 04:01:00 <gavinandresen> If multiple people do it, then they can't all win.
177 2013-11-05 04:01:19 <copumpkin> emergent HFM
178 2013-11-05 04:01:21 <gavinandresen> … and if you are not SURE you are going to win, then why risk making that investment?
179 2013-11-05 04:01:28 <BlueMatt> 
ACTION admits to have only skimmed most of the thread today after he got out of the gre...a few hours of that thread got quite long

180 2013-11-05 04:02:05 <gavinandresen> Investing in a fancier user interface or better customer support might be a better strategy.
181 2013-11-05 04:02:08 <gavinandresen> In any case:  "meh"
182 2013-11-05 04:02:08 <petertodd> gavinandresen: ...why risk making any investment?
183 2013-11-05 04:02:32 <BlueMatt> what happened to the idea of going from first-block to deterministic function (eg lower hash of block hash)
184 2013-11-05 04:02:38 <BlueMatt> ?
185 2013-11-05 04:02:59 <BlueMatt> seemed easy and fixing
186 2013-11-05 04:03:09 <petertodd> gavinandresen: Someone with existing high-speed trading/low-latency networking knowledge would be in a better position to make that investment - they may even be able to leverage an existing network for not much cost.
187 2013-11-05 04:03:32 <gavinandresen> petertodd: okey dokey
188 2013-11-05 04:03:48 <BlueMatt> then you cant race the network, you can only get lucky with a 50/50 shot
189 2013-11-05 04:04:11 <copumpkin> what's the worst-case outcome from all this?
190 2013-11-05 04:04:13 <copumpkin> assuming someone can pull it off
191 2013-11-05 04:04:46 <petertodd> BlueMatt: It's nothing to do with luck, it's about maximizing your returns, and minimizing the returns of your competitors.
192 2013-11-05 04:04:59 <BlueMatt> copumpkin: if you can (magically) pull it off flawlessly, you can "block" 1(+) block per block you generate
193 2013-11-05 04:05:22 <copumpkin> that sounds like fun
194 2013-11-05 04:05:23 <BlueMatt> petertodd: thats my point, what happened to the suggestion that we stop picking based on first-seen and switch to some deterministic function?
195 2013-11-05 04:05:45 <petertodd> Heck, the scary thing is that Bitcoin is still small enough that plenty of financial institutions could implement this as a training exercise for their staff.
196 2013-11-05 04:06:07 <gavinandresen> petertodd: why is that scary if plenty of them can do it?
197 2013-11-05 04:06:07 <petertodd> BlueMatt: The authors suggested that exact fix actually.
198 2013-11-05 04:06:14 <gavinandresen> if plenty of them can do it, then plenty of them will… voila, decentralized.
199 2013-11-05 04:06:24 <petertodd> gavinandresen: because one of them might succeed and turn a profit.
200 2013-11-05 04:06:38 <BlueMatt> petertodd: I was under the impression they suggested doing random-selection?
201 2013-11-05 04:06:43 <gavinandresen> petertodd: you seem to have very little faith in the power of competition.
202 2013-11-05 04:07:13 <BlueMatt> petertodd: anyway, what was wrong with deterministic function?
203 2013-11-05 04:07:21 <gavinandresen> BlueMatt: seem like the short-term incentive for miners is to stick with first-block-seen-wins.
204 2013-11-05 04:07:40 <petertodd> BlueMatt: In their paper they sugggested and analyzed random-selection, they said on the email list that they left out deterministic selection due to lack of space, but did think of it.
205 2013-11-05 04:07:59 <BlueMatt> petertodd: again, what's wrong with it? (I havent thought much, just asking)
206 2013-11-05 04:08:03 <gavinandresen> BlueMatt: if orphan rates go up because people start selfish mining (I'm still not convinced their calculations are correct), then it would be trivial to defeat by going to random-block or lowest-hash
207 2013-11-05 04:08:10 <petertodd> BlueMatt: as gavin says, first-block-seen-wins is in miners short-term incentives because first-block is most likely to have the majority of hashing power.
208 2013-11-05 04:08:29 <BlueMatt> ahh, ok, so aside from migration it wouldn't be too bad
209 2013-11-05 04:08:31 <gavinandresen> Just the fact that it is trivial to defeat might keep anybody from doing it.
210 2013-11-05 04:08:33 <BlueMatt> well, yea, probably not worth doing
211 2013-11-05 04:08:48 <BlueMatt> anyway, suggests we need more orphan monitoring too :p
212 2013-11-05 04:08:50 <copumpkin> darn game theory
213 2013-11-05 04:08:53 <copumpkin> how does it work!
214 2013-11-05 04:09:08 <petertodd> Their proposed solutions, both in the paper and deterministic, do work, the problem is they don't result in quite 51% strength, and both solutions are short-term irrational for individual miners.
215 2013-11-05 04:09:44 <petertodd> So it'd be good to come up with solutions that are stronger; I was working on analyzing another deterministic version that was short-term economically rational for individual miners.
216 2013-11-05 04:09:59 <gavinandresen> The whole "double-down on withholding blocks" feels too much like the Martingale betting strategy to me, it smells like some of the gains might be concentrated in tail-end events that are at risk of failing spectacularly.  But I might be completely wrong, haven't done the math
217 2013-11-05 04:10:47 <petertodd> BlueMatt: heh, well, read me mistaken first impression of their paper - I suggested orphan monitoring, and then realized it actually makes the problem worse depending on how you implement it :(
218 2013-11-05 04:11:24 <BlueMatt> petertodd: how does making people aware of how the network is performing (ie not taking automated action) make the problem worse?
219 2013-11-05 04:11:28 <gavinandresen> Mmm.  If there are two selfish miners, I believe the one with the most hashing power always wins.  But how do you know if you've got the most hashing power?
220 2013-11-05 04:11:57 <gavinandresen> … could always be some Mystery Miner who has never released any blocks working away in secret....
221 2013-11-05 04:12:15 <justusranvier> Are all mining pools actually using first-seen right now? https://bitcointalk.org/index.php?topic=324413.msg3485173#msg3485173
222 2013-11-05 04:12:16 <petertodd> gavinandresen: modern economics recognizes that competition tends to lead towards oligopolies and monopolies in situations where more capital investment yields greater returns
223 2013-11-05 04:12:37 <gavinandresen> petertodd: mmm.  We're Doomed!
224 2013-11-05 04:12:59 <gavinandresen> That darn monopolistic Apple Computer....
225 2013-11-05 04:13:05 <gavinandresen> biggest damn company in the world...
226 2013-11-05 04:13:16 <gavinandresen> … investing in those fancy UIs that nobody can compete with….
227 2013-11-05 04:13:22 <gavinandresen> … if only I had a choice....
228 2013-11-05 04:13:49 <BlueMatt> 
ACTION agrees with gavinandresen and goes back to coding high-speed relay nodes and apis that smarter people than him can use to design fancy UIs

229 2013-11-05 04:14:17 <petertodd> BlueMatt: What I suggested was to relay block headers, full and "near-target". However when you do that, miners can use that information to easily pick the side of a fork that has the majority of hashing power, which is in their advantage.
230 2013-11-05 04:14:33 <BlueMatt> I did see that much
231 2013-11-05 04:14:44 <shripadk> hello all :) what is the upper limit of N in a M-of-N transaction? is there one?
232 2013-11-05 04:14:47 <petertodd> BlueMatt: Now if you truly don't act on the information, then doesn't make the problem worse, but it's easy to create situations where you can without much work.
233 2013-11-05 04:15:07 <gavinandresen> shripadk: 3 for standard transactions that will be relayed.  20 in the protocol.
234 2013-11-05 04:15:27 <petertodd> BlueMatt: Also, relaying such info is a bit useful for the attacker.
235 2013-11-05 04:15:30 <shripadk> gavinandresen: thanks :) so anything greater than 3 today will not be relayed?
236 2013-11-05 04:15:34 <gavinandresen> shripadk: if you need more than 3 then you are probably doing it wrong.  Whatever "it" is.
237 2013-11-05 04:15:55 <BlueMatt> petertodd: I was talking about making nice graphs for developers and people to watch so we'd see if someone was doing something fishy
238 2013-11-05 04:16:13 <gavinandresen> shripadk: and yes, more than -of-3 will not be relayed and will probably not be mined.
239 2013-11-05 04:16:20 <petertodd> gavinandresen: try an industry that hasn't undergone transformational change, lots of examples in mining and other industry where the leaders just don't change for decades and no-one else has a hope of challenging them due to the economies of scale.
240 2013-11-05 04:16:28 <shripadk> gavinandresen: i'm developing a gui client for making it easy to do M-of-N. so is there any reason why greater than 3 is wrong?
241 2013-11-05 04:16:43 <petertodd> BlueMatt: Sure, but where are you going to get the info for those nice graphs?
242 2013-11-05 04:17:01 <BlueMatt> monitoring nodes conveniently placed near all the miners?
243 2013-11-05 04:17:16 <petertodd> shripadk: bare multisig has a limit of three, however for P2SH multisig we don't have any specific limit. (although there is a 520 byte limit on the P2SH scriptPubKey size)
244 2013-11-05 04:17:24 <BlueMatt> 
ACTION goes back to coding high-speed relay nodes designed to be placed near all the miners that pools have shown some interest in peering with...

245 2013-11-05 04:17:52 <petertodd> BlueMatt: that works - changing relay code to relay orphans would be more fool-proof and guaranteed
246 2013-11-05 04:19:06 <gavinandresen> shripadk: don't do a -of-greater-than-3 P2SH, it will get stuck and you won't be able to redeem it (or your users won't be able to)
247 2013-11-05 04:19:38 <shripadk> petertodd: thanks :) will look into P2SH then. btw how do i calculate the size in bytes of a raw transaction? i checked up online for a way to calculate the size and many offer different methods… but most of them seem too magical to actual take them seriously… an example: size_in_bytes = ((180 * total_inputs) + (34 * total_outputs) + 10)
248 2013-11-05 04:19:49 <shripadk> gavinandresen: okay will make sure i limit it to 3 then
249 2013-11-05 04:20:10 <gavinandresen> shripadk: are you just giving users a low-level "create a multisig transaction" GUI ?  Or are you making the GUI task-specific?  (like "setup a secure wallet" or "create a three-party escrow")
250 2013-11-05 04:20:31 <petertodd> shripadk: gavin's incorrect, but be careful due to that 520 byte limit. I'd suggest you read up on the details of the low-level transaction format, see the protocol specification page on the bitcoin.it wiki
251 2013-11-05 04:20:36 <gavinandresen> shripadk: … and is your GUI intended for the geekiest of the geeks, or ordinary users?
252 2013-11-05 04:20:43 <shripadk> i was wanting to create a multisig transaction guy but now i think i'll have to make it task specific
253 2013-11-05 04:21:04 <shripadk> gavinandresen: i was wanting to make it easy for ordinary users to execute m-of-n
254 2013-11-05 04:21:16 <shripadk> *gui
255 2013-11-05 04:21:45 <gavinandresen> shripadk: start with the user experience would be my advice….
256 2013-11-05 04:22:03 <gavinandresen> … and don't listen to petertodd, he is incorrect.
257 2013-11-05 04:22:06 <shripadk> gavinandresen: advice taken! so it'll be task specific then
258 2013-11-05 04:22:12 <shripadk> gavinandresen: ha okay :P
259 2013-11-05 04:22:43 <petertodd> shripadk: sorry, that's a 500 byte limit.
260 2013-11-05 04:22:52 <petertodd> gavinandresen: lol, what do you want to bet?
261 2013-11-05 04:23:15 <gavinandresen> petertodd: I wrote the AreInputsStandard() routine you know....
262 2013-11-05 04:23:20 <shripadk> petertodd: np :) i'll read up on P2SH myself… BIP0016 is the one right?
263 2013-11-05 04:23:48 <petertodd> shripadk: yup
264 2013-11-05 04:23:54 <shripadk> gavinandresen: can you please help me figure out how to calculate the size of a raw transaction? i googled quite a bit… but i haven't yet looked at the source
265 2013-11-05 04:24:06 <petertodd> gavinandresen: yes, and you missed a case
266 2013-11-05 04:24:09 <BlueMatt> shripadk: are you creating the transactions yourself?
267 2013-11-05 04:24:25 <shripadk> BlueMatt: yes.. but wanting to automate it mostly
268 2013-11-05 04:24:43 <gavinandresen> petertodd: ok, educate me.  How do you redeem a 1-of-4 P2SH multisig with a standard transaction?
269 2013-11-05 04:24:51 <BlueMatt> shripadk: seems like there is a bitcoin library in just about every language at this point (of varying quality, but if you're just making transactions, should work)
270 2013-11-05 04:25:52 <shripadk> BlueMatt: yes true. but there isn't one that i found that would calculate the size of raw transactions… most of what i found is only calculations that are inaccurate at most by +/- 20-30 bytes
271 2013-11-05 04:26:02 <BlueMatt> what language?
272 2013-11-05 04:26:28 <gavinandresen> shripadk: what are you trying to do that you need to calculate the size?  Size depends on a lot of things (compressed or uncompressed public keys to start)
273 2013-11-05 04:26:32 <shripadk> BlueMatt: i have looked at javascript and python libs… but i'm mostly interested in javascript
274 2013-11-05 04:26:33 <lianj> shripadk: you mean to calc fees or what?
275 2013-11-05 04:26:58 <shripadk> gavinandresen, lianj: yes to calculate fees
276 2013-11-05 04:27:03 <BlueMatt> but, yea, the size is nondeterministic and depends on a few factors so its not guaranteed to be some constant
277 2013-11-05 04:27:05 <petertodd> gavinandresen: 672d4dddfd5f667fe1088c06a8164c4caba109576f310599ce68808cce8ce603
278 2013-11-05 04:27:21 <petertodd> gavinandresen: I just did
279 2013-11-05 04:28:58 <shripadk> oh i can just use sendtomany instead
280 2013-11-05 04:29:07 <gavinandresen> petertodd: that's a main network txid?
281 2013-11-05 04:29:21 <petertodd> gavinandresen: yup
282 2013-11-05 04:29:42 <petertodd> gavinandresen: depends on "f7fd59e2a27dd12ca9423efa20a40a29cb74f125a7df80d3184a33c869436ad0"
283 2013-11-05 04:30:19 <petertodd> http://0bin.net/paste/x4paFW9whWOh2n8k#wXlWGKNNXqmHpA+PD8Pjx7l18Q6wkyM4/UsNZsKsVwg= <- raw tx
284 2013-11-05 04:48:13 <gavinandresen> petertodd: I sit corrected.  Do you know if that is a regression, or an unintended feature?
285 2013-11-05 04:48:13 <gavinandresen> petertodd: mmm.  The 500-byte limit keeps things sane.
286 2013-11-05 04:48:13 <petertodd> gavinandresen: pretty sure it's always been like that - I'd be reluctant to tighten the rules now
287 2013-11-05 04:48:13 <petertodd> gavinandresen: what we should fix is how we don't actually check that the 0 placeholder byte is actually zero...
288 2013-11-05 04:48:13 <shripadk> petertodd, gavinandresen so its possible to do -of-4 P2SH multisig? so then its possible to do m-of-n as well?
289 2013-11-05 04:48:14 <petertodd> shripadk: 2) scriptSigs can be no more than 500 bytes, including the P2SH scriptPubKey, which limits things even further
290 2013-11-05 04:48:14 <petertodd> shripadk: yup, but... there's two issues: 1) P2SH fundementally can't have more than a 520 byte scriptPubKey, which limits you to -of-15 even with compressed keys. (but make sure you check this!)
291 2013-11-05 04:48:14 <shripadk> petertodd: okay thanks for this info :) i'll go through p2sh seriously now
292 2013-11-05 04:48:15 <gavinandresen> yes, I know.
293 2013-11-05 04:48:15 <petertodd> gavinandresen: that we don't check the 0's is a mutabilty issue
294 2013-11-05 04:48:16 <justusranvier> Is the 500 byte limit a protocol limit, or a standard definition limit?
295 2013-11-05 04:48:16 <petertodd> gavinandresen: I've also seen transactions with more than one zero; gotta get around to debugging exactly what allows that. (placeholder something I assume)
296 2013-11-05 04:48:16 <shripadk> petertodd, gavinandresen: do you have an example of one 2-2 of 2-3 transaction done using P2SH that i can use for reference?
297 2013-11-05 04:48:17 <justusranvier> i.e. Could a mining pool which accepted non-standard transaction mine a transaction that was a m-of-20 ?
298 2013-11-05 04:48:17 <justusranvier> So you can still do m-of-20 if you want, as long as you find a pool who will agree to mine them for you?
299 2013-11-05 04:48:17 <petertodd> justusranvier: IsStandard. 520 bytes limit is a protocol limit.
300 2013-11-05 04:48:17 <petertodd> justusranvier: might be 521 bytes actually...
301 2013-11-05 04:48:17 <petertodd> justusranvier: try it on eligius for us
302 2013-11-05 04:48:17 <petertodd> justusranvier: yes
303 2013-11-05 04:48:17 <petertodd> shripadk: 672d4dddfd5f667fe1088c06a8164c4caba109576f310599ce68808cce8ce603
304 2013-11-05 04:48:17 <shripadk> petertodd: thanks
305 2013-11-05 04:48:18 <gavinandresen> RE: putting rick-roll in the blockchain:  dont' do that, by the way.  It has already been done.
306 2013-11-05 04:48:18 <justusranvier> Voting pools in OpenTransactions might want to use high values of n for their operations.
307 2013-11-05 04:48:18 <petertodd> justusranvier: yup. You can embed the rick-roll song in the blockchain is you mine it yourself...
308 2013-11-05 04:48:19 <justusranvier> Like 9-12
309 2013-11-05 04:48:23 <petertodd> on testnet
310 2013-11-05 04:51:00 <Luke-Jr> <.<
311 2013-11-05 04:51:00 <Luke-Jr> gavinandresen: not with video!
312 2013-11-05 04:51:14 <petertodd> Luke-Jr: what do you charge per KB again?
313 2013-11-05 04:51:34 <Luke-Jr> petertodd: 42 BTC
314 2013-11-05 04:52:12 <petertodd> Luke-Jr: pff, I'm sure I can get a better price than that
315 2013-11-05 04:52:35 <Luke-Jr> petertodd: no no, it's extra for you! :P
316 2013-11-05 04:52:39 <petertodd> 
ACTION keeps meaning to sign such a tx with a 1BTC fee and post it in the mining section of the forum

317 2013-11-05 04:53:18 <petertodd> Actually, I hid a 1BTC giveway in one of my posts, but to mine it you're forced to put a usage of OP_CODESEPARATOR in the mainnet blockchain.
318 2013-11-05 04:54:10 <Luke-Jr> petertodd: I'm supposed to fear that?
319 2013-11-05 04:54:52 <petertodd> Luke-Jr: um, sure... (actually your eval thing used codeseparator didn't it?)
320 2013-11-05 04:55:28 <Luke-Jr> petertodd: BIP 17 did, but it never evaled in any form..
321 2013-11-05 04:55:43 <petertodd> oh, right, not eval, codecheckhash
322 2013-11-05 04:55:59 <Luke-Jr> CHECKHASHVERIFY
323 2013-11-05 04:56:12 <Luke-Jr> to keep in the spirit of stupidly named opcodes that tell nothing about what they do
324 2013-11-05 04:56:14 <Luke-Jr> lol
325 2013-11-05 04:56:20 <petertodd> did you ever mine an example tx? though I guess it wouldn't have really tested it out in terms of an actual signature
326 2013-11-05 04:56:26 <Luke-Jr> plenty
327 2013-11-05 04:56:31 <Luke-Jr> gavinandresen forced me to do all testing on mainnet
328 2013-11-05 04:56:38 <petertodd> lol
329 2013-11-05 04:56:57 <Luke-Jr> he had a bot on testnet spending against the softforking rule
330 2013-11-05 04:57:05 <petertodd> that's hilarious
331 2013-11-05 04:57:26 <petertodd> also, assholish
332 2013-11-05 04:57:32 <Luke-Jr> more hilarious tohugh
333 2013-11-05 04:57:34 <Luke-Jr> though*
334 2013-11-05 04:57:36 <gavinandresen> yeah, I feel a little guilty about that
335 2013-11-05 04:58:04 <gavinandresen> If I was a realy asshole I would've pretended it wasn't me doing it
336 2013-11-05 04:58:19 <Luke-Jr> didn't you at the time? <.<
337 2013-11-05 04:58:48 <petertodd> Luke-Jr: still, I'm pretty sure that OP_CODESEPARATOR has never appeared on mainnet in such a way that the checksig code was used to evaluate it
338 2013-11-05 05:00:29 <Luke-Jr> petertodd: besides older versions when it had more meaning?
339 2013-11-05 05:00:43 <petertodd> Luke-Jr: older versions never used in in the blockchain
340 2013-11-05 05:00:57 <Luke-Jr> not in the blockchain, but it was used
341 2013-11-05 05:01:40 <petertodd> Luke-Jr: kinda unfortunate actually, as satoshi *nearly* made a design that wouldhave let you create signatures that signed code in the scriptSig; you'd have been able to delegate signing authority after the fact
342 2013-11-05 05:02:01 <petertodd> 
ACTION curses satoshi for probably being a student who had classes to return to in january...

343 2013-11-05 05:02:23 <wizkid057> 
ACTION blames Luke-Jr

344 2013-11-05 05:02:37 <petertodd> ah, mystery solved!
345 2013-11-05 05:02:52 <petertodd> although... wait.. but I'm satoshi!
346 2013-11-05 05:03:03 <wizkid057> shh
347 2013-11-05 05:03:19 <wizkid057> you're not supposed to know that
348 2013-11-05 05:03:24 <Luke-Jr> lol
349 2013-11-05 05:03:40 <Luke-Jr> TBC is proof I'm not satoshi ;)
350 2013-11-05 05:03:47 <petertodd> my horrible experience with Bitcoin 1.0 has lead to second-system effect with the Bitcoin 2.0 I'm designing...
351 2013-11-05 05:03:54 <Luke-Jr> so it's important the NSA knows about TBC
352 2013-11-05 05:03:56 <Luke-Jr> <.<
353 2013-11-05 05:04:14 <wizkid057> thats just what satoshi would do to throw us off his trail...
354 2013-11-05 05:04:28 <petertodd> ...yeah, that's why I wrote it for windows
355 2013-11-05 05:04:50 <petertodd> it's also why the crypto all sucks, er, wait, no that's because I have a fine arts degree...
356 2013-11-05 05:06:19 <wizkid057> just XOR everything with "WILL THE REAL SATOSHI PLEASE STAND UP".  Solid encryption.
357 2013-11-05 05:06:22 <shripadk> petertodd, gavinandresen: so if i send 1-of-4 multisig tx on testnet it shouldn't even broadcast it right?
358 2013-11-05 05:06:41 <gavinandresen> shripadk: sure it will, testnet allows non-standard transactions
359 2013-11-05 05:07:22 <shripadk> gavinandresen: okay so then how do i know for sure that >3 is non-standard… the only way is to test on mainnet?
360 2013-11-05 05:07:29 <petertodd> wizkid057: you laugh, but this is the most embarassing crypto mistake I've ever made: https://github.com/opentimestamps/opentimestamps-client/commit/288f3c17626974de7eaef4f1c9b5cd93eecf40f6
361 2013-11-05 05:07:53 <petertodd> wizkid057: I swear someone must have slipped something into my drink
362 2013-11-05 05:08:51 <wizkid057> ... i didnt know about this before I made the joke I swear. lol
363 2013-11-05 05:08:55 <gavinandresen> shripadk: yes.  Unless you get petertodd to implement his idea of a switch to control the accepts-only-standard-transactions-on-testnet… (I'm busy with other stuff righ tnow)
364 2013-11-05 05:10:10 <petertodd> wizkid057: heh, I left it in the git tree delibrately to remind myself everyone has their moments of idiocy
365 2013-11-05 05:11:13 <petertodd> wizkid057: the great thing was I had explained it to a professional cryptographer over lunch earlier that day, and he too completely missed it! he swore later on that he genuinely just blanked on it
366 2013-11-05 05:11:32 <shripadk> gavinandresen: okay thanks :) do you have an example of creating a P2SH tx similar to the one in this gist of yours: https://gist.github.com/gavinandresen/3966071
367 2013-11-05 05:11:44 <wizkid057> :)
368 2013-11-05 05:12:46 <gavinandresen> shripadk: nope
369 2013-11-05 05:13:12 <shripadk> gavinandresen: okay np :) i'll figure it out myself then
370 2013-11-05 05:41:37 <gmaxwell> heh: "By now, the Bitcoin market has priced in this information.  Bitcoin is at $239 on Mt. Gox."
371 2013-11-05 05:42:30 <petertodd> gmaxwell: as I said on the foundation forum, one of Bitcoin's strengths is that even though it's currently flawed, it can be changed in response to an attack
372 2013-11-05 05:42:33 <BlueMatt> gmaxwell: what the mining strategy paper?
373 2013-11-05 05:42:54 <gmaxwell> yes.
374 2013-11-05 05:42:59 <BlueMatt> hah
375 2013-11-05 05:44:09 <gmaxwell> kinda concerning, I mean, the paper doesn't worry _me_ but like ... why isn't it worrying the markets?
376 2013-11-05 05:44:40 <BlueMatt> because they're markets
377 2013-11-05 05:45:00 <BlueMatt> especially the bitcoin market is really quite oblivious to technical issues
378 2013-11-05 05:45:02 <BlueMatt> or it doesnt care...
379 2013-11-05 05:45:07 <phantomcircuit> gmaxwell, because they're irrational
380 2013-11-05 05:45:18 <gmaxwell> yea, I've observed it in the past, though this time we're up 5% since the paper started making the rounds.
381 2013-11-05 05:45:22 <petertodd> Also much of the dev team doesn't take the paper seriously, which is a clear indication to the markets that they don't need to take it seriously.
382 2013-11-05 05:46:08 <gmaxwell> I hope the folks writing the super sensationalist headlines found a way to short bitcoin. :P
383 2013-11-05 05:46:22 <petertodd> heh, well it did have a quick drop...
384 2013-11-05 05:46:49 <BlueMatt> petertodd: until the dev team ends up wrong and there is a serious problem
385 2013-11-05 05:46:59 <BlueMatt> petertodd: more realistically, the markets dont pay attention to the dev team
386 2013-11-05 05:47:01 <gmaxwell> petertodd: I hope you don't think I'm not taking it seriously, ... Do you think I'm wrong in not considering it an urgent concern demanding sudden changes?
387 2013-11-05 05:47:08 <BlueMatt> petertodd: I mean how many traders do you think idle in here...
388 2013-11-05 05:47:22 <petertodd> BlueMatt: Well, heck, even I got contacted by *two* reporters about the issue.
389 2013-11-05 05:47:27 <BlueMatt> lol
390 2013-11-05 05:47:40 <gmaxwell> I had people in the hall at IETF ask me about it, but no reporters.
391 2013-11-05 05:47:59 <gmaxwell> (also coworkers)
392 2013-11-05 05:48:05 <petertodd> gmaxwell: Heck no, assembling the right type of low-latency network to really take advantage of this takes time.
393 2013-11-05 05:48:14 <BlueMatt> 
ACTION is glad he gets ignored by reporters because he doesnt post on the ml enough :)

394 2013-11-05 05:48:29 <BlueMatt> (and doesnt do enough work, but...whatever)
395 2013-11-05 05:48:57 <petertodd> BlueMatt: heh, I get contacted before I don't do enough work. :P
396 2013-11-05 05:49:21 <gmaxwell> petertodd: not just that, it's super detectable. .. and even if it works for all hashpower levels and the right networket the absolute return is small with small hashpwoer....
397 2013-11-05 05:49:36 <justusranvier> Has the news about this reached China yet? Maybe that's why nobody is panic selling.
398 2013-11-05 05:49:38 <petertodd> gmaxwell: but equally the dismissive attitude taken by so many is wrong, both now, and also in that it discourages people from working on this stuff
399 2013-11-05 05:50:29 <gmaxwell> a large pool that would have the hashpower to make real absolute return on it probably couldn't take the PR risk...
400 2013-11-05 05:50:29 <petertodd> gmaxwell: sure, although super detectable isn't necessarily all that useful if there isn't will-power to actually fix it - that the easier fixes go against miner incentives worries me.
401 2013-11-05 05:50:57 <petertodd> gmaxwell: maybe. maybe not. ASICminer a few months ago might not have had any reason to care about the PR risk...
402 2013-11-05 05:51:36 <gmaxwell> Perhaps, but its a fine line. The paper itself used somewhat sensational language that had people demanding ill-considered changes right away. And the press has been a bit over the top. If you're going to binary-classify responses....
403 2013-11-05 05:52:11 <gmaxwell> petertodd: yea, well in general the hashpower consolidation is a problem, and has been a problem, will continue to be one. But that much isn't news.
404 2013-11-05 05:52:30 <gmaxwell> But I've had basically no luck moving the needle on that front.
405 2013-11-05 05:53:11 <petertodd> gmaxwell: I wouldn't call the paper's language sensational.
406 2013-11-05 05:53:36 <gavinandresen> I would
407 2013-11-05 05:54:04 <gavinandresen> e.g. using the term "toss up" to describe the block race between first- and second- broadcast is very misleading
408 2013-11-05 05:54:18 <gavinandresen> propagation is exponential, so first-broadcast will win almost always
409 2013-11-05 05:54:34 <gavinandresen> … unless you can pull off a massive sybil, which you can't.....
410 2013-11-05 05:54:37 <petertodd> gmaxwell: Well, franly that's not the impression I got, and the impression one of my co-workers gave me was he thought it was very balanced and well done.
411 2013-11-05 05:55:07 <petertodd> gavinandresen: what makes you think you can't?
412 2013-11-05 05:55:22 <gavinandresen> miners have an incentive to be well-connected to each other.
413 2013-11-05 05:55:22 <justusranvier> Not sensational? http://hackingdistributed.com/2013/11/04/bitcoin-is-broken/
414 2013-11-05 05:55:28 <petertodd> justusranvier: I said the paper...
415 2013-11-05 05:55:52 <petertodd> gavinandresen: well-connected doesn't prevent this attack
416 2013-11-05 05:56:32 <petertodd> gavinandresen: notably, mike's (and my) idea of putting node addresses in blocks makes the attacker easier to pull off rather than harder.
417 2013-11-05 05:58:42 <gmaxwell> gavinandresen: yea, I wtfed at that too.
418 2013-11-05 05:59:03 <gmaxwell> Random headlines: "Bitcoin Protocol Vulnerability Could Lead To a Collapse" "Researchers Say 'Bitcoin Is Broken' And Could Collapse" "'Selfish miner' attack could devastate Bitcoin, researchers say" "Bitcopocalypse! Top crypto-currency can be HIJACKED, warn boffins" "Bitcoin open to takeover, researchers discover with new algorithm"
419 2013-11-05 05:59:45 <gavinandresen> petertodd: I'm not following.  My point is that honest miners have an incentive to connect directly to each other and quickly propagate blocks.  They also have an incentive to keep those connections private to prevent sybil / dos attacks
420 2013-11-05 05:59:56 <gmaxwell> justusranvier: holy crap
421 2013-11-05 06:00:05 <gavinandresen> … and they have an incentive to kick out cheating miners if they can detect that they are cheating...
422 2013-11-05 06:00:05 <gmaxwell> justusranvier: I hadn't seen that
423 2013-11-05 06:00:28 <petertodd> gmaxwell: that sentence specifically refers the situation where the attacker, who has the ability to learn when a new block is created, in response immediately reveals one of their blocks. It's nearly simultaneous, so calling it a "toss up" is reasonable.
424 2013-11-05 06:01:07 <justusranvier> gmaxwell: Based on that blog post, I halfway expect the author to be revans on the forum.
425 2013-11-05 06:01:10 <gavinandresen> "who has the ability to learn when a new block is created" …. "Imagine blocks being transmitted on an infinte plane with zero friction...."
426 2013-11-05 06:02:05 <petertodd> gavinandresen: Mike and I proposed putting node addresses in blocks. Now if you do this the attacker has an easier time knowing where to broadcast their blocks when they need to reveal them; the attacker optimizes for low-latency. Meanwhile if those nodes also tell arbitrary peers what blocks those miners have created, the attacker can use that information to find out when a new block is created sooner.
427 2013-11-05 06:02:24 <gmaxwell> petertodd: think you could get their simulation code out of them?
428 2013-11-05 06:02:43 <gmaxwell> petertodd: it might be useful to run the simulations with some reasonable constraints on what the observing nodes could do.
429 2013-11-05 06:03:02 <petertodd> gavinandresen: yes, and that ability is achieved by obtaining low-latency nodes, not rocket science, just find computers with low ping times to the miners.
430 2013-11-05 06:03:05 <arioBarzan> a bunch of stupid people think they have found something new. Satoshi himself has talked about this long time ago. If people have short memory is their own fault. http://www.mail-archive.com/cryptography@metzdowd.com/msg09967.html
431 2013-11-05 06:04:17 <gmaxwell> arioBarzan: thats not really related.
432 2013-11-05 06:04:21 <petertodd> gmaxwell: just ask them, they replied to me pretty quickly. Frankly I think "reasonable constraints" is missing the point - regardless of what the constraints are, if you invest more money, you'll get a better result re: latency. Once you beat everyone else, you can use the attack very effectively unless we apply some kind of effective countermeasure.
433 2013-11-05 06:05:17 <gmaxwell> arioBarzan: but as I linked to in my posts, bytecoin did write about this class of behavior: https://bitcointalk.org/index.php?topic=2227.msg30083#msg30083
434 2013-11-05 06:05:52 <gmaxwell> petertodd: yes, but as you note: that takes money. And then what is the return?
435 2013-11-05 06:06:06 <gmaxwell> Spend $10000/mo to earn $10/mo more is not a win. :)
436 2013-11-05 06:07:51 <petertodd> gmaxwell: The return is that your competitors make very little money, and the miners mining on their pools give up and switch to you, and/or difficulty drops and you earn more money. We don't know exactly what the constraints are, but we shouldn't assume such a network is expensive: they already exist and as I said above, it may be the case that doing some bitcoin mining as a side project would be pretty cheap.
437 2013-11-05 06:08:30 <petertodd> gmaxwell: Eventually you can add fees to the equation, and also note my comment on the list about how this screws up nLockTime sacrifices.
438 2013-11-05 06:12:08 <gmaxwell> meh. I would probably put this concern someplace somewhat lower than the middle in my list of concerns about bitcoin, below many other possible consilidation sources.
439 2013-11-05 06:12:34 <gmaxwell> If we have been reorg producing things we have many problems, I am not worred about sacrifices related to this.
440 2013-11-05 06:13:11 <petertodd> gmaxwell: The sacrifices are an example where the miner pursuing this strategy most effectively gets all the reward.
441 2013-11-05 06:13:36 <petertodd> I think this is quite a bit worse than other consolidation pressures that we've found by virtue of how effective it is.
442 2013-11-05 06:14:04 <gmaxwell> I'm sorry. We already have single pools kissing 40% on their own. How can anything be _worse_?
443 2013-11-05 06:14:21 <gmaxwell> in terms of short term behavior that can be adapted away by users, at least?
444 2013-11-05 06:14:39 <petertodd> gmaxwell: Because those pools aren't, and can't quite yet, effectively stop the 10% pools from getting bigger.
445 2013-11-05 06:15:05 <petertodd> gmaxwell: 40% isn't enough hashing power to take their inflation subsidies away from them basically.
446 2013-11-05 06:15:47 <petertodd> gmaxwell: Now if a relatively simple fix *is* possible, and can be deployed, we're probably ok, even if in theory it's economically irrational for a miner to use the fix. But, I'd like to know that.
447 2013-11-05 06:17:08 <petertodd> ...and hilariously, right as we've been having this conversation mtgox price volume shot up, and price gyrated wildly.
448 2013-11-05 06:17:18 <gmaxwell> yea, the bots read irc. :P
449 2013-11-05 06:17:36 <gmaxwell> watch this
450 2013-11-05 06:17:39 <gmaxwell> buffer overflow
451 2013-11-05 06:17:39 <petertodd> OH FUCK, THE CHAIN IS FORKING!
452 2013-11-05 06:17:44 <gmaxwell> jinx
453 2013-11-05 06:17:49 <petertodd> heh
454 2013-11-05 06:18:06 <petertodd> hey cool, so turns out a chain fork causes the price to rise!
455 2013-11-05 06:18:22 <gmaxwell> every technical problem causes the price to rise.
456 2013-11-05 06:18:38 <petertodd> hmm....
457 2013-11-05 06:18:50 <petertodd> UNDEAD SATOSHI RISES!
458 2013-11-05 06:19:25 <beethoven8201> stupid question here ... how are the dev's going to coordinate a block size increase across all the different clients?
459 2013-11-05 06:19:39 <gavinandresen> beethoven8201: very slowly
460 2013-11-05 06:19:42 <petertodd> beethoven8201: clients don't check blocksize
461 2013-11-05 06:19:49 <petertodd> beethoven8201: at least the vast majority don't (SPV)
462 2013-11-05 06:19:50 <beethoven8201> sorry node is what I meant
463 2013-11-05 06:20:11 <beethoven8201> if there are forks of -qt, for example
464 2013-11-05 06:20:12 <BlueMatt> woo, fast-relay daemon implemented (yay bitcoinj)
465 2013-11-05 06:20:17 <beethoven8201> that don't update, what do you do?
466 2013-11-05 06:20:24 <BlueMatt> (yes, fast-relay in java, but fuck you, I wrote the network stack, it performs well)
467 2013-11-05 06:20:25 <beethoven8201> do they just break off the main chain?
468 2013-11-05 06:20:36 <petertodd> beethoven8201: there's a pretty simple update mechanism, you cange the version in the block header and vote on the change basically
469 2013-11-05 06:20:40 <gavinandresen> beethoven8201: https://gist.github.com/gavinandresen/2355445
470 2013-11-05 06:21:26 <petertodd> BlueMatt: blocks or blockheaders?
471 2013-11-05 06:21:33 <BlueMatt> petertodd: blocks + txn
472 2013-11-05 06:21:44 <petertodd> BlueMatt: cool, we need alternate mechanisms...
473 2013-11-05 06:22:01 <BlueMatt> petertodd: Im gonna set up a few nodes and then get a bunch of miners/merchants to peer with this node
474 2013-11-05 06:22:07 <BlueMatt> (and then make it public if its stable)
475 2013-11-05 06:22:34 <petertodd> BlueMatt: cool. For blocks is it checking headers for validity?
476 2013-11-05 06:22:39 <BlueMatt> it does depend on having a single bitcoind on the backend to check validity
477 2013-11-05 06:22:40 <beethoven8201> gavinandresen: will we be able to monitor/estimate what percentage of the nodes / miners are using what version of software?
478 2013-11-05 06:22:49 <BlueMatt> but it could pretty trivially just use bitcoinj spv mode and not bother
479 2013-11-05 06:23:33 <petertodd> BlueMatt: could you do a version that only checks header validity? that's enough to prevent DoS attacks, and it'd be really good to have something that could relay blocks in case we ever run into block-dependent relay bugs
480 2013-11-05 06:23:43 <beethoven8201> gavinandresen: never mind -- I see this in the version number
481 2013-11-05 06:23:45 <beethoven8201> thanks
482 2013-11-05 06:23:52 <petertodd> BlueMatt: tx's aren't so important; tx relaying failing doesn't harm consensus much
483 2013-11-05 06:24:32 <BlueMatt> petertodd: yea, that'll happen
484 2013-11-05 06:24:33 <gmaxwell> BlueMatt: you've not seen jgarzik's brd? :P
485 2013-11-05 06:24:41 <petertodd> BlueMatt: thanks
486 2013-11-05 06:24:57 <BlueMatt> gmaxwell: meh, Im lazy
487 2013-11-05 06:25:29 <petertodd> BlueMatt: heh, you'll like my semi-paper describing a crypto-currency system, heck, a decentralized consensus system, where block data isn't validated at all.
488 2013-11-05 06:28:35 <ThomasV> midnightmagic: ping
489 2013-11-05 09:07:20 <HaltingState> sipa, I added crytographic random number generator to my golang wrapper and added unit tests
490 2013-11-05 09:07:33 <HaltingState> https://github.com/haltingstate/secp256
491 2013-11-05 09:08:06 <HaltingState> it would be nice if there was a c function for checking if nonce was valid, but ..
492 2013-11-05 09:31:42 <HaltingState> sipa, look in secp256_test.go; is so elegant, this library and its interface
493 2013-11-05 09:32:26 <HaltingState> your library is so elegant and then the golang library on top of this is amazing and clean; key generation, signatures and testing in 3 lines!
494 2013-11-05 09:51:07 <HaltingState> SIGABRT: abort
495 2013-11-05 09:51:07 <HaltingState> sipa, secp256.test: /home/atomos/secp256/./secp256k1/src/impl/num_gmp.h:55: secp256k1_num_get_bin: Assertion `len-shift <= rlen' failed.
496 2013-11-05 09:52:19 <HaltingState> i am taking a  fixed message and then generating random signatures and testing the random signatures and its crashing
497 2013-11-05 10:03:02 <HaltingState> sipa, what i am doing is creating a random signatures (just completely random byte string) and trying to verify if they are valid signature for a pubkey and it crashes/aborts
498 2013-11-05 10:05:05 <sipa> HaltingState: can you create an issue or something about it?
499 2013-11-05 10:05:11 <sipa> i don't have time to look now
500 2013-11-05 10:08:03 <HaltingState> k
501 2013-11-05 10:56:54 <HaltingState> sipa, https://github.com/sipa/secp256k1/issues/16  I am checking other fields now and stuff
502 2013-11-05 10:57:01 <HaltingState> your at the internet task force thing?
503 2013-11-05 10:57:46 <HaltingState> their might need to be a function to verify if a compact signature is valid; i am generating compact signatures as random strings and it crashes, but validly generated signatures for the wrong message validate correctly
504 2013-11-05 10:59:47 <HaltingState> i might add this to the C test cases if its quick
505 2013-11-05 11:13:38 <HaltingState> sipa, writing unit tests in C now for the cases i tried in golang; will see if i can replicate; then will push
506 2013-11-05 11:16:51 <arioBarzan> For the sake of argument, if the alleged "selfish mining" attack is pooled effectively, how it would relate to the checkpoints which currently is put in the bitcoin-qt? If one could find a longer chain, should people ignore the checkpoints if it conflicts with that longer chain?
507 2013-11-05 11:19:01 <justaskingplz> a selfish mining attack would not target blocks of a sufficient age
508 2013-11-05 11:19:10 <justaskingplz> especially checkpoint blocks
509 2013-11-05 11:20:06 <justaskingplz> it becomes extremely hard to orphan blocks that old
510 2013-11-05 11:22:35 <arioBarzan> I know that would be "extremely hard", but I believe if hypothetically it does, either the checkpoints would be irrelevant, or the rule of longer chain.
511 2013-11-05 11:25:31 <sipa> arioBarzan: if checkpoints ever become relevant, we have failed
512 2013-11-05 11:26:27 <sipa> arioBarzan: the point of having checkpoints is not to lock-in the chain (though that is a side effect, and often misunderstood as preventing attacks); their purpose is to make an optimization safe
513 2013-11-05 11:26:39 <HaltingState> https://dl.dropboxusercontent.com/u/21517274/img/c_woot.png
514 2013-11-05 11:26:51 <sipa> to prevent someone who is catching up, from being fed a chain with invalid transactions
515 2013-11-05 11:26:52 <HaltingState> so long since i have written C, probably 4 months? but its like reflex...
516 2013-11-05 11:27:56 <arioBarzan> Some weeks ago, I mined a block at the height of 175, and then replaced the checkpoints with hash of my fake block and connected to my node to internet. It was very interesting experiment. I guess the nodes who ran old clients at the time had difficulties when connected to my rouge node.
517 2013-11-05 11:29:28 <sipa> arioBarzan: in fact, there are some ideas to abolish checkpoints entirely, or at least significantly reduce their importance
518 2013-11-05 11:30:01 <michagogo> cloud|"<arioBarzan> Some weeks ago, I mined a block at the height of 175, and then replaced the checkpoints with hash of my fake block and connected to my node to internet. It was very interesting experiment. I guess the nodes who ran old clients at the time had difficulties when connected to my rouge node."
519 2013-11-05 11:30:10 <michagogo> cloud|Why not a yellow node?
520 2013-11-05 11:30:20 <sipa> :D
521 2013-11-05 11:30:27 <michagogo> cloud|Also, that would just mean that your node would disagree with other nodes
522 2013-11-05 11:30:40 <sipa> it literally means he forked himself off :)
523 2013-11-05 11:30:46 <michagogo> cloud|They'd take your block, and simply not relay it
524 2013-11-05 11:31:06 <michagogo> cloud|And your client will refuse to accept the actual chain, so you've just created a 1-man fork
525 2013-11-05 11:31:48 <arioBarzan> I was trying to learn about mining, so it was easier for me to mine at difficulty 1. so for experimental reasons it was convenient to fork myself out :)
526 2013-11-05 11:31:58 <michagogo> arioBarzan: There's a testnet for that :-P
527 2013-11-05 11:32:27 <sipa> unfortunately, testnet difficulty is at 18k or so now
528 2013-11-05 11:32:47 <sipa> there's still the regtest network (maybe not in 0.8.5 yet, unsure)
529 2013-11-05 11:33:17 <HaltingState> sipa, src/tests.c:480:3: warning: implicit declaration of function secp256k1_ecdsa_recover_compact [-Wimplicit-function-declaration]
530 2013-11-05 11:33:18 <HaltingState>    int ret = secp256k1_ecdsa_recover_compact(
531 2013-11-05 11:33:28 <HaltingState> in test.c
532 2013-11-05 11:33:30 <sipa> with difficulty 0.00000000023 :)
533 2013-11-05 11:34:04 <sipa> < HaltingState> your at the internet task force thing?    <-- no, gmaxwell is
534 2013-11-05 11:34:19 <HaltingState> the test.c file is not importing the .h secp256k hmm
535 2013-11-05 11:34:27 <michagogo> Does regtest actually connect to other nodes across the network?
536 2013-11-05 11:34:27 <sipa> it probably should
537 2013-11-05 11:34:31 <michagogo> I thought it was local-only
538 2013-11-05 11:34:34 <sipa> michagogo: not by default
539 2013-11-05 11:34:36 <HaltingState> sipa, "it probably should" ahahah ya
540 2013-11-05 11:34:37 <arioBarzan> michagogo: Testnet wouldn't be that much enjoyable. In my forked chain, I used the same type of addresses as main net. It was also easy to use the public data for initial 175 blocks (from blockchain.info and other sites)
541 2013-11-05 11:35:01 <michagogo> Anyway, it's pretty easy to mine diff 1 blocks on testnet, as long as you don't need more than 6 in rapid succession
542 2013-11-05 11:35:07 <michagogo> just set your system clock ahead
543 2013-11-05 11:35:22 <michagogo> What internet task force thing?
544 2013-11-05 11:35:25 <HaltingState> your unit tests look like they are fine for ECC operations but there are no top level functional tests i guess
545 2013-11-05 11:35:44 <sipa> indeed
546 2013-11-05 11:35:51 <sipa> feel free to contribute :)
547 2013-11-05 11:36:11 <HaltingState> /home/atomos/secp256k1/src/tests.c:482: undefined reference to `secp256k1_ecdsa_recover_compact'
548 2013-11-05 11:36:26 <HaltingState> soooo its not linking that in, even in tests...
549 2013-11-05 11:36:41 <sipa> heh
550 2013-11-05 11:36:47 <sipa> that makes no sense
551 2013-11-05 11:37:05 <HaltingState> i know
552 2013-11-05 11:37:59 <Apocalyptic> how many people have the push priv to the main bitcoin github ?
553 2013-11-05 11:38:57 <sipa> Apocalyptic: 7
554 2013-11-05 11:40:59 <sipa> HaltingState: you need to either link with secp256k1.o, or include the necessary impl/*.h files directly
555 2013-11-05 11:41:29 <pigeons> michagogo: http://www.ietf.org/meeting/88/index.html i guess
556 2013-11-05 11:41:32 <HaltingState> sipa, on it; i am writing your unit tests and the things i crashed it with in golang
557 2013-11-05 11:54:34 <arioBarzan> A quote from Gavin reads: " The other safeguard, Andresen explained, has been Bitcoin’s “get big quick” strategy.  If enough Bitcoins can be put into circulation quickly, then it becomes much harder for any faction to corner the market in Bitcoins or to compromise their integrity." http://bollier.org/taxonomy/term/12
558 2013-11-05 11:54:48 <arioBarzan> anyone could explain this further?
559 2013-11-05 11:56:52 <arioBarzan> what is meant by "to corner the market in Bitcoins" ?
560 2013-11-05 11:58:15 <pigeons> http://en.wikipedia.org/wiki/Corner_the_market
561 2013-11-05 11:58:41 <pigeons> set the price by controlling the supply
562 2013-11-05 12:02:28 <melvster> can lock_time actually be used today?
563 2013-11-05 12:03:35 <melvster> oh found it, it says it's in the std client
564 2013-11-05 12:04:03 <sipa> yes, but without tx replacements it's not very useful
565 2013-11-05 12:05:52 <melvster> sipa: sorry for my ignorance, but what are tx replacements?
566 2013-11-05 12:06:42 <melvster> to do with the sequence number?
567 2013-11-05 12:07:15 <TD> yes
568 2013-11-05 12:07:26 <melvster> 
ACTION reading https://en.bitcoin.it/wiki/Contracts

569 2013-11-05 12:07:29 <sipa> melvster: sending a new version of a transaction, which replaces an older one
570 2013-11-05 12:07:46 <melvster> very cool
571 2013-11-05 12:08:04 <melvster> so i take it that tx replacements isnt implemented ...
572 2013-11-05 12:09:18 <TD> it was implemented and switched off
573 2013-11-05 12:09:28 <melvster> ah thanks
574 2013-11-05 12:11:11 <HaltingState> sipa, bad news; i replicated it in C
575 2013-11-05 12:11:29 <HaltingState> trying to push now; i have your copy of repo; how do i push to my copy
576 2013-11-05 12:12:13 <michagogo> HaltingState: git remote delete origin;git remote add origin <url>
577 2013-11-05 12:12:30 <michagogo> and perhaps git remote add upstream <sipa's url>
578 2013-11-05 12:12:37 <HaltingState> atomos@maslow:~/secp256k1$ git push -f https://github.com/haltingstate/secp256k1.git/
579 2013-11-05 12:12:37 <HaltingState> fatal: You are pushing to remote 'https://github.com/haltingstate/secp256k1.git/', which is not the upstream of
580 2013-11-05 12:12:37 <HaltingState> to update which remote branch.
581 2013-11-05 12:12:37 <HaltingState> your current branch 'master', without telling me what to push
582 2013-11-05 12:13:00 <michagogo> HaltingState: oh, try appending "master" to that
583 2013-11-05 12:13:16 <HaltingState> fatal: remote origin already exists.
584 2013-11-05 12:13:22 <t7> remote add url master
585 2013-11-05 12:13:29 <t7> makes it a bit easier
586 2013-11-05 12:13:39 <michagogo> HaltingState: actually, it's rm, not delete
587 2013-11-05 12:13:40 <t7> not master
588 2013-11-05 12:13:45 <michagogo> but it looks like there's also a rename
589 2013-11-05 12:14:03 <michagogo> git remote rename origin upstream;git remote add origin <url>
590 2013-11-05 12:14:52 <HaltingState> atomos@maslow:~/secp256k1$ git remote rename origin upstream;git remote add origin https://github.com/haltingstate/secp256k1atomos@maslow:~/secp256k1$ git push
591 2013-11-05 12:14:52 <HaltingState> fatal: The current branch master has no upstream branch.
592 2013-11-05 12:15:02 <HaltingState> michagogo, thanks i think that worked; magic incantations
593 2013-11-05 12:17:13 <HaltingState> atomos@maslow:~/secp256k1$ git push  --set-upstream origin maste
594 2013-11-05 12:17:13 <HaltingState> error: failed to push some refs to 'https://github.com/haltingstate/secp256k1'
595 2013-11-05 12:17:13 <HaltingState> error: src refspec maste does not match any.
596 2013-11-05 12:17:29 <HaltingState> nm missing r!! lol
597 2013-11-05 12:18:07 <HaltingState> omg, i broke github!!! wtf
598 2013-11-05 12:18:59 <sipa> lol
599 2013-11-05 12:21:14 <HaltingState> sipa, pushing; this is bad
600 2013-11-05 12:21:26 <HaltingState> sipa, https://github.com/haltingstate/secp256k1
601 2013-11-05 12:21:35 <HaltingState> do "make tests_fuzzer" and ./tests_fuzzer
602 2013-11-05 12:22:00 <HaltingState> i generate random signatures and messages and do secp256k1_ecdsa_recover_compact() which is signature check
603 2013-11-05 12:22:14 <HaltingState> and 600 out of 10,000 are returning 1...
604 2013-11-05 12:23:07 <sipa> i would expect more
605 2013-11-05 12:23:55 <sipa> it's not a signature check
606 2013-11-05 12:24:03 <sipa> it computes a public for which this is a valid signature
607 2013-11-05 12:24:27 <HaltingState> it says in documentation that if it returns valid pubkey that signature is valid
608 2013-11-05 12:24:28 <sipa> pretty much every message/signature combination should result in a valid public key
609 2013-11-05 12:24:36 <sipa> yes
610 2013-11-05 12:25:13 <HaltingState>  *           0: otherwise.
611 2013-11-05 12:25:13 <HaltingState>  *  Returns: 1: public key succesfully recovered (which guarantees a correct signature).
612 2013-11-05 12:25:18 <sipa> yes
613 2013-11-05 12:25:23 <sipa> i don't understand the problem
614 2013-11-05 12:25:38 <sipa> only that i would expect almost 100% to return 1
615 2013-11-05 12:25:57 <HaltingState> "public key succesfully recovered (which guarantees a correct signature)."
616 2013-11-05 12:26:09 <sipa> for that publci key, yes
617 2013-11-05 12:26:18 <HaltingState> it says that if it returns one, the signature is correct
618 2013-11-05 12:26:20 <sipa> for signature checking, you still have to compare that public key to what you'd expect
619 2013-11-05 12:26:38 <sipa> it just reconstructs *some* public key, for which this signature would be valid
620 2013-11-05 12:27:54 <sipa> if you start from a valid signature for message M and key K
621 2013-11-05 12:28:01 <sipa> and modify either the message or the signature
622 2013-11-05 12:28:08 <sipa> you won't recover K from it anymore
623 2013-11-05 12:28:16 <sipa> so the recovery still returns 1
624 2013-11-05 12:28:21 <sipa> but it's not what you expect
625 2013-11-05 12:29:03 <sipa> or put otherwise: there is no way to check that a signature is valid without knowing who should have sent it
626 2013-11-05 12:29:16 <HaltingState> also i am using a random number generator with fixed seed and numebr is 535, 539, 9460 out of 1000 etc and wtf
627 2013-11-05 12:29:47 <HaltingState> it should be generating same sequence everytime, the seed is fixed on my random number generator; so wtf?
628 2013-11-05 12:30:01 <sipa> can you please stop panicking and just read up on what key recovery is in the first place?
629 2013-11-05 12:30:15 <HaltingState> sipa, https://dl.dropboxusercontent.com/u/21517274/img/Screenshot%20from%202013-11-05%2004%3A30%3A06.png
630 2013-11-05 12:30:51 <HaltingState> i am generating same message and same signature ; same sequence everytime program is run and i am counting up number of times signature recovery returns 1 and the number is changing; meaning is stocastic or there is memory leak
631 2013-11-05 12:32:08 <sipa> line 34
632 2013-11-05 12:32:14 <sipa> don't you mean & instead of &&
633 2013-11-05 12:32:35 <HaltingState> ahaha
634 2013-11-05 12:32:48 <sipa> and t is not initialized
635 2013-11-05 12:32:57 <sipa> dude, stop implementing your own RNG
636 2013-11-05 12:33:35 <HaltingState> sipa, i  crashed it :)
637 2013-11-05 12:33:52 <sipa> ?
638 2013-11-05 12:33:54 <HaltingState> https://dl.dropboxusercontent.com/u/21517274/img/Screenshot%20from%202013-11-05%2004%3A33%3A49.png
639 2013-11-05 12:34:01 <HaltingState> i replicated the segfault
640 2013-11-05 12:34:30 <sipa> that is more interesting :)
641 2013-11-05 12:34:40 <sipa> i'll look at it tonight
642 2013-11-05 12:35:15 <HaltingState> t should not matter, it gets set so its not used unitialized
643 2013-11-05 12:35:32 <HaltingState> but valgrind is not showing anything; this is crazy
644 2013-11-05 12:35:34 <sipa> in rand_byte
645 2013-11-05 12:35:57 <HaltingState> hehe :)
646 2013-11-05 12:36:30 <HaltingState> ya now its straight core dump
647 2013-11-05 13:36:11 <gulli> Hey, could anyone give me feedback on how this system could work?
648 2013-11-05 13:36:11 <gulli> https://notendur.hi.is/~glf/plan.png
649 2013-11-05 13:36:22 <gulli> Im making a small exchange, game cyrrency <-> btc/ltc
650 2013-11-05 13:37:08 <graingert> what's an HD wallet?
651 2013-11-05 13:37:25 <graingert> are there not open source exchange code-bases available, gulli?
652 2013-11-05 13:41:04 <gulli> greingert: https://en.bitcoin.it/wiki/Deterministic_wallet
653 2013-11-05 13:41:23 <gulli> graingert: no ><
654 2013-11-05 13:48:20 <graingert> gulli: https://github.com/justcoin/snow
655 2013-11-05 13:48:24 <graingert> according to pigeons
656 2013-11-05 13:59:07 <pigeons> i'm not saying to use it for something other than a game, was just responding to "does open source exchange code exist?"
657 2013-11-05 15:29:28 <michagogo> cloud|;;bc,stas
658 2013-11-05 15:29:29 <gribble> Error: "bc,stas" is not a valid command.
659 2013-11-05 15:29:35 <michagogo> cloud|;;bc,stats
660 2013-11-05 15:29:39 <gribble> Current Blocks: 268098 | Current Difficulty: 3.9092878763808584E8 | Next Difficulty At Block: 268127 | Next Difficulty In: 29 blocks | Next Difficulty In About: 4 hours, 1 minute, and 23 seconds | Next Difficulty Estimate: 511860733.453 | Estimated Percent Change: 30.93452
661 2013-11-05 15:30:08 <michagogo> cloud|;;diffchange
662 2013-11-05 15:30:10 <gribble> Estimated percent change in difficulty this period | 30.91167 % based on data since last change | 34.68031 % based on data for last three days
663 2013-11-05 16:08:49 <petertodd> TD: re: https://plus.google.com/+MikeHearn/posts/LW1DXJ2BK8k, +∞
664 2013-11-05 16:11:21 <brocktice> nice
665 2013-11-05 16:21:59 <grau> TD: I applaud your courage to come out with a straight opinion on the matter.
666 2013-11-05 16:24:43 <petertodd> grau: ..and I'm sad that "courage" is an appropriate word in this situation :(