| 00:00:17 | vfor: | vfor has left #bitcoin-wizards |
| 00:25:02 | maaku: | Luke-Jr: 'storageless mining' isn't relaly about mining. it's a litmus test that the scheme being considered is powerful enough to not require local storage of the utxo at all |
| 00:26:00 | maaku: | since mining involves continuously 'rebasing' transactions in memory against new merkleroots each time a block is processed |
| 00:30:42 | maaku: | 'maybe we could design a structure which used the blockchain to define a tree' <-- that is 'merkle mountain ranges' which is what petertodd proposed for committed TXO |
| 00:32:26 | maaku: | so committed TXO means an insertion-ordered tree based on the block headers which includes spend status as an updatable bit |
| 00:32:27 | petertodd: | maaku: fwiw these days I'm thinking it'd be better to just use a standard sparse merkle tree in append-only mode rather than use the additional complexity of a merkle mountain range - the advantage of a MMR is in short proofs, but that's only applicable if you're proving the most recently added data |
| 00:32:47 | petertodd: | s/append-only/insertion-ordered/ <- better terminology |
| 00:34:55 | maaku: | andytoshi: the committed UTXO does require that someone have the paths through the UTXO trie for new outputs |
| 00:35:34 | maaku: | however this could be externalized by including a fee to a service node which maintains this info -- it then prepends the proofs as necessary |
| 00:37:25 | andytoshi: | maaku: what i've been musing about with Eliel is that nodes would store some small subset of the whole trie and grind outputs to make sure that their own outputs always land in this subset |
| 00:37:59 | petertodd: | andytoshi: that's my thinking w/ tree chains as well |
| 00:38:51 | maaku: | andytoshi: you can do that but why? incentives are structured so as to not require that, and it comes with loss of privacy |
| 00:38:58 | andytoshi: | i've been thinking about it and it's not clear that there are any small (in terms of required storage space) subsets of tries except contiguous ranges, and there is a huge privacy hit there |
| 00:40:02 | andytoshi: | maaku: i hadn't considered paid service nodes |
| 00:40:36 | andytoshi: | generally i get nervous about requiring fees to get set up because presumably when a user is first receiving money they don't have any to be spending on fees |
| 00:40:47 | petertodd: | andytoshi: that's an excellent point |
| 00:41:18 | andytoshi: | but if you could set it up so that you paid the fee on spend, e.g. the service node wouldn't help you unless you added an output, maybe it could work |
| 00:41:32 | maaku: | andytoshi: that's the idea |
| 00:41:44 | andytoshi: | (an entire output is probably too much, this is the kinda thing where micropayments seem appropriate, but that doesn't really change much) |
| 00:44:07 | petertodd: | of course the alternative is to do UTXO archiving, which puts a maximum size on the UTXO set, and still lets you spend old coins |
| 00:45:15 | maaku: | idk you lose much of the benefit there |
| 00:45:16 | gmaxwell: | RE: earlier STXO discussion, did someone magically figure out how to make TXO+STXO compatible with pruning while I've been busy? |
| 00:45:36 | maaku: | what do you mean by STXO -- insertion ordered or txid ordered? |
| 00:45:44 | andytoshi: | maaku: txid ordered |
| 00:46:09 | andytoshi: | gmaxwell: we sorta landed on prefix-filtering the STXO set so every interested party would store the (small) part that was relevant to them |
| 00:46:10 | maaku: | then it is compatible in the same way that UTXO is compatible with pruning, no? |
| 00:46:10 | gmaxwell: | insertion ordered wouldn't be so useful for a spent tree, since you need key ordered queries to prove non-existance. |
| 00:46:50 | gmaxwell: | maaku: A spent coin is forever spent. |
| 00:48:56 | andytoshi: | maaku: the trick is you never need to prove something's -not- in the UTXO set |
| 00:49:11 | maaku: | andytoshi: sure you do. all the time |
| 00:49:27 | maaku: | that's the quitasential wallet operation: has my coins been spent? |
| 00:49:51 | andytoshi: | if you're tracking the coins, you should have a proof that the coins are in the UTXO set |
| 00:50:14 | maaku: | andytoshi: not for full nodes, for spv clients |
| 00:50:16 | andytoshi: | if nobody has a proof it's safe to assume they're not |
| 00:50:28 | maaku: | ehhhh. no i don't think so |
| 00:50:32 | maaku: | you need an actual negative proof |
| 00:50:40 | maaku: | or you could just be sybil'd |
| 00:50:46 | andytoshi: | yeah, for SPV clients you do, sorry |
| 00:50:49 | petertodd: | hmm, so let me make sure I'm clear on this: the purpose of STXO is privacy scheme were you have some TXO->something mapping, and then prove that you're spending valid coins by showing they aren't in the spent list? |
| 00:51:07 | andytoshi: | petertodd: yup. cryptonote's ring signatures come with such a mapping |
| 00:52:04 | petertodd: | andytoshi: ok, and the advantage over zk-SNARKS is just math details? (IE I could prove a tx is valid by a zk proof that I correctly marked the TXO as spent) |
| 00:53:24 | petertodd: | oh, no that doesn't work... dumb idea |
| 00:53:47 | andytoshi: | you can do it with zk-snarks, just not that simply.. i think you need miner cooperation |
| 00:54:05 | andytoshi: | ring signatures are (a) computationally feasible, and (b) require no trusted setup |
| 00:54:39 | petertodd: | andytoshi: yeah, and the zk-SNARK version still needs a STXO set anyway |
| 00:55:35 | andytoshi: | hmm, i think so if you want it to be zero-knowledge to everyone but the spender |
| 00:55:48 | andytoshi: | most of the snark discussion has involved things being zero-knowledge to everyone but a miner |
| 00:56:12 | andytoshi: | and then you can just make the blocks' validity depend on legal UTXO updates (insertions and deletions), no STXO needed |
| 00:58:51 | andytoshi: | by 'legal UTXO updates' a mean a proof that the UTXO set used to be U, now it's U', which is zk in the actual transactions |
| 00:59:42 | petertodd: | andytoshi: yeah, and thus miners are evaluating the zk validity |
| 01:01:10 | petertodd: | so the ring-sigs k-anonymity set in cryptonote is all outputs in a single block right? not all prior outputs? |
| 01:02:06 | andytoshi: | the spender chooses the anonymity set from the set of all prior outputs i believe |
| 01:02:22 | andytoshi: | and every output in the anonymity set needs to be explicitly referenced |
| 01:03:14 | petertodd: | ah right, being ring sigs... (hilarious how you can choose to possibly be the pirate, over and over again) |
| 01:03:16 | andytoshi: | just using "all from a single block" would save some space but theoretically opens up an attack where someone mines blocks containing only one tx |
| 01:03:22 | petertodd: | yup |
| 01:07:52 | petertodd: | andytoshi: anyway, the prefix filtering concept seems fine to me, although I'd be inclined to make it a time-based window of epochs |
| 01:12:34 | andytoshi: | petertodd: can you elaborate on how to do that? to do insertion proofs in a hash-ordered trie you need to know the new element's immediate neighbor.. i guess when creating an output you would just grind until you find something where you're able to construct a proof? |
| 01:13:31 | andytoshi: | it seemed to me that your anonymity set would need to be a contiguous interval so that you could grind txids into there and be sure that you have the neighbors needed to make the insertion proof |
| 01:13:51 | petertodd: | andytoshi: well, imagine every year you start a new STXO tree, and every TXO specifies what year's tree it'll be spent in. Now you might wind up updating that tree well afer it's "year", but you can still prove the update was valid later. |
| 01:14:09 | petertodd: | advantage over prefix is just that it's more clear what's actually happening, and what the k-anonymity set consists of |
| 01:14:55 | petertodd: | (and yeah, you actually want an interval, so there aren't abrupt changes in the size of that set) |
| 01:15:58 | andytoshi: | right, i gotcha |
| 02:45:02 | justanotheruser: | What exactly would have to happen in the MPC to generate a SNARK seed? Would everyone need a seed for a priv-key and communicate with others to make the public key without knowing what the private key or their seeds were? |
| 03:42:24 | Eliel: | andytoshi: I think the incentives work pretty nicely with the STXO set. If you don't care about your privacy, you can get by with very little. If you do care about your privacy, you can store much more. |
| 04:09:48 | andytoshi: | Eliel: yeah, i quite like that aspect of it |
| 04:40:56 | maaku: | Eliel: that's true of UTXO sets as well |
| 04:41:17 | maaku: | nothging to do with STXO vs UTXO, just insertion-ordered vs txid-ordered |
| 07:52:18 | dsnrk: | looks like another altcoin (boolberry) has made a totally stupid PoW function that's "asic resistant". they use their own block chain as a scratchpad, which is useful for hardware devices and SPV clients that might want to verify it. |
| 07:54:02 | gmaxwell: | dsnrk: the notion isn't completely dumb, it's of a general class I noted as 'interesting' on https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas (search for utxo) |
| 07:54:13 | gmaxwell: | their implementation uhh isn't what I would have used. |
| 07:55:44 | gmaxwell: | What I would have done is H(header || H(utxo-sample(H(header))) where utxo-sample takes an input as a csprng seed, and samples some random places in the utxo set and builds a merkle tree over them. |
| 07:57:06 | gmaxwell: | Then based on the resulting block hash I'd have it reveal a subset of the points it sampled. SPV nodes can ask for utxo tree membership proofs too. |
| 07:57:19 | gmaxwell: | so assuming you have a comitted utxo you should be able to make self contained verification possible. |
| 07:57:28 | gmaxwell: | I dunno if it would be a good idea, but at least an interesting one. |
| 07:57:45 | gmaxwell: | The boolberry formulation seems very uh. adhoc. |
| 07:58:08 | dsnrk: | the system they've designed seems to be fairly insane though |
| 07:58:16 | gmaxwell: | I need a polite phrase for "didn't solve any of the concerns that I came up with given 5 minutes of thought." |
| 07:58:39 | nsh: | is that not polite enough? |
| 07:58:57 | nsh: | i think it's within your remit to be firm about these things |
| 07:59:20 | nsh: | i'd be kicking arse left right and centre if i had the ken and authority |
| 08:00:25 | gmaxwell: | Well I just think it unfortunate... I get a lot of emails that are outright technobabble, like proposing protocols where they hash random things for no explicable reasons, as if "Hash" means "add pixie dust". By that comparison the boolberry function is very well considered. :) |
| 08:01:04 | nsh: | * nsh nods |
| 08:01:30 | dsnrk: | gmaxwell: I would have expected the hash to pick a new set of data with the PRNG for each round rather than doing it once for setup only. is that a complete misunderstanding of the idea? |
| 08:01:34 | gmaxwell: | but it does seem to be a weird mix that basically maximally gets the harms (requires verfiers to pretty much have the blockchain, also pretty costly to verify) without the benefits (doesn't discourage delegation of hashing to blockchainless devices). |
| 08:01:47 | gmaxwell: | dsnrk: it's a correct understanding of what boolberry does. |
| 08:02:01 | gmaxwell: | (unless my understanding was also incorrect, I've not implemented it) |
| 08:02:30 | gmaxwell: | I think thats unfortunate, since yea... it makes it not actually block-data-query-hard. |
| 08:02:40 | dsnrk: | well their mining clients seem to get 4.8MB+ scratch pads from the pool server, and then the local client does hundreds of rounds a second on that data. |
| 08:03:50 | gmaxwell: | yea. As far as I'm concerned that totally defeats all the upsides of that kind of function. |
| 08:04:14 | dsnrk: | so really it's proving nothing and just makes their system have a lot of stales and use a lot of data. swanky. |
| 08:04:53 | gmaxwell: | vs a well constructed version where it would be infeasable to mine without having the data locally. (e.g. lowering any gap between decenteralized pooling and centeralized pooling) |
| 08:05:43 | dsnrk: | I'll have to try it out, but it looks like the CryptoNote PoW is broken in the same way scrypt was as well |
| 08:06:02 | dsnrk: | you seem to be able to do a time/memory tradeoff |
| 08:07:17 | gmaxwell: | ... |
| 08:08:21 | Apocalyptic: | well if it's a BSGS-like time/memory tradeoff it isn't that critical |
| 08:08:43 | dsnrk: | I could have totally misunderstood the way it works (hence why I need to actually try this out). |
| 08:11:21 | gmaxwell: | it's just kind of boggling, since this is a known optimization in ltc-scrypt that makes a non-trivial difference, and it can be engineered out... |
| 08:13:32 | dsnrk: | well if it works out it drops the price of FPGA CryptoNote miners considerably |
| 08:16:09 | dsnrk: | for scrypt it's nice and linear, you can mine litecoin on something with almost scratchpad at all |
| 11:38:46 | jaromil_: | jaromil_ is now known as jaromil |
| 16:03:29 | tjopper: | I think this is the right channel for this kind of theoritical stuff. Pls let me know if im wrong about it. |
| 16:04:03 | tjopper: | Me theory is kinda evilish and attacks the wrong people but its just to start some discussion |
| 16:04:49 | tjopper: | What if we create a DAC with a hashrate measuring tool. On this DAC we will create a coin (on the bitcoin blockchain(2.0 a bit like Mastercoin,Counterparty)) To mine this coin you have to provide "network traffic". The DAC wil use this "network traffic" too auto DDOS any node/pool above percentage X. When all nodes/pools are below percentage X we lower X by halve till it reaches a set percentage.When the set percentage is reached the D |
| 16:07:10 | tjopper: | Im dutch so I already misses the start of the game, I will read back later |
| 16:08:38 | tacotime: | dsnrk: The CryptoNote people were saying that optimization doesn't work and that for decreases in memory usage you achieve exponential or quadratic increases in computation time. |
| 16:08:55 | tacotime: | Although that doesn't sound like it should be true. |
| 16:09:31 | tacotime: | I do know dga (of CMU) spent a while optimizing it and said it was a bit of a pain in the ass as compared to scrypt. |
| 16:10:41 | tacotime: | https://bitcointalk.org/index.php?topic=583449.msg6865147#msg6865147 |
| 16:14:51 | dsnrk: | tacotime: I have a hard enough time working out what's meant to be going on with their stuff. remember that they also claimed it was GPU resistant, which given that the CUDAminer guys are keeping their code private while their farm pumps out Monero.. doesn't seem to hold true either. |
| 16:14:55 | tacotime: | My favourite thing about the Boolberry blockheader hashing algo is here: http://boolberry.com/index.html#hash |
| 16:15:04 | tacotime: | "Such difference(caused by the cache memory exhaustion) points to real memory hardness we guess." |
| 16:15:09 | dsnrk: | tacotime: the AMD miner is sort of questionable. |
| 16:15:22 | dsnrk: | yeah, it's like even they don't trust what they're saying about it. |
| 16:16:54 | dsnrk: | tacotime: ugh, someone in that thread just justified a binary as not malware by posting a virustotal link :C |
| 16:17:27 | phantomcircuit: | it's basically impossible to built an asic resistant pow |
| 16:17:30 | tacotime: | dsnrk: dga's final numbers on CUDA were reported to be about 3x power efficiency as compared to CPU. Which I suppose is still better than scrypt, but not really GPU unfriendly. |
| 16:18:09 | phantomcircuit: | SRAM is expensive but fast, i can put exactly the right amount to run your pow algo onto the chip and outperform cpu/gpu by 10x |
| 16:18:15 | dsnrk: | dga? thought it was made by christian or something. |
| 16:18:18 | phantomcircuit: | at 100x less the capital cost |
| 16:18:29 | dsnrk: | (no not Luke, dude's name is Christian) |
| 16:18:35 | phantomcircuit: | er |
| 16:18:39 | phantomcircuit: | at 1% the capital cost |
| 16:18:42 | phantomcircuit: | yeah that |
| 16:19:01 | tacotime: | dga does all the analysis and optimization afaik, i think they've been working together to profit off of altcoins. |
| 16:19:44 | dsnrk: | wouldn't surprise me. "NEW ASIC FREE ALGO" > mine it with your GPU miner in the background |
| 16:20:12 | tacotime: | That's about the state of things. :P |
| 16:20:37 | phantomcircuit: | dsnrk, i suspect that's what Artforz did with litecoin |
| 16:20:47 | phantomcircuit: | actually i bet he had an FPGA scrypt miner on day 1 |
| 16:21:06 | dsnrk: | I don't think anybody really cared about scrypt on an FPGA that much |
| 16:21:23 | dsnrk: | the only public one I've seen for that was quite slow in comparison with GPUs |
| 16:21:42 | tacotime: | That's what artforz did on Bitcoin, heh. I think he had the first closed source miner on 4870s, and hammered the network with it way before anyone else. |
| 16:22:10 | phantomcircuit: | tacotime, pretty sure he had functional ASICs before anybody else |
| 16:22:12 | phantomcircuit: | well |
| 16:22:15 | phantomcircuit: | eASIC |
| 16:22:20 | phantomcircuit: | but that's the same shit KNC is doing |
| 16:22:25 | tacotime: | Pretty much all FPGA implementations of scrypt are slow, I think the fastest one reported was ~40kh/s. |
| 16:22:26 | tacotime: | Yeah. |
| 16:22:44 | dsnrk: | 60kh/s over a quad spartan board |
| 16:22:51 | tacotime: | ah ok |
| 16:22:54 | phantomcircuit: | that's interesting |
| 16:22:57 | tacotime: | Yeah that's not super impressive. |
| 16:23:02 | phantomcircuit: | dont you get like 300kh/s on a gpu? |
| 16:23:07 | tacotime: | Getting it to run quickly on FPGA was a major PITA. |
| 16:23:09 | dsnrk: | 6-700 on a good GPU |
| 16:23:39 | tacotime: | But then synthesis onto ASICs led to some really high efficiency chips. |
| 16:23:48 | dsnrk: | the Vertcoin stuff is hilarious, if you ever looked into their "ASIC RESISTANT" nonsense |
| 16:23:50 | tacotime: | The Gridseed miners were rumoured to be just that, heh. |
| 16:24:09 | dsnrk: | it's pretty much a PoW built entirely for the time-memory tradeoff. |
| 16:25:26 | dsnrk: | phantomcircuit: got any thoughts on where Bitmain's new chips came from? |
| 16:25:42 | dsnrk: | if the originals were Bitfury clones, is this one as well? |
| 16:25:46 | phantomcircuit: | the A1 chips? |
| 16:26:15 | phantomcircuit: | bitfury has been working on a new chip for a while |
| 16:26:37 | phantomcircuit: | iirc he taped out on a timeline that would correlate with their A1 pretty close to exactly |
| 16:27:00 | tacotime: | I kinda wonder sometimes if bitfury = artforz = solar designer. |
| 16:27:06 | phantomcircuit: | the miner source guys tried to sell me some S1s |
| 16:27:11 | dsnrk: | you mean bitmain == coincraft == bitfury? |
| 16:27:22 | phantomcircuit: | i laughed and told them i have more than they've sold total |
| 16:28:31 | dsnrk: | phantomcircuit: doesn't look like the new Bitmain chip is the A1, the specs are totally different. |
| 16:28:51 | phantomcircuit: | $1.55/Gh isn't a bad price on the capital costs side, but they use 2W/Gh which means they wont be worth running at ~500Ph/s network |
| 16:29:11 | phantomcircuit: | dsnrk, i cant remember the names of any of this shit |
| 16:29:17 | dsnrk: | https://bitcointalk.org/index.php?topic=656461.0 |
| 16:29:35 | phantomcircuit: | dsnrk, are you talking about the 28nm chip? |
| 16:29:35 | dsnrk: | < 1W/GH |
| 16:29:36 | phantomcircuit: | http://bitmine.ch/coincraft-28nm-asic/ |
| 16:29:37 | phantomcircuit: | that one |
| 16:29:51 | dsnrk: | yes. I'm saying it's not the same as the new antminer design. |
| 16:30:47 | tacotime: | If bitfury makes a 28 or 22 nm node chip, it'll be a lot less than 1W/GH. That's what his 55 nm design did, and he's probably learned from that. |
| 16:31:35 | tacotime: | "Power usage of 0.35 W/GH in low power, " that's pretty nice. |
| 16:32:00 | phantomcircuit: | dsnrk, 0.6W/Gh would be ~0.8W/Gh at the wall |
| 16:32:05 | phantomcircuit: | which is decent |
| 16:32:19 | phantomcircuit: | except i hate the packaging on those chips |
| 16:32:47 | dsnrk: | why? lots of small, binnable chips is what you want |
| 16:33:06 | phantomcircuit: | dsnrk, the epoxy packaging means nearly all of the heat is being dissipated into the board |
| 16:33:40 | phantomcircuit: | it's why the heat sinks are connected to the back of the board and not the chips |
| 16:33:40 | phantomcircuit: | https://bitmaintech.com/productDetail.htm?pid=00020140531103056245Ox3OpK1E0664 |
| 16:34:26 | dsnrk: | mm? I didn't see that as a bad thing. I'm sure it's a design choice, else they would have used BGA packages like BFL did. |
| 16:35:07 | dsnrk: | off the top of my head, it means you don't need to worry about the heatsink making proper contact with every chip. slight variences in heights is just fine |
| 16:35:56 | dsnrk: | pull me up on that if I'm being an idiot, but it seems sensible to me |
| 16:36:19 | tacotime: | I don't think it's a huge problem unless you want to overvolt and overclock them. |
| 16:36:38 | phantomcircuit: | dsnrk, the heatsinks have to be significantly larger |
| 16:37:08 | phantomcircuit: | the biggest issue with those systems is the heat dissipation from the chips |
| 16:37:18 | dsnrk: | right, so with the BGA ones you can pack a very dense board and have one heatsink. |
| 16:37:29 | phantomcircuit: | if one of them goes into thermal run away you basically can say goodbye to the entire board |
| 16:38:59 | phantomcircuit: | dsnrk, also if you look closely |
| 16:39:07 | phantomcircuit: | you'll notice the fins on their heatsink are bent |
| 16:39:23 | phantomcircuit: | on the unit they used for the sales website... |
| 16:39:24 | dsnrk: | don't need to look close, I have a pile of them at home |
| 16:39:46 | dsnrk: | oh |
| 16:39:51 | phantomcircuit: | dsnrk, if you're going to buy like a few of them |
| 16:40:05 | phantomcircuit: | then it's not so bad because you can baby them |
| 16:40:09 | phantomcircuit: | if you're going to buy thousands |
| 16:40:24 | phantomcircuit: | you have to calculate in a fairly substantial failure rate as the cost of business |
| 16:40:34 | dsnrk: | I haven't touched my antminers at all, babying what what you had to do with the bitfury rigs. |
| 16:41:03 | dsnrk: | blew the hell out of a multimeter testing the antminers voltage rails, decided I should just leave them alone. |
| 16:42:36 | tromp__: | phantomcircuit: you can make a pow resistant to a self-contained ASIC |
| 16:42:59 | dsnrk: | what like boolberry did? ;) |
| 16:43:31 | tromp__: | requiring on the order of a GB of memory should do it |
| 16:43:41 | tromp__: | they're not quite there yet |
| 16:44:09 | phantomcircuit: | tromp, what makes you think i cant build an asic which interfaces with DDR3 dimms? |
| 16:44:13 | dsnrk: | great, I'd like to see the size of the Trezor wallet for that coin. |
| 16:44:29 | dsnrk: | tromp__: heck, you can buy FPGA will very good DDR3/4 interfaces. |
| 16:44:36 | phantomcircuit: | if you can build something that works on an x86 cpu, someone can build an asic that does it 10x faster |
| 16:44:39 | tromp__: | phantomcircuit: that's what i mean by not selfcontained |
| 16:44:53 | phantomcircuit: | tromp__, who cares if it's self contained? |
| 16:44:54 | tromp__: | you can make an ASIC that relies on external memory modules |
| 16:45:21 | phantomcircuit: | dsnrk, how did you blow a multimeter measuring voltage? |
| 16:45:37 | phantomcircuit: | i've measured the voltage on the 12v 80+A rail in a cointerra unit without issue |
| 16:45:49 | tromp__: | if an x86 cpu can saturate the memory bandwidth, then an asic cannot be much faster |
| 16:46:01 | dsnrk: | phantomcircuit: I was tired and didn't pay attention to the fact that I was on the amperage range :C |
| 16:46:09 | phantomcircuit: | tromp__, an x86 cpu will not be able to saturate the memory bandwidth |
| 16:46:16 | phantomcircuit: | dsnrk, lolol |
| 16:46:34 | dsnrk: | phantomcircuit: 125A through a cheap multimeter. melted the leads and blew the hell out of the board inside. |
| 16:46:49 | phantomcircuit: | yeah |
| 16:46:50 | tromp__: | phantomcircuit it can if most access are random |
| 16:47:20 | phantomcircuit: | tromp__, let me try this another way |
| 16:47:49 | phantomcircuit: | i can build a system with an fpga that interfaces with 32 small ddr modules attached directly to the board |
| 16:48:02 | phantomcircuit: | and get 16x the bandwidth that a $400 mobo would give you for $40 |
| 16:50:46 | tromp__: | phantomcircuit: true, but the smaller the memory modules, the more expensive they become per GB |
| 16:51:13 | tromp__: | and you start running out of pins |
| 16:52:07 | phantomcircuit: | tromp__, shrug |
| 16:52:38 | phantomcircuit: | im sure that an application specific system could be made with a total cost 10x less than a standard cpu/mobo |
| 16:53:06 | tromp__: | not if the majority of the cost is in the memory modules |
| 16:53:17 | tromp__: | or even a significant fraction of the cost |
| 16:53:49 | phantomcircuit: | tromp__, it's not |
| 16:54:19 | tromp__: | 16GB memory modules dont come cheap |
| 16:54:47 | phantomcircuit: | you cant use 16GB |
| 16:54:56 | dsnrk: | tromp__: you're describing something which can't even be verified on any normal computer.. |
| 16:55:05 | phantomcircuit: | SPV clients on phones wouldn't be able to verify the chain in a timely manner |
| 16:55:11 | tromp__: | dsnr: you're totally wrrong |
| 16:55:27 | tromp__: | dsnr: i'm talking about an asymetric PoW |
| 16:55:32 | gmaxwell: | dsnrk: tromp has a class of algorithims which are reasonably cheap to verify. |
| 16:55:39 | tromp__: | dsnr: where verification is memoryless |
| 16:55:58 | gmaxwell: | (if you'd like to analyize it, digging into this TMTO claims would be useful) |
| 16:56:10 | gmaxwell: | er. s/this/his/ |
| 16:56:25 | dsnrk: | for cryptonote? |
| 16:56:49 | tromp__: | https://github.com/tromp/cuckoo |
| 16:56:56 | gmaxwell: | ^ that. |
| 16:57:00 | dsnrk: | oh you're thay guy, hey |
| 16:57:57 | phantomcircuit: | tromp__, at the very least a centralized player would calculate the depreciation costs correctly and operate cheaper on the basis of proper accounting alone |
| 16:58:02 | tacotime: | oh, dga did the review of it, heh |
| 16:58:16 | tromp__: | yes, dga helped tighten the memory requirements |
| 16:58:35 | tromp__: | now it's down to 1 bit per node in the graph |
| 17:00:30 | tromp__: | a centralized player needs to spend roughly the same on memory modules as desktop owners but would be less than a factor of 10 more efficient |
| 17:00:52 | tromp__: | and for the desktop owners it's often an alrd sunk cost |
| 17:01:36 | tromp__: | with efficient i mean hash-power per GB |
| 17:01:46 | phantomcircuit: | tromp__, i suspect your economics are wrong for a certain class of players (that would be me) but it's certainly a much better solution than the usual "JUST USE MORE RAM!" people :P |
| 17:02:19 | Eliel: | tromp__: efficient as in hashes per watt or hashes per second? |
| 17:02:49 | phantomcircuit: | Eliel, he's front loading the cost into the infrastructure instead of the power requirements |
| 17:02:57 | tromp__: | Eliel: per second |
| 17:03:15 | phantomcircuit: | tromp__, that's the other thing |
| 17:03:26 | tromp__: | power costs are dominated by memory costs |
| 17:03:33 | phantomcircuit: | there's more than a few novel optimizations which can be had with a more custom dram |
| 17:03:49 | Eliel: | if power efficiency is about the same, then it's still worth it to mine on desktops |
| 17:03:57 | phantomcircuit: | they're not used in consumer products because the reduction in reliability isn't worth it |
| 17:04:06 | tromp__: | phantomcircuit: how to optimize random access to global memory? |
| 17:04:07 | phantomcircuit: | but for something like this it probably would be |
| 17:04:13 | phantomcircuit: | tromp__, *magic* |
| 17:04:29 | phantomcircuit: | (power efficiency gains is what im thinking) |
| 17:04:37 | tromp__: | phantomcircuit: that would help all applications then , not just my pow |
| 17:04:58 | phantomcircuit: | optimizing for random access though the easiest thing to do is to physically move the dram modules closer to the consumer |
| 17:05:17 | tromp__: | the consumer is a tiny 1mm^2 circuit |
| 17:05:22 | phantomcircuit: | on a normal mobo the cpu/ram are 4-6 in apart |
| 17:05:26 | tromp__: | the memory chips are huge in comparison |
| 17:05:48 | tromp__: | if you consider an optimized cuckoo cycle asic |
| 17:06:04 | phantomcircuit: | tromp__, well yeah then i can basically just build the consumer onto the dram module |
| 17:06:42 | tromp__: | basically your distance to consumer is defined by distance between memory chips |
| 17:07:05 | tromp__: | the consumer needs to combine data from *all* memory chips |
| 17:07:15 | tromp__: | which are by necessity spread out |
| 17:07:42 | phantomcircuit: | tromp__, ok then i can get a 16GB memory chip and modify it with a consumer |
| 17:07:54 | tromp__: | also, you face the memory latency for random access |
| 17:08:02 | phantomcircuit: | then have a shared power infrastructure between tons and tons of boards |
| 17:08:13 | tromp__: | there are no 16GB chips |
| 17:08:25 | tromp__: | 16GB is like 16 memory chips |
| 17:09:29 | phantomcircuit: | tromp__, there are 16GB chips |
| 17:09:31 | tromp__: | anyway, redesigning 1GB memory chips is a whole different ballgame from making compute-intensive ASICS |
| 17:09:35 | phantomcircuit: | er |
| 17:09:37 | phantomcircuit: | no |
| 17:10:08 | tromp__: | commodity RAM is a market that dwarfs bitcoin |
| 17:10:26 | phantomcircuit: | tromp__, i was talking about basically modifying an existing DDR modules controller with the algorithm on it |
| 17:10:57 | tromp__: | yes, you can do that |
| 17:10:59 | phantomcircuit: | thus mostly commodity modules with a reflow |
| 17:11:23 | phantomcircuit: | that removes the cost of the mobo cpu and the vast majority of other components |
| 17:11:36 | phantomcircuit: | plus allows for shared power infrastructure between a ton of them |
| 17:11:53 | phantomcircuit: | and magic total manufacturing cost is now 100x per unit than a consumer cpu |
| 17:13:07 | tromp__: | in the near future we'll have many-core (on the order of a 100) cpus for a few hundred dolalr |
| 17:13:41 | tromp__: | which might be able to saturate 16GB of memory running cuckoo cycle |
| 17:14:21 | tromp__: | you're gonna have trouble doing that 10x more efficiently on a hashpower/$ basis with a custom solution |
| 17:15:10 | tromp__: | note that the memory cost is also on the order of a 100$ |
| 17:15:11 | phantomcircuit: | maybe |
| 17:16:33 | tromp__: | anyway, there seems to be little interest in using a novel PoW:( |
| 17:16:48 | dsnrk: | turn it into an altcoin, get filthy rich |
| 17:17:01 | dsnrk: | I'm shocked nobody has already, it's pretty much copy and paste from your code. |
| 17:17:09 | gmaxwell: | tromp__: oh no, there is tons of interest, so long as it's idiotically bad. :( |
| 17:17:12 | tromp__: | ppl are much happier proposing yet another hashcash-pow with a silly new hash function |
| 17:17:56 | tromp__: | cuckoo cycle is nontrivial to employ for 2 reasons |
| 17:17:58 | phantomcircuit: | er |
| 17:18:04 | gmaxwell: | tromp__: many of the altcoins being created have new, novel, and bad POWs. (see the earlier comments about boolberry) |
| 17:18:16 | phantomcircuit: | tromp__, i can buy 4x4Gb DDR3 modules for ~$35 |
| 17:18:27 | tromp__: | 1: proofs are as big as 168 bytes |
| 17:18:47 | tromp__: | 2: a single proof attempt can take severl minutes |
| 17:19:11 | tromp__: | gmaxwell: yes, but how many are non-hashcash? |
| 17:19:12 | dsnrk: | gmaxwell: got a PoW idea for you. measuring the surface area of a menger sponge. not really a hash, not really hard, but it sounds sweet right? |
| 17:19:24 | gmaxwell: | 1 isn't a problem compared to primecoin and other things. |
| 17:19:26 | tromp__: | gmaxwell: the only one i've seen proposed recently is gapcoin |
| 17:19:37 | hearn: | i think after all this research we'll conclude that SHA256 is a perfectly cromulent PoW :) |
| 17:20:05 | dsnrk: | tromp__: yeah that's nothing. boolberry PoW does searches across their block chain data.. except not for every round. it just means their pools send 4MB works to their clients. |
| 17:20:05 | phantomcircuit: | hearn, if anything it's too slow |
| 17:20:17 | andytoshi: | tromp__: do you have any thoughts on the economic argument that by improving joule/hash efficiency, memory hardness pushes the costs from maintenance and running costs into capital costs, which gives an advantage to established players? (it's a vague argument and more economic than technical so i don't mind if you just ignore it) |
| 17:20:26 | gmaxwell: | Well (2) reduces progress freeness. |
| 17:20:50 | gmaxwell: | I don't think the consequences of something like that have been well considered yet. |
| 17:21:16 | phantomcircuit: | tromp__, is the github for the hash a simple interface like calculate(); verify() |
| 17:21:17 | hearn: | the issues PoW has with outsourcing seem fundamental to the notion of "work", i don't see why another algorithm would do better or worse in the long run. though as a purely academic exercise, sure, designing exotic PoWs could be fun ... |
| 17:21:22 | tromp__: | it might require block interval times even larger than bitcoin's |
| 17:21:45 | gmaxwell: | tromp__: Right. |
| 17:21:48 | dsnrk: | does it change some of the logic around orphan blocks? if I'm 90% of the way through a hash it makes sense to finish it rather than switching to the other head. |
| 17:22:18 | phantomcircuit: | tromp__, oh actually im wrong |
| 17:22:22 | phantomcircuit: | there are 16GB modules |
| 17:22:57 | tromp__: | andytoshi: you have to distinguish between capital costs and sunken costs that characterize most desktop owners with spare mem/cycles |
| 17:22:59 | phantomcircuit: | LPDDR2 |
| 17:23:02 | phantomcircuit: | it's slower |
| 17:23:08 | gmaxwell: | dsnrk: the bigger concern is that if say the difficult is 1 hash, and you are 1/8th the hashpower of the network, but you are clocked 5x faster than everyone else— you'll be finding most of the blocks. (random numbers, but to just make a point) |
| 17:23:30 | tromp__: | andytoshi: but no, i don't feel comfortable making economic judgments:( |
| 17:24:03 | phantomcircuit: | tromp__, http://www.digikey.com/product-search/en?vendor=0&keywords=MT42L256M64D4EV-18+WT |
| 17:24:15 | phantomcircuit: | $24.60 per 16GB module |
| 17:24:27 | andytoshi: | tromp__: ah, ok. i guess this reduces to the argument about efficiency gains by dedicated hw (which i don't have the first clue about) |
| 17:24:42 | dsnrk: | gmaxwell: right, so in bitcoin that's dwarfed by other latencies. makes sense. |
| 17:25:14 | tromp__: | phantomcircuit: that's pretty competitive. i paid $300 for 32GB in my imac |
| 17:25:47 | gmaxwell: | andytoshi: the complex network-economic question in the memory hard case is the shift in costs between upfront and ongoing. |
| 17:25:55 | phantomcircuit: | tromp__, yeah these come in tubes or trays not as a ddr3 module |
| 17:26:08 | phantomcircuit: | the ddr module doubles the cost |
| 17:26:15 | phantomcircuit: | or actually |
| 17:26:17 | phantomcircuit: | adds about 25% |
| 17:26:30 | phantomcircuit: | then the retail supply chain adds another 25-50% |
| 17:26:38 | phantomcircuit: | and you have doubled the price per GB |
| 17:26:44 | andytoshi: | gmaxwell: sure, but it can reduce to asic-hardness. because suppose you don't have to deal with the upfront costs because your 'mining hardware' is some general purpose machine you'd be buying and upgrading anyway |
| 17:27:14 | phantomcircuit: | tromp__, and those are the published retail prices from digikey, i bet with some effort you could find those same modules for half the price |
| 17:27:38 | phantomcircuit: | which would be |
| 17:27:48 | dsnrk: | andytoshi: or stealing. you could hide a memory-hard PoW miner on a botnet. someone mining dogecoin on NAS was recently caught because their CPUs were being maxed out and slowing down the interfaces. |
| 17:27:54 | phantomcircuit: | $0.75/GB vs your macs $9.375/GB |
| 17:28:02 | phantomcircuit: | approximately a 10x price reduction |
| 17:28:07 | phantomcircuit: | which was my first guess |
| 17:28:21 | andytoshi: | dsnrk: ugh :( |
| 17:28:32 | phantomcircuit: | that being said |
| 17:28:39 | gmaxwell: | andytoshi: Thats just a constant factor (the base of existing parts)... maybe its a big enough one to matter, maybe not. I suspect not because the custom part will still enjoy considerable upfront and operating advantages. (e.g. lots of parts in a PC that aren't needed in a mining device). It would take a very parts specific analysis to know. |
| 17:28:43 | tromp__: | anyway, while i like the idea that most of a cuckoo cycle data center investment goes to repurposable hardware, i know you can argue that make it more attreactive to attack |
| 17:28:48 | phantomcircuit: | THIS IS THE BEST POW EVER EVERYBODY SHOULD USE IT |
| 17:28:58 | phantomcircuit: | * phantomcircuit goes off designing his pow machine |
| 17:29:03 | tacotime: | lol/ |
| 17:29:09 | dsnrk: | andytoshi: $600,000 worth of botnet mined on embedded hardware :\ |
| 17:29:26 | gmaxwell: | At a minimum it's better than the memory hard crap which is memory hard in the verifer. :) |
| 17:29:47 | dsnrk: | andytoshi: er, $600k worth of dogecoin mined on embedded hardware. |
| 17:30:16 | gmaxwell: | tromp__: Have you given any though to efficiently making your approach dataset-hard too? |
| 17:30:33 | andytoshi: | dsnrk: idk, i think i would notice ram exhaustion before i noted CPU exhaustion.. i spend a lot of time running really grindy academic code and don't feel it, but when i'm compiling every meg of ram helps |
| 17:30:41 | tromp__: | gmaxwell: what is dataset-hard? |
| 17:31:14 | gmaxwell: | The idea there is that in the inner loop of the funciton there is a step that does random lookups against a database which all verifiers know. E.g. the dataset could be the blockchain. The proofs would also carry responses to prove that the lookups in the resonse are part of the blockchain. |
| 17:31:16 | phantomcircuit: | andytoshi, how little ram do you have that every meg matters o.o |
| 17:31:57 | gmaxwell: | tromp__: the argument there is that it makes it infeasable to mine without having the dataset locally, so dumb botnet nodes that mine without validating the network data don't have so much of an advantage. |
| 17:32:05 | andytoshi: | phantomcircuit: 4gb :}. it's a new laptop, it was twice as costly to include the RAM with the machine, then i forgot to buy more.. thx for reminding me |
| 17:32:17 | tromp__: | gmaxwell: you can change the random graph definition to incorporate fragments of a data set into the siphash fuinction |
| 17:32:19 | phantomcircuit: | ha |
| 17:32:25 | andytoshi: | (but i guess even with 4gb i don't notice individual megabytes) |
| 17:32:31 | phantomcircuit: | andytoshi, nom nom 32GB of ram laptop |
| 17:32:43 | dsnrk: | andytoshi: wow, I run into SWAP even with 16GB :( |
| 17:32:57 | phantomcircuit: | dsnrk, o.o |
| 17:33:04 | dsnrk: | swap is not a acronym. |
| 17:33:16 | tromp__: | gmaxwell: in fact i proposed that on one of the ethereum blog articles |
| 17:33:21 | phantomcircuit: | swap is entirely empty with 32gb of ram |
| 17:33:41 | gmaxwell: | tromp__: it's an old idea— I just wondered if you'd considered it in the context of your system. |
| 17:33:51 | phantomcircuit: | MemFree: 29121872 kB |
| 17:33:53 | andytoshi: | can i do 32gb? is there an easy way to check my mobo's max, i'm worried it might be 16.. |
| 17:33:59 | dsnrk: | phantomcircuit: 16GB total, 400MB into swap |
| 17:34:15 | phantomcircuit: | dsnrk, that might be 400MB of stuff that's entirely idle |
| 17:34:22 | tacotime: | gmaxwell, I'm not sure that'll work against botnets, with Monero people just ran thousands of instances of the full node daemon on each member of the botnet. |
| 17:34:28 | dsnrk: | andytoshi: very mobo specific |
| 17:34:29 | tacotime: | I guess you get a lot of free full nodes, though. |
| 17:34:29 | phantomcircuit: | lots of programs have startup stuff they do which they never free |
| 17:34:36 | phantomcircuit: | it gets swapped out and never swapped back in |
| 17:34:37 | gmaxwell: | I'm fond of a structure where the prover does N random queries, and commits to a hashtree of them... then the final (winning) hash is used to select M of those random queries to reveal, M |
| 17:34:44 | tromp__: | gmaxwell: i only considered it when i read that ethereum article, but then didnt think it was interesting enough to put in the paper |
| 17:34:58 | phantomcircuit: | andytoshi, need model numbers |
| 17:35:34 | gmaxwell: | tacotime: it's not so much "anti-botnet" but "anti-non-validator" ... botnets that are running real full nodes are only a "concern" if you're worried about the ability to profit off mining.. if you're only worried about network integrity, thats not a huge problem. |
| 17:35:52 | dsnrk: | phantomcircuit: it's all sort of biggish things. web browser, VM from when I was testing an OSX bug before, redis. probably stuff I could kill but I don't value my SSD that much. |
| 17:36:01 | dsnrk: | phantomcircuit: oh and testnet3 in a ramdisk. |
| 17:36:09 | gmaxwell: | tromp__: in the past we've had some issues with miners that produced blocks with no transactions, which we believed was because it allowed them to mine without needing a pool or any system that had the blockchain data. |
| 17:36:14 | phantomcircuit: | lol redis |
| 17:36:17 | phantomcircuit: | shoot it in the face |
| 17:36:21 | phantomcircuit: | redis is ridiculous |
| 17:36:27 | phantomcircuit: | 5GB on disk db |
| 17:36:32 | phantomcircuit: | 45GB in ram |
| 17:36:38 | dsnrk: | * dsnrk shrugs |
| 17:36:39 | gmaxwell: | (they were, it seemed, — at least for now— cleaned out by deploying a soft-fork that caused them to mine a bunch of invalid blocks) |
| 17:36:45 | phantomcircuit: | effectively zero garbage collection of removed keys |
| 17:37:14 | phantomcircuit: | gmaxwell, that is hilarious |
| 17:37:14 | dsnrk: | not using it for anything serious, not a problem. |
| 17:37:28 | gmaxwell: | tromp__: more recently, you could look at the operating cost of p2pool vs being a dumb hashing slave... the cost of running a node is a real cost, though not a huge one. |
| 17:37:49 | gmaxwell: | so a function that shows you have the state required to mine is perhaps interesting. |
| 17:38:34 | Eliel: | frankly, I'm surprised I haven't heard of a coin with that kind of PoW yet |
| 17:38:44 | gmaxwell: | though keeping the proof size down is perhaps a challenge, esp if you do enough random queries to prevent a time memory tradeoff. |
| 17:38:44 | dsnrk: | Eliel: boolberry.. tried. |
| 17:38:50 | phantomcircuit: | gmaxwell, invalid soft forks seems like a reasonable solution to that though |
| 17:38:57 | gmaxwell: | Eliel: boolberry is ... kinda like that.. but they really didn't do it well. |
| 17:38:59 | phantomcircuit: | requires someone who cares enough to do it |
| 17:39:01 | phantomcircuit: | but eh |
| 17:39:12 | dsnrk: | Eliel: they do the whole block chain searching thing, but only for the setup. the miners can then increment a nonce without redoing the block chain search. |
| 17:39:16 | gmaxwell: | Since they seem to have sought to preserve mindless miners, kinda of the worst of all worlds. |
| 17:39:31 | Eliel: | dsnrk: how big of a nonce? |
| 17:39:53 | dsnrk: | don't know, big enough that the miners can mine over stratum |
| 17:39:58 | gmaxwell: | Eliel: the real important point is that there are already pools for it with mindless miners. |
| 17:40:16 | Eliel: | yeah, that's a problem |
| 17:40:19 | tacotime: | The boolberry dev had been warned a bunch of times about the uselessness of the hash function when the coin was in testnet, but didn't bother changing it. |
| 17:40:34 | gmaxwell: | I told them too. |
| 17:40:42 | dsnrk: | tacotime: it doesn't matter. it works enough for the pump and dump. |
| 17:41:03 | gmaxwell: | I also suggested a better facility than their minimum mixin flag. |
| 17:41:42 | zooko: | Hi folks! |
| 17:41:46 | tacotime: | Yeah that was another weird thing. Also I'm not sure how secure their "no ring signature inclusion for txouts before checkpoints" thing is. |
| 17:42:12 | dsnrk: | checkpoints as a security feature \o/ |
| 17:42:14 | gmaxwell: | (I propose that, instead, all coins be minimum mixin of 3 and that the value of the mixins not be required to be equal, but instead you take the minimum value of the mixins) |
| 17:42:24 | zooko: | I'm thinking about proof-of-work functions. I want one that fits onto a smart phone, and then with that constraint I want it to be as expensive as possible to scale up, e.g. by manufacturing ASICs. |
| 17:42:34 | zooko: | Do you have a pointer to the best ideas along those lines, if any? |
| 17:42:54 | tromp__: | i'm being ultra conservative with my 42 cycle length; perhaps length 8 could be similarly tmto hard |
| 17:43:05 | zooko: | amiller mentioned some off-hand idea to me of having a PoW function which exercises the whole ARM instruction set, so the Cortex-A9 in your smartphone is already an optimized ASIC for that function. |
| 17:43:25 | Eliel: | by the way, is there any point in using ring signatures bigger than the default? It seems to me you get the same by doing 2 consecutive rings of 3 than |
| 17:43:35 | Eliel: | one with 9 |
| 17:43:39 | gmaxwell: | zooko: it's probably impossible or at least very hard to make such a thing which is convincingly approximation free. |
| 17:43:50 | zooko: | * zooko nods. |
| 17:44:04 | Eliel: | (dang, typoed enter before was finished with editing the line) |
| 17:44:23 | gmaxwell: | zooko: e.g. say I define a new Arm ISA, Arm-BrainDamaged which implements something arm like but removes every expensive operation. I use that thing to mine instead, — sometimes its gets wrong results, but thats okay, I just throw those out. |
| 17:44:32 | zooko: | gmaxwell: I would uncertainly guess that such thing *could* be made so that the advantage of a custom ASIC vs. a commodity Cortex-A9 is not a huge factor. |
| 17:44:39 | gmaxwell: | Perhaps I can even rapidly detect if any particular challange will be wrong and terminate extra fast. |
| 17:44:43 | zooko: | gmaxwell: yeah. |
| 17:45:30 | zooko: | gmaxwell: And at the same time, the real general-purpose commodity ARM is optimized to do common operations more efficiently than rare ones, where if the mining challenge is evenly distributed then maybe the custom ARMiner would optimize differently.. |
| 17:45:44 | gmaxwell: | zooko: Also, hashcash which is upfront cost driven vs operating cost (power) driven is different economically. (maybe better? I'm dubious). Certantly fabrication capacity is way more centeralized than power generation. |
| 17:46:10 | zooko: | But despite all that, it seems like it should be *too* hard to define a thing where efficiency-of-custom-ASIC / efficiency-of-commodity-smartphone is a lower factor than a lot of other PoW alternatives. |
| 17:46:25 | zooko: | gmaxwell: Yes. |
| 17:46:37 | gmaxwell: | zooko: yea, in andy's pow paper these properties are called "approximation freeness" and "optimization freeness" a good POW is convincingly largely these things. |
| 17:46:40 | zooko: | gmaxwell: as you know, I think Bitcoin is prone to centralization of mining. |
| 17:47:00 | zooko: | gmaxwell: and like you suggest, I think that reducing the marginal efficiency gained from capital investments could help. |
| 17:47:09 | tromp__: | zooko: some phones have more cores (8) than my brand new 27" imac (4) |
| 17:47:15 | zooko: | Could you please give me a link to that paper? |
| 17:47:22 | zooko: | tromp__: good point. |
| 17:47:27 | gmaxwell: | zooko: https://download.wpsoftware.net/bitcoin/asic-faq.pdf |
| 17:47:29 | tromp__: | so they could do a small size cuckoo cycle reasonably well |
| 17:47:35 | zooko: | Thanks |
| 17:47:59 | maaku: | So I have a UTXO related question that perhaps someone can help me with. |
| 17:48:02 | zooko: | tromp__: I looked at your cuckoo paper, but I don't remember why it would be particularly relevant to this. Can you summarize what advantages cuckoo hashing PoW has? |
| 17:48:10 | zooko: | Hi maaku! Nice to IRC you again. |
| 17:48:13 | maaku: | If you assume UTXOs are stored in a PATRICIA trie, it has been argued before in this channel that there is a series of updates which if applied out of order require non-local information to update the tree, making stateless mining impossible. |
| 17:48:15 | maaku: | hi zooko |
| 17:48:30 | tromp__: | the advantages are right on the github page in the README |
| 17:48:33 | maaku: | This had something to do with the interaction of deleting nodes and PATRICIA level-compression. The solution was to not use level-compression when computing hashes by inserting a series of single-branch nodes, for level-compresed branches. |
| 17:48:49 | gmaxwell: | it's only an issue for level compression |
| 17:48:55 | maaku: | Now that I am finishing a BIP describing the implementation I'm working on, I need to justify this rather significant performance hit, but I'm having trouble recreating the problem.. perhaps someone can help me recreate the situation where uncompressed branches are required when hashing? |
| 17:49:20 | maaku: | gmaxwell: yeah i'm having trouble recreating that issue though |
| 17:49:42 | gmaxwell: | maaku: IIRC if you remove a node, such that it would allow another level compression step, you need the neighboring branch to graft it in. |
| 17:53:22 | maaku: | but you would have that wouldn't you? the inner branch which disappears has the hash which would be propagated upwards |
| 17:54:53 | gmaxwell: | it's not the disappear which is the problem, it's that when you go up you need to graft on a neighboring one, and you don't have it, as it wasn't needed in any of the indivigual updates that didn't cause the prune. |
| 17:57:09 | zooko: | tromp__: this is the interesting claimed advantage: "Runtime in Cuckoo Cycle is dominated by memory latency (67%). This promotes the use of commodity general-purpose hardware over custom designed single-purpose hardware." |
| 17:57:21 | zooko: | But why can't custom-designed single-purpose hardware have good memory latency? |
| 17:57:29 | maaku: | so let's assume two keys: 00000000 and 00001111. that results in [root -> 0000 -> (0000, 1111)] |
| 17:57:41 | maaku: | so the inner node has hashes for both 0000 and 1111 |
| 17:58:04 | maaku: | when you say "graft on a neighboring one" you mean the other branch not deleted right? |
| 17:58:09 | gmaxwell: | yes. |
| 17:59:17 | maaku: | so we have the hash for that. if we delete 00001111, then we get [root -> 00000000], where the root node is updated to point directly to the leaf node |
| 17:59:27 | tromp__: | zooko: because making memory cheap forces you into existing dram technology, which incurs such latencies for random access |
| 18:00:17 | tromp__: | zooko: of all PoWs, cuckoo cycle does by far the least amount of computation per random global memory access |
| 18:00:41 | maaku: | likewise if we add 00001111, then we are back where we started, and we get there by pushing the hash of the leaf node down from the root to the new intermediate node |
| 18:01:26 | maaku: | i remember we were convinced earlier, i just can't figure out what it was |
| 18:01:29 | gmaxwell: | maaku: hm. maybe the issue was on an insertion then? |
| 18:01:34 | maaku: | maybe if there are multiple insertion deletions... |
| 18:01:36 | gmaxwell: | yea. I don't remember the specific case. :-/ |
| 18:01:55 | zooko: | Hm, yeah https://download.wpsoftware.net/bitcoin/asic-faq.pdf that I'm reading now asserts the opposite: that RAM in a circuit is more expensive to manufacture, but faster and cheaper to run, than commodity DRAM. |
| 18:02:09 | maaku: | i mean it's a 10x performance hit, so I want ot be extra sure it's actually necessary |
| 18:02:19 | zooko: | In "4. |
| 18:02:19 | zooko: | Is memory hardness desirable?" |
| 18:02:56 | tromp__: | zooko: they consider smaller amounts of ram, where sram technology makes sense |
| 18:03:35 | tromp__: | zooko: a GB of sram would be 10x faster but 100x more expensive than DRAM |
| 18:04:00 | zooko: | tromp__: that's consistent with that asic-faq.pdf claims. |
| 18:04:34 | zooko: | Today 1 GB of DRAM on a stick costs... |
| 18:04:36 | zooko: | $15 |
| 18:05:07 | zooko: | I wonder how much it adds to the cost (size) of an ASIC to add 1 GB SRAM to it. |
| 18:06:01 | tromp__: | zooko: it might increase the cost 100x? |
| 18:06:04 | gmaxwell: | SRAM? a lot... and a lot of power usage. |
| 18:07:14 | gmaxwell: | though dram has more gate advantage than speed loss, so you're generally cheaper (total costs) to have n copies of dram for anything that is embarassingly parallel (e.g. for any progress free pow) |
| 18:07:56 | zooko: | gmaxwell: oh, DRAM built into the ASIC? Or more like commodity DRAM connected to your ASIC with a bus of some kind? |
| 18:08:14 | zooko: | tromp__: I meant in concrete terms. I mean, 100 * what? |
| 18:08:16 | gmaxwell: | either or are possible. |
| 18:08:20 | zooko: | * zooko nods. |
| 18:08:32 | gmaxwell: | (see also the edram stuff now becoming possible in embedded systems) |
| 18:08:43 | gmaxwell: | er s/possible/popular/ |
| 18:09:01 | zooko: | Hm. |
| 18:09:08 | tromp__: | zooko: 100 times cost of your ASIC without any memory |
| 18:10:26 | tromp__: | it's very hard to find SRAM memory chips in decent sizes (more than a fwe MB) |
| 18:10:56 | dsnrk: | should be fun when Nvidia gets past Maxwell, their generation after that is going to be moving their memory on top of the GPU die. |
| 18:11:40 | dsnrk: | (sort of related, I just watched their roadmap video before and found it interesting) |
| 18:14:39 | zooko: | tromp__: okay, thanks. |
| 18:15:49 | zooko: | tromp__: I've been imagining a smartphone, of the kind which would be new and fancy in 2014, so it has maybe 2 GB of RAM total, which is left plugged into power and mining overnight, when it is otherwise idle. |
| 18:16:18 | tromp__: | ah, the minephone |
| 18:17:27 | dsnrk: | zooko: wouldn't you get huge hashrate fluctuations with that? |
| 18:17:31 | tromp__: | also comes with a copy of minecraft pre-installed:) |
| 18:17:54 | nsh: | not if we rearrange the continents a bit |
| 18:18:04 | dsnrk: | that'll work! |
| 18:18:07 | nsh: | * nsh smiles |
| 18:18:51 | tromp__: | zooko: note that smartphone OS usually have low per-process memory limits... |
| 18:19:04 | zooko: | Hm. |
| 18:19:06 | zooko: | How low? |
| 18:19:20 | dsnrk: | are iphones still 1GB total? |
| 18:19:39 | tromp__: | zooko: dunno. maybe 16MB or so? |
| 18:20:02 | dsnrk: | yep. 1GB DDR2. |
| 18:20:03 | tromp__: | zooko: just dont assume they can use all the RAM |
| 18:20:21 | zooko: | tromp__ thanks for the note. |
| 18:21:12 | tromp__: | zooko: then again, the OS itself might be unlimited, so if you can make mining OS-native... |
| 18:21:53 | zooko: | Hm. |
| 18:22:38 | zooko: | http://blog.javia.org/how-to-work-around-androids-24-mb-memory-limit/ |
| 18:23:50 | zooko: | http://stackoverflow.com/questions/4351678/two-questions-about-max-heap-sizes-and-available-memory-in-android?rq=1 |
| 18:23:56 | zooko: | <- "Recent devices (e.g. the Nexus 4) cap the heap size at 96MB or more." |
| 18:24:29 | tromp__: | that's enough for a decent-size cuckoo cycle |
| 18:25:12 | zooko: | Hm. |
| 18:25:24 | zooko: | Yeah, so a memory-hard function is a pretty good candidate for my purposes. |
| 18:25:32 | zooko: | And cuckoo-PoW is a pretty good memory-hard function. |
| 18:25:52 | tromp__: | keeps the phone from overheating |
| 18:26:02 | zooko: | Good point! |
| 18:26:13 | hearn: | bear in mind you don't get to use all 96mb |
| 18:26:17 | hearn: | the OS takes up some as well (per process) |
| 18:26:47 | zooko: | Ah, thanks. |
| 18:26:54 | zooko: | Hiya, hearn. How's life? |
| 18:27:02 | hearn: | hey. not bad! enjoying the summer :) |
| 18:27:08 | hearn: | how about for you? |
| 18:27:09 | tromp__: | cuckoo cycle at 2^29 vertices runs in 64MB |
| 18:27:33 | zooko: | Life is very busy for me! But great. |
| 18:27:42 | zooko: | I'm acting in the role of single dad for 2 or 3 of my boys all summer. |
| 18:27:47 | zooko: | Since my wife went away to Hacker School in New York. |
| 18:27:51 | zooko: | (We're in Boulder, Colorado.) |
| 18:27:58 | zooko: | Which is super awesome but business-inducing. |
| 18:28:10 | zooko: | I'm running this secure storage startup -- https://LeastAuthority.com. |
| 18:28:22 | zooko: | We announced the first upgrade of our secure storage service a couple of weeks ago. |
| 18:28:54 | hearn: | you have a hacker wife? awesome :) |
| 18:29:09 | hearn: | yes, i've seen least authority, very cool stuff |
| 18:29:12 | zooko: | Then last week my Chromebook Pixel lost its legacy-boot-flag from its NVRAM, locking me out, and then some unknown and unauthorized actor took over several of our gmail accounts and attempted to take over our coinbase account. |
| 18:29:23 | hearn: | yikes! |
| 18:29:24 | zooko: | Then while I was dealing with that, my *backup* laptop died... :-) |
| 18:29:27 | zooko: | So, it has been quite a ride. |
| 18:29:32 | hearn: | sorry to hear that. sounds like my lovely anti-hacking system didn't work :( |
| 18:29:44 | hearn: | where by "my" i mean "me and my old teams" of course ... |
| 18:29:47 | zooko: | But, since LeastAuthority does real end-to-end encryption for our customers, their data was never in danger of being read or edited. |
| 18:29:47 | tromp__: | busy times for Murphy... |
| 18:29:51 | zooko: | hearn: right. |
| 18:29:54 | dsnrk: | anti hacking system? |
| 18:30:06 | zooko: | tromp__: I actually hypothesize that they chose that day to strike because I had published about my main laptop locking me out. |
| 18:30:08 | hearn: | all google logins are risk analysed and subjected to a weak form of ID verification if they're considered risky |
| 18:30:19 | zooko: | Since it turns out they had access to at least one of our gmail accounts for about 6 weeks. |
| 18:30:25 | hearn: | but it can't stop skilled and determined attackers. it's meant to interfere with bulk operations |
| 18:30:36 | zooko: | hearn: we are still investigating, and it is a confounded mystery. |
| 18:30:37 | hearn: | right. if you were specifically targeted, that's what 2-step is for |
| 18:30:42 | dsnrk: | hearn: ha, yeah I'v been caught by that a lot of times (on my own accounts) |
| 18:30:46 | zooko: | hearn: one hypothesis is that they have a 0-day against google. ;-) |
| 18:30:58 | zooko: | A more likely hypothesis is that they compromised two independent laptops of our team. |
| 18:31:01 | hearn: | possible! but rare. |
| 18:31:11 | hearn: | right. or someone fell for a phishing scam, etc |
| 18:31:17 | dsnrk: | cloudflare was a google 2fa 0day wasn't it? |
| 18:31:20 | zooko: | Which, even though it is more likely than the first hypothesis, still surprises me quite a lot, because those two folks have exceptional security tools and practices. |
| 18:31:20 | hearn: | a good phish can take out even skilled sysadmins |
| 18:31:37 | zooko: | Yes, that's a good hypothesis. We can't find evidence of it yet. :-( |
| 18:31:41 | dsnrk: | zooko: checked your recovery email? setting it to an old hotmail account seems to bite everybody. |
| 18:31:52 | zooko: | I mean, not to brag, but our team are pretty exceptionally skilled. |
| 18:32:00 | zooko: | So, it is both humiliating and mysterious. |
| 18:32:05 | nsh: | :( |
| 18:32:13 | hearn: | yes, but security is hard. |
| 18:32:29 | zooko: | dsnrk: yeah, that's the thing, is that the attackers logged into two different accounts which had unguessable passwords that were not written down. |
| 18:32:34 | hearn: | google runs "red team" type exercises. i saw a few of them. new employees start out with ~nothing and are told to hack google. some of the things they came up with were amazing |
| 18:32:49 | zooko: | Hence, they either hacked google itself or hacked those two people's personal computers. |
| 18:32:55 | zooko: | That's as far as we've gotten in our investigation. :-( |
| 18:33:05 | dsnrk: | zooko: waterhole attack? |
| 18:33:06 | zooko: | I mean not stored/saved/written anywhere. |
| 18:33:28 | zooko: | dsnrk: yeah, such things are possible, but I don't know how to find conclusive evidence one way or the other of what happened to us. :-( |
| 18:33:45 | nsh: | can you image the personal computers |
| 18:33:47 | nsh: | ? |
| 18:33:52 | zooko: | Yes. |
| 18:34:09 | zooko: | Oh, and when I was listing reasons that I am super busy |
| 18:34:16 | zooko: | oh yes and by the way my wife is awesome, thank you very much, |
| 18:34:19 | nsh: | * nsh smiles |
| 18:34:24 | zooko: | I forgot to mention that I'm getting serious about inventing a cryptocurrency. |
| 18:34:28 | [BNC]dansmith: | [BNC]dansmith is now known as dansmith_btc |
| 18:34:33 | zooko: | So I spend a lot of time thinking and writing about that. |
| 18:34:44 | zooko: | s/inventing/implementing and deploying/ |
| 18:34:51 | dsnrk: | zooko: I'd be reimaging or selling all of the hardware and buying new stuf, maybe a bit over the top though. |
| 18:35:10 | zooko: | Yeah, we've done the latter step. |
| 18:35:21 | zooko: | I mean, we bought some new hardware. |
| 18:35:36 | zooko: | But, I'd really like to have a better understanding of what happened. |
| 18:36:12 | dsnrk: | seems like a long way to go to get to a coinbase account |
| 18:36:21 | zooko: | Yeah, that's what is creeping me out about it. |
| 18:36:33 | dsnrk: | surely there's lower hanging fruit than a company that's meant for security |
| 18:36:39 | zooko: | Is that I expect such things to be mostly-automated, or operated by low-skilled workers, and going for |
| 18:36:50 | zooko: | widely understood payoffs, such as domain name ransom. |
| 18:37:15 | zooko: | I *guess* someone could have gotten the idea from my public image that I was holding a big stash of Bitcoin. |
| 18:37:19 | zooko: | But... I dunno. |
| 18:37:20 | nsh: | they didn't gain access to coinbase then? |
| 18:37:31 | zooko: | They did not, because it had 2FA that they couldn't answer. |
| 18:37:36 | nsh: | great :) |
| 18:37:58 | zooko: | At which point they reset the password on zooko@LeastAuthority.com-within-gmail, and after that I have no evidence of them doing anything else. |
| 18:38:03 | zooko: | :-( |
| 18:38:07 | nsh: | it's a shame you can't (i presume) see what else they did with the gmail accounts |
| 18:38:14 | dsnrk: | zooko: I'm not sure I'd ever want to be one presenting that image. I'd be scared of people deciding rubber hose crypto was the easiest option. |
| 18:38:21 | nsh: | it'd be nice if you could keep a history of that for auditing |
| 18:38:24 | gmaxwell: | I recommend everyone in this space have a compromise canary on their personal workstations.. stick an unencrypted wallet.dat in the correct place (e.g. ~/.bitcoin) with a bitcoin or whatever in it... now you'll be paying the attacker to tell you that you've been compromised. |
| 18:38:35 | zooko: | dsnrk: I've never deliberately given the impression that I have a lot of Bitcoin, I don't think. |
| 18:38:43 | nsh: | * nsh nods |
| 18:38:47 | zooko: | But I've been talking about it, including talking about buying/trading/spending it, for many years, in public. |
| 18:38:49 | helo: | gmaxwell: already done :D |
| 18:38:52 | zooko: | gmaxwell: we did that. |
| 18:39:01 | dsnrk: | gmaxwell: I set up a nice honeypot just before with something similar :) |
| 18:39:03 | zooko: | gmaxwell: they didn't take the canary coins from the laptop. |
| 18:39:08 | zooko: | So, either they FORGOT TO LOOK |
| 18:39:14 | zooko: | or they used a 0-day against google instead of compromising that laptop. |
| 18:39:16 | zooko: | Or... ?? |
| 18:39:20 | zooko: | Burglars are just weird? |
| 18:39:22 | helo: | in time it will become more effective |
| 18:39:41 | zooko: | nsh: yes, that kind of audit trail would be super helpful. Google has it. We don't. |
| 18:39:52 | nsh: | * nsh nods |
| 18:39:53 | dsnrk: | gmaxwell: bitcoind listening on mainnet + weak root password + RPC open + SSH honeypot. lets see what we catch :) |
| 18:39:56 | nsh: | wonder what they'd do if you asked... |
| 18:39:59 | zooko: | nsh: we've asked for the google investigations team to work with us, and are waiting to hear back. |
| 18:40:02 | nsh: | right |
| 18:40:15 | nsh: | maybe dangling the idea that the compromise might be of them will get you some traction |
| 18:40:19 | nsh: | +initial |
| 18:40:37 | zooko: | I would assume that they will think we are wrong to suggest that. :-) And we probably would be wrong to suggest that. |
| 18:40:53 | nsh: | allusion > suggestion :) |
| 18:41:07 | gmaxwell: | zooko: it's possible they didn't look, or turned their nose up because it was too small relative to what they hoped to gain |
| 18:41:15 | zooko: | Yeah, we made it clear what we know. They ought to understand that. |
| 18:41:23 | gmaxwell: | then again I dunno why they would have if they let you know via the account access. |
| 18:41:29 | zooko: | Yeah. |
| 18:41:38 | dsnrk: | wouldn't they be better off taking the wallet canary then stealing the coins after they got busted? |
| 18:41:44 | zooko: | They outed themselves in order to attempt access to coinbase. |
| 18:41:47 | dsnrk: | suggests more the coins weren't the target at all. |
| 18:41:49 | zooko: | Which failed. |
| 18:41:57 | zooko: | So, it is creepy/. |
| 18:42:09 | zooko: | And they didn't take the canary coins. |
| 18:42:34 | dsnrk: | did you move the canary coins after compromise? |
| 18:42:42 | zooko: | Can't say. |
| 18:43:33 | gmaxwell: | zooko: yea, if they're outed, if they didn't take the coins it suggests they didn't know of them.. which seems implausable unless the compromise was elsewhere. |
| 18:43:46 | dsnrk: | hope the google team gets back to you, otherwise that's one creepy attack. |
| 18:43:47 | zooko: | Right. :-( |
| 18:44:13 | dsnrk: | were the compromised email addresses public? could I find them on a WHOIS or google search? |
| 18:44:29 | zooko: | dsnrk: yes. nathan@LeastAuthority.com and zancas@LeastAuthority.com. |
| 18:44:52 | zooko: | Then they used google admin privs to reset the password of jessica@LeastAuthority.com, which was associated with our coinbase account. |
| 18:44:59 | nsh: | how did you surmise one was compromised for 6 weeks btw? |
| 18:45:19 | dsnrk: | google mail has a public log of IP addresses, guessing that showed up |
| 18:45:20 | zooko: | Then they did "I forgot my password" on coinbase, but instead of sending an email challenge to her email, it sent a 2FA to her phone, so they were thus stymied. |
| 18:45:25 | zooko: | Then they reset zooko@LeastAuthority.com's password. |
| 18:45:56 | zooko: | nsh: unexplained logins to zancas@LeastAuthority.com's google account starting in late May, not noticed until now. |
| 18:46:17 | nsh: | ah |
| 18:46:27 | dsnrk: | zooko: you know, neither of those email addresses are very public. there's less than a page of results each. |
| 18:46:34 | zooko: | Hm. |
| 18:46:37 | zooko: | dsnrk: good point. |
| 18:46:52 | zooko: | There was a recent attack which allowed enumeration of gmail address, IIUC. |
| 18:46:56 | zooko: | I mean recently published. |
| 18:47:00 | nsh: | yup |
| 18:47:05 | nsh: | read it yesterday |
| 18:47:18 | nsh: | also linked to another piece about full account compromise, which i'm looking for |
| 18:47:27 | nsh: | .t http://blog.spiderlabs.com/2014/06/from-a-username-to-full-account-takeover.html |
| 18:47:29 | zooko: | http://www.wired.com/2014/06/gmail-bug-could-have-exposed-every-users-address/ |
| 18:47:41 | zooko: | * zooko looks at http://blog.spiderlabs.com/2014/06/from-a-username-to-full-account-takeover.html |
| 18:48:06 | nsh: | summary of vectors |
| 18:48:34 | zooko: | * zooko nods. |
| 18:48:48 | dsnrk: | zooko: that feels unlikely, manually searching a bunch of names and getting "zancas" at your domain would be pretty improbable. |
| 18:49:17 | zooko: | dsnrk: hm |
| 18:49:47 | dsnrk: | if you were going to target leastauthority.com it's easier to find them in your github account. |
| 18:50:11 | zooko: | Oh, yeah. |
| 18:50:28 | zooko: | Well, thanks for lending a sympathetic ear. |
| 18:50:32 | zooko: | I need to go for a bit. |
| 18:50:39 | dsnrk: | hope you get some answers o/ |
| 18:50:56 | zooko: | Oh, and did I mention my car battery went dead and my watch stopped? :-) |
| 18:50:59 | zooko: | Thanks, dsnrk! |
| 18:51:01 | zooko: | Bye for now! |
| 20:18:08 | dsnrk: | http://hackingdistributed.com/2014/06/18/how-to-disincentivize-large-bitcoin-mining-pools/ |
| 20:18:32 | dsnrk: | ahhhh why do these batty ideas keep getting to large audiences :C |
| 20:20:02 | dsnrk: | "Actually, it became a 55% miner for almost a day. And prior to that, it seems to have tested the waters over a period of 10 days or so, perhaps gauging the public's reaction." totally doesn't understand mining either. implying their hashrate actually changed over the space of a few hours. |
| 20:27:48 | phantomcircuit: | dsnrk, i got a really nice laugh out of that one |
| 20:28:26 | phantomcircuit: | dsnrk, his plan would make all mining solo mining, which would basically guarantee an oligopoly |
| 20:31:28 | dsnrk: | phantomcircuit: I like that it's described as just a few lines of changes too :C |
| 20:32:05 | jcorgan: | gavin just tweeted amiller's preprint |
| 20:34:24 | dsnrk: | is that a good thing? |
| 20:35:01 | jcorgan: | i have no idea. just quickly browsed through it and it is beyond my skillz |
| 20:35:15 | jcorgan: | but istr it was discussed in here, controversially |
| 20:36:05 | dsnrk: | yeah I'm going to need andy or gmax to explain this one to me. |
| 20:39:47 | dsnrk: | nothing like an academic paper citing blockchain.info's charts, which are totally useless and inaccurate for the most part |
| 20:44:17 | phantomcircuit: | dsnrk, tl;dr non-outsourcible puzzles, not practical currently as the variance would be far too high for individual miners |
| 20:44:33 | phantomcircuit: | providing a solution for variance is part of "future work" |
| 20:44:40 | phantomcircuit: | amiller, that's cheating :P |
| 20:46:26 | maaku: | phantomcircuit: also not practical because they are trivially hard-forkable away, and whoever generates the zkp parameters has the ability to mint blocks on demand ;) |
| 20:46:34 | maaku: | *soft-forkable |
| 20:47:15 | phantomcircuit: | maaku, are those parameters generated once? |
| 20:47:23 | phantomcircuit: | if so im sure a social solution would be possible |
| 20:47:53 | phantomcircuit: | although i personally would not want to be involved, the conspiracy theories would be extensive and ridiculous |
| 20:48:32 | maaku: | yes they are generated once, but no I don't think any social solution is possible |
| 20:48:47 | dsnrk: | I'm not sure you could ever trust it, there was some long winded thing about it a while ago. filming buying the PC, going somewhere with a camera rolling the whole time, making the proofs, destroying it, all that. the issue came down to the result being too big to write down by hand and thus you could never prove on video the secrets hadn't been exported too. |
| 20:49:07 | maaku: | it'd basically be 'yes, it is possible that someone with these keys could *undetectably* mint blocks on demand. but you don't have to worry about that because we destroyed them. trust me.' |
| 20:49:20 | phantomcircuit: | maaku, sure it is, at the next conference we get a hundred people to walk to a random computer shop |
| 20:49:21 | phantomcircuit: | buy a computer |
| 20:49:25 | phantomcircuit: | generate the parameters |
| 20:49:29 | phantomcircuit: | smash the computer into bits |
| 20:49:42 | phantomcircuit: | social solution |
| 20:49:52 | dsnrk: | exporting the bits is the issue, how do you get them off? how do you prove the secrets weren't exported too? |
| 20:49:58 | maaku: | that wouldn't even come close to satisfying me |
| 20:50:36 | maaku: | no one would be allowed to actually *see* the parameters, because you can't erse the memory. so now you're assuming the computer setup isn't compromised |
| 20:50:52 | phantomcircuit: | dsnrk, reams and reams of paper and smash the printer also |
| 20:50:59 | phantomcircuit: | then have some poor shlub sit there for a month scanning them back in |
| 20:51:11 | maaku: | with the entire future bitcoin economy on the line ... how certain are you that the NSA or GCHQ couldn't pull of a stunt and substitute parameters at the last moment? |
| 20:51:31 | dsnrk: | phantomcircuit: how do you know the secrets weren't compromised and made to be deterministic? |
| 20:53:50 | phantomcircuit: | dsnrk, have the problem on some read only media which is available for inspection |
| 20:54:13 | phantomcircuit: | basically what you're worried about at that point is someone pulling off some crazy giant magic trick type stuff |
| 20:54:17 | zooko: | maaku: we could do a secure multiparty computation so that N different participants each generate a secret factor, and then if any of them successfully destroy their secret factor, nobody can ever exploit the parameters. |
| 20:55:06 | dsnrk: | phantomcircuit: backdoored computer that alters the generation on the fly? I don't know, it's something that would undoubtably turn into a conspiracy theory. |
| 20:55:42 | maaku: | zooko: the trouble is that practical MPC systems at this scale have the same secret parameters involved. it's turtles all the way down. |
| 20:57:18 | maaku: | dsnrk: when the prize is the ability to mint blocks on demand for all eternity, I don't think any conspiracy theory is too outlandish |
| 20:58:45 | zooko: | maaku: hm, I think there's a way to do this without standing on a turtle. |
| 20:59:01 | zooko: | Because you don't use a general-purpose MPC system, you custom-design one to generate the necessary shared public parameters without exposing the secret factors. |
| 20:59:26 | zooko: | maaku: another perspective on that is, could we have ex post facto detection of counterfeiting? |
| 20:59:32 | zooko: | If that detection were good enough, it would probably deter counterfeiting. |
| 21:00:12 | maaku: | zooko: if you could design such a prototypical setup, it would be a very good thing |
| 21:00:25 | maaku: | this has implications for things like zerocash as well, which suffer the same problems |
| 21:00:50 | maaku: | but regarding ex-post-fact detection, that would violate the zkp condition |
| 21:02:30 | dsnrk: | maaku: neither. being able to make free money, is that motivation enough to backdoor every computer going to be sold near a BTC conference? maybe, maybe not. |
| 21:04:15 | phantomcircuit: | dsnrk, probably, is it motivation enough to do so without getting caught? |
| 21:04:18 | phantomcircuit: | i doubt it |
| 21:05:47 | maaku: | dsnrk: for state level actors? certainly |
| 21:06:08 | zooko: | Yes, in fact I am getting this idea from something Matt Green told me, in the context of ZeroCash, that he knew how to design such a secure multi-party setup protocol. |
| 21:06:58 | phantomcircuit: | lol that stupid selfish mining guy |
| 21:07:03 | zooko: | maaku: I don't think it would violate the zkp condition if, for example. we had some aggregate measurement of how much independent money was existent, or moved during a certain interval, or something, and the counterfeiting detector is just testing whether that ever exceeds the intended upper bound. |
| 21:07:06 | phantomcircuit: | he's just smart enough to say things that sound smart |
| 21:07:10 | phantomcircuit: | but not smart enough for them to be smart |
| 21:07:49 | maaku: | zooko: i'm not talking about counterfeiting at all. i'm talking about making a fradulent proof that you solved a proof of work |
| 21:08:14 | maaku: | which would let you mint a block in the non-outsourceable puzzle setup |
| 21:23:54 | Burrito: | Burrito is now known as Burrito_ |
| 21:24:31 | Burrito_: | Burrito_ is now known as Burrito |
| 21:45:40 | amiller: | fuck i'm totally pissed that gun sirer is beating me to the punch with his blogpost... |
| 21:45:40 | amiller: | anyway... my paper preprint is announced now http://cs.umd.edu/~amiller/nonoutsourceable_full.pdf Nonoutsourceable Scratch-Off Puzzles to Discourage Bitcoin Mining Coalitions |
| 21:50:50 | maaku: | amiller: well gun's blog post isn't even a progress-free construction |
| 21:54:37 | tromp__: | maaku: how is it not progress-free? |
| 21:55:18 | tromp__: | each header only has one SHA256d and one SIG?! |
| 22:02:08 | maaku: | amiller: no hard feelings I hope (re: reddit). My goal was more to get in front of the mob of users that will latch onto this as The Solution and decry developers for not pushing it out fast enough |
| 22:02:18 | maaku: | tromp__: you have to mine the signature |
| 22:02:47 | maaku: | so mining is two stages: mine the SHA256d proof of work, then mine the digital signature proof of work |
| 22:02:57 | maaku: | that is not progress free |
| 22:06:08 | tromp__: | you're not mining the SIG, you're computing one SIG and one more SHA256d, that are tied to the same header. |
| 22:07:16 | tromp__: | if that fails you have to restart from scratch |
| 22:09:03 | maaku: | tromp__: that's not what the blog post is about |
| 22:09:43 | maaku: | or rather, that's not how the scheme actually works |
| 22:10:42 | maaku: | since ECDSA is trivially malleable, and undetectably so |
| 22:12:35 | maaku: | maybe what you describe what the author's intent, but it's not how it would work in practice with the rules as described |
| 22:13:10 | tromp__: | then i stand corrected, misled by the author's use of "the hash (SHA256(SIG(header, privkey)))" rather than "a hash" |
| 22:13:45 | tromp__: | how much entroyp is in the choice of sig? |
| 22:14:11 | gmaxwell: | if you konw the private key? 256 bits. |
| 22:14:17 | gmaxwell: | if you don't, one bit. |
| 22:15:36 | tromp__: | so the author unwittingly proposes changing the PoW from SHA256d to SHA256(ECDSA()) |
| 22:15:55 | gmaxwell: | There exist signature schemes without freedom, but as far as I know they either result in being one time signatures (can't reuse the key), or must use a bilinear group. |
| 22:17:18 | tromp__: | so much for "preserves the current investment in Bitcoin ... by existing miners" |
| 22:19:02 | maaku: | gmaxwell: well there's RSA |
| 22:20:06 | maaku: | but in this post he is talking about using "the coinbase transaction's private key" (sic) which presumably means ECDSA |
| 22:20:46 | gmaxwell: | maaku: hm. point. RSA sigs with determinstic padding are determinstic. |
| 22:20:53 | maaku: | although I suppose you could stick an RSA pubkey in a miner commitment and use that |
| 22:21:48 | maaku: | amiller's point actually, he pointed out RSA in a comment |
| 22:22:00 | gmaxwell: | maaku: you can derandomize dsa in that context. |
| 22:22:07 | gmaxwell: | commit to the nonce. |
| 22:23:56 | maaku: | or set the nonce by convention |
| 22:24:05 | gmaxwell: | you can't without compromising the private key. |
| 22:24:14 | maaku: | one-off private key |
| 22:24:18 | dsnrk: | phantomcircuit: ha, I didn't notice earlier but check out the hash board. their example one has a mod wire on it as well as bent up fins :) https://bitmaintech.com/bmtech/userfiles/image/5%281%29.jpg |
| 22:24:30 | maaku: | but yeah either way would work |
| 22:25:02 | maaku: | what do you mean then by commiting to the nonce without revealing it? |
| 22:26:42 | gmaxwell: | if the nonce is k such that r = k*G, you just include r in the block. And you're signing the block hash, so then the signature is entirely determinstic. I haven't read the protocol you're talking about so perhaps thats not the right level of determinism. |
| 22:28:03 | maaku: | i see |
| 22:29:00 | gmaxwell: | maaku: just from what was said here I assume he's making the proposal that the POW be something like H(header) |
| 22:29:40 | tromp__: | with diffferent targets X and Y that allow for smooth transition |
| 22:30:09 | maaku: | gmaxwell: yes |
| 22:31:35 | gmaxwell: | if so, this has been proposed before. The issues that it has that I'm aware of, are as you mentioned it's not progress free, though perhaps it can be derandomized to achieve that. It is not hosting free— and hosting is much worse than pooling from a decenteralizion perspective. It's not immune to defection detection, so honest behavior can be bonded. I don't recall any other differences. |
| 22:32:34 | gmaxwell: | thinking about it more… bonding is more effective the more consolidation you have in a single party, so it could even give you provable hosting, though no one seems to care about hosting honesty. |
| 22:33:06 | maaku: | thinking about it some more, i'm not sure it accomplishes the goals he sets out either |
| 22:33:20 | gmaxwell: | it's especially ironic to talk about things that encourage hosting by killing pooling in the context of ghash.io. |
| 22:33:28 | maaku: | e.g. it doesn't where where the pool pays miners in the coinbase, which is recommended behavior |
| 22:33:38 | maaku: | yeah |
| 22:34:20 | maaku: | pooling is highly beneficial. centralized transaction selection is not. and these can or should be orthogonal |
| 22:34:34 | dsnrk: | heh well, ghash.io doesn't even notice when their pool mines to the wrong address for a few days. doubt they care enough to bother with all this coinbase payments crap. |
| 22:34:41 | gmaxwell: | maaku: presumably it's just completely incompatible with that. E.g. you'd require signatures under all keys, which is effectively a requirement that you only have a single output or suffer a massive slowdown. |
| 22:35:15 | gmaxwell: | yea, solving the wrong problem. Kills pooling for payment variance reduction, does nothing for centeralized transaction selection. |
| 22:35:20 | maaku: | gmaxwell: right. it necessitates poor practices and needless centralization |
| 22:35:36 | gmaxwell: | only except hoping that if you can't pool for variance reduction you won't do centeralized transaction selection. |
| 22:35:49 | gmaxwell: | which is an open question. |
| 22:36:08 | gmaxwell: | I think the obvious answer is that it completely kills decenteralized mining entirely and forces pratically all mining into cloud operations. |
| 22:36:20 | gmaxwell: | * gmaxwell waits for phantomcircuit's full and vigorous support of the proposal |
| 22:37:28 | maaku: | why aren't the hacking distributed people vetting their ideas on wizards first? grrr |
| 22:37:51 | gmaxwell: | In any case, this stuff might well just result in my depature from bitcoin completely. I don't have the energy to combat selfishly interested academics who promote irresponsible non-solutions using inflamitory and ill justified claims to the general public. |
| 22:38:22 | gmaxwell: | Because a voice of reason would compromise their ability to make unjusitified claims with a straight face? |
| 22:38:30 | dsnrk: | maaku: you're getting caught up in the small details. |
| 22:38:33 | gmaxwell: | This way enormous resources must be expended in a political battle. |
| 22:39:28 | dsnrk: | gmaxwell: a voice of reason would have at least told them their hashrate figures they have at the bottom are complete and total nonsense. |
| 22:39:35 | gmaxwell: | And they're right. In my case, I concede. I am not going to waste my time arguing against their bogus claims, nothing will compensate me for it... and I'm just completely tired of promiting correctness for the sake of correctness. |
| 22:41:13 | lechuga_: | :( |
| 22:43:48 | gmaxwell: | esp if I'm holding myself to a higher standard of accuracy than they are it means that I have to do a larger amount of work to respond than they do. |
| 22:44:29 | gmaxwell: | and this advantage is multiplied further if they're taking a position that results in big headlines and I'm taking a "woah there, things are more complicated than that" position. |
| 22:52:42 | andytoshi: | gmaxwell: i haven't spent half the effort you have fighting the bullshit around this event, but i'm still feeling pretty crushed by it....my feeling is, there is a lot of real stuff we've developed here towards getting a scalable trustless cryptocurrency, and we're potentially within arms' reach of some really incredible things (e.g. utxo updates in zk). so a better failure mode than 'fuck this |
| 22:52:43 | andytoshi: | noise, i quit' is maybe to say 'let reddit have bitcoin, i'll go quietly work on something with better privacy/scaling/whatever' |
| 22:53:14 | zooko: | I'm planning to start a new cryptocurrency. |
| 22:53:29 | zooko: | I would listen with intense interest and respect to any ideas you two have on the topic. |
| 22:53:43 | zooko: | Um, not RIGHT NOW, I mean -- it is time to go home and feed my children dinner. :-) |
| 22:54:13 | zooko: | The biggest unsolved problem for me right now is exactly what just blew up: how to deter or slow down centralization of mining. |
| 22:54:20 | andytoshi: | zooko: well, i really want the zk stuff and the crypto is not there today (to do fully zero-knowledge transactions you need SNARKs, which have trusted setup, and even the weaker ideas are not computationally feasible) |
| 22:54:46 | zooko: | andytoshi: did you see what we were saying earlier about a secure-multiparty-computation for the trusted setup? |
| 22:55:00 | zooko: | That sounds difficult/expensive/complicated, but it is my current favorite path forward. |
| 22:55:01 | andytoshi: | yeah, but that's nowhere near feasible |
| 22:56:05 | andytoshi: | i dunno, i feel like you're just smearing the trust around. there are NIZK proofs for specific things (e.g. you can prove DL_g(r) = DL_h(s) in zero-knowledge of teh actual discrete log) with no setup at all |
| 22:56:56 | gmaxwell: | andytoshi: but I don't really believe there can be another, — if one system is just going to be replaced by another then ultimately there is no value in it— perhaps a sufficiently decisive change could happen— something better in every way... but beyond that it's all just dilluting the network effects... the very little network effects we've fought so hard for over all these years. |
| 22:57:05 | zooko: | Right! If you can get me SNARKy awesomeness like zerocash and non-outsourceable without *any* trusted setup then yes, you are the hero of many future generations. |
| 22:58:04 | zooko: | gmaxwell: I don't think if Bitcoin were superceded, or even if it completely failed, that would permanently prevent widespread use of a future cryptocurrency. |
| 22:59:35 | gmaxwell: | permanently is a long time, I think it could be a major setback. Depending on the nature of things that happen, e.g. completely failed might be worse... but in general with freely clonable software there is no schelling point, except maybe "first" |
| 22:59:37 | maaku: | zooko: I've hit you with this offline before. you'd better have a darn good justification for yet another digital scarcity system |
| 22:59:59 | zooko: | maaku: I know. |
| 23:00:01 | andytoshi: | gmaxwell: nah, i think enabling anonymity would be a big enough change alone not to disillusion people. if we could also get cheap and quick blockchain verification that'd definitely do it |
| 23:00:07 | maaku: | otherwise many (myself included) will take pains not to share info |
| 23:00:20 | andytoshi: | and bitcoin is not quite 'freely clonable', it has enough awful failure modes that you really need smart people to keep it alive |
| 23:00:28 | andytoshi: | and there are extremely few of those |
| 23:00:30 | zooko: | maaku: well I'll do my best to explain why I think it is valuable, and I hope you choose to share. |
| 23:00:40 | zooko: | But first: make dinner for kids. :-) |
| 23:00:43 | zooko: | Bye for now folks! |
| 23:01:00 | gmaxwell: | andytoshi: Yes, anonymity might be a big enough one, but even then, maybe only if it doesn't make anything worse in the process, and it seems fundimental that the strong anonymity systems require an inherent tradeoff which so far has not been compenstated for by other improvements. |
| 23:01:29 | gmaxwell: | andytoshi: those failure modes are design flaws though, I mean, it's a bug that it (currently) requires people at all. |
| 23:01:35 | maaku: | kids are more important :) |
| 23:02:47 | phantomcircuit: | * gmaxwell [22:36:20] waits for phantomcircuit's full and vigorous support of the proposal |
| 23:02:49 | phantomcircuit: | ha |
| 23:03:15 | gmaxwell: | yea, zooko left too fast. I have lots of ideas and tools that I've not published because I'm tired of them showing up on some vaporcoin pump and dump whitepaper. Where my own bitcoin assets and projects lose value because I opened my mouth and some clueless schemer is trying to get rich on them, even without making them available to the public. :( |
| 23:03:16 | andytoshi: | gmaxwell: this is true, there were some oddities with bitcoin where there is consensus code in openssl and bdb..but what i meant was that it requires smart people to do the initial design stuff. either your currency copies bitcoin 100% or you're making some change that you'll fuck up if you're an idiot |
| 23:03:45 | phantomcircuit: | gmaxwell, i have no need for trickery, we're genuinely better at this than the competition :P |
| 23:03:48 | gmaxwell: | andytoshi: well you can just do it a bunch of times with different people and one will survive by chance. |
| 23:03:49 | andytoshi: | and if you're not an idiot, probably you spend your free time on -wizards and have no spare time to be implementing shitcoins ;) |
| 23:03:53 | gmaxwell: | (The silicon valley model) |
| 23:04:03 | andytoshi: | gmaxwell: mm, yeah :( |
| 23:04:37 | maaku: | andytoshi: if you created a new currency, you fucked up at that step |
| 23:04:58 | maaku: | (modulo exceptional footnote cases, which i am guilty of) |
| 23:05:02 | andytoshi: | maaku: almost certainly, yeah |
| 23:05:04 | dsnrk: | altcoins are pretty much in the startup mentality. make the minimum viable product and see if it sticks. |
| 23:05:22 | dsnrk: | if it doesn't, it wasn't your money that got burnt in the process. |
| 23:05:40 | gmaxwell: | it can fail amazingly and still make you a huge profit even. |
| 23:05:52 | gmaxwell: | Sadly they're not good science, since we can't even usually tell why things break. |
| 23:06:35 | dsnrk: | or we can say that a system is broken, but that doesn't mean anything because it's not on-the-spot breakable. |
| 23:06:56 | andytoshi: | anyway when i'm down about bitcoin's idiot-miner and idiot-user situation, i remember the potential there is in cryptocurrency as an idea. there are whole classes of faulty political and legal systems that could be completely obviated by eliminating trust and/or identifiability. and for the most part this was not even imaginable 5 years ago |
| 23:07:02 | andytoshi: | i gtg as well. but be happy everyone |
| 23:07:13 | dsnrk: | andytoshi: take care o/ |
| 23:09:41 | dsnrk: | gmaxwell: you too. don't let yourself get too burnt out. |
| 23:10:08 | gmaxwell: | I'm okay, the ordinarily ignorant people are just a lot easier to deal with. |
| 23:10:24 | gmaxwell: | Since the only thing against curing that is a bit of ego and inertia. |
| 23:11:12 | gmaxwell: | When you've got earnest, maybe kinda sorta viable proposals if you squint just right, with complex and subtle tradeoffs it just takes a lot more work to deal with. |
| 23:11:55 | gmaxwell: | What will be wose if it the loud PR causes people to raise money to pay someone to implement it (whom won't care if it's good or not, they're just being paid) who will actually go do so, it might be a lot harder to deal with. |
| 23:12:41 | dsnrk: | yes, it would. as soon as that happens bitcoin developers are "competition" seen as hostile. |
| 23:12:46 | gmaxwell: | sadly the best time-conserving strategy for anyone who doesn't like this is to stay quiet with criticisms until the last moment. |
| 23:14:03 | gmaxwell: | I don't feel comfortable with that sort of thing. |
| 23:15:14 | gmaxwell: | But I also don't like that I don't just have to analyize the proposal but to analyize the best possible modified proposal that I can come up with.. such a huge work sink and someone else gets all sorts of kudos for jumping the publication gun. |
| 23:15:51 | dsnrk: | that's the trouble with the number of developers/generally in the loop people not scaling to the amount of foolish ideas I suppose. in a way it doesn't seem to matter all that much, much of what gets posted on HN/reddit/bitcointalk in this sort of situation never turn into anything, at least from what I've seen of it thus far. |
| 23:16:40 | dsnrk: | can't say if that's because people point out obvious flaws or if they just never go anywhere. |
| 23:17:03 | gmaxwell: | I played a fun board game last night, http://www.conquistadorgames.com/conquistador-games-products/the-new-science.html The goal of the game is to get the most 'prestige' by publishing before your competition, but you can do fun strategic things in delaying publication so you can work ahead of everyone else. :) |
| 23:17:43 | gmaxwell: | dsnrk: yea, most of the stuff goes nowhere, but thats not actually much comfort since you don't know which things will gain legs until its already happened. |
| 23:18:21 | Eliel: | maaku: I don't think you necessarily need to prevent centralization of mining power. It's enough to make sure you can prove, in the short term, that the miners are doing what they're supposed to. In the long term the proof of work will do. |
| 23:19:04 | gmaxwell: | Eliel: maybe I don't understand what you're saying— but what we have mining for is the one thing (ordering) that we cannot do in a provable way. |
| 23:19:11 | gmaxwell: | If we could prove it was correct we wouldn't need mining... |
| 23:19:36 | gmaxwell: | even knowing after the fact that doom happened is little consolation. |
| 23:19:41 | Eliel: | I think PoS works for short term. |
| 23:19:47 | Eliel: | just not for long term |
| 23:20:09 | dsnrk: | gmaxwell: that looks incredibly interesting. I half expected it to be a gag product, but nope, real :) |
| 23:20:19 | Eliel: | and then there's this entangled logs thing. |
| 23:20:25 | gmaxwell: | dsnrk: it's a little immature as a product. |
| 23:22:02 | gmaxwell: | Eliel: It's very hard to analyize, even if you ignore that the nothing at stake bag of issues— what are the centeralization pressures when you need to have a big pool of money in one place to get a low variance ROI? ... and the collateral effects where now a mining pool compromise steals all the miners 'mining capital' ? oy. |
| 23:22:27 | dsnrk: | gmaxwell: for me half the game would be finding somebody willing to endure such a concept :P |
| 23:22:28 | tromp__: | gmaxwell: the irony of this game being published prematurely:) |
| 23:23:33 | gmaxwell: | tromp__: haha. yes. Well it was a kickstarter thing, and I have gotten the impression that producing a good board game is harder than it looks (like so many things…) |
| 23:24:00 | gmaxwell: | gwillen played it too (gwillen is local to me). |
| 23:27:04 | dsnrk: | oh well if you have bitcoin people around you've already cheated on the first part (finding anybody else willing to play) |
| 23:28:14 | gmaxwell: | that one isn't an issue, at all— one of the benefits of living here. |
| 23:28:48 | Eliel: | gmaxwell: stealing mining pool capital is not an issue, you can create limited keys that are only allowed to mine and sign them with the full rights key. |
| 23:29:05 | Eliel: | that way, pools can function without actually having access to the capital, just the right to mine with it |
| 23:29:43 | gmaxwell: | Eliel: yes, and then you start to lose the arguments that stake = an economic interest in the currency. :) |
| 23:30:08 | gmaxwell: | which was one of the arguments for that class of scheme in the first place. |
| 23:31:32 | Eliel: | gmaxwell: then again, I'm not sure what's the point in pooling up in a PoS system. Most of them seem to be setup to produce a set percentage extra per year. |
| 23:33:37 | gmaxwell: | Eliel: because all schemes implemented that I'm aware of are scalar, they'll only produce a fixed number of blocks per year. If you have 0.0001% of the coins, and there are only 53k blocks in a year.. what is your 90th percentile income range? |
| 23:33:38 | Gnar: | Where can I buy cocaine with shitcoins? |
| 23:33:41 | gmaxwell: | (for a year) |
| 23:34:01 | gmaxwell: | gmaxwell has kicked Gnar from #bitcoin-wizards |
| 23:35:11 | gmaxwell: | [META] so what I just set is that anyone who is banned in bitcoin-dev or bitcoin-global-bans is banned in here. I intend to use global bans just for repeat malware/scam/crapflood etc. |
| 23:35:32 | nairb: | heh... Gnar is now bragging about his trolling over in efnet #stocks.. |
| 23:35:37 | gmaxwell: | [META] and I set it so anyone banned in #bitcoin is quieted in here, which migth be more controversal? if anyone thinks that bad, please remove it. |
| 23:47:48 | catcow: | what logging bot do you use in this channel? |