00:00:17vfor:vfor has left #bitcoin-wizards
00:25:02maaku: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:00maaku:since mining involves continuously 'rebasing' transactions in memory against new merkleroots each time a block is processed
00:30:42maaku:'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:26maaku:so committed TXO means an insertion-ordered tree based on the block headers which includes spend status as an updatable bit
00:32:27petertodd: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:47petertodd:s/append-only/insertion-ordered/ <- better terminology
00:34:55maaku:andytoshi: the committed UTXO does require that someone have the paths through the UTXO trie for new outputs
00:35:34maaku: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:25andytoshi: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:59petertodd:andytoshi: that's my thinking w/ tree chains as well
00:38:51maaku: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:58andytoshi: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:02andytoshi:maaku: i hadn't considered paid service nodes
00:40:36andytoshi: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:47petertodd:andytoshi: that's an excellent point
00:41:18andytoshi: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:32maaku:andytoshi: that's the idea
00:41:44andytoshi:(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:07petertodd: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:15maaku:idk you lose much of the benefit there
00:45:16gmaxwell:RE: earlier STXO discussion, did someone magically figure out how to make TXO+STXO compatible with pruning while I've been busy?
00:45:36maaku:what do you mean by STXO -- insertion ordered or txid ordered?
00:45:44andytoshi:maaku: txid ordered
00:46:09andytoshi: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:10maaku:then it is compatible in the same way that UTXO is compatible with pruning, no?
00:46:10gmaxwell:insertion ordered wouldn't be so useful for a spent tree, since you need key ordered queries to prove non-existance.
00:46:50gmaxwell:maaku: A spent coin is forever spent.
00:48:56andytoshi:maaku: the trick is you never need to prove something's -not- in the UTXO set
00:49:11maaku:andytoshi: sure you do. all the time
00:49:27maaku:that's the quitasential wallet operation: has my coins been spent?
00:49:51andytoshi:if you're tracking the coins, you should have a proof that the coins are in the UTXO set
00:50:14maaku:andytoshi: not for full nodes, for spv clients
00:50:16andytoshi:if nobody has a proof it's safe to assume they're not
00:50:28maaku:ehhhh. no i don't think so
00:50:32maaku:you need an actual negative proof
00:50:40maaku:or you could just be sybil'd
00:50:46andytoshi:yeah, for SPV clients you do, sorry
00:50:49petertodd: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:07andytoshi:petertodd: yup. cryptonote's ring signatures come with such a mapping
00:52:04petertodd: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:24petertodd:oh, no that doesn't work... dumb idea
00:53:47andytoshi:you can do it with zk-snarks, just not that simply.. i think you need miner cooperation
00:54:05andytoshi:ring signatures are (a) computationally feasible, and (b) require no trusted setup
00:54:39petertodd:andytoshi: yeah, and the zk-SNARK version still needs a STXO set anyway
00:55:35andytoshi:hmm, i think so if you want it to be zero-knowledge to everyone but the spender
00:55:48andytoshi:most of the snark discussion has involved things being zero-knowledge to everyone but a miner
00:56:12andytoshi:and then you can just make the blocks' validity depend on legal UTXO updates (insertions and deletions), no STXO needed
00:58:51andytoshi: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:42petertodd:andytoshi: yeah, and thus miners are evaluating the zk validity
01:01:10petertodd:so the ring-sigs k-anonymity set in cryptonote is all outputs in a single block right? not all prior outputs?
01:02:06andytoshi:the spender chooses the anonymity set from the set of all prior outputs i believe
01:02:22andytoshi:and every output in the anonymity set needs to be explicitly referenced
01:03:14petertodd:ah right, being ring sigs... (hilarious how you can choose to possibly be the pirate, over and over again)
01:03:16andytoshi: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:07:52petertodd: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:34andytoshi: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:31andytoshi: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:51petertodd: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:09petertodd:advantage over prefix is just that it's more clear what's actually happening, and what the k-anonymity set consists of
01:14:55petertodd:(and yeah, you actually want an interval, so there aren't abrupt changes in the size of that set)
01:15:58andytoshi:right, i gotcha
02:45:02justanotheruser: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:24Eliel: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:48andytoshi:Eliel: yeah, i quite like that aspect of it
04:40:56maaku:Eliel: that's true of UTXO sets as well
04:41:17maaku:nothging to do with STXO vs UTXO, just insertion-ordered vs txid-ordered
07:52:18dsnrk: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:02gmaxwell: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:13gmaxwell:their implementation uhh isn't what I would have used.
07:55:44gmaxwell: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:06gmaxwell: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:19gmaxwell:so assuming you have a comitted utxo you should be able to make self contained verification possible.
07:57:28gmaxwell:I dunno if it would be a good idea, but at least an interesting one.
07:57:45gmaxwell:The boolberry formulation seems very uh. adhoc.
07:58:08dsnrk:the system they've designed seems to be fairly insane though
07:58:16gmaxwell: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:39nsh:is that not polite enough?
07:58:57nsh:i think it's within your remit to be firm about these things
07:59:20nsh:i'd be kicking arse left right and centre if i had the ken and authority
08:00:25gmaxwell: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:04nsh:* nsh nods
08:01:30dsnrk: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:34gmaxwell: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:47gmaxwell:dsnrk: it's a correct understanding of what boolberry does.
08:02:01gmaxwell:(unless my understanding was also incorrect, I've not implemented it)
08:02:30gmaxwell:I think thats unfortunate, since yea... it makes it not actually block-data-query-hard.
08:02:40dsnrk: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:50gmaxwell:yea. As far as I'm concerned that totally defeats all the upsides of that kind of function.
08:04:14dsnrk: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:53gmaxwell: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:43dsnrk: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:02dsnrk:you seem to be able to do a time/memory tradeoff
08:08:21Apocalyptic:well if it's a BSGS-like time/memory tradeoff it isn't that critical
08:08:43dsnrk:I could have totally misunderstood the way it works (hence why I need to actually try this out).
08:11:21gmaxwell: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:32dsnrk:well if it works out it drops the price of FPGA CryptoNote miners considerably
08:16:09dsnrk:for scrypt it's nice and linear, you can mine litecoin on something with almost scratchpad at all
11:38:46jaromil_:jaromil_ is now known as jaromil
16:03:29tjopper:I think this is the right channel for this kind of theoritical stuff. Pls let me know if im wrong about it.
16:04:03tjopper:Me theory is kinda evilish and attacks the wrong people but its just to start some discussion
16:04:49tjopper: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:10tjopper:Im dutch so I already misses the start of the game, I will read back later
16:08:38tacotime: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:55tacotime:Although that doesn't sound like it should be true.
16:09:31tacotime: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:14:51dsnrk: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:55tacotime:My favourite thing about the Boolberry blockheader hashing algo is here: http://boolberry.com/index.html#hash
16:15:04tacotime:"Such difference(caused by the cache memory exhaustion) points to real memory hardness we guess."
16:15:09dsnrk:tacotime: the AMD miner is sort of questionable.
16:15:22dsnrk:yeah, it's like even they don't trust what they're saying about it.
16:16:54dsnrk:tacotime: ugh, someone in that thread just justified a binary as not malware by posting a virustotal link :C
16:17:27phantomcircuit:it's basically impossible to built an asic resistant pow
16:17:30tacotime: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:09phantomcircuit: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:15dsnrk:dga? thought it was made by christian or something.
16:18:18phantomcircuit:at 100x less the capital cost
16:18:29dsnrk:(no not Luke, dude's name is Christian)
16:18:39phantomcircuit:at 1% the capital cost
16:18:42phantomcircuit:yeah that
16:19:01tacotime:dga does all the analysis and optimization afaik, i think they've been working together to profit off of altcoins.
16:19:44dsnrk:wouldn't surprise me. "NEW ASIC FREE ALGO" > mine it with your GPU miner in the background
16:20:12tacotime:That's about the state of things. :P
16:20:37phantomcircuit:dsnrk, i suspect that's what Artforz did with litecoin
16:20:47phantomcircuit:actually i bet he had an FPGA scrypt miner on day 1
16:21:06dsnrk:I don't think anybody really cared about scrypt on an FPGA that much
16:21:23dsnrk:the only public one I've seen for that was quite slow in comparison with GPUs
16:21:42tacotime: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:10phantomcircuit:tacotime, pretty sure he had functional ASICs before anybody else
16:22:20phantomcircuit:but that's the same shit KNC is doing
16:22:25tacotime:Pretty much all FPGA implementations of scrypt are slow, I think the fastest one reported was ~40kh/s.
16:22:44dsnrk:60kh/s over a quad spartan board
16:22:51tacotime:ah ok
16:22:54phantomcircuit:that's interesting
16:22:57tacotime:Yeah that's not super impressive.
16:23:02phantomcircuit:dont you get like 300kh/s on a gpu?
16:23:07tacotime:Getting it to run quickly on FPGA was a major PITA.
16:23:09dsnrk:6-700 on a good GPU
16:23:39tacotime:But then synthesis onto ASICs led to some really high efficiency chips.
16:23:48dsnrk:the Vertcoin stuff is hilarious, if you ever looked into their "ASIC RESISTANT" nonsense
16:23:50tacotime:The Gridseed miners were rumoured to be just that, heh.
16:24:09dsnrk:it's pretty much a PoW built entirely for the time-memory tradeoff.
16:25:26dsnrk:phantomcircuit: got any thoughts on where Bitmain's new chips came from?
16:25:42dsnrk:if the originals were Bitfury clones, is this one as well?
16:25:46phantomcircuit:the A1 chips?
16:26:15phantomcircuit:bitfury has been working on a new chip for a while
16:26:37phantomcircuit:iirc he taped out on a timeline that would correlate with their A1 pretty close to exactly
16:27:00tacotime:I kinda wonder sometimes if bitfury = artforz = solar designer.
16:27:06phantomcircuit:the miner source guys tried to sell me some S1s
16:27:11dsnrk:you mean bitmain == coincraft == bitfury?
16:27:22phantomcircuit:i laughed and told them i have more than they've sold total
16:28:31dsnrk:phantomcircuit: doesn't look like the new Bitmain chip is the A1, the specs are totally different.
16:28:51phantomcircuit:$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:11phantomcircuit:dsnrk, i cant remember the names of any of this shit
16:29:35phantomcircuit:dsnrk, are you talking about the 28nm chip?
16:29:35dsnrk:< 1W/GH
16:29:37phantomcircuit:that one
16:29:51dsnrk:yes. I'm saying it's not the same as the new antminer design.
16:30:47tacotime: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:35tacotime:"Power usage of 0.35 W/GH in low power, " that's pretty nice.
16:32:00phantomcircuit:dsnrk, 0.6W/Gh would be ~0.8W/Gh at the wall
16:32:05phantomcircuit:which is decent
16:32:19phantomcircuit:except i hate the packaging on those chips
16:32:47dsnrk:why? lots of small, binnable chips is what you want
16:33:06phantomcircuit:dsnrk, the epoxy packaging means nearly all of the heat is being dissipated into the board
16:33:40phantomcircuit:it's why the heat sinks are connected to the back of the board and not the chips
16:34:26dsnrk: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:07dsnrk: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:56dsnrk:pull me up on that if I'm being an idiot, but it seems sensible to me
16:36:19tacotime:I don't think it's a huge problem unless you want to overvolt and overclock them.
16:36:38phantomcircuit:dsnrk, the heatsinks have to be significantly larger
16:37:08phantomcircuit:the biggest issue with those systems is the heat dissipation from the chips
16:37:18dsnrk:right, so with the BGA ones you can pack a very dense board and have one heatsink.
16:37:29phantomcircuit:if one of them goes into thermal run away you basically can say goodbye to the entire board
16:38:59phantomcircuit:dsnrk, also if you look closely
16:39:07phantomcircuit:you'll notice the fins on their heatsink are bent
16:39:23phantomcircuit:on the unit they used for the sales website...
16:39:24dsnrk:don't need to look close, I have a pile of them at home
16:39:51phantomcircuit:dsnrk, if you're going to buy like a few of them
16:40:05phantomcircuit:then it's not so bad because you can baby them
16:40:09phantomcircuit:if you're going to buy thousands
16:40:24phantomcircuit:you have to calculate in a fairly substantial failure rate as the cost of business
16:40:34dsnrk:I haven't touched my antminers at all, babying what what you had to do with the bitfury rigs.
16:41:03dsnrk:blew the hell out of a multimeter testing the antminers voltage rails, decided I should just leave them alone.
16:42:36tromp__:phantomcircuit: you can make a pow resistant to a self-contained ASIC
16:42:59dsnrk:what like boolberry did? ;)
16:43:31tromp__:requiring on the order of a GB of memory should do it
16:43:41tromp__:they're not quite there yet
16:44:09phantomcircuit:tromp, what makes you think i cant build an asic which interfaces with DDR3 dimms?
16:44:13dsnrk:great, I'd like to see the size of the Trezor wallet for that coin.
16:44:29dsnrk:tromp__: heck, you can buy FPGA will very good DDR3/4 interfaces.
16:44:36phantomcircuit:if you can build something that works on an x86 cpu, someone can build an asic that does it 10x faster
16:44:39tromp__:phantomcircuit: that's what i mean by not selfcontained
16:44:53phantomcircuit:tromp__, who cares if it's self contained?
16:44:54tromp__:you can make an ASIC that relies on external memory modules
16:45:21phantomcircuit:dsnrk, how did you blow a multimeter measuring voltage?
16:45:37phantomcircuit:i've measured the voltage on the 12v 80+A rail in a cointerra unit without issue
16:45:49tromp__:if an x86 cpu can saturate the memory bandwidth, then an asic cannot be much faster
16:46:01dsnrk:phantomcircuit: I was tired and didn't pay attention to the fact that I was on the amperage range :C
16:46:09phantomcircuit:tromp__, an x86 cpu will not be able to saturate the memory bandwidth
16:46:16phantomcircuit:dsnrk, lolol
16:46:34dsnrk:phantomcircuit: 125A through a cheap multimeter. melted the leads and blew the hell out of the board inside.
16:46:50tromp__:phantomcircuit it can if most access are random
16:47:20phantomcircuit:tromp__, let me try this another way
16:47:49phantomcircuit:i can build a system with an fpga that interfaces with 32 small ddr modules attached directly to the board
16:48:02phantomcircuit:and get 16x the bandwidth that a $400 mobo would give you for $40
16:50:46tromp__:phantomcircuit: true, but the smaller the memory modules, the more expensive they become per GB
16:51:13tromp__:and you start running out of pins
16:52:07phantomcircuit:tromp__, shrug
16:52:38phantomcircuit:im sure that an application specific system could be made with a total cost 10x less than a standard cpu/mobo
16:53:06tromp__:not if the majority of the cost is in the memory modules
16:53:17tromp__:or even a significant fraction of the cost
16:53:49phantomcircuit:tromp__, it's not
16:54:19tromp__:16GB memory modules dont come cheap
16:54:47phantomcircuit:you cant use 16GB
16:54:56dsnrk:tromp__: you're describing something which can't even be verified on any normal computer..
16:55:05phantomcircuit:SPV clients on phones wouldn't be able to verify the chain in a timely manner
16:55:11tromp__:dsnr: you're totally wrrong
16:55:27tromp__:dsnr: i'm talking about an asymetric PoW
16:55:32gmaxwell:dsnrk: tromp has a class of algorithims which are reasonably cheap to verify.
16:55:39tromp__:dsnr: where verification is memoryless
16:55:58gmaxwell:(if you'd like to analyize it, digging into this TMTO claims would be useful)
16:56:10gmaxwell:er. s/this/his/
16:56:25dsnrk:for cryptonote?
16:56:56gmaxwell:^ that.
16:57:00dsnrk:oh you're thay guy, hey
16:57:57phantomcircuit: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:02tacotime:oh, dga did the review of it, heh
16:58:16tromp__:yes, dga helped tighten the memory requirements
16:58:35tromp__:now it's down to 1 bit per node in the graph
17:00:30tromp__: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:52tromp__:and for the desktop owners it's often an alrd sunk cost
17:01:36tromp__:with efficient i mean hash-power per GB
17:01:46phantomcircuit: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:19Eliel:tromp__: efficient as in hashes per watt or hashes per second?
17:02:49phantomcircuit:Eliel, he's front loading the cost into the infrastructure instead of the power requirements
17:02:57tromp__:Eliel: per second
17:03:15phantomcircuit:tromp__, that's the other thing
17:03:26tromp__:power costs are dominated by memory costs
17:03:33phantomcircuit:there's more than a few novel optimizations which can be had with a more custom dram
17:03:49Eliel:if power efficiency is about the same, then it's still worth it to mine on desktops
17:03:57phantomcircuit:they're not used in consumer products because the reduction in reliability isn't worth it
17:04:06tromp__:phantomcircuit: how to optimize random access to global memory?
17:04:07phantomcircuit:but for something like this it probably would be
17:04:13phantomcircuit:tromp__, *magic*
17:04:29phantomcircuit:(power efficiency gains is what im thinking)
17:04:37tromp__:phantomcircuit: that would help all applications then , not just my pow
17:04:58phantomcircuit:optimizing for random access though the easiest thing to do is to physically move the dram modules closer to the consumer
17:05:17tromp__:the consumer is a tiny 1mm^2 circuit
17:05:22phantomcircuit:on a normal mobo the cpu/ram are 4-6 in apart
17:05:26tromp__:the memory chips are huge in comparison
17:05:48tromp__:if you consider an optimized cuckoo cycle asic
17:06:04phantomcircuit:tromp__, well yeah then i can basically just build the consumer onto the dram module
17:06:42tromp__:basically your distance to consumer is defined by distance between memory chips
17:07:05tromp__:the consumer needs to combine data from *all* memory chips
17:07:15tromp__:which are by necessity spread out
17:07:42phantomcircuit:tromp__, ok then i can get a 16GB memory chip and modify it with a consumer
17:07:54tromp__:also, you face the memory latency for random access
17:08:02phantomcircuit:then have a shared power infrastructure between tons and tons of boards
17:08:13tromp__:there are no 16GB chips
17:08:25tromp__:16GB is like 16 memory chips
17:09:29phantomcircuit:tromp__, there are 16GB chips
17:09:31tromp__:anyway, redesigning 1GB memory chips is a whole different ballgame from making compute-intensive ASICS
17:10:08tromp__:commodity RAM is a market that dwarfs bitcoin
17:10:26phantomcircuit:tromp__, i was talking about basically modifying an existing DDR modules controller with the algorithm on it
17:10:57tromp__:yes, you can do that
17:10:59phantomcircuit:thus mostly commodity modules with a reflow
17:11:23phantomcircuit:that removes the cost of the mobo cpu and the vast majority of other components
17:11:36phantomcircuit:plus allows for shared power infrastructure between a ton of them
17:11:53phantomcircuit:and magic total manufacturing cost is now 100x per unit than a consumer cpu
17:13:07tromp__:in the near future we'll have many-core (on the order of a 100) cpus for a few hundred dolalr
17:13:41tromp__:which might be able to saturate 16GB of memory running cuckoo cycle
17:14:21tromp__:you're gonna have trouble doing that 10x more efficiently on a hashpower/$ basis with a custom solution
17:15:10tromp__:note that the memory cost is also on the order of a 100$
17:16:33tromp__:anyway, there seems to be little interest in using a novel PoW:(
17:16:48dsnrk:turn it into an altcoin, get filthy rich
17:17:01dsnrk:I'm shocked nobody has already, it's pretty much copy and paste from your code.
17:17:09gmaxwell:tromp__: oh no, there is tons of interest, so long as it's idiotically bad. :(
17:17:12tromp__:ppl are much happier proposing yet another hashcash-pow with a silly new hash function
17:17:56tromp__:cuckoo cycle is nontrivial to employ for 2 reasons
17:18:04gmaxwell:tromp__: many of the altcoins being created have new, novel, and bad POWs. (see the earlier comments about boolberry)
17:18:16phantomcircuit:tromp__, i can buy 4x4Gb DDR3 modules for ~$35
17:18:27tromp__:1: proofs are as big as 168 bytes
17:18:47tromp__:2: a single proof attempt can take severl minutes
17:19:11tromp__:gmaxwell: yes, but how many are non-hashcash?
17:19:12dsnrk: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:24gmaxwell:1 isn't a problem compared to primecoin and other things.
17:19:26tromp__:gmaxwell: the only one i've seen proposed recently is gapcoin
17:19:37hearn:i think after all this research we'll conclude that SHA256 is a perfectly cromulent PoW :)
17:20:05dsnrk: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:05phantomcircuit:hearn, if anything it's too slow
17:20:17andytoshi: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:26gmaxwell:Well (2) reduces progress freeness.
17:20:50gmaxwell:I don't think the consequences of something like that have been well considered yet.
17:21:16phantomcircuit:tromp__, is the github for the hash a simple interface like calculate(); verify()
17:21:17hearn: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:22tromp__:it might require block interval times even larger than bitcoin's
17:21:45gmaxwell:tromp__: Right.
17:21:48dsnrk: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:18phantomcircuit:tromp__, oh actually im wrong
17:22:22phantomcircuit:there are 16GB modules
17:22:57tromp__:andytoshi: you have to distinguish between capital costs and sunken costs that characterize most desktop owners with spare mem/cycles
17:23:02phantomcircuit:it's slower
17:23:08gmaxwell: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:30tromp__:andytoshi: but no, i don't feel comfortable making economic judgments:(
17:24:03phantomcircuit:tromp__, http://www.digikey.com/product-search/en?vendor=0&keywords=MT42L256M64D4EV-18+WT
17:24:15phantomcircuit:$24.60 per 16GB module
17:24:27andytoshi: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:42dsnrk:gmaxwell: right, so in bitcoin that's dwarfed by other latencies. makes sense.
17:25:14tromp__:phantomcircuit: that's pretty competitive. i paid $300 for 32GB in my imac
17:25:47gmaxwell:andytoshi: the complex network-economic question in the memory hard case is the shift in costs between upfront and ongoing.
17:25:55phantomcircuit:tromp__, yeah these come in tubes or trays not as a ddr3 module
17:26:08phantomcircuit:the ddr module doubles the cost
17:26:15phantomcircuit:or actually
17:26:17phantomcircuit:adds about 25%
17:26:30phantomcircuit:then the retail supply chain adds another 25-50%
17:26:38phantomcircuit:and you have doubled the price per GB
17:26:44andytoshi: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:14phantomcircuit: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:38phantomcircuit:which would be
17:27:48dsnrk: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:54phantomcircuit:$0.75/GB vs your macs $9.375/GB
17:28:02phantomcircuit:approximately a 10x price reduction
17:28:07phantomcircuit:which was my first guess
17:28:21andytoshi:dsnrk: ugh :(
17:28:32phantomcircuit:that being said
17:28:39gmaxwell: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:43tromp__: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:58phantomcircuit:* phantomcircuit goes off designing his pow machine
17:29:09dsnrk:andytoshi: $600,000 worth of botnet mined on embedded hardware :\
17:29:26gmaxwell:At a minimum it's better than the memory hard crap which is memory hard in the verifer. :)
17:29:47dsnrk:andytoshi: er, $600k worth of dogecoin mined on embedded hardware.
17:30:16gmaxwell:tromp__: Have you given any though to efficiently making your approach dataset-hard too?
17:30:33andytoshi: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:41tromp__:gmaxwell: what is dataset-hard?
17:31:14gmaxwell: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:16phantomcircuit:andytoshi, how little ram do you have that every meg matters o.o
17:31:57gmaxwell: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:05andytoshi: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:17tromp__:gmaxwell: you can change the random graph definition to incorporate fragments of a data set into the siphash fuinction
17:32:25andytoshi:(but i guess even with 4gb i don't notice individual megabytes)
17:32:31phantomcircuit:andytoshi, nom nom 32GB of ram laptop
17:32:43dsnrk:andytoshi: wow, I run into SWAP even with 16GB :(
17:32:57phantomcircuit:dsnrk, o.o
17:33:04dsnrk:swap is not a acronym.
17:33:16tromp__:gmaxwell: in fact i proposed that on one of the ethereum blog articles
17:33:21phantomcircuit:swap is entirely empty with 32gb of ram
17:33:41gmaxwell:tromp__: it's an old idea— I just wondered if you'd considered it in the context of your system.
17:33:51phantomcircuit:MemFree: 29121872 kB
17:33:53andytoshi:can i do 32gb? is there an easy way to check my mobo's max, i'm worried it might be 16..
17:33:59dsnrk:phantomcircuit: 16GB total, 400MB into swap
17:34:15phantomcircuit:dsnrk, that might be 400MB of stuff that's entirely idle
17:34:22tacotime: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:28dsnrk:andytoshi: very mobo specific
17:34:29tacotime:I guess you get a lot of free full nodes, though.
17:34:29phantomcircuit:lots of programs have startup stuff they do which they never free
17:34:36phantomcircuit:it gets swapped out and never swapped back in
17:34:37gmaxwell: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:44tromp__: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:58phantomcircuit:andytoshi, need model numbers
17:35:34gmaxwell: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:52dsnrk: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:01dsnrk:phantomcircuit: oh and testnet3 in a ramdisk.
17:36:09gmaxwell: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:14phantomcircuit:lol redis
17:36:17phantomcircuit:shoot it in the face
17:36:21phantomcircuit:redis is ridiculous
17:36:27phantomcircuit:5GB on disk db
17:36:32phantomcircuit:45GB in ram
17:36:38dsnrk:* dsnrk shrugs
17:36:39gmaxwell:(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:45phantomcircuit:effectively zero garbage collection of removed keys
17:37:14phantomcircuit:gmaxwell, that is hilarious
17:37:14dsnrk:not using it for anything serious, not a problem.
17:37:28gmaxwell: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:49gmaxwell:so a function that shows you have the state required to mine is perhaps interesting.
17:38:34Eliel:frankly, I'm surprised I haven't heard of a coin with that kind of PoW yet
17:38:44gmaxwell: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:44dsnrk:Eliel: boolberry.. tried.
17:38:50phantomcircuit:gmaxwell, invalid soft forks seems like a reasonable solution to that though
17:38:57gmaxwell:Eliel: boolberry is ... kinda like that.. but they really didn't do it well.
17:38:59phantomcircuit:requires someone who cares enough to do it
17:39:01phantomcircuit:but eh
17:39:12dsnrk: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:16gmaxwell:Since they seem to have sought to preserve mindless miners, kinda of the worst of all worlds.
17:39:31Eliel:dsnrk: how big of a nonce?
17:39:53dsnrk:don't know, big enough that the miners can mine over stratum
17:39:58gmaxwell:Eliel: the real important point is that there are already pools for it with mindless miners.
17:40:16Eliel:yeah, that's a problem
17:40:19tacotime: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:34gmaxwell:I told them too.
17:40:42dsnrk:tacotime: it doesn't matter. it works enough for the pump and dump.
17:41:03gmaxwell:I also suggested a better facility than their minimum mixin flag.
17:41:42zooko:Hi folks!
17:41:46tacotime: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:12dsnrk:checkpoints as a security feature \o/
17:42:14gmaxwell:(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:24zooko: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:34zooko:Do you have a pointer to the best ideas along those lines, if any?
17:42:54tromp__:i'm being ultra conservative with my 42 cycle length; perhaps length 8 could be similarly tmto hard
17:43:05zooko: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:25Eliel: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:35Eliel:one with 9
17:43:39gmaxwell:zooko: it's probably impossible or at least very hard to make such a thing which is convincingly approximation free.
17:43:50zooko:* zooko nods.
17:44:04Eliel:(dang, typoed enter before was finished with editing the line)
17:44:23gmaxwell: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:32zooko: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:39gmaxwell:Perhaps I can even rapidly detect if any particular challange will be wrong and terminate extra fast.
17:44:43zooko:gmaxwell: yeah.
17:45:30zooko: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:44gmaxwell: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:10zooko: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:25zooko:gmaxwell: Yes.
17:46:37gmaxwell: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:40zooko:gmaxwell: as you know, I think Bitcoin is prone to centralization of mining.
17:47:00zooko:gmaxwell: and like you suggest, I think that reducing the marginal efficiency gained from capital investments could help.
17:47:09tromp__:zooko: some phones have more cores (8) than my brand new 27" imac (4)
17:47:15zooko:Could you please give me a link to that paper?
17:47:22zooko:tromp__: good point.
17:47:27gmaxwell:zooko: https://download.wpsoftware.net/bitcoin/asic-faq.pdf
17:47:29tromp__:so they could do a small size cuckoo cycle reasonably well
17:47:59maaku:So I have a UTXO related question that perhaps someone can help me with.
17:48:02zooko: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:10zooko:Hi maaku! Nice to IRC you again.
17:48:13maaku: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:15maaku:hi zooko
17:48:30tromp__:the advantages are right on the github page in the README
17:48:33maaku: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:49gmaxwell:it's only an issue for level compression
17:48:55maaku: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:20maaku:gmaxwell: yeah i'm having trouble recreating that issue though
17:49:42gmaxwell: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:22maaku:but you would have that wouldn't you? the inner branch which disappears has the hash which would be propagated upwards
17:54:53gmaxwell: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:09zooko: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:21zooko:But why can't custom-designed single-purpose hardware have good memory latency?
17:57:29maaku:so let's assume two keys: 00000000 and 00001111. that results in [root -> 0000 -> (0000, 1111)]
17:57:41maaku:so the inner node has hashes for both 0000 and 1111
17:58:04maaku:when you say "graft on a neighboring one" you mean the other branch not deleted right?
17:59:17maaku: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:27tromp__:zooko: because making memory cheap forces you into existing dram technology, which incurs such latencies for random access
18:00:17tromp__:zooko: of all PoWs, cuckoo cycle does by far the least amount of computation per random global memory access
18:00:41maaku: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:26maaku:i remember we were convinced earlier, i just can't figure out what it was
18:01:29gmaxwell:maaku: hm. maybe the issue was on an insertion then?
18:01:34maaku:maybe if there are multiple insertion deletions...
18:01:36gmaxwell:yea. I don't remember the specific case. :-/
18:01:55zooko: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:09maaku:i mean it's a 10x performance hit, so I want ot be extra sure it's actually necessary
18:02:19zooko:In "4.
18:02:19zooko:Is memory hardness desirable?"
18:02:56tromp__:zooko: they consider smaller amounts of ram, where sram technology makes sense
18:03:35tromp__:zooko: a GB of sram would be 10x faster but 100x more expensive than DRAM
18:04:00zooko:tromp__: that's consistent with that asic-faq.pdf claims.
18:04:34zooko:Today 1 GB of DRAM on a stick costs...
18:05:07zooko:I wonder how much it adds to the cost (size) of an ASIC to add 1 GB SRAM to it.
18:06:01tromp__:zooko: it might increase the cost 100x?
18:06:04gmaxwell:SRAM? a lot... and a lot of power usage.
18:07:14gmaxwell: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:56zooko:gmaxwell: oh, DRAM built into the ASIC? Or more like commodity DRAM connected to your ASIC with a bus of some kind?
18:08:14zooko:tromp__: I meant in concrete terms. I mean, 100 * what?
18:08:16gmaxwell:either or are possible.
18:08:20zooko:* zooko nods.
18:08:32gmaxwell:(see also the edram stuff now becoming possible in embedded systems)
18:08:43gmaxwell:er s/possible/popular/
18:09:08tromp__:zooko: 100 times cost of your ASIC without any memory
18:10:26tromp__:it's very hard to find SRAM memory chips in decent sizes (more than a fwe MB)
18:10:56dsnrk: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:40dsnrk:(sort of related, I just watched their roadmap video before and found it interesting)
18:14:39zooko:tromp__: okay, thanks.
18:15:49zooko: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:18tromp__:ah, the minephone
18:17:27dsnrk:zooko: wouldn't you get huge hashrate fluctuations with that?
18:17:31tromp__:also comes with a copy of minecraft pre-installed:)
18:17:54nsh:not if we rearrange the continents a bit
18:18:04dsnrk:that'll work!
18:18:07nsh:* nsh smiles
18:18:51tromp__:zooko: note that smartphone OS usually have low per-process memory limits...
18:19:06zooko:How low?
18:19:20dsnrk:are iphones still 1GB total?
18:19:39tromp__:zooko: dunno. maybe 16MB or so?
18:20:02dsnrk:yep. 1GB DDR2.
18:20:03tromp__:zooko: just dont assume they can use all the RAM
18:20:21zooko:tromp__ thanks for the note.
18:21:12tromp__:zooko: then again, the OS itself might be unlimited, so if you can make mining OS-native...
18:23:56zooko:<- "Recent devices (e.g. the Nexus 4) cap the heap size at 96MB or more."
18:24:29tromp__:that's enough for a decent-size cuckoo cycle
18:25:24zooko:Yeah, so a memory-hard function is a pretty good candidate for my purposes.
18:25:32zooko:And cuckoo-PoW is a pretty good memory-hard function.
18:25:52tromp__:keeps the phone from overheating
18:26:02zooko:Good point!
18:26:13hearn:bear in mind you don't get to use all 96mb
18:26:17hearn:the OS takes up some as well (per process)
18:26:47zooko:Ah, thanks.
18:26:54zooko:Hiya, hearn. How's life?
18:27:02hearn:hey. not bad! enjoying the summer :)
18:27:08hearn:how about for you?
18:27:09tromp__:cuckoo cycle at 2^29 vertices runs in 64MB
18:27:33zooko:Life is very busy for me! But great.
18:27:42zooko:I'm acting in the role of single dad for 2 or 3 of my boys all summer.
18:27:47zooko:Since my wife went away to Hacker School in New York.
18:27:51zooko:(We're in Boulder, Colorado.)
18:27:58zooko:Which is super awesome but business-inducing.
18:28:10zooko:I'm running this secure storage startup -- https://LeastAuthority.com.
18:28:22zooko:We announced the first upgrade of our secure storage service a couple of weeks ago.
18:28:54hearn:you have a hacker wife? awesome :)
18:29:09hearn:yes, i've seen least authority, very cool stuff
18:29:12zooko: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:24zooko:Then while I was dealing with that, my *backup* laptop died... :-)
18:29:27zooko:So, it has been quite a ride.
18:29:32hearn:sorry to hear that. sounds like my lovely anti-hacking system didn't work :(
18:29:44hearn:where by "my" i mean "me and my old teams" of course ...
18:29:47zooko: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:47tromp__:busy times for Murphy...
18:29:51zooko:hearn: right.
18:29:54dsnrk:anti hacking system?
18:30:06zooko:tromp__: I actually hypothesize that they chose that day to strike because I had published about my main laptop locking me out.
18:30:08hearn:all google logins are risk analysed and subjected to a weak form of ID verification if they're considered risky
18:30:19zooko:Since it turns out they had access to at least one of our gmail accounts for about 6 weeks.
18:30:25hearn:but it can't stop skilled and determined attackers. it's meant to interfere with bulk operations
18:30:36zooko:hearn: we are still investigating, and it is a confounded mystery.
18:30:37hearn:right. if you were specifically targeted, that's what 2-step is for
18:30:42dsnrk:hearn: ha, yeah I'v been caught by that a lot of times (on my own accounts)
18:30:46zooko:hearn: one hypothesis is that they have a 0-day against google. ;-)
18:30:58zooko:A more likely hypothesis is that they compromised two independent laptops of our team.
18:31:01hearn:possible! but rare.
18:31:11hearn:right. or someone fell for a phishing scam, etc
18:31:17dsnrk:cloudflare was a google 2fa 0day wasn't it?
18:31:20zooko: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:20hearn:a good phish can take out even skilled sysadmins
18:31:37zooko:Yes, that's a good hypothesis. We can't find evidence of it yet. :-(
18:31:41dsnrk:zooko: checked your recovery email? setting it to an old hotmail account seems to bite everybody.
18:31:52zooko:I mean, not to brag, but our team are pretty exceptionally skilled.
18:32:00zooko:So, it is both humiliating and mysterious.
18:32:13hearn:yes, but security is hard.
18:32:29zooko: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:34hearn: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:49zooko:Hence, they either hacked google itself or hacked those two people's personal computers.
18:32:55zooko:That's as far as we've gotten in our investigation. :-(
18:33:05dsnrk:zooko: waterhole attack?
18:33:06zooko:I mean not stored/saved/written anywhere.
18:33:28zooko: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:45nsh:can you image the personal computers
18:34:09zooko:Oh, and when I was listing reasons that I am super busy
18:34:16zooko:oh yes and by the way my wife is awesome, thank you very much,
18:34:19nsh:* nsh smiles
18:34:24zooko: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:33zooko:So I spend a lot of time thinking and writing about that.
18:34:44zooko:s/inventing/implementing and deploying/
18:34:51dsnrk:zooko: I'd be reimaging or selling all of the hardware and buying new stuf, maybe a bit over the top though.
18:35:10zooko:Yeah, we've done the latter step.
18:35:21zooko:I mean, we bought some new hardware.
18:35:36zooko:But, I'd really like to have a better understanding of what happened.
18:36:12dsnrk:seems like a long way to go to get to a coinbase account
18:36:21zooko:Yeah, that's what is creeping me out about it.
18:36:33dsnrk:surely there's lower hanging fruit than a company that's meant for security
18:36:39zooko:Is that I expect such things to be mostly-automated, or operated by low-skilled workers, and going for
18:36:50zooko:widely understood payoffs, such as domain name ransom.
18:37:15zooko:I *guess* someone could have gotten the idea from my public image that I was holding a big stash of Bitcoin.
18:37:19zooko:But... I dunno.
18:37:20nsh:they didn't gain access to coinbase then?
18:37:31zooko:They did not, because it had 2FA that they couldn't answer.
18:37:36nsh:great :)
18:37:58zooko: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:07nsh:it's a shame you can't (i presume) see what else they did with the gmail accounts
18:38:14dsnrk: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:21nsh:it'd be nice if you could keep a history of that for auditing
18:38:24gmaxwell: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:35zooko:dsnrk: I've never deliberately given the impression that I have a lot of Bitcoin, I don't think.
18:38:43nsh:* nsh nods
18:38:47zooko:But I've been talking about it, including talking about buying/trading/spending it, for many years, in public.
18:38:49helo:gmaxwell: already done :D
18:38:52zooko:gmaxwell: we did that.
18:39:01dsnrk:gmaxwell: I set up a nice honeypot just before with something similar :)
18:39:03zooko:gmaxwell: they didn't take the canary coins from the laptop.
18:39:08zooko:So, either they FORGOT TO LOOK
18:39:14zooko:or they used a 0-day against google instead of compromising that laptop.
18:39:16zooko:Or... ??
18:39:20zooko:Burglars are just weird?
18:39:22helo:in time it will become more effective
18:39:41zooko:nsh: yes, that kind of audit trail would be super helpful. Google has it. We don't.
18:39:52nsh:* nsh nods
18:39:53dsnrk:gmaxwell: bitcoind listening on mainnet + weak root password + RPC open + SSH honeypot. lets see what we catch :)
18:39:56nsh:wonder what they'd do if you asked...
18:39:59zooko:nsh: we've asked for the google investigations team to work with us, and are waiting to hear back.
18:40:15nsh:maybe dangling the idea that the compromise might be of them will get you some traction
18:40:37zooko:I would assume that they will think we are wrong to suggest that. :-) And we probably would be wrong to suggest that.
18:40:53nsh:allusion > suggestion :)
18:41:07gmaxwell: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:15zooko:Yeah, we made it clear what we know. They ought to understand that.
18:41:23gmaxwell:then again I dunno why they would have if they let you know via the account access.
18:41:38dsnrk:wouldn't they be better off taking the wallet canary then stealing the coins after they got busted?
18:41:44zooko:They outed themselves in order to attempt access to coinbase.
18:41:47dsnrk:suggests more the coins weren't the target at all.
18:41:49zooko:Which failed.
18:41:57zooko:So, it is creepy/.
18:42:09zooko:And they didn't take the canary coins.
18:42:34dsnrk:did you move the canary coins after compromise?
18:42:42zooko:Can't say.
18:43:33gmaxwell: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:46dsnrk:hope the google team gets back to you, otherwise that's one creepy attack.
18:43:47zooko:Right. :-(
18:44:13dsnrk:were the compromised email addresses public? could I find them on a WHOIS or google search?
18:44:29zooko:dsnrk: yes. nathan@LeastAuthority.com and zancas@LeastAuthority.com.
18:44:52zooko:Then they used google admin privs to reset the password of jessica@LeastAuthority.com, which was associated with our coinbase account.
18:44:59nsh:how did you surmise one was compromised for 6 weeks btw?
18:45:19dsnrk:google mail has a public log of IP addresses, guessing that showed up
18:45:20zooko: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:25zooko:Then they reset zooko@LeastAuthority.com's password.
18:45:56zooko:nsh: unexplained logins to zancas@LeastAuthority.com's google account starting in late May, not noticed until now.
18:46:27dsnrk:zooko: you know, neither of those email addresses are very public. there's less than a page of results each.
18:46:37zooko:dsnrk: good point.
18:46:52zooko:There was a recent attack which allowed enumeration of gmail address, IIUC.
18:46:56zooko:I mean recently published.
18:47:05nsh:read it yesterday
18:47:18nsh:also linked to another piece about full account compromise, which i'm looking for
18:47:27nsh:.t http://blog.spiderlabs.com/2014/06/from-a-username-to-full-account-takeover.html
18:47:41zooko:* zooko looks at http://blog.spiderlabs.com/2014/06/from-a-username-to-full-account-takeover.html
18:48:06nsh:summary of vectors
18:48:34zooko:* zooko nods.
18:48:48dsnrk:zooko: that feels unlikely, manually searching a bunch of names and getting "zancas" at your domain would be pretty improbable.
18:49:17zooko:dsnrk: hm
18:49:47dsnrk:if you were going to target leastauthority.com it's easier to find them in your github account.
18:50:11zooko:Oh, yeah.
18:50:28zooko:Well, thanks for lending a sympathetic ear.
18:50:32zooko:I need to go for a bit.
18:50:39dsnrk:hope you get some answers o/
18:50:56zooko:Oh, and did I mention my car battery went dead and my watch stopped? :-)
18:50:59zooko:Thanks, dsnrk!
18:51:01zooko:Bye for now!
20:18:32dsnrk:ahhhh why do these batty ideas keep getting to large audiences :C
20:20:02dsnrk:"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:48phantomcircuit:dsnrk, i got a really nice laugh out of that one
20:28:26phantomcircuit:dsnrk, his plan would make all mining solo mining, which would basically guarantee an oligopoly
20:31:28dsnrk:phantomcircuit: I like that it's described as just a few lines of changes too :C
20:32:05jcorgan:gavin just tweeted amiller's preprint
20:34:24dsnrk:is that a good thing?
20:35:01jcorgan:i have no idea. just quickly browsed through it and it is beyond my skillz
20:35:15jcorgan:but istr it was discussed in here, controversially
20:36:05dsnrk:yeah I'm going to need andy or gmax to explain this one to me.
20:39:47dsnrk:nothing like an academic paper citing blockchain.info's charts, which are totally useless and inaccurate for the most part
20:44:17phantomcircuit:dsnrk, tl;dr non-outsourcible puzzles, not practical currently as the variance would be far too high for individual miners
20:44:33phantomcircuit:providing a solution for variance is part of "future work"
20:44:40phantomcircuit:amiller, that's cheating :P
20:46:26maaku: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:47:15phantomcircuit:maaku, are those parameters generated once?
20:47:23phantomcircuit:if so im sure a social solution would be possible
20:47:53phantomcircuit:although i personally would not want to be involved, the conspiracy theories would be extensive and ridiculous
20:48:32maaku:yes they are generated once, but no I don't think any social solution is possible
20:48:47dsnrk: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:07maaku: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:20phantomcircuit:maaku, sure it is, at the next conference we get a hundred people to walk to a random computer shop
20:49:21phantomcircuit:buy a computer
20:49:25phantomcircuit:generate the parameters
20:49:29phantomcircuit:smash the computer into bits
20:49:42phantomcircuit:social solution
20:49:52dsnrk:exporting the bits is the issue, how do you get them off? how do you prove the secrets weren't exported too?
20:49:58maaku:that wouldn't even come close to satisfying me
20:50:36maaku: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:52phantomcircuit:dsnrk, reams and reams of paper and smash the printer also
20:50:59phantomcircuit:then have some poor shlub sit there for a month scanning them back in
20:51:11maaku: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:31dsnrk:phantomcircuit: how do you know the secrets weren't compromised and made to be deterministic?
20:53:50phantomcircuit:dsnrk, have the problem on some read only media which is available for inspection
20:54:13phantomcircuit:basically what you're worried about at that point is someone pulling off some crazy giant magic trick type stuff
20:54:17zooko: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:06dsnrk: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:42maaku: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:18maaku: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:45zooko:maaku: hm, I think there's a way to do this without standing on a turtle.
20:59:01zooko: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:26zooko:maaku: another perspective on that is, could we have ex post facto detection of counterfeiting?
20:59:32zooko:If that detection were good enough, it would probably deter counterfeiting.
21:00:12maaku:zooko: if you could design such a prototypical setup, it would be a very good thing
21:00:25maaku:this has implications for things like zerocash as well, which suffer the same problems
21:00:50maaku:but regarding ex-post-fact detection, that would violate the zkp condition
21:02:30dsnrk: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:15phantomcircuit:dsnrk, probably, is it motivation enough to do so without getting caught?
21:04:18phantomcircuit:i doubt it
21:05:47maaku:dsnrk: for state level actors? certainly
21:06:08zooko: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:58phantomcircuit:lol that stupid selfish mining guy
21:07:03zooko: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:06phantomcircuit:he's just smart enough to say things that sound smart
21:07:10phantomcircuit:but not smart enough for them to be smart
21:07:49maaku: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:14maaku:which would let you mint a block in the non-outsourceable puzzle setup
21:23:54Burrito:Burrito is now known as Burrito_
21:24:31Burrito_:Burrito_ is now known as Burrito
21:45:40amiller:fuck i'm totally pissed that gun sirer is beating me to the punch with his blogpost...
21:45:40amiller: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:50maaku:amiller: well gun's blog post isn't even a progress-free construction
21:54:37tromp__:maaku: how is it not progress-free?
21:55:18tromp__:each header only has one SHA256d and one SIG?!
22:02:08maaku: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:18maaku:tromp__: you have to mine the signature
22:02:47maaku:so mining is two stages: mine the SHA256d proof of work, then mine the digital signature proof of work
22:02:57maaku:that is not progress free
22:06:08tromp__:you're not mining the SIG, you're computing one SIG and one more SHA256d, that are tied to the same header.
22:07:16tromp__:if that fails you have to restart from scratch
22:09:03maaku:tromp__: that's not what the blog post is about
22:09:43maaku:or rather, that's not how the scheme actually works
22:10:42maaku:since ECDSA is trivially malleable, and undetectably so
22:12:35maaku: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:10tromp__:then i stand corrected, misled by the author's use of "the hash (SHA256(SIG(header, privkey)))" rather than "a hash"
22:13:45tromp__:how much entroyp is in the choice of sig?
22:14:11gmaxwell:if you konw the private key? 256 bits.
22:14:17gmaxwell:if you don't, one bit.
22:15:36tromp__:so the author unwittingly proposes changing the PoW from SHA256d to SHA256(ECDSA())
22:15:55gmaxwell: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:18tromp__:so much for "preserves the current investment in Bitcoin ... by existing miners"
22:19:02maaku:gmaxwell: well there's RSA
22:20:06maaku:but in this post he is talking about using "the coinbase transaction's private key" (sic) which presumably means ECDSA
22:20:46gmaxwell:maaku: hm. point. RSA sigs with determinstic padding are determinstic.
22:20:53maaku:although I suppose you could stick an RSA pubkey in a miner commitment and use that
22:21:48maaku:amiller's point actually, he pointed out RSA in a comment
22:22:00gmaxwell:maaku: you can derandomize dsa in that context.
22:22:07gmaxwell:commit to the nonce.
22:23:56maaku:or set the nonce by convention
22:24:05gmaxwell:you can't without compromising the private key.
22:24:14maaku:one-off private key
22:24:18dsnrk: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:30maaku:but yeah either way would work
22:25:02maaku:what do you mean then by commiting to the nonce without revealing it?
22:26:42gmaxwell: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:03maaku:i see
22:29:00gmaxwell:maaku: just from what was said here I assume he's making the proposal that the POW be something like H(header)
22:29:40tromp__:with diffferent targets X and Y that allow for smooth transition
22:30:09maaku:gmaxwell: yes
22:31:35gmaxwell: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:34gmaxwell: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:06maaku:thinking about it some more, i'm not sure it accomplishes the goals he sets out either
22:33:20gmaxwell:it's especially ironic to talk about things that encourage hosting by killing pooling in the context of ghash.io.
22:33:28maaku:e.g. it doesn't where where the pool pays miners in the coinbase, which is recommended behavior
22:34:20maaku:pooling is highly beneficial. centralized transaction selection is not. and these can or should be orthogonal
22:34:34dsnrk: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:41gmaxwell: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:15gmaxwell:yea, solving the wrong problem. Kills pooling for payment variance reduction, does nothing for centeralized transaction selection.
22:35:20maaku:gmaxwell: right. it necessitates poor practices and needless centralization
22:35:36gmaxwell:only except hoping that if you can't pool for variance reduction you won't do centeralized transaction selection.
22:35:49gmaxwell:which is an open question.
22:36:08gmaxwell:I think the obvious answer is that it completely kills decenteralized mining entirely and forces pratically all mining into cloud operations.
22:36:20gmaxwell:* gmaxwell waits for phantomcircuit's full and vigorous support of the proposal
22:37:28maaku:why aren't the hacking distributed people vetting their ideas on wizards first? grrr
22:37:51gmaxwell: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:22gmaxwell:Because a voice of reason would compromise their ability to make unjusitified claims with a straight face?
22:38:30dsnrk:maaku: you're getting caught up in the small details.
22:38:33gmaxwell:This way enormous resources must be expended in a political battle.
22:39:28dsnrk: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:35gmaxwell: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:43:48gmaxwell: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:29gmaxwell: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:42andytoshi: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:43andytoshi: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:14zooko:I'm planning to start a new cryptocurrency.
22:53:29zooko:I would listen with intense interest and respect to any ideas you two have on the topic.
22:53:43zooko:Um, not RIGHT NOW, I mean -- it is time to go home and feed my children dinner. :-)
22:54:13zooko: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:20andytoshi: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:46zooko:andytoshi: did you see what we were saying earlier about a secure-multiparty-computation for the trusted setup?
22:55:00zooko:That sounds difficult/expensive/complicated, but it is my current favorite path forward.
22:55:01andytoshi:yeah, but that's nowhere near feasible
22:56:05andytoshi: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:56gmaxwell: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:05zooko: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:04zooko: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:35gmaxwell: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:37maaku: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:59zooko:maaku: I know.
23:00:01andytoshi: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:07maaku:otherwise many (myself included) will take pains not to share info
23:00:20andytoshi: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:28andytoshi:and there are extremely few of those
23:00:30zooko:maaku: well I'll do my best to explain why I think it is valuable, and I hope you choose to share.
23:00:40zooko:But first: make dinner for kids. :-)
23:00:43zooko:Bye for now folks!
23:01:00gmaxwell: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:29gmaxwell:andytoshi: those failure modes are design flaws though, I mean, it's a bug that it (currently) requires people at all.
23:01:35maaku:kids are more important :)
23:02:47phantomcircuit:* gmaxwell [22:36:20] waits for phantomcircuit's full and vigorous support of the proposal
23:03:15gmaxwell: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:16andytoshi: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:45phantomcircuit:gmaxwell, i have no need for trickery, we're genuinely better at this than the competition :P
23:03:48gmaxwell:andytoshi: well you can just do it a bunch of times with different people and one will survive by chance.
23:03:49andytoshi: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:53gmaxwell:(The silicon valley model)
23:04:03andytoshi:gmaxwell: mm, yeah :(
23:04:37maaku:andytoshi: if you created a new currency, you fucked up at that step
23:04:58maaku:(modulo exceptional footnote cases, which i am guilty of)
23:05:02andytoshi:maaku: almost certainly, yeah
23:05:04dsnrk:altcoins are pretty much in the startup mentality. make the minimum viable product and see if it sticks.
23:05:22dsnrk:if it doesn't, it wasn't your money that got burnt in the process.
23:05:40gmaxwell:it can fail amazingly and still make you a huge profit even.
23:05:52gmaxwell:Sadly they're not good science, since we can't even usually tell why things break.
23:06:35dsnrk: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:56andytoshi: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:02andytoshi:i gtg as well. but be happy everyone
23:07:13dsnrk:andytoshi: take care o/
23:09:41dsnrk:gmaxwell: you too. don't let yourself get too burnt out.
23:10:08gmaxwell:I'm okay, the ordinarily ignorant people are just a lot easier to deal with.
23:10:24gmaxwell:Since the only thing against curing that is a bit of ego and inertia.
23:11:12gmaxwell: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:55gmaxwell: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:41dsnrk:yes, it would. as soon as that happens bitcoin developers are "competition" seen as hostile.
23:12:46gmaxwell: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:03gmaxwell:I don't feel comfortable with that sort of thing.
23:15:14gmaxwell: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:51dsnrk: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:40dsnrk:can't say if that's because people point out obvious flaws or if they just never go anywhere.
23:17:03gmaxwell: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:43gmaxwell: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:21Eliel: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:04gmaxwell: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:11gmaxwell:If we could prove it was correct we wouldn't need mining...
23:19:36gmaxwell:even knowing after the fact that doom happened is little consolation.
23:19:41Eliel:I think PoS works for short term.
23:19:47Eliel:just not for long term
23:20:09dsnrk:gmaxwell: that looks incredibly interesting. I half expected it to be a gag product, but nope, real :)
23:20:19Eliel:and then there's this entangled logs thing.
23:20:25gmaxwell:dsnrk: it's a little immature as a product.
23:22:02gmaxwell: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:27dsnrk:gmaxwell: for me half the game would be finding somebody willing to endure such a concept :P
23:22:28tromp__:gmaxwell: the irony of this game being published prematurely:)
23:23:33gmaxwell: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:00gmaxwell:gwillen played it too (gwillen is local to me).
23:27:04dsnrk:oh well if you have bitcoin people around you've already cheated on the first part (finding anybody else willing to play)
23:28:14gmaxwell:that one isn't an issue, at all— one of the benefits of living here.
23:28:48Eliel: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:05Eliel:that way, pools can function without actually having access to the capital, just the right to mine with it
23:29:43gmaxwell:Eliel: yes, and then you start to lose the arguments that stake = an economic interest in the currency. :)
23:30:08gmaxwell:which was one of the arguments for that class of scheme in the first place.
23:31:32Eliel: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:37gmaxwell: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:38Gnar:Where can I buy cocaine with shitcoins?
23:33:41gmaxwell:(for a year)
23:34:01gmaxwell:gmaxwell has kicked Gnar from #bitcoin-wizards
23:35:11gmaxwell:[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:32nairb:heh... Gnar is now bragging about his trolling over in efnet #stocks..
23:35:37gmaxwell:[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:48catcow:what logging bot do you use in this channel?