00:42:34gmaxwell:andytoshi: Fun observation, you can do a fancy crypto free but guy-fawkes-secure version of the same kind of anonymity as the OWAS signatures like this: the transaction hash for signing is H(txins || H(H(txouts)||nonce)) You give the miner the nonce. The miner permuts up the block and doesn't reveal the nonces unlinking inputs and outputs. If the miner cheats, you broadcast the nonce, which invalidates the block content (and gets ...
00:42:41gmaxwell:... mined in a future block). To prevent infinitely delayed protests you demand that all counter claims happen in a certian number of blocks.
00:43:11gmaxwell:This is neat because it has ~no cpu overhead, and no bandwidth overhead, low code complexity, and no new cryptographic assumptions.
01:50:45paavo:paavo is now known as cracksmurf
02:36:47amiller:my advisor elaine suggested a really interesting attack on proof of stake systems.
02:36:56amiller:we've talked about incentives and collusion and stuff like that before
02:37:04amiller:the concern now is collusion after the fact
02:37:51amiller:you can always find people who perhaps didn't initially collude and convince them to do so later on, so this is a component of one of those go-back-in-time-and-simulate-an-alternate-history attacks
02:38:22amiller:maybe we've discussed this before but i haven't thought about it that way recently
02:43:21gmaxwell:yes, thats why I've taken to calling "nothing at stake" "costless simulation" since it better covers that.. See also part 5. third paragraph https://download.wpsoftware.net/bitcoin/pos.pdf
02:51:23amiller:thanks. i forgot how well it's described there.
03:01:26amiller:andytoshi, i notice that nothing in your paper really covers "punitive" algorithms like slasher etc
03:01:44amiller:i'm not sure whether that matters
03:02:22gmaxwell:amiller: anything with a finite delay has the same problem, just after the delay ends go get the old keys.
03:02:59amiller:even with punishment, you can go get the keys from someone in the past who declined to participate
03:03:18amiller:i should have added #tendermint in the list of punitive algoirthms but there's others too
03:04:27amiller:this is sort of discussed by the bribery section of the PoA paper.
03:04:47gmaxwell:I think all the delay ones also require locking up your funds, which creates a strong centeralization incentive 'banks' that give you interest while still allowing funds access.
03:05:51gmaxwell:e.g. if the delay lasts a week, maybe you might want to use your funds in the next week.. so you're sure to put them with a bank that takes deposits from many people, gives you less returns but also lets you withdraw at any time unless their funds run low.
03:13:39amiller:both of these concerns are directly addressed by 5.2, 5.3 of the PoA paper, but i think the arguments make no sense
03:15:41gmaxwell:PoA paper?
03:17:14amiller:http://eprint.iacr.org/2014/452.pdf gmaxwell
03:17:32amiller:Proof of Activity: Extending Bitcoin’s Proof of Work via Proof of Stake by Iddo and three others
03:17:36gmaxwell:oh that.
03:18:42amiller:i'm circulating that and andytoshi's writeup to colleagues as a way of explaining the big dilemma and formalism gap we need to fill
03:20:12gmaxwell:andy's writeup isn't yet comprehensive (E.g. doesn't reflect all the concerns we know about)
03:21:20gmaxwell:part of the problem is that there are dozen different designs, many more or less underspecified (e.g. never implemented or only in closed source things; or implemented but not also described).. and a lot of them patch around specific attacks with changes which may or may not be general improvements (and may instead open up new attacks, for example)
03:22:06gmaxwell:virtually no one making software for this stuff has made any effort to make a crisp and reasonably complete statement of what their security assumptions actually are.
03:23:08amiller:i can point to these two writeups and say this justifies the need for a model which is inclusive of both of these kinds of techniques and thus allows us to compare them
03:23:47amiller:there's no model for bitcoin in which these are comparable either... the 51%-hashpower-is-honest model is adequately understood for example, but stake protocols don't make sense in
03:25:01gmaxwell:not that majorit hashpower is honest is a comprehensive statement of our real assumptions, but the POS stuff doesn't even get that close.
03:25:27gmaxwell:like, what actually is the assumption that makes someone getting old keys and resimulating the network not a concern?
03:26:38amiller:i can't figure out how to bootstrap an incentives model, because there's no incentive except for the virtual currency payments, and yet the value of the virtual currency payments only matters if it's secure, and it's only secure if the incentive mechanism works.
03:27:15amiller:so it's inherently circular, but that's basically the least of the problems (it's not a problem, that part is totally plausible is OK, just weird to work with)
03:28:02amiller:so i think the model needs a cost for computational effort (i.e., the power and cooling), but also a cost for computational power (i.e. the hardware)
04:13:34nairb:why is there a need to keep the whole blockchain forever? has anyone tried making a cryptocurrency that just shares a single static ledger, or only keeps maybe every balance and the X blocks of transactions?
04:13:53nairb:last* X blocks of transactions
04:16:11sl01:nairb: I think ripple's consensus always assumes the ledger that the majority of your UNL agreed upon is the correct one
04:16:48sl01:although I beleive they do by default keep all history as a way to prove someone lied, but thats outside of the protocol
04:20:23sl01:nairb: if you do that with PoW how do you prove that some entry in the ledger is correct without looking at the entire block history?
04:23:29nairb:sl01: I don't know too much about the details of how bitcoin is implemented, but I think the way it's setup now we just have all transactions, and kinda calculate "balances" as the sum of transaction outputs. I'm thinking it would, instead of maintaining a chain of transactions, just have actual ledger entries. if you had the last few ledgers, you'd be able to verify that the set of transactions from one ledger to the next made se
04:24:32sl01:nairb: well yea you don't need to keep very old blocks I think, but you need to see them at least once, I believe that's already a planned change in bitcoind (getting rid of old blocks)
04:25:06nairb:interesting, i thought the plan was for bitcoind to always hold the full record forever...
04:25:42nairb:can bitcoind actually get rid of old blocks? I thought most would contain at least some unspent coins?
04:25:48sl01:nairb: I think there is going to be an option that lets you get rid of old blocks... not 100% sure about that though... full chain holding nodes will be called archive nodes
04:26:20nairb:maybe I'm missunderstanding what's actually in a block... I still have a lot to learn about this
04:42:09nairb:I feel like the 51% thing always in the bitcoin-news isn't really a big deal,.... I'm surprised I don't see more people worried about scalability. if paypal/ebay/amazon/others suddenly all started accepting bitcoin, I mean, amazon sells up to 300 items per second. getting 2% of amazon's purchase volume would require some sidechain solution instantly. bitcoin growth is so fast.... how long will it take to research and develop mec
04:42:09nairb:hanisms to work around the 7 tps limit?
06:52:40justanot1eruser:justanot1eruser is now known as justanotheruser
11:27:57nshsome:nshsome is now known as [nsh]
12:04:48sipa:nairb: #bitcoin please
13:15:19[nsh]:[nsh] is now known as [nshiary]
14:04:2677CAAG7LP:77CAAG7LP is now known as e4xit
16:04:21andytoshi:gmaxwell: that nonce thing is pretty slick. i thought of several variants on miner/transacter collusion and it seems that it doesn't enable anyone to steal money
16:06:27andytoshi:amiller: right, pos.pdf doesn't discuss punitive schemes or single-use-signing keys or incentives surrounding signature witholding (or schemes to work around withheld signatures)
16:07:44andytoshi:these all introduce new ways to destroy consensus depending how they are used, but it's hard to think about them generally and it's not clear what kind of incentives are required to prevent them
16:27:18andytoshi:gmaxwell: the ambiguous output-distribution thing is also really cheap and requires no fancy crypto. have you gotten a chance to look at adam's homomorphically-encrypted values stuff?
16:28:57andytoshi:https://bitcointalk.org/index.php?topic=305791.0 <--- « bitcoins with homomorphic value (validatable but encrypted) » adam3us
17:56:53andytoshi:i think HE values might conflict with your hash-based miner-trusting OWAS (we need a name for that) since you can't slice a zk proof that outputs ≤ inputs. with the ambiguous-output-distribution scheme we developed a few days ago we get a big benefit of this (there are lots of outputs of any size available for ringsigning with) though we don't get output value anonymity. maybe this is not so
17:56:54andytoshi:important if the ringsigs are killing traceability?
18:02:33andytoshi:idk, my next steps are (a) can we ringsign with two keys in one signature (so spending two outputs and combining their anonymity sets), (b) can we do k-of-n threshold signatures like this the way you can with schnorr-sigs (so multisig outputs are undectectable and can be in each others' anonymity sets)
21:16:16NikolaiToryzin:NikolaiToryzin is now known as stqism
21:16:24stqism:stqism is now known as NikolaiToryzin
21:16:45NikolaiToryzin:NikolaiToryzin is now known as stqism
21:16:53stqism:stqism is now known as NikolaiToryzin
21:46:59mapppum:mapppum is now known as mappum
22:52:37NikolaiToryzin:NikolaiToryzin is now known as stqism
22:52:44stqism:stqism is now known as NikolaiToryzin