| --- Log opened Tue Dec 29 00:00:34 2015 | ||
| --- Day changed Tue Dec 29 2015 | ||
| -!- hdbuck [~hdbuck@unaffiliated/hdbuck] has quit [Quit: hdbuck] | 00:00 | |
| -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 260 seconds] | 00:02 | |
| -!- rasengan [~rasengan@eyearesee.com] has quit [Quit: leaving] | 00:05 | |
| -!- rasengan [sid136612@pdpc/corporate-sponsor/privateinternetaccess.com/rasengan] has joined #bitcoin-wizards | 00:06 | |
| -!- throughnothing [~throughno@c-71-204-189-125.hsd1.ca.comcast.net] has quit [Quit: Leaving...] | 00:09 | |
| -!- heyrhett [~rhett@c-73-223-86-218.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 00:14 | |
| heyrhett | I have a dumb question. I heard that 40% of the altcoins on coinmarketcap have failed. Does anyone know what tends to cause these failures? Is there a trend? | 00:18 |
|---|---|---|
| nsh | why should they succeed in the first place? | 00:20 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] | 00:20 | |
| nsh | what is the value proposition offered? what underpins the ostensible value? what are the requirements maintenance and development and community that allow bitcoin to succeed which may be lacking in altcoins? | 00:20 |
| -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 264 seconds] | 00:21 | |
| nsh | (unless you want to go into theoretical issues, this discussion is better suited to #bitcoin however) | 00:21 |
| nsh | (altcoin failure is more often sociological than theoretical, which is not to say there's a lack of technical fuck-ups, but they're secondary to the social/cultural issues generally) | 00:22 |
| gentoognuhurd | heyrhett: yes, the failure is due to the fact that they are scams | 00:23 |
| heyrhett | I get that they are scams | 00:32 |
| heyrhett | but I guess I'm wondering where the line is. What level of network participation is needed to maintain a PoW coin? | 00:33 |
| heyrhett | and how exactly do they fail | 00:33 |
| -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards | 00:33 | |
| heyrhett | I'm a little more interested in wondering if analogous situations could apply to bitcoin | 00:33 |
| heyrhett | I see a lot of small time coins still running with a small number of miners | 00:34 |
| heyrhett | not listed on exchanges | 00:34 |
| heyrhett | maybe they are considered failures if there is no real exchange that supports them anymore | 00:34 |
| -!- pozitron [~nu@45.32.232.26] has quit [Ping timeout: 246 seconds] | 00:35 | |
| nsh | heyrhett, some nice people wrote a treatise on it: https://download.wpsoftware.net/bitcoin/alts.pdf | 00:35 |
| nsh | this shouldn't be surprising though. the fact that it's surprising to you that altcoins fail probably means you don't understand the extent to which it's an incredibly difficult engineering problem | 00:36 |
| heyrhett | nsh: did I say I was surprised? | 00:37 |
| heyrhett | thanks for the link | 00:37 |
| nsh | imagine i said "one" instead of "you" | 00:37 |
| nsh | :) | 00:37 |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vapnjrtrmcjveeso] has joined #bitcoin-wizards | 01:04 | |
| -!- Guyver2 [~Guyver2@a80-100-156-239.adsl.xs4all.nl] has joined #bitcoin-wizards | 01:15 | |
| fluffypony | heyrhett: the vast majority of them have no raison d'être | 01:17 |
| fluffypony | most of the rest are scams | 01:18 |
| fluffypony | there's maybe 1% of 1% that are actually useful / not scams / not designed by utter retards | 01:18 |
| fluffypony | and the vast majority of those 1% of 1% will fail anyway | 01:19 |
| heyrhett | fluffypony: i'm aware. my favorite one is ripoffcoin | 01:19 |
| fluffypony | frustratingly there's LOTS of decentralised theatre in the altcoin world, and very few participants are honest enough to be realistic about how insecure their pet project is (in relation to Bitcoin) | 01:20 |
| heyrhett | even ripoffcoin seems to technically be operating though, with $14 in volume on cryptsy in the past 24 hours | 01:20 |
| heyrhett | I'm not sure if that counts in the 40% failure stat I heard | 01:21 |
| fluffypony | lol | 01:21 |
| fluffypony | I think if we're going by trade volume it's a lot higher than that | 01:21 |
| fluffypony | 85 coins on CMC had > $100 in trade over the last 24 hours | 01:22 |
| fluffypony | that's of the 667 listings | 01:22 |
| fluffypony | so 13% are "actively" traded by some arbitrary measure I just made up | 01:22 |
| heyrhett | by the way, totally unrelated to this channel, but does anyone find this disturbing? https://www.reddit.com/r/privacy/comments/3yinij/entire_us_voter_registration_record_leaks_191/ | 01:23 |
| fluffypony | we have #bitcoin-wizards-offtopic for that now :) | 01:24 |
| heyrhett | haha | 01:24 |
| -!- raver_edm [~vegas_nig@2602:306:b8e0:8160:c1b3:84f5:2321:86b7] has joined #bitcoin-wizards | 01:27 | |
| -!- raver_edm [~vegas_nig@2602:306:b8e0:8160:c1b3:84f5:2321:86b7] has quit [Client Quit] | 01:32 | |
| -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-wizards | 01:39 | |
| -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Ping timeout: 246 seconds] | 01:40 | |
| -!- LeMiner2 is now known as LeMiner | 01:40 | |
| -!- JackH [~Jack@host-80-43-143-141.as13285.net] has joined #bitcoin-wizards | 01:47 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has quit [] | 02:00 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 02:11 | |
| -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has quit [Remote host closed the connection] | 02:19 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 02:22 | |
| -!- JackH [~Jack@host-80-43-143-141.as13285.net] has quit [Ping timeout: 260 seconds] | 02:24 | |
| -!- yosso [~yosso@31.210.188.117] has joined #bitcoin-wizards | 02:26 | |
| -!- Yoghur114 [~Yoghurt11@131.224.198.111] has quit [Remote host closed the connection] | 02:28 | |
| -!- Yoghur114 [~Yoghurt11@131.224.198.111] has joined #bitcoin-wizards | 02:29 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] | 02:30 | |
| -!- yossso [~yosso@46.19.85.31] has joined #bitcoin-wizards | 02:36 | |
| -!- yosso [~yosso@31.210.188.117] has quit [Ping timeout: 260 seconds] | 02:40 | |
| -!- tripleslash_k [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-wizards | 02:45 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 02:45 | |
| -!- tripleslash_b [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 260 seconds] | 02:46 | |
| -!- p15 [~p15@42.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 265 seconds] | 02:49 | |
| -!- JackH [~Jack@host-80-43-143-141.as13285.net] has joined #bitcoin-wizards | 02:53 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep] | 02:53 | |
| -!- JackH [~Jack@host-80-43-143-141.as13285.net] has quit [Client Quit] | 02:53 | |
| -!- ElmerFunk_ [~Mutter@213.57.66.158] has joined #bitcoin-wizards | 02:57 | |
| -!- ElmerFunk_ [~Mutter@213.57.66.158] has quit [Remote host closed the connection] | 02:58 | |
| -!- ElmerFunk_ [~Mutter@37.142.35.67] has joined #bitcoin-wizards | 02:59 | |
| -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 245 seconds] | 03:00 | |
| -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-wizards | 03:01 | |
| -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_] | 03:13 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 265 seconds] | 03:26 | |
| -!- phy1729 [~phy1729@unaffiliated/phy1729] has quit [Ping timeout: 276 seconds] | 03:35 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 03:48 | |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 03:51 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 276 seconds] | 03:52 | |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Client Quit] | 03:55 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 240 seconds] | 04:05 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 04:06 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 04:08 | |
| -!- ElmerFunk_ [~Mutter@37.142.35.67] has quit [Remote host closed the connection] | 04:09 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 04:10 | |
| -!- nuke1989 [~nuke@178-157-152.dynamic.cyta.gr] has quit [Remote host closed the connection] | 04:17 | |
| -!- phy1729 [~phy1729@unaffiliated/phy1729] has joined #bitcoin-wizards | 04:19 | |
| -!- maaku [~quassel@botbot.xen.prgmr.com] has quit [Remote host closed the connection] | 04:19 | |
| -!- wallet42 [~wallet42@nz112l10.bb11352.ctm.net] has joined #bitcoin-wizards | 04:44 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds] | 04:54 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 04:56 | |
| -!- pozitrono [~nu@85.17.25.22] has joined #bitcoin-wizards | 04:58 | |
| -!- wallet42 [~wallet42@nz112l10.bb11352.ctm.net] has quit [Quit: Leaving.] | 05:07 | |
| -!- ElmerFunk_ [~Mutter@213.57.66.158] has joined #bitcoin-wizards | 05:09 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has quit [Remote host closed the connection] | 05:15 | |
| -!- eudoxia [~eudoxia@r167-57-98-146.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 05:15 | |
| -!- wallet42 [~wallet42@nz112l10.bb11352.ctm.net] has joined #bitcoin-wizards | 05:20 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] | 05:24 | |
| -!- GAit [~GAit@2.230.161.158] has joined #bitcoin-wizards | 05:27 | |
| -!- ElmerFunk_ [~Mutter@213.57.66.158] has quit [Remote host closed the connection] | 05:32 | |
| -!- maaku [~quassel@botbot.xen.prgmr.com] has joined #bitcoin-wizards | 05:32 | |
| -!- maaku is now known as Guest87480 | 05:32 | |
| -!- Guest87480 is now known as maaku | 05:33 | |
| -!- ryan-c [~ryan@srv1.turboslow.net] has quit [Ping timeout: 276 seconds] | 05:39 | |
| -!- hashtag [~hashtag@cpe-174-97-254-80.ma.res.rr.com] has quit [Ping timeout: 246 seconds] | 05:44 | |
| -!- tripleslash_i [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-wizards | 05:46 | |
| -!- tripleslash_k [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 264 seconds] | 05:47 | |
| -!- GAit [~GAit@2.230.161.158] has quit [Quit: Leaving.] | 05:48 | |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 05:48 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 05:49 | |
| -!- ryan-c [~ryan@srv1.turboslow.net] has joined #bitcoin-wizards | 05:56 | |
| -!- hashtag [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has joined #bitcoin-wizards | 06:00 | |
| SheffieldCrypto_ | We're a machine learning and predictive modeling based start-up focusing on modeling various aspects of bitcoin and other digital currencies. We're currently looking for new members, please view this google doc for more information. | 06:10 |
| SheffieldCrypto_ | https://docs.google.com/document/d/15PLREFfmo4gy1ozJV9bLkjgGoLBCjL8Q05our13b2-Q/edit | 06:10 |
| -!- AaronvanW [~ewout@meinhotspot26.websecuritas.com] has joined #bitcoin-wizards | 06:16 | |
| -!- AaronvanW [~ewout@meinhotspot26.websecuritas.com] has quit [Changing host] | 06:16 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 06:16 | |
| dcousens | wouldn't payment channels be vulnerable to a miner and a party colluding to ignore the newer transactions? | 06:16 |
| dcousens | obviously the cheated party could submit to multiple miners in hope that they would pick them up though | 06:18 |
| dcousens | and the colluding parties would have to keep up the blockade until the next locktime expired | 06:19 |
| dcousens | which may be unfeasible | 06:19 |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] | 06:22 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 06:31 | |
| instagibbs | dcousens, you'd hope a miner would defect for a large enough fee | 06:34 |
| -!- wallet42 [~wallet42@nz112l10.bb11352.ctm.net] has quit [Ping timeout: 264 seconds] | 06:36 | |
| dcousens | I wonder if the lightning network nlocktime gaps are taking these sort of things into account | 06:36 |
| dcousens | I assume they are, but, I'd be curious as to what the thresholds are | 06:36 |
| -!- wallet42 [~wallet42@nz112l10.bb11352.ctm.net] has joined #bitcoin-wizards | 06:40 | |
| instagibbs | dcousens, that would be a per-user/channel choice, so I'm sure | 06:41 |
| instagibbs | time preference of money needs to be taken into account | 06:42 |
| -!- ElmerFunk_ [~Mutter@37.142.35.67] has joined #bitcoin-wizards | 06:50 | |
| -!- ElmerFunk_ [~Mutter@37.142.35.67] has quit [Remote host closed the connection] | 06:53 | |
| -!- wangchun [~wangchun@li414-193.members.linode.com] has quit [Ping timeout: 256 seconds] | 06:55 | |
| -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-wizards | 06:57 | |
| -!- alpalp [~alp@104-54-235-28.lightspeed.austtx.sbcglobal.net] has quit [Ping timeout: 260 seconds] | 06:59 | |
| -!- mappum [sid43795@gateway/web/irccloud.com/x-lfykcvkwzfnjmdpv] has quit [Ping timeout: 240 seconds] | 07:03 | |
| -!- pozitrono [~nu@85.17.25.22] has quit [Ping timeout: 246 seconds] | 07:04 | |
| -!- runeks [sid21167@gateway/web/irccloud.com/x-gvjbntktthdlsmec] has quit [Ping timeout: 250 seconds] | 07:05 | |
| -!- mappum [sid43795@gateway/web/irccloud.com/x-abbwpwgwiteijsai] has joined #bitcoin-wizards | 07:05 | |
| -!- runeks [sid21167@gateway/web/irccloud.com/x-poheizepziobufjw] has joined #bitcoin-wizards | 07:07 | |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer] | 07:07 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection] | 07:09 | |
| -!- eudoxia [~eudoxia@r167-57-98-146.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] | 07:10 | |
| -!- eudoxia [~eudoxia@r167-57-98-146.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 07:13 | |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards | 07:13 | |
| -!- AaronvanW [~ewout@meinhotspot26.websecuritas.com] has joined #bitcoin-wizards | 07:17 | |
| -!- AaronvanW [~ewout@meinhotspot26.websecuritas.com] has quit [Changing host] | 07:17 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 07:17 | |
| -!- coinoperated [~coinopera@70.15.164.106.res-cmts.t132.ptd.net] has joined #bitcoin-wizards | 07:20 | |
| -!- melvster1 [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 256 seconds] | 07:23 | |
| -!- zookolaptop [~user@68.233.157.2] has joined #bitcoin-wizards | 07:24 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] | 07:35 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 07:35 | |
| -!- melvster1 [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards | 07:37 | |
| -!- pozitron [~nu@162.216.46.34] has joined #bitcoin-wizards | 07:46 | |
| -!- coinoperated [~coinopera@70.15.164.106.res-cmts.t132.ptd.net] has quit [Ping timeout: 256 seconds] | 07:54 | |
| -!- melvster1 [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 240 seconds] | 08:00 | |
| -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-wizards | 08:02 | |
| -!- Yoghur114_2 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards | 08:02 | |
| bsm117532 | Doesn't Casper require that coins be fungible between forks, which by definition they aren't? (https://blog.ethereum.org/2015/12/28/understanding-serenity-part-2-casper/) | 08:05 |
| bsm117532 | PoW works because energy expenditure IS fungible between forks. | 08:05 |
| AdrianG | so intheoreum finally works yet? | 08:06 |
| bsm117532 | I don't think it works, that's why I'm asking. | 08:06 |
| bsm117532 | One has to assume consensus on the state of Casper contracts to generate consensus. | 08:06 |
| -!- tripleslash_q [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-wizards | 08:09 | |
| -!- tripleslash_i [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 265 seconds] | 08:10 | |
| AdrianG | bsm117532: personally, i think PoS in the end boils down to subjective emotions almost | 08:11 |
| AdrianG | 'If someone buys up half the coins on a proof-of-stake chains, and attacks it, then the community simply needs to coordinate on a patch where clients ignore the attacker’s fork, and the attacker and anyone who plays along with the attacker automatically loses all of their coins.' | 08:11 |
| AdrianG | so instead of fungibility, they are hard at work on how to automate blacklisting. | 08:12 |
| bsm117532 | Yeah. Casper seems to have a long withdrawl period (4 months), I think they just put off the range of an attack to that time scale, rather than preventing them. | 08:13 |
| -!- melvster1 [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards | 08:14 | |
| -!- eudoxia_ [~eudoxia@r167-57-128-13.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 08:15 | |
| -!- eudoxia [~eudoxia@r167-57-98-146.dialup.adsl.anteldata.net.uy] has quit [Read error: Connection reset by peer] | 08:16 | |
| instagibbs | at this point it's hard to tell what he's solving | 08:27 |
| instagibbs | proposing to solve* | 08:27 |
| fluffypony | isn't this still the 3 second block time thing? | 08:27 |
| bsm117532 | ;;later tell bramc (re non-inclusion) Aha so you're keeping the tree in sorted order. I should have thought of that... Then you just need to show the Merkle path to two adjacent leaves and the metadata indicates there are no more children. So non-inclusion proofs are log(n) and so are inclusion proofs. But in extreme circumstances you need two Merkle paths for the non-inclusion proof. I don't understand your description of "passthrough"... :- | 08:29 |
| gribble | The operation succeeded. | 08:29 |
| bsm117532 | fluffypony: No it's Etherium's attempt at PoS. | 08:30 |
| instagibbs | he liked Truthcoin so much he replaced distributed consensus algorithms with it. | 08:30 |
| -!- Giszmo [~leo@pc-139-55-215-201.cm.vtr.net] has joined #bitcoin-wizards | 08:33 | |
| instagibbs | oh ok, so the "old" PoS has already been tossed. | 08:40 |
| -!- eudoxia_ [~eudoxia@r167-57-128-13.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] | 08:44 | |
| AdrianG | they have a new one now? | 08:44 |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer] | 08:44 | |
| bsm117532 | They've been working on this for a long time... | 08:46 |
| fluffypony | and it's WAY more complex than the last one, so it's exactly what they're aiming for | 08:46 |
| jcorgan | i never followed where their money came from, but somewhere, some investor has got to be asking hard questions by now | 08:52 |
| zookolaptop | jcorgan: I believe it was mostly from a crowd-fund, and my impression is that the crowd is mostly satisfied with their performance. | 08:54 |
| zookolaptop | And I just want to mention that I am blown away by their performance. Ethereum is a tour de force on many technical fronts and I'm impressed. | 08:54 |
| fluffypony | depends | 08:54 |
| bsm117532 | Copying my criticism from the blog: Betting requires fungibility between forks, which is fundamentally impossible. The time horizon of an attack enabled by this non-fungibility is set by the time required to commit funds to be a bonded validator and then withdraw them. You've lengthened the time window of an attack by making it 4 months, but I don't think the attack can be prevented. To put it another way, in order to achieve consensus you mus | 08:54 |
| fluffypony | if you were part of the crowdsale and then sold at a high point you're fine | 08:54 |
| bsm117532 | To put it another way, in order to achieve consensus you must assume consensus on the Casper contract. This is a circular argument. You must use assets external to the system to create consensus. Bitcoin's proof-of-work energy expenditure is precisely an asset that IS fungible between forks. | 08:55 |
| zookolaptop | bsm117532: you wrote a blog post about this? Link, please. | 08:55 |
| fluffypony | but if you're hodling and it crashes because they've burnt through nearly $20 million in 18 months...well... | 08:55 |
| bsm117532 | No I just added a comment to Vitalik's blog above. | 08:55 |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 08:55 | |
| zookolaptop | Disclosure: Ethereum paid us to do a security review of a few bits, and we did, and published our results. About a year ago. | 08:56 |
| bsm117532 | zookolaptop: this Casper stuff is new, and they still don't have it figured out (I think because PoS doesn't work fundamentally for all the usual arguments). I doubt you reviewed this. | 08:56 |
| bramc | bsm117532 Yes it's kept in sorted order. Also because every terminal has a coherent thing in it proofs of exclusion only have to trace a single path rather than two. | 08:57 |
| zookolaptop | bsm117532: Right, we didn't review the Casper stuff, nor its predecessors that were current at the time we did our work. | 08:58 |
| zookolaptop | I don't really care to argue about it. I mostly spoke up just because I didn't want some | 08:58 |
| zookolaptop | observer to see me sitting silently by while people went on and on with "sour grapes" complaining about Ethereum. | 08:58 |
| zookolaptop | Oh, another disclosure: Vitalik is a member of my Technical Advisory Board and we're working together in other ways. | 08:59 |
| bsm117532 | zookolaptop: I don't really have anything to argue. But I think Vitalik is smart and has good intentions. I know other people that I respect that think PoS isn't fundamentally impossible. So I keep an eye out, even though I disagree. | 09:00 |
| bsm117532 | bramc: I see how to do it now but I don't understand "every terminal has a coherent thing in it" nor your description of "passthrough". I assume it's an optimization that gets you a single Merkle path for non-inclusion, which seems reasonable. | 09:02 |
| fluffypony | I know dogs that are smart, I saw a video the other day of a dog that has learnt to drive a car. it doesn't mean I'm going to let my Basenjis design a censorship-resistant, secure, decentralised system. | 09:02 |
| bsm117532 | fluffypony: The set of people in the crypto-community that are worth paying attention to is small enough that I don't have to reject anyone by topic. ;-) | 09:04 |
| fluffypony | bsm117532: oh that set gets a LOT wider if you glance at altcoins now and then :-P | 09:05 |
| bramc | bsm117532 For example in the case where your tree is storing only two things but they share their first ten bits, the resulting tree will be ten layers of passthrough followed by a node which is terminal on both sides | 09:05 |
| -!- Piper-Off is now known as Monthrect | 09:11 | |
| -!- kmels [~kmels@120.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards | 09:17 | |
| bsm117532 | bramc: Aha because you're using a Patricia tree... | 09:23 |
| -!- chjj [~chjj@unaffiliated/chjj] has quit [Quit: null] | 09:23 | |
| -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards | 09:24 | |
| -!- brg444 [415ce066@gateway/web/freenode/ip.65.92.224.102] has joined #bitcoin-wizards | 09:28 | |
| -!- satoshin [~wsirc_935@www.nisys.be] has joined #bitcoin-wizards | 09:31 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] | 09:31 | |
| satoshin | bramc: Hello | 09:32 |
| bramc | bsm117532 Right because it isn't balanced sometimes there's stuff on only one side. I should probably stop calling that case passthrough. That name made sense when it was handled by passthrough, and doesn't make sense when it isn't | 09:34 |
| bramc | satoshin, Good morning | 09:34 |
| -!- gentoognuhurd [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 276 seconds] | 09:35 | |
| satoshin | bramc: it seems to me one can't have less than quadratic sized signatures and det. polymomial time verification without additional assumptions | 09:36 |
| satoshin | I didn't wrote the page 3 yet | 09:37 |
| bramc | satoshin, Not sure what you mean by 'quadratic' in this case. Or determininistic polynomial time verification for that matter. | 09:40 |
| satoshin | bramc: Let n be the nuber of bits of security we claim to offer. I claim signature size is theta(n*n) with relying only on one-way-compr.funcs. ie no better algorithm exists | 09:43 |
| satoshin | I don't really want to inovate something here, ECDSA worked fine in Bitcoin | 09:44 |
| satoshin | let's consider it "Quantum era preparations" or whatever | 09:45 |
| bramc | satoshin, How are regular lamport signatures not linear? | 09:47 |
| bramc | satoshin, amiller's nonoutsourceability uses secure hash based signatures because of their strong nonoutsourceability by the way | 09:48 |
| satoshin | because individual digests for each bits are in this case n-bit and the whole message to be signed is m-bits, so m*n ... again quadratic | 09:49 |
| bramc | I mean nonmalleability | 09:49 |
| satoshin | but Lamport's has huge priv. and pub. keys | 09:49 |
| satoshin | so that's the main result of this | 09:49 |
| bramc | satoshin, Oh yeah that. Winternitz compression improves it a little, but yeah, that seems to be a fairly hard limit. | 09:50 |
| satoshin | the main result is the tiny pub and priv keys | 09:50 |
| bramc | You can always make public keys small by making them be the secure hash of what you would otherwise consider the public key and putting the 'whole' public key in the signature | 09:50 |
| bramc | Likewise private keys can be deterministically generated from a seed, thus making them small. This of course can require extra CPU on signing | 09:51 |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 09:52 | |
| GGuyZ | bsm117532: That post is missing a lot. It's an interesting idea, but I find a serious gap between his strong statement of equilibrium then the notes at the end of the article | 09:52 |
| bramc | hash tubes make signatures a bit bigger, because (a) You have to use half of each of n pairs, rather than k/2 of k things, that loses you about a factor of 2, and (b) You can't use winternitz compression, that loses a lot more | 09:52 |
| satoshin | bramc: sure that has it's uses | 09:53 |
| GGuyZ | Basically at the end they're saying that they need to see if this consensus can withstand byzantine faults | 09:53 |
| GGuyZ | And that the strategy is an equilibrium | 09:53 |
| satoshin | bramc: I disagree with the winternitz compression, on the grounds that the runtime seems to be exponential time | 09:54 |
| bsm117532 | GGuyZ: Yep. I'm filing this under "doesn't work" for now. | 09:54 |
| satoshin | ie someone could ddos a node with bad signatures | 09:55 |
| GGuyZ | bsm117532: I agree. I just think it makes more sense to actually do the analysis first before implementing/posting about it/planning to roll it out in a big production system | 09:56 |
| satoshin | in my app this would be the miners, and that's where we absolutely cannot afford to have a congestion | 09:56 |
| * bsm117532 continues his analysis of braids... | 09:57 | |
| GGuyZ | :D | 09:57 |
| satoshin | furthermore if we want to tune the signature size, we have other ways mainly 1) we can pick stronger oneway compression function f, and make n smaller | 09:57 |
| -!- eudoxia [~eudoxia@r167-57-128-13.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 09:57 | |
| bramc | satoshin, Winternitz is good for a small constant factor improvement in signatures size. Getting a factor of 2 doesn't cost anything at all, 4 is totally reasonable, more than 10 is not a good idea. | 09:58 |
| satoshin | 2) we can use different oneway f at each place in the tube and shrink n even more | 09:58 |
| -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-wizards | 09:59 | |
| bramc | Using a weaker hash function in places sounds like a really bad idea | 09:59 |
| satoshin | 3) we can make the f more slow to compute and shrink n further, but this seems to bring the assumption that nobody will optimize f to run faster | 09:59 |
| -!- dave4925_z [dave4925@unaffiliated/dave4925] has quit [Remote host closed the connection] | 09:59 | |
| -!- JayDugger [~jwdugger@108.19.186.58] has quit [Ping timeout: 264 seconds] | 10:00 | |
| satoshin | bramc: in my application, not really, since one can only start cracking that once an user signs something, at which point one is racing with the miners | 10:00 |
| satoshin | I think we can safely shrink the signature to few KB's | 10:01 |
| -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has joined #bitcoin-wizards | 10:01 | |
| satoshin | at this point the signature fits to one jumbo network packet | 10:02 |
| satoshin | bramc: but yes, I agree with you that small n asks for a trouble | 10:03 |
| -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has quit [Read error: Connection reset by peer] | 10:05 | |
| -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has joined #bitcoin-wizards | 10:06 | |
| satoshin | bramc: The things I've wanted to write about on the next pages, is the doublespend transaction would have to be mined | 10:07 |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep] | 10:08 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] | 10:09 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 10:09 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] | 10:14 | |
| -!- JayDugger [~jwdugger@108.19.186.58] has joined #bitcoin-wizards | 10:17 | |
| -!- throughnothing [~throughno@50.254.145.83] has joined #bitcoin-wizards | 10:23 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 10:26 | |
| -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has quit [] | 10:28 | |
| -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards | 10:34 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer] | 10:36 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 10:37 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Client Quit] | 10:37 | |
| -!- satoshin [~wsirc_935@www.nisys.be] has quit [Quit: satoshin] | 10:49 | |
| -!- nabu [~nabu@179.43.176.162] has quit [Ping timeout: 265 seconds] | 10:50 | |
| -!- desantis [~desantis@50.153.216.5] has joined #bitcoin-wizards | 10:51 | |
| -!- yossso [~yosso@46.19.85.31] has quit [Ping timeout: 276 seconds] | 10:51 | |
| -!- desantis [~desantis@50.153.216.5] has left #bitcoin-wizards [] | 10:52 | |
| -!- TBI_ [~TBI@154.92-220-180.customer.lyse.net] has quit [Read error: Connection reset by peer] | 10:56 | |
| -!- TBI_ [~TBI@154.92-220-180.customer.lyse.net] has joined #bitcoin-wizards | 10:57 | |
| -!- JackH [~Jack@host-80-43-143-141.as13285.net] has joined #bitcoin-wizards | 11:09 | |
| -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Ping timeout: 240 seconds] | 11:30 | |
| -!- throughnothing [~throughno@50.254.145.83] has quit [Remote host closed the connection] | 11:31 | |
| -!- eudoxia [~eudoxia@r167-57-128-13.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] | 11:36 | |
| -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-wizards | 11:47 | |
| -!- coinoperated [~coinopera@cpe-static-mountainintermodal-rtr.cmts.bus.ptd.net] has joined #bitcoin-wizards | 11:49 | |
| -!- psztorc [4575fa8d@gateway/web/freenode/ip.69.117.250.141] has joined #bitcoin-wizards | 11:57 | |
| psztorc | > psztorc: i am wondering if you could elaboate on "In a complex system, it is logically defensible to say “I don’t know what the rule is for, but we should keep it right where it is anyway.” In fact, civilization practically depends on this (namely, our laws)." | 11:58 |
| psztorc | kanzure: There is this concept that society has a kind of evolutionary accumulation (something like "culture"). | 11:58 |
| psztorc | Right-libertarian economist Tom Sowell has written extensively about this...one book is Intellectuals and Society. | 11:59 |
| kanzure | how is it different from an argument from ignorance? | 12:00 |
| psztorc | No single individual can possess all of the info needed to determine, for example, what to do on a romantic date. The smart thing is to just take society's knowledge, ie older friends, tv shows, etc, and just copy that. | 12:01 |
| psztorc | It is different because you can observe x reliably, where x = "I thought I could come up with a better way, but I could not." | 12:01 |
| kanzure | i don't understand that example either! many people absolutely do determine what to do on a romantic date. how else are people sharing their company? | 12:01 |
| psztorc | X can be generalized, leading to so-called chaos theory. | 12:01 |
| psztorc | I mean, guidelines like "don't talk about politics", "wear nice clothes" or "don't expect to remain friends if you break up" stuff about how to "move on", etc. | 12:03 |
| kanzure | and an argument from ignorance is different because you cannot reliably observe that? | 12:03 |
| kanzure | thanks for the elaboration. | 12:04 |
| psztorc | Argument from ignorance attempts to conclude something that *isn't* "I don't know". This is more of an "I reject your conclusion, that you *do* know." | 12:04 |
| kanzure | oh i see. that is much more clear. | 12:05 |
| psztorc | It is a Karl Popper falsification, negative argument. | 12:05 |
| kanzure | yes i could spend all day typing about popperean epistemology stuff ... (in fact yesterday i was reading up on his constraint of deductive consistency and also eliminative inference (or was that eliminative interference)). | 12:06 |
| psztorc | He is certainly The Man. | 12:07 |
| coinoperated | the map is there for the benefit of those who haven't done the travelling, not the ones who have | 12:07 |
| psztorc | Final thought: https://en.wikipedia.org/wiki/Double_pendulum Imagine that someone claims they know the shape of the drawn line. Your response would be not be an 'argument from ignornace' it would be an 'argument of (universal) ignorance. | 12:08 |
| kanzure | also, lately i have taken to calling a fallacy a proof of failure of independent verification | 12:08 |
| -!- throughnothing [~throughno@2601:646:4001:f3d1:3cee:b9a6:943b:1165] has joined #bitcoin-wizards | 12:08 | |
| kanzure | but i'll stop mentioning that because worried that petertodd is gonna show up and insist i volunteer to only consider proofs of non-failure :) | 12:10 |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 12:10 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 12:14 | |
| -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Ping timeout: 240 seconds] | 12:14 | |
| -!- Heliox_ [~Heliox@unaffiliated/heliox] has joined #bitcoin-wizards | 12:14 | |
| -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-wizards | 12:18 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has quit [Remote host closed the connection] | 12:27 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] | 12:31 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 12:38 | |
| -!- vladzamfir [550718c9@gateway/web/freenode/ip.85.7.24.201] has joined #bitcoin-wizards | 12:39 | |
| vladzamfir | hey wizards | 12:40 |
| vladzamfir | thought you might have some questions about Casper, or maybe about why PoS works | 12:40 |
| vladzamfir | ;) | 12:40 |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 12:41 | |
| vladzamfir | i think the main misunderstanding that I always hear is about the authentication model, in security-deposit-based PoS | 12:42 |
| vladzamfir | clients must have the list of currently bonded validators, and they authenticate the consensus against that list, only ever relying on signatures from these validators | 12:42 |
| kanzure | http://gnusha.org/bitcoin-wizards/2015-12-29.log | 12:42 |
| vladzamfir | this makes SPV better, and prevents long range attack problems | 12:43 |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep] | 12:44 | |
| kanzure | see also https://download.wpsoftware.net/bitcoin/pos.pdf | 12:44 |
| instagibbs | vladzamfir, was the name "validator" deliberately chosen as a delegation to validate on those bonded parties | 12:44 |
| vladzamfir | yes - the whole point is that you have an economic assurance that they are validating correctly (if they don't, they lose their deposit) | 12:45 |
| instagibbs | or can we also say "chain voter" or something, for deciding ordering, but other full nodes can still validate everything | 12:45 |
| vladzamfir | and the assurance exists into the future | 12:45 |
| instagibbs | ok | 12:45 |
| vladzamfir | yeah i don't like to assume that clients ever process txs | 12:46 |
| AdrianG | oh nice | 12:46 |
| vladzamfir | light client is my religion | 12:46 |
| bsm117532 | vladzamfir: I'm not convinced PoS works at all... Would you like to address my comment on Vitalik's blog? | 12:47 |
| vladzamfir | i'd rather answer your question here ^_^ | 12:48 |
| bsm117532 | Ok | 12:48 |
| vladzamfir | lol @kanzure can't believe you linked me to Poelstra's paper | 12:50 |
| kanzure | have you read it? | 12:50 |
| vladzamfir | ofc | 12:51 |
| vladzamfir | see my comment about the authentication model of PoS | 12:51 |
| kanzure | if you are willing to use that authentication model then why bother with proof-of-stake at all? | 12:51 |
| vladzamfir | because PoS lets us rotate the set of validators without a network administrator | 12:52 |
| vladzamfir | and gives us an economic assurance that blocks in the consensus chain are valid | 12:52 |
| vladzamfir | that they won't be reverted | 12:53 |
| vladzamfir | etc | 12:53 |
| psztorc | even assuming that's true, PoW also allows you to do that, so you haven't answer the question | 12:53 |
| psztorc | I think. | 12:53 |
| bsm117532 | Only if you have a consensus on the state of the PoS contract, which you don't have. | 12:53 |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 12:54 | |
| vladzamfir | yeah PoW also does that, although not as elegantly - the aim is to have a consensus protocol that is cheap for everyone to secure except for an attacker during an attack | 12:54 |
| vladzamfir | at least, that's the ideal - we can't get exactly that, but we can try to get as close as possible | 12:54 |
| bsm117532 | https://blog.ethereum.org/2015/12/28/understanding-serenity-part-2-casper/#comment-2430757765 | 12:54 |
| -!- pozitron [~nu@162.216.46.34] has quit [Ping timeout: 272 seconds] | 12:54 | |
| psztorc | Again, though, until you define "cheap", I can say that PoW also does that. | 12:55 |
| AdrianG | vladzamfir: cheap for everyone except for the attacker in case of PoS sounds like automated blacklisting | 12:55 |
| vladzamfir | not really, PoW always spends more than attacker might at any time | 12:56 |
| vladzamfir | in PoS the cost most of the time will be the cost of capital (tx fees = interest rate on bonded stake) | 12:56 |
| instagibbs | bsm117532, I think it's along the lines of "make the time horizons really long so out of band we can pull the emergency fork lever" | 12:56 |
| vladzamfir | except when deposits are lost, in which case the cost is much higher | 12:56 |
| psztorc | That capital cost will still equal the issuance. | 12:57 |
| instagibbs | not that I'm satisfied with it, for other reasons. But these arguments are all quite well-worn. | 12:57 |
| psztorc | It will be just as "expensive" as PoW. | 12:57 |
| vladzamfir | assuming the issuance is the same | 12:57 |
| vladzamfir | but attacking it will be more expensive | 12:57 |
| bsm117532 | instagibbs: I think that's it too, and that's centralized control. But waiting to hear from vladzamfir. | 12:57 |
| vladzamfir | since losing a deposit will be more expensive | 12:57 |
| instagibbs | bsm117532, right, and I'd agree that's what it would degenerate too, just letting you know my interpretation since I've spent time reading their blog stuff :) | 12:58 |
| vladzamfir | >[21:53] <bsm117532> Only if you have a consensus on the state of the PoS contract, which you don't have. | 12:58 |
| vladzamfir | actually, you rely on this for PoW security, too - it's only secure inasfar as the issuance has a price, which it can't have unless there's consensus | 12:58 |
| psztorc | If one assumes that "a large double spend destroys the value of all mining hardware" then this is, again, also true of PoW. | 12:59 |
| vladzamfir | this self-bootstrapping is actually the most elegant part of PoW consensus imo | 12:59 |
| vladzamfir | yeah sure, if double-spending makes hardware self-destruct then great | 12:59 |
| vladzamfir | but i don't think you can guarantee that | 13:00 |
| vladzamfir | i can, in-protocol | 13:00 |
| psztorc | Sure, that's fine -- I just think we should all agree on what exactly the point of all of this is. | 13:00 |
| vladzamfir | me too ^_^ | 13:00 |
| psztorc | Which, according to you is, to make sure that { mining hardware } completely loses its value if there is a big reorg. | 13:00 |
| psztorc | Yes? | 13:00 |
| -!- dave4925 [dave4925@unaffiliated/dave4925] has joined #bitcoin-wizards | 13:01 | |
| psztorc | Where { mining hardware } can equal whatever you want. | 13:01 |
| vladzamfir | well what i want to do specifically is to cover byzantine faults with disincentives | 13:01 |
| bsm117532 | vladzamfir: since issuance always has a price in PoW, your argument reduces to agreement on the genesis block alone. | 13:01 |
| vladzamfir | reorgs are one thing | 13:01 |
| vladzamfir | there are others | 13:01 |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 13:02 | |
| psztorc | Vlad you're killing me here...."cover byzantine faults with disincentives" , again....PoW...also wants to do this. | 13:02 |
| vladzamfir | well no it doesn't have a price if the price of the tokens is zero, in which case the cost of the PoW will be very low, and it will be easy to attack | 13:02 |
| vladzamfir | but paul it doesn't do a great job | 13:02 |
| vladzamfir | if 80% of miners censor 20% of miners, they get a 25% raise | 13:02 |
| bsm117532 | disincentives don't remain constant and economic argument should be used as little as possible. Marginal price can become negative, and then the maximization process needed for consensus fails. So, I'm extremely skeptical of adding incentives and disincentives. | 13:02 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 13:03 | |
| psztorc | What if the 20% team up with 61% of those 80%, and tell the 61% that *they* can be in charge of the extra '80 bonus'? | 13:03 |
| psztorc | > ) | 13:03 |
| vladzamfir | the point is just that censorship isn't punished in-protocol | 13:04 |
| vladzamfir | but rather it's rewarded | 13:04 |
| psztorc | I can't agree. | 13:04 |
| vladzamfir | :) | 13:05 |
| vladzamfir | bsm: i think the economic argument is the main thing that ensures that things continue running smoothly into the future | 13:05 |
| bsm117532 | That's rather imprecise. | 13:06 |
| psztorc | The fact that Strategy X can be optimal, doesn't change the fact that "51% are in charge". | 13:06 |
| vladzamfir | paul, do you agree that we have a bigger design space, in security-deposit-based PoS than you do in PoW? | 13:06 |
| vladzamfir | yeah so 51% is the most profitable coalition | 13:06 |
| vladzamfir | (for PoW, not so in Casper) | 13:07 |
| psztorc | But if the 49% are sufficiently screwed, they can team up with 2 of the 51%, and reward that 2% outrageously. | 13:07 |
| psztorc | This is what that Cornell guy doesn't understand about selfish mining. | 13:07 |
| vladzamfir | yeah but the 51% can all place large deposits that get slashed if they leave the coalition, before forming it | 13:08 |
| vladzamfir | cartels learn how to punish defection | 13:08 |
| kanzure | the cornell guy from in here? | 13:08 |
| psztorc | Bigger design space...? I'm not sure. I will admit it is possible. | 13:08 |
| psztorc | The "bitcoin is broken" guy. | 13:08 |
| vladzamfir | emin gun sirer, i assume you mean | 13:08 |
| vladzamfir | i <3 him | 13:08 |
| vladzamfir | but yeah it's a strictly bigger design space because i can say what happens to the assets that are used as an anti-sybil mechanism | 13:09 |
| vladzamfir | whereas in PoW they are external to the protocol | 13:09 |
| waxwing | human politics has an absolutely huge design space | 13:09 |
| vladzamfir | and the role of the protocol developer is to take responsibility away from human politics :p | 13:10 |
| bsm117532 | There are an infinite number of ways to design something that fails to achieve consensus. | 13:10 |
| vladzamfir | we want to make sure that things last despite people's efforts to stop them | 13:10 |
| AdrianG | vladzamfir: it will boil down to arguments about what code will have to look like. | 13:10 |
| -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-ouppmgxlnnuqexsc] has joined #bitcoin-wizards | 13:10 | |
| AdrianG | sort of like we have arguments about legal "code" today. | 13:11 |
| AdrianG | PoW expenditures are external to software. | 13:11 |
| vladzamfir | are you making a "simpler is better" argument? | 13:11 |
| waxwing | the larger the number of parameters in a system design there are, the more brittle it is to failure | 13:11 |
| -!- fkhan_ [~weechat@unaffiliated/loteriety] has quit [Ping timeout: 272 seconds] | 13:12 | |
| AdrianG | vladzamfir: no. your entire design will be contained within your code. PoW hardware exists independently. | 13:12 |
| vladzamfir | yep | 13:12 |
| -!- brg444 [415ce066@gateway/web/freenode/ip.65.92.224.102] has quit [Ping timeout: 252 seconds] | 13:12 | |
| AdrianG | this way, it serves as a moderating influence, external to your software. a limit on what can be done with code. | 13:12 |
| -!- pozitrono [~nu@46.166.190.130] has joined #bitcoin-wizards | 13:12 | |
| psztorc | Ok, but, to stay on topic -- you want to make sure that { miners } are punished completely if they misbehave, and you want to "expand the design space". | 13:12 |
| psztorc | Yes? | 13:13 |
| -!- kmels [~kmels@120.62.151.186.static.intelnet.net.gt] has quit [Ping timeout: 276 seconds] | 13:13 | |
| vladzamfir | i think expanding the design space (specifically by giving the protocol control of the assets that act as an anti-sybil mechanism) makes it easier to make attacks expensive | 13:13 |
| vladzamfir | i just want it to be extremely expensive to attack | 13:14 |
| psztorc | So, the _entire_ purpose is to make attacks more expensive? | 13:14 |
| vladzamfir | and i also like the idea that the expense will benefit the people who are being attacked | 13:14 |
| psztorc | What about that thing where you wanted instant / guaranteed confirmations? | 13:14 |
| vladzamfir | that's most of the purpose ^_^ | 13:14 |
| vladzamfir | oh yeah i want fast finality | 13:15 |
| vladzamfir | but that's really just the same as making things really expensive/difficult to attack | 13:15 |
| kanzure | why is this not solved by centralization? | 13:15 |
| vladzamfir | b.c. it's easy to threaten the center | 13:15 |
| kanzure | perhaps that is where you should look | 13:16 |
| vladzamfir | ^_^ | 13:16 |
| bsm117532 | vladzamfir: Can you address my criticism that coins are not fungible between forks, and therefore cannot be used to bet? One needs an external source of consensus for this to work at all. | 13:16 |
| vladzamfir | the external source of consensus is the fact that everyone has to know who has deposits - the thing it relies on is that forks learn about each other | 13:17 |
| vladzamfir | i.e. if you place a bet on a block that isn't in this fork, this fork finds out so that you are punished in this fork | 13:17 |
| bsm117532 | So it only works as long as the deposits never change? | 13:17 |
| vladzamfir | no, the deposits change, but people need to know who is currently bonded | 13:17 |
| bsm117532 | Once I withdraw my bond, I can place a new one and generate two forks with different bets. | 13:18 |
| vladzamfir | no one cares about sigs from your unbonded validator | 13:18 |
| bsm117532 | I'm not making unbonded sigs... | 13:20 |
| psztorc | You know, if you don't mind, you should really list *all* of your purposes first. That way, we know what this conversation is actually about. | 13:20 |
| psztorc | Is the entire purpose of Ethereum's multimillion-dollar PoS research campaign, solely an effort to make sure that, in the event of a loss of consensus, the investment in 'mining hardware' really is fully lost? | 13:21 |
| vladzamfir | so then you're only signing with your bonded validator? you're going to lose money by doing that | 13:21 |
| bsm117532 | The question of fungibility is really the simplest way to state this, I think, and should be addressed directly. If there can ever exist two forks on which bonded validators have different numbers of coins, then your algorithm fails. And this must exist. | 13:21 |
| vladzamfir | lol paul i've been part-time the whole time, i guarantee you the pos budget is tiny | 13:21 |
| vladzamfir | i wish it wasn't | 13:21 |
| bsm117532 | vladzamfir: there are multiple forks. You can't move coins between forks, and this is why betting fails to achieve consensus. | 13:22 |
| vladzamfir | i don't want to commit to an exhaustive list of design goals because i might be able to think of new ones ;) | 13:22 |
| vladzamfir | right now i have | 13:22 |
| psztorc | Sorry to hear that re: budget . My intel is this document: http://www.truthcoin.info/images/IntendedUseOfRevenue.pdf | 13:22 |
| -!- fkhan_ [weechat@gateway/vpn/mullvad/x-fgvzvpcisbnqjtpl] has joined #bitcoin-wizards | 13:23 | |
| vladzamfir | cover byzantine faults with disincentives (i.e. make attacks expensive) - and to make attackers buy coins | 13:23 |
| vladzamfir | bsm not following your point here - you lose coins on both forks | 13:23 |
| bsm117532 | vladzamfir: Different forks have different values. There is no central source of "value". You can't make it "expensive" across all forks. | 13:24 |
| bsm117532 | I don't lose coins if I'm no longer a bonded validator on the fork. | 13:25 |
| bramc | I looked into those techniques before and they gave me the heebie jeebies. There are contrapositive attacks where you undo branches to 'trick' other people into 'double-spending' and thus steal from them | 13:25 |
| vladzamfir | you can't make a fork when you aren't bonded | 13:25 |
| vladzamfir | i don't understand | 13:25 |
| vladzamfir | :p | 13:25 |
| bramc | People who are bonded are the ones who can do this attack | 13:26 |
| bsm117532 | The length of the fork is the withdrawl period. | 13:26 |
| vladzamfir | yes, only the bonded are doing the attack | 13:26 |
| vladzamfir | and you release one fork after you are unbonded? | 13:27 |
| vladzamfir | the withdrawl period is defined in terms of RL time, not in terms of blocks, btw | 13:27 |
| bsm117532 | Doesn't matter. The fundamental fact is that you can't move coins between forks. | 13:27 |
| vladzamfir | you have a deposit on both | 13:28 |
| vladzamfir | you can lose it on both | 13:28 |
| vladzamfir | lol | 13:28 |
| bsm117532 | Not if you don't know about the other one. | 13:28 |
| bsm117532 | So you have to also have consensus on the state of all possible forks, to have consensus on one of them? | 13:28 |
| vladzamfir | lol, yeah so you keep a fork private | 13:28 |
| vladzamfir | block finality means that clients won't accept that fork | 13:28 |
| vladzamfir | so the price of everything on that fork is zero | 13:28 |
| bsm117532 | What is "block finality"? | 13:29 |
| vladzamfir | it's like how traditional consensus protocols commit to changes only when all correct clients will be certain that all correct clients will also make that change - they never revert | 13:30 |
| bsm117532 | No one is ever certain. A chain of any length can be reorged in principle. | 13:30 |
| vladzamfir | not when you have finality | 13:30 |
| vladzamfir | the fork-choice rule refuses to choose forks that don't include finalized blocks | 13:30 |
| bsm117532 | You're assuming consensus to get consensus. | 13:30 |
| bsm117532 | "finalizing" a block is externally imposing consensus. | 13:30 |
| vladzamfir | yeah and if it doesn't, then no one will be upset by the reorg because they knew it was possible | 13:31 |
| bsm117532 | What if there's a network split and the two sides finalize a different set of blocks? | 13:31 |
| vladzamfir | no it's subjectivity, actually | 13:31 |
| vladzamfir | then you have a consensus failure | 13:31 |
| bsm117532 | Ok so you admit your algorithm doesn't work. Bitcoin would reorg in that case. | 13:31 |
| bsm117532 | Network splits are real. | 13:32 |
| vladzamfir | yeah so you basically have to choose between having finality and having a reorg, in that case | 13:32 |
| vladzamfir | it's easy to modify casper to have a reorg, but i prefer to have finality, myself | 13:32 |
| vladzamfir | so that i can defend against a supermajority of the bonds making a fork in private | 13:33 |
| psztorc | bsm is saying that you could accidentally have two different finalities, for physics reasons | 13:33 |
| bsm117532 | You can't just impose consensus like that!!! | 13:33 |
| bsm117532 | You're failing number 5: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing | 13:33 |
| vladzamfir | paul it's not accidental, a supermajority of the bonded stake would need to participate to cause a consensus failure | 13:33 |
| vladzamfir | i'm comfortable with the fact that this can happen | 13:34 |
| vladzamfir | every traditional consensus protocol has this problem | 13:34 |
| bsm117532 | Bitcoin doesn't. | 13:34 |
| vladzamfir | which is why they rely on their fault tolerance assumptions | 13:34 |
| vladzamfir | yeah well bitcoin has a whole host of other problems instead | 13:34 |
| vladzamfir | like that 51% can revert blocks | 13:34 |
| vladzamfir | lol | 13:34 |
| bsm117532 | Ok I'm done. | 13:34 |
| helo | bless you... | 13:34 |
| vladzamfir | <3 | 13:35 |
| psztorc | Well so far the only difference is that, instead of using the military to take over large mining centers, a government will use the NSA to track down large holders of -coin. | 13:36 |
| psztorc | So my pointlessness-o-meter is still going off like crazy. | 13:36 |
| vladzamfir | if bitcoin has transaction finality it would have the consensus failure problem - you basically need to choose between blocks always possibly being reverted and having consensus failure if there's sufficient byzantine faults + a network partition | 13:36 |
| vladzamfir | oh it's much easier to hide coins than mining equipment | 13:37 |
| vladzamfir | but the difference is bigger than that | 13:37 |
| psztorc | What if miners installed thermite self-destructs on their miners, which they could trigger from their phone. Then no military would have anything to gain by swooping in. | 13:38 |
| psztorc | And I've only seriously been thinking about it for ~20 seconds. | 13:38 |
| helo | there is a frame of reference which will indicate some conflicting finality | 13:38 |
| vladzamfir | you only have conflicting finality with sufficient byzantine faults, and you still wouldn't be able to revert finalized blocks - paul i'm not seeing the point :) | 13:39 |
| vladzamfir | if the protocol can set off the thermite, then it's close to security-deposit based PoS | 13:40 |
| vladzamfir | but still not quite all the way there | 13:40 |
| vladzamfir | anyways paul i think the censorship thing is a good place to start, if you want to see the difference between PoS and PoW | 13:42 |
| vladzamfir | if 20% of the mining power is ignored, the protocol can't tell | 13:42 |
| vladzamfir | if 20% of the bonds are ignored, the protocol can tell | 13:42 |
| vladzamfir | it's actually surprising to me that you think in-protocol assets can be understood as behaving in exactly the same way as extra-protocol assets :D | 13:44 |
| bsm117532 | By adding "block finality" you are stating by fiat, without proof, that you achieved consensus. Clearly you do not, regardless of what else your protocol does. | 13:44 |
| AdrianG | so is block finality some sort of checkpoint? | 13:45 |
| vladzamfir | no? block finality only occurs when a supermajority (80%) of the bonds claim they are certain the block won't be reverted | 13:45 |
| vladzamfir | yeah it's like a checkpoint in the sense that clients don't revert | 13:46 |
| vladzamfir | so you need consensus to have finality | 13:46 |
| vladzamfir | that or a very large amount of faults | 13:47 |
| psztorc | Hey! This is what I said about the purposes. Now you're saying that you want "to prevent { miners } from censoring". | 13:47 |
| bsm117532 | So a much simpler algorithm is just to have nodes vote on every block and checkpoint every block. (Tendermint, I think) | 13:47 |
| vladzamfir | that's an example of the faulty behaviour i want to cover with disincentives | 13:47 |
| bsm117532 | Now to shut the entire system down I just need to partition off a minority (>21%) of validators. | 13:47 |
| bsm117532 | Bitcoin would continue in that circumstance. | 13:47 |
| vladzamfir | the important difference between tendermint and casper is that tendermint votes before the blocks are created, whereas casper bets afterwards | 13:47 |
| -!- digitalmagus8 [~digitalma@unaffiliated/digitalmagus] has quit [Ping timeout: 276 seconds] | 13:48 | |
| vladzamfir | bsm, unlike tendermint, casper can have nonfinalized blocks | 13:48 |
| vladzamfir | it doesn't halt when 21% go offline | 13:48 |
| psztorc | What was the point of asking us to talk about "making it extremely expensive to attack"? What is attack supposed to mean now? | 13:48 |
| -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has joined #bitcoin-wizards | 13:48 | |
| vladzamfir | there are three basic attacks - reverting history, censoring blocks, and preventing consensus | 13:48 |
| bsm117532 | psztorc: A better question is what does "expensive" mean when there are multiple versions of the ledger. => fungibility... | 13:48 |
| psztorc | In 5 minutes you'll say you didn't really care about censorship and that "it is really about" X. | 13:48 |
| -!- coinoperated [~coinopera@cpe-static-mountainintermodal-rtr.cmts.bus.ptd.net] has quit [Ping timeout: 264 seconds] | 13:49 | |
| bramc | fungibility seems to be non-negotiable. As soon as that falters confidence in the system plummets. | 13:49 |
| vladzamfir | oh paul, i've only ever appended to the list - and i did say that i want to cover faults with disincentives - you were the one who assumed that i only meant reversion | 13:50 |
| psztorc | I did assume that. Now you've listed your comprehsive set of attacks? | 13:50 |
| vladzamfir | it's not about fungibility, it's about having deposits on all forks | 13:51 |
| vladzamfir | tentatively, yes :) | 13:51 |
| psztorc | By "preventing consensus", you don't like mean 20 other things? | 13:51 |
| vladzamfir | in bitcoin preventing consensus means maintaining two forks that have the same total difficulty, in tendermint it means preventing 67% of validators from commiting to a block (perhaps by taking 34% offline) | 13:52 |
| bsm117532 | I'll take bitcoin's one-miner-online-and-it's-still-up guarantee over a 20% ddos risk. | 13:54 |
| -!- CubicEar_ [~cubiceart@2600:100f:b00c:c3cc:555d:e70c:881:a009] has joined #bitcoin-wizards | 13:54 | |
| vladzamfir | in casper, we have the property that if 1 validator online then it's still up | 13:54 |
| psztorc | Well, you are about to move the goalposts again. | 13:54 |
| vladzamfir | and we also don't get the blocks slowing to 1/year, like yo might in btc | 13:54 |
| bsm117532 | And you can't cover up consensus problems with incentives. For incentives to work, you have to start with a consensus on what the incentive is! | 13:54 |
| vladzamfir | well yeah the protocol defines the payouts | 13:55 |
| vladzamfir | we have consensus on the protocol | 13:55 |
| bsm117532 | Ok now I'm really done. vladzamfir you've failed to convince me. | 13:55 |
| vladzamfir | i never could have succeeded <3 | 13:56 |
| vladzamfir | have a nice day | 13:56 |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has quit [Ping timeout: 246 seconds] | 13:56 | |
| bsm117532 | Probably not, I still don't think PoS can work at all. It's by definition circular...defining value by using its value. | 13:56 |
| vladzamfir | yeah that's the elegant part | 13:57 |
| * zookolaptop reads with interest | 13:57 | |
| bsm117532 | No, that's a logical fallacy. | 13:57 |
| psztorc | Ok -- so the whole point of this is to 1. change from "assaulting the miners" to "assaulting the owners" and 2. make it easier to know when a { miner } is blocking someone else. | 13:57 |
| vladzamfir | no, bitcoin does the same thing and it worked really well - it's the best thing about nakamoto consensus | 13:57 |
| bsm117532 | *sigh* no it doesn't. | 13:57 |
| psztorc | How do you know if the miner is actually censoring, vs being DoS ed or his computer caught on fire or something. | 13:58 |
| vladzamfir | if the price of bitcoin was fixed at zero, the hashing power would fall and consensus would be lost | 13:58 |
| -!- hashtag [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has quit [Quit: Leaving] | 13:58 | |
| vladzamfir | paul - great observation, you don't | 13:58 |
| psztorc | Then how is PoS doing this impossible thing cheaper that PoW would do it? | 13:58 |
| vladzamfir | you punish people who go offline in case they went offline, and people who stayed online in case they censored the offline party | 13:58 |
| vladzamfir | PoW rewards it, actually :P block time retargets and the censoring coalition get a raise | 13:59 |
| zookolaptop | vladzamfir: thank you for explaining this stuff. | 13:59 |
| vladzamfir | <3 you zooko | 13:59 |
| zookolaptop | ❤ | 13:59 |
| -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards | 14:00 | |
| psztorc | PoS ... also rewards it? Didn't you just say? | 14:01 |
| vladzamfir | no...? we can tell when 20% drops off | 14:01 |
| vladzamfir | so we can punish it | 14:01 |
| psztorc | That DoS is same as censoring. | 14:01 |
| vladzamfir | yeah so, we also punish everyone when someone gets DoSd | 14:01 |
| psztorc | Not everyone (?) you mean all miners? | 14:02 |
| vladzamfir | the protocol can't tell the difference between a node going offline voluntarily and a node being censored | 14:02 |
| vladzamfir | yeah the validators | 14:02 |
| psztorc | How do you punish them? | 14:02 |
| vladzamfir | i can take away part of their deposits | 14:02 |
| bsm117532 | Who gets those deposits? | 14:03 |
| psztorc | So...now the attacker can just DoS everyone, as long as he is not a miner? | 14:03 |
| vladzamfir | great question bsm - it's a funny thing, when you have a public good spending problem, rather than a public good funding problem ;) basically taking the money away is a public good, but it's not clear where it should go | 14:04 |
| vladzamfir | yeah paul, that's a legitimate attack | 14:04 |
| zookolaptop | It goes to all current holders in proportion to their holdings. | 14:04 |
| vladzamfir | no it doesn't, zooko | 14:04 |
| zookolaptop | The real value does, that is, not any nominal value. | 14:04 |
| vladzamfir | that's if it's burned | 14:04 |
| zookolaptop | Oh, that's what I assumed happened. | 14:04 |
| vladzamfir | if we do that then if you have a large stake then you have an incentive to DoS validators | 14:05 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds] | 14:05 | |
| vladzamfir | but that is one thing we are considering | 14:05 |
| bsm117532 | No matter what you do with the deposits, it puts a lot of power in the hands of an attacker with the DDoS button. | 14:05 |
| zookolaptop | vladzamfir: what are the alternatives you're considering? | 14:05 |
| vladzamfir | yes, but there's a corresponding incentive not to get DoS'd | 14:05 |
| vladzamfir | giving it to the foundation, to a DAO, to the next set of bonded validators | 14:06 |
| bsm117532 | Punishing the victim... | 14:06 |
| vladzamfir | giving it to me ;) | 14:06 |
| vladzamfir | yeah well it's their responsibility to be online | 14:06 |
| vladzamfir | when your miner get DoS'd you also lose | 14:07 |
| bsm117532 | You're amplifying the damage. | 14:07 |
| vladzamfir | only other miners have a direct incentive to DoS you themselves | 14:07 |
| zookolaptop | bsm117532: I thought you already gave up on being persuaded that this PoS scheme is good. | 14:07 |
| vladzamfir | it's ok, it's just a validator - the protocol is meant to give guarantees to users, not validaotrs | 14:07 |
| bsm117532 | zookolaptop: Yeah but to get it to stop blinking I have to leave the room or quit IRC and I don't want to be sipa. ;-) But I probably should. I posted my question on the blog, I'd still appreciate a coherent answer. | 14:09 |
| zookolaptop | ☺ | 14:09 |
| bsm117532 | Without validators you have no system at all. | 14:09 |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 14:09 | |
| bsm117532 | *sigh* | 14:10 |
| -!- bsm117532 [~mcelrath@38.121.165.30] has left #bitcoin-wizards [] | 14:10 | |
| vladzamfir | yeah well we certainly need enough validators | 14:10 |
| -!- CubicEar_ [~cubiceart@2600:100f:b00c:c3cc:555d:e70c:881:a009] has quit [Read error: No route to host] | 14:10 | |
| vladzamfir | lolol :D | 14:10 |
| psztorc | I think it sounds fine to me. But the tradeoff is that total security will actually be lower tha PoW, because there will be the risk of a completely natural failure in connectivity, which will punish miners. Miners must be compensated for this risk. | 14:10 |
| vladzamfir | well if you believe that the average marginal return is the average marginal cost, then they will be | 14:11 |
| vladzamfir | no idea what you mean about the security being lower than PoW tho | 14:11 |
| psztorc | You've decreased the marginal revenue. | 14:11 |
| vladzamfir | yes but it's a known risk - the failure in connectivity also a problem for PoW miners | 14:11 |
| vladzamfir | since their blocks have a good chance of being orphaned | 14:11 |
| zookolaptop | I don't believe that's a major problem in the absence of malicious action. | 14:12 |
| zookolaptop | In either PoW or PoS. | 14:12 |
| psztorc | Your punishment is (effectively) comparable to an orphaned block? | 14:12 |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 14:12 | |
| zookolaptop | vladzamfir: I'm thinking about how burning the bond is problematic because it rewards | 14:12 |
| vladzamfir | perhaps :) | 14:12 |
| zookolaptop | big stakeholders and therefore can incentivize them to attack (DoS) validators, | 14:12 |
| zookolaptop | and your proposed alternative of giving the bond to someone else therefore | 14:13 |
| zookolaptop | incentivizes whoever else that is, right? | 14:13 |
| vladzamfir | yes, that's right | 14:13 |
| vladzamfir | but i certainly would never stoop to such low levels ;) | 14:13 |
| zookolaptop | So are you thinking by picking someone -- a DAO or whatever -- you can pick someone incorruptible by such incentives? | 14:13 |
| vladzamfir | it's partly a joke, but yes we are thinking about it | 14:13 |
| zookolaptop | Because my opinion is that the marginal benefit is so small when it is distributed evenly to all stakeholders that it won't incentivize bad behavior. | 14:13 |
| vladzamfir | yeah i like to assume that a supermajority of coins are owned by an adversary, because why not | 14:14 |
| zookolaptop | *thinks* | 14:14 |
| zookolaptop | I don't think the effect of that burning of bond changes their calculus much even then ? | 14:14 |
| vladzamfir | well they benefit more than anyone else if there are consensus problems | 14:15 |
| zookolaptop | Especially if you factor in that DoS'ing validators could depress the exchange rate between the coin and other things ?? | 14:15 |
| zookolaptop | Saying they benefit more than anyone else isn't sufficient to show that this is a problem. | 14:15 |
| vladzamfir | well i don't like to assume that the price of the underlying asset changes in a predictable way in response to attacks | 14:15 |
| zookolaptop | They might still benefit so little that it isn't a problem. | 14:15 |
| zookolaptop | Why not? | 14:15 |
| vladzamfir | because it's too convenient | 14:16 |
| vladzamfir | and because i want to take responsibility in-protocol | 14:16 |
| vladzamfir | not assume away responsibilities by saying things about extra-protocol prices | 14:16 |
| zookolaptop | Well, even with all of those ways that you want to tie your own hands behind your back, it still boils down to whether "whoever is the biggest, or a big stakeholder", or "whoever controls this very special signing key" is more corruptible. | 14:16 |
| zookolaptop | IMHO the latter is more corruptible. | 14:17 |
| vladzamfir | yeah i understand your perspective | 14:17 |
| zookolaptop | It seems to me entirely reasonable and in fact inevitable that the biggest — or a big — stakeholder is more likely to be incentivized to do things that improve the value of the system than that harm it. | 14:18 |
| vladzamfir | but we're working from inside the ethereum community, where at least atm there are sources of trust, and this is a super rare opportunity: funds generated by a public good | 14:18 |
| vladzamfir | yeah i understand that | 14:18 |
| zookolaptop | If the opposite, then maybe that means nobody cares enough about your system and it is okay if it breaks? | 14:18 |
| vladzamfir | but we also have a public goods funding problem with respect to core development | 14:18 |
| zookolaptop | Yeah. | 14:18 |
| vladzamfir | so it would be cool if.. | 14:18 |
| zookolaptop | I'm also doing a thing -- not yet publicly explained in detail but soon -- | 14:18 |
| zookolaptop | that does something like that, although that is a time-limited thing that we're doing, for the first four years. | 14:19 |
| vladzamfir | interesting - yeah this might be time-limited, too | 14:19 |
| vladzamfir | because we have lots of hard forks to go | 14:19 |
| zookolaptop | I basically think the "controller of the special signing key" *is* better than a lot of options, for the first few years, but given enough time and chaos, then that is worse. :-) | 14:19 |
| zookolaptop | Sorry to be negative, but, you know, the center cannot hold and all that. | 14:20 |
| vladzamfir | yeah i feel the same way about giving it to stakeholders | 14:20 |
| zookolaptop | Really? | 14:20 |
| zookolaptop | It seems to me that large stakeholders almost always have incentives aligned with "general social good of all users"./ | 14:20 |
| zookolaptop | Am I being naive? | 14:20 |
| zookolaptop | Wait | 14:20 |
| zookolaptop | I don't mean *all* incentives, | 14:20 |
| vladzamfir | yeah of course - the longer things go, the more likely the coins are to fall into the hands of an adversary, and the less the coin's price will react to DDoS' | 14:20 |
| zookolaptop | I mean just with regard to "stuff that increases or reduces the value of the system to everyone at once". | 14:20 |
| bramc | Large thieving stakeholders are incentivized to not thieve so much that they kill the whole system | 14:21 |
| zookolaptop | Which I *think* is roughly what we're talking about here wrt DoS of validators, but I could be oversimplifying. | 14:21 |
| zookolaptop | bramc: that's Mancur Olson's "stationary bandits" | 14:21 |
| vladzamfir | yeah i just don't like to assume that the people who hold the coins have the protocol's guarantees in mind | 14:21 |
| vladzamfir | i treat everyone but users as potential adversaries | 14:22 |
| vladzamfir | (especially validators) | 14:22 |
| zookolaptop | vladzamfir: well it sounds like currently your choice is assuming that, or else assuming that the holders of a few special signing keys have? | 14:22 |
| vladzamfir | but i treat users as gods ^_^ | 14:22 |
| zookolaptop | Have the protocol's best interests in mind? | 14:22 |
| vladzamfir | yeah | 14:22 |
| vladzamfir | it's either that or burning it :/ | 14:22 |
| zookolaptop | Also I think it is likely that there won't be any single entity/coalition that has a huge stake compared to everyone-else. | 14:23 |
| vladzamfir | really? | 14:23 |
| MRL-Relay | [othe] exchanges will have. | 14:23 |
| zookolaptop | That's the "inequality metric". How does it apply to Bitcoin today? | 14:23 |
| vladzamfir | yeah, exchanges, large stakeholders | 14:23 |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has quit [Remote host closed the connection] | 14:23 | |
| vladzamfir | i think probably there will be <50 people with >80% of the stake for a long time | 14:23 |
| zookolaptop | The largest stakeholder is the so-called Satoshi mined coins -- about ⓑ1M ? | 14:23 |
| vladzamfir | just a power law thing | 14:23 |
| zookolaptop | Out of about ⓑ15M? | 14:23 |
| vladzamfir | that's a lot, and there are a large handful of people with >100K | 14:24 |
| zookolaptop | vladzamfir: I agree with that, but that's consistent with my claim that there's no single person/org/coalition with, like, .. a lot. | 14:24 |
| zookolaptop | I mean, if it has that sort of power law distribution, like current Bitcoin, or current USD, or whatever, | 14:24 |
| vladzamfir | yeah so that means that there's a small coalition with a lot, doesn't it? | 14:24 |
| zookolaptop | then the person/coalition with the *most* stake still gives like 80% or 90% of the reward to random other people, in the "burn the bond" scenario. Right? | 14:25 |
| zookolaptop | I guess we're differing on our ideas about how much "a lot" is, and how big effective coalitions could be for this purpose. | 14:25 |
| vladzamfir | oh no so the people with stake are not the people with deposits | 14:25 |
| zookolaptop | Oh, right. | 14:25 |
| vladzamfir | ideally deposits would be a teeny tiny fraction of the coins | 14:26 |
| zookolaptop | That changes it, because someone who controls "merely" 1% of all the Vladcoin can invest and get 90% of all the bonds? | 14:26 |
| zookolaptop | No, wait. | 14:26 |
| vladzamfir | yeah sure | 14:26 |
| zookolaptop | The transfer of value in the burn-the-bonds approach is to *all* holders of all Vladcoins! | 14:26 |
| vladzamfir | yep :p | 14:26 |
| zookolaptop | So yeah, it seems to me unlikely that any particular org or coalition would receive more than a small fraction of that largess. | 14:26 |
| -!- Souptacular [6bdcb109@gateway/web/freenode/ip.107.220.177.9] has joined #bitcoin-wizards | 14:27 | |
| vladzamfir | assuming that an adversary doesn't have a large stake yeah | 14:27 |
| vladzamfir | or, i mean, a small coalition | 14:27 |
| zookolaptop | IIUC you earlier said you want to design for the case that an adversary controls a great majority of all the Vladcoins? | 14:27 |
| vladzamfir | yep :) | 14:27 |
| zookolaptop | I don't think I'm very interested in defending in that scenario. Doesn't that basically mean your adversary already won? He's by far the richest person on planet Vlad? | 14:27 |
| zookolaptop | He can just retire to an island fortress and torture Vlad day and night for fun? | 14:28 |
| vladzamfir | well no, winning means censoring, reverting blocks or preventing consensus | 14:28 |
| zookolaptop | Oh I privmsged you a while back but I don't know if freenode servers send those through in all cases ... | 14:28 |
| zookolaptop | Well, I think if he's the richest person on planet Vlad, then he's going to succeed at those other goals if he wants to. | 14:28 |
| -!- Jeremy_Rand_2 [~user@ip68-97-45-209.ok.ok.cox.net] has joined #bitcoin-wizards | 14:29 | |
| vladzamfir | well i want to make it as expensive for him as possible | 14:29 |
| zookolaptop | Okay, but you still lose? | 14:29 |
| vladzamfir | yeah ^_^ | 14:29 |
| vladzamfir | but he can't revert finalized blocks | 14:29 |
| zookolaptop | Hm. | 14:29 |
| zookolaptop | Okay, my brain is tired. Thanks for patiently explaining this much. | 14:29 |
| vladzamfir | my pleasure zooko, you're the best | 14:30 |
| zookolaptop | http://growingleaders.com/blog/wp-content/uploads/2011/01/my-brain-is-full.jpg | 14:30 |
| phantomcircuit | vladzamfir, can you describe the exact changes to the security model | 14:31 |
| phantomcircuit | compared to bitcoin that is | 14:31 |
| vladzamfir | sure, the main thing is that clients must know the set of currently bonded validators, instead of the genesis block | 14:32 |
| vladzamfir | well, that really is the only fundamental change | 14:32 |
| vladzamfir | economic proofs in PoW are chains of work, in PoS they are signatures that affect the payoffs of validators | 14:33 |
| vladzamfir | the affect of faults is different, too - you can't just revert arbitrarily many blocks with 51% (or 33% if selfish mining ;) ), it's more complicated than that | 14:34 |
| vladzamfir | but really the different authentication model is the critical thing to understand | 14:35 |
| vladzamfir | having current information is arguably more difficult than having a genesis block | 14:35 |
| vladzamfir | but it also makes economic proofs much more concise | 14:35 |
| vladzamfir | and we don't need to store the whole blockchain | 14:35 |
| vladzamfir | which is a relief | 14:35 |
| -!- go1111111 [~go1111111@104.232.116.217] has quit [Ping timeout: 255 seconds] | 14:40 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards | 14:42 | |
| -!- kmels [~kmels@120.62.151.186.static.intelnet.net.gt] has joined #bitcoin-wizards | 14:47 | |
| -!- Jeremy_Rand_2 [~user@ip68-97-45-209.ok.ok.cox.net] has quit [Ping timeout: 265 seconds] | 14:48 | |
| -!- Jeremy_Rand_2 [~user@ip68-97-45-209.ok.ok.cox.net] has joined #bitcoin-wizards | 14:52 | |
| phantomcircuit | <vladzamfir> and we don't need to store the whole blockchain | 14:54 |
| phantomcircuit | if bitcoin nodes were to make the same trade off that you have describes your PoS system uses then they wouldn't have to either | 14:55 |
| vladzamfir | not sure i agree - you do need to store the block headers | 14:55 |
| vladzamfir | i have to go to bed, tho - it's past my bedtime in europe :) gn heros | 14:56 |
| -!- go1111111 [~go1111111@50.248.197.241] has joined #bitcoin-wizards | 14:57 | |
| -!- coinoperated [~coinopera@70.15.164.106.res-cmts.t132.ptd.net] has joined #bitcoin-wizards | 15:01 | |
| phantomcircuit | vladzamfir, no actually you dont | 15:06 |
| -!- jeremyrubin [~jeremyrub@biohazard-cafe.mit.edu] has quit [Quit: Lost terminal] | 15:06 | |
| -!- neha_ [~narula@mint-square.mit.edu] has quit [Quit: Lost terminal] | 15:07 | |
| -!- go1111111 [~go1111111@50.248.197.241] has quit [Ping timeout: 250 seconds] | 15:09 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] | 15:09 | |
| -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-wizards | 15:09 | |
| -!- tripleslash_q [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 260 seconds] | 15:11 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Read error: Connection reset by peer] | 15:14 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 15:14 | |
| -!- jcorgan is now known as jcorgan|away | 15:18 | |
| -!- Souptacular [6bdcb109@gateway/web/freenode/ip.107.220.177.9] has quit [Quit: Page closed] | 15:22 | |
| -!- go1111111 [~go1111111@104.232.116.217] has joined #bitcoin-wizards | 15:22 | |
| -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:b8e2:1c9c:fe32:8ba2] has quit [Ping timeout: 260 seconds] | 15:26 | |
| -!- throughnothing [~throughno@2601:646:4001:f3d1:3cee:b9a6:943b:1165] has quit [Quit: Leaving...] | 15:31 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has joined #bitcoin-wizards | 15:33 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has quit [Remote host closed the connection] | 15:33 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has joined #bitcoin-wizards | 15:34 | |
| -!- NewLiberty [~NewLibert@rrcs-74-87-213-251.west.biz.rr.com] has joined #bitcoin-wizards | 15:34 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 15:35 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has quit [Remote host closed the connection] | 15:36 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has joined #bitcoin-wizards | 15:36 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] | 15:43 | |
| -!- wallet42 [~wallet42@nz112l10.bb11352.ctm.net] has quit [Ping timeout: 240 seconds] | 15:46 | |
| bramc | Preliminary results of my going over petertodd's selfish mining stuff: His exact calculation is wrong, but his central thesis - that a miner or coalition of miners can get ahead by withholding successful blocks strategically - is basically correct. The threshold appears to be 1/3 (I'm using monte carlo so it isn't entirely clear) and things get gnarly by 40%. It isn't the case that slowing propagation helps though. I'll | 15:53 |
| bramc | make a much more detailed writeup when I'm done with this. | 15:53 |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 15:57 | |
| zookolaptop | vladzamfir: this is still bothering my brain. If your adversay controls, let's say, 50% of all the Vladcoin on Planet Vlad, and your system either transfers the value of the forfeited bond to all stakeholders, | 16:01 |
| zookolaptop | so 50% to your adversary, and the rest to a bunch of other folks, or | 16:01 |
| zookolaptop | else your system transfers the value of the forfeited bond to some special designated | 16:02 |
| zookolaptop | beneficiary, | 16:02 |
| zookolaptop | then my question is: how much does it cost to subvert that designated beneficiary? | 16:02 |
| -!- jcorgan|away is now known as jcorgan | 16:03 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 16:10 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has quit [Remote host closed the connection] | 16:11 | |
| -!- Guyver2 [~Guyver2@a80-100-156-239.adsl.xs4all.nl] has quit [Quit: :)] | 16:12 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards | 16:13 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit] | 16:16 | |
| petertodd | bramc: cool, email me your draft when it'sready | 16:19 |
| AdrianG | bramc: where are you going to publish the write up? | 16:20 |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has quit [Remote host closed the connection] | 16:21 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] | 16:21 | |
| -!- psztorc [4575fa8d@gateway/web/freenode/ip.69.117.250.141] has quit [Ping timeout: 252 seconds] | 16:28 | |
| -!- pozitrono [~nu@46.166.190.130] has quit [Ping timeout: 260 seconds] | 16:28 | |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Remote host closed the connection] | 16:32 | |
| JackH | <JackH> anyone know of some crazy implementation of bitcoin in an altcoin? for example, with new op_codes that does something, or with some new features? the closest I come to anything is the sidechains protocol. | 16:33 |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards | 16:34 | |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has joined #bitcoin-wizards | 16:34 | |
| bramc | AdrianG, Probably my blog or medium | 16:35 |
| JackH | hi bramc, what was the eventual conclusion on that whitepaper? is there anything substantial to it? | 16:35 |
| bramc | JackH, If you mean the one on hash tubes, I think it has an interesting idea but nothing important to add yet. | 16:37 |
| JackH | alright, thanks bramc | 16:38 |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] | 16:41 | |
| dcousens | Anyone available to review a coinswap alternative I'm looking at implementing? | 16:43 |
| -!- OneFixt [~OneFixt@unaffiliated/onefixt] has joined #bitcoin-wizards | 16:45 | |
| kanzure | better to just post a link instead of asking | 16:45 |
| dcousens | kanzure: sure, https://gist.github.com/dcousens/1287ead78b1104ba5c95 - best viewed using the viewer at https://stackedit.io/editor# due to the sequence diagrams rendering, but, thats up to the reader | 16:51 |
| -!- cheetah2 [~cheetah2@172.242.102.144] has joined #bitcoin-wizards | 16:54 | |
| -!- alpalp [~alp@104-54-235-28.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards | 16:55 | |
| -!- go1111111 [~go1111111@104.232.116.217] has quit [Ping timeout: 256 seconds] | 16:56 | |
| bramc | petertodd, Sure, still working on it. I'm specifically not going to work out some of the math, so finding closed form rather than monte carlo solutions would be much appreciated. | 16:56 |
| kanzure | unclear to me if you have seen some of the selfish mining papers | 16:58 |
| kanzure | or block withholding papers | 16:58 |
| dcousens | kanzure: me or bramc ? | 16:58 |
| kanzure | bramc | 16:58 |
| bramc | kanzure, I haven't, I'm working off http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.html | 16:59 |
| kanzure | i am really bad at making good assumptions about what bramc has seen or not seen :-) | 16:59 |
| bramc | What I've seen is somewhat random and nonsensical | 16:59 |
| bramc | A lot of it is links people gave me in this channel | 17:00 |
| kanzure | http://diyhpl.us/~bryan/papers2/bitcoin/Optimal%20selfish%20mining%20strategies%20in%20bitcoin.pdf | 17:00 |
| kanzure | http://diyhpl.us/~bryan/papers2/bitcoin/Stubborn%20mining:%20Generalizing%20selfish%20mining%20and%20combining%20with%20an%20eclipse%20attack.pdf | 17:01 |
| kanzure | http://diyhpl.us/~bryan/papers2/bitcoin/On%20subversive%20miner%20strategies%20and%20block%20withholding%20attack%20in%20Bitcoin%20digital%20currency.pdf | 17:01 |
| kanzure | http://diyhpl.us/~bryan/papers2/bitcoin/Majority%20is%20not%20Enough:%20Bitcoin%20Mining%20is%20Vulnerable.pdf | 17:02 |
| kanzure | and was of course briefly mentioned in amiller's SoK paper http://www.ieee-security.org/TC/SP2015/papers-archived/6949a104.pdf http://diyhpl.us/~bryan/papers2/bitcoin/Research%20perspectives%20and%20challenges%20for%20Bitcoin%20and%20cryptocurrencies.pdf | 17:04 |
| -!- shesek [~shesek@bzq-84-110-208-231.red.bezeqint.net] has quit [Ping timeout: 265 seconds] | 17:06 | |
| -!- shesek [~shesek@bzq-84-110-208-231.cablep.bezeqint.net] has joined #bitcoin-wizards | 17:07 | |
| -!- go1111111 [~go1111111@104.232.116.217] has joined #bitcoin-wizards | 17:09 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] | 17:14 | |
| bramc | I don't understand the bizarre pseudocode which academics use in papers. What's wrong with Python? | 17:15 |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 17:15 | |
| dcousens | bramc: whats more annoying is when they include pseudo-code for very common algorithms not relevant to their work | 17:15 |
| dcousens | what ever happened to just using the built-ins or an #include of the std-lib | 17:16 |
| bramc | There appears to be some 'real' standard the pseudocode is supposed to conform to, even though nothing actually runs it and it doesn't have any particular expressive power. | 17:17 |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 17:17 | |
| -!- go1111111 [~go1111111@104.232.116.217] has quit [Ping timeout: 256 seconds] | 17:21 | |
| -!- go1111111 [~go1111111@104.232.116.217] has joined #bitcoin-wizards | 17:23 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection] | 17:25 | |
| -!- adam3us1 [~Adium@host-92-18-110-49.as13285.net] has joined #bitcoin-wizards | 17:25 | |
| -!- adam3us [~Adium@host-92-18-110-107.as13285.net] has quit [Ping timeout: 256 seconds] | 17:26 | |
| -!- adam3us1 [~Adium@host-92-18-110-49.as13285.net] has quit [Client Quit] | 17:27 | |
| -!- adam3us [~Adium@host-92-18-110-49.as13285.net] has joined #bitcoin-wizards | 17:27 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has quit [Remote host closed the connection] | 17:28 | |
| bramc | Okay, so what I've come up with is a reinvention of the algorithm by Eyal and Sirer | 17:28 |
| -!- cheetah2 [~cheetah2@172.242.102.144] has joined #bitcoin-wizards | 17:33 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has quit [Remote host closed the connection] | 17:35 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has joined #bitcoin-wizards | 17:36 | |
| -!- tromp_ [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 17:37 | |
| * nsh smiles | 17:38 | |
| -!- Monthrect is now known as Piper-Off | 17:38 | |
| nsh | of the 'bitcoin [mining | 17:38 |
| nsh | ] is broken' paper? | 17:38 |
| nsh | .title http://hackingdistributed.com/2013/11/04/bitcoin-is-broken/ | 17:39 |
| yoleaux | Bitcoin Is Broken | 17:39 |
| nsh | -> http://arxiv.org/pdf/1311.0243v5.pdf | 17:39 |
| -!- archobserver [~archobser@unaffiliated/superobserver] has joined #bitcoin-wizards | 17:40 | |
| bramc | I don't understand the claim in that paper that 'under current conditions any size mining pool can effectively collude' | 17:46 |
| -!- tripleslash_i [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-wizards | 17:48 | |
| -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 265 seconds] | 17:49 | |
| -!- JackH [~Jack@host-80-43-143-141.as13285.net] has quit [Ping timeout: 264 seconds] | 17:57 | |
| -!- Dizzle_ [~Dizzle@2605:6000:1018:c0b1:ed32:6ea8:eebc:fa06] has joined #bitcoin-wizards | 17:57 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has quit [Remote host closed the connection] | 18:00 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has joined #bitcoin-wizards | 18:02 | |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vapnjrtrmcjveeso] has quit [Quit: Connection closed for inactivity] | 18:04 | |
| -!- Dizzle_ [~Dizzle@2605:6000:1018:c0b1:ed32:6ea8:eebc:fa06] has quit [Remote host closed the connection] | 18:10 | |
| AdrianG | i think it just means there is nothing in the protocol that prevents collusion. | 18:12 |
| alpalp | Nor is there any way to identify it | 18:16 |
| bramc | A high orphan rate would be a red flag | 18:16 |
| -!- AaronvanW [~ewout@2001:67c:20a1:1192:1d38:1e26:9078:1d4b] has joined #bitcoin-wizards | 18:21 | |
| -!- AaronvanW [~ewout@2001:67c:20a1:1192:1d38:1e26:9078:1d4b] has quit [Changing host] | 18:21 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 18:21 | |
| coinoperated | could be masked if colluders slowly ramped up orphan rate artificially ahead of collusion | 18:22 |
| coinoperated | but good catch | 18:22 |
| -!- NewLiberty [~NewLibert@rrcs-74-87-213-251.west.biz.rr.com] has quit [Ping timeout: 256 seconds] | 18:22 | |
| -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving] | 18:24 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has quit [Remote host closed the connection] | 18:25 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has joined #bitcoin-wizards | 18:27 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has joined #bitcoin-wizards | 18:31 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] | 18:45 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has quit [Remote host closed the connection] | 18:50 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has joined #bitcoin-wizards | 18:53 | |
| -!- p15 [~p15@87.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-wizards | 18:56 | |
| -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has quit [Quit: Page closed] | 19:00 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has quit [Remote host closed the connection] | 19:01 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has joined #bitcoin-wizards | 19:03 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 19:10 | |
| -!- Yoghur114_2 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection] | 19:18 | |
| bramc | It would be highly ballsy to pull off a withholding attack in practice. If you had, say, 40% of mining power, you'd have to go a full cycle (actually a bit longer, because you slowed it down) earning 20% less than usual, to make 10% more on subsequent cycles, so you'd be talking six weeks from the start to make break-even, assuming that no big increases in hashpower happened in the interim | 19:21 |
| bramc | But if you think hash power will stay stable for the next 3 months or so and have 40% of hash power you can pull it off, assuming your margins are big enough to be able to handle a massive hit for a cycle. | 19:22 |
| -!- Jeremy_Rand_2 [~user@ip68-97-45-209.ok.ok.cox.net] has quit [Remote host closed the connection] | 19:23 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] | 19:23 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has quit [Remote host closed the connection] | 19:28 | |
| -!- Jeremy_Rand_2 [~user@ip68-97-45-209.ok.ok.cox.net] has joined #bitcoin-wizards | 19:29 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has joined #bitcoin-wizards | 19:31 | |
| CubicEarth | phantomcircuit: "Weak blocks are useless under adversarial conditions." So are strong blocks | 19:33 |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 19:37 | |
| -!- brg444 [415ce066@gateway/web/freenode/ip.65.92.224.102] has joined #bitcoin-wizards | 19:37 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has quit [Remote host closed the connection] | 19:38 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds] | 19:40 | |
| bramc | Another pet peeve: Latin letters. What's wrong with english ones? | 19:41 |
| -!- cheetah2 [~cheetah2@172.242.102.144] has joined #bitcoin-wizards | 19:45 | |
| -!- Cory [~C@unaffiliated/cory] has joined #bitcoin-wizards | 19:48 | |
| bramc | Quick summary of the more sophisticated selfish mining papers: Very modest improvements are possible | 19:51 |
| bramc | The discussion of γ is not helpful. If you assume an attacker can notice when someone else is publishing a block and front-run they of course you're fucked | 19:57 |
| bramc | In practice there's the high speed relay network and the mining pools are probably directly connected to each other, so the value of it is close to 0 | 19:59 |
| kanzure | why bother complaining about latin vs english letters when you could just insist on actual variable names? even relevant variable names. | 19:59 |
| -!- bildramer [~bildramer@p5DC8ADCC.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds] | 20:04 | |
| -!- bildramer [~bildramer@p5DC8ADCC.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 20:04 | |
| bramc | Hey man, the time it takes to type in variable names in papers is a big part of the time it takes to write them. Shaving off letters matters! | 20:04 |
| -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-wizards | 20:07 | |
| -!- tripleslash_i [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 265 seconds] | 20:08 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has quit [Remote host closed the connection] | 20:09 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has joined #bitcoin-wizards | 20:09 | |
| -!- GGuyZ [~GGuyZ@216-15-125-203.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com] has quit [Quit: GGuyZ] | 20:11 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 20:17 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has quit [Remote host closed the connection] | 20:18 | |
| -!- fwefwefew [b8a0d889@gateway/web/freenode/ip.184.160.216.137] has joined #bitcoin-wizards | 20:19 | |
| -!- fwefwefew [b8a0d889@gateway/web/freenode/ip.184.160.216.137] has quit [Client Quit] | 20:20 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] | 20:23 | |
| -!- wallet42 [~wallet42@014136144048.static.ctinets.com] has joined #bitcoin-wizards | 20:33 | |
| -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-wizards | 20:33 | |
| bramc | And of course the Majority is not Enough paper was already next up on my list of papers to read | 20:34 |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 260 seconds] | 20:35 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 20:36 | |
| -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-wizards | 20:36 | |
| tulip | bramc: I don't blame you for not noticing, but nobody actually keeps track of stale blocks. | 20:36 |
| coinoperated | if you are composing in LaTeX you aren't concerned about speed anyway | 20:38 |
| bramc | Since that's already been analyzed to death, next step for me is to analyze whether it really is beneficial to have one's blocks propagate more slowly. I suspect not, but the papers don't address that one directly and since the claim has been made that it is, so I should do a thorough analysis because I think that's wrong | 20:39 |
| tulip | in all probability nobody would catch the vast majority of attacks against the network. | 20:39 |
| bramc | tulip, That's unfortunate | 20:39 |
| aj | bramc: you mean greek letters, surely | 20:39 |
| tulip | bramc: I doubt anybody would care anyway. | 20:39 |
| bramc | aj, Is that what those are? Not cyrilic? | 20:39 |
| bramc | tulip, People wouldn't get concerned if there was a 20% orphan rate? | 20:40 |
| tulip | cyrillic shares some of the same characters as greek, but usually in papers it's going to be greek. | 20:40 |
| tulip | bramc: in 2013 a pool had an abysmal stale rate, nobody cared. people still happily mined with them. | 20:40 |
| bramc | *sigh* | 20:41 |
| tulip | miners still used the pool which admitted to Finney attacking! | 20:41 |
| aj | bramc: selfish mining with 40% hashpower (and without effective countermeasures) gives you ~100% of blocks though doesn't it? | 20:41 |
| aj | bramc: that's just \gamma isn't it? | 20:41 |
| tulip | ф Φ | 20:42 |
| tulip | ^ spot the greek | 20:43 |
| coinoperated | you pointed to it | 20:43 |
| -!- heyrhett [~rhett@c-73-223-86-218.hsd1.ca.comcast.net] has quit [Quit: Leaving] | 20:44 | |
| tulip | the right is Greek phi, left is Cyrillic ef | 20:44 |
| bramc | aj: \gamma is a representation of how effective your front-running is, that is assuming that you have a setup where whenever a block is published you notice fast and spam yours out quick to beat it | 20:44 |
| coinoperated | and everyone else 100% orphans, i think they would get concerned pretty fast. wonder how long it would be written off as bad luck | 20:45 |
| tulip | coinoperated: a private pool mined *invalid* blocks for a week at several petahash. | 20:45 |
| tulip | nobody noticed. | 20:45 |
| bramc | Hey, here's an idea: Use weak block height as a tiebreak on near-equal time arrived sibling blocks | 20:45 |
| petertodd | bramc: not enforceable | 20:45 |
| bramc | petertodd, Neither is anything about picking between sibling blocks | 20:46 |
| aj | bramc: most work is enforcable | 20:46 |
| petertodd | bramc: indeed, now there may be a incentive there if you think it has propagated more widely, but that'sa very complex question | 20:47 |
| coinoperated | tulip, don't they have bills to pay? Or is the mine-to-market meme debunked now | 20:47 |
| aj | bramc: but weak blocks have the same height as the strong block that replaces them, so i don't see how that works? | 20:47 |
| -!- royce [~royce@50.153.175.69] has joined #bitcoin-wizards | 20:47 | |
| tulip | right now I'm looking at the control interface of a private pool with a 5% stale rate. | 20:47 |
| tulip | nobody cares. | 20:47 |
| aj | bramc: maybe prefer the strong block whose weak block you saw first? | 20:47 |
| bramc | So the thing with \gamma is that if it's 100% then trivially selfish mining works, and making any assumptions about its value at all is presuming a fairly effective attack | 20:48 |
| petertodd | tulip: indeed, which means we need a system where lazy people like that pool don't end uppunishing others' for their lazyness | 20:48 |
| -!- royce [~royce@50.153.175.69] has quit [Quit: Leaving] | 20:49 | |
| petertodd | bramc: fwiw, my conjunctor is that if selfish mining is possible through sybil, you're in a situation where you're fucked anyway | 20:49 |
| bramc | aj, The idea here is that you want to stop somebody from front-running, so what you do is say that if two blocks arrive within, say, 5 seconds of each other, and the second one is based off 2 weak blocks more than the first, then the second one wins. That would make there only be a narrow window in which you could even dream of having gamma | 20:49 |
| tulip | bramc: the latency of block transversal is far higher than that. | 20:49 |
| bramc | petertodd, That's my assumption as well, hence only being interested in \gamma = 0 | 20:50 |
| bramc | tulip, One would hope that with weak blocks it wouldn't be | 20:50 |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 20:50 | |
| aj | bramc: weak blocks don't build on each other though... ? | 20:50 |
| bramc | aj, Of course they do | 20:50 |
| bramc | aj, Or rather, you could design it so they do or don't, but the approaches currently favored by most people in the know do | 20:51 |
| aj | bramc: hmm, maybe i'm behind then. i didn't think there was a directed cryptographic relationship between weak blocks? | 20:52 |
| bramc | aj, Each weak block uses a previous weak block as a form of compression, resulting in it itself being useful for later weak blocks | 20:52 |
| bramc | And also, as I just pointed out, a reasonable method of timestamping when some numnutz is trying to front-run previously withheld blocks | 20:53 |
| aj | what's the distribution for weak blocks with time? if it takes 2*n minutes to find a strong block, do you expect 2*k weak blocks, or k weak blocks? | 20:53 |
| petertodd | note that weak blocks is tech that disadvantages small miners... if you're sufficiently small, you don't have any opportunity to find weak blocsk, equally, if you're large, you don'tneed them | 20:53 |
| -!- wallet42 [~wallet42@014136144048.static.ctinets.com] has quit [Quit: Leaving.] | 20:53 | |
| tulip | bramc: I think if you are hedging on weak blocks (or anything else) being the saviour of the network latency you'll probably end up disappointed. | 20:54 |
| bramc | petertodd, I'm assuming weak blocks are simply a form of compression, and are all about making latencies very low everywhere | 20:55 |
| petertodd | yeah, ifyou want to fix lnetwork latency, fix the underlying O(n^2) problem | 20:55 |
| -!- zookolaptop [~user@68.233.157.2] has quit [Ping timeout: 265 seconds] | 20:55 | |
| petertodd | bramc: yes, but this is one of those "if you need it, you're fucked"situations | 20:55 |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Quit: Reconnecting] | 20:55 | |
| -!- justanot1eruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 20:55 | |
| tulip | petertodd: arguably we're already in trouble if this behaviour is showing its head. | 20:56 |
| petertodd | tulip: yes, I think we are | 20:56 |
| -!- pozitron [~nu@46.166.188.227] has joined #bitcoin-wizards | 20:57 | |
| tulip | well, I think we're in trouble from the perspective of everything quickly becoming unmanageable. | 20:58 |
| bramc | tulip, I disagree. With weak blocks it should be possible for the blocks themselves to be way under 1k of 'new' stuff to transport and the weak blocks themselves and be distributed in a slightly more leisurely way. | 20:59 |
| tulip | something interesting is that the rapid UTXO growth as stopped. I noticed that a while ago and still don't know what to make of it. | 20:59 |
| coinoperated | easy, just make Bitcoin only work in a geographic area the size of rhode island. I bet you could have as many TPS as you want, with no latency-based advantage attacks. dontations welcome | 20:59 |
| -!- cheetah2 [~cheetah2@172.242.102.144] has joined #bitcoin-wizards | 21:00 | |
| bramc | aj, Weak blocks should probably be some constant factor more common than strong blocks based on social convention. Probably 10x or 100x. I've tried to start discussion on here about what that factor should be but haven't been successful so far. | 21:00 |
| petertodd | bramc: _if_ everyone cooperates and everything works perfectly | 21:00 |
| tulip | bramc: there's probably room for taking p2pools share chain and using that as "weak blocks" today and seeing how it goes. | 21:01 |
| bramc | petertodd, Maybe I'm an optimist. I don't think it requires universal cooperation and the parts which have to work 'perfectly' are completely manageable. | 21:01 |
| tulip | the p2pool share chain is just a diff/20 Bitcoin blockchain pretty much. | 21:01 |
| petertodd | bramc: notice how if there's a bug in weak blocks that disables them temporarily, low bandwidth miners are fucked, yet high bandwidth ones don't care much | 21:01 |
| bramc | petertodd, Yes bugs suck and if there's a problem then small miners are stuck where they are today | 21:02 |
| petertodd | bramc: but today we have a blocksize limit low enough that everyone has access to reasonably low orphan rates | 21:02 |
| petertodd | bramc: (remember that the networking code we have right now on the p2p network is *really* inefficient) | 21:03 |
| bramc | I do think a conservative approach to using weak blocks for sibling selection makes sense, or at least enough sense to consider seriously | 21:03 |
| coinoperated | dumb non-wizard question: where to catch up on strong/weak block discussion? i.e. are strong blocks some sort of checkpointing mechanism etc. paper i should read? | 21:03 |
| petertodd | coinoperated: none that I know of | 21:04 |
| tulip | coinoperated: please never, ever use the term "checkpointing" in the context of consensus. | 21:04 |
| bramc | petertodd, And the blocksize limit is staying down there, by design | 21:04 |
| petertodd | bramc: what do you mean? | 21:04 |
| bramc | petertodd, The current 'plan of record' is for the block size to de facto go up by less than 2x with segwit and otherwise stay put, at least for now | 21:05 |
| bramc | For exactly that reason | 21:05 |
| petertodd | bramc: sure | 21:05 |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 21:05 | |
| petertodd | bramc: OTOH, I think that plan is kinda misleading, as it doesn't make clear thatwe have no reason to think further increases are possible (modulo fundemental tech improvements) | 21:06 |
| bramc | coinoperated, You aren't the first person to ask that. We've been assuming that the implications of weak blocks are 'obvious', which is, uh, probably a wrong assumption | 21:06 |
| tulip | petertodd: the problem is ultimately that there's the perception that the current network status is healthy. | 21:07 |
| bramc | petertodd, I'm with you there, but there are some... political problems | 21:07 |
| petertodd | tulip: well, from the point of view of circle and coinbase, it probably is reasonably healthy - they want different things from bitcoin than we do | 21:07 |
| tulip | petertodd: I don't see why they want a terrible paypal clone. | 21:08 |
| petertodd | tulip: remember that they're in a position where hearn's centralized checkpoint proposal wouldn't be a bad thing | 21:08 |
| bramc | petertodd, On the network protocol: People with blue hair keep bugging me to make a new peer protocol, which I could certainly do, but right now I'm working on things I find a lot more interesting | 21:09 |
| tulip | petertodd: it's paypal! but slower, has no consumer protection built in, it's difficult to work with, has no fungibility and no privacy. but hey, the name is cool! | 21:09 |
| petertodd | bramc: I'm very dubious about hiding problems, because it invites responses like jgarzik/gavin's recent medium post | 21:09 |
| tulip | bramc: to be fair the current P2P network does suck terribly. not as bad as the original creators design of it mind you. | 21:10 |
| bramc | petertodd, I wish I could successfully argue that a balloon payment on a mortgage was a 'new economic policy' and hence I shouldn't have to pay it. | 21:11 |
| petertodd | bramc: sure, yet, that argument does ring true in a certain way | 21:12 |
| bramc | tulip, It's a totally fair argument that it can be improved, and that I'm the most qualified to do it. It just hasn't bubbled up to the top of my list of things to do, in no small part because it doesn't sound like much fun. | 21:12 |
| coinoperated | bramc, not obvious to the semi informed at least. didn't know if the discussion was based on a paper where terms are defined. I can lurk and log up, extra clueless thx to spotty IRC attendance thanks to Santa Week | 21:14 |
| tulip | bramc: in the wxBitcoin implementation things got weird. it was designed to host other services like a marketplace, so most of the commands were to do with subscribing to receiving review and product information. some connections were direct TCP for making payments, playing games and things like that. there was no inventory messages so every message was flooded to every peer perhaps hundreds of times. the implementation of it had 100ms sleeps in | 21:15 |
| tulip | the networking loop as well. | 21:15 |
| bramc | Maybe I should do a post on weak blocks. I should learn exactly what p2pool's side chains do first though. | 21:15 |
| tulip | coinoperated: botbot.me/freenode/bitcoin-wizards | 21:15 |
| bramc | tulip, No blame being cast about the current state of the peer protocol. It's entirely to be expected. | 21:17 |
| tulip | p2pool isn't quite that. it's a blockchain that has a significantly lower difficulty, targeting 30 seconds. every now and then people will find a p2pool sharechain block which also happens to be difficult enough to be a Bitcoin network block, and that gets pushed onto the Bitcoin network. every block solved includes all the payments to other miners as an internal consensus rule. | 21:18 |
| bramc | That's very much like weak blocks, extra stuff added though and not quite as optimized for latency as it could be. | 21:20 |
| tulip | it has its strong and weak points, one problem is that the number of possible payments to make is limited. you really can't be a tiny miner on p2pool or you will get dust payments every block which you can never spend economically. here's a recent p2pool block paying out 300 people with a 10kb transaction. https://webbtc.com/tx/1564fb99bed0db4069a955092c4dd2f52209cf73304f0e1f0cde374c1778f6c4 | 21:21 |
| tulip | for quite a while p2pool was the most efficient pool due to the way it pushes around blocks to other p2pool nodes using the sharechain. that might still be true to some degree now, I don't know. it's probably suffering a bit now due to being written in Python. | 21:24 |
| CubicEarth | tulip: Can it smoothly sample a single 5 TH/s miner? | 21:24 |
| CubicEarth | tulip: or would the variance still be very high? | 21:24 |
| tulip | CubicEarth: 5TH would be fine. variance really doesn't matter, you've just got to learn to ignore it. | 21:26 |
| bramc | For anyone curious about the selfish mining papers: The 'Optimal Selfish Mining Strategies in Bitcoin' paper takes the 'Mining is not Enough' paper and squeezes a little more blood from the stone. It also debunks the proposed improvement in the first paper. | 21:28 |
| bramc | The other related papers aren't very good | 21:29 |
| CubicEarth | tulip: Personally I agree about the variance, being good to ignore, but someone also mentioned recently (maybe it was ptodd) that variance is a real cosst of doing business, which I thought was interesting and I can see how that could be true | 21:29 |
| bramc | I'm a bit annoyed at jgarzik making an appeal to what Satoshi said about raising the block size limit, because (a) it doesn't matter what Satoshi thought, and (b) if Satoshi wanted that he wouldn't have made mining rewards fall exponentially over time | 21:32 |
| -!- CubicEarth [~cubiceart@c-67-168-82-178.hsd1.wa.comcast.net] has quit [Remote host closed the connection] | 21:33 | |
| -!- nuke1989 [~nuke@178-157-152.dynamic.cyta.gr] has joined #bitcoin-wizards | 21:46 | |
| -!- Giszmo [~leo@pc-139-55-215-201.cm.vtr.net] has quit [Quit: Leaving.] | 21:46 | |
| kanzure | coinoperated: for catching up on weak block stuff, see http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/invertible-bloom-lookup-tables-and-weak-block-propagation-performance/ | 21:46 |
| jgarzik | bramc, Market expectations are relevant | 21:47 |
| -!- funkenstein_ [~bowler@unaffiliated/funkenstein] has joined #bitcoin-wizards | 21:47 | |
| kanzure | security is more important than market misexpectation | 21:47 |
| coinoperated | kanzure, thanks. IRC logs help but still jump in around mid november with some sort of definition already established. Weakly validated, weakly propagated, weakly confirmed, weakly understood :D | 21:49 |
| bramc | jgarzik, There are very real market expectations of the block size staying put | 21:49 |
| petertodd | bramc: +1 | 21:51 |
| petertodd | equally, demanding devs say things about what tx fees willbe is unrealistic:we don't know, and can't know | 21:52 |
| petertodd | in a system that doesn't scale, there's absolutely nothing we can do to keep a lid on tx fees if demand goes up | 21:53 |
| petertodd | (well, we aqn centralize bitcoin, but thats not going to happen by this dev team) | 21:54 |
| -!- funkenstein_ [~bowler@unaffiliated/funkenstein] has quit [Quit: Leaving] | 21:56 | |
| jcorgan | seems we're at a point where all that can be said, has been. we'll only learn more about "market expectations" and the motivations of everyone in this grand experiment by allowing things to play out | 22:04 |
| petertodd | jcorgan: yeah, I'm inclined to recommend that those who don't agree with the bitcoin core team's general direction leave and work on a competing project | 22:06 |
| petertodd | jcorgan: trying to change dev's minds with the types of arguments being used is silly | 22:06 |
| petertodd | jcorgan: people are talking past each other because what they want out of bitcoin is radically different (and/or their understanding of the technology is radically different) | 22:07 |
| dgenr8 | petertodd: bitcoin doesn't have a dev team | 22:08 |
| petertodd | dgenr8: that'swhy I said "bitcoin core" | 22:09 |
| bramc | On my list of stuff to do now: essay on weak blocks, essay on the long term of bitcoin mining and transaction fees, make a concrete proposal for not valid after (ideally a BIP), make a new peer protocol, finish the merkle set data structure | 22:13 |
| jcorgan | is that all? | 22:14 |
| bramc | That's my *bitcoin* list of stuff to do | 22:14 |
| dgenr8 | petertodd: miners have access to a 1MB orphan rate any time they like | 22:14 |
| petertodd | dgenr8: huh? | 22:14 |
| dgenr8 | <petertodd> bramc: but today we have a blocksize limit low enough that everyone has access to reasonably low orphan rates | 22:14 |
| petertodd | dgenr8: your orphan rate is influenced by the blocksize *other* miners use | 22:15 |
| kanzure | and also asymmetries in the network bandwidth graph | 22:15 |
| kanzure | ... for various definitions of network. and "your". | 22:16 |
| dgenr8 | petertodd: do explain if you would | 22:16 |
| petertodd | dgenr8: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.html | 22:17 |
| bramc | I got excited the other day about not-valid-after when I realized it's possible to hack it into the output, getting around the limitations in extending transactions. It will undoubtedly be ugly though, and I'll have to do some digging in low level details to figure it out | 22:17 |
| kanzure | propagation delay too | 22:17 |
| petertodd | dgenr8: or even more simple: if 90% of the hashing power has chosen a blocksize such that your bandwidht can'treceive those blocks in <10mins, you're gonna have a damn high orphan rate... | 22:18 |
| jcorgan | bramc: looking forward to reading your essays and proposal. | 22:18 |
| brg444 | +1 | 22:21 |
| bramc | jcorgan, Thanks for the encouragement. At the moment I'm stuck on the merkle set data structure, which I am going to get finished, dammit | 22:21 |
| brg444 | jcorgan can you take care of the troll in #bitcoin ? | 22:21 |
| petertodd | bramc: re:merkle set, preliminary link? | 22:21 |
| jcorgan | sorry, wasn't in channel, am now | 22:22 |
| -!- silvaedium [~faenumis@ip24-253-204-109.ok.ok.cox.net] has joined #bitcoin-wizards | 22:23 | |
| bramc | petertodd, localhost:///~bram/merkle_set/merkle_set.py | 22:23 |
| dgenr8 | petertodd: it'd be good to try not to conflate bandwidth-challenged miners with low-hashpower miners. the first problem is orders of magnitude cheaper to fix | 22:23 |
| petertodd | bramc: sheesh, that code looks like crap, were you drunk while writing it? | 22:23 |
| petertodd | dgenr8: if you thnk that's easy to fix, you have fundementally different ideas about what bitcoin should be than I do, and further discussion is pointless | 22:24 |
| jcorgan | um | 22:24 |
| kanzure | this does not seem to be loading for me http://99-75-88-206.lightspeed.sntcca.sbcglobal.net/~bram/merkle_set.py | 22:25 |
| -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has left #bitcoin-wizards [] | 22:25 | |
| kanzure | oops got the url wrong | 22:25 |
| bramc | petertodd, In all seriousness, it isn't even done as a first draft yet, although at least the documentation is getting a bit coherent. Maybe a few more days and I'll deem it not horribly embarrassing for other people to look at. It's going to be probably two weeks before it even has all the methods filled in as a first draft | 22:25 |
| petertodd | kanzure: oh weird, *that* one loads for me... and that letter to your wife is really sweet | 22:26 |
| kanzure | petertodd: i am disappointed in you- surely you have better info on me than that? | 22:26 |
| jcorgan | wtf | 22:27 |
| petertodd | bramc: what properties do you think you can get? | 22:27 |
| bramc | petertodd, Low L1 and L2 cache misses, fairly good memory compactness, lazy root evaluation, 'reasonable' defense against malicious data | 22:28 |
| petertodd | kanzure: well, I'm not going to reveal everything.... | 22:29 |
| petertodd | bramc: so the crypto itself isn'tspecial? justthe efficiency? | 22:30 |
| kanzure | in an effort to not assume what bramc has seen or not seen, i should probably mention proofchains to him | 22:30 |
| petertodd | kanzure: oh yeah, I need to do a writeup for that... | 22:31 |
| petertodd | kanzure: although I may need to change the name for bullshit legal reasons :/ | 22:31 |
| kanzure | that bad, huh? | 22:31 |
| bramc | petertodd, Also compact and simple proofs of inclusion and exclusion which can be generated fast. It's a sha256 patricia tree, similar to what maaku's done but with different proofs of inclusion and exclusion (I don't know how different because I don't know what he did for that) | 22:32 |
| bramc | kanzure, I don't know proofchains | 22:32 |
| petertodd | kanzure: yup - granted, my lawyer is cautious, but most are, so... | 22:32 |
| bramc | Or at least, I don't know them under that name | 22:32 |
| kanzure | petertodd: broadcast your hashed commitments now while you still have a tongue | 22:32 |
| petertodd | bramc: https://github.com/proofchains/python-proofmarshal/blob/master/proofmarshal/mmr.py <-merkle set! | 22:33 |
| petertodd | kanzure: heh | 22:33 |
| petertodd | bramc: I've got a rustversion of that too IIRC, butthe legal status of that code is murky... | 22:35 |
| kanzure | damn i keep forgetting to link to the marshalling stuff. i always end up at the other unit tests and then confused why there seems to be nothing there (like in python-proofchains.git). | 22:35 |
| bramc | petertodd, I'm also doing all the memory management manually. Mine is meant to be highly performant but fairly pedestrian in terms of crypto and API. I'll look through yours as a reference. My main interest from other implementations is in how they do proofs of inclusion/exclusion. The patricia tree idea I got from maaku. | 22:35 |
| petertodd | kanzure: yeah, when I did the rust version I put both in the same repo :) | 22:36 |
| petertodd | bramc: I optimised for low probability of fuckups rather than performance :) | 22:36 |
| petertodd | bramc: there's a bunch of neat compressions that you can use on mine too that make the serialized size not as bad as ait looks at first glance | 22:37 |
| bramc | petertodd, Also my proofs of inclusion/exclusion are strongly canonical. Don't know if that matters for anything but it's possible and sounds good so I'm doing it. | 22:37 |
| petertodd | bramc: yes, my stuff is all canonical as well - 100% deterministic | 22:37 |
| bramc | petertodd, Mine is meant to be implementable very simply with low probability of fuckup as well if that's what you want to optimize for in implementation | 22:38 |
| petertodd | bramc: though my proofs of inclusion/exclusion are somewhat weird, as they're based on code that just determines theminimal set of data needed to prove a statement | 22:38 |
| petertodd | bramc: whoops, I meant https://github.com/proofchains/python-proofmarshal/blob/master/proofmarshal/merbinnertree.py | 22:39 |
| kanzure | ha see not even you can figure out what to link to | 22:39 |
| petertodd | kanzure: they both started with m :) | 22:39 |
| bramc | Ah, this is the MerkleMountainRange stuff. What I'm doing is quite a bit dumber at the expense of not supporting as efficient merging of data sets | 22:40 |
| -!- coinoperated [~coinopera@70.15.164.106.res-cmts.t132.ptd.net] has quit [Ping timeout: 256 seconds] | 22:40 | |
| kanzure | but didn't you have something about efficient diff updating or something? | 22:41 |
| bramc | Oh I see, the apples-to-apples is with that last link | 22:41 |
| petertodd | bramc: see, one of my working assumptions, is that ifI can't implement it fast enough in python, my system doesn't scale well enough :) | 22:41 |
| bramc | kanzure, Yeah it does efficient updating but it always does it by shoving the data into the tree. You can in principle do better with batching things but... uh... we'd like to avoid that if it's possible. | 22:41 |
| bramc | petertodd, It may be that the Python implementation I'm doing will in the end be fairly performant, but it looks ridiculous with it being in Python and the intention is for it to be ported to C/C++ | 22:42 |
| petertodd | bramc: fwiw, I'd suggest writing it in rust first actually! the struct types I found made it easier to be clar about what exactly is what | 22:43 |
| bramc | For what I'm doing now the language doesn't matter much, it's going to look like C regardless. | 22:44 |
| petertodd | bramc: well, what can I say, if you haven't already, try rust out | 22:44 |
| bramc | Like, my central data structure is a byte array called self.memory | 22:45 |
| -!- brg444 [415ce066@gateway/web/freenode/ip.65.92.224.102] has quit [Ping timeout: 252 seconds] | 22:47 | |
| petertodd | ha | 22:47 |
| bramc | Not even slightly joking | 22:50 |
| tulip | petertodd: what would you like to see in a Bitcoin P2P network? | 22:52 |
| petertodd | tulip: O(1) scalability :P | 22:53 |
| tulip | petertodd: what would you like to see in a realistic Bitcoin P2P network? | 22:53 |
| petertodd | tulip: actually, make that O(0) scaling :P | 22:54 |
| tulip | I'm talking wire protocol. | 22:54 |
| petertodd | tulip: I genuinely think that if you need to optimize that stuff, something is wrong | 22:54 |
| tulip | do we need to optimise that stuff today? | 22:54 |
| petertodd | tulip: yes :) | 22:54 |
| tulip | thought so. | 22:55 |
| -!- adam3us1 [~Adium@host-92-18-110-49.as13285.net] has joined #bitcoin-wizards | 22:56 | |
| -!- adam3us [~Adium@host-92-18-110-49.as13285.net] has quit [Read error: Connection reset by peer] | 22:56 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has quit [Remote host closed the connection] | 23:00 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has joined #bitcoin-wizards | 23:00 | |
| -!- justanot1eruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 245 seconds] | 23:03 | |
| -!- cheetah2 [~cheetah2@172.242.102.144] has quit [Client Quit] | 23:04 | |
| bramc | petertodd, A difference between your tree and mine: In yours if there's only stuff on one side the stuff below is collapsed in. In mine it's treated as a special case with there simply being stuff on only one side. I also don't hash in prefixes, because they're implicit | 23:06 |
| bramc | My reasons for doing this are (1) simplicity, and (2) it makes proofs of non-inclusion cleaner | 23:08 |
| -!- vladzamfir [550718c9@gateway/web/freenode/ip.85.7.24.201] has quit [Ping timeout: 252 seconds] | 23:09 | |
| petertodd | bramc: collapsed in? what do you mean by that? | 23:11 |
| -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 246 seconds] | 23:11 | |
| bramc | petertodd, Like, if you have a tree with exactly two things in it, they'll branch at the top level. In mine they branch n levels down, where n is the size of their shared prefix | 23:11 |
| -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-wizards | 23:13 | |
| bramc | I'm also specifying whether the children are terminals in the parent, which sounds more complicated but actually makes implementation simpler | 23:15 |
| bramc | petertodd, You misspelled 'invarients' | 23:17 |
| petertodd | bramc: pull-reqs accepted :P | 23:17 |
| kanzure | coinoperated: for weak block stuff, check out the following- | 23:17 |
| kanzure | http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/invertible-bloom-lookup-tables-and-weak-block-propagation-performance/ | 23:17 |
| kanzure | http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011707.html | 23:17 |
| kanzure | http://gnusha.org/bitcoin-wizards/2015-12-02.log | 23:17 |
| kanzure | http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011158.html | 23:17 |
| kanzure | bramc: for merkle mountain range things, see- | 23:18 |
| kanzure | https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md | 23:18 |
| kanzure | http://gnusha.org/bitcoin-wizards/2015-09-18.log | 23:18 |
| bramc | kanzure, I knew about merkle mountain ranges already, just didn't realize that's what was being discussed | 23:18 |
| kanzure | https://gist.github.com/maaku/2aed2cb628024800044d (you have already seen this one i think) | 23:18 |
| kanzure | http://gnusha.org/bitcoin-wizards/2015-09-18.log | 23:18 |
| petertodd | bramc: ah right, because in my version the philosophy is "since we have the prefix, below is everything under this prefix" | 23:18 |
| petertodd | (I have no concept of depth, kinda) | 23:18 |
| petertodd | (sorry, my internet is lagged all to hell irgh tnow) | 23:18 |
| kanzure | oops that's the same date. whoops. | 23:18 |
| bramc | petertodd, I waffled on exactly how to format it and concluded that what I'm doing now is simpler for reasons having to do with practical implementation details. They aren't meaningfully different semantics. | 23:20 |
| kanzure | am i forgetting anything for syncing bramc up? i regret not pointing out the selfish mining stuff to him... | 23:20 |
| petertodd | bramc: yeah, if there were, something would be wrong :) | 23:20 |
| petertodd | bramc: my version probably lets you share muore stuff between different versions in some cases, but that disn't necessarily good for l1/l2 caches | 23:21 |
| bramc | kanzure, Somebody had pointed out the selfish mining stuff to me because it was in my list of stuff to read, I just didn't realize that until I'd reinvented it today. | 23:21 |
| kanzure | yeah but i mean it would be more efficient if you were to focus on reinventing the stuff that isn't widely known, though | 23:22 |
| kanzure | okay i can't think of anything else for the moment, bbl | 23:22 |
| bramc | kanzure, No major harm done, I only spent part of today on it and now I understand it deeply and am more prepared to work through the details of the related question of whether you can benefit from your own blocks getting propagated slowly, which I don't think is handled directly anywhere in the literature | 23:23 |
| petertodd | bramc: note that my writeup only made the claim that getting your own blocks propagated slowly would hurt others more than it hurt you, in many cases | 23:24 |
| kanzure | "propagated slowly" is too ambiguous- there is a network bandwidth graph with lots of asymmetries in uplinks and downlinks. different bandwidth available in different locations. slowness is approximately the same thing as withholding in some cases. selectively choosing which parts of the network to send the data more quickly to... and er, something about cartel consensus building. | 23:24 |
| kanzure | also, big blocks can propagate more slowly on the wider network due to those bandwidth bottlenecks. but really it's the race to propagate to hashrate, not to the nodeso, so the nodes will (absent a limit) get squeezed out much more quickly. | 23:25 |
| bramc | petertodd, There's a subtle difference between hurting others more by proportionately or absolutely which may be the crux of the problem, but yes I know what you meant (well, one of those two anyway) | 23:25 |
| bramc | kanzure, Yes the meaning of 'propagate slowly' is something which needs to be nailed down in any discussion whether you can benefit from it. | 23:26 |
| kanzure | and more specifically, it's whether an adversary can benefit | 23:27 |
| kanzure | but you already know this so i'm not sure why i'm saying that | 23:27 |
| petertodd | bbl, sleep! | 23:27 |
| kanzure | same. | 23:27 |
| bramc | All you people without kids | 23:27 |
| bramc | Oh, and also not in the time zone desert of the west coast | 23:28 |
| kanzure | i am a child at heart, does that count | 23:28 |
| bramc | It's interesting what causes there to be large active developer communities. BitTorrent doesn't have one, because it does one thing and does it well, so there isn't a neverending supply of problems to work on. Web frameworks have lots of stuff to work on, because they do many things. Bitcoin has lots of stuff to work on, because although it only does one thing it does it so badly that you never have to worry about runnin | 23:32 |
| bramc | g out of things to fix. | 23:32 |
| bramc | The IBLT metrics in that IBLT/weakblocks presentation looks quite encouraging | 23:38 |
| p15 | bittorrent has toolchain devs | 23:40 |
| fluffypony | I'd argue that BitTorrent is a protocol that can remain relatively stable and fixed, with only implementation weaknesses having to be fixed, whereas Bitcoin presents previously unknown challenges because of all the attack vectors against the consensus state | 23:43 |
| bramc | p15 True, but they're outside of core. People at my company do work on core stuff, but it's mostly humdrum maintenance which outside people would be unlikely to work on for fun. | 23:44 |
| tulip | BitTorrent also has the luxury of just making versions of the software which can speak multiple protocols for compatibility. | 23:44 |
| bramc | fluffypony, That's another way of putting it. | 23:45 |
| bramc | tulip, Well, we don't have to be quite as maniacal about avoiding hard forks, although for the most part we are anyway. | 23:45 |
| tulip | Bitcoin has remained remarkably backwards compatible, though I would hardly suggest anybody run anything older than 0.11 under any circumstances. | 23:46 |
| tulip | the P2P wire protocol is the main incompatibility. | 23:46 |
| bramc | The wire protocol incompatibility isn't so bad. The thing you can never, ever do is cause a utxo to no longer be valid, no matter how old and busted it is. | 23:47 |
| tulip | we do that with soft forks, it's the other way around that's a problem | 23:48 |
| -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Ping timeout: 240 seconds] | 23:49 | |
| bramc | The hong kong weak blocks presentation actually suggests a ration: 20x. So nice to see a number suggested by someone other than me. (I've been suggesting 10-100, which 20 is close to the middle of) | 23:49 |
| tulip | P2Pool has a 20x lower difficulty target too for what that's worth. | 23:50 |
| tulip | it used to be 10s, then was altered to 30s. | 23:50 |
| bramc | Sounds like another good data point | 23:51 |
| tulip | perhaps. | 23:53 |
| tulip | lots of things like this are dictated by other factors. for example, at one point in time a lot of the Bitcoin hardware couldn't flush the current work from their buffers quickly which made them produce ridiculous amounts of stale work. | 23:55 |
| bramc | That sounds like Their Problem | 23:58 |
| --- Log closed Wed Dec 30 00:00:51 2015 | ||
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!
