1 2013-11-24 00:01:09 <HM2> better an open source project tries to put an alt implementation online than a closed one
  2 2013-11-24 00:01:18 <HM2> at least you can scream at them on github
  3 2013-11-24 00:01:22 <gmaxwell> HM2: a closed one would go absolutely no where. It would be riskless.
  4 2013-11-24 00:01:27 <petertodd> HM2: nah, there's more alt-implementations out there then we could ever need - a closed one wouldn't do any harm to anyone except it's users
  5 2013-11-24 00:03:10 <amiller> so the problem with libbitcoin is that it's technically good enough that it could be a plausible alternative for unwitting miners?
  6 2013-11-24 00:03:41 <petertodd> yup
  7 2013-11-24 00:03:52 <amiller> it could have bugs, the community behind it is prone to advertise it and direct miners towards it, and the problem with the code is that it's too competent
  8 2013-11-24 00:04:14 <HM2> miners have a strong incentive to avoid netsplits though right
  9 2013-11-24 00:04:17 <HM2> and bugs cause netsplits
 10 2013-11-24 00:04:19 <berndj> but possibly/probably still different
 11 2013-11-24 00:04:56 <berndj> bugs don't cause netsplits if everyone has the bug
 12 2013-11-24 00:04:58 <petertodd> HM2: their incentive to avoid them is significantly less than amunt users can lose from them
 13 2013-11-24 00:05:05 <gmaxwell> I haven't seen any real evidence that it's been tested at all for agreement with widely deployed nodes except by having it sync the chain... which is only a one sided test, and has very poor coverage.
 14 2013-11-24 00:05:25 <pigeons> so because consensus is hard and there can be non-obvious, subtle bugs, such as the bdb locl fork, we can never have another full-node implementation that is significantly mined with?
 15 2013-11-24 00:05:35 <petertodd> amiller: well, "too competent" in this case is "just barely competent enough that it works at all" pretty much
 16 2013-11-24 00:05:45 <gmaxwell> pigeons: nah, but doing one requires substantial evidence-producing effort.
 17 2013-11-24 00:06:04 <HM2> why did they start the project anyway
 18 2013-11-24 00:06:08 <gmaxwell> E.g. you can't even use libbitcoin with bluematts' blocktester. (or couldn't when I looked last at least)
 19 2013-11-24 00:06:12 <HM2> was their feeling they couldn't get involved in mainline
 20 2013-11-24 00:06:19 <HM2> that you guys have no incentive to improve mainline?
 21 2013-11-24 00:06:19 <petertodd> amiller: anyway, as I wrote on the forums, by making an alt-implementation politically they're making a big mistake if they want to take control away from the bitcoin foundation
 22 2013-11-24 00:06:50 <petertodd> HM2: amir wants to take control away from the bitcoin foundation is a part of why
 23 2013-11-24 00:07:19 <pigeons> is that admitting bitcoin foundation has "control" ? ;)
 24 2013-11-24 00:07:25 <HM2> that's a lot of effort to expend on a political motive
 25 2013-11-24 00:07:27 <gmaxwell> pigeons: bluematt's full node support for bitcoinj is the only I've seen produce the kind of evidence of effort I'd expect, but even thats a long way from complete.
 26 2013-11-24 00:07:47 <HM2> if he wanted to do that he could just fork the client and innovate like a mofo
 27 2013-11-24 00:08:01 <petertodd> pigeons: heh, that's part of what amir gets wrong... though it's more complex than to just say they do or don't have control
 28 2013-11-24 00:08:43 <petertodd> HM2: that was my advise: turn the consensus critical part of the bitcoin reference codebase into a "set-in-stone" library, and focus on a client/node implementation using that library
 29 2013-11-24 00:08:51 <petertodd> s/advise/advice/
 30 2013-11-24 00:09:21 <HM2> modularisation sounds like a good idea
 31 2013-11-24 00:09:31 <berndj> petertodd, do you think the claim that it's there to give an escape route in case a bug were to render a bitcoind monoculture dead overnight, is disingenuous?
 32 2013-11-24 00:10:02 <petertodd> HM2: that strategy emphasises that the satoshi bitcoin protocol is something we all must agree on to change, rather than letting the foundation eventually start being seen as the guardians of that *evolving* specification
 33 2013-11-24 00:10:26 <petertodd> berndj: yes. bitcoin's strength is the monoculture; consensus systems are weird.
 34 2013-11-24 00:10:41 <licnep> alternative clients are a must, and modularization is a good idea imo
 35 2013-11-24 00:10:56 <berndj> petertodd, even if there turns out to be a bug that implements OP_GIVEALLYOURMONEY?
 36 2013-11-24 00:11:04 <gmaxwell> berndj: espeically
 37 2013-11-24 00:11:47 <petertodd> berndj: YES! we're better off if everyone either implements the bug, so it's clear the bug needs fixing and the blockchain simply gets cleanly rolled back, or if the bug doesn't happen at all. We're much worse off if only some implementations lets that happen.
 38 2013-11-24 00:11:56 <gmaxwell> berndj: the most important thing for a bitcoin node to do is to come to an agreement about the unique best state with ~all other nodes.
 39 2013-11-24 00:12:10 <amiller> it's pretty clear that amir is not afraid to spend an enormous amount of personal resource to pursue what he perceives is a socially worthwhile cause
 40 2013-11-24 00:12:18 <gmaxwell> berndj: diversity is useful, but diversity in the consensus parts is absolutely fatal.
 41 2013-11-24 00:12:21 <berndj> i don't get the part about "rolled back"
 42 2013-11-24 00:12:24 <HM2> i don't believe in full decentralisation. all that's important is those in control can be shot and the rest of us can enjoy it and then recover gracefully from the trauma
 43 2013-11-24 00:12:45 <licnep> lol you guys are SO afraid of forks
 44 2013-11-24 00:12:54 <HM2> in bitcoin that means fork and elect a new pope
 45 2013-11-24 00:13:09 <berndj> weren't there a couple of anarcho-jerks who refused to get "rolled back" when something got hacked and the foundation ended up bailing out the bank^Wexchange?
 46 2013-11-24 00:13:23 <amiller> i really like the two-factions aspect of bitcoin's community so far, i'm pretty happy with the Foundations efforts especially as it turned out in the recent senate hearings which were really bitcoin-positive
 47 2013-11-24 00:13:25 <gmaxwell> berndj: HUH?
 48 2013-11-24 00:13:26 <gavinandresen> gmaxwell petertodd: imagine there are eleven implementations, each of which is used by about 9 percent of the hashing power.  A bug in one of them would NOT be fatal.
 49 2013-11-24 00:13:33 <petertodd> A good analogy: Imagine you have a group of people, and you're trying to make sure that theives can't run off with a tresure chest of gold. All you can do is hang on to the chest and hope you *collectively* are strong enough that a very strong thief can't pull harder than the rest of you. Are you better off if you all hang on to the treasure chest at once, or if sometimes you end up wasting effort pulling in opposite directions?
 50 2013-11-24 00:13:38 <gavinandresen> I think we should work towards that
 51 2013-11-24 00:13:39 <amiller> but i'm also glad the darkwallet crew is around
 52 2013-11-24 00:13:55 <amiller> there should be more factions not fewer
 53 2013-11-24 00:14:10 <licnep> petertodd: that's a shitty analogy
 54 2013-11-24 00:14:12 <amiller> speaking of which... are there any china-specific bitcoin codebases?
 55 2013-11-24 00:14:40 <licnep> more like, is it better if all the people use the same machine to secure the treasure chest, so if a bug in that machine is found everything is fucked?
 56 2013-11-24 00:14:46 <petertodd> Now what's even weirder about Bitcoin, is in my treasure chest example, because this is software a really clever attacker could create multiple transactions at once that split the effort *suddenly* into tiny little bits of hashing power, and then overpower any one of those small groups.
 57 2013-11-24 00:14:47 <amiller> i predicted a ChinaCoin altcoin by now... but at least a codebase fork or something seems plausible
 58 2013-11-24 00:15:02 <gmaxwell> gavinandresen: depends on the kind of disagreement but I agree generally. How do we get there when a single party actually physically controls about 20% of the current hashpower?  Or when the network hasn't has a largest pool with <30% for years now?
 59 2013-11-24 00:15:13 <petertodd> licnep: well, I'm sorry, but you're simply wrong. Decentalized consensus systems are weird that way; totally unlike other systems.
 60 2013-11-24 00:15:27 <gmaxwell> licnep: if everything is 'fucked' then things can be fixed.
 61 2013-11-24 00:15:47 <licnep> with an alternative implementation they may get fixed even faster
 62 2013-11-24 00:15:49 <gmaxwell> licnep: a split in consensus can result in a brakage that can't be fixed because its mutually exclusive.
 63 2013-11-24 00:15:51 <licnep> incentives..
 64 2013-11-24 00:16:15 <petertodd> licnep: fixing the code does nothing - getting hashing power to use the fix is what helps.
 65 2013-11-24 00:16:27 <berndj> isn't bitcoind 0.8.4 already a different implementation than 0.8.5?
 66 2013-11-24 00:16:53 <licnep> petertodd: yea of course ideally you'd have at least three main implementations, two is not enough cause one will always have the majority of hashing power
 67 2013-11-24 00:17:00 <gavinandresen> gmaxwell petertodd : you both tend to wander off into "what if" land too quickly, in my humble opinion.  In practice, we will do the best we can and things will be messy and complicated
 68 2013-11-24 00:17:03 <gmaxwell> berndj: no— not in the consensus criticial parts, and there is extensive (but, not yet enough, agreed) testing infrastructure to verify that.
 69 2013-11-24 00:17:04 <petertodd> berndj: not really, the *consensus-critical* part of the code changes rarely, and we work very hard to make sure that we don't acidentally change it
 70 2013-11-24 00:17:31 <petertodd> licnep: Doesn't work that way: an attacker can *delibrately* fork all three at once.
 71 2013-11-24 00:17:32 <gmaxwell> gavinandresen: Please don't bin me in with petertodd.
 72 2013-11-24 00:17:55 <petertodd> gmaxwell: lol, don't bin me in with a spherical cow model of petertodd's thought processes either :P
 73 2013-11-24 00:18:01 <gmaxwell> gavinandresen: I'm not proposing a hypothetical. 20% of the hashpower is under physical control of a single person and his employees right now.
 74 2013-11-24 00:18:17 <gmaxwell> gavinandresen: how do we get 11 implementations with 9% each in this world that we're living in to day.
 75 2013-11-24 00:18:30 <gavinandresen> gmaxwell: apologies for "binning"
 76 2013-11-24 00:18:45 <gmaxwell> S'kay.
 77 2013-11-24 00:18:51 <gavinandresen> gmaxwell: how?  We do things like write a cross-implementation testing tool, JSON-based unit tests
 78 2013-11-24 00:18:56 <gavinandresen> We try to tighten up rules
 79 2013-11-24 00:18:56 <licnep> petertodd: so what? i'm not sure i get the point
 80 2013-11-24 00:19:01 <gavinandresen> We try to simplify when we can
 81 2013-11-24 00:19:08 <gmaxwell> (hah, and I'd agree with the complaint in any case. Just not the binning!)
 82 2013-11-24 00:19:08 <licnep> definitely such a situation would get noticed and people would stop spending until it's fixed
 83 2013-11-24 00:19:09 <gavinandresen> We do all of the things that we're (slowly) doing already
 84 2013-11-24 00:19:13 <petertodd> gmaxwell: I agree that in the future we may be at the point where the "10x different implementations" thing actually works out, but we're a long way from getting there.
 85 2013-11-24 00:19:55 <petertodd> gmaxwell: For now we're much better off with the "one master codebase" strategy, ironically in part because hashing power is so !@$% centralized that fixing stuff is easy.
 86 2013-11-24 00:19:57 <gavinandresen> RE: concentrated hashpower:  make it trivial to run p2pool would be a great start
 87 2013-11-24 00:19:58 <licnep> hopefully we'll get to genetic implementations that compete against each other, reproduce and evolve..
 88 2013-11-24 00:20:13 <licnep> (and become self-conscious)
 89 2013-11-24 00:20:24 <petertodd> licnep: yeah, take that to #bitcoin...
 90 2013-11-24 00:20:28 <roconnor> What's this coinvalidation thing?  I've been browsing the forums looking for information but ... you know how the forums are.
 91 2013-11-24 00:20:44 <licnep> petertodd: genetic algorithms are a thing, it's not that far fetched
 92 2013-11-24 00:21:03 <petertodd> licnep: This has nothing to do with decentralized consensus systems. Go away.
 93 2013-11-24 00:21:23 <HM2> 10 implementations seems unlikely. things tend to settle down in to 2-3 implementations. Take HTTP: 50% apache, 20% Microsoft IIS, 15% nginx, 5% other
 94 2013-11-24 00:21:37 <berndj> it has to do with mutation testing
 95 2013-11-24 00:21:38 <licnep> petertodd: it's exactly what we were talking about? what? diversification of clients
 96 2013-11-24 00:21:46 <licnep> modular or genetic clients could provide that
 97 2013-11-24 00:21:51 <HM2> wait that's only 90% :S
 98 2013-11-24 00:22:11 <petertodd> HM2: Right, but for *standards* things very often settle down to 1 standard, and we've got a case where security is directly proportinal to how many people are on the one single standard.
 99 2013-11-24 00:22:27 <HM2> SSL is that way too
100 2013-11-24 00:22:45 <petertodd> HM2: Like it or not, Bitcoin is really weird that way.
101 2013-11-24 00:23:01 <licnep> the standard is the protocol, not the client
102 2013-11-24 00:23:17 <petertodd> licnep: What language is the standard written in?
103 2013-11-24 00:23:37 <licnep> petertodd: human readable language?
104 2013-11-24 00:23:48 <petertodd> licnep: nope, C++
105 2013-11-24 00:23:59 <licnep> petertodd: that's cause no one took the time to write it yet
106 2013-11-24 00:24:19 <petertodd> licnep: Directly executable standards are a lovely thing.
107 2013-11-24 00:24:29 <gmaxwell> A standard written in non-machine-excutable language can not be the standard, in a meaningful sense, in a consensus system.
108 2013-11-24 00:24:39 <licnep> i would respectfully disagree
109 2013-11-24 00:24:50 <licnep> the more freedom a standard lives to implementation the better
110 2013-11-24 00:24:59 <berndj> which, exact, dialect of the language though
111 2013-11-24 00:25:02 <petertodd> The real consensus issues that are hard to fix are actually a step beyond the standard itself, issues like "What's the largest re-org that should be supported, for some sense of supported?"
112 2013-11-24 00:25:04 <gmaxwell> e.g. The specification says X. 99% of the nodes do !X.  You do X.  Whos wrong?
113 2013-11-24 00:25:12 <licnep> gmaxwell: ever heard of the internet?
114 2013-11-24 00:25:18 <licnep> oh in a consensus system
115 2013-11-24 00:25:23 <licnep> it would still work
116 2013-11-24 00:25:25 <gmaxwell> licnep: the internet is not a consensus system.
117 2013-11-24 00:25:32 <licnep> yea didn't read that part
118 2013-11-24 00:26:04 <berndj> is the standard written in GCC 3.4's C++ with STL bugs A, B and C, or in LLVM something or other with STL bugs D, E and F?
119 2013-11-24 00:26:16 <licnep> alternative clients will be a thing anyway, and there's nothing that can be done to stop them
120 2013-11-24 00:26:18 <gmaxwell> (And I note that even in general internet protocols, the robustness principle is now generally considered to be bad advice, as it's resulted in impossible complexity in many cases)
121 2013-11-24 00:26:20 <HM2> I love CoinJoin btw gmaxwell, the concept is so incredibly simple to pickup
122 2013-11-24 00:26:27 <licnep> unless bitcoin becomes officially centralized
123 2013-11-24 00:26:28 <petertodd> berndj: "is the standard written for a computer with 1GB of ram or 2GB?"
124 2013-11-24 00:26:44 <berndj> not the same thing and i think you know it
125 2013-11-24 00:27:17 <petertodd> berndj: Oh no, it's very similar, which is why I'm saying that even an executable standard is more complex than it sounds.
126 2013-11-24 00:27:21 <gmaxwell> licnep: perhaps you're overly fixated on the word 'client'— the concern isn't about "client" behavior, but consensus behavior.  Diversity in client behavior is a fantastic thing which I wish we had more of ASAP.
127 2013-11-24 00:27:47 <berndj> petertodd, crashing because you're out of RAM is very different to continuing to execute, but differently
128 2013-11-24 00:27:52 <petertodd> Which gets down to my non-spherical cow advice that we should stick with the idea of an executable standard for now because even getting consensus on that si something we don't understand well yet.
129 2013-11-24 00:27:55 <gmaxwell> licnep: And sure, there will be other implementations of everything— but making sure people know the difficulty and danger in differences in consensus behavior is important.
130 2013-11-24 00:28:32 <licnep> gmaxwell: the consensus part hasn't changed much anyway, and i don't think it's _that_ hard to implement, unless more and more bloat gets added
131 2013-11-24 00:28:54 <licnep> the transaction scripts are probably part of that unnecessary bloat... but whatever
132 2013-11-24 00:28:54 <petertodd> berndj: Whether or not it's better for a node to crash out of ram in, say, a re-organization is by itself a very complex topic.
133 2013-11-24 00:29:00 <gmaxwell> licnep: it's very hard to implement, and we have proof of this in that there are many implementations already and they've all been wrong.
134 2013-11-24 00:29:27 <licnep> 'wrong' is a temporary state
135 2013-11-24 00:29:30 <petertodd> licnep: a few weeks ago I spent something like 2-3 hours looking for consensus bugs in a few of the alt-implementations and found a half-dozen.
136 2013-11-24 00:29:45 <petertodd> licnep: that's how bad it is. How long it will take to get from that to perfect is anyone's guess...
137 2013-11-24 00:29:47 <licnep> petertodd: let me guess, cause of scripts?
138 2013-11-24 00:29:54 <gmaxwell> licnep: which, if widely deployed, can cause millions of dollars in losses which are irrepariable, even to uses who don't use them.
139 2013-11-24 00:30:28 <licnep> gmaxwell: i think you're being overly catastrophic
140 2013-11-24 00:30:56 <gmaxwell> licnep: I think you are a newbie who doesn't understand the enviroment well yet, but you will agree with me after you've learned more. :)
141 2013-11-24 00:30:59 <licnep> they 'could' but that's like a worst case scenario (which of course must be considered)
142 2013-11-24 00:31:31 <gmaxwell> licnep: will, if widely deployed when such a bug still exists: because it's possible to profit from triggering it, so someone will.
143 2013-11-24 00:31:36 <petertodd> licnep: yup, adding scripts to bitcoin may very well have been a bad engineering decision, but they are very useful too.
144 2013-11-24 00:31:40 <licnep> gmaxwell: how many millions were lost in the last fork?
145 2013-11-24 00:32:20 <gmaxwell> licnep: there were funds lost, but not millions. IIRC one person also performed a large (1000 BTC double spend?) but paid it back.
146 2013-11-24 00:32:33 <petertodd> licnep: Every day that Bitcoin doesn't work is worth 3.5 million in mining revenue for sarters.
147 2013-11-24 00:32:39 <petertodd> *starters
148 2013-11-24 00:33:21 <petertodd> licnep: If bitcoin is an important transaction system businesses will be unable to do business whenever the system doesn't work, and that very quickly adds up to millions for any decently large system.
149 2013-11-24 00:33:30 <licnep> every holiday shops loose billions in revenue, those calculations don't make much sense, it's more like delayed revenue
150 2013-11-24 00:33:40 <gmaxwell> licnep: and in that case it wasn't much of a fork, most nodes were on the restrictive side.  It would have self resolved in 2-3 blocks except there were two miners on the less restrictive side which alone were >50% hashpower.
151 2013-11-24 00:33:43 <licnep> i get your points tho
152 2013-11-24 00:33:48 <petertodd> licnep: nah, doesn't work that way when there are competitors to your system
153 2013-11-24 00:33:59 <gmaxwell> petertodd: meh, kind of a lame point.
154 2013-11-24 00:34:08 <petertodd> gmaxwell: what, bitcoin being down?
155 2013-11-24 00:34:09 <berndj> gmaxwell, that related to the HUH earlier, but i'm struggling to find the right search terms
156 2013-11-24 00:34:25 <petertodd> gmaxwell: I give those points because they show how in the absense of malic the losses are still huge.
157 2013-11-24 00:34:29 <berndj> something something refused to give it back
158 2013-11-24 00:34:30 <petertodd> *malice
159 2013-11-24 00:34:37 <petertodd> 
ACTION needs a new keyboard.

160 2013-11-24 00:35:28 <petertodd> gmaxwell: The most profitable ways to exploit lack of consensus for attackers is still an open research question after all.
161 2013-11-24 00:35:36 <licnep> well you guys have fun when some hacker finally discovers a vuln in the client and makes bitcoin completely useless
162 2013-11-24 00:35:54 <licnep> i think i understand the downside of multiple implementations, but a single one is very risky too
163 2013-11-24 00:35:57 <petertodd> licnep: we support a diversity in client implementations you realize
164 2013-11-24 00:36:03 <midnightmagic> licnep: It's built, operated, and used by humans. Problems will be corrected.
165 2013-11-24 00:36:07 <gmaxwell> licnep: wrt script, I'm sad to see you complain about it. It's indeed a complicated thing, but it's utterly essential if bitcoin's benefits aren't to be lost right away by everything being built on top of it having to be highly centeralized in order to accomplish anything more than just transfering value.
166 2013-11-24 00:36:11 <licnep> petertodd: wouldn't seem so
167 2013-11-24 00:36:16 <licnep> midnightmagic: that's my point exactly
168 2013-11-24 00:36:43 <petertodd> licnep: There *should* be lots of clients out there, the issue is what codebase miners should use, and what codebase people should use to verify that a transaction is valid. That != clients at all.
169 2013-11-24 00:37:16 <petertodd> licnep: Standard advice for merchants is to run a reference implementation node, and have whatever internal systems you are using connect to that trusted node.
170 2013-11-24 00:37:17 <berndj> should there be non-x86 versions?
171 2013-11-24 00:37:18 <licnep> gmaxwell: i know they're really cool, but maybe should be something somehow separated, 'on top' of bitcoin, not really sure tho, haven't given it much thought
172 2013-11-24 00:37:25 <gmaxwell> licnep: consider that when their is risky diversity in consensus any otherwise benign differences between implementations are themselves "vuln"s, we must advance the art of proving that distinct software does the same thing in order to avoid them.
173 2013-11-24 00:37:49 <gmaxwell> licnep: they're what generally makes it possible to seperate out _other things_.
174 2013-11-24 00:37:57 <petertodd> licnep: Similarly a diverse set of node implementations is really valuable, because it helps keep the network from being partitioned.
175 2013-11-24 00:39:11 <gmaxwell> s/their/there/  ... need moar sleep.
176 2013-11-24 00:39:11 <midnightmagic> licnep: Namecoin had a bug which allowed people to steal domains completely. People stole a bunch. A fix was released. Everyone upgraded. The coins reverted to their normal owners. It wasn't a big deal. People were shouting "namecoin's dead!" But of course it wasn't. Aside from the problems of improperly spent coins, the system will recover, heal, and immunize itself against that kind of attack again, forever.
177 2013-11-24 00:39:24 <petertodd> It would be absolutely wonderful news to hear that Dark Wallet had decided to use the consensus-critical part of the reference implementation to determine if blocks were valid, and then wrote a ground-up redesign of everything else, including a brand new P2P protocol to distribute those blocks and transactions.
178 2013-11-24 00:39:48 <gmaxwell> midnightmagic: uh. you know the names are still stolen right?
179 2013-11-24 00:40:06 <midnightmagic> gmaxwell: The client ignores the stolen txn.
180 2013-11-24 00:40:12 <licnep> midnightmagic: maybe, maybe not. If the hack has been there for a while and no one knows how long, it would be hard to choose which transactions are legit and which arent
181 2013-11-24 00:40:15 <gmaxwell> midnightmagic: not currently it doesn't.
182 2013-11-24 00:40:25 <licnep> people would very likely run away from btc
183 2013-11-24 00:40:35 <gmaxwell> what licnep said.
184 2013-11-24 00:40:41 <licnep> or maybe not, it really depends, these are hypothetical scenarios
185 2013-11-24 00:40:46 <licnep> it's hard to speculate
186 2013-11-24 00:40:48 <gmaxwell> Fortunately namecoin is mostly worthless esp with names, so there was no mutual exclusion.
187 2013-11-24 00:40:57 <midnightmagic> gmaxwell: The fix is in, and d/wav reverted the moment I resync'd the chain.
188 2013-11-24 00:41:28 <gmaxwell> The real kinds of risks are where someone uses a forking bug to rob both mtgox and bitstamp with the same coins. There is no way to make everyone whole without inflating the currency. What now?
189 2013-11-24 00:41:31 <midnightmagic> gmaxwell: In fact, there are three separate, parlty independent fixes in three different mainlines that corrected it.
190 2013-11-24 00:41:39 <petertodd> licnep: bitcoin's primary use right now is as a long-term store of value; bitcoin has very little usage as a transaction system right now. So a major problem would probably have little effect given people will know it can be fixed and is only temporary.
191 2013-11-24 00:42:09 <gmaxwell> midnightmagic: transfer wav to me then.
192 2013-11-24 00:42:09 <HM2> I had no idea that Gnutella clients used Merkle trees - http://bitzi.com/developer/bitprint
193 2013-11-24 00:42:15 <HM2> I wonder how long they've been doing that
194 2013-11-24 00:42:23 <midnightmagic> gmaxwell: d/wav isn't mine. None of mine were stolen.
195 2013-11-24 00:42:36 <pigeons> i think its kind of silly to say its a long term store of value, we dont know that,
196 2013-11-24 00:42:50 <midnightmagic> gmaxwell: d/wav read the hacked message. I rebuilt with the fix. It now reads its original value.
197 2013-11-24 00:42:58 <licnep> petertodd: well that's sad imo,i always hoped the direction was for bitcoin to become a transaction system, i think satoshi's original idea was like that too.
198 2013-11-24 00:43:14 <HM2> looks like THEX has been around since 2002
199 2013-11-24 00:43:20 <HM2> cool beans
200 2013-11-24 00:43:20 <licnep> he wanted microtransactions, something that was like coins but for the web
201 2013-11-24 00:43:25 <petertodd> pigeons: we don't know, but it could be; my point is that transactions cost about $40 each so it's obviously not a transaction medium right now.
202 2013-11-24 00:43:48 <licnep> it's still cool if it stays mainly a store of value tho
203 2013-11-24 00:43:57 <licnep> no problem with that, just sadness for missed potential
204 2013-11-24 00:44:08 <shesek> is there a better way to extract the public key of a (multisig) transaction signature other than brute forcing all the possible nRecId and public keys? here's what I'm currently doing, which feels kinda hacky: http://pastie.org/pastes/8504252/text
205 2013-11-24 00:44:15 <midnightmagic> The potential for loss is much greater with a break. But people have seen the utility. lol It's not going away even in the face of a break.
206 2013-11-24 00:44:31 <petertodd> licnep: well it's a shitty system for transactions because it can't both scale and be decentralized. can such a system exist? sure, but bitcoin in its current form isn't that system.
207 2013-11-24 00:45:04 <gmaxwell> midnightmagic: the hardfork hasn't happened yet (not till block 175k iirc?) so say the 'right' owner of wav transfers it, ... how could that get mined?
208 2013-11-24 00:45:05 <licnep> petertodd: yea scalability is an issue i guess, haven't looked that much into it tho
209 2013-11-24 00:45:25 <licnep> we can just pray for moore's law i guess
210 2013-11-24 00:45:37 <midnightmagic> gmaxwell: The stolen txn can be mined, the client ignores the theft txn as though they don't exist.
211 2013-11-24 00:46:32 <petertodd> midnightmagic: note how right now even that model doesn't let you update your records after a thief steals your domain
212 2013-11-24 00:46:36 <gmaxwell> midnightmagic: right now the original namecoin rules say 'evil' owns wav. Your client seems to think good owns wav. If good transfers wav to me, that wouldn't be permitted under the original rules.
213 2013-11-24 00:47:42 <midnightmagic> petertodd: *shrug* I understood it was corrected even with that later discovery.
214 2013-11-24 00:47:45 <midnightmagic> Might be wrong.
215 2013-11-24 00:48:00 <petertodd> midnightmagic: post-hardfork, it'll be corrected, but for now namecoin doesn't work very well is my point
216 2013-11-24 00:48:26 <petertodd> midnightmagic: it's an interesting example where a system that *didn't* do validation of the contents of a block is actually more useful
217 2013-11-24 00:48:39 <gmaxwell> midnightmagic: I know the 'fix' that I'm running hasn't changed anything yet except not mining any of the spends of evil names. But I dunno about all fixes.
218 2013-11-24 00:48:53 <midnightmagic> petertodd: It *appears* to work fine even for stolen domains. That's why d/wav currently reads "Not today!"
219 2013-11-24 00:49:45 <gmaxwell> for all I know they made a mistake and fixed it prematurely in some implementations and the network will fork as soon as someone moves a clawed back na,e
220 2013-11-24 00:50:04 <midnightmagic> gmaxwell: It's already happened.
221 2013-11-24 00:50:24 <petertodd> midnightmagic: ah, yeah, that's because you can steal it back basically
222 2013-11-24 00:50:35 <gmaxwell> midnightmagic: whats already happened?
223 2013-11-24 00:50:59 <petertodd> midnightmagic: e.g. *because* of the bug, you have a system that doesn't validate the contents of a block, and hence a client-side fix works...
224 2013-11-24 00:51:17 <Luke-Jr> I'm not complaining, but are we merging #namecoin-dev into this channel? (if so, I can /part the former.. :P)
225 2013-11-24 00:51:31 <midnightmagic> bleh that one's dead
226 2013-11-24 00:51:44 <midnightmagic> I don't even think khalahan is in there
227 2013-11-24 00:51:47 <petertodd> midnightmagic: if people were using namecoin with SPV and a UTXO commitment scheme that wouldn't have worked
228 2013-11-24 00:52:01 <Luke-Jr> midnightmagic: is khalahan anywhere? :/
229 2013-11-24 00:52:13 <midnightmagic> Luke-Jr: Yeah he came back to deal with the fix.
230 2013-11-24 00:52:18 <midnightmagic> And he talks to me too.
231 2013-11-24 00:52:23 <midnightmagic> (occasionally)
232 2013-11-24 00:52:29 <gmaxwell> midnightmagic: voices in your head?
233 2013-11-24 00:52:35 <gmaxwell> Satoshi talks to me too...
234 2013-11-24 00:52:40 <midnightmagic> :-P
235 2013-11-24 00:52:45 <gmaxwell> They said the drugs would start working soon.
236 2013-11-24 00:52:49 <Luke-Jr> topic.. lol .. NEWS: Merged Mining starts at block 19200
237 2013-11-24 00:52:52 <[\\\]> which they?
238 2013-11-24 00:52:55 <[\\\]> the same voices?
239 2013-11-24 00:54:20 <midnightmagic> lol
240 2013-11-24 00:56:26 <midnightmagic> petertodd: anyway, I would say the UTXO and SPV stuff in bitcoin is the tradeoff bitcoin made for performance reasons. It's made bitcoin slightly more fragile in the event of a namecoin-like hack, but really all that needs to happen is a correction to the rules (maybe hardfork) and a fresh utxo and spv authorities and.. meh.
241 2013-11-24 00:57:41 <petertodd> midnightmagic: sure, I'm just pointing out that UTXO and SPV is just one of many possible designs, each with different sets of trade-offs.
242 2013-11-24 00:57:50 <midnightmagic> petertodd: I agree with you.
243 2013-11-24 00:58:38 <midnightmagic> Apparently there's another issue that Gavin found in namecoin but I don't know what that is.
244 2013-11-24 00:59:01 <petertodd> midnightmagic: like recently found or years ago?
245 2013-11-24 00:59:06 <midnightmagic> recently.
246 2013-11-24 00:59:16 <midnightmagic> like few weeks ago.
247 2013-11-24 00:59:19 <petertodd> midnightmagic: well that codebase has a stack of bugs, probably mostly unfixed...
248 2013-11-24 00:59:33 <midnightmagic> yes, correct it does. :)
249 2013-11-24 00:59:41 <petertodd> midnightmagic: I don't know and would rather not know about security vulnerabilities so I can't comment much there
250 2013-11-24 01:00:04 <midnightmagic> and yet it lurches on! clumps of gravedirt falling from its corpse!
251 2013-11-24 01:00:05 <midnightmagic> ha ha haaa
252 2013-11-24 01:00:33 <petertodd> midnightmagic: ha, yeah, I told a guy almost a year ago that I expected namecoin to die off and he probably should sell most of his investment... so much for that
253 2013-11-24 01:00:56 <petertodd> midnightmagic: though he would have made more with his money in BTC :P
254 2013-11-24 01:01:06 <midnightmagic> true!
255 2013-11-24 01:01:23 <midnightmagic> 
ACTION stubbornly rides the zombie

256 2013-11-24 01:02:16 <petertodd> 
ACTION tries to imagine that as scene from a Western, rather than a foreign film...

257 2013-11-24 01:30:07 <darsie> hey
258 2013-11-24 01:31:14 <warren> jgarzik: gmaxwell: I guess jgarzik guessed this earlier... disablewallet is saving me 400MB+ RES on fedora with bitcoind.
259 2013-11-24 01:31:20 <warren> empty wallet
260 2013-11-24 01:32:41 <darsie> If a bad coin blacklist were implemented, could ppl send bad coins to taint the whole balance of other addresses/wallets? Or could the other wallets/adresses spend all but the bad gift?
261 2013-11-24 01:33:22 <darsie> I know, coins are not stored in adresses, but I don't know where else. They are stored in tx, maybe.
262 2013-11-24 01:34:24 <gmaxwell> warren: please qualifiy "gitian" when you say that.
263 2013-11-24 01:34:42 <warren> gmaxwell: not gitian this time
264 2013-11-24 01:34:50 <gmaxwell> warren: uhhhhhh wtf?
265 2013-11-24 01:35:03 <warren> goes from 750MB to like 420MB
266 2013-11-24 01:35:09 <gmaxwell> warren: my res on my bitcoind is 388396  are you using negative memory?
267 2013-11-24 01:35:24 <gmaxwell> and this is with     "connections" : 47,
268 2013-11-24 01:35:28 <gmaxwell> and a fairly large wallet.
269 2013-11-24 01:35:38 <warren> on fedora?
270 2013-11-24 01:35:40 <gmaxwell> 750 is very high.
271 2013-11-24 01:35:44 <gmaxwell> Fedora release 19 (Schrödinger’s Cat)
272 2013-11-24 01:35:55 <warren> is that master?
273 2013-11-24 01:36:02 <gmaxwell> warren: minus a week or so.
274 2013-11-24 01:36:08 <warren> this is my 0.8.5. + weird stuff branch
275 2013-11-24 01:36:24 <gmaxwell> I was also the same usage (under 400mbytes) on 0.8.5
276 2013-11-24 01:36:30 <warren> mmm
277 2013-11-24 01:44:54 <gulli> What exactly is the identifier here
278 2013-11-24 01:44:55 <gulli> https://en.bitcoin.it/wiki/BIP_0032_TestVectors
279 2013-11-24 01:47:38 <gmaxwell> gulli: an address generated off the master public key.
280 2013-11-24 01:48:13 <gulli> sorry, I ment the fpr
281 2013-11-24 01:48:17 <gulli> I know its the address :)
282 2013-11-24 01:48:29 <gulli> ive been trying to google fpr, not finding anything about it
283 2013-11-24 02:56:48 <jgarzik> oh brother
284 2013-11-24 02:56:52 <jgarzik> http://bits.blogs.nytimes.com/2013/11/23/study-suggests-link-between-dread-pirate-roberts-and-satoshi-nakamoto/?_r=1&
285 2013-11-24 02:57:36 <Diablo-D3> well duh
286 2013-11-24 02:57:46 <Diablo-D3> one invented bitcoin, the other made a bunch of money with it
287 2013-11-24 02:58:02 <Diablo-D3> obvious link is obious
288 2013-11-24 02:59:04 <warren> I doubt satoshi nakamoto woudl have posted using his real name on any bitcoin forum
289 2013-11-24 03:00:16 <warren> "Earlier this year, the researchers obtained a complete listing of all bitcoin transactions"  wow, experts.
290 2013-11-24 03:00:45 <SomeoneWeird> warren, lmao exactly what i thought
291 2013-11-24 03:01:30 <Diablo-D3> warren: yeah
292 2013-11-24 03:01:33 <Diablo-D3> thats hilarious
293 2013-11-24 03:06:09 <jgarzik> warren, amusingly, they did it by web-crawling a block explorer website
294 2013-11-24 03:06:27 <jgarzik> rather than, you know, downloading and reading the public blockchain itself
295 2013-11-24 03:09:36 <shesek> you gotta be kidding me
296 2013-11-24 03:10:07 <shesek> they wrote a crawler to scrape that information from a website, when they can already, much more easily, get it in a machine-readable format?
297 2013-11-24 03:10:32 <shesek> that's just idiotic
298 2013-11-24 03:13:47 <Polyatomic> Can someone help me understand why transaction fees included in a block reward also need 120 confirmations to mature
299 2013-11-24 03:14:23 <lianj> 100
300 2013-11-24 03:16:30 <K1773R> 101 :P
301 2013-11-24 03:19:48 <lianj> K1773R: really? don't think so
302 2013-11-24 03:20:13 <K1773R> its spendable after 101 confirmations
303 2013-11-24 03:20:22 <K1773R> AFAIK
304 2013-11-24 03:20:34 <lianj> im pretty sure its after 100 and not below < 100
305 2013-11-24 03:22:19 <K1773R> why below 100? i said 101 not 99
306 2013-11-24 03:24:22 <cfields> anyone around who can approve me on bitcointalk? I've never posted there, and would like to respond to someone
307 2013-11-24 03:25:14 <K1773R> lianj: nvm, your right. the time you spend it and the tx will be confirmed is at least 101. sry about that ;)
308 2013-11-24 03:29:00 <lianj> K1773R: (nSpendHeight - coins.nHeight < COINBASE_MATURITY)
309 2013-11-24 03:30:38 <lianj> if its in the 100th block after its created/coinbase block then its valid
310 2013-11-24 03:44:12 <gmaxwell> cfields: I whitelisted you.
311 2013-11-24 03:44:21 <cfields> gmaxwell: thanks
312 2013-11-24 03:45:52 <gmaxwell> lianj: the rule and the wallet-client behavior are not quite the same, it's not a great idea to spend right at the limit because your transaction may not propagate well.
313 2013-11-24 03:46:21 <gmaxwell> lianj: in all release versions of bitcoin-qt the wallet wouldn't spend until 120.  In git I've reduced that to 101.
314 2013-11-24 03:47:21 <gmaxwell> jgarzik: we'll we've ruined their future research, blockexplorer is gone.
315 2013-11-24 03:48:23 <warren> gone?
316 2013-11-24 03:49:33 <gmaxwell> poof gone
317 2013-11-24 03:49:54 <lianj> gmaxwell: woa, thanks for that info, didn't now. weird also
318 2013-11-24 03:50:17 <lianj> also why does wallet spend relate to not relayed well?
319 2013-11-24 03:51:05 <gmaxwell> lianj: e.g. if you hit 100 but your peers are mostly at 99 and you spent at that point your peers will drop your txn on the floor.
320 2013-11-24 03:51:18 <lianj> oh right
321 2013-11-24 03:51:19 <gmaxwell> and then it won't make progress until you retransmit it later.
322 2013-11-24 03:51:20 <lianj> makes sense then
323 2013-11-24 03:51:29 <gmaxwell> yea, 20 was a bit crazy though.
324 2013-11-24 03:51:45 <lianj> ok so 105-ish should do. 101 even
325 2013-11-24 03:52:00 <lianj> thanks, will change that in my coin selection
326 2013-11-24 03:52:33 <gmaxwell> 1 might still be a bit too early, but I thought it was a reasonable tradeoff for a personal wallet considering that the only cost is that you'll get delayed until the next rebrodcast. For a shared wallet with many coins to choose from higher is probably better.
327 2013-11-24 03:53:18 <gmaxwell> I ran my namecoin daemon for a long time at 100 and got a few stupid delays, moved it to 101 and think I only noticed it get delayed once.
328 2013-11-24 03:58:39 <n0n0> hi! I just asked the following to #bitcoin and have been advised to go to this channel:  so i was asking a couple days ago about this 7 txn/s limit issue. I am trying to inform myself and am now looking for information what the status of the software is wrt. sending only partial/compressed blocks out when solving them, to decrease the orphan cost and thus its impact on the transaction fees. Has such functionality already been implemented?
329 2013-11-24 03:59:17 <lianj> gmaxwell: will change it to 105 so everyone can bitch about that number
330 2013-11-24 03:59:19 <lianj> :9
331 2013-11-24 03:59:32 <gmaxwell> lianj: hah. Sounds like a fine number to me. you have my approval. :P
332 2013-11-24 04:00:16 <gmaxwell> n0n0: there are a number of threads on the bitcointalk forum. If you'd like to expirement with sending only partial/compressed blocks out it would probably be best done as a parallel protocol at first.
333 2013-11-24 04:00:54 <gmaxwell> n0n0: afaik the only implementation of sending compacted blocks out there is p2pool's.
334 2013-11-24 04:03:25 <gulli> I think nobody answered the question though, why wait so long until you can spend transaction fees from a block?
335 2013-11-24 04:03:43 <n0n0> gmaxwell, ah thank you. i was reading a bit about the details on the minimum transaction fees, and I hope I got it right. I read that the idea is to eventually replace the full transactions with just parts of the transaction hashes when saying 'I got a new block'. I saw that this would increase the transmission of new blocks by 'about a factor of ten easily'. But is that the optimum solution? Can't there be a way to compress this even further or, for exa
336 2013-11-24 04:03:43 <n0n0> mple, for a pool/miner to advertise to its peers: hey, I am going to put these transactions into a block?
337 2013-11-24 04:04:38 <n0n0> what do you mean by a parallel protocol? something that is 'out-of-band' wrt. the main bitcoin protocol?
338 2013-11-24 04:05:05 <gmaxwell> n0n0: well once you get down to the point where the whole message fits into a single IP packet there is likely not much latency impact anymore, your transmission time starts becoming dominated by propagation.
339 2013-11-24 04:05:08 <n0n0> s/increase the transmission/decrease the transmission time/
340 2013-11-24 04:05:54 <n0n0> true, but assuming that the blocksize gets lifted soon, won't there be thousands of txn in a block (I mean, there are hundreds already, right?) How does that fit into a single udp packet?
341 2013-11-24 04:05:57 <gmaxwell> n0n0: there is no reason that blocks need to be relayed over any particular protocol. ... they could be sent via carrier pidgeon or what have you. :)
342 2013-11-24 04:05:59 <n0n0> (or TCP)
343 2013-11-24 04:06:34 <n0n0> i see. but that's one of the scaling issues right now, correct? that the finished/validated block is taking so long to propagate and risks being orphaned? or did I miss something?
344 2013-11-24 04:08:22 <gmaxwell> Sure, its something that should be improved. We don't currently have good measurements of the propagation though, the best thing we have are numbers that were taken before 0.8 (and the caching just before it) made block validation tens of times faster.
345 2013-11-24 04:09:02 <gmaxwell> And currently the largest source of latency is _probably_ the fact that the message processing loop in the reference software has a 100ms sleep in it.
346 2013-11-24 04:10:00 <gmaxwell> n0n0: if you start talking about a hard fork to the network to increase the maximum permitted blocksize increased orphaning is the least of the concerns there— after all, you could still actually produce smaller blocks if the limit were higher.
347 2013-11-24 04:10:11 <n0n0> ok. but when I researched the blocksize issue, I stumbled upon the whole argument what the minimum fee can realistically be, wether the blocksize needs to be enforced somehow. From that I gathered, that basically there is this 'natural' limit of the block propagating widely into the network quickly enough which basically makes sure that miningpools limit the amount of txn that they take in
348 2013-11-24 04:10:36 <n0n0> gmaxwell, yes i thought this was going to happen soon?
349 2013-11-24 04:11:24 <gmaxwell> n0n0: No. There has been no public movement towards changing it in the soon— e.g. we don't even know if the software will work correctly without fixes, as no one has even tested it as far as I know, unless you mean soon on the timeframe of years.
350 2013-11-24 04:12:51 <gmaxwell> And considering that the number of nodes has been falling precipitously for months I don't see how we could hope survive as a decenteralized system if we dramatically increase the network's operating cost without first improving the node behavior to make it not undesirable to run a node at the current operating cost.
351 2013-11-24 04:13:40 <n0n0> i see. i thought that eventually this was going to happen, though? like scaling up to higher rates?
352 2013-11-24 04:14:03 <gmaxwell> n0n0: presumably, though the march of technology makes doing that easier over time.
353 2013-11-24 04:15:07 <gmaxwell> n0n0: it's a bit tricky, both in keeping it viable enough for many parties to run nodes, and because the argument for the long term viability of bitcoin depends on there being a fee market to create transaction fees which are able to replace the subsidy and pay to secure the network.
354 2013-11-24 04:16:14 <n0n0> i see. what is considered many nodes? like just firing it up on your laptop, or rather quite dedicated people?
355 2013-11-24 04:16:54 <n0n0> right now i can pay for my lunch directly on the blockchain and I read that the plan is to not do microtransactions on the chain. will those things be considered mictrotransactions?
356 2013-11-24 04:18:26 <joecool> anyone in here screw with bip32 yubikey neo applet?
357 2013-11-24 04:18:44 <gmaxwell> n0n0: I don't think anyone knows magically what number is enough. Certantly if there are only a few hundred nodes it would be very easy to shutdown bitcoin or impose violations of the system's promises. My hope is that participation would remain inexpensive enough (relative to current technology of the time) that many people could do it casually, without worrying how they'll get paid back for their costs.
358 2013-11-24 04:18:59 <gmaxwell> joecool: hadn't heard of it, I knew neo was supposted to be more powerful…
359 2013-11-24 04:19:38 <joecool> gmaxwell: it's a javacard implementation, it does have a openpgp smartcard implementation on it too but the keysize is limited to 2048 (got uploading working there though)
360 2013-11-24 04:20:03 <gmaxwell> n0n0: One point is that the blockchain is the upper limit on how decenteralized anything can be in the bitcoin ecosystem. You can build things with different scale tradeoffs on top of it, but nothing built on top of it can be more decenteralized than bitcoin itself.
361 2013-11-24 04:20:03 <joecool> OATH via NFC is pretty cool too for authenticator stuff (use it on localbitcoin, etc)
362 2013-11-24 04:20:26 <gmaxwell> joecool: but there is a BIP32 signer implemented for it now?
363 2013-11-24 04:20:26 <joecool> gmaxwell: but i hadn't seen anyone mess with the bip32 wallet on it
364 2013-11-24 04:20:30 <joecool> yeah there is
365 2013-11-24 04:20:36 <n0n0> i see.
366 2013-11-24 04:20:39 <gmaxwell> Guess I'll have to go buy one now.
367 2013-11-24 04:21:11 <joecool> i forget the tool that was announced not too long ago (another bip32 device) with screen on it
368 2013-11-24 04:21:18 <joecool> this is cheaper, can do this + rpi
369 2013-11-24 04:21:19 <n0n0> is the main worry the diskspace for archiving the blockchain when scaling up? what is considered the biggest risk in terms of increase in cost when scaling up?
370 2013-11-24 04:21:32 <joecool> if you want a portable signer
371 2013-11-24 04:21:44 <gmaxwell> n0n0: so I think the question there has to do with how fast bitcoin usage grows vs how technology improves. Of course if bitcoin becomes a world currency in a serious way then many more people will be willing to undertake some costs to keep it secure.
372 2013-11-24 04:22:36 <gmaxwell> n0n0: disk space isn't a big concern, since you can just have nodes storing a fraction of the old history: to validate blocks they only need fast access to a trusted table of unspent outputs... right now thats only about 256mbytes.
373 2013-11-24 04:23:42 <gmaxwell> n0n0: bigger concerns are bandwidth requirements, at least today. Also CPU speed for signature validation is potentially an issue, though we can now do 40k signature validations per second on a fast desktop multicore cpu using some code that isn't yet part of the reference client.
374 2013-11-24 04:23:50 <n0n0> if the blocksize changes, that would not necessarily mean a change in the centralisation of the mining power though, right? because miners do not need the whole chain to do their job
375 2013-11-24 04:24:47 <n0n0> so even if there are just a couple hundred 'full' nodes worldwide, they would still need the dispersed power of the miners, right? so aren't there basically different ways that bitcoin is decentralized?
376 2013-11-24 04:25:11 <gmaxwell> n0n0: dumb hashers, devices that validate nothing and just work on stuff they're given, don't really contribute to decenteralization.  But mining is pretty orthogonal, every node validates: and thats what prevents miners from having an obvious common incentive to not start writing themselves blank checks
377 2013-11-24 04:26:01 <n0n0> well, but the dumb hashers are needed in the transaction validating game. so if they vote with their feet, don't they have sufficient power to keep it decentralized?
378 2013-11-24 04:26:04 <gmaxwell> Mining just serves the purpose of giving a consensus ordering of transactions, correctness with the rules is validated autonomously by full nodes.
379 2013-11-24 04:26:51 <gmaxwell> n0n0: so far that doesn't appear to be the case. (e.g. ghash.io appears to have been using their 20% hashpower to rob some gambling site, and it seems to have had no real effect on behavior)
380 2013-11-24 04:27:18 <gmaxwell> Of course, voting with your feet doesn't much matter if the control loop is super slow.
381 2013-11-24 04:27:33 <n0n0> i see. if they would be aware though, they would choose their pools more wisely, right?
382 2013-11-24 04:28:55 <n0n0> so, just to see whether i get this right: the risk you are talking about is basically the so-called fully validated nodes saying: 'sure, sure, everything is right', while messing big time with the transaction history?
383 2013-11-24 04:28:58 <gmaxwell> I don't think they care— e.g. a service where you got paid >100% expectation run by a notorious ponzi operator was super popular—  but it's hard to say what aspects of behavior are short term anomalies.
384 2013-11-24 04:29:38 <gmaxwell> n0n0: well, in particular— permitting inflation.
385 2013-11-24 04:29:48 <n0n0> from satoshi's paper, it sounds like that is one of the main parts of the decentralisation and the feedback-loop - the power of the hashers