--- Log opened Fri Dec 20 00:00:12 2013 00:29 < Emcy> merge avoidance needs a nifty name 00:31 < Emcy> offramp? something that lets you demerge from a general serial stream of traffic...... 00:35 < Emcy> lol mergepurge. 00:36 <@gmaxwell> SPUI 00:37 < Emcy> wut 00:37 <@gmaxwell> google it 00:38 < Emcy> oh a spaghetti junction 00:38 < Emcy> i thought of that but didnt know what it was called 00:39 < Emcy> coinspui 00:39 < Emcy> coinspew? lol 00:42 < Emcy> i didnt know peter todd was involved with the darkwallet stuff 00:43 < Emcy> that best practices list seems reasonable so far 00:44 < BlueMatt> petertodd: btw, thought bloom filters can be expensive if you're looking at the whole chain, they certainly arent n^2... 00:46 < BlueMatt> (and though I agree other things are probably better than them, saying that wallets shouldn't rely on bloom filters now just introduces development overhead for something thats largely unnecessary currently) 01:06 < maaku> gmaxwell: whoops, correct extra should go after value 01:06 < maaku> that's why the branches come last - they are most likely to update 01:07 < maaku> so you could cache midstate, at least for the first few levels where it makes sense 01:09 < maaku> gmaxwell: varchar is length-prefixed, i should have defined that 03:08 < petertodd> BlueMatt: they're n^2 work summed over all users and all nodes is my point 03:08 < BlueMatt> no, they're not 03:08 < BlueMatt> as an spv client downloading blocks, you only download blocks from some subset of your peers 03:09 < petertodd> BlueMatt: ok, you have n users, they make 1 transaction each, that results in blocks with n transactions, for each user to scan a block via bloom filters is thus n work per block, or n^2 work total 03:09 < petertodd> BlueMatt: doesn't matter how you divide it up among your peers 03:10 < petertodd> BlueMatt: it's not so bad if they're scanning a new block, because that's just memory IO bandwidth, but what's particularly bad about the design is that we use it for archival history too, and thus get n^2 IO bandwidth load too 03:11 < petertodd> BlueMatt: compare to prefix-filters which is roughly n*log(n) total work 03:11 < petertodd> BlueMatt: (for n users) 03:11 < BlueMatt> your definition of n is...varying. Realistically you have n users, they each download each block from 1 peer, each peer spends O(|tx|) per client, so O(|txn|*|peers|) sure, but calling that n^2 isnt quite right... 03:11 < petertodd> Again, I'm talking about work done by the system as a whole. 03:12 < petertodd> Consider the most efficient case where there's exactly one Bitcoin supernode out there... 03:12 < BlueMatt> yea, Im not saying they're ideal 03:12 < BlueMatt> just that saying "nodes SHOULD NOT depend on bloom filters" seems very premature 03:13 < BlueMatt> (for non-archival nodes) 03:13 < petertodd> It's not really a "best practices that you should adopt right now", it's a "best practices that you *will* be adopting in the future as all the underlying tech gets developed" 03:13 < petertodd> e.g. practically everything it recommends doesn't exist yet 03:14 < petertodd> The whole point of the document is to guide development efforts so we make exist the most important stuff first; prefix-filters is in there because electrum already implements half of what's needed for them. 03:14 < BlueMatt> well if you're talking 10 years down the road a) dont think we can plan that far ahead, b) probably should say dont use bloom filters at all, not optional 03:15 < BlueMatt> really? nice 03:15 < BlueMatt> if youre talking entirely "down the road" you should probably say you cannot sync from the chain at all 03:15 < petertodd> I'm probably talking about 1 year down the road for everything in there depending on how much man-power proves to be available - note how nothing in there depends on soft-forks although takes the possibilities of them into account. 03:16 < petertodd> Right, which is why I also say that wallets shouldn't depend on the existance of UTXO-set prefix filters because TXO commitments looks to be the front-runner in that space right now. 10:52 < adam3us> petertodd: so how is TXO commitment better than UTXO-set prefix now? by TXO commitment you mean what? that the TXO is included in a merkle tree the root of which is mined; but a recipient needs to know the unspent state of that, which is what tries are being propose for (which i expect you mean with UTXO-set prefix) 13:37 < maaku> adam3us: TXO commitment, minus the U, is petertodd's scheme for building an append/modify-only list of transaction outputs and spend status from genesis block to present 13:38 < maaku> which has the not insignificant disadvantage that you can't lookup spend status by txid 13:39 < maaku> the onus is on the holder of the coins to keep and maintain an unspentness proof which they *must* prefix to the transaction broadcast to spend 13:40 < maaku> petertodd: elaboration on the evil things that either txid-indexed validation trie, or scriptPubKey-indexed wallet trie makes possible would be appreciated 13:41 <@gmaxwell> maaku: the onus isn't on the holder of the coin exactly. 13:42 <@gmaxwell> Rather it's not necessarily on any _more_ than the holder of the coin. 13:42 <@gmaxwell> maaku: or perhaps I should say "holder of the coin is sufficient" 13:43 <@gmaxwell> I don't think anyone (except maybe pt?) think that all holders would do that themselves, I think they'd go get the utxo from archive nodes that kept the data. 13:54 < phantomcircuit> hmm 13:54 < phantomcircuit> theoretically you shoudl be able to merge the bloomfilters for multiple peers 13:58 < maaku> gmaxwell: yes, which is why I don't really understand the objection. in either case you will be using an archival node (the use and maintenance of which can be paid for with explicit fees) 13:59 <@gmaxwell> maaku: because you're not forced to use an archival node, and every full verifiying node isn't forced to be one (in order to verify the utxo updates) 14:01 <@gmaxwell> in any case, I wouldn't have posted PT's no stop message. Though I do think that some of the more recent thinking has made straight utxo commitments less shiny. 14:01 <@gmaxwell> As far as I'm concerned the verdict is out until someone sits down and really figures out exactly what the overheads would be for the proofs in the model.. or. um.. maybe actually writes some code for it. 14:02 < maaku> "and every full verifiying node isn't forced to be one (in order to verify the utxo updates)" <-- this isn't required 14:02 < maaku> with updatable proofs 14:02 < petertodd> gmaxwell: remember that the archival nodes require much less data in my model - older data that's rarely needed can be dropped by everyone but a few specalized services 14:04 <@gmaxwell> maaku: Whats the prefix compression part of the spec fro then? 14:04 < petertodd> gmaxwell: whereas for utxo indexes that a new utxo can be inserted anywhere requires anyone who wants to keep up with the set and serve requests to store some fraction k of the whole set at best 14:06 < maaku> gmaxwell: to keep the serialization small, and level-compressed hashing variant is for other applications like document timestamping in the coinbase 14:06 < maaku> which don't require "rebasing" proofs 14:07 < petertodd> maaku: again, why does timestamping require anything more than a dumb tree? I mean, I've actually implemented this... 14:07 < maaku> petertodd: what type of tree? 14:07 < maaku> some applications require key uniqueness, which your tree structure has to provide compact proofs of 14:08 < petertodd> maaku: yes, timestamping is definitely not one of those. and strictly speaking, I only say tree for efficiency, opentimestamps handles arbitrary dags for a reason 14:08 < maaku> and the level-compression is a bonus for merged mining, where you don't want 128+ hashes to validate a pow 14:09 < petertodd> maaku: right, but direction-based proofs with randomized keys get you the exact same thing with far less complexity 14:10 < maaku> yuck. so what, every altchain picks a random value? or some central authority assigns them? 14:10 < maaku> that's the kind of thing the current merged mining code does that I want to avoid 14:11 < maaku> re: complexity, we're talking about a few dozen lines of code 14:11 < petertodd> heck, with per-block randomization like I suggested, every altchain could literally use their name and it'd work out fine 14:13 < maaku> to be clear, your path-based tree is the same underlying data structure as this 14:13 < maaku> i just have a fancier serialization 14:13 < maaku> (assuming you don't level compress, which I would suggest doing in this case) 14:15 < petertodd> yup, and with randomized keys there's no need to level compress 14:16 < petertodd> anyway, it'd help if I write up txo commitments properly for once :) 14:16 < petertodd> your BIP is a good model there 14:16 < maaku> yes, i was going to recommend that 14:17 < petertodd> I should raid unicode and draw up some nice looking mountain ranges with all the special characters! 14:17 < maaku> i'd like to reference TXO commitments in the followup BIP that discusses UTXO commitments 14:17 < petertodd> likewise 14:18 < petertodd> and I should also write up a description of how you'd do something like namecoin with utxo commitment indexes 14:19 < maaku> yeah i've got a whole solution for that worked out 14:19 < maaku> on the backburner though 14:19 < maaku> it's also stateless 14:19 < petertodd> you mean, solution to make namecoin work on the btc blockchain or block it? :P 14:19 < nsh> petertodd, i'd enjoy reading such a description 14:19 < maaku> oh maybe we mean different things 14:20 < nsh> or such a write-up, even 14:20 < petertodd> well, I was thinking "this is how you use UTXO commitments to make namecoin work, and/or make namecoin on the bitcoin blockchain because I'm evil" 14:20 < maaku> oh ok yes, I would like that to understand better your worry 14:21 < petertodd> yup, and it's actually rather relevant to my new dayjob too... utxo commitments could be quite handy for things like mastercoin data feeds 14:21 < maaku> so this is totally offtopic then, but my namecoin 2.0 in a nutshell: 14:21 < nsh> not enough essay titles end with the phrase "...because i'm evil" 14:22 < petertodd> nsh: lol 14:22 < maaku> add another coinbase committed prefix tree that persists from block to block 14:23 < maaku> and add soft-fork opcodes to insert/update into this tree, using pushdata proofs 14:24 < maaku> and signatures for updates (the first bytes of the value field being a length-prefix encoded scriptPubKey) 14:24 < petertodd> right, basically you're adding state to the scripting language 14:24 < nsh> (what could go wrong...) 14:25 < petertodd> what vitalik's ethereum thing should have focused on rather than getting into the nitty-gritty of the language IMO 14:26 < maaku> nsh: so you can have another way to double-spend a transaction, in a way that is observable to anyone who understands this soft-fork. what's the issue? 14:26 < petertodd> nsh: well, the key thing is to charge fees for every time the scripts run rather than allow them to run unhindered, on every block, multiplying and multiplying, consuming, EVERYTHING 14:26 * nsh nods 14:27 < petertodd> (though petri-coin is suddenly sounding *really* attractive...) 14:27 * nsh registers graygoocoin 14:27 < maaku> hehe, jtimon and I said basically the same thing to vtalik... 14:31 < petertodd> yeah, although that still assumes a model where you are outsourcing validation to miners - pure proof-of-publication schemes are IMO superior 14:31 < maaku> but anyway, that's part of why I find it a little hard to follow the UTXO namecoin objection ... there's a very easy pathway to namecoin-over-bitcoin which is stateless, scales better, and requires very little validation effort 14:31 < maaku> petertodd: you need consensus, no? 14:31 < petertodd> maaku: the only consensus you need is what data has been published and in what order 14:32 < petertodd> maaku: the objection is that things never expire out of the UTXO set, and to insert new items into it you need the whole damn thing 14:32 < maaku> ok, so you can do the same thing with the document-timestamper solution and not even need the soft-fork 14:32 < petertodd> maaku: maybe not you personally, but someone has to have it 14:33 < petertodd> maaku: actually no you can't - timestamping is only part of proof-of-publication 14:33 < maaku> and have people's view of the DNS database be eventually consistent 14:33 < maaku> petertodd: what's the other part? 14:33 < nsh> bunga bunga parties on the moon 14:33 < petertodd> well, the proof that your data actually got to people 14:34 < petertodd> IE, I can timestamp data that I have kept hidden all to myself 14:34 < nsh> well, proof-of-existence should be differentiates from proof-of-dissemination 14:34 < petertodd> only proof-of-publication can be used to solve the double-spend problem 14:34 < nsh> *differentiated 14:34 < maaku> yes, which is why I suggested soft-fork miner verification (although they throw away the data as soon as it is published) 14:34 < jrmithdobbs> ya, you need timestamps from observers and then the rabbit hole starts getting deeper and deeper 14:34 < petertodd> jrmithdobbs: no, not timestamps, proof-of-work/sacrifice 14:35 < maaku> really? why? 14:35 < maaku> if you have the data, you can broadcast it anytime at your convenience 14:35 < petertodd> right, which is the *problem* 14:36 < jrmithdobbs> petertodd: well, signed timestamps from observers is a (bad) form of proof-of-work 14:36 < jrmithdobbs> petertodd: ;p 14:36 < petertodd> for instance, you timestamp your transaction, but don't publish, you then make a subsequent transaction spending the same coins, and do publish, I only see the later timestamp, and then you can take the money from me later by publishing the earlier one 14:36 < maaku> you can't have your cake and eat it too ... you need a distributed consensus mechanism 14:36 < petertodd> jrmithdobbs: assume frictionless spherical cow timestamps 14:36 < maaku> do you have a solution to this? 14:36 < jrmithdobbs> petertodd: come again 14:37 < jrmithdobbs> maaku: noone has to my knowledge 14:37 < petertodd> jrmithdobbs: assume timestamps are free, infinity timestamps is still zero work 14:37 < petertodd> maaku: yes and no 14:37 < petertodd> the yes is that bitcoin is a proof-of-publication system, so obviously the problem can be solved. 14:38 < petertodd> the no is that if you want a scalable system, you still need some notion of "audience size" so to speak, and your security is better if you can prove the data was published to a larger audience 14:38 < jrmithdobbs> petertodd: the signatures on the timestamps aren't free though 14:40 < petertodd> jrmithdobbs: this is -wizards, we're mathematicians here :P 14:41 * nsh smiles 14:41 < maaku> Merkle-tree validation is pretty cheap though right? and the added size is paid for in fees 14:41 < jrmithdobbs> petertodd: my point was the timestamp isn't the proof, the multiple signatures from separate observers on "close" timestamps can serve as the proof of publication time 14:42 < petertodd> jrmithdobbs: only if I have some notion of observer - without proof-of-work every observer claimed has zero weight (sybil problem) 14:42 < jrmithdobbs> petertodd: you need a mechanism for defining what are enough and that's where it starts falling apart imho 14:42 < petertodd> jrmithdobbs: exactly, and proof-of-work is what fixes that mechanism 14:43 < petertodd> (I *really* need to write a book on this as fast as possible so I can cement as much terminology as possible from the fine art world into this field...) 14:43 < nsh> please do 14:44 < nsh> i am happy to contribute by poking you daily with an imaginary irc stick if that helps 14:44 < nsh> (was actually wondering what "weight" means here...) 14:45 < maaku> petertodd: that doesn't seem to address the issue very well 14:46 < petertodd> oh man, the crazy thing is semiotics terminology actually makes sense here too, sign, signified, signifier... 14:46 < maaku> so i burn some coins or electricity to get enough sybil identities to double-spend 14:46 < nsh> oh good, let's invite umberto eco to keynote the next bitcoin conference 14:46 < maaku> it puts an economic cost on it, but not one that can be too big 14:47 < petertodd> maaku: they're not sybil identities, the notion of identity is really kinda irrelevant at the theory level, what matters is a certain amount of electricity was destroyed in support of a particular history 14:47 < petertodd> nsh: lol 14:47 < maaku> maybe if I'm "selling" superpreciousname.bit it's worth while 14:48 < maaku> petertodd: you mean like mining proof-of-work? 14:48 < maaku> sorry to come back, but this is sounding like "let's reinvent bitcoin!" 14:51 < petertodd> maaku: not reinventing, expalining what it's really doing 14:52 < petertodd> maaku: first of all, do you see how if miners did no validation at all, bitcoin can still work just fine? 14:53 < maaku> no 14:53 < jrmithdobbs> can you clarify that? what do you mean by that 14:53 < maaku> not for my definition of fine at least 14:54 < jrmithdobbs> petertodd: you mean that even if they didn't verify the actual contents as part of the pow the verification would happen by being rejected by peeers on the network? or are you after something else? 14:55 < andytoshi> i think he means, the order of transactions would be set in stone by the POW 14:55 < petertodd> andytoshi: exactly 14:55 < andytoshi> and the ordering is the only thing that nodes can't agree on by themselves 14:56 < petertodd> andytoshi: and nothing else, dups, invalid, whatever would all be allowed 14:57 < andytoshi> it occurs to me that growing up is in some sense a POW, you can't sybil irl because humans take so long to spam 14:58 < petertodd> andytoshi: indeed 14:58 < petertodd> jrmithdobbs: well, wallet software would ignore the invalid transactions basically 14:59 < jrmithdobbs> petertodd: but it wouldn't "work just fine" in that case as the clients would have to do a lot more filtering and processing wouldn't they? you get the ordering from the pow but you don't know how much of it is valid, doesn't that open up real spam issues? 14:59 < petertodd> jrmithdobbs: after parsing through the entire blockchain 14:59 < petertodd> jrmithdobbs: oh sure, but other than bandwidth and storage the system *would* work just fine 14:59 < petertodd> jrmithdobbs: IE, miner validation is an *optimization*, it's not fundemental 15:00 < maaku> ok yes, i get that (i wouldn't say "just fine" either, but let's not argue sematics) 15:00 < petertodd> maaku: "just fine" to a mathematician :) 15:00 < jrmithdobbs> petertodd: i see your point but would like to point out that the basic mechanisms for all this have been around for several decades and the optimizations are what made it feasible ;p 15:01 < jrmithdobbs> damn you beat me to the academic joke ;p 15:01 < petertodd> jrmithdobbs: well no, proof-of-work consensus in any form *has not* been around for long 15:02 < jrmithdobbs> petertodd: but it's building blocks have been 15:03 < maaku> petertodd: requiring nodes to validate by processing the entire block chain themselves is not scalable. so how do you determine with certainty whether the inputs to a transaction are valid without processing the whole block chain? 15:03 < amiller> jrmithdobbs, no one thought of doing proof of work consensus, it's an out-of-the-blue idea 15:03 < amiller> not something that was waiting for optimizations to be around 15:04 < amiller> there's one counterexample where someone wrote about proof of work consensus, but they seemed just to think it would be irrelevant 15:05 < nsh> "64k hashes should be enough for anyone" 15:05 < maaku> well the idea of using a scarce resource for consensus is old 15:06 < maaku> the application of hashcash to make thermodynamic potential that scarce resource is new 15:06 < maaku> new and very novel 15:06 < petertodd> maaku: well, one way is to structure your proof-of-publication in such a way that you only need to scan part of the blockchain 15:06 < petertodd> maaku: which is what TXIN commitments does 15:07 < jrmithdobbs> petertodd: anyways, back to something you said earlier as an offhand comment ... assuming all ops were enabled i thought it was already feasible to store state in scripts? 15:08 < petertodd> jrmithdobbs: not at all, none of the ops can do anything related to state 15:09 < petertodd> maaku: more generally, any key-value consensus system that allows multiple *time ordered* values for one key lets you efficiently determine the validity of your coins by tracing them back to genesis 15:09 < maaku> petertodd: why is it objectionable to require miners to do a little bit of work to earn their coins, for communal benefit? 15:10 < helo> maaku: are you taking much from https://en.bitcoin.it/wiki/User:Gmaxwell/namecoin_that_sucks_less for your namecoin? 15:10 < maaku> petertodd: which is still very suboptimal from a user's perspective 15:11 < maaku> helo: i wasn't aware of that wiki page 15:12 < helo> it has some neat suggestions, but it may be in a different direction than you were headed 15:12 < petertodd> maaku: because you need to look at the system as a whole - having to store utxo data forever sucks 15:13 < maaku> helo: regarding storage of the names themselves, yes, it's a different direction. my system doesn't require validator storage at all, beyond the root hash 15:13 < maaku> but the name-hidden-with-hash idea is something I hadn't considered 15:13 < helo> i like the "If you haven't guessed a name, or someone hasn't told you about it— it's none of your business that it exists." 15:14 < helo> yep 15:14 < maaku> petertodd: in the absence of well-defined suckiness, I disagree 15:15 < maaku> the UTXO set *is* what we all care about 15:15 < maaku> having access to the whole UTXO set is not an intrinsically bad thing 15:16 < petertodd> maaku: but it's not! wallets don't even care about the UTXO set - they only need to care about their own UTXO's 15:17 < maaku> the bitcoin economy is not a collection of purely self-interested wallets 15:17 < maaku> people also care about macroeconomic issues like estimations of lost coins, potential inferences of wealth distribution, etc. 15:17 < maaku> which require the whole utxo set 15:18 < petertodd> right, and all those things can be maintained by people who need it, people who don't need that and just want to mine and/or run full nodes don't need that stuff 15:18 < maaku> the difference between your approach and mine is that I'm trying make full use of the structure and incentivise people to make it available 15:18 < maaku> whereas you seem to be doom-and-gloom predicting its enevitable demise 15:19 < helo> ensuring miners can't make rule changes requires a lot of non-mining nodes to be involved in deep validation 15:19 < maaku> petertodd: neither miners nor full nodes need the utxo set! 15:19 < maaku> that what updatable proofs are about 15:19 < petertodd> maaku: I know, but now to spend a coin you need the assistance of someone who does, where as with TXO commitments you do not 15:20 < petertodd> you just need blockchain data from now to when the txo was created 15:20 < petertodd> that's a significant savings 15:20 < maaku> yes, but don't pretend that TXO commitments don't have down sides 15:21 < petertodd> yes, but as I argue the fact that electrum implements transaction lookup, rather than UTXO lookup, is indicative of the fact that those downsides aren't actually all that important 15:22 < maaku> ... that's a total non-sequiter 15:23 < petertodd> how so? 15:23 < maaku> with TXO you are requiring access to the full block chain since the txo was created, vs a summary of that data 15:23 < jrmithdobbs> petertodd: oh wow, i missed the 10-20 minutes before hand to understand the context of that state comment, different than what i meant by state ... and this whole conversation makes much more sense (and is more evil) now that I have 15:25 < maaku> and i'm not sure offering electrum up is a model for how we should do things 15:25 < maaku> jrmithdobbs: transactions are responsive to state already (the UTXO state) 15:26 < maaku> the objection to having state in scripts is that a reorg could make the transaction invalid ... but that can already happen 15:27 < maaku> so long as the conditions for invalidation can be quantified and other unconfirmed transactions checked for that, the status quo remains 15:28 < petertodd> maaku: right, so I have a wallet, I'm m blocks behind, and I need to sync it to get the current balance. With UTXO commitments that's a O(log2(n)) lookup per scriptPubKey, with TXO commitments thats O(m*log2(n)) 15:28 < petertodd> OTOH, if I also want to get transactions too - which it seems that users like having - they're both the same 15:29 < petertodd> I argue that the common case is m is small - people sync their wallets reasonably frequently - so the additional overhead isn't a big deal and *is* worth it in the context of long-term viability of the system. 15:29 < maaku> petertodd: no, the UTXO record has the block height, which they can go to directly 15:32 < petertodd> maaku: ok, I'll grant you that: if you assume transactions involving the scriptPubKey's were all not spent then you don't need to scan, but if you want to see all possible tx's, including spends, you do need to scan 15:33 < petertodd> maaku: also with regard to my point about security, having the heigh *does not* change the single-confirm security that UTXO commitments give you 15:35 < maaku> why? 15:35 < maaku> you know when it was originally confirmed, to the extent that you can trust the index at all 15:38 < petertodd> maaku: how do you know transactions between that single *tx proof* and now do not exist? 15:39 < petertodd> you still only have a single confirm of evidence about the state of the UTXO set 15:39 < maaku> by watching the blocks go by ... same as TXO commitments 15:42 < petertodd> maaku: no, with txo commitments you naturally do that at startup is my point 15:42 < petertodd> maaku: anyway, the security aspect wasn't the main issue I had with UTXO 15:43 < petertodd> again, long-term scalability is really important; txo commitments pushes the costs of a UTXO to the right people 15:44 < maaku> petertodd: this is my disagreement. the right people are, imho, the miners 15:44 < maaku> they're being paid to provide a service. they should actually provide useful service 15:47 < petertodd> well I'd like them to wipe my ass while we're at it :P 15:47 < petertodd> anyway, the most important service they provide is decentralization, so optimize for that 15:47 < petertodd> you optimize for that by keeping costs low 15:47 < maaku> gmaxwell: it seems SHA-512 is faster on 64-bit CPUs? then it's a better choice, no argument there 15:48 < petertodd> and full-node decentralization matters too, so keep costs low for that too so you have verification that the miners are actually being honest 15:48 < nsh> (or by keeping costs from scaling sublinearly) 15:48 < nsh> (ideally) 15:48 < petertodd> nsh: ideally every node is a full node! 15:48 < petertodd> nsh: less than that is a compromise 15:48 < maaku> petertodd: i imagine a future where asic/fpga validators much these utxo proofs 15:49 * nsh nods - all is compromise 15:49 < petertodd> maaku: that's not particularly decentralized - that's custom hardware 15:49 < maaku> yes, but mass produced and widely distributed 15:49 < maaku> the asic rollout has shown that this aids decentralization, compared with general-purpose computing solutions 15:49 < petertodd> that's a bunch of handwaving frankly 15:50 < nsh> i think without dual-use you get specialization, which is kin to, if not a species of, centralization 15:50 < petertodd> no, asics are a decentralization disaster: control of bitcoin is held by well under a half-dozen companies 15:50 < petertodd> the last thing we need is more of that 15:51 < maaku> petertodd: control is held by the people who own the asics 15:51 < maaku> that's more than a half-dozen companies 15:51 < maaku> and it's way better than when I first got involved with bitcoin and it was 2-3 botnets that controlled bitcoin 15:51 < petertodd> anyway, asics can't fix the problem that to start a new node requires getting the UTXO set from someone else, and the size of that data may be huge 15:53 < petertodd> maaku: the number of companies with competitive chip fabs is about three 15:53 < petertodd> maaku: sub-contractors don't count 15:54 < petertodd> maaku: er, I mean companies that contract those designs to those fabs 15:55 < petertodd> We're probably stuck with ASICs for the PoW, but there's no reason to think involving more of them is a good thing, especially since if Bitcoin fails because of chip-fab-related centralization it'd be much preferable to take the same technology and replace the PoW with a more asic hard one. 16:24 < helo> is botnet-related centralization better or worse than chip-fab-related? 16:24 < helo> not a false dichotomy afaict 16:37 <@gmaxwell> maaku: {cite} Bitcoin was never controlled by botnets, — having seen detailed logs from large pools there certantly were large botnets, but gpu powered bots were largerly a later revelation. 16:37 < petertodd> helo: agreed, they *do* have tradeoffs with regard to pow. However I would argue that for full-nodes "botnet-centralization" isn't a risk, so avoiding asics makes a lot of sense. 16:37 <@gmaxwell> maaku: but I'll grant you that if bitcoin had been asic (/gpu) resistant then it would have been mostly botnets. 16:38 < petertodd> helo: anyway, it's rather hypothetical: bandwidth kills you way before you need asics to process the blockchain... 16:38 <@gmaxwell> petertodd: I don't believe you can avoid asics. 16:38 <@gmaxwell> petertodd: at best you could lower then to some small factor advantage, but the competativeness of mining means that eventually that small factor will be enough that only the specialized hardware survived. I thought you agreed about this? 16:38 < petertodd> gmaxwell: sure you can, like I've said before making asics a small integer multiple more efficient rather than hundreds of thousands of times is a huge win 16:38 <@gmaxwell> I don't think it's a win. 16:39 < petertodd> gmaxwell: well, I agreed with the first half, the second half I don't: if censorship becomes prevalant, it's ok if blacklisted transactions cost some small multiple more to get mined 16:39 <@gmaxwell> e.g. if the asics are 10x advantaged then asics farms in the lower 50-tile worldwide power can put everyone else completely out of profitablity. 16:40 <@gmaxwell> okay, maybe there is something there.... but censored miners have an uphill battle, e.g. like having to hide their operations. 16:40 < petertodd> sure, but a hill is far more likely to be surmounted than a cliff 16:52 < jtimon> asics cannot by avoided by definition, by asics I mean specialized hardware 16:53 < maaku> jtimon: yeah, but the petertodd's goal i think would be to have a pow whose specialized hardware is the everyman's computer 16:54 < jtimon> you could design an algorithm targeted for certain architecture, that's all 16:54 < maaku> e.g., memory-hard and requiring complex computational capability, which would make something like the AMD APU the best system to use 16:55 < petertodd> well, absolute lowest cost will likely be custom hardware, but if it's a matter of custom PCB's and maybe some FPGA's linking it together, you've made a cottage industry that's fairly decentralized vs. ASICs which are hard-centralized. 16:56 < petertodd> and if off-the-shelf PCs aren't *too* large of a difference, people may still very well mine with them for reasons like "because I can" and "hey, free heat!" 16:56 < maaku> petertodd: ASICs will always win out, by double-digit factors I would wager 16:56 < jtimon> to matcht the "majority's architecture" you would need to both 1) predict the futterre 2) cause it, by imposing a favourite arch 16:57 < petertodd> maaku: well, I'm arguing single-digit factors, so we're in agreement roughly :P 16:57 < jtimon> no, maybe not both, sorry I'm... 16:57 <@gmaxwell> good luck powering a common cpu with just a 2 layer pcb. 16:57 < petertodd> jtimon: target RAM and you're within ballpark - heck, litecoin's PoW seems to have decent FPGA performance 16:58 < helo> how would the security-via-difficulty achieved with a novel proof of work and the expected value of nc2 block rewards + fees compare with capitulating to bitcoin merge-mining? 16:58 < petertodd> gmaxwell: 8 and even 16 layer PCB production is pretty decentralized, easilly two orders of magnitude more decentralized than ASIC production 16:58 < maaku> nc2? 16:58 < helo> (namecoin2) 16:58 < jtimon> the main problem is what is the target 16:58 <@gmaxwell> petertodd: okay, I'll grant that. 16:59 * nsh wonders what the unit of decentralization is 16:59 < helo> cost to attack? 17:00 < petertodd> nsh: person dollars? 17:03 < nsh> mmm, maybe 17:03 < jtimon> maaku if petertodd wants to impose a low level architecture that's more philosophical than techincal, what is the "layman arch" of the next year? 17:05 < petertodd> re: ASICs vs FPGA's, this paper suggests numbers ranging from mid double-digits to even low single digits: https://dl.acm.org/citation.cfm?id=1117205 17:05 < jtimon> I think we all overestimate pow 17:05 < jtimon> the rules are the chanel 17:06 < petertodd> suggesting a mem-hard PoW is likely to be FPGA implementable without *that* large of a gap 17:06 < maaku> jtimon: I was being devil's advocate :) 17:06 < maaku> you know I'm diehard pro-ASIC 17:07 < jtimon> what's more important 17:07 < petertodd> FPGA development isn't as decentralized as off-the-shelf PC, but it's still a lot better than ASICs 17:07 < jtimon> we shouldn't be targeting archs 17:07 < maaku> petertodd: i don't know, i think you're likely to get custom, non-von-neuman memory architectures for that 17:07 < maaku> i think people who analyze these things are thinking too much in the box 17:07 < petertodd> jtimon: memory vs FPGA vs ASIC are arch classes; they're fundemental 17:08 < petertodd> maaku: that's the point of FPGA's: you can cheaply make all kinds of crazy non-von-neuman memory architectures 17:08 < jtimon> we should be targeting problems that are common goods and not confilictive with the incentive structure 17:08 < petertodd> jtimon: huh? 17:09 < jtimon> gmaxwell knows how it could go all wrong if we target something "too useful" as pow 17:10 < jtimon> seriously, targetting archs is wrong, even html5 js could be implementedlow level in a way you don't expect now 17:11 < petertodd> jtimon: that's completely unrelated to what I'm talking about... with the one exception that the more competitive the pow is on off-the-shelf hardware, the easier it is to use for things like anti-sybil 17:12 < petertodd> jtimon: again, I'm not arguing for targetting architectures. 17:12 < jtimon> what do ou mean by competitive"? 17:12 < jtimon> what resources are we measuring? 17:13 < jtimon> what are we optimizing for? 17:14 < petertodd> jtimon: I want cost per hash for high-capital-cost ASIC implementations to be as close as possible to cost-per-hash on hardware that is less custom, off-the-shelf pc's are the extreme of less custom, gpu's slightly less so, standard fpga dev kits less, fpga's on custom PCB's even less, etc. 17:14 < petertodd> you pull off that trick by targetting PoW that makes use of RAM as much as possible, because RAM is fairly generic. *how* you target ram is tricky though 17:14 < jtimon> I first of all 17:15 < maaku> petertodd: or you make efficient asics into the commodity, off-the-shelf category 17:16 < jtimon> we willl all code parallel without noticing in the near future thanks to some fancy lib beter than cuda, so please don't anti-gpu 17:16 < petertodd> maaku: and you never will because of the nature of ASIC manufacturing. it may be "commodity", but the world economy appears to be unable to support more than maybe three or four top-of-the-line ASIC manfacturers, and they have a huge advantage over their lesser competitors 17:16 < MoALTz> petertodd: you want to support general computation? 17:16 < jtimon> but everybody has gpus or could have 17:17 < jtimon> I don't but I rented ne for villages gours 17:17 < jtimon> hours 17:17 < jtimon> one 17:17 < maaku> petertodd: so? monopoly/duopoloy on manufacture of asics is not the same as controlling the hashpower itself 17:19 < petertodd> maaku: it's very close to it, those companies can put restrictions of hashing power they produce overnight, for instance they can only sell it to authorized and licensed miners, or build backdoors into the hardware itself 17:20 < jtimon> wait, wait, how are monopoly miners changing the rues again? 17:20 < maaku> to the first that's why we have incentive structures that reward them for widespread distribution (which thankfully the freemarket provided and we didn't have to setup) 17:20 < maaku> the second is a hollywood threat 17:20 < petertodd> maaku: vs. to control FPGA's, let alone generic CPU's, they're forced to put restrictions on a huge industry - that's much harder politically. Not impossible, but much harder. 17:20 < petertodd> maaku: incentives mean nothing to a government that decides Bitcoin needs to be regulated 17:21 < jtimon> I didn't heard that part, maybe I don't get the solutions because I don't undesrtand the problem 17:21 < petertodd> jtimon: by 51% attacking us until we accept their new rules 17:21 < jtimon> why would we accept their new rules 17:21 < petertodd> jtimon: because if we don't we don't have a currency anyway 17:21 < helo> so with asic/memory-hard pow, there would likely be a varying mining script ('header, sha256, sha256' with bitcoin)? 17:22 < maaku> petertodd: and that's the one scenario where we'd realistically switch to scrypt or something else 17:22 < jtimon> chanell 1: morgan and rothchilds 22565554 petachashes 17:22 < jtimon> chanel 2: the rest of the world 100 moderatohashes 17:22 < petertodd> maaku: ah! you mean you'd be glad people like me had researched the problem and had solutions ready. 17:22 < maaku> it's nonsense hollywood threat. no government is going to spend 100's of millions of dollars to construct such an eleaborate scheme with so many moving parts 17:22 < maaku> when it can be so easily undone 17:22 < maaku> (i worked for the government I know ;) 17:23 < maaku> petertodd: ok, I shouldn't have said scrypt - SHA-3 would be more my tastes 17:23 < jtimon> that's the best part of bitcoin: you cant's change the rules unless theres consensus BY THE USERS 17:23 < petertodd> maaku: they don't have too, they tell intel/globalfoundries and tsmc to include cheap lockout circuit in every ASIC they produce so they have a bitcoin kill switch 17:24 < petertodd> jtimon: nope, without mining the rules aren't very useful 17:24 < maaku> petertodd: which you can see with an electron scanning microscope 17:24 < maaku> you want to be useful, organize an effort to image asic chips 17:24 < petertodd> maaku: so what? you have no choice but to buy ASICs that have it if you want performance that doesn't suck 17:24 < jtimon> that's true 17:24 < petertodd> maaku: it'd be done 100% publicly 17:25 < jtimon> butthey can only paralize the network, never change the rules 17:25 < petertodd> maaku: you may work for government, but I work in a field where I have to have a itar security clearance - I know how hard it is to buy custom equipment that the governmetn has decided shall be regulated 17:26 < maaku> it's a lot easier to buy that equipment in china. or singapore. or south africa 17:26 < petertodd> maaku: no it's not, the manufacturing capacity simply doesn't exist for a lot of this stuff. As I say, only a tiny number of companies in the world can make top-of-the-line ASICs. 17:27 < petertodd> maaku: in fact, only a tiny number can make even low-performance digitial ASICs... 17:27 < petertodd> fab plants are fucking expensive 17:29 <@gmaxwell> maaku: WRT sha512 speed, the compression function is slower, but it handles twice the data, and it's not twice slower. 17:30 < jtimon> will anybody be prohibited from building another asic when asic's yield is 0% and is clearly stupid to build another one? 17:30 < petertodd> jtimon: huh? 17:30 < jtimon> who's going to be the champion who thinks that can control the users by controllling the pow? 17:31 < petertodd> jtimon: still huh? 17:31 < jtimon> the hashing alg is somthing you can change whenever you want 17:31 < petertodd> in a hard-fork yes 17:32 < petertodd> which is why I'm *not* suggesting bitcoin change the pow right now, I'm suggesting that asic-hard pow's be researched so we'll have them ready if we need them 17:32 < petertodd> after all, governments may very well play nice and we'll be just fine, great! 17:32 < jtimon> if users are screwed up and just need a hard-fork to be where they were, they wll download the next version 17:32 <@gmaxwell> I did make a Modest Proposal to LTC to change their POW. When people started attacking my character I departed the thread, I dunno how that discussion has gone since. 17:32 < petertodd> and they're more likely to play nice if they know the community has alternatives 17:33 < petertodd> gmaxwell: try again when LTC is 51% attacked by an ASIC vendor :P 17:33 < jtimon> of course you would need "social consensus" whatever that is 17:34 < jtimon> probably not something to look for in a cuLTC 17:34 < jtimon> sorry 17:35 < maaku> helo: btw, one system we (jtimon and I) came up with for the namecoin 2.0 system is squatting resistance by having a market-set cost assocated with the domain 17:35 < jtimon> that's pretty economic actually 17:36 < maaku> heh, i hadn't seen cuLTC 17:36 < jtimon> sorry again 17:37 * petertodd didn't realize he wasn't the only Canadian in the room 17:37 * maaku is a canadian whenever he travels 17:37 <@gmaxwell> midnightmagic: is here 17:42 < jtimon> hey wizards, if it had an application, how would you define the pow ADDition operation? 17:42 < jtimon> like if tx could have pow fees or something 17:46 < nsh> i would define it constructively if possible, otherwise existentially 17:46 < petertodd> jtimon: just add the work together is one way 17:46 < petertodd> anyway, bbl 17:49 < maaku> jtimon: not sure what you mean 17:50 < helo> maaku: you create a limited supply of domains that can be created in each block so fees compete? 17:50 < maaku> helo: no, domains are unlimited in supply 17:51 < maaku> but domains are not a fungible commodity 17:51 < helo> how do you create a market of price competition without scarcity? 17:52 < maaku> helo: there is scarcity. domains are like land 17:52 < maaku> only one person/scriptPubKey can own google.bit 17:53 < maaku> so you have a mechanism for registering committed bids to buy domains from the current owner 17:53 < jtimon> maaku I've been thinking lately about incorporating petertodd's input-only txs to freimarkets with per-tx pow which with you can build "pow chains" you can hash your transaction on top of some others that already have pow, adding it all for the txs that haven't appeared "latelay" 17:54 < helo> so initial squatting is cheap, but you construct a bidding market to allow people to purchase the domains from the initial squatters? 17:54 < maaku> so long as there is an outstanding valid bid, the current owner has to pay (by destroying coins) a small percentage of the highest bid 17:54 < jtimon> you could also have hash-only transactions 17:55 < helo> interesting... 17:55 < maaku> yeah, and if the owner doesn't pay upkeep than the highest bid can claim the domain (but in doing so, they have to pay the owner the amount they offered) 17:56 <@gmaxwell> maaku: certantly not socially optimal. How would nike-exploits-children.bit exist in that world? 17:56 < maaku> jtimon: i'd have to see a more therough description / example to understand it 17:56 < helo> i think it would be uneconomical for me to keep my namesake's domain as i have for 15 years in such a system :/ 17:57 < jtimon> so you cannot bid up a domain for free, google could actually accept your million 17:57 < maaku> gmaxwell: in what way are you thinking? 17:57 <@gmaxwell> helo: you have hello.something? 17:57 <@gmaxwell> maaku: I mean that powerful voices could silence people just by outbidding them. 17:57 * helo dot org :) 17:57 < maaku> gmaxwell: that gets expensive, fast 17:57 < maaku> (the upkeep is destroyed, but the payment goes to the previous owner) 17:58 <@gmaxwell> When you're nike and your opponent is some broke activists? 17:58 < maaku> helo: that's two sides of the same coin. can't get rid of squatting or achieve ultimate utilization without annoying some early adopters 17:59 < helo> yeah... 17:59 < maaku> fwiw this is actually an application of georgian land tax theory 18:00 < jtimon> helo: if nobody else like the domain, you would pay a percentage of your "reserve" until somebody offers more, but you can always stop paying and leave the domain available 18:00 < maaku> which seeks to show that tax on the basic value of land (what I'm calling upkeep fees here) is the only known tax to *increase* economic production, and thereby (a georgist would claim) a moral tax 18:01 <@gmaxwell> maaku: making money is not the only valid use of a domain name. 18:01 < maaku> gmaxwell: i think it's more likely to work in the reverse direction 18:01 < maaku> re: nike 18:01 <@gmaxwell> nike-explots-children.bit doesn't make any money, its good cannot easily be monetized. 18:02 <@gmaxwell> so yes, letting people outbid popular names may well increase economic production, it may not improve human welfare (at least in all cases) 18:02 < maaku> so the activists pay their own upkeep fees as nike keeps upping the bid, then finally they run out of money and give in 18:02 < maaku> and get paid by nike, 20x what their annual upkeep fee was 18:03 < maaku> and then they register nike-enslaves-children.bit 18:03 <@gmaxwell> The most valuable economic production of wikiipedia.org (note typo) is, no doubt, a malware installer or other scam. I'm glad that it's owned by wikimedia instead. :) 18:04 < maaku> i'm more worried about solving the ideal distribution problem 18:04 < maaku> i'm not a crypto-anarchist, so I'm comfortable with some legal fallback for libel and such 18:05 < nsh> that's exactly what a crypto-crypto-anarchist would say, to throw us off the scent 18:05 < nsh> i'll be watching you... 18:05 < maaku> heh 18:05 < jtimon> but he has a point, how do you prevent people from getting sick when they get into wikipedia.bit ? 18:05 < nsh> :) 18:05 <@gmaxwell> I'm not uncomfortable about fallbacks for libel, but I don't think creating default economic incentives which fixate everything on money is a great way to achieve social justice. 18:05 < jtimon> into fake-wikipedia.bit, I mean 18:06 <@gmaxwell> (e.g. I am not a capitalism-is-everything-ist) 18:06 <@gmaxwell> There is merit to first come first serve. 18:07 <@gmaxwell> maybe something like com should be pay to park, and .org should be first come first serve. 18:07 < helo> i definitely like the idea of in-band domain bidding. the adversarial anti-bid fee is kind of spooky though. 18:07 < maaku> gmaxwell: that's a solution i'd be comfortable with 18:08 < maaku> for context, this originally came was designed for registering locations in a virtual world 18:08 < Luke-Jr> in other news, I am now officially a home owner <.< 18:08 < maaku> but there's going to be an alternate system for registering loations in the real world 18:08 < jtimon> but there has to be some cost, even or .org or you would bloat the "domain-UTXO" 18:08 <@gmaxwell> The idea that some names have more productive use than others is ... somewhat true but limited, thats probably only true for relatively few names, and we're faced with the problem that almost always the most 'productive' use of a name is a bad one (like scams) since good uses don't depend on their _name_ in order to be prodctive. Naming is not like land. Land has properties beyond location. :) 18:08 < maaku> for the purpose of augmented reality 18:08 < maaku> which is similar 18:08 < maaku> Luke-Jr: congrats :) 18:09 <@gmaxwell> Luke-Jr: congrats. 18:09 < Luke-Jr> now I need to hack this silly Nest thermostat so I can put some free software on it <.< 18:09 <@gmaxwell> you bought a place swank enough to have a nest thermostat .. in florida? really? :P 18:09 < Luke-Jr> .. or just wait and see if they give in to my legal demands :P 18:09 < Luke-Jr> gmaxwell: nah, bought the Nest separately 18:09 <@gmaxwell> hehe 18:09 < Luke-Jr> couldn't find a cheap IP humidity sensor 18:10 < nsh> what happens if your nest gets too warm/cold? 18:10 < nsh> are you running a hatchery on the side or something? 18:10 < Luke-Jr> … 18:10 <@gmaxwell> mining should have been called incubating. 18:10 < Luke-Jr> heh 18:10 < nsh> hehe 18:10 < nsh> just hatched a block! 18:10 < Luke-Jr> Nest should put a miner in their tstat! 18:10 < warren> not digging? =P 18:11 < Luke-Jr> then it'd always report a higher-than-reality temperature <.< 18:11 < maaku> helo: it's essential that the bids be committed coins 18:11 < helo> yes 18:12 < maaku> because keep in mind that the adversary is sharing a cost, even if just opportunity cost 18:12 < helo> with a space carved out for first-come-first-served, i'm not so worried :) 18:14 <@gmaxwell> maaku: yea, but money has a non-uniform value. Joe acvitists might consider $50/month upkeep unreacable, while nike might think nothing of droping $60k on shutting up a nussance. 18:14 <@gmaxwell> yea, if both exist its less of a concern. 18:14 < nsh> why not... first come, first served with a (reasonably short ~6 month) julibee period 18:14 < nsh> owner has preference to keep domain through jubilee, but at a nonzero cost 18:15 <@gmaxwell> you mean initial obtaining is behind a auction? the problem there is that even if you're a dumb robot, stealing other people's names is perhaps a good strategy. 18:15 <@gmaxwell> people have done that with namecoin: snatching up names on expiration. 18:15 <@gmaxwell> assuming that people's original registrations are a good estimate of value. 18:15 < nsh> hmm 18:16 <@gmaxwell> though the idea of how hard it is to kick the holder depending on how hard they've held it isn't terrible. 18:17 < nsh> maybe how easy it is to keep a domain should be a function of html/css aesthetics 18:18 < nsh> although you'd want to have a "geocities peak" in the distribution somewhere 20:39 < wangbus> digging sounds more difficult :p 21:34 * andytoshi-logbot is logging 22:51 < Dylan_> I had some ideas for bitcoin, would anyone want to listen? 22:52 < BlueMatt> Dylan_: its always best to just go for it instead of asking if you can...whether or not you get responses is a function of who's online, but there are plenty of people who read scrollback, so it'll be seen eventually 22:57 < Dylan_> I was thinking about an automated system for the distribution of electricity (watts of the network) to reward people for to caputre electricity using solar panels, in the same way the miner are rewarded for computation 23:00 < Dylan_> I figure there are two ways to do it. 1. to have a box that plugs into the volage meter, that would send bitcoins to a wallet for electricy into the grid 2. to have a premined coin that was regulated by a power company that was sent when an owner put power into the grid 23:01 < Dylan_> but, I am stuggling over the first solution. How would one design a box to assure someone didn't break the voltage meter.... etc 23:02 < Dylan_> Has anyone been thinking about this? 23:04 < BlueMatt> I'm not sure if you can/want to handle checking of hardware modification at the currency layer... 23:05 < BlueMatt> there are ways to try to address it (make the thing fail if its case is opened, have someone physically go check it every month, etc), but I think thats all at a layer way higher than what you're paying with 23:06 < Dylan_> well, its definately a plan for after the ASIC's come out, and I definately need help to figure out if authenticating the watts is worth it.... 23:06 < Dylan_> yeah, my intuition says it is possible, but my conscious brain says... duh 23:07 < Dylan_> maybe I need more long walk, and showers or something 23:08 < Dylan_> would love to make it open source 23:08 < BlueMatt> I think dealing with hardware drm is something that happens way higher level than here 23:08 < Dylan_> and easy enough for my grandmother to use 23:09 < BlueMatt> (eg put private key in the thing, wipe the key when the box is opened, require key for payment from the power company) 23:10 < Dylan_> that way would use the premined version 23:10 < Dylan_> all a distributed system would need is a web page/server 23:13 < Dylan_> maybe having both systems to compete against eachother would also be good 23:17 < BlueMatt> I'm not sure what your model is here, if you mean no power company and completely decentralized grid...I'm not sure how well thats gonna work to begin with 23:27 < Dylan_> well, it depends on the country and the existing grid... but I would like to at least try to develope a model for both of them 23:27 < Dylan_> centralized and decentralized grids.... 23:29 < Dylan_> but solar panels are pretty good for both types of grids, which is why I would like to start there... and perhaps try and limit it there, because I don't think fosil fuel or wind tech are very good, 23:30 < Dylan_> maybe geothermal.... but now I am rambling... --- Log closed Sat Dec 21 00:00:15 2013