| --- Log opened Thu Dec 10 00:00:32 2015 | ||
| -!- p15 [~p15@108.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-wizards | 00:00 | |
| -!- Guest1234 [~ubuntu@ec2-52-0-91-57.compute-1.amazonaws.com] has quit [Ping timeout: 244 seconds] | 00:05 | |
| -!- Guest1234 [~ubuntu@ec2-52-0-91-57.compute-1.amazonaws.com] has joined #bitcoin-wizards | 00:07 | |
| -!- el33th4x0r [68e5aa14@gateway/web/cgi-irc/kiwiirc.com/ip.104.229.170.20] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] | 00:11 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 00:13 | |
| -!- AaronvanW [~ewout@tswc3022.netvigator.com] has joined #bitcoin-wizards | 00:13 | |
| -!- AaronvanW [~ewout@tswc3022.netvigator.com] has quit [Changing host] | 00:13 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 00:13 | |
| -!- DigiDreamer [~DigiDream@238-124-200-46.pool.ukrtel.net] has quit [Remote host closed the connection] | 00:16 | |
| -!- mkarrer [~mkarrer@17.Red-83-52-38.dynamicIP.rima-tde.net] has joined #bitcoin-wizards | 00:22 | |
| -!- CubicEar_ [~cubiceart@70-36-136-123.dsl.dynamic.fusionbroadband.com] has joined #bitcoin-wizards | 00:25 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] | 00:26 | |
| -!- p15 [~p15@108.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 250 seconds] | 00:26 | |
| -!- CubicEarth [~cubiceart@70-36-136-123.dsl.dynamic.fusionbroadband.com] has quit [Ping timeout: 240 seconds] | 00:28 | |
| -!- p15 [~p15@ip-18-214-104-93.static.contabo.net] has joined #bitcoin-wizards | 00:29 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 00:30 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 00:31 | |
| @gmaxwell | making OWAS fraudproofable is annoying. | 00:41 |
|---|---|---|
| @gmaxwell | requires having a MST for the GT. :( | 00:41 |
| -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:688b:d62d:40e3:5d5d] has quit [Ping timeout: 250 seconds] | 00:43 | |
| -!- gielbier [~giel____@a149043.upc-a.chello.nl] has joined #bitcoin-wizards | 00:45 | |
| -!- gielbier [~giel____@a149043.upc-a.chello.nl] has quit [Changing host] | 00:46 | |
| -!- gielbier [~giel____@unaffiliated/gielbier] has joined #bitcoin-wizards | 00:46 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 00:48 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 00:49 | |
| -!- beanlein [hackerman@ip5b401d10.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 00:54 | |
| -!- Yoghur114_2 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards | 00:54 | |
| -!- CubicEar_ [~cubiceart@70-36-136-123.dsl.dynamic.fusionbroadband.com] has quit [Remote host closed the connection] | 00:54 | |
| -!- matsjj [~matsjj@213.205.251.158] has joined #bitcoin-wizards | 00:55 | |
| -!- matsjj [~matsjj@213.205.251.158] has quit [Remote host closed the connection] | 00:57 | |
| phantomcircuit | gmaxwell, what about for the XY? or the NB ? :) | 01:01 |
| -!- tromp [~tromp@24.190.11.216] has joined #bitcoin-wizards | 01:01 | |
| @gmaxwell | idk rtfm pdq | 01:02 |
| -!- CubicEarth [~cubiceart@70-36-136-123.dsl.dynamic.fusionbroadband.com] has joined #bitcoin-wizards | 01:04 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep] | 01:05 | |
| -!- tromp [~tromp@24.190.11.216] has quit [Ping timeout: 272 seconds] | 01:06 | |
| -!- CubicEarth [~cubiceart@70-36-136-123.dsl.dynamic.fusionbroadband.com] has quit [Remote host closed the connection] | 01:07 | |
| -!- Casper- [~Casper@garza.riseup.net] has quit [Quit: Casper-] | 01:18 | |
| -!- Terry4 [~Terry4@garza.riseup.net] has joined #bitcoin-wizards | 01:18 | |
| -!- RoboTedd_ [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 01:21 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds] | 01:25 | |
| -!- Terry4 [~Terry4@garza.riseup.net] has quit [Ping timeout: 256 seconds] | 01:28 | |
| -!- Terry4 [~Terry4@garza.riseup.net] has joined #bitcoin-wizards | 01:29 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] | 01:38 | |
| -!- Yoghur114_2 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection] | 01:40 | |
| -!- matsjj [~matsjj@89.197.31.78] has joined #bitcoin-wizards | 01:47 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] | 01:50 | |
| -!- mkarrer [~mkarrer@17.Red-83-52-38.dynamicIP.rima-tde.net] has quit [] | 01:51 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Quit: Leaving] | 01:52 | |
| -!- mkarrer [~mkarrer@83.52.38.17] has joined #bitcoin-wizards | 01:53 | |
| -!- catcow [sid62269@gateway/web/irccloud.com/x-olrujhukbpidauio] has quit [Ping timeout: 240 seconds] | 02:01 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 02:01 | |
| -!- Terry4 [~Terry4@garza.riseup.net] has quit [Ping timeout: 256 seconds] | 02:01 | |
| -!- andytoshi [~andytoshi@unaffiliated/andytoshi] has quit [Ping timeout: 260 seconds] | 02:02 | |
| -!- catcow [sid62269@gateway/web/irccloud.com/x-ezeqlxdjxxthhvsh] has joined #bitcoin-wizards | 02:02 | |
| -!- andytoshi [~andytoshi@wpsoftware.net] has joined #bitcoin-wizards | 02:03 | |
| -!- Terry4 [~Terry4@garza.riseup.net] has joined #bitcoin-wizards | 02:09 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 02:11 | |
| -!- Terry4 [~Terry4@garza.riseup.net] has left #bitcoin-wizards [] | 02:12 | |
| -!- ttttemp [~ttttemp@pc-5305.ethz.ch] has quit [Remote host closed the connection] | 02:23 | |
| -!- ttttemp [~ttttemp@nb-10350.ethz.ch] has joined #bitcoin-wizards | 02:25 | |
| -!- Terry4 [~Terry4@garza.riseup.net] has joined #bitcoin-wizards | 02:31 | |
| -!- fkhan [weechat@gateway/vpn/mullvad/x-yqcqeprchyjuxube] has quit [Ping timeout: 272 seconds] | 02:34 | |
| -!- lmatteis [uid3300@gateway/web/irccloud.com/x-xcaajgrjwsymizri] has joined #bitcoin-wizards | 02:44 | |
| -!- tripleslash_j [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 264 seconds] | 02:46 | |
| -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-wizards | 02:48 | |
| -!- markus-k [~markus-k@designnet.work.de] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 03:03 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Read error: Connection reset by peer] | 03:17 | |
| -!- melvster1 [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards | 03:17 | |
| -!- markus-k [~markus-k@designnet.work.de] has joined #bitcoin-wizards | 03:23 | |
| -!- gobiasindustries [60268e75@gateway/web/freenode/ip.96.38.142.117] has quit [Ping timeout: 252 seconds] | 03:24 | |
| -!- fkhan [weechat@gateway/vpn/mullvad/x-mozsewsdhsnnifqx] has joined #bitcoin-wizards | 03:33 | |
| -!- fkhan [weechat@gateway/vpn/mullvad/x-mozsewsdhsnnifqx] has quit [Changing host] | 03:33 | |
| -!- fkhan [weechat@unaffiliated/loteriety] has joined #bitcoin-wizards | 03:33 | |
| -!- fkhan [weechat@unaffiliated/loteriety] has quit [Changing host] | 03:33 | |
| -!- fkhan [weechat@gateway/vpn/mullvad/x-mozsewsdhsnnifqx] has joined #bitcoin-wizards | 03:33 | |
| fluffypony | sort-of OT, but interesting: http://www.nature.com/nature/journal/v528/n7581/full/nature16059.html | 03:41 |
| fluffypony | .title | 03:41 |
| yoleaux | Undecidability of the spectral gap : Nature : Nature Publishing Group | 03:41 |
| -!- mkarrer [~mkarrer@83.52.38.17] has quit [Read error: Connection reset by peer] | 03:46 | |
| -!- _biO_ [~biO_@80.156.183.43] has joined #bitcoin-wizards | 03:48 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] | 03:49 | |
| -!- beanlein [hackerman@ip5b401d10.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer] | 03:51 | |
| -!- markus-k [~markus-k@designnet.work.de] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 04:06 | |
| -!- markus-k [~markus-k@designnet.work.de] has joined #bitcoin-wizards | 04:06 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 04:10 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Read error: Connection reset by peer] | 04:13 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 04:14 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] | 04:16 | |
| -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards | 04:16 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 256 seconds] | 04:22 | |
| -!- GfxdjGFhgF [~KHDXGFHGh@86.121.131.214] has joined #bitcoin-wizards | 04:39 | |
| -!- el33th4x0r [68e5aa14@gateway/web/cgi-irc/kiwiirc.com/ip.104.229.170.20] has joined #bitcoin-wizards | 04:43 | |
| -!- DigiDreamer [~DigiDream@212.3.113.102] has joined #bitcoin-wizards | 04:48 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 04:48 | |
| -!- GfxdjGFhgF [~KHDXGFHGh@86.121.131.214] has quit [Quit: Leaving] | 04:48 | |
| -!- adam3us [~Adium@141.8.72.43] has joined #bitcoin-wizards | 04:48 | |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 04:51 | |
| -!- bit2017 [~linker@115.79.55.177] has quit [Ping timeout: 272 seconds] | 04:52 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 250 seconds] | 04:52 | |
| -!- ttttemp__ [~ttttemp@pc-5305.ethz.ch] has joined #bitcoin-wizards | 04:53 | |
| -!- ttttemp_ [~ttttemp@pc-10236.ethz.ch] has quit [Remote host closed the connection] | 04:53 | |
| -!- ttttemp [~ttttemp@nb-10350.ethz.ch] has quit [Remote host closed the connection] | 04:55 | |
| -!- execute [~execute@unaffiliated/execute] has quit [Ping timeout: 250 seconds] | 04:55 | |
| -!- xeon-enouf [~xeon-enou@unaffiliated/xeon-enouf] has quit [Ping timeout: 250 seconds] | 04:56 | |
| -!- gavinandresen [~gavin@unaffiliated/gavinandresen] has quit [Ping timeout: 250 seconds] | 04:56 | |
| -!- xeon-enouf [~xeon-enou@unaffiliated/xeon-enouf] has joined #bitcoin-wizards | 04:56 | |
| -!- bsm117532 [~mcelrath@static-108-21-236-13.nycmny.fios.verizon.net] has quit [Ping timeout: 250 seconds] | 04:56 | |
| -!- bsm117532 [~mcelrath@static-108-21-236-13.nycmny.fios.verizon.net] has joined #bitcoin-wizards | 04:57 | |
| -!- gavinandresen [~gavin@unaffiliated/gavinandresen] has joined #bitcoin-wizards | 04:58 | |
| -!- execute [~execute@ec2-52-68-0-151.ap-northeast-1.compute.amazonaws.com] has joined #bitcoin-wizards | 04:59 | |
| -!- execute [~execute@ec2-52-68-0-151.ap-northeast-1.compute.amazonaws.com] has quit [Changing host] | 04:59 | |
| -!- execute [~execute@unaffiliated/execute] has joined #bitcoin-wizards | 04:59 | |
| -!- Giszmo [~leo@201.215.55.139] has joined #bitcoin-wizards | 05:03 | |
| -!- ttttemp [~ttttemp@pc-10236.ethz.ch] has joined #bitcoin-wizards | 05:04 | |
| -!- ttttemp__ [~ttttemp@pc-5305.ethz.ch] has quit [Remote host closed the connection] | 05:04 | |
| -!- tachys_ [~alex@c-73-231-188-118.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 05:05 | |
| -!- tachys_ [~alex@c-73-231-188-118.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds] | 05:09 | |
| -!- tachys_ [~alex@c-73-231-188-118.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 05:10 | |
| -!- tachys_ [~alex@c-73-231-188-118.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds] | 05:14 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] | 05:27 | |
| -!- RoboTedd_ [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Remote host closed the connection] | 05:29 | |
| -!- el33th4x0r [68e5aa14@gateway/web/cgi-irc/kiwiirc.com/ip.104.229.170.20] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] | 05:34 | |
| -!- hashtagg_ [~hashtag@cpe-174-97-254-80.ma.res.rr.com] has quit [Ping timeout: 272 seconds] | 05:37 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 05:41 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 05:43 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 272 seconds] | 05:51 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 05:51 | |
| -!- hashtagg_ [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has joined #bitcoin-wizards | 05:55 | |
| -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 250 seconds] | 05:57 | |
| -!- [Derek] [~derek@unaffiliated/derek/x-8562683] has quit [Ping timeout: 260 seconds] | 05:57 | |
| -!- [Derek] [~derek@2605:6400:10:3c9:dfd3:3e96:2608:98a7] has joined #bitcoin-wizards | 05:59 | |
| -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-wizards | 05:59 | |
| -!- [Derek] is now known as Guest94083 | 06:00 | |
| -!- markus-k [~markus-k@designnet.work.de] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 06:02 | |
| -!- markus-k [~markus-k@designnet.work.de] has joined #bitcoin-wizards | 06:04 | |
| -!- markus-k [~markus-k@designnet.work.de] has quit [Read error: Connection reset by peer] | 06:16 | |
| -!- GGuyZ [~GGuyZ@59-100-109-145.cust.static-ipl.aapt.com.au] has joined #bitcoin-wizards | 06:24 | |
| -!- atgreen_ [~green@38.140.131.195] has joined #bitcoin-wizards | 06:29 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 06:49 | |
| -!- GGuyZ [~GGuyZ@59-100-109-145.cust.static-ipl.aapt.com.au] has quit [Quit: GGuyZ] | 06:53 | |
| -!- damethos [~damethos@unaffiliated/damethos] has quit [Ping timeout: 250 seconds] | 06:53 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 256 seconds] | 06:54 | |
| -!- lmatteis [uid3300@gateway/web/irccloud.com/x-xcaajgrjwsymizri] has quit [Quit: Connection closed for inactivity] | 06:57 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 07:00 | |
| -!- chmod755 [~chmod755@unaffiliated/chmod755] has joined #bitcoin-wizards | 07:00 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds] | 07:04 | |
| -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 240 seconds] | 07:09 | |
| bsm117532 | kanzure: "how do you avoid runaway bandwidth on this system without a block size limit?" | 07:14 |
| bsm117532 | I didn't say anything about that directly, but I would like to remove the bandwidth limit as a consensus rule. We can find better ways to control it. | 07:15 |
| bsm117532 | There is a natural bandwidth limit that is the "number of transactions" times a constant factor. e.g. if you're sending out blocks way faster than the underlying transaction rate, you're just blowing away bandwidth. Since coinbases in my proposal are empty, there's no value in a transaction-less block. | 07:17 |
| bsm117532 | Also, it's silly to think that a miner on a Rasperry Pi and a shitty uplink will be able to run a global transaction processing system. Sorry, but eventually they won't be able to keep up. I don't want to artificially restrict bitcoin to be slow. | 07:18 |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] | 07:19 | |
| bsm117532 | (This is all Re: my "Braiding the Blockchain" talk https://scalingbitcoin.org/hongkong2015/presentations/DAY2/2_breaking_the_chain_1_mcelrath.pdf) | 07:19 |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep] | 07:20 | |
| bsm117532 | There's also a general mechanism I call an "Equivalent Bead" where you can bundle a bunch of lower-work beads into a higher-work one. (This is e.g.how a bitcoin block is made from the braid) I actually removed this slide from my talk. At the end of the day it only saves you some headers of lower-work blocks, so doesn't save a large amount of bandwidth anyway. | 07:21 |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 07:24 | |
| kanzure | that doesn't address the question at all; "blowing away bandwidth" no- at the moment the way the current system works is that there's a centralizing effect by having hashrate publish full blocks towards high-bandwidth peers. i suspect the same is true in your system. | 07:26 |
| bsm117532 | kanzure: I think that is still the case in my system. | 07:28 |
| kanzure | then the scaling problem is unsolved :) | 07:28 |
| -!- afdudley [~afdudley@166.84.136.68] has quit [Ping timeout: 260 seconds] | 07:28 | |
| bsm117532 | In fact I explicitly incentivized it by using the "cohort difficulty". If I hadn't done that, there's an attack where you can just hold on to your block forever and attempt to become everyone's sibling. | 07:28 |
| -!- JackH [~Jack@host-80-43-143-143.as13285.net] has quit [Ping timeout: 240 seconds] | 07:29 | |
| bsm117532 | kanzure: I would set a floor as the minimum difficulty, which is a constant fraction times bitcoin's bandwidth. The extra bandwidth is only PoW headers for the extra beads and would be less than 2x bitcoin's current bandwidth. | 07:29 |
| bsm117532 | So I'm not so concerned about it. Why are you? | 07:30 |
| kanzure | just making sure you don't claim this is some sort of scaling solution. has same inherent problem. | 07:33 |
| kanzure | it has other okay properties, i guess. | 07:34 |
| -!- ttttemp [~ttttemp@pc-10236.ethz.ch] has quit [Remote host closed the connection] | 07:38 | |
| bsm117532 | I'm far more concerned about bandwidth usage by free relay of txns in the p2p layer, than mined txns in my proposal. | 07:38 |
| bsm117532 | And you can't scale without scaling bandwidth (modulo sipa's talk). My proposal is absolutely a scaling solution, because it removes the problems associated with larger block sizes or faster block rate. | 07:40 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] | 07:44 | |
| -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards | 07:48 | |
| instagibbs | in what ways? The fairness metric? | 07:49 |
| bsm117532 | That and miner utilization too, because work isn't wasted on stale/orphan blocks. | 07:50 |
| -!- ttttemp [~ttttemp@nb-10350.ethz.ch] has joined #bitcoin-wizards | 07:52 | |
| instagibbs | while that would be great, when kanzure is saying "scaling solution" he probably means something that isn't bound by "everyone must know everything forever". | 07:53 |
| bsm117532 | kanzure wants sharding. I do too. My proposal doesn't address that at all. | 07:54 |
| bsm117532 | I'm disappointed there hasn't been more work on that topic... | 07:54 |
| -!- adam3us [~Adium@141.8.72.43] has quit [Quit: Leaving.] | 07:54 | |
| instagibbs | LN is another "paradigm" | 07:54 |
| bsm117532 | After I finish this paper I'm going to throw some more thought toward sharding. | 07:55 |
| instagibbs | probably not just restricted to LN long-term, only use blockchain as adjudicator with non-cooperative counter-parties. | 07:55 |
| instagibbs | cool | 07:55 |
| bsm117532 | I have a silly proposal here, but I'm sure we can do better: http://blog.sldx.com/three-challenges-for-scaling-bitcoin/ | 07:55 |
| bsm117532 | See #3 | 07:55 |
| kanzure | "And you can't scale without scaling bandwidth (modulo sipa's talk)." this seems to be false | 07:56 |
| gavinandresen | We seem to get half-baked sharding scheme ideas once every four months or so; my standard response is "go code up a prototype, complete with wallet, and then come back" | 07:58 |
| instagibbs | Make sure to relate any sharding to the SCP/Treechains/EthereumSharding(? no idea what they called it) ideas. If you could even summarize the space in a writeup that may be helpful | 07:58 |
| gavinandresen | Bandwidth is absolutely not the bottleneck to scaling bitcoin right now, even an average home internet connection has plenty of bandwidth assuming just implementing the very lowest-hanging-fruit for optimizing bandwidth usage | 07:59 |
| instagibbs | this is -wizards, and is being used to help clarify claims | 08:00 |
| instagibbs | :) | 08:00 |
| gavinandresen | I was responding to "why hasn't there been more work on sharding solutions" | 08:00 |
| instagibbs | ah | 08:00 |
| instagibbs | +1 | 08:01 |
| gavinandresen | Solutions that reduce latency of new block announcements and mitigate selfish mining are big priorities right now, in my humble opinion | 08:01 |
| coinoperated_tv | braiding, sharding, sooner or later the transaction domain will have to be separated into largest practical signal domains | 08:02 |
| gavinandresen | I'm not familiar with the term "largest practical signal domains" | 08:03 |
| kanzure | huh? | 08:03 |
| kanzure | no way to have consensus over bandwidth at a protocol-level, unfortunately. | 08:04 |
| kanzure | (my "huh" is unrelated- was to signal whowhats) | 08:05 |
| gavinandresen | I seem to also dimly remember people saying that something like Google would be impossible way back when... (we'll HAVE to shard the Internet, no possible way anybody could search the entire thing....) | 08:05 |
| kanzure | google is a centralized system, and i think that it makes sense that you can just keep adding hardware and run mapreduce over it. | 08:05 |
| -!- NewLiberty [~NewLibert@134.71.249.212] has joined #bitcoin-wizards | 08:05 | |
| coinoperated_tv | google can live with a longer settlement window than 10 minutes though, no? | 08:05 |
| kanzure | what were the actual google concerns? | 08:05 |
| kanzure | to be fair, you still can't search the entire internet. there's a large quantity of pages that are simply inaccessible through the search interface. but why would google advertise that? that's not in their favor. | 08:06 |
| coinoperated_tv | even if internally google is a closed decentralized system, i don't think they have a requirement to have consistency every 10 mins, but i dunno, maybe interally they do | 08:07 |
| gavinandresen | kanzure: but the Internet is still decentralized. And if Google went away tomorrow, we'd still have Bing and duckduckgo and blekko and ... I dunno, a hundred others? | 08:07 |
| coinoperated_tv | seems unlikely | 08:07 |
| kanzure | duckduckgo uses bing, so that doesn't count | 08:07 |
| instagibbs | gavinandresen, pushing the computation/resources to the endpoints allows us closer to google. One reason I really like LN, and even though impractical today, treechains. | 08:07 |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 08:08 | |
| gavinandresen | Sure, I like the Poon/Dryja bathtub of too much centralization of what-is-needed-to-be-a-fully-validating-node on one side and too much centralization of number-of-keys-that-can-spend-on-the-main-chain on the other. | 08:08 |
| coinoperated_tv | laregst practical signal domain is the largest graph that can become consistent in a timely manner (timely being however long humans can tolerate waiting for it wrt their practical needs for the graph) given physical boundaries like rtt and speed of light | 08:08 |
| kanzure | gavinandresen: i think the argument for "the internet is decentralized" is "regulators don't have the capacity to interfere with all of the existing peering agreements" or something? i haven't seen anyone elaborating on that, which could be useful. (you and i have discussed internet before, but not in any relevant depth) | 08:08 |
| instagibbs | now we just get to endlessly argue about the shape of bathtubs rather than color of bikeshed :) | 08:09 |
| kanzure | we could do a graph/bikeshed color theorem of some kind, if that would make it seem more topical | 08:10 |
| nsh | sometimes bathtubs result in eurekas | 08:10 |
| -!- JackH [~Jack@host-80-43-143-143.as13285.net] has joined #bitcoin-wizards | 08:10 | |
| nsh | (sometimes toes get stuck in taps) | 08:10 |
| gavinandresen | coinoperated_tv: thanks, is that term from academic computer science networking or some other field? | 08:10 |
| gavinandresen | coinoperated_tv: rtt.... round trip time? | 08:11 |
| gavinandresen | coinoperated_tv: And to save me some googling: what IS the largest practical signal domain for the entire Internet? | 08:13 |
| kanzure | "largest graph"- in this context though it's not the size of the graph that matters..... | 08:13 |
| kanzure | (because sybil) | 08:13 |
| coinoperated_tv | no just from casual reading in complex adaptive systems, i.e. the quark and the jaguar, santa fe institute blog, gmu complexity studies papers. readily admit its little more than a slightly informed hunch | 08:13 |
| gavinandresen | coinoperated_tv: ... to be more specific: if the graph is the entire Internet, with Internet rtt and speed of light, what is the consistency time? | 08:15 |
| gavinandresen | If it's less than a minute or so, it seems to me there's not a whole lot of reason to worry about sharding. | 08:15 |
| coinoperated_tv | gavinandresen: i think consistency time needs to be modeled in graduated degrees from most ideal case (simple consistency assuming everyone plays fair and has equal mean link latency, no cross-validation needed) down through what we actually have to deal with. But ultimately settlement time is a human factor, how long to wait is too long for practical use cases | 08:17 |
| -!- CubicEarth [~cubiceart@70.36.136.123] has joined #bitcoin-wizards | 08:18 | |
| -!- wizkid057 [wk@unaffiliated/wizkid057] has quit [Ping timeout: 272 seconds] | 08:18 | |
| bsm117532 | kanzure: I still don't understand your argument WRT bandwidth... | 08:19 |
| coinoperated_tv | 10 mins, if i understand properly, is the target right now? And this seems short enough for most uses, i guess LN covers this? | 08:19 |
| -!- ttttemp [~ttttemp@nb-10350.ethz.ch] has quit [Remote host closed the connection] | 08:19 | |
| -!- ttttemp [~ttttemp@pc-10236.ethz.ch] has joined #bitcoin-wizards | 08:19 | |
| instagibbs | coinoperated_tv, you need block propagation to be << average block emission time | 08:20 |
| instagibbs | otherwise bad convergence | 08:20 |
| bsm117532 | I don't know if I can make any comparison to treechains -- it seems insufficiently fleshed out. I've spoken to petertodd about it briefly, but it needs more work. | 08:20 |
| instagibbs | even in optimistic cases | 08:21 |
| gavinandresen | Lightning network MIGHT be the solution for instant mostly-trustless transactions... I don't think we know if people will be willing to park money in payment channels to get the benefits. | 08:21 |
| instagibbs | bsm117532, I am speaking at a high level even. For example, in SCP/EthereumSharding you are expecting validators to not lie a sufficient amount | 08:22 |
| -!- wizkid057 [wk@unaffiliated/wizkid057] has joined #bitcoin-wizards | 08:22 | |
| kanzure | bsm117532: your claim is that you can't scale without scaling bandwidth. my argument is that this is wrong because we have evidence to the contrary. additionally, we have evidence of how both miners and nodes can't download fast enough at some bandwidth limit vs. data size. thus you are simply wrong.... | 08:22 |
| -!- CubicEarth [~cubiceart@70.36.136.123] has quit [Remote host closed the connection] | 08:22 | |
| instagibbs | treechains is saying "don't trust miners" | 08:22 |
| instagibbs | aside from ordering of data | 08:22 |
| coinoperated_tv | gavinandresen: is LN sharding by another name? I do not mean to stir up controversy here, but some agreement on what terms like sharding means, in the abstract at least, is lacking generally. | 08:23 |
| gavinandresen | treechains are a buzzword, really | 08:23 |
| kanzure | LN is not really sharding; it's more like adding restrictions around otherwise undefined behavior of zero-conf transactions | 08:23 |
| instagibbs | coinoperated_tv, sort of? It's not sharding the chain state though. | 08:23 |
| kanzure | and also, keeping most of those zero-conf transactions to themselves | 08:23 |
| instagibbs | when we say sharding I'm assuming we are sharding the chain's ledger state somehow | 08:24 |
| gavinandresen | instagibbs: +1 | 08:24 |
| bsm117532 | kanzure: bitcoin's bandwidth usage is extremely modest. The real problem is downloading large blobs quickly and verifying it quickly. A solution is to spread the 10-minute spike of downloading a block over the entire 10 minutes by using a smaller faster layer. Then you're downloading a few kb at a time and verifying it continuously, rather than the spiky 10-minute way. In that sense my proposal *allows* us to s | 08:24 |
| kanzure | bsm117532: your irc client got cutoff at "my proposal *allows us to s". | 08:24 |
| bsm117532 | Large 1MB blobs have problems downloading because of latency, routing, and bufferbloat. | 08:25 |
| kanzure | that's a local optimization; i'm confident we can solve those problems. | 08:25 |
| bsm117532 | sorry: In that sense my proposal *allows* us to scale to the available bandwidth. | 08:25 |
| kanzure | my disagreement with you is "And you can't scale without scaling bandwidth (modulo sipa's talk)." | 08:25 |
| bsm117532 | kanzure: I am too. This is a solution. ;-) | 08:25 |
| kanzure | not about local block propagation optimizations | 08:25 |
| kanzure | gavinandresen: btw have you used rusty's data corpus? | 08:26 |
| kanzure | gavinandresen: https://github.com/rustyrussell/bitcoin-corpus | 08:26 |
| coinoperated_tv | instagibbs: ok, fair enough. so off-chain state maintenance is not sharding but something a step closer to decoupling of state? | 08:26 |
| gavinandresen | kanzure: no, not yet-- I keep getting distracted by Drama and Controversy... | 08:26 |
| instagibbs | coinoperated_tv, I think of it as "using blockchain space as adjudication of smart contracts" or something | 08:26 |
| instagibbs | set up smart contract, then do normal negotiation off-chain | 08:27 |
| bsm117532 | kanzure: I think that statement is accurate. We're using like 3kb/s (averaged every 10m). We can't go faster because of protocol rules. Doubling the transaction rate means 6kb/s, and there's no way around that, modulo compressing the transaction format a la sipa. | 08:27 |
| instagibbs | only when the contract is violated do you need to tell others, aka close channel | 08:27 |
| kanzure | bsm117532: what does that have to do with "you can't scale without scaling bandwidth"? | 08:28 |
| instagibbs | bsm117532, last time I try to explain this: Your proposal, as well as Bitcoin proper, are bound to the "everyone must know everything" paradigm. Which today can't scale 1000x. | 08:28 |
| gavinandresen | bsm117532: you're poking a pet peeve of mine when you say "protocol rules" . Do you mean p2p network protocol rules, consensus protocol rules ???? | 08:28 |
| bsm117532 | instagibbs, kanzure: "everyone must know everything" is clearly a scaling limit of bitcoin that must be solved. But even keeping that rule we can't scale because larger blocks generate more orphans. My proposal solves that. | 08:29 |
| bsm117532 | gavinandresen: I mean consensus rules. | 08:29 |
| -!- lmatteis [uid3300@gateway/web/irccloud.com/x-lpwixcmulrljnbrq] has joined #bitcoin-wizards | 08:30 | |
| gavinandresen | bsm117532: ... then it would be much clearer if you said 'the 1MB blocksize limit' | 08:30 |
| bsm117532 | gavinandresen: Okay. You're right "protocol rules" was incorrect in the above sentence. | 08:30 |
| gavinandresen | "everyone must know everything" is also a pet peeve of mine.... | 08:30 |
| gavinandresen | Today, not everybody using bitcoin knows everything, so on the face it is clearly a false statement.... | 08:31 |
| kanzure | i think he means "see all ze transactions" | 08:32 |
| instagibbs | see and validate | 08:32 |
| kanzure | e.g. in the whitepaper "The only way to know is to see everything" | 08:32 |
| coinoperated_tv | @instagibbs: my hunch is that it can never happen, there's a wall ahead where serial Tx convergence above a certain frequency limit just isn't possible on a global scale, no matter what shortcuts are developed. | 08:32 |
| coinoperated_tv | but I'll shup and not pretend to be more than the interested observer that I am | 08:33 |
| gavinandresen | The vast majority of people using bitcoin do not see all the transactions... I agree that all fully-validating nodes need to see all transactions under the consensus rules we're using today. | 08:33 |
| kanzure | coinoperated_tv: shortcuts like centralization should make that possible. | 08:33 |
| kanzure | coinoperated_tv: i also think there are promising long-term proposals that use cryptography magic to make that possible. | 08:33 |
| instagibbs | It's short-hand for: I want to use the full security of Bitcoin, and I'm compelled to know everything. | 08:34 |
| kanzure | coinoperated_tv: http://diyhpl.us/~bryan/irc/bitcoin/scalingbitcoin-review.pdf | 08:34 |
| gavinandresen | It is loose talk like "bitcoin can't scale because everybody needs to see all the transactions" that trickles out from -wizards and misleads non-wizards into thinking things that just simply aren't true. | 08:34 |
| kanzure | nobody in here says bitcoin can't scale because of that requirement | 08:34 |
| coinoperated_tv | @instagibbs: some days ago i asked how much security is "enough" security, i think the reply I got was "all of it, or else..." | 08:34 |
| kanzure | perhaps they say "can't scale in the traditional ways", which is valid | 08:34 |
| gavinandresen | Yes, I know... we are all -wizards. | 08:35 |
| kanzure | no that's not what i meant :p | 08:35 |
| gavinandresen | I just get tired of trying to fix misperceptions that I think are made worse when I see experts being kind of sloppy | 08:35 |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 08:35 | |
| instagibbs | What language would you prefer | 08:35 |
| gavinandresen | Instead of "everyone" : fully validating nodes | 08:36 |
| instagibbs | Oh, easy fix. | 08:36 |
| gavinandresen | Instead of absolutes like "can't scale" be more precise: "cannot scale without sacrificing some amount of trust" (for example) | 08:36 |
| instagibbs | I was anthropomorphizing myself as a fully validating node | 08:36 |
| gavinandresen | or "cannot scale without sacrificing some amount of centralization" | 08:36 |
| kanzure | "cannot scale in the traditional way by increasing direct throughput without sacrificing decentralization and trustlessness and valuable properties of the bitcoin financial asset" | 08:37 |
| kanzure | whoops let me edit | 08:37 |
| kanzure | "cannot scale in the traditional way by increasing direct throughput without sacrificing some decentralization and trustlessness and valuable properties of the bitcoin financial asset" | 08:37 |
| gavinandresen | instagibbs: yeah, I tend to do that too-- it's a bad habit I need to break, it confuses non-experts who don't think of themselves as computers | 08:37 |
| gavinandresen | ("so you validate the transaction then send it to your peers..." "Wait, you mean there are people validating bitcoin transactions somewhere in sweat shops in china?" ) | 08:38 |
| kanzure | gavinandresen: one of my thoughts about this is that over time bitcoin is going to increasingly be people's first introductions to: programming, open source software development, p2p, network protocols, security, cryptography | 08:38 |
| kanzure | so over time we will have waves and waves of newbies to some of those fields | 08:39 |
| kanzure | and eventually, in best case scenario, bitcoin might one day be people's first introduction to money... | 08:39 |
| coinoperated_tv | @kanzure ty for link, good one as usual | 08:39 |
| instagibbs | I heard chinese coal miners validate the bitcoin network | 08:39 |
| gavinandresen | I heard it was reindeer in iceland | 08:40 |
| kanzure | instagibbs: that one... might be true. | 08:40 |
| kanzure | (no reason that bitcoind would be incompatible with computers owned by chinese coal miners) | 08:40 |
| coinoperated_tv | it's the planck constant | 08:40 |
| gavinandresen | kanzure: from what I hear, it's mostly excess hydro power. Coal is easy to turn on/off, so there's no excess..... | 08:41 |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Ping timeout: 246 seconds] | 08:41 | |
| kanzure | i think you are talking about miners | 08:41 |
| instagibbs | I was more poking fun at people who think miners make sure the chain is valid(for others) | 08:41 |
| instagibbs | i guess they do for spv... until fraud proofs. doh | 08:42 |
| kanzure | right... miners != bitcoind for the most part. | 08:42 |
| TD-Linux | coal is actually one of the harder ones to turn on and off. hydro is the easiest (and also has built in energy storage!) | 08:43 |
| kanzure | coal- http://i.pics.livejournal.com/pryf/39738266/1631169/original.jpg | 08:43 |
| kanzure | (bagger 188) | 08:43 |
| gavinandresen | TD-Linux: really? I believe that on short timescales (e.g. diverting water takes a minute, shutting down a coal burner takes... I dunno, an hour?), I was thinking long timescales... | 08:46 |
| gavinandresen | And hydro is free power up to whatever the dam capacity is. You gotta buy coal.... | 08:47 |
| -!- hashtagg_ [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has quit [Read error: Connection reset by peer] | 08:49 | |
| TD-Linux | right, well maybe if they screw up managing the hydro buffer there would be excess (and I think china has been building a lot of hydro recently) | 08:50 |
| gavinandresen | irrelevant fact: I go cross-country skiing a few times every winter here: https://en.wikipedia.org/wiki/Northfield_Mountain_(hydroelectricity_facility) | 08:51 |
| TD-Linux | and hydro is really cheap, not only because of free fuel, but also because it's mechanically simple and low maintenance. | 08:51 |
| instagibbs | I wonder how much of the hashing is done on hydro today | 08:52 |
| TD-Linux | so it's likely that they are using hydro power for the cost (the AWS region in oregon is the cheapest for this reason!) but I wouldn't call it *excess* | 08:52 |
| bsm117532 | gavinandresen: I understand your frustration, you've been doing this longer than most. It's an inevitable fact that new people are going to come in and try to learn, and get it a little bit wrong, over and and over and over. :-/ | 08:52 |
| bsm117532 | See also AOL users jumping on the internet in 1994... | 08:52 |
| gavinandresen | instagibbs: a large percentage, I think. The hashing hotspots are china and eastern washington state, which are both hydro. And iceland, which is geothermal. | 08:53 |
| TD-Linux | yeah iceland is pretty neat. drill a hole, get free high pressure steam. | 08:54 |
| gavinandresen | instagibbs: mining is a zero-sum game, of course, so if a miner finds a spot with really cheap electricity they have an incentive not to advertise it | 08:54 |
| -!- TBI [~TBI@20.84-48-195.nextgentel.com] has joined #bitcoin-wizards | 08:54 | |
| -!- TBI_ [~TBI@84.48.195.20] has quit [Ping timeout: 240 seconds] | 08:56 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 08:56 | |
| bsm117532 | If we can decentralize mining by utilizing braids/beads with lower difficulty targets, or validating nodes publishing weak blocks, more mining will happen at the edges where the node operator is subsidizing his node for other reasons. | 08:56 |
| -!- Erik_dc [~erik@d54C620ED.access.telenet.be] has joined #bitcoin-wizards | 08:58 | |
| -!- hashtag [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has joined #bitcoin-wizards | 09:01 | |
| gavinandresen | bsm117532: ... I think you're just saying more miners should use p2pool... | 09:04 |
| -!- _biO_ [~biO_@80.156.183.43] has quit [Remote host closed the connection] | 09:19 | |
| -!- dave4925 [dave4925@unaffiliated/dave4925] has joined #bitcoin-wizards | 09:21 | |
| -!- bendavenport [~bpd@96.90.231.161] has joined #bitcoin-wizards | 09:25 | |
| -!- mkarrer [~mkarrer@16.Red-88-25-142.staticIP.rima-tde.net] has joined #bitcoin-wizards | 09:25 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer] | 09:29 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 09:33 | |
| -!- tachys_ [~alex@96.90.231.161] has joined #bitcoin-wizards | 09:44 | |
| -!- zooko [~zooko@2607:fb90:2193:c518:a20e:5b57:8cc5:5187] has joined #bitcoin-wizards | 09:50 | |
| -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-wizards | 09:51 | |
| -!- bramc [~bram@99.75.88.206] has joined #bitcoin-wizards | 09:59 | |
| -!- matsjj [~matsjj@89.197.31.78] has quit [Remote host closed the connection] | 10:01 | |
| -!- Yoghur114_2 [~jorn@80.57.227.14] has joined #bitcoin-wizards | 10:04 | |
| coinoperated_tv | @gavinandresen speaking of free electricity, many colo facilities sell power in 20A blocks. You pay for the whole 20A whether you use it all or not. I wonder if a significant fraction of hashing is from datacenter tenants monetizing these unused power slices. | 10:04 |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 10:06 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 256 seconds] | 10:10 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 240 seconds] | 10:10 | |
| -!- liteIRC_ [~zooko@2607:fb90:2171:3233:e0a0:2e08:ca75:db44] has joined #bitcoin-wizards | 10:14 | |
| -!- liteIRC__ [~zooko@216.9.110.14] has joined #bitcoin-wizards | 10:16 | |
| -!- zooko [~zooko@2607:fb90:2193:c518:a20e:5b57:8cc5:5187] has quit [Ping timeout: 240 seconds] | 10:17 | |
| -!- liteIRC___ [~zooko@2607:fb90:2199:c6cf:411a:6723:b506:11bf] has joined #bitcoin-wizards | 10:17 | |
| -!- liteIRC__ [~zooko@216.9.110.14] has quit [Read error: Connection reset by peer] | 10:18 | |
| -!- zooko [~zooko@2607:fb90:2173:aa0f:380c:d2f5:89d9:a9bb] has joined #bitcoin-wizards | 10:19 | |
| -!- liteIRC_ [~zooko@2607:fb90:2171:3233:e0a0:2e08:ca75:db44] has quit [Ping timeout: 240 seconds] | 10:19 | |
| -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-wizards | 10:20 | |
| -!- liteIRC___ [~zooko@2607:fb90:2199:c6cf:411a:6723:b506:11bf] has quit [Ping timeout: 240 seconds] | 10:22 | |
| -!- liteIRC_ [~zooko@216.9.110.5] has joined #bitcoin-wizards | 10:26 | |
| -!- zooko [~zooko@2607:fb90:2173:aa0f:380c:d2f5:89d9:a9bb] has quit [Ping timeout: 240 seconds] | 10:29 | |
| -!- liteIRC_ is now known as zooko | 10:29 | |
| -!- liteIRC_ [~zooko@2607:fb90:217f:89d5:255b:ace3:2bd2:6a5b] has joined #bitcoin-wizards | 10:30 | |
| -!- NewLiberty_ [~NewLibert@134.71.249.212] has joined #bitcoin-wizards | 10:32 | |
| -!- Joseph__ [~NewLibert@134.71.249.212] has joined #bitcoin-wizards | 10:34 | |
| -!- zooko [~zooko@216.9.110.5] has quit [Ping timeout: 256 seconds] | 10:35 | |
| -!- liteIRC_ is now known as zooko | 10:35 | |
| -!- NewLiberty [~NewLibert@134.71.249.212] has quit [Ping timeout: 272 seconds] | 10:35 | |
| -!- eudoxia [~eudoxia@r186-55-162-88.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 10:35 | |
| -!- NewLiberty_ [~NewLibert@134.71.249.212] has quit [Ping timeout: 250 seconds] | 10:37 | |
| -!- zooko [~zooko@2607:fb90:217f:89d5:255b:ace3:2bd2:6a5b] has quit [Remote host closed the connection] | 10:48 | |
| -!- bit2017 [~linker@171.250.100.43] has joined #bitcoin-wizards | 10:48 | |
| -!- bit2017 [~linker@171.250.100.43] has quit [Ping timeout: 240 seconds] | 10:53 | |
| -!- fluffypony [~fluffypon@unaffiliated/fluffypony] has quit [Excess Flood] | 10:58 | |
| -!- Guest71642 [~fluffypon@coreteam.getmonero.org] has joined #bitcoin-wizards | 11:01 | |
| -!- Guest71642 is now known as fluffypony | 11:02 | |
| -!- fluffypony [~fluffypon@coreteam.getmonero.org] has quit [Changing host] | 11:02 | |
| -!- fluffypony [~fluffypon@unaffiliated/fluffypony] has joined #bitcoin-wizards | 11:02 | |
| -!- jgarzik [~jgarzik@119.17.33.135] has joined #bitcoin-wizards | 11:04 | |
| -!- jgarzik [~jgarzik@119.17.33.135] has quit [Changing host] | 11:04 | |
| -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards | 11:04 | |
| -!- bramc [~bram@99.75.88.206] has quit [Quit: This computer has gone to sleep] | 11:05 | |
| -!- oldbrew [brew@24-212-254-57.cable.teksavvy.com] has joined #bitcoin-wizards | 11:08 | |
| -!- justanot1eruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 11:20 | |
| -!- justanot1eruser [~Justan@unaffiliated/justanotheruser] has quit [Client Quit] | 11:20 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Quit: Lost terminal] | 11:20 | |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 11:21 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 11:22 | |
| -!- mrkent_ [~textual@unaffiliated/mrkent] has joined #bitcoin-wizards | 11:25 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 11:28 | |
| bsm1175321 | gavinandresen: in many ways what I'm proposing absorbs p2pool into bitcoin. I've talked with a couple people about p2pool and am going to pursue testing these ideas there. p2pool users take a 5% hit due to their orphan rate, and braids can make that zero. | 11:28 |
| -!- mrkent [~textual@unaffiliated/mrkent] has quit [Ping timeout: 250 seconds] | 11:28 | |
| @gmaxwell | bsm1175321: thats simply halariously untrue. | 11:29 |
| bsm1175321 | gmaxwell: explain? | 11:29 |
| @gmaxwell | P2pool has virtually no orphan rate; it's difficult to measure now because the hashrate was so low, but back when it was about 1% of the network it clearly had the lowest orphan rate of any namable pool. | 11:29 |
| @gmaxwell | It has integrated efficient relay similar to the relay network client that causes p2pool nodes to very rapidly announce blocks from all over the network at once. | 11:30 |
| bsm1175321 | Yes you can pretend orphaning doesn't happen with a very fast network. In the limit that your network is infinitely fast, there's no orphaning. Braids have no orphans ever though. | 11:31 |
| @gmaxwell | My income over on p2pool is about 110% expected. | 11:31 |
| @gmaxwell | I think you were talking to someone who was just profoundly ignorant about how p2pool works. | 11:33 |
| @gmaxwell | which isn't uncommon, sadly. | 11:34 |
| bsm1175321 | Does p2pool not have orphans? Admittedly I haven't looked at p2pool at all yet. | 11:34 |
| bsm1175321 | I understood it was just another blockchain with 30s blocks. | 11:34 |
| @gmaxwell | bsm1175321: which is used to measure users proportional hashrate over a several day window, nothing else. | 11:36 |
| bsm1175321 | So orphans don't affect your payout? | 11:36 |
| bsm1175321 | You just get a slightly worse measurement? | 11:36 |
| @gmaxwell | relative stale shares compared to other people does; but they also reduce the bitcoin income for the pool. | 11:37 |
| @gmaxwell | so if it was completely insensitive you could mine on a huge delay, and your contributions would be worthless (since your work is unlikely to result in a successful block), but you would still get paid. | 11:38 |
| bsm1175321 | It sounds like you're verifying my 5% hit statement in bitcoin income. (?) | 11:38 |
| -!- atgreen_ [~green@38.140.131.195] has quit [Ping timeout: 272 seconds] | 11:39 | |
| @gmaxwell | bsm1175321: I refuted it above with the strongest possible language I could use without being insulting. | 11:39 |
| bsm1175321 | e.g. the pool earns 5% less because 30s/600s=5% and that's how often the pool is mining on a stale block, no? | 11:40 |
| bsm1175321 | gmaxwell: let's be civil. | 11:40 |
| maaku | bsm1175321: why would the pool be mining on a stale block for 30s? | 11:40 |
| @gmaxwell | bsm1175321: I'm sorry, you have a profound misunderstanding which I don't know how to correct. Someone else will have to take a stab at it. | 11:41 |
| bsm1175321 | *sigh* I'll go read about p2pool. | 11:41 |
| @gmaxwell | bsm1175321: go talk it through with maaku | 11:42 |
| maaku | eh, sorry, shouldn't have said anything (4am here) | 11:42 |
| @gmaxwell | hah | 11:42 |
| @gmaxwell | ::sigh:: | 11:43 |
| @gmaxwell | bsm1175321: the processes are completely unrelated. You can't just divide random numbers. | 11:43 |
| bsm1175321 | Dunno, some people liked my ideas and said p2pool. That's all I know at this point. | 11:43 |
| @gmaxwell | there is no relationship between shares and blocks (well other than every block p2pool finds is also a share) | 11:44 |
| -!- eudoxia [~eudoxia@r186-55-162-88.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] | 11:45 | |
| bsm1175321 | So I guess it's impossible that p2pool accurately represents the hashpower in the *last* 10 minutes, and constructs an accurate coinbase for it. At best it would be 5% off, if I started mining at the beginning of the interval. | 11:46 |
| bsm1175321 | So it must assume everyone has constant hash rate, and averages over a longer time interval to determine shares.... | 11:46 |
| maaku | bsm1175321: your p2pool node is constantly watching the bitcoin network and generating current work. as soon as you hear about a new block, you switch to it | 11:47 |
| maaku | bsm1175321: the interblock interval of p2pool has absolutely no corrolation at all with stale rates... | 11:48 |
| @gmaxwell | bsm1175321: yes, it has a several day long rolling window... doesn't need to be accurate. | 11:48 |
| bsm1175321 | I see. | 11:48 |
| bsm1175321 | And I can't mine my own bitcoin block because then I would be unable to report shares (which require a coinbase provided by p2pool). | 11:49 |
| @gmaxwell | well you could, but you wouldn't get paid by p2pool. :) | 11:50 |
| bsm1175321 | See gmaxwell only took a few minutes to correct my misunderstanding without being insulting. :-P | 11:51 |
| bsm1175321 | BTW I think gmaxwell and sipa deserve awards for engaging with all comers on IRC. I know it must be frustrating. | 11:52 |
| Lightsword | bsm1175321, I think the bigger issue with p2pool is that antminers have problems with it | 11:53 |
| katu | Given the pattern of miners changing pools, I suspect a lot of miners are not fond of p2pool now because it lacks sleek UI with graphs | 11:54 |
| katu | along with its history of being less profitable initially | 11:54 |
| bsm1175321 | Lightsword: tough luck. You want a faster network, you have to switch mining hashes faster. I hope Bitmain fixes this. I talked about exactly this issue with several people at Scaling Bitcoin. | 11:54 |
| @gmaxwell | katu: it has really nice graphs | 11:54 |
| @gmaxwell | better than any other pool, in fact.. I'm not aware of any that will chart your latency, for example. | 11:54 |
| -!- Joseph__ [~NewLibert@134.71.249.212] has quit [Ping timeout: 272 seconds] | 11:54 | |
| @gmaxwell | katu: it was never less profitable. | 11:55 |
| Lightsword | bsm1175321, problem is the majority of the network runs on antminers, probably over 60% | 11:55 |
| katu | gmaxwell: oh? so that side improved too. so it's all just historical prejudice/ignorance, just like i displayed now? | 11:55 |
| bsm1175321 | katu: I had that misunderstanding too...not sure where it came from... | 11:55 |
| @gmaxwell | katu: yea. a lot of people think it's less profitable for unfortunate reasons;... also it just doesn't work with some hardware. | 11:55 |
| @gmaxwell | Because there is hardware with really embarassing latency that just can't be used with a 30s chain. | 11:56 |
| katu | gmaxwell: it was definitely producinga flurry of orphans when pool operators ddosed powerful p2pool nodes which are obviously quite exposed :> | 11:56 |
| Lightsword | gmaxwell, there is also a discard bug in antminers in the cgminer driver | 11:56 |
| @gmaxwell | katu: since before you ever heard of p2pool many of the miners on it have maintained a seperate dark topology. | 11:57 |
| @gmaxwell | (specifically to avoid being dos attack vulnerable) | 11:57 |
| oldbrew | very confusing sometimes when rejected blocks are high | 11:58 |
| oldbrew | goes nutz when you find a block | 11:58 |
| Lightsword | share stale rates also depend a lot on your relative latency with other p2pool nodes | 11:59 |
| katu | gmaxwell: are not there limits to it? i thought the progression in variance is linear. ie you need at least 0.1% or so of global hashrate to shoot down variance to some sane number? | 11:59 |
| @gmaxwell | There is just a lot of confusion that arises from people who think sharechain performance == blockchain performance. Also, a lot of people have used "p2pool" via third party front ends instead of running it. and these front ends sometimes rip people off. | 11:59 |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 11:59 | |
| katu | gmaxwell: meaning, dark f2f networks are not suitable for the small guy | 11:59 |
| katu | but only for couple of industrial mining ops who cooperate? | 12:00 |
| @gmaxwell | katu: they're not disconnected from the rest of p2pool the traffic is flooded. | 12:00 |
| @gmaxwell | but it means that dos attacking public p2pool nodes doesn't need to impact most of p2pool's hashrate, so there is little to no gain to do it. | 12:00 |
| @gmaxwell | and I can only think of two instances where p2pool nodes were being dos attacked and in both cases the attackers quickly gave up. | 12:01 |
| katu | gmaxwell: well, my reasoning is that with tiered, ddos resistant infrastructure you inevitably need someone to have incentive to invest into ddos proof infrastructure | 12:01 |
| Lightsword | gmaxwell, were people actually DoS’ing p2pool nodes a lot, most smaller mining pools rarely get hit AFAIK | 12:01 |
| katu | gmaxwell: with traditional pools, its the pool fee. but with p2pool? | 12:01 |
| bsm1175321 | ddosing large centralized pools must be more effective... | 12:02 |
| * katu does not believe in altruism | 12:02 | |
| Lightsword | katu, a lot of ddos mitigation relies on misdirecting attackers so the techniques aren’t always revealed | 12:02 |
| @gmaxwell | katu: it's very hard to dos p2pool, you're attacking a cloud... and indivigual members have self interest to avoid being dosed generally. | 12:02 |
| katu | Lightsword: misdirecting? you mean dns falseflags? :) | 12:02 |
| Lightsword | katu, there are some other tricks | 12:03 |
| @gmaxwell | katu: "tiered ddos resistant infrastructure" is a trapping of centeralized systems. | 12:03 |
| bsm1175321 | Wouldn't it be even better if every mining bitcoin node was a p2pool node? ;-) | 12:03 |
| katu | gmaxwell: tiered is what it boils down to from external PoV for peer cloud with dark links | 12:03 |
| Lightsword | katu, a lot of the tricks are really specific to stratum protocol | 12:03 |
| katu | gmaxwell: there are obviously simple ways to foil naive attackers (like forced segregation where peer pairs communicate only if hash of their ips share a byte) | 12:04 |
| @gmaxwell | katu: there is no special cost to this. you turn off advertisement and manually add-node somewhat trusted peers. | 12:04 |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 12:04 | |
| katu | gmaxwell: that way you get segregated tiers | 12:05 |
| -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: This computer has gone to sleep] | 12:05 | |
| katu | if its done manually and there is not flux its even more trivial to dos | 12:05 |
| katu | gmaxwell: but agreed, most of attackers do not bother | 12:06 |
| @gmaxwell | katu: the attackers never learn about it. | 12:07 |
| -!- tromp [~tromp@24.190.11.216] has joined #bitcoin-wizards | 12:07 | |
| @gmaxwell | it's not visible; I think you're stuck imagining p2pool as a centeralized service or something. | 12:07 |
| katu | gmaxwell: depends. are individual miners self-identifying in the shares they submit, or not? | 12:08 |
| @gmaxwell | ... what purpose would that serve? advertising so dos attackers could attack them? | 12:08 |
| @gmaxwell | No of course not. | 12:09 |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 12:09 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Client Quit] | 12:09 | |
| -!- NewLiberty [~NewLibert@134.71.249.228] has joined #bitcoin-wizards | 12:09 | |
| -!- tromp [~tromp@24.190.11.216] has quit [Ping timeout: 272 seconds] | 12:12 | |
| katu | gmaxwell: well last time i remember (2012) there was a single reward address specified to the proxy. | 12:13 |
| katu | if thats fixed, i cant think of any other way :) | 12:13 |
| Lightsword | katu, people using a proxy in front of p2pool? | 12:14 |
| Lightsword | https://bitcointalk.org/index.php?topic=18313.msg13190522#msg13190522 | 12:17 |
| @gmaxwell | katu: what do reward addresses have anything to do with dos attacks? | 12:18 |
| @gmaxwell | (though even in 2012 you could provide addresses in the miner url; there is also multiple payout addresses and rotation for monetary privacy) | 12:19 |
| -!- GGuyZ [~GGuyZ@59-100-109-145.cust.static-ipl.aapt.com.au] has joined #bitcoin-wizards | 12:21 | |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer] | 12:21 | |
| -!- DigiDreamer [~DigiDream@212.3.113.102] has quit [Remote host closed the connection] | 12:24 | |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 12:25 | |
| -!- zooko [~zooko@2607:fb90:170a:c440:fdbc:a417:2167:8986] has joined #bitcoin-wizards | 12:27 | |
| katu | gmaxwell: 1. connect to all sharechain nodes 2. look where share submission is propagated to soonest. It's no different from uncloaking classic pool upstreams. | 12:31 |
| katu | *the soonest | 12:31 |
| Lightsword | hmm, it may be easier actually, regular pools are on relay network which makes tracing nodes somewhat more difficult | 12:31 |
| -!- eudoxia [~eudoxia@r186-55-162-88.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 12:32 | |
| katu | but as long each share carries no identifying info per miner (for example, use different address per each share) | 12:33 |
| -!- joecool [~joecool@no-sources/joecool] has joined #bitcoin-wizards | 12:33 | |
| -!- zooko [~zooko@2607:fb90:170a:c440:fdbc:a417:2167:8986] has quit [Ping timeout: 264 seconds] | 12:33 | |
| katu | using different address makes the coinbases more spammy, does it not? | 12:33 |
| Lightsword | p2pool has a larger network footprint in general though so it’s harder to attack overall, more nodes you would have to take out | 12:34 |
| @gmaxwell | katu: I explained above, that you do not need to be visible at all to the outside world. | 12:34 |
| katu | only those using fixed set of upstreams are easy to take out :) | 12:34 |
| katu | gmaxwell: if you're talking about private share-alt-chain, sure | 12:35 |
| @gmaxwell | no. :( | 12:35 |
| katu | but otherwise your shares propagate to all nodes. the sooner observation = the node is closer to you | 12:36 |
| @gmaxwell | katu: sure but that isn't very useful for targeting dos attacks. | 12:36 |
| @gmaxwell | and hasn't been used. | 12:36 |
| katu | yet thats how some more sophisticated attacks roll :) | 12:36 |
| katu | on mainnet, not sharechain | 12:36 |
| @gmaxwell | I am really tired of the relentless fud. | 12:36 |
| @gmaxwell | katu: yea you can identify large centeralized miners on bitcoin; mostly because they hardly make more than a superficial effort to hide | 12:38 |
| -!- zooko [~zooko@2607:fb90:170a:c440:fdbc:a417:2167:8986] has joined #bitcoin-wizards | 12:38 | |
| Lightsword | dos isn’t really the issue with p2pool IMO, the issues are that your profitability is dependent on your relative share stale rates in addition to hardware issues | 12:38 |
| Lightsword | most DDoS attackers are just script kiddies renting botnets anyways :P | 12:38 |
| @gmaxwell | Lightsword: hardware issues are real; but I think it's just easy to fud and people have. | 12:39 |
| katu | Lightsword: the propdelay attacks are not usually for ddos though | 12:39 |
| katu | gmaxwell calls it fud, yet we've seen a whole /24's connected to virtually all nodes on some occasions | 12:39 |
| katu | they sure werent ddosing, but doing something :) | 12:40 |
| Lightsword | katu transaction traceing probably | 12:40 |
| @gmaxwell | katu: thats chainanalysis; they're tracing people's transactions and selling the data. | 12:40 |
| @gmaxwell | It takes pulling teeth to convince people of things like the fact that the 30s measurement chain has lots of stale shares doesn't mean p2pool has low profits. Like a half hour explination per person, and then the fudder just repeats the incorrect claim again. | 12:41 |
| katu | gmaxwell: yeah, thats unfortunate people dont realize the stales on the parallel subchain are unrelated. | 12:41 |
| Lightsword | gmaxwell, when the majority of deployed mining hardware however has known issues it’s certainly a problem, also in order to scale up you have to use a stratum proxy to load balance the connections | 12:41 |
| @gmaxwell | Lightsword: Why would you need to do that? I've had nearly 1% of the network's hashrate on a single p2pool daemon at one point. Of course, you could just run multiple p2pool daemons. | 12:43 |
| -!- Taurohtar [~Taurohtar@131.94.186.31] has joined #bitcoin-wizards | 12:43 | |
| maaku | "in order to scale up you have to use a stratum proxy to load balance the connections" is generally true regardless of the transaction selection code used... | 12:43 |
| -!- atgreen_ [~green@65.202.134.66] has joined #bitcoin-wizards | 12:43 | |
| katu | Lightsword: for larger mining ops, using a proxy is a given. i dont see any advantage each antminer doing anything more than being a dumb client to a pool or a sharechain proxy. | 12:43 |
| Lightsword | gmaxwell, from my understanding p2pools networking code has issues dealing with thousands of connections | 12:44 |
| @gmaxwell | Lightsword: perhaps, though the only reports along those lines I've seen is from people exposing their downstream interface to the public and getting botnet loads and such. | 12:45 |
| Lightsword | gmaxwell, how many connections did you have when you had 1% of the network? | 12:45 |
| @gmaxwell | Lightsword: p2pool scales the difficulty based on hashrate so the actual work it needs to do should be more or less constant; though certantly there could be stupidity with thousands of connections. | 12:46 |
| @gmaxwell | Lightsword: not thousands. :) | 12:46 |
| maaku | Lightsword: why would you have thousands of simultaneous connections? | 12:46 |
| @gmaxwell | maaku: because of running thousands of little mining devices off of it. | 12:46 |
| katu | dos. | 12:46 |
| -!- GGuyZ [~GGuyZ@59-100-109-145.cust.static-ipl.aapt.com.au] has quit [Quit: GGuyZ] | 12:46 | |
| katu | note that you dont need botnet to dos most of bitcoin these days | 12:46 |
| maaku | katu: ... why would you have an open p2pool port? | 12:46 |
| @gmaxwell | katu: You might want to see someone about that dos obsession. | 12:46 |
| Lightsword | gmaxwell, it’s not an issue for difficulty so much as pushing out updates as fast as possible | 12:46 |
| katu | about 2000 packets per node to fd starve it momentarily | 12:47 |
| Lightsword | maaku, um that’s pretty normal for any large mining operation | 12:47 |
| Lightsword | katu, yeah, I think most pools have to override those OS limits, they fill up pretty fast | 12:47 |
| maaku | Lightsword: if you have thousands of devices simultaneously fetching work, I'm not sure why this is in particular p2pool's issue .. you run into the same thing with any work server | 12:48 |
| @gmaxwell | maaku: well the p2pool one could well perform poorly for that case, it's not a case anyone working on p2pool has cared to address. | 12:48 |
| Lightsword | maaku, depends, stratum servers like ckpool are pretty good at handling very high connection counts | 12:48 |
| @gmaxwell | and as far as I know no one ever reported a concern with it. | 12:48 |
| Lightsword | gmaxwell, most that have just put ckproxy in front of it AFAIK | 12:49 |
| @gmaxwell | (I mean, p2pool is written in python so networking being stupid is a given) | 12:49 |
| Lightsword | yeah, python is single threaded for the most part | 12:49 |
| katu | Lightsword: indeed. also common sense hashlimit iptables and other. the problem is that the network code is not particularly robust and expects certain degree of expertise wrt networking. | 12:50 |
| katu | Lightsword: similiar to the "slowloris" situation some years back. only after these attacks became commonplace, so did httpd hardening to avoid it. | 12:50 |
| -!- MagikSquirrel [~MagikSqui@unaffiliated/magiksquirrel] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.] | 12:51 | |
| -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has left #bitcoin-wizards [] | 12:52 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds] | 12:52 | |
| Lightsword | katu, yeah, AFAIK ckpool/ckproxy should be fairly resistant to that type of attack | 12:52 |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 12:52 | |
| katu | Lightsword: no idea, my observations are just from playing with bitcoind | 12:53 |
| Lightsword | well bitcoind doesn’t really handle multiple connections well at all :P | 12:53 |
| -!- GGuyZ [~GGuyZ@59-100-109-145.cust.static-ipl.aapt.com.au] has joined #bitcoin-wizards | 12:53 | |
| -!- zookolaptop [~user@63-156-62-129.dia.static.qwest.net] has joined #bitcoin-wizards | 12:54 | |
| Lightsword | then again a lot of pool software doesn’t really do threading….eloipool have to run an instance for every core | 12:59 |
| -!- melvster1 [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 250 seconds] | 13:04 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 256 seconds] | 13:04 | |
| -!- lmatteis [uid3300@gateway/web/irccloud.com/x-lpwixcmulrljnbrq] has quit [Quit: Connection closed for inactivity] | 13:07 | |
| -!- NewLiberty [~NewLibert@134.71.249.228] has quit [Ping timeout: 240 seconds] | 13:12 | |
| -!- GGuyZ [~GGuyZ@59-100-109-145.cust.static-ipl.aapt.com.au] has quit [Quit: GGuyZ] | 13:14 | |
| -!- melvster1 [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards | 13:17 | |
| -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has joined #bitcoin-wizards | 13:17 | |
| -!- GGuyZ [~GGuyZ@59-100-109-145.cust.static-ipl.aapt.com.au] has joined #bitcoin-wizards | 13:20 | |
| -!- CubicEarth [~cubiceart@70-36-136-123.dsl.dynamic.fusionbroadband.com] has joined #bitcoin-wizards | 13:25 | |
| -!- matsjj [~matsjj@213.205.251.158] has joined #bitcoin-wizards | 13:27 | |
| -!- jcorgan is now known as jcorgan|away | 13:29 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 13:29 | |
| -!- GGuyZ [~GGuyZ@59-100-109-145.cust.static-ipl.aapt.com.au] has quit [Quit: GGuyZ] | 13:30 | |
| -!- fabianfabian [~fabianfab@5ED15F42.cm-7-2b.dynamic.ziggo.nl] has joined #bitcoin-wizards | 13:34 | |
| -!- GGuyZ [~GGuyZ@59-100-109-145.cust.static-ipl.aapt.com.au] has joined #bitcoin-wizards | 13:34 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 13:38 | |
| -!- GGuyZ [~GGuyZ@59-100-109-145.cust.static-ipl.aapt.com.au] has quit [Ping timeout: 256 seconds] | 13:39 | |
| -!- CubicEarth [~cubiceart@70-36-136-123.dsl.dynamic.fusionbroadband.com] has quit [Remote host closed the connection] | 13:42 | |
| -!- GGuyZ [~GGuyZ@59-100-109-145.cust.static-ipl.aapt.com.au] has joined #bitcoin-wizards | 13:44 | |
| -!- Terry4 [~Terry4@garza.riseup.net] has quit [Ping timeout: 240 seconds] | 13:44 | |
| -!- GGuyZ [~GGuyZ@59-100-109-145.cust.static-ipl.aapt.com.au] has quit [Ping timeout: 240 seconds] | 13:48 | |
| -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-wizards | 13:51 | |
| -!- GGuyZ [~GGuyZ@59-100-109-145.cust.static-ipl.aapt.com.au] has joined #bitcoin-wizards | 13:53 | |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 13:56 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 256 seconds] | 13:58 | |
| -!- hashtag [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has quit [Ping timeout: 256 seconds] | 14:03 | |
| -!- fkhan [weechat@gateway/vpn/mullvad/x-mozsewsdhsnnifqx] has quit [Ping timeout: 240 seconds] | 14:04 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds] | 14:07 | |
| -!- Logicwax [~Logicwax@c-76-126-174-152.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds] | 14:10 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] | 14:11 | |
| -!- bendavenport [~bpd@96.90.231.161] has quit [Ping timeout: 265 seconds] | 14:11 | |
| -!- tachys_ [~alex@96.90.231.161] has quit [Ping timeout: 256 seconds] | 14:11 | |
| -!- mrkent_ [~textual@unaffiliated/mrkent] has quit [Ping timeout: 256 seconds] | 14:12 | |
| -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 272 seconds] | 14:12 | |
| -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds] | 14:12 | |
| -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has quit [Ping timeout: 245 seconds] | 14:13 | |
| -!- tachys [~alex@96.90.231.161] has joined #bitcoin-wizards | 14:13 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 14:13 | |
| -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-wizards | 14:13 | |
| -!- nwilcox [~nwilcox@c-73-202-109-21.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 14:13 | |
| -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has joined #bitcoin-wizards | 14:15 | |
| -!- bendavenport_ [~bpd@96.90.231.161] has joined #bitcoin-wizards | 14:15 | |
| -!- Logicwax [~Logicwax@c-76-126-174-152.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 14:15 | |
| -!- GGuyZ [~GGuyZ@59-100-109-145.cust.static-ipl.aapt.com.au] has quit [Quit: GGuyZ] | 14:16 | |
| -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards | 14:16 | |
| -!- fkhan [weechat@gateway/vpn/mullvad/x-lkxmxpmacezohmyl] has joined #bitcoin-wizards | 14:18 | |
| -!- fkhan [weechat@gateway/vpn/mullvad/x-lkxmxpmacezohmyl] has quit [Changing host] | 14:18 | |
| -!- fkhan [weechat@unaffiliated/loteriety] has joined #bitcoin-wizards | 14:18 | |
| -!- fkhan [weechat@unaffiliated/loteriety] has quit [Changing host] | 14:18 | |
| -!- fkhan [weechat@gateway/vpn/mullvad/x-lkxmxpmacezohmyl] has joined #bitcoin-wizards | 14:18 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] | 14:21 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 14:24 | |
| -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has joined #bitcoin-wizards | 14:27 | |
| gmaxwell | on the p2pool subject; nice example-- https://www.reddit.com/r/Bitcoin/comments/3w98v8/proof_of_concept_its_not_pretty_but_i_believe/cxui7uo?context=3 the comment there is from someone who runs a mining pool frontend on p2pool and is, I think, one of its larger miners. | 14:28 |
| gmaxwell | And I think the comment suggests that they think you can't mine p2pool or will get paid less if you don't always have at least one share in the window. | 14:28 |
| gmaxwell | (maybe not; but even if the commenter doesn't think that-- other people reading it will) | 14:29 |
| kanzure | window means sharechain? | 14:29 |
| gmaxwell | kanzure: the tip of the sharechain used for payout calculations. | 14:30 |
| bsm1175321 | Please someone correct them. | 14:30 |
| bsm1175321 | There's so much ignorance and noise on reddit and bitcointalk that I rarely read them at all... | 14:30 |
| gmaxwell | If your hashrate is such that you don't always have a share in the sharechain; you'll not get paid for every block. But it's just variance, and not qualitatively different than 1 vs 2 shares. The expected income is still the same, and the variance doesn't have any sudden change or inflection at that point. | 14:31 |
| bsm1175321 | I'm not qualified to correct this one... | 14:31 |
| gmaxwell | midnightmagic was fast. | 14:31 |
| gmaxwell | midnightmagic: you could edit to make it not accuse the poster of misunderstanding that. (I dunno if he does or not, but avoiding a dispute is helpful) | 14:31 |
| gmaxwell | might just be that he's defined for himself a "limit of acceptable variance" at that level. Why at that level? who knows.. why even would a 60GH/s miner care about variance at all who knows. :) | 14:32 |
| kanzure | wouldn't a share be required for payout? | 14:32 |
| kanzure | so if there wasn't a share, how could the payout be the same? | 14:32 |
| kanzure | i am clearly missing something. | 14:33 |
| katu | kanzure: if you have bad luck and miss the window, you dont get payout of course. but *overall* (ie when observing several days) you hit the window. | 14:33 |
| gmaxwell | kanzure: say your expected number of shares in the window is 0.5. This means you won't get paid whenever there isn't one, and when you do have one you'll get paid 2x as much as you deserve. The expectation is 0.5. (same story applies for 1 vs 2). | 14:33 |
| kanzure | ok so this is just about variance; having zero shares in the sharechain should always lead to zero payout. | 14:33 |
| bsm1175321 | Given that p2pool only finds a block every 4 days, that's a lot of variance. | 14:34 |
| gmaxwell | and, of course, sometimes you'll get lucky and have 2 or 3 in the window and get paid massively more than you 'deserve'. | 14:34 |
| -!- zookolaptop [~user@63-156-62-129.dia.static.qwest.net] has quit [Ping timeout: 240 seconds] | 14:34 | |
| bsm1175321 | https://blockchain.info/pools?timespan=4days | 14:34 |
| gmaxwell | bsm1175321: most of the time p2pool isn't finding a block, doesn't matter if you were in or out at those times. | 14:34 |
| oldbrew | sounds like wipe out or surf on a tidal wave | 14:35 |
| kanzure | i think midnightmagic should say "On average, the *expected* payout is the same regardless of previous recent shares" ? | 14:35 |
| kanzure | "payout is the same if there's no share in the p2pool sharechain" just still doesn't compute for me. | 14:36 |
| bsm1175321 | But if on average I only generate 1/2 share per bitcoin block generated, and p2pool only generates a block every 4 days, I need 8 days on average to see any single payout. The lower my share the longer I have to wait for "average payout" to be a relevant term. | 14:36 |
| gmaxwell | bsm1175321: And, a "lot of variance" means that over the month you expected to make $3 and maybe you make $0.5 or $15. --- who cares? critically the same is true but with a slightly narrower window even if you reliably have 1 share in, vs 2. | 14:36 |
| gmaxwell | bsm1175321: there is no waiting. mining is a posson process. | 14:37 |
| kanzure | how do p2pool shares work? are there partial shares? is it difficulty-weighted? | 14:37 |
| gmaxwell | Every block is found infinitely far ahead of it's expected time, because the expected time is always 4 days from now. | 14:37 |
| gmaxwell | kanzure: share difficulty weighed. | 14:38 |
| kanzure | low-difficulty goes in? | 14:38 |
| katu | does not the p2pool divide solo variance by constant factor of 20? | 14:38 |
| gmaxwell | kanzure: miners set their own share difficulty to try to avoid having more than 1000 shares in the window. minimum share difficulty is adjusted to keep the coinbase transaction from being so large that it breaks stupid hardware. | 14:38 |
| kanzure | hm. | 14:38 |
| gmaxwell | katu: no, more like 600. | 14:38 |
| oldbrew | hard to see the global hash rate drop | 14:38 |
| kanzure | i was hoping the answers to my questions would help me rephrase midnightmagic's answer, but they haven't. :-) | 14:39 |
| -!- DigiDreamer [~DigiDream@179-104-178-94.pool.ukrtel.net] has joined #bitcoin-wizards | 14:40 | |
| gmaxwell | katu: the measurement window is many blocks long, so the variance reduction is much larger than the ratio of share difficulties. | 14:40 |
| kanzure | i understand the concept of variance, and why it works out in the end. but i don't understand why you would expect someone to expect payout from not having a share in the sharechain. | 14:40 |
| katu | gmaxwell: yep, of course forgot about that :) | 14:40 |
| bsm1175321 | gmaxwell: payout variance for a small miner (smaller than p2pool share difficulty) is much larger than the average payout (hence often zero) until they mine long enough. The smaller the miner the longer they will mine with zero payout. (That's what I meant by "wait") | 14:41 |
| katu | gmaxwell: it also depends on the total proportion of p2pool hashrate compared to rest. ie it would be much more than 600 if p2pool had large share of the pie, wouldn't it? | 14:41 |
| gmaxwell | bsm1175321: yes but this has no discontinuity. your variance just goes up linearly as your size goes down. | 14:42 |
| bsm1175321 | gmaxwell: agreed. Mining with zero payout sucks, perhaps that's what's driving people away? | 14:42 |
| gmaxwell | katu: right now p2pool's variance is limited by its low hashrate. When it is sufficiently large, it's limited by the sharechain. | 14:42 |
| katu | i see | 14:42 |
| -!- DigiDreamer [~DigiDream@179-104-178-94.pool.ukrtel.net] has quit [Client Quit] | 14:42 | |
| bsm1175321 | So ultimately the restriction comes from limiting the number of outputs in the coinbase. | 14:43 |
| -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards | 14:43 | |
| kanzure | do you mean "On average, the payout is the same independent of sharechain presence, because you might find the winning share yourself" ? | 14:43 |
| kanzure | *of sharechain share inclusion (not presence) | 14:43 |
| gmaxwell | bsm1175321: ... over $3/month expected? I doubt it. And when people talk about it; they always talk in terms of losing money, which isn't whats happening. | 14:43 |
| -!- p15 [~p15@ip-18-214-104-93.static.contabo.net] has quit [Ping timeout: 250 seconds] | 14:44 | |
| -!- GGuyZ [~GGuyZ@msm760.powerhousemuseum.com] has joined #bitcoin-wizards | 14:45 | |
| -!- Erik_dc [~erik@d54C620ED.access.telenet.be] has quit [Remote host closed the connection] | 14:46 | |
| -!- dEBRUYNE_ [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 256 seconds] | 14:46 | |
| -!- MoALTz [~no@78-11-180-214.static.ip.netia.com.pl] has quit [Quit: Leaving] | 14:50 | |
| -!- GGuyZ [~GGuyZ@msm760.powerhousemuseum.com] has quit [Client Quit] | 14:50 | |
| bsm1175321 | gmaxwell p2pool says it keeps track of 8640 shares. That's $1.15 per block won or $8.60 per month (on average) to make it worth mining on p2pool. | 14:50 |
| bsm1175321 | Smaller than that and you'll look at several zero p2pool payouts and wonder if something is wrong... | 14:51 |
| gmaxwell | oh jesus. | 14:51 |
| bsm1175321 | gmaxwell: Just agreeing with you... | 14:52 |
| gmaxwell | bsm1175321: you're saying "to make it worth" | 14:52 |
| gmaxwell | as if you would be paid less if your expected income from mining was $3/month | 14:52 |
| bsm1175321 | Ok rephrase. It's aways "worth it". | 14:53 |
| bsm1175321 | But "Smaller than that and you'll look at several zero p2pool payouts and wonder if something is wrong..." | 14:53 |
| midnightmagic | #p2pool | 14:53 |
| gmaxwell | you just won't get paid in every block, if you have less.. you'll get paid in some and other others; when you mine on p2pool you are not paid by f2pools' blocks, but this doesn't make you lose income. | 14:53 |
| gmaxwell | and unlike other pools, p2pool provides great feedback if you're working or not; and I think thats actually worked against it. | 14:54 |
| kanzure | i think that midnightmagic's reply should be rephrased to say that "You don't lose expected income when the sharechain doesn't have your share. You lose only hypothetical income." or something... | 14:55 |
| -!- liteIRC_ [~zooko@2607:fb90:1708:6387:8dd4:4743:eb06:3b5e] has joined #bitcoin-wizards | 14:55 | |
| kanzure | saying that the payout is the same when there's no share in the sharechain, is just absurd... there's zero payout when a share is absent. | 14:56 |
| bsm1175321 | I wouldn't use the word "lose" -- It's variance, that's all. Sometimes you'll have 2 shares. | 14:56 |
| -!- liteIRC__ [~zooko@63-156-62-129.dia.static.qwest.net] has joined #bitcoin-wizards | 14:57 | |
| -!- liteIRC___ [~zooko@2607:fb90:170b:2ae5:8b44:2c8e:5311:3fbf] has joined #bitcoin-wizards | 14:58 | |
| -!- zooko [~zooko@2607:fb90:170a:c440:fdbc:a417:2167:8986] has quit [Ping timeout: 240 seconds] | 14:58 | |
| -!- liteIRC___ is now known as zooko | 14:58 | |
| kanzure | haha yep i called it, the dude replied "If the miner does not have a share in the P2Pool share chain when P2Pool finds a block then payout=0" | 14:59 |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 250 seconds] | 14:59 | |
| -!- liteIRC_ [~zooko@2607:fb90:1708:6387:8dd4:4743:eb06:3b5e] has quit [Ping timeout: 240 seconds] | 14:59 | |
| midnightmagic | great, you modelled a moron's misinterpretation of arithmetic accurately | 15:00 |
| katu | so basically, the "unattractiveness" of p2pool is that the PPLNS window is too small? | 15:01 |
| kanzure | he was talking about share inclusion, wasn't he? you should instead tell him that he is talking about the wrong concept. | 15:01 |
| -!- liteIRC__ [~zooko@63-156-62-129.dia.static.qwest.net] has quit [Ping timeout: 256 seconds] | 15:01 | |
| AdrianG | how can 21 inc possibly scale p2pool? | 15:02 |
| bsm1175321 | 21 is already 3%, bigger than p2pool. | 15:02 |
| AdrianG | is it even theoretically possible, what they are trying to do? | 15:03 |
| AdrianG | bsm1175321: yes, but they are saying they want to eventually have their devices mining on p2pool v2 or whatgever. | 15:03 |
| AdrianG | i cant see how can it be possibly scaled like that, in their use case, with tiny embedded devices. | 15:03 |
| midnightmagic | is this really -wizards topic material | 15:03 |
| AdrianG | p2pool scalability for embedded, distributed miners? | 15:04 |
| bsm1175321 | midnightmagic: Yeah, I'll take it elsewhere. | 15:04 |
| kanzure | midnightmagic: so, i told you (above) that i understand the concept of variance. i get it. the way you phrased your reddit post was in a way such that someone could read "the payout (when p2pool finds a block) to you is the same even if you don't have a share included", which is simply not true. | 15:08 |
| kanzure | midnightmagic: i think it would be more productive to say that "your expected payout is not determined by p2pool sharechain share inclusion" | 15:08 |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 15:08 | |
| kanzure | or, rather, "p2pool finding a block when the sharechain does not include your share, does not determine your actual expected payout (barring some network failure with transmitting any shares you find)" | 15:10 |
| bsm1175321 | kanzure: FWIW I can see why anyone who has not had Statistics 101 has difficulty understanding. Things we need to teach in grade school... | 15:11 |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 15:13 | |
| bramc | Bitcoin's approach to payout can be summarized as 'Lotteries do a great job of saving bandwidth on rewards payouts'. | 15:17 |
| bsm1175321 | a.k.a. it's not worth it to pay small miners frequently enough to make it worth their time => centralization. :-/ | 15:19 |
| bramc | Only a certain amount of centralization though | 15:21 |
| bramc | What we have now is centralization far in excess of what's necessary to damped the variance in payouts. | 15:22 |
| -!- matsjj [~matsjj@213.205.251.158] has quit [Remote host closed the connection] | 15:24 | |
| -!- meZee [~meZee@unaffiliated/swedftp] has quit [Ping timeout: 256 seconds] | 15:25 | |
| bramc | My cold gets one star. Would not have again. | 15:28 |
| -!- hashtag [~hashtag@cpe-174-97-254-80.ma.res.rr.com] has joined #bitcoin-wizards | 15:29 | |
| -!- Quanttek [~quassel@ip1f11db5b.dynamic.kabel-deutschland.de] has quit [Ping timeout: 246 seconds] | 15:31 | |
| -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards | 15:35 | |
| -!- fabianfabian [~fabianfab@5ED15F42.cm-7-2b.dynamic.ziggo.nl] has quit [Quit: why] | 15:37 | |
| -!- dEBRUYNE [~dEBRUYNE@56-197-ftth.onsbrabantnet.nl] has quit [Ping timeout: 256 seconds] | 15:45 | |
| -!- licnep [uid4387@gateway/web/irccloud.com/x-kgolrahxedduhqhl] has joined #bitcoin-wizards | 15:47 | |
| -!- tcrypt [~tylersmit@173.247.206.110] has joined #bitcoin-wizards | 15:50 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 15:53 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 15:54 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 240 seconds] | 15:58 | |
| -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has quit [Quit: ChatZilla 0.9.92 [Firefox 42.0/20151029151421]] | 16:02 | |
| -!- eudoxia [~eudoxia@r186-55-162-88.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] | 16:07 | |
| -!- MoALTz [~no@78-11-180-214.static.ip.netia.com.pl] has joined #bitcoin-wizards | 16:11 | |
| -!- liteIRC_ [~zooko@2601:281:8001:26aa:857a:3d66:e5d:5748] has joined #bitcoin-wizards | 16:14 | |
| -!- smk [51111532@gateway/web/freenode/ip.81.17.21.50] has quit [Ping timeout: 252 seconds] | 16:16 | |
| -!- zooko [~zooko@2607:fb90:170b:2ae5:8b44:2c8e:5311:3fbf] has quit [Ping timeout: 240 seconds] | 16:17 | |
| -!- liteIRC_ is now known as zooko | 16:17 | |
| -!- JackH [~Jack@host-80-43-143-143.as13285.net] has quit [Ping timeout: 240 seconds] | 16:18 | |
| -!- meZee [~meZee@unaffiliated/swedftp] has joined #bitcoin-wizards | 16:19 | |
| -!- smk [6dc98f28@gateway/web/freenode/ip.109.201.143.40] has joined #bitcoin-wizards | 16:19 | |
| -!- JackH [~Jack@host-80-43-143-143.as13285.net] has joined #bitcoin-wizards | 16:23 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 16:26 | |
| -!- mrkent [~textual@unaffiliated/mrkent] has quit [] | 16:27 | |
| -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-wizards | 16:27 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 16:28 | |
| -!- CubicEarth [~cubiceart@234.sub-70-197-4.myvzw.com] has joined #bitcoin-wizards | 16:41 | |
| -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has quit [Ping timeout: 252 seconds] | 16:45 | |
| -!- CubicEarth [~cubiceart@234.sub-70-197-4.myvzw.com] has quit [Remote host closed the connection] | 16:46 | |
| -!- zookolaptop [~user@2601:281:8001:26aa:6878:6b87:8777:e14a] has joined #bitcoin-wizards | 16:49 | |
| -!- chmod755 [~chmod755@unaffiliated/chmod755] has quit [Quit: Ex-Chat] | 16:54 | |
| -!- tcrypt [~tylersmit@173.247.206.110] has quit [Remote host closed the connection] | 17:18 | |
| -!- mrkent [~textual@unaffiliated/mrkent] has quit [] | 17:19 | |
| Taek42 | midnightmagic: being able to communicate effectively with 'morons' is a powerful timesaving skill. Beneficial to both you and everyone else. | 17:22 |
| -!- Taek42 is now known as Taek | 17:23 | |
| Taek | I had an idea for being able to retroactively add new signature schemes to outputs | 17:24 |
| Taek | Instead of a pubkey, you provide the hash of some secret entropy that could be used to derive a pubkey | 17:25 |
| gmaxwell | then the ZKP that proves its linked is just your 'signature scheme'. :) | 17:25 |
| Taek | Basically | 17:26 |
| gmaxwell | Taek: I'd suggested before if there were a DLP break we could spend unspent coins that way; problem is, of course, all sufficiently performant ZKP schemes are also discrete log assumption (and a much stronger form than ECDSA) | 17:26 |
| katu | Taek: ID-based sig schemes are tad bit heavier than classic schnorr/dsa | 17:26 |
| gmaxwell | Taek: have you seen 'guy fawkes signatures'? | 17:27 |
| Taek | katu: not a problem, you really only want this for emergency situations | 17:27 |
| katu | Taek: depends if you mean guy fawkes, or id based. guy fawkes is just commitment, id based allows pubkeys to be based on specific data | 17:27 |
| Taek | gmaxwell: the snark can be soft-forked into bitcoin after the fact. If a snark ever exists which dodges the discreet log problem then you can still use the scheme. | 17:28 |
| Taek | Actually, p2sh is probably already good enough to offer this protection | 17:28 |
| Taek | gmaxwell: I have not seen guy fawkes sigs before, checking it out now | 17:30 |
| gmaxwell | Taek: can't be soft-forked. | 17:31 |
| gmaxwell | You can't add a new way to spend a existing coin in a softfork. | 17:31 |
| gmaxwell | But who cares? if such a problem existed adding a hardfork way to securely spend the coins would be fine. | 17:31 |
| zookolaptop | There's even a paper on Guy Fawkes Coin by Joe Bonneau. | 17:32 |
| yoleaux | 1 Dec 2015 04:11Z <Taek> zookolaptop: <zookolaptop> "Taek: are you the taek mentioned in https://github.com/NebulousLabs/Sia ?" Yes | 17:32 |
| Taek | Oh, right. You'd need a new type of script designed to allow that type of soft-fork to happen. | 17:33 |
| Taek | Which would be a soft fork itself, it just wouldn't apply to today's outputs | 17:33 |
| midnightmagic | Taek: Recognising it is not possible to do so saves even more; further, recognising that the actual intended audience is not the person that someone seems to be responding to is a useful diplomatic ability. | 17:35 |
| -!- dstadulis [~dstadulis@c-73-189-234-152.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 17:44 | |
| -!- bendavenport_ [~bpd@96.90.231.161] has quit [Quit: bendavenport_] | 17:48 | |
| -!- jcorgan|away is now known as jcorgan | 17:55 | |
| -!- liteIRC_ [~zooko@2607:fb90:170d:8511:27f7:78d5:7715:fa16] has joined #bitcoin-wizards | 17:55 | |
| -!- Yoghur114_2 [~jorn@80.57.227.14] has quit [Remote host closed the connection] | 17:55 | |
| -!- zooko [~zooko@2601:281:8001:26aa:857a:3d66:e5d:5748] has quit [Ping timeout: 264 seconds] | 17:57 | |
| -!- liteIRC_ is now known as zooko | 17:57 | |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lzdqldanpfalfyju] has quit [Quit: Connection closed for inactivity] | 18:01 | |
| -!- dstadulis [~dstadulis@c-73-189-234-152.hsd1.ca.comcast.net] has quit [Quit: ZZZzzz…] | 18:03 | |
| bramc | ZKP is fun but in practice protocols are basically all protocols are built on top of the basics: secure hashes, signatures, encryption, and maybe some, ahem, n of n+1 error correcting codes. | 18:04 |
| -!- rusty1 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 18:05 | |
| -!- tachys [~alex@96.90.231.161] has quit [Remote host closed the connection] | 18:07 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] | 18:09 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] | 18:11 | |
| gmaxwell | bramc: I've got an inefficient ZKP for general computation based on just that! http://people.xiph.org/~greg/simple_verifyable_execution.txt | 18:12 |
| gmaxwell | perhaps you'll finally be the person with enough motivation to crunch out the combinitorics for security paramters so I can actually publish the darn thing for other people to read it? :P | 18:12 |
| bramc | gmaxwell, Thanks, I'll read through that to enhance my understanding of ZKP, which is unfortunately rather lacking. | 18:13 |
| gmaxwell | I came up with it as a teching tool to get programmers who are compfortable with hashes, but think of ZKP for general computation as implausable magic. | 18:14 |
| katu | gmaxwell: very lamport-ey | 18:14 |
| gmaxwell | er to get them to open their mind to the idea that these things can work, and that they can be understood. | 18:14 |
| bramc | Funny thing, my very simple signature scheme may or may not have directly lead to the more sophisticated gizmos based on the same math. I suspect nobody really knows, my mention of them seems to be the first time they were discussed and they were sort of 'in the air' for a while. | 18:15 |
| bramc | I also suspect that the work on communication complexity of recovery schemes is directly based on me explaining that that was the interesting problem after I'd worked out my own solution to it. Unsurprisingly other people worked out better solutions later, but the timing seems to indicate that the work got kickstarted by me blabbing to a few people (exactly whom I've forgotten) about what the interesting problem was. Aga | 18:16 |
| bramc | in I suspect nobody really knows. | 18:16 |
| katu | bramc: you mean your lamportey-knapsack or is there something i missed :) | 18:20 |
| -!- TBI_ [~TBI@20.84-48-195.nextgentel.com] has joined #bitcoin-wizards | 18:27 | |
| bramc | katu: That's the one. The stupid knapsack trick. | 18:28 |
| -!- TBI [~TBI@20.84-48-195.nextgentel.com] has quit [Ping timeout: 240 seconds] | 18:29 | |
| bramc | katu, Actually it's an encryption scheme rather than a signature scheme. I also independently figured out most of the tricks for making lamport signatures independently (I missed winternitz) but that was a few years after the basic had already been published | 18:33 |
| jl2012 | do you think it is good to have a bitcoin-wizards mailing list, so people may share academic idea which may not be otherwise suitable in bitcoin-dev? | 18:34 |
| bramc | That reminds me, I came up with some other tricks more recently which aren't in the published literature which I need to explain to somebody. I spent some time thinking about them because they're useful to nonoutsourceability. It's possible to make strongly non-reusable signatures, meaning ones which you can't use more than once without essentially giving away your key. That doesn't play so well with winternitz though. | 18:34 |
| bramc | jl2012, That depends on the signal/noise ratio it manages to maintain. | 18:35 |
| gmaxwell | bramc: "single show signatures" (or even n-show) are a thing in the crypto lit; they're very easy to construct for discrete log signature systems. | 18:36 |
| bramc | gmaxwell, Is there anything in the literature on doing them for lamport signatures? | 18:37 |
| gmaxwell | I see how you could construct one with a hash based scheme, that was a threshold. "x matching preimages out of a bag of m" | 18:37 |
| gmaxwell | Not that I'm aware of. | 18:37 |
| gmaxwell | but I've never looked. | 18:37 |
| -!- tcrypt [~tylersmit@c-67-169-17-114.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 18:38 | |
| -!- dstadulis [~dstadulis@73.189.234.152] has joined #bitcoin-wizards | 18:38 | |
| bramc | The trick is fairly cute, instead of revealing roughly 1/2 of the preimages, you set it up so you have to reveal 99% of the preimages, so if you sign two things you've probably given away way too much. You can make it efficient by making the preimages be generated in a tree, so when you have to reveal a bunch of things next to each other you reveal their common parent. | 18:38 |
| -!- jcorgan is now known as jcorgan|away | 18:38 | |
| bramc | It's entirely possible somebody else figured that out already of course. | 18:39 |
| gmaxwell | high radix digits and you reveal all bit the value of the digit? | 18:39 |
| bramc | I think that's what I said but I'm not sure what you mean. | 18:39 |
| gmaxwell | like take your message hash in (example) base 16 and for each digit reveal 15 of the preimages? | 18:40 |
| jl2012 | bramc: there are many interesting ideas in Bitcoin but not well organized. For example, the idea of checking block height in script has been discussed even by Satoshi in 2010, while deployed through BIP65 5 years later. It'd be nice if there is a single place to collect these idea | 18:41 |
| bramc | jl2012, Sounds like a job for a wiki | 18:41 |
| gmaxwell | jl2012: well in particular, people lose track of what costs or benefits these ideas have. | 18:41 |
| -!- liteIRC_ [~zooko@63.229.238.215] has joined #bitcoin-wizards | 18:42 | |
| jl2012 | gmaxwell: yes, and we have to discuss the same over and over again | 18:42 |
| gmaxwell | yes, also some of us get tired of that and tune out, and the discussions can sometimes become less informed over time. :( | 18:42 |
| amiller | a wiki would be good | 18:43 |
| amiller | we have plenty of material for a snarks wiki | 18:43 |
| jl2012 | Sometime it is difficult even for me to search my old idea | 18:44 |
| -!- zooko [~zooko@2607:fb90:170d:8511:27f7:78d5:7715:fa16] has quit [Ping timeout: 250 seconds] | 18:44 | |
| -!- liteIRC_ is now known as zooko | 18:44 | |
| amiller | a whole bunch of utxo hash data structures | 18:44 |
| Taek | jl2012: I've been pulling together a set of readmes that point to good sources of information. Bit different from a wiki | 18:45 |
| gmaxwell | jl2012: I have a funny story related to that. a while back, I solved a problem that had troubled me for a while in how to create a system for ring signatures which prevent double usage but where participants could not prove they didn't sign later. ... a tool for selecting trusted judges but keeping them private. | 18:46 |
| Taek | I don't like wiki's because they don't give you a good sense of what else exists that you might be interested in. If two pages are mostly unrelated, you are unlikely to find the second after looking at the first | 18:46 |
| gmaxwell | jl2012: I wrote up my solution. Then a week later, I went to look for it... and found a document I wrote nearly a year before. that had the same solution. | 18:46 |
| gmaxwell | and the same optimizations that I thought I was so clever in coming up with just then. :) | 18:46 |
| -!- adam3us [~Adium@141.8.72.43] has joined #bitcoin-wizards | 18:47 | |
| Taek | jl2012: https://github.com/DavidVorick/knosys | 18:47 |
| jl2012 | maybe a wiki or something under bitcoin.ninja? I also have a short domain name: xbt.hk | 18:47 |
| -!- tcrypt [~tylersmit@c-67-169-17-114.hsd1.ca.comcast.net] has quit [] | 18:47 | |
| -!- dstadulis [~dstadulis@73.189.234.152] has quit [Ping timeout: 272 seconds] | 18:48 | |
| jl2012 | gmaxwell: I just heard a same story from another person. It's common | 18:50 |
| amiller | Taek, that's really cool | 18:53 |
| Taek | amiller: thanks, work in progress of course. Would be great to have more contributors | 18:54 |
| Taek | bsm1175321: did you ever get that wiki software working? I'm guessing Matt would be happy to throw it on bitcoin.ninja | 18:55 |
| Taek | gmaxwell: name overloading is making hard for me to find 'guy fawkes signatures' | 18:58 |
| -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] | 19:03 | |
| -!- liteIRC_ [~zooko@2607:fb90:1709:34f5:f27c:7804:36b9:c2ac] has joined #bitcoin-wizards | 19:05 | |
| -!- GGuyZ [~GGuyZ@msm760.powerhousemuseum.com] has joined #bitcoin-wizards | 19:06 | |
| -!- paulbernard [~paulberna@ec2-52-6-136-108.compute-1.amazonaws.com] has joined #bitcoin-wizards | 19:07 | |
| -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 272 seconds] | 19:07 | |
| jl2012 | Taek: try guy fawkes signatures bitcoin | 19:08 |
| -!- zooko [~zooko@63.229.238.215] has quit [Ping timeout: 256 seconds] | 19:09 | |
| -!- liteIRC_ is now known as zooko | 19:09 | |
| -!- rusty1 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds] | 19:09 | |
| -!- Terry4 [~Terry4@garza.riseup.net] has joined #bitcoin-wizards | 19:10 | |
| -!- joecool [~joecool@no-sources/joecool] has quit [Ping timeout: 240 seconds] | 19:11 | |
| -!- oldbrew [brew@24-212-254-57.cable.teksavvy.com] has quit [Read error: Connection reset by peer] | 19:12 | |
| -!- GGuyZ [~GGuyZ@msm760.powerhousemuseum.com] has quit [Read error: Connection reset by peer] | 19:12 | |
| -!- GGuyZ [~GGuyZ@msm760.powerhousemuseum.com] has joined #bitcoin-wizards | 19:12 | |
| -!- liteIRC_ [~zooko@2601:281:8001:26aa:857a:3d66:e5d:5748] has joined #bitcoin-wizards | 19:14 | |
| -!- GGuyZ [~GGuyZ@msm760.powerhousemuseum.com] has quit [Read error: Connection reset by peer] | 19:14 | |
| -!- GGuyZ [~GGuyZ@msm760.powerhousemuseum.com] has joined #bitcoin-wizards | 19:14 | |
| -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has joined #bitcoin-wizards | 19:14 | |
| Taek | https://fanbitcoin.com/index.php?topic=320634.0 | 19:17 |
| -!- zooko [~zooko@2607:fb90:1709:34f5:f27c:7804:36b9:c2ac] has quit [Ping timeout: 250 seconds] | 19:17 | |
| -!- liteIRC_ is now known as zooko | 19:17 | |
| katu | Taek: Best candidates SIDH, Lamport (possibly BLS? it sure resits index calculus; someone please correct me) | 19:24 |
| gmaxwell | what is 'fanbitcoin.com'? | 19:25 |
| gmaxwell | is this some malwareize version of bitcointalk? | 19:25 |
| jl2012 | Taek: that's my topic on bitcointalk...... | 19:28 |
| jl2012 | original: https://bitcointalk.org/index.php?topic=320634.0 | 19:29 |
| jl2012 | It's either a mirror or malware | 19:30 |
| katu | gmaxwell: it even has an "about us" page https://fanbitcoin.com/index.php?topic=1181932.0 | 19:30 |
| katu | it infested google results at some point :/ | 19:30 |
| -!- GGuyZ [~GGuyZ@msm760.powerhousemuseum.com] has quit [Quit: GGuyZ] | 19:30 | |
| gmaxwell | katu: there have been a bunch of these that proxy the site and replace random links with malware. :( | 19:30 |
| -!- p15 [~p15@ip-19-214-104-93.static.contabo.net] has joined #bitcoin-wizards | 19:32 | |
| -!- GGuyZ [~GGuyZ@203.9.149.3] has joined #bitcoin-wizards | 19:35 | |
| -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_] | 19:47 | |
| -!- dstadulis [~dstadulis@c-73-189-234-152.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 19:48 | |
| -!- GGuyZ [~GGuyZ@203.9.149.3] has quit [Quit: GGuyZ] | 19:50 | |
| -!- oldbrew [brew@24.212.254.57] has joined #bitcoin-wizards | 19:53 | |
| -!- brg444 [46346d00@gateway/web/freenode/ip.70.52.109.0] has joined #bitcoin-wizards | 19:58 | |
| -!- GGuyZ [~GGuyZ@msm760.powerhousemuseum.com] has joined #bitcoin-wizards | 20:01 | |
| -!- GGuyZ [~GGuyZ@msm760.powerhousemuseum.com] has quit [Quit: GGuyZ] | 20:08 | |
| -!- paulbernard [~paulberna@ec2-52-6-136-108.compute-1.amazonaws.com] has left #bitcoin-wizards ["Leaving"] | 20:12 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Remote host closed the connection] | 20:16 | |
| -!- zooko [~zooko@2601:281:8001:26aa:857a:3d66:e5d:5748] has quit [Remote host closed the connection] | 20:19 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Remote host closed the connection] | 20:31 | |
| -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving] | 20:41 | |
| -!- brg444 [46346d00@gateway/web/freenode/ip.70.52.109.0] has quit [Ping timeout: 252 seconds] | 20:42 | |
| Taek | Ah sorry about that. Fun fact I gave my btt password to one of those once. | 20:47 |
| gmaxwell | erp. | 20:52 |
| -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-wizards | 21:00 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 240 seconds] | 21:01 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 21:02 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 21:16 | |
| -!- dstadulis [~dstadulis@c-73-189-234-152.hsd1.ca.comcast.net] has quit [Quit: ZZZzzz…] | 21:20 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 256 seconds] | 21:21 | |
| -!- jcorgan|away is now known as jcorgan | 21:35 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 21:58 | |
| bramc | Taek, Password managers are your friend | 22:07 |
| -!- adam3us1 [~Adium@blockstream.com] has joined #bitcoin-wizards | 22:10 | |
| -!- adam3us [~Adium@141.8.72.43] has quit [Ping timeout: 250 seconds] | 22:11 | |
| -!- alexkuck_ [sid117875@gateway/web/irccloud.com/x-bvvtthxlvivjlkfe] has quit [Ping timeout: 264 seconds] | 22:27 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has joined #bitcoin-wizards | 22:27 | |
| -!- alexkuck_ [sid117875@gateway/web/irccloud.com/x-buzcvlzwaswlpnvj] has joined #bitcoin-wizards | 22:28 | |
| -!- adam3us1 [~Adium@blockstream.com] has quit [Ping timeout: 272 seconds] | 22:29 | |
| -!- bliljerk101 [~bliljerk1@c-71-60-0-241.hsd1.pa.comcast.net] has quit [Ping timeout: 240 seconds] | 22:29 | |
| -!- adam3us [~Adium@141.8.72.43] has joined #bitcoin-wizards | 22:30 | |
| -!- tromp [~tromp@ool-18be0bd8.dyn.optonline.net] has quit [Ping timeout: 250 seconds] | 22:32 | |
| bsm117532 | Taek: would still be happy to throw up a wiki. The hard part is finding maintainers. It's a lot of work. | 22:35 |
| bsm117532 | There are a lot of topics discussed here that lack enough work on them to properly evaluate them. (e.g. DAGs) | 22:36 |
| bsm117532 | Which is why I haven't contributed to your knosys yet...I need to finish forming my opinion, which includes simulations and a more quantitative analysis. | 22:37 |
| bsm117532 | I chose to present a mostly-introductory talk at Scaling Bitcoin because no one really understands anyone about DAGs AFAICT. But that's mostly useless. We need quantitative analysis to make decisions. | 22:39 |
| bsm117532 | *anyone->anything. | 22:39 |
| bsm117532 | I've tried to explain to numerous people how the "bitcoin community makes decisions" because it keeps coming up on ignoramous places like reddit and bitcointalk...but my answer is science: demonstrate, quantitatively that whatever you're doing is better. Either the community accepts it and adopts it, or your analysis is wrong (and someone should prove it) or the community is full of idiots and a fork is called for | 22:42 |
| bramc | The process of decision-making in bitcoin is intentionally haphazardous | 22:43 |
| bsm117532 | bramc: BTW I've been thinking about your Merkle Sets...I need a data structure like a hash map which can contain mostly-similar data. (e.g. 1000 hash maps differing by one hash each) I've been wondering if your Merkle Set could be used? | 22:45 |
| -!- bliljerk101 [~bliljerk1@2601:547:c303:6cd0:5076:c6ef:23a:e155] has joined #bitcoin-wizards | 22:45 | |
| bsm117532 | Doing this wrong costs n^2 while doing it right is linear... | 22:45 |
| -!- sdaftuar [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds] | 22:48 | |
| bramc | bsm117532 Not sure what you mean. What makes something a merkle set as opposed to a regular set is that it maintains a merkle root at all times. Unfortunately this obliterates a hash data structure and forces you to use a tree. | 22:48 |
| -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 246 seconds] | 22:48 | |
| -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 260 seconds] | 22:48 | |
| bsm117532 | Yeah. :-/ | 22:49 |
| bsm117532 | Also forces you to log(n) complexity instead of O(1) :-/ | 22:49 |
| -!- sdaftuar [~sdaftuar@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-wizards | 22:50 | |
| -!- zxzzt [~prod@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-wizards | 22:50 | |
| -!- morcos [~morcos@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-wizards | 22:50 | |
| bsm117532 | Anyway, if you're interested, the "siblings" and "cohort" notions in my talk involve a lot of nearly-same data. | 22:51 |
| -!- licnep [uid4387@gateway/web/irccloud.com/x-kgolrahxedduhqhl] has quit [Quit: Connection closed for inactivity] | 22:56 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds] | 22:59 | |
| bramc | bsm117532 What talk? | 23:03 |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jgxgogaylkjucbjk] has joined #bitcoin-wizards | 23:06 | |
| bsm117532 | https://scalingbitcoin.org/hongkong2015/presentations/DAY2/2_breaking_the_chain_1_mcelrath.pdf | 23:14 |
| bramc | bsm117532 How do you propose splitting transaction fees when a transaction occurs in multiple sides of a braid? | 23:14 |
| bsm117532 | See slide 17. I use a difficulty-weighting. | 23:15 |
| bsm117532 | Each miner receives a difficulty-weighted proportional split. | 23:15 |
| bramc | There needs to be a sanity check of how many generations a braid is allowed to be split before it can't be merged back in. My suggestion would be one: siblings can be merged together, but no uncles or cousins | 23:16 |
| bsm117532 | Why? | 23:16 |
| bsm117532 | That's the purpose of "cohort". If a bead contains many uncles and cousins, its reward is reduced. | 23:17 |
| bramc | That would get rid of most orphans without reducing the incentive to mine all the latest stuff because you could always get merged it later anyway | 23:17 |
| bsm117532 | Orphans in bitcoin get no reward. In my proposal they get a proportional reward. There are no orphans. | 23:17 |
| bramc | I don't see a need for all that complexity. Allowing merging of siblings already gets rid of the vast majority of orphans | 23:17 |
| bsm117532 | The incentive to include the latest stuff is that it creates a bread with higher work, incentivizing other miners to mine on top of yours, preferentially. | 23:18 |
| bsm117532 | bramc: I agree, merging of siblings works with less complexity, but you still have to keep the block rate low so as to not generate more complex graphs that cannot be described simply as "siblings" and a diamond graph. | 23:19 |
| bsm117532 | e.g. your new orphan is a pentagon graph. | 23:19 |
| bramc | Reducing the block rate is viewed as a bit of a pipe dream. You're never going to get it down to seconds, so you're never going to make it fast enough for point of sale transactions anyway. | 23:21 |
| bramc | The risk of incompatible transactions in siblings is very real. In the future it might be the norm. | 23:21 |
| bsm117532 | bramc: there's a fundamental limit related to the size of the earth and the speed of light. Bitcoin is many orders of magnitude slower than that. POS not withstanding... | 23:21 |
| bsm117532 | bramc: Yep and they're forks. | 23:21 |
| bramc | If everything is a fork the ability to merge siblings doesn't help any | 23:22 |
| bramc | I have enough trouble thinking through all the potential ramifications of just being able to merge siblings, much less anything more complicated. And of course the biggest problem here is that it just isn't going to happen, although the idea has a fair amount of appeal. | 23:24 |
| bsm117532 | If it "just isn't going to happen" despite being better than that's dumb...If it's not better then that's the right choice. We'll see. | 23:25 |
| bsm117532 | Not everything is a fork, only conflicting transactions. | 23:25 |
| -!- Guest94083 is now known as [Derek] | 23:28 | |
| -!- [Derek] [~derek@2605:6400:10:3c9:dfd3:3e96:2608:98a7] has quit [Changing host] | 23:28 | |
| -!- [Derek] [~derek@unaffiliated/derek/x-8562683] has joined #bitcoin-wizards | 23:28 | |
| bramc | Conflicting transactions might become the norm. For example if rbf becomes standard the way I'm recommending, you're going to see a lot of conflict between similar transactions with differing fees. And if anyone has potential benefits to sneaking in conflicting transactions they're likely to do so. | 23:29 |
| bsm117532 | bramc: This has the same consequence for bitcoin/blockchain as it has for my proposal. There's no way to ensure that every miner has the same mempool. Mining is how you select one of the conflicting transactions. | 23:30 |
| bramc | There's 'better' and then there's 'clearly better': If something adds complexity, or concern about possible new attacks (even vague feelings of uneasiness about them because it can't be shown to be clearly safe) then it's likely to not happen. And of course hard forks are generally not going to happen just because. | 23:31 |
| bsm117532 | bramc: Don't really care about people's vague feelings, I'll back mine up with numbers. Paper due by the end of the month... | 23:31 |
| bramc | Whenever there's a conflict resolution algorithm people are going to feel queasy about it unless its properties can be absolutely nailed down. That's generally very hard to do. | 23:32 |
| bsm117532 | I've absorbed many good suggestions, but prognostication about decision processes based on vague feelings is not productive... | 23:33 |
| bsm117532 | Will do the best I can... | 23:33 |
| bsm117532 | I'm uneasy about making an altcoin. But I'll do it if necessary. | 23:33 |
| bramc | Well to date there's no process for doing hard forks and many people are against it even in principle, so that's a hurdle. | 23:34 |
| bramc | Even for soft forks decision making tends to be slow and haphazard, as you'd expect from something which intentionally tries to make it impossible to have central control. | 23:35 |
| bsm117532 | I'll just quote jgarzik here: "A hard fork will signal that we’re willing to grow, that we’re willing to change, that we’re willing to change the system. Not increasing it will be seen as, we want to increase fees, we want to push people off the system." | 23:35 |
| bramc | That is hardly a consensus view. Many take the opposite view that transaction fees are not only a good but a necessary thing, and pushing them off creates permanent weaknesses | 23:37 |
| bsm117532 | tx fees are good and necessary. Increasing them by failing to increase blocksize or otherwise increase scalability is dumb. | 23:37 |
| bramc | Increasing the blocksize in many ways decreases scalability because it makes it much harder to run nodes. | 23:39 |
| bsm117532 | Good. Run faster nodes. And let's talk about sharding. | 23:39 |
| bramc | AUGH | 23:39 |
| bramc | those both directly impact security in a horrible way | 23:39 |
| bsm117532 | I simply don't understand this perspective of keeping bitcoin slow as being in any way desirable. | 23:40 |
| bsm117532 | I've never seen any sensible sharding proposal, but we need to go there. | 23:41 |
| -!- bit2017 [~linker@115.79.55.177] has joined #bitcoin-wizards | 23:41 | |
| bramc | The generally favored approach of improving transaction times is to use microchannels. Running the numbers on proposals for reducing block times, even with crazy block-merging tricks, looks fairly hopeless | 23:42 |
| bramc | Sharding is inherently susceptible to all kinds of crazy attacks. You're never going to see the community as a whole build consensus behind it being a good idea. | 23:42 |
| bsm117532 | bramc: I've never seen any numbers on "crazy block-merging tricks". Do you have any refs? | 23:42 |
| bsm117532 | bramc: if bitcoin can't shard, it's dead. | 23:43 |
| bramc | bsm117532 only stuff I've run myself, the main point is that to work for point of sale you need transaction times well under 10 seconds. If you reduce block times to like 1 second and figure orphans always get merged you start getting extremely unpleasant intentional forking attacks. | 23:44 |
| bramc | Sharding isn't going to happen. It doesn't even improve scaling all that much. Net settlement is a fundamentally better approach. | 23:45 |
| bsm117532 | bramc: I don't think my proposal can make a blockchain fast enough for POS. I do think it could get confirmation times under 10s though. | 23:45 |
| bsm117532 | bramc: We may be talking about different things WRT sharding. I mean a node processing only a fraction of the blockchain, while maintaining the security as though every node was processing every transaction. I don't know how to do that yet... | 23:46 |
| bramc | I don't think trying to get the block interval much lower is a particularly useful thing in and of itself if it can't hit POS. Getting the orphan rate down is a good thing for its own reasons though, even if the block time and overall transaction rate remain the same as they are right now. | 23:47 |
| bsm117532 | Intentional forking attacks just increase confirmation time. | 23:47 |
| bsm117532 | bramc: That's my target, I don't think POS is possible. | 23:47 |
| bramc | Keeping miners from killing the orphans of others is a good thing, the problem is avoiding giving them new ways of elbowing each other in the process of getting rid of the old ones. | 23:48 |
| bramc | Intentional forkage could be very valuable if it enables fraud | 23:49 |
| bsm117532 | It's something deserving of careful analysis before adopting any faster idea. | 23:50 |
| bsm117532 | Too much dismissal of ideas without analysis here. Agreed it's an issue, not agreed that it's insurmountable... | 23:50 |
| bramc | There are proposals to allow peers to do partial validation, that's a bit different from sharding. | 23:51 |
| aj | bramc: i keep wondering if it wouldn't be interesting to make a "crobots" style game, where you could program strategies for miners and test them against different potential rulesets for bitcoin | 23:51 |
| bramc | aj usually the strategies are simple enough to work out with pencil and paper | 23:51 |
| -!- oldbrew [brew@24.212.254.57] has quit [] | 23:52 | |
| bsm117532 | bramc: partial validation with a ZKP proving that validation had been done on the portion of the UTXO set I'm not holding would work. | 23:52 |
| bsm117532 | aj: I agree with bramc, it isn't that complicated. ;-) | 23:52 |
| aj | bramc: yeah; but i wonder if something more interactive/demo-like would be more persuasive for the people who aren't already convinced | 23:53 |
| aj | bramc: (there's also the handful of cases where when you work it out via pen-and-paper you miss a case that turns out to be important) | 23:53 |
| bramc | bsm117532 I didn't say that the problems with merging of blocks are insurmountable, just that there are many problems. I will grant you that I'm rather flatly saying that I don't think they'll reduce block times enough to make a fundamental difference there. | 23:55 |
| bramc | That would be an interesting use of ZKP. It probably would create way too much latency with current technology and also still leaves open attacks where someone could hog all the nodes in a certain part of the space and cause the data there to become completely unrecoverable | 23:56 |
| bsm117532 | bramc: Regardless of block time the double-spend attack dominates when the attacker is willing/able to give a different double-spend to each node. It could be done with bitcoin now if an attacker wanted to create 6000 double-spends. That no one has done it is that 10m and 6000 are annoying numbers, not that it's impractical or impossible. | 23:57 |
| bramc | Generally it's a good idea to wait until a few blocks have passed before accepting a transaction as truly committed | 23:58 |
| bramc | aj Having a simulation could easily miss the sorts of malicious behavior which a pencil and paper 'simulation' does as well. | 23:59 |
| --- Log closed Fri Dec 11 00:00:33 2015 | ||
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!
