| 00:03:05 | nsh: | andytoshi, lemme know if you're ever headed to the UK |
| 00:14:00 | jgarzik: | amiller, dakami says he lost the bet, and will pay 10BTC |
| 00:14:50 | nsh: | fair play |
| 00:18:20 | phantomcircuit: | ha |
| 00:18:25 | phantomcircuit: | that's fun |
| 00:40:10 | maaku: | nsh: what part of the uk are you at? |
| 00:40:20 | nsh: | near Cambridge |
| 01:02:51 | amiller: | jgarzik, where's the tweet as such? |
| 01:04:32 | phantomcircuit: | amiller, he's not here :P |
| 01:04:44 | amiller: | who cares |
| 01:06:34 | phantomcircuit: | lol |
| 01:08:16 | andytoshi: | Eliel: if i can manipulate a block 1400 in the future, i can at a minimum ensure that im controlling that particular block, so i have 1/1400 of the chain. i can also influence the stake distribution in my favor, slowing moving the system to my benefit |
| 01:08:51 | andytoshi: | i am at school now on a qwerty keyboard, can't really type, but i think i have a way to prevent grinding.. |
| 01:09:44 | andytoshi: | it does not help the initial block download situation, and it requires somehow that the stake get evenly-distributed farily early on |
| 01:11:30 | nsh: | andytoshi, you normally use Dvorak?? |
| 01:12:48 | andytoshi: | a good question to contemplate is, can we make the stakeholders' differing interest cause them to naturally force the stake to be decentralized, much as bitcoin miners' interest force the difficulty up? basically exploiting a tragedy of commons? |
| 01:13:27 | andytoshi: | nsh: yeah, dvorak, and yeah, will def let you know if i find myself in the uk |
| 01:13:36 | nsh: | great :) |
| 01:28:35 | Eliel: | andytoshi: the thing is, you only have a binary choice for influencing the stake distribution with that one block. |
| 01:29:04 | Eliel: | whether you forge it, or if you pass on it and let someone else forge it (you also lose your chance to forge for 1400 blocks whichever you choose) |
| 01:31:17 | Eliel: | what you choose to include in the block has no effect on who gets to forge after you. |
| 02:34:10 | BurritoBazooka: | BurritoBazooka has left #bitcoin-wizards |
| 05:21:59 | ghtdak: | ghtdak has left #bitcoin-wizards |
| 06:50:37 | [BNC]dansmith: | [BNC]dansmith is now known as dansmith_btc |
| 07:47:49 | arubi_: | arubi_ is now known as arubi |
| 08:47:21 | lclc_: | lclc_ is now known as lclc |
| 10:29:30 | rodarmor: | rodarmor has left #bitcoin-wizards |
| 11:24:21 | samson: | samson is now known as samson_ |
| 11:50:06 | nshlike: | andytoshi, you don't mind if i spider the logs to extract an informal research/interesting-stuff bibliography? |
| 11:50:12 | nshlike: | or if you want to make me an archive mebbes |
| 12:04:54 | fanquake: | fanquake has left #bitcoin-wizards |
| 14:33:02 | andytoshi: | nsh: go for it |
| 14:52:09 | andytoshi: | Eliel: ah, one bit per block is good, i was going to suggest that last night. but i think i made a mistake in my calculations and it doesn't really improve things much.. |
| 14:52:44 | andytoshi: | suppose an attacker has 1/q of the stake (1/q of the potential signing keys, all chosen uniformly for simplicity's sake) and needs to control m signatures to have control over the next block |
| 14:54:38 | andytoshi: | then by controlling B blocks (they have to be consecutive since he needs to be able to grind them all) he gets 2^B chances to land on a signature set where he has m of the keys |
| 14:55:52 | andytoshi: | so if B = m lg q, he can expect to win. if he has 1% of the stake and needs 10 signatures, that's 70 blocks |
| 15:06:23 | gmaxwell: | andytoshi: you should stop assuming that M>1 is needed, I can't find any deployed system that works that way. :) |
| 15:07:30 | nsh: | M being? |
| 15:07:56 | andytoshi: | :P but i'm curious if we can stop the stake-grinding, because that would push the "costless simulation" problem into the early part of the chain when stake is being dispersed |
| 15:09:43 | gmaxwell: | nsh: it's an idea that you require multiple signers to produce a block. A different way of sampling approval. |
| 15:10:05 | nsh: | mmm, okay |
| 15:10:14 | andytoshi: | and also the above calculation is wrong. doing it in general for M-of-N required sigs on each block is a fun tricky probability problem |
| 15:11:15 | gmaxwell: | andytoshi: I wonder if it's not worth thinking through the progress freeness implications first. Like, if you have a lot of stake and M>1, you have an advantage if you refuse to share unless you are not all the M. |
| 15:15:17 | andytoshi: | gmaxwell: like, hold the block hostage? i have not thought about what happens if not enough signers do the signing (there is almost certainly an opportunity for rewriting here if we don't throw up our hands and say "game over") |
| 15:16:03 | andytoshi: | but i think it's really unlikely that a single signer would get more than 1 sig for a given block (unless he was grinding) even with a lot of stake |
| 15:19:12 | andytoshi: | oh, that's definitely not true, even with 1% of the stake, if there are 10 potential signees there's like a 7.5% chance he'll be at least two of them |
| 15:28:50 | andytoshi: | ok, if you need M of N sigs, have 1/q of the total stake keys and get 1 bit for every block you control, i think the number of blocks you have to control is -m * lg(1 - (1 - 1/q)^n) |
| 15:29:55 | andytoshi: | you can plug in some numbers and play with it, you'll always get a small (<100) number of blocks. what's really important is that this increases really slowly with q, so you don't need to have a lot of stake to pull this off, you just need to get hold of the keys |
| 15:31:00 | andytoshi: | last night i thought i had exponential growth, but i was wrong. i think this stake-grinding prevention is bunk. |
| 15:45:05 | stonecoldpat: | andytoshi: have you borrowed any ideas from greggs CoinWitness idea? (proof of storage) - im going to read it shortly, but just interested if it has been of use so far |
| 15:46:09 | stonecoldpat: | so far to you* not in general |
| 15:46:35 | justanotheruser: | proof of storage??? Link please |
| 15:46:52 | justanotheruser: | Does it involve actual proofs, or does it invoke trust? |
| 15:47:21 | stonecoldpat: | https://bitcointalk.org/index.php?topic=310323.0 |
| 15:47:48 | stonecoldpat: | ah coinwitness is another one of his ideas about block compression (https://bitcointalk.org/index.php?topic=277389.0) - didnt mean to mix them up! |
| 15:48:48 | justanotheruser: | thanks |
| 15:48:58 | justanotheruser: | oh wait, is that the right link? |
| 15:48:59 | justanotheruser: | gtg |
| 15:49:57 | andytoshi: | stonecoldpat: haven't used coinwitness or proof-of-storage — i've read coinwitness a few times and tbh i still don't have an intuition for what's going on. i don't think proof-of-storage is applicable here |
| 16:35:33 | fasdfasdfsaf: | fasdfasdfsaf is now known as drawingthesun2 |
| 17:43:13 | samson_: | samson_ is now known as samson |
| 17:43:20 | samson: | samson is now known as samson_ |
| 17:56:13 | wallet42: | wallet42 is now known as Guest72781 |
| 17:56:13 | wallet421: | wallet421 is now known as wallet42 |
| 19:54:13 | andytoshi: | amiller: is any of your lottery stuff public enough to be cited in my PoS document? |
| 19:54:45 | andytoshi: | also what is a good 'consensus is impossible' paper to cite? one was posted here a month or two ago and i can't find it |
| 20:02:32 | tacotime: | Not sure of the relevance, by my system involved per block signing by a majority of eligible stakeholders selected by a lottery based on blockheader entropy. |
| 20:02:39 | gmaxwell: | I like the old lamport distributed clocks paper. |
| 20:03:02 | gmaxwell: | * gmaxwell twitches at the misuse of entropy |
| 20:03:12 | tacotime: | So it's the same probability problem essentially. |
| 20:03:25 | tacotime: | Sorry gmaxwell. What would the correct term be? |
| 20:04:30 | tacotime: | (Same probability probably as M-of-N signers per block) |
| 20:06:31 | gmaxwell: | tacotime: it's okay, I would have just said "based on blockheaders". Assuming what you're doing is e.g. some hash of some set of blockheader data.. it's a determinstic function. There is no entropy. :P Don't mind me. |
| 20:07:26 | tacotime: | Yeah, that's correct, thanks. |
| 20:07:30 | Fundraise: | Fundraise is now known as TirixTa |
| 20:07:47 | TirixTa: | TirixTa is now known as MakTa |
| 20:08:12 | MakTa: | MakTa has left #bitcoin-wizards |
| 20:12:00 | tacotime: | And the block hostage situation is relevant and can pose serious issues, for instance if a PoW miner colludes with a PoS miner and the PoS miner refuses to let any blocks onto the network except those from the PoW pool. |
| 20:13:07 | tacotime: | Collusion is probably the foremost instability in such a system, but I'm not totally sure. Find out if I ever get it running, I guess. :P |
| 20:14:05 | helo_: | helo_ is now known as helo |
| 21:56:06 | dgenr8: | gmaxwell: lamport required global locks |
| 22:05:26 | dgenr8: | it reminded me of token ring. to scale, ethernet had to abandon certainty for a statistical approach |
| 22:06:14 | nsh: | determinism is an overhead |
| 23:13:55 | Guest81977: | Guest81977 is now known as jgarzik_ |