| 02:18:30 | vfor: | guys, how about changing the mining algorithm since over 50% of the asic chips get produced under a totalitarian regime? |
| 02:28:51 | Luke-Jr: | vfor: you're talking to the wrong people |
| 02:29:14 | Luke-Jr: | vfor: you need to convince the entire community, or at least an economic majority. |
| 02:29:18 | Luke-Jr: | not developers |
| 02:33:52 | dsnrk: | vfor: you've also got to somehow convice people that the security of a few people with GPUs is better than the 10PH of sha256d we have (it's not!) |
| 02:34:21 | dsnrk: | sorry, 100PH/s. |
| 02:36:10 | Luke-Jr: | dsnrk: no, we aren't reduced to GPUs even with an algo change. |
| 02:36:38 | dsnrk: | I know the whole alternate sha256d thing, but even that is a ridiculous reduction. |
| 02:36:46 | Luke-Jr: | not really |
| 02:37:02 | Luke-Jr: | if only bitfury-based hardware goes offline, we still have quite a bit |
| 02:37:13 | dsnrk: | bitfury hardware makes up a fair portion of the network. antminer stuff alone is a good tens of a percent. |
| 02:37:30 | dsnrk: | tens of percents? |
| 02:37:33 | Luke-Jr: | Antminer isn't bitfury |
| 02:37:46 | dsnrk: | they're the same silicon though right? |
| 02:38:08 | Luke-Jr: | not sure that's known |
| 02:38:20 | dsnrk: | different packaged chips I realise, but the performance is identical. |
| 02:39:03 | dsnrk: | anyone got a spare same of both to be decapped? :) |
| 02:39:11 | dsnrk: | *spare sample. |
| 03:01:10 | wyager: | wyager has left #bitcoin-wizards |
| 09:39:33 | [nsh]: | [nsh] is now known as nsh |
| 09:39:50 | nsh: | nsh is now known as [nsh] |
| 10:27:46 | fanquake: | fanquake has left #bitcoin-wizards |
| 12:59:06 | jgarzik: | jgarzik is now known as home_jg |
| 16:55:41 | sl01: | adam3us: is this solve 51% attack with SNARKS stuff something new ? |
| 16:56:47 | sl01: | re your partner: "allows ZNARKS and use of well pairing constructs to allow for levels of security that solve the 51% attack issues" |
| 16:58:22 | phantomcircuit: | sl01, i believe it does, but ZSNARKS is bleeding edge crypto |
| 16:58:33 | phantomcircuit: | as in the odds that you get cut are pretttty close to 1 |
| 17:00:05 | sl01: | yea i understand what it is and that it's bleeding edge but I wasn't aware of how it could mitigate a 51% atatck though |
| 17:01:24 | phantomcircuit: | magic |
| 17:01:29 | phantomcircuit: | (i dont either) |
| 17:01:39 | adam3us: | sl01: not in a general sense but in the side-chain sense. it can elevate SPV to full node security view. magic indeed. |
| 17:02:06 | adam3us: | sl01: its not new. gmaxwell (where is he last few days?!?) said this some time ago. |
| 17:02:10 | sl01: | adam3us: ah ok, well i do get how that part works, thx! |
| 17:06:36 | jtimon: | there's a version with unilateral withdrawals from the sidechain, but the full proofs may be too long without snarks and bitcoin's scripting would need to undesrtand the sidechain's scripting so without snarks again doesn't seem very generic |
| 17:07:08 | jtimon: | though it could be useful for two way peg between an intermediary sidechain and a private chain |
| 17:08:26 | jtimon: | so yep, snarks is last-resort magic |
| 17:09:08 | jtimon: | as sipa says, "bitcoin is a gateway drug to snarks", anyway |
| 17:25:37 | andytoshi: | weird, always thought of snarks as a gateway to drugs.. |
| 17:25:41 | andytoshi: | ;) |
| 17:27:06 | austinhill: | sipa: mentioned that snarks are a gateway to drugs, but we checked with Prof @ stanford on the math : he verified that the constructs for well pairing EC crypto are secure but he wouldn't bet his liife savings on snarks so I guess they are drugs that you are risking your financial future with |
| 18:24:37 | licnep_: | licnep_ is now known as licnep |
| 18:25:32 | adam3us: | sl01: also i think they might've slightly misquoted or confused two questions. one was is weil pairing secure (and the prof says yes, though note he co-invented them:) and the relevance for that was two fold their optional use in snarks (there are other mechanisms) and the IBE addresses that i propose a while back. |
| 19:14:35 | maaku: | adam3us: gmaxwell has decided this channel is now too low SNR, I guess |
| 19:15:30 | maaku: | sl01: automatic 2-way pegging only has SPV security by itself, but nothing precludes combining that with other mechanisms |
| 19:16:09 | maaku: | e.g. a threshold signature (now stealing funds requires 51% AND trusted party collusion) |
| 19:17:12 | maaku: | or a SNARK signature validating the external chain (now stealing funds requires 51% AND the CRS for the SNARK) |
| 19:17:44 | maaku: | these can be combined, e.g. threshold-SNARK (require 2-of-2 proofs using proving keys generated by competiting entities) |
| 19:19:45 | jtimon: | what do you mean "AND trusted party collusion"? |
| 19:19:48 | maaku: | SNARKs have interesting properties here because they are censorship resistant -- you can't stop an honest person from making a SNARK proof verifying an honest withdrawal |
| 19:20:50 | maaku: | jtimon: that scenario involved some threshold-signature N-of-M scheme using trusted third partiess |
| 19:21:16 | maaku: | who only sign off on pegging transactions that follow chain rules |
| 19:21:58 | maaku: | what is interesting about SNARKs is it is basically a delegated signature |
| 19:22:42 | maaku: | you know that a valid SNARK proof was either (a) created by the person who setup the paramaters, or (b) created by someone who followed the specified rules |
| 19:23:58 | maaku: | so threshold-SNARK combines the two: it is censorship resistant because anyone can compute a proof for a valid program+inputs (e.g. an honest chain in this case), or by getting ALL of the SNARK parameter selection entities to collude |
| 19:38:51 | jtimon: | I see, sacrificing the unfreezable corner of the "2-way peg triangle" |
| 19:39:06 | jtimon: | which of course snarks breaks |
| 19:41:46 | jtimon: | the triangle was unfreezable, secure and generic |
| 19:43:00 | jtimon: | unilateral withdrawal lacks the generic property because the parentchain needs to undesrtand the childchain for the full-history proof of ownership |
| 19:43:26 | jtimon: | unless, as always, you use snark |
| 19:44:41 | home_jg: | home_jg is now known as jgarzik |
| 19:45:02 | jtimon: | the default approach sacrifices security because it allows a 51% the-attacker-gets-all attack |
| 20:08:04 | petertodd: | "The Value of App Coins" - https://github.com/DavidJohnstonCEO/TheValueofAppCoins <- curious seeing a document where about 50% is your writing, mixed in with 50% someone elses opinions, and then edited somewhat poorly (in their defense, pretty sure the person was a non-native english speaker) |
| 20:16:14 | phantomcircuit: | fun fact |
| 20:16:26 | phantomcircuit: | libreoffice calc does not like drawing charts with 150k points |
| 20:19:24 | petertodd: | phantomcircuit: neither does your mom |
| 20:20:02 | phantomcircuit: | petertodd, i expect most people would not like drawing a chart with 150k points |
| 20:20:05 | phantomcircuit: | so |
| 20:20:07 | phantomcircuit: | "ok" |
| 20:20:12 | petertodd: | heh |
| 20:21:50 | phantomcircuit: | man this is still stalled |
| 20:24:46 | phantomcircuit: | petertodd, ... it's pegged trying to scroll |
| 20:52:18 | justanotheruser: | hmm, couldn't p2pool operate in SPV mode if we had a softfork requiring the coinbase tx to contain a merkle root of the UTXO? |
| 20:54:32 | justanotheruser: | I assume that one reason people don't use p2pool is the requirement of having the blockchain |
| 20:55:55 | sipa: | well that's inevitable |
| 20:56:02 | sipa: | you can't mine without validating blocks... |
| 21:01:44 | justanotheruser: | sipa: but you can validate blocks if you can verify that a tx is spending something in the UTXO |
| 21:02:46 | justanotheruser: | And if the merkle root of the UTXO is in the previous block, you can validate transactions. |
| 21:03:47 | sipa: | you still need the actual UTXO set, not just its hash |
| 21:04:38 | sipa: | which i would qualify as being a full node |
| 21:06:31 | sipa: | (though committed UTXO allows you to bootstrap a full node with only SPV security in historical data) |
| 21:06:43 | sipa: | that's the #1 benefit imho |
| 21:07:56 | andrew_: | oops. got disconnected |
| 21:08:08 | andrew_: | andrew_ is now known as justanotheruser |
| 21:14:42 | justanotheruser: | sipa: Are you sure you need the full UTXO set? Couldn't full nodes just give an SPV proof that the transaction they're including belongs to the UTXO? |
| 21:15:29 | sipa: | that's another model, yes |
| 21:15:55 | justanotheruser: | It's a .5gb UTXO vs having a few hundred kb to a few mb of SPV proofs every block |
| 21:16:11 | sipa: | but you still need full nodes to validate things |
| 21:16:19 | justanotheruser: | and by full nodes I mean full nodes in p2pool. |
| 21:16:26 | Eliel: | you could also modify the network protocol to always send the inputs along with the new tx |
| 21:16:35 | justanotheruser: | sipa: you do, but with this, you wouldn't need a full node to mine in p2pool |
| 21:17:11 | sipa: | Eliel: if you accept you need to rebroadcast after every block |
| 21:17:18 | sipa: | transactions wouldn't be "timeless" anymore |
| 21:17:55 | sipa: | justanotheruser: you'd get pretty ugly results from a 51% attack |
| 21:18:00 | justanotheruser: | I'm guessing those already in p2pool don't mind running a full node, but allowing SPV could let new users instantly join p2pool and not need any disk space |
| 21:18:08 | sipa: | as they can make other non-full miners believe what the right chain is |
| 21:18:08 | justanotheruser: | sipa: please elaborate |
| 21:18:31 | justanotheruser: | sipa: what is a "right" chain? |
| 21:18:39 | sipa: | a valid one, with valid transactions |
| 21:18:53 | sipa: | sorry, it's not "the right" but "a valid" |
| 21:19:15 | justanotheruser: | sipa: well you would choose to mine on one fork or another and you would accept SPV proofs from the fork you chose. |
| 21:19:39 | sipa: | a 51% group could make you believe anything |
| 21:19:49 | justanotheruser: | sipa: how? |
| 21:19:51 | sipa: | ... |
| 21:19:57 | sipa: | they can create blocks they like |
| 21:20:03 | sipa: | with UTXO commitments they like |
| 21:20:13 | sipa: | the SPV proofs nodes give you are only SPV proofs |
| 21:20:21 | sipa: | they rely on the majority of miners being honest |
| 21:20:39 | Eliel: | sipa: you mean majority of full node miners. |
| 21:20:50 | sipa: | well, yes and no |
| 21:21:07 | sipa: | if miners themselves start relying on such proofs, they can be tricked into helping a 51% attack without knowing it |
| 21:21:16 | Eliel: | ah, right |
| 21:21:51 | justanotheruser: | sipa: that is a good point. They could make an invalid chain and if there are 51% or more SPV miners then that invalid chain could just keep growing... |
| 21:23:15 | sipa: | essentially, if you have A honest full miners, B attackers and C honest spv miners |
| 21:23:30 | sipa: | then a rewrite attack is possible with B > A |
| 21:23:37 | sipa: | rather than B > A + C |
| 21:24:37 | justanotheruser: | hmm. somehow they would have to be able to get a proof of invalidity from an honest miner |
| 21:24:44 | justanotheruser: | but that isn't sybil resistant |
| 22:31:03 | gmaxwell: | Fairly comprehensive presence notification protocol using PIR and a pairing crypto forward secrecy: http://cacr.uwaterloo.ca/techreports/2014/cacr2014-10.pdf It might inform some thoughts about stealth address scanning. |
| 23:27:44 | warren: | Idle curiosity, has anyone analyzed torcoin's design to see if it is sound? |
| 23:43:30 | justanotheruser: | warren: If you mean Yacoin, it uses PoS and is centralized https://github.com/yacoin/yacoin/blob/master/src/checkpoints.cpp#L395 |