1 2015-02-15 00:40:10 <kanzure> what is this about libbitcoincompleteconsensus versus libbitcoinconsensus?
 2 2015-02-15 00:41:15 <gmaxwell> gibbberish what?
 3 2015-02-15 00:42:22 <gmaxwell> oh luke's comment? I don't know that I agree.
 4 2015-02-15 00:42:30 <kanzure> yes that comment
 5 2015-02-15 00:42:33 <gmaxwell> The distinction there is stateless vs stateful consensus.
 6 2015-02-15 00:42:33 <kanzure> ah
 7 2015-02-15 00:42:45 <kanzure> i have not thought about that one much. hmm.
 8 2015-02-15 00:43:04 <kanzure> i suppose the distinction might be interesting, but in practice i don't care how stuff is persisted as long as the format is correct.
 9 2015-02-15 00:43:17 <gmaxwell> If there is comitted state of some kind then the two basically become one and the same. (if storage fails the failure will eventually be cleanly detectable)
10 2015-02-15 00:43:26 <kanzure> or as long as various guarantees are kept by whatever implementation you pick
11 2015-02-15 00:44:27 <phantomcircuit> gmaxwell, how do you cleanly detect a storage failure without replaying?
12 2015-02-15 00:45:07 <gmaxwell> kanzure: they usually aren't, of course.  though I think there are basically two ways around it (other than also stuffing the storage into the consensus code): one is using a comitted state which basically means that no undetectable divergence can happen; the other is by using oblivious storage with per host randomization; so that any storage failure is non-systemic with high probablity.
13 2015-02-15 00:45:32 <kanzure> if storage code is stuffed into consensus code, then what does that actually look like?
14 2015-02-15 00:45:45 <kanzure> in practice you are not going to have ssd firmware in consensus code, right?
15 2015-02-15 00:46:15 <kanzure> oh you mean network-level storage. hrm.
16 2015-02-15 00:46:33 <gmaxwell> phantomcircuit: if your state is comitted then any corruption eventually results in a failed hash in a case where such a failure is impossible;   (oh and by commited I don't necessarily mean in the blockchain, there I mean 'comitted to in a small amount trusted storage which is assumed correct')
17 2015-02-15 00:46:39 <gmaxwell> no I don't mean network level storage.
18 2015-02-15 00:46:59 <kanzure> 
ACTION consults his philosophy book about storage

19 2015-02-15 00:47:42 <gmaxwell> If you have your state (the utxo set in the case of bitcoin) in a hash tree. And the consensus magic box keeps track of the root (perhaps its in the blockchain, perhaps not)... then there is no way the storage can 'fail' which is results in a false acceptance or rejection of a block.
20 2015-02-15 00:48:04 <gmaxwell> Because to do so the storage would have to present tree fragments which are consistent with the commited state.
21 2015-02-15 00:48:09 <phantomcircuit> gmaxwell, that's cheating but ok
22 2015-02-15 00:48:49 <gmaxwell> It's not cheating, it's completely pratical, it allows you a strong guarentee that no matter how screwed up your key value store is you'll never falsely accept or reject a block, at worst you'll detect that you're screwed and shut off.
23 2015-02-15 00:49:09 <gmaxwell> The only down side is that having authenticated state has overhead.
24 2015-02-15 00:49:18 <phantomcircuit> no i mean the assuming you have some reliable storage that isn't the kv storage
25 2015-02-15 00:50:30 <gmaxwell> phantomcircuit: well if it's in the blockchain then you don't have to have it. And if it's not; well it's only storing 32 bytes, and any corruption there will _also_ be detected, unless it's some kind of malicious adjustment to be consistent with the broken storage; in which case all bets are off.  The attack model here is faulty hardware/software.
26 2015-02-15 00:50:43 <phantomcircuit> i suspect building a kv store that provides much stronger guarantees than leveldb does for example would give you virtually identical results
27 2015-02-15 00:52:24 <gmaxwell> I'm quite confident that it's not possible to build such a thing without basically doing exactly the same. It is _insanely_ hard to write correct software. Leveldb is many many thousands of lines of code, and I'm quite sure that it's already not durable even absent flaky hardware. Mix in flaky hardware, and I doubt anything short of all the data being hashed is sufficient to have zero undetectable fa
28 2015-02-15 00:52:30 <gmaxwell> ilures.
29 2015-02-15 00:53:22 <gmaxwell> Keep in mind this is a discussion which is not about "don't be busted shit", it's about "be structurally impossible for a block to be falsely accepted or rejected due to storage corruption"
30 2015-02-15 00:53:47 <kanzure> yeah i had the wrong scope in mind
31 2015-02-15 00:55:02 <gmaxwell> kanzure: the other path I mentioned, ... w/ oblivious storage would be to use the storage in such a way that you could have strong confidence that even if the storage has a common design flaw no two systems will fault the same. Basically by having the consensus black box hide its data and access patterns from the storage. ... but the overhead for this is somewhat higher than a comitted utxo set, sooo
32 2015-02-15 00:55:08 <gmaxwell> .
33 2015-02-15 00:55:11 <phantomcircuit> gmaxwell, i guess this is relatively easy to get right but the issue im seeing with something like that is a valid but older than we think it is hash
34 2015-02-15 00:56:40 <gmaxwell> Hm?,  storage_root = H(disk_data_root || block_hash)
35 2015-02-15 00:57:28 <gmaxwell> then when a new block comes in, a non-consensus disk manager looks up all the required utxo for the block and presents the proofs relative to the storage_root. Consensus code verifies them, and continues on.
36 2015-02-15 00:57:41 <phantomcircuit> gmaxwell, and then you have an ssd that miraculously reverts the disk data root and block hash AFTER you've run the check
37 2015-02-15 00:57:47 <phantomcircuit> it's unlikely but hardly impossible
38 2015-02-15 00:58:09 <phantomcircuit> either way this would be pretty clearly better than what exists today
39 2015-02-15 00:58:10 <phantomcircuit> :P
40 2015-02-15 00:58:13 <gmaxwell> if the block hash is reverted then youre just stuck on a particular block.
41 2015-02-15 00:58:17 <phantomcircuit> i will stop being ridiculous now
42 2015-02-15 00:58:23 <gmaxwell> (or not even stuck)
43 2015-02-15 01:07:08 <midnightmagic> 
ACTION is happy to discover that much of the island-of-truth-tellers-and-randoms logic puzzles stretching back into von neumann reliable circuits and lamport's non-generals reliable autonomous agents work is just as applicable as it has been for .. what is it now? 60 years or something?

44 2015-02-15 01:18:24 <kanzure> midnightmagic: feed me relevant papers
45 2015-02-15 01:19:07 <midnightmagic> kanzure: I can feed you cites. If you want actual fulltext from papers I can do that too much it's a lot of work to make them available.
46 2015-02-15 01:19:22 <kanzure> cites are also acceptable
47 2015-02-15 01:19:29 <midnightmagic> 1. Blecher PM. On a logical problem. Discrete Mathematics. 1983;43(1):107-110. doi:10.1016/0012-365X(83)90026-2.
48 2015-02-15 01:20:10 <midnightmagic> start there. it's verrrry difficult to find without someone pointing directly at it, but the result is really pretty stupendous in its simplicity.
49 2015-02-15 01:21:48 <midnightmagic> uh. there's a few of them. Maybe PM would be better.
50 2015-02-15 05:05:54 <leakypat> Ok I've been reading up, but still don't get it
51 2015-02-15 05:06:02 <leakypat> What is libconsensus?
52 2015-02-15 05:13:55 <evanxbt> leakypat: where have you been reading about it? I *thought* it was something along the lines of this: https://bitcointalk.org/index.php?topic=876020.msg9760326#msg9760326 .. but can't find anything to back that up
53 2015-02-15 05:14:26 <leakypat> On the dev mailing list
54 2015-02-15 05:14:37 <leakypat> Thanks I'll check it that post
55 2015-02-15 05:17:36 <justanotheruser> leakypat: it is a block evaluation library
56 2015-02-15 05:17:52 <justanotheruser> to my knowledge it only does scripts right now
57 2015-02-15 05:36:31 <alfacent> Hello, how many confirmations has https://blockchain.info/latestblock ?
58 2015-02-15 05:37:09 <alfacent> Some people say it has 1 confirmation and some people say it has 6 confirmations...
59 2015-02-15 05:42:04 <evanxbt> alfacent: that url was one behind, now it is showing the latest block
60 2015-02-15 05:42:39 <evanxbt> alfacent: did you mean to ask about a particular transaction?
61 2015-02-15 05:42:58 <alfacent> so, one confirmation?
62 2015-02-15 05:43:41 <alfacent> what do you mean when you say "was one behind" ?
63 2015-02-15 05:44:38 <evanxbt> there was a newer block mined that it wasn't showing yet
64 2015-02-15 05:46:19 <evanxbt> alfacent: I'm looking at https://blockchain.info/block-index/769534/03a58
65 2015-02-15 05:50:40 <Luke-Jr> alfacent: evanxbt: blockchain.info = bad idea; also off-topic here
66 2015-02-15 05:51:15 <evanxbt> Luke-Jr: you mean the API or in general?
67 2015-02-15 05:51:36 <Luke-Jr> evanxbt: everything about it
68 2015-02-15 05:51:40 <evanxbt> lol
69 2015-02-15 05:51:58 <Luke-Jr> it's so wrong, it's a stretch to even call it Bitcoin anymore
70 2015-02-15 05:52:14 <evanxbt> what web-based blockchain explorer do you recommend?
71 2015-02-15 05:54:03 <justanotheruser> evanxbt: this isn't development discussion and should be in #bitcoin
72 2015-02-15 13:49:44 <theorbtwo> General-purpose computers are astounding. They're so astounding that our society still struggles to come to grips with them, what they're for, how to accommodate them, and how to cope with them. This brings us back to something you might be sick of reading about: copyright.
73 2015-02-15 13:49:53 <theorbtwo> Gaaah, sorry, mispaste.
74 2015-02-15 20:15:40 <bliljerk101> How was bter attacked? Anyone know?
75 2015-02-15 20:28:04 <grim21>  /r/bitcoin thinks it was an inside job. but i've not seen anything else about it
76 2015-02-15 20:28:43 <rnicoll> They've said loss from cold store, which suggests they're misusing the term "cold store", screwed up key generation (wasn't random enough), or an inside job
77 2015-02-15 20:30:55 <b_lumenkraft> or a weak brainwallet perhaps?
78 2015-02-15 20:31:42 <sipa> #bitcoin please
79 2015-02-15 22:42:51 <earlz> where was the discussion for removing getwork in bitcoin 0.10?
80 2015-02-15 22:43:08 <earlz> I see an old issue from 2013 for removing it that got closed and rejected.. but nothing more recent
81 2015-02-15 22:44:48 <rnicoll> thought it was mostly within https://github.com/bitcoin/bitcoin/pull/4100 ?
82 2015-02-15 22:44:58 <rnicoll> s/thought/think/
83 2015-02-15 22:46:20 <rnicoll> Nope, actually http://sourceforge.net/p/bitcoin/mailman/message/31316041/ apologies
84 2015-02-15 22:47:12 <earlz> always forget about the mailing list