| --- Log opened Wed Mar 16 00:00:01 2016 | ||
| -!- phiche [~Adium@37.250.84.214.bredband.tre.se] has quit [Quit: Leaving.] | 00:02 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 00:12 | |
| -!- phiche [~Adium@193.89.191.214] has joined #bitcoin-wizards | 00:15 | |
| -!- jaekwon [~jaekwon@c-98-234-63-169.hsd1.ca.comcast.net] has quit [Remote host closed the connection] | 00:21 | |
| -!- spinza [~spin@197.89.233.166] has quit [Ping timeout: 244 seconds] | 00:35 | |
| -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] | 00:40 | |
| -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-wizards | 00:42 | |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-azboyycbtwyfpxwn] has joined #bitcoin-wizards | 00:44 | |
| -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has quit [Ping timeout: 248 seconds] | 00:47 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 00:47 | |
| -!- spinza [~spin@197.89.233.166] has joined #bitcoin-wizards | 00:48 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds] | 00:51 | |
| -!- JackH [~Jack@host-2-103-125-30.as13285.net] has joined #bitcoin-wizards | 01:00 | |
| -!- Esper [~pkotbauer@m176-71-32-29.cust.tele2.se] has joined #bitcoin-wizards | 01:06 | |
| -!- Esper [~pkotbauer@m176-71-32-29.cust.tele2.se] has quit [Ping timeout: 252 seconds] | 01:15 | |
| -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection] | 01:16 | |
| -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-wizards | 01:17 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 01:22 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds] | 01:27 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds] | 01:30 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 01:34 | |
| -!- Esper_ [~pkotbauer@m176-71-32-29.cust.tele2.se] has joined #bitcoin-wizards | 01:35 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 01:40 | |
| -!- proslogion [~proslogio@90.199.33.154] has joined #bitcoin-wizards | 01:45 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 01:48 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has quit [Ping timeout: 240 seconds] | 01:48 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 01:52 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds] | 01:52 | |
| -!- roconnor [~roconnor@host-45-58-253-237.dyn.295.ca] has quit [Ping timeout: 268 seconds] | 02:04 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has joined #bitcoin-wizards | 02:07 | |
| nsh | -- | 02:16 |
|---|---|---|
| nsh | It wasn’t easy at all. The single biggest issue that kept popping up was the actual increase of the block size limit. That's why we settled on “around 2 MB” for the purpose of finishing the letter. If we settled on a base block size of 2 megabytes, the effective size with Segregated Witness would be 3.6, and possibly 8 under adversarial conditions. But we won't really know the exact size witho | 02:16 |
| nsh | ut more discussions between developers and the mining community. If miners and pools are OK with 2 megabytes, that will be fine, but it could end up being slightly smaller. | 02:16 |
| nsh | -- https://bitcoinmagazine.com/articles/btcc-s-sampson-mow-on-block-size-the-bitcoin-community-must-see-through-manipulation-keep-calm-and-write-code-1458061357 | 02:16 |
| nsh | how wo9uld the effective blocksize go up to 8MB under 'adversarial conditions'? | 02:17 |
| -!- jaekwon [~jaekwon@2601:645:c001:263a:7d8e:29:ffc5:adda] has joined #bitcoin-wizards | 02:22 | |
| -!- Esper_ [~pkotbauer@m176-71-32-29.cust.tele2.se] has quit [Ping timeout: 252 seconds] | 02:22 | |
| -!- atgreen [~green@CPE687f74122463-CM00fc8d24cab0.cpe.net.cable.rogers.com] has joined #bitcoin-wizards | 02:23 | |
| aj | nsh: segwit allows up to 4 times the blocksize in witness data; with the blocksize upped to 2MB that would be up to 8MB of witness data | 02:23 |
| aj | nsh: i think the conclusion they came up with was (1MB, 4x) for segwit initially changing to (2MB, 2x) for segwith with a 2MB hardfork, which i think is effectively the equivalent of ~3MB without segwit | 02:24 |
| -!- jaekwon [~jaekwon@2601:645:c001:263a:7d8e:29:ffc5:adda] has quit [Ping timeout: 250 seconds] | 02:26 | |
| gmaxwell | aj: that 'conclusion' came from locking several people who hadn't worked a bit on setwit in a room in pressuring them to agree to something; you should consider it meaningless. | 02:29 |
| nsh | but that's how they pick popes.... | 02:30 |
| gmaxwell | I think it's a misnomer to call that adversarial--- miners could pad up a block with crap to make it take longer to communicate, yes. but they can also simply delay sending it for an almost equivilent effect. And the adversarial case that isn't being considered, which is the one more than a few blocks in the chain have already hit-- blocks that cause nearly 1MB of UTXO expansion, rather than the | 02:32 |
| gmaxwell | very small amount normally. | 02:32 |
| gmaxwell | and twiddling with the SW ratio degrades that protection. | 02:32 |
| gmaxwell | (and achieving a rebalancing of costing to make the limits far more strongly protect the UTXO was _the_ and _the only_ factor in the montreal discussions that got everyone saying "yea, something could be done here". I think it's a travisty that Jeff went back on that discussion and turned around and attacked the one unifying thing that came out of montreal, what a waste of time. | 02:36 |
| nsh | hmm | 02:41 |
| -!- Esper_ [~pkotbauer@m176-71-32-29.cust.tele2.se] has joined #bitcoin-wizards | 02:48 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 02:48 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds] | 02:53 | |
| * adlai fantasizes about a rosy future where angry noisemakers prevent a blocksize hardfork from ever going through, leaving us with the ample room provided by the segwit compromise. | 02:54 | |
| adlai | oops, off-/topic. sorry. | 02:54 |
| adlai | actually it's precisely on-topic, since there's nothing against long-term bitcoin nondevelopment. | 02:54 |
| gmaxwell | lol. | 02:55 |
| gmaxwell | Any good political system has infrastructure for deadlock coded into its DNA. | 02:55 |
| adlai | the political system baked into nakamoto-money is... selling it. | 02:55 |
| adlai | (or buying, if that's your style) | 02:56 |
| adlai | or has satoshi saved his keys, for the day when he must sign-off on an unnecessary yet insufficient hardfork? | 02:56 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 268 seconds] | 03:00 | |
| fluffypony | what if adlai == satoshi? | 03:01 |
| fluffypony | dun dun dun DUN | 03:01 |
| -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] | 03:02 | |
| proslogion | hi, so are we going anywhere with OP_SIDECHAINPROOFVERIFY? thanks | 03:03 |
| JackH | or BIP65, 112 and 113? | 03:06 |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has quit [Ping timeout: 268 seconds] | 03:08 | |
| kanzure | proslogion: i think you can use these instead: OP_WITHDRAWALPROOFVERIFY OP_REORGPROOFVERIFYOP_CHECK_VOTES_VERIFY OP_CHECKMULTISIG | 03:12 |
| nsh | how is a reorg proof verified? | 03:14 |
| kanzure | oops yes those were two separate things, OP_REORGPROOFVERIFY OP_CHECK_VOTES_VERIFY | 03:14 |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards | 03:21 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit] | 03:23 | |
| -!- MoALTz_ is now known as MoALTz | 03:29 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has joined #bitcoin-wizards | 03:30 | |
| -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards | 03:30 | |
| aj | JackH: bip65 is done? 68, 112 and 113 are pending versionbits implementation because classic mining messes up IsSuperMajority aiui | 03:31 |
| JackH | so we have to wait for versionbits before we can enable them? | 03:32 |
| JackH | bip65 is done, but was that not just node policy? | 03:33 |
| aj | 65 is cltv; 68 is nSequence | 03:33 |
| JackH | argh, my bad, I switched them around | 03:33 |
| JackH | 68, yes | 03:33 |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has quit [Ping timeout: 248 seconds] | 03:36 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 03:38 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection] | 03:39 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] | 03:40 | |
| JackH | so what, we are stalling because of classic now? | 03:42 |
| JackH | and we cant deploy what is arguably the most important BIP's ever ? | 03:43 |
| aj | more of a scenic detour than an outright stall | 03:47 |
| JackH | but versionsbits still requires the same from miners as these 3 bips | 03:48 |
| JackH | so detour or not, if the classic miners blocks any feature coming from core... | 03:48 |
| -!- AaronvanW [~ewout@217.121.233.97] has joined #bitcoin-wizards | 03:48 | |
| -!- AaronvanW [~ewout@217.121.233.97] has quit [Changing host] | 03:48 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 03:48 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 03:49 | |
| aj | IsSuperMajority would incorrectly count classic miners that don't implement 68/112/113 as voting for it (because their super high version is greater than 5 or whatever we're up to), versionbits just makes it possible to correctly count support | 03:49 |
| aj | classic has a bit under 5% of blocks, so they can't block it alone atm | 03:50 |
| JackH | hence this applies to 68, 112 and 113 as well | 03:50 |
| JackH | and there is no need to wait for versionbits | 03:50 |
| JackH | unless we can live with a sequential push | 03:51 |
| aj | without versionbits a 95% trigger would be activated with only 90.5% support (the additional 4.5% of classic nodes would put it over the limit) | 03:51 |
| aj | (assuming classic support doesn't increase in the meantime) | 03:51 |
| aj | s/classic nodes/classic blocks/ | 03:51 |
| JackH | well node count shouldn count for much in this case | 03:51 |
| aj | yeah, i mistyped | 03:52 |
| JackH | so, either classic block discovery decreases, or we have to deploy versionbits before we can do 68, 112 and 113 | 03:52 |
| -!- atgreen [~green@CPE687f74122463-CM00fc8d24cab0.cpe.net.cable.rogers.com] has quit [Ping timeout: 260 seconds] | 03:53 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 276 seconds] | 03:54 | |
| JackH | so what will 0.12.1 then contain in respect to the above? | 03:54 |
| aj | https://github.com/bitcoin/bitcoin/pull/7575 and https://github.com/bitcoin/bitcoin/pull/7648 i'd guess? | 03:58 |
| JackH | alright, makes perfect sense now | 04:01 |
| -!- Esper_ [~pkotbauer@m176-71-32-29.cust.tele2.se] has quit [Ping timeout: 246 seconds] | 04:04 | |
| -!- andytoshi [~andytoshi@wpsoftware.net] has quit [Ping timeout: 268 seconds] | 04:09 | |
| JackH | so merge it already | 04:14 |
| adlai | JackH: merge it yourself! or have you not yet forked bitcoin? | 04:16 |
| * adlai grumbles something about this being such a short-term question | 04:16 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has joined #bitcoin-wizards | 04:17 | |
| adlai | fluffypony: you know i'm actually just barely old enough to have been able to invent bitcoin (i read and understood the whipetater in jan '09), although i doubt i'd have had the time to write the code myself, had i thought of it myself. | 04:18 |
| adlai | but don't ask my deans, they definitely would think that i had enough time-not-spent-on-classes to have done so. | 04:19 |
| fluffypony | lol | 04:19 |
| adlai | although arguably, "old enough to invent bitcoin" means "stopped caring enough to shave, many moons before eternal september" | 04:20 |
| * adlai would not have cared enough to invent bitcoin had he not heard about bitcoin first | 04:20 | |
| adlai | (and yes, satoshi was a man. cue Carlin's "no woman would've fucked things up this badly") | 04:23 |
| adlai | https://www.youtube.com/watch?v=gPOfurmrjxo | 04:24 |
| adlai | ^^^ CAUTION: ANY AND ALL URLs CAN AND MAY LEAD TO TIME-STEALING MALWARE ^^^ | 04:24 |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 04:26 | |
| -!- Esper [~pkotbauer@m176-71-32-29.cust.tele2.se] has joined #bitcoin-wizards | 04:27 | |
| -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards | 04:28 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer] | 04:31 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 04:31 | |
| -!- murch [~murch@p4FE39668.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 04:38 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has quit [Ping timeout: 240 seconds] | 04:42 | |
| -!- atgreen [~green@CPE687f74122463-CM00fc8d24cab0.cpe.net.cable.rogers.com] has joined #bitcoin-wizards | 04:45 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 04:50 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds] | 04:55 | |
| -!- nanasho [~nanasha25@195-154-136-40.rev.poneytelecom.eu] has joined #bitcoin-wizards | 04:58 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has joined #bitcoin-wizards | 04:59 | |
| -!- GAit1 [~GAit@93-38-252-172.ip73.fastwebnet.it] has joined #bitcoin-wizards | 05:01 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Ping timeout: 240 seconds] | 05:05 | |
| nanasho | am i wrong to assume that coinwhomustnotbenamed will have the same blockchain growth issues | 05:12 |
| nanasho | 28x as fast, actually? | 05:12 |
| -!- jaekwon [~jaekwon@2601:645:c001:263a:7d8e:29:ffc5:adda] has joined #bitcoin-wizards | 05:15 | |
| -!- jaekwon [~jaekwon@2601:645:c001:263a:7d8e:29:ffc5:adda] has quit [Remote host closed the connection] | 05:16 | |
| -!- jaekwon [~jaekwon@c-98-234-63-169.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 05:16 | |
| -!- andytoshi [~andytoshi@wpsoftware.net] has joined #bitcoin-wizards | 05:19 | |
| proslogion | nanasho: https://blog.ethereum.org/2015/12/24/understanding-serenity-part-i-abstraction/ | 05:21 |
| proslogion | quote: "An important consequence of this is that Serenity introduces a model where all transactions (that satisfy basic formatting checks) are valid; transactions that are currently “invalid” will in Serenity simply have no effect (the invalid opcode in the code above simply points to an unused opcode, immediately triggering an exit from code execution). This does mean that transaction inclusion in a block is no longer a guarantee that t | 05:21 |
| proslogion | he transaction was actually executed; " | 05:21 |
| proslogion | i interpret it as:"all sorts sh*t you can come up with will go into the blocks, no matter if you pay some gases" | 05:22 |
| adlai | nanasho: not just blockchain, but also ~state~ | 05:22 |
| adlai | proslogion: this is true for bitcoin, too. | 05:23 |
| nanasho | othercoin will centralize fast if it cant handle its blocksize | 05:23 |
| nanasho | with proof of stake around the corner also | 05:23 |
| proslogion | adlai: how? you need to pay fees to have your tx mined, in most of the cases | 05:24 |
| adlai | yeah but you don't need to pay fees to have your data mined. | 05:25 |
| adlai | (exercise left for the alert lurker) | 05:25 |
| -!- Esper [~pkotbauer@m176-71-32-29.cust.tele2.se] has quit [Ping timeout: 264 seconds] | 05:26 | |
| proslogion | i think with OP_RETURN you need to burn some outputs, of coz in theory you can burn 0 | 05:28 |
| -!- Esper [~pkotbauer@m176-71-32-29.cust.tele2.se] has joined #bitcoin-wizards | 05:44 | |
| -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Quit: Leaving] | 05:45 | |
| -!- crossing-styx [~crossing-@c-67-165-86-109.hsd1.pa.comcast.net] has joined #bitcoin-wizards | 05:49 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 05:51 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 244 seconds] | 05:55 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 248 seconds] | 05:59 | |
| -!- c0rw1n [~c0rw1n@225.139-67-87.adsl-dyn.isp.belgacom.be] has quit [Remote host closed the connection] | 06:06 | |
| -!- c0rw1n [~c0rw1n@225.139-67-87.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards | 06:07 | |
| -!- proslogion [~proslogio@90.199.33.154] has quit [Ping timeout: 244 seconds] | 06:07 | |
| -!- GAit1 [~GAit@93-38-252-172.ip73.fastwebnet.it] has quit [Quit: Leaving.] | 06:12 | |
| -!- iddo [~idddo@csm.cs.technion.ac.il] has quit [Ping timeout: 252 seconds] | 06:14 | |
| -!- iddo [~idddo@csm.cs.technion.ac.il] has joined #bitcoin-wizards | 06:15 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 06:28 | |
| -!- jaekwon [~jaekwon@c-98-234-63-169.hsd1.ca.comcast.net] has quit [Remote host closed the connection] | 06:36 | |
| -!- Esper [~pkotbauer@m176-71-32-29.cust.tele2.se] has quit [Quit: Lost terminal] | 06:42 | |
| -!- bildramer [~bildramer@p5DC8ADCC.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 06:48 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 06:51 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards | 06:56 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds] | 06:56 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit] | 06:56 | |
| -!- sn0wmonster [~skifree@unaffiliated/sn0wmonster] has joined #bitcoin-wizards | 07:06 | |
| -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards | 07:08 | |
| -!- zooko [~user@50-79-43-161-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 07:27 | |
| -!- proslogion [~proslogio@94.119.67.131] has joined #bitcoin-wizards | 07:33 | |
| -!- proslogion [~proslogio@94.119.67.131] has quit [Ping timeout: 248 seconds] | 07:40 | |
| -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-nkjvcygsodsyflfq] has joined #bitcoin-wizards | 07:42 | |
| -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 07:43 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds] | 07:45 | |
| -!- Guyver2_ is now known as Guyver2 | 07:45 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 07:52 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] | 07:56 | |
| -!- proslogion [~proslogio@130.159.13.130] has joined #bitcoin-wizards | 07:57 | |
| -!- GAit [~GAit@212.91.77.40] has quit [Quit: Leaving.] | 07:58 | |
| -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards | 08:04 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has quit [Ping timeout: 250 seconds] | 08:08 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has joined #bitcoin-wizards | 08:13 | |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer] | 08:15 | |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards | 08:16 | |
| -!- GAit [~GAit@212.91.77.40] has quit [Quit: Leaving.] | 08:16 | |
| -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards | 08:22 | |
| -!- GAit [~GAit@212.91.77.40] has quit [Remote host closed the connection] | 08:22 | |
| -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-wizards | 08:23 | |
| -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards | 08:26 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 276 seconds] | 08:28 | |
| -!- zooko [~user@50-79-43-161-static.hfc.comcastbusiness.net] has quit [Ping timeout: 244 seconds] | 08:31 | |
| -!- GAit [~GAit@212.91.77.40] has quit [Quit: Leaving.] | 08:32 | |
| -!- voxelot [~voxelot@remote.digitalmoneycorp.com] has joined #bitcoin-wizards | 08:32 | |
| -!- funkenstein_ [~bowler@unaffiliated/funkenstein] has joined #bitcoin-wizards | 08:37 | |
| -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards | 08:52 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 08:53 | |
| -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards | 08:56 | |
| -!- GAit [~GAit@212.91.77.40] has quit [Client Quit] | 08:56 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds] | 08:58 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 09:03 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 09:06 | |
| -!- andytoshi [~andytoshi@wpsoftware.net] has quit [Changing host] | 09:13 | |
| -!- andytoshi [~andytoshi@unaffiliated/andytoshi] has joined #bitcoin-wizards | 09:13 | |
| -!- aspect_ [uid151486@gateway/web/irccloud.com/x-ttryurccfrpavvsj] has joined #bitcoin-wizards | 09:13 | |
| -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards | 09:13 | |
| -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection] | 09:19 | |
| -!- GAit [~GAit@212.91.77.40] has quit [Quit: Leaving.] | 09:19 | |
| -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards | 09:19 | |
| -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has quit [Read error: Connection reset by peer] | 09:22 | |
| -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [Remote host closed the connection] | 09:24 | |
| -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards | 09:24 | |
| -!- GAit [~GAit@212.91.77.40] has quit [Client Quit] | 09:24 | |
| -!- Tiraspol [~Tiraspol3@c-98-212-187-224.hsd1.il.comcast.net] has joined #bitcoin-wizards | 09:24 | |
| -!- Tiraspol [~Tiraspol3@c-98-212-187-224.hsd1.il.comcast.net] has quit [Changing host] | 09:24 | |
| -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards | 09:24 | |
| -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards | 09:26 | |
| -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has quit [Read error: Connection reset by peer] | 09:27 | |
| -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards | 09:27 | |
| -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards | 09:28 | |
| -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [Remote host closed the connection] | 09:39 | |
| -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards | 09:39 | |
| -!- GAit [~GAit@212.91.77.40] has quit [Quit: Leaving.] | 09:39 | |
| -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards | 09:44 | |
| -!- markus-k [~markus-k@p4FCCC251.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 09:49 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 09:54 | |
| -!- everyBloc [~everybloc@c-73-158-140-36.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 09:56 | |
| -!- everyBloc [~everybloc@c-73-158-140-36.hsd1.ca.comcast.net] has quit [Remote host closed the connection] | 09:56 | |
| -!- GAit [~GAit@212.91.77.40] has quit [Quit: Leaving.] | 09:57 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 248 seconds] | 09:58 | |
| -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards | 10:01 | |
| -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection] | 10:02 | |
| -!- everyBloc [~everybloc@c-73-158-140-36.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 10:02 | |
| -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards | 10:06 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards | 10:07 | |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 10:07 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 276 seconds] | 10:11 | |
| -!- GAit [~GAit@212.91.77.40] has quit [Quit: Leaving.] | 10:13 | |
| -!- brianhoffman [~brianhoff@pool-173-79-161-229.washdc.fios.verizon.net] has joined #bitcoin-wizards | 10:16 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards | 10:23 | |
| -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards | 10:30 | |
| -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards | 10:31 | |
| -!- phiche [~Adium@193.89.191.214] has quit [Quit: Leaving.] | 10:33 | |
| -!- GAit [~GAit@212.91.77.40] has quit [Ping timeout: 244 seconds] | 10:37 | |
| -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-wizards | 10:38 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 260 seconds] | 10:41 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 10:54 | |
| -!- proslogion [~proslogio@130.159.13.130] has quit [Ping timeout: 268 seconds] | 10:57 | |
| -!- gigq [~gigq@2602:302:d14c:51a0:34db:7d7:328e:126d] has quit [Remote host closed the connection] | 10:59 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds] | 10:59 | |
| -!- gigq [~gigq@45-20-197-26.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards | 11:04 | |
| -!- molz [~molly@unaffiliated/molly] has quit [Write error: Connection reset by peer] | 11:06 | |
| -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-wizards | 11:07 | |
| -!- wallet421 [~wallet42@172.58.104.227] has joined #bitcoin-wizards | 11:13 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Ping timeout: 248 seconds] | 11:16 | |
| -!- joesmoe_ [~joesmoe@201.216.206.41] has joined #bitcoin-wizards | 11:17 | |
| -!- joesmoe [~joesmoe@201.216.206.41] has quit [Read error: Connection reset by peer] | 11:19 | |
| -!- cluckj [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has joined #bitcoin-wizards | 11:42 | |
| -!- binaryatrocity [~quassel@unaffiliated/br4n] has joined #bitcoin-wizards | 11:46 | |
| -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection] | 11:50 | |
| -!- CrazyTruthYakDDS [uid67551@gateway/web/irccloud.com/x-wlfsidzkcejhihia] has joined #bitcoin-wizards | 11:53 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 11:55 | |
| -!- Guest28763 is now known as [Derek] | 11:56 | |
| -!- murch [~murch@p4FE39668.dip0.t-ipconnect.de] has left #bitcoin-wizards [] | 11:56 | |
| -!- [Derek] [~derek@2605:6400:10:3c9:dfd3:3e96:2608:98a7] has quit [Changing host] | 11:56 | |
| -!- [Derek] [~derek@unaffiliated/derek/x-8562683] has joined #bitcoin-wizards | 11:56 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] | 12:00 | |
| -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has joined #bitcoin-wizards | 12:00 | |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 12:05 | |
| -!- jaekwon [~jaekwon@173-13-150-22-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 12:12 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 12:15 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Client Quit] | 12:17 | |
| -!- throughnothing [~throughno@162.217.73.10] has joined #bitcoin-wizards | 12:22 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Read error: Connection reset by peer] | 12:22 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards | 12:22 | |
| -!- mol11111 [~molly@unaffiliated/molly] has joined #bitcoin-wizards | 12:26 | |
| -!- mol11111 is now known as moli | 12:27 | |
| -!- jaekwon [~jaekwon@173-13-150-22-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 248 seconds] | 12:28 | |
| -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds] | 12:28 | |
| -!- jaekwon [~jaekwon@173-13-150-22-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 12:32 | |
| maaku | jonasschnelli: for what it's worth, there are many useful applications for loading UTXO dumps | 12:41 |
| maaku | i think that's code that should exist | 12:41 |
| -!- Krellan [~krellan@2601:640:4000:1ee4:216d:f0a0:9e73:dc3c] has joined #bitcoin-wizards | 12:46 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 12:56 | |
| -!- kaptah [kaptah@hilla.kapsi.fi] has quit [Ping timeout: 250 seconds] | 12:57 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 276 seconds] | 13:01 | |
| -!- jaekwon [~jaekwon@173-13-150-22-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 260 seconds] | 13:02 | |
| -!- jaekwon [~jaekwon@173-13-150-22-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 13:07 | |
| -!- funkenstein_ [~bowler@unaffiliated/funkenstein] has quit [Quit: Leaving] | 13:07 | |
| -!- kaptah [kaptah@hilla.kapsi.fi] has joined #bitcoin-wizards | 13:07 | |
| -!- bliljerk101 [~bliljerk1@2601:547:c303:6cd0:449b:111b:6de8:e61] has quit [Read error: Connection reset by peer] | 13:14 | |
| -!- bliljerk101 [~bliljerk1@2601:547:c303:6cd0:d06b:c193:b43c:eaca] has joined #bitcoin-wizards | 13:14 | |
| -!- proslogion [~proslogio@90.199.33.154] has joined #bitcoin-wizards | 13:17 | |
| -!- jaekwon [~jaekwon@173-13-150-22-sfba.hfc.comcastbusiness.net] has quit [Remote host closed the connection] | 13:18 | |
| -!- nuke1989 [~nuke@46-86-125.adsl.cyta.gr] has joined #bitcoin-wizards | 13:19 | |
| -!- jaekwon [~jaekwon@75-144-246-5-SFBA.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 13:19 | |
| -!- phiche [~Adium@37.250.84.214.bredband.tre.se] has joined #bitcoin-wizards | 13:23 | |
| -!- jaekwon [~jaekwon@75-144-246-5-SFBA.hfc.comcastbusiness.net] has quit [Ping timeout: 244 seconds] | 13:23 | |
| -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards | 13:25 | |
| -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection] | 13:26 | |
| -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards | 13:26 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Remote host closed the connection] | 13:27 | |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards | 13:28 | |
| -!- nanasho [~nanasha25@195-154-136-40.rev.poneytelecom.eu] has quit [Quit: Leaving] | 13:28 | |
| -!- nanasho [~nanasha25@195-154-136-40.rev.poneytelecom.eu] has joined #bitcoin-wizards | 13:29 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] | 13:44 | |
| -!- funkenstein_ [~bowler@unaffiliated/funkenstein] has joined #bitcoin-wizards | 13:55 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 13:57 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 244 seconds] | 14:01 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds] | 14:08 | |
| -!- joesmoe_ [~joesmoe@201.216.206.41] has quit [Ping timeout: 268 seconds] | 14:23 | |
| -!- Don_John [~Don@ip72-211-182-139.tc.ph.cox.net] has joined #bitcoin-wizards | 14:23 | |
| -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection] | 14:26 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] | 14:47 | |
| -!- koshii [~w@c-68-58-151-30.hsd1.in.comcast.net] has quit [Ping timeout: 246 seconds] | 14:57 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 14:58 | |
| -!- koshii [~w@c-68-58-151-30.hsd1.in.comcast.net] has joined #bitcoin-wizards | 14:58 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards | 15:01 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds] | 15:02 | |
| -!- kisspunch_ [~za3k@71.19.156.60] has joined #bitcoin-wizards | 15:13 | |
| -!- kisspunch [~za3k@za3k.com] has quit [Ping timeout: 260 seconds] | 15:14 | |
| -!- HastaJun [~10339A764@c-98c5e455.02-226-6c6b701.cust.bredbandsbolaget.se] has quit [Ping timeout: 276 seconds] | 15:14 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 15:15 | |
| -!- kisspunch_ is now known as kisspunch | 15:15 | |
| -!- iLearn [~ilearn@h-219-171.a240.priv.bahnhof.se] has joined #bitcoin-wizards | 15:17 | |
| -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [Remote host closed the connection] | 15:17 | |
| -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards | 15:17 | |
| -!- adlai [~adlai@unaffiliated/adlai] has quit [Ping timeout: 250 seconds] | 15:21 | |
| -!- throughnothing [~throughno@162.217.73.10] has quit [Quit: Leaving...] | 15:24 | |
| -!- iLearn [~ilearn@h-219-171.a240.priv.bahnhof.se] has quit [Remote host closed the connection] | 15:24 | |
| -!- earthris1 [~earthrise@S01065404a6902716.cg.shawcable.net] has quit [Remote host closed the connection] | 15:25 | |
| -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [Remote host closed the connection] | 15:26 | |
| -!- Tiraspol [~Tiraspol3@c-98-212-187-224.hsd1.il.comcast.net] has joined #bitcoin-wizards | 15:26 | |
| -!- Tiraspol [~Tiraspol3@c-98-212-187-224.hsd1.il.comcast.net] has quit [Changing host] | 15:26 | |
| -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards | 15:26 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 15:28 | |
| -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards | 15:29 | |
| -!- bramc [26632a82@gateway/web/freenode/ip.38.99.42.130] has joined #bitcoin-wizards | 15:29 | |
| bramc | Hey everybody. I've got a very early draft of a new BIP ready, early enough that I don't really want to send it to the list yet. Is there a sucker^H^H^H^H^H^Hvolunteer who would like to give feedback on it? | 15:31 |
| -!- HastaJun [~10339A764@c-98c5e455.02-226-6c6b701.cust.bredbandsbolaget.se] has joined #bitcoin-wizards | 15:32 | |
| -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving] | 15:33 | |
| JackH | what does it do | 15:35 |
| bramc | JackH: It adds a not valid after time to transactions | 15:36 |
| maaku | bramc: you know the probability of this being accepted is ~0? | 15:36 |
| maaku | unless you added a 100-block maturity period, but that would eliminate many (most?) use cases | 15:37 |
| bramc | maaku: I disagree with you on that point. There are some reasonable qualms about it, but there are strong arguments in favor and I believe I have argued it well. Notably my motivation and rationale sections are longer than most BIPs are in total. | 15:37 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 248 seconds] | 15:37 | |
| bramc | maaku: A 100 block maturity period doesn't eliminate the most important use cases. I can send you then document if you'd like to see the argument | 15:38 |
| bramc | Because it would be silly for me to repeat my arguments badly on IRC when you could be reading the actual document and giving useful feedback on it. | 15:38 |
| maaku | sorry i wouldn't have time. just wanted to save you from wasting your time :\ | 15:39 |
| -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards | 15:41 | |
| JackH | is it on github yet bramc | 15:42 |
| bramc | JackH: No not on github yet, is that the preferred way to solicit feedback? | 15:43 |
| -!- nabu [~nabu@192.40.88.15] has quit [Ping timeout: 240 seconds] | 15:43 | |
| JackH | I personally would like it there, but cant speak for all | 15:43 |
| JackH | easy browseable | 15:43 |
| bramc | I was thinking email, but github has handy suggested edits | 15:43 |
| JackH | yep that too | 15:43 |
| bramc | Okay here you go https://github.com/bramcohen/NotValidAfter/blob/master/Transaction_expirations.txt | 15:48 |
| bramc | Feedback much appreciated | 15:49 |
| nanasho | can it only be done using segwit? :( | 15:49 |
| bramc | nanasho: Unfortunately yes, the extension hooks pre-segwit suck too badly | 15:50 |
| bramc | Otherwise I'd have written something months ago | 15:50 |
| nanasho | i think segwit is an accounting trick to fool miners | 15:51 |
| -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has left #bitcoin-wizards [] | 15:52 | |
| bramc | No segwit is a bug fix to something core to how bitcoin transactions work coupled with improved hooks for future extensions and some extra space in blocks as a bonus | 15:52 |
| bramc | Calling it an 'accounting trick' is rather silly. It increases effective block size. Perhaps it does that in a way which is too purple or green, the effect is the same. | 15:53 |
| bramc | Actual feedback would be appreciated | 15:55 |
| -!- phiche [~Adium@37.250.84.214.bredband.tre.se] has quit [Quit: Leaving.] | 15:55 | |
| * nsh science spideysense tingles | 15:57 | |
| -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has joined #bitcoin-wizards | 15:58 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 15:58 | |
| nanasho | if sigs (witness data) is not stored in blocks, how can the sig of an old (segwit) transaction reliably be stored? | 15:59 |
| -!- joesmoe [~joesmoe@201.216.206.41] has joined #bitcoin-wizards | 15:59 | |
| nsh | bramc, can you handwave through this bit? 'WRITEME details of how it's made possible by segwit and works with that go here' | 16:00 |
| andytoshi | nanasho: that question makes no sense. the signature data is committed to just like the rest of the data. whether it is "in a block" depends on what you consider to be a block | 16:00 |
| -!- nabu [~nabu@192.40.88.16] has joined #bitcoin-wizards | 16:01 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] | 16:03 | |
| Luke-Jr | nanotube: it is stored in blocks | 16:06 |
| Luke-Jr | bramc: can you mediawiki it? :/ | 16:08 |
| Luke-Jr | bramc: preferred form for review is a fork of the bips repo | 16:08 |
| funkenstein_ | nanasho, good question | 16:08 |
| bramc | nsh: Unfortunately I can't. nullc told me that it's fairly trivial after segwit and I believe him | 16:09 |
| nsh | kk | 16:10 |
| nsh | i need to better understand segwit anyway. should read up | 16:10 |
| nanasho | bramc, that sounds bad if you ask me | 16:11 |
| nsh | was just thinking about the possibility of transactions having an invalidation pubkey which means clients seeing a future transaction that includes the corresponding privkey as an 0 value input would remove it from mempool and not mine | 16:11 |
| nanasho | so signatures are "somewhere else", but we havent really figured this out. still segwit is due in one month if yo u believe the roadmap. crazy stuff | 16:12 |
| nsh | which might be complementary to blockheight expiry | 16:12 |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 16:13 | |
| Eliel | nsh: segwit lays down the foundation for script language upgrades as a soft-fork. I understood that you could even add support for a completely new scripting language as a soft-fork with it. | 16:15 |
| Luke-Jr | nanasho: signatures are not somewhere else | 16:15 |
| nanasho | there not part of the tx hashing process. so why should they be stored in the blockchain? they are not needed to verify the hash. (in case of segwit) | 16:16 |
| nanasho | *they're | 16:16 |
| Eliel | nanasho: they're not part of tx hashes, but they end up as part of the block hash. | 16:16 |
| Luke-Jr | nanasho: yes they are | 16:16 |
| Eliel | because they're hashes separately | 16:16 |
| Luke-Jr | nanasho: they're hashed into the block, just not the txids | 16:16 |
| nanasho | Eliel, care to elaborate? | 16:16 |
| Luke-Jr | which is kinda the point | 16:16 |
| -!- proslogion [~proslogio@90.199.33.154] has quit [Ping timeout: 252 seconds] | 16:17 | |
| Eliel | nanasho: more accurately, in the softfork segwit, they're actually hashed into the coinbase transaction. | 16:17 |
| nanasho | how can old clients consider the block invalid if the hash in the coinbase is rubbish? | 16:17 |
| -!- wallet421 [~wallet42@172.58.104.227] has quit [Ping timeout: 248 seconds] | 16:17 | |
| nanasho | they wouldnt know would they? | 16:18 |
| maaku | nanasho: see every soft fork ever | 16:18 |
| Eliel | nanasho: they don't care about the coinbase input where that is stored. | 16:18 |
| Luke-Jr | nanasho: that's what softforks are | 16:18 |
| nanasho | so a hash of witness data is in the coinbase transaction | 16:19 |
| nanasho | of all txs in the block | 16:19 |
| bramc | nsh: I'm not sure what the use case for that would be. The claim that transactions which can become invalidated are potentially dangerous has some validity, I'm justifying a not valid after for a very specific use case where other hacks couldn't work. | 16:19 |
| Eliel | nanasho: yes, a merkle root for them I think was what goes in there. | 16:19 |
| nanasho | ok | 16:19 |
| nsh | it would make things more chaotic and therefore entertaining | 16:20 |
| nanasho | but where do i get the witness data 2 weeks down the line? the blockchain only stores the merkle root :3 where are the sigs | 16:20 |
| Luke-Jr | nanasho: no, the blockchain stores all the data as it does now | 16:20 |
| Luke-Jr | and just like you can prune now, you can prune with segwit too | 16:20 |
| nsh | (no, but i'm interested in the kinds of attacks that might be facilitated by transaction invalidation and you don't usually get to find out about things quickly until they exist) | 16:21 |
| Eliel | nanasho: old nodes won't even download it. Upgraded nodes will download it and store it. | 16:21 |
| nanasho | Eliel, where? | 16:21 |
| nsh | (i think we should make all kinds of silly decisions in non-omgsrsbsns experimental/side chains) | 16:21 |
| Eliel | nanasho: as part of the block. | 16:21 |
| nanasho | luke says, on the blockchain. you say, old nodes wont see it. how can this be if it is on the blockchain, or is it not | 16:21 |
| Eliel | nanasho: as far as old nodes are concerned, the witness data doesn't exist. For upgraded nodes, it's part of the block. Not that difficult. | 16:22 |
| bramc | Luke-Jr: I don't know mediawiki. Are you asking for me to post in a particular place? | 16:22 |
| nanasho | and where in the block is it stored? | 16:23 |
| Luke-Jr | bramc: every BIP is written in mediawiki. just copy the formatting from one | 16:23 |
| nanasho | for upgraded nodes to find | 16:23 |
| Luke-Jr | bramc: it's the format | 16:23 |
| nanasho | the what | 16:23 |
| Luke-Jr | nanasho: after the outputs | 16:23 |
| bramc | Luke-Jr: Okay I'll do that later | 16:24 |
| Eliel | nanasho: The block structure has been extended with new datafields in the upgraded version. That's where it's stored. | 16:24 |
| Luke-Jr | nanasho: the current format is: <version><inputs+signatures><output_scripts><locktime> | 16:25 |
| Luke-Jr | nanasho: the new format is: <version><inputs><output_scripts><signatures><locktime> | 16:25 |
| nanasho | i see | 16:25 |
| Luke-Jr | nanasho: currently, the txid is H(transaction) | 16:25 |
| Luke-Jr | with segwit, the txid is H(<version><inputs+empty signatures><output_scripts><locktime) | 16:25 |
| nanasho | alright | 16:26 |
| nanasho | and the missing part, sigs | 16:26 |
| nanasho | is in the coinbase | 16:26 |
| funkenstein_ | Luke-Jr> nanasho: no, the blockchain stores all the data as it does now <-- really? | 16:26 |
| nanasho | it actually makes sense | 16:26 |
| Luke-Jr | nanasho: the sigs are in the transaction after the output scripts, but not used in the txid hashing | 16:26 |
| Luke-Jr | funkenstein_: yes | 16:26 |
| nanasho | hmm | 16:26 |
| Eliel | nanasho: it's not actually in the coinbase as such. Only the merkle root is. | 16:26 |
| nanasho | yeah but you'd need all sigs to create the merkle root yourself | 16:27 |
| funkenstein_ | hmm i am confused, i thought there was a space reduction | 16:27 |
| nanasho | so it is needed for verification | 16:27 |
| nanasho | making it part of the blockchain | 16:27 |
| Luke-Jr | nanasho: yes, it's part of the block | 16:27 |
| Luke-Jr | funkenstein_: there isn't. | 16:27 |
| Luke-Jr | funkenstein_: a 2 MB segwit block uses the same space as a 2 MB HF block | 16:27 |
| nsh | but if it was a 2MB block of pure lead vs. a 2MB block of classic features | 16:28 |
| Eliel | nanasho: yes, I think you got it now. | 16:28 |
| nsh | which would be more truthy? | 16:28 |
| Luke-Jr | if you're willing to *trust* old blocks, you'll be able to skip downloading parts of the blockchain (ie, better pruning), but this is a security reduction, not full nodes anymore | 16:28 |
| nsh | *feathers | 16:28 |
| -!- nanasho [~nanasha25@195-154-136-40.rev.poneytelecom.eu] has quit [Read error: Connection reset by peer] | 16:28 | |
| Luke-Jr | nsh: what? | 16:28 |
| nsh | nm, bad joke. mauled | 16:28 |
| funkenstein_ | Luke-Jr, thank you - i will go read in more detail | 16:28 |
| Luke-Jr | schnorr signatures, a different softfork, can reduce the size of transactions significantly, and doing that softfork is made easier with segwit - but it is in the end a separate feature/softfork entirely | 16:29 |
| Luke-Jr | schnorr signatures allows you to provide 1 signature for *all* the inputs, rather than N signatures for N inputs | 16:30 |
| maaku | well, schnorr signature agregation, to be pedantic | 16:30 |
| Luke-Jr | which also means CoinJoins become much more valuable for compression | 16:30 |
| nsh | yeah, that proposal is great imho | 16:30 |
| nsh | combined with some external mechanism to facilitate wide coinjoins it would go a long way to improving a bunch of stuff at once | 16:31 |
| Eliel | Although, the practical effect of schnorr after segwit, for transaction throughput, is less than you might expect from the numbers. | 16:31 |
| Luke-Jr | I wonder if there's a way to allow miners to do the signature combining somehow | 16:31 |
| Luke-Jr | would be nice if the entire block could just have one sig :P | 16:31 |
| nsh | heh, aye... | 16:31 |
| nsh | i don't think you can eliminate interactivity | 16:31 |
| maaku | Luke-Jr: yes, that's what OWAS is | 16:32 |
| -!- Jeremy_Rand_2 [~user@ip68-97-35-223.ok.ok.cox.net] has quit [Ping timeout: 248 seconds] | 16:32 | |
| maaku | it involves new crypto assumptions however | 16:32 |
| nsh | pairing? | 16:32 |
| maaku | yes | 16:32 |
| maaku | https://bitcointalk.org/index.php?topic=290971.0 | 16:32 |
| nsh | could be enabled as a softfork with transactions using an opcode to signify trust in the pairing crypto and allowing miners to aggregate their signatures | 16:33 |
| nsh | but it could be argued that this affects fidelity for people not electing to trust the crypto | 16:33 |
| maaku | It's not as interesting as it seems for privacy reasons though, because anyone listening on the network hears about the original transaction form, and knows the inputs + outputs | 16:33 |
| maaku | It's also fairly slow, compared with schnorr | 16:34 |
| nsh | well, it puts an ongoing storage cost on deaggregation which is nonzero | 16:34 |
| nsh | but utah is a big place | 16:34 |
| Luke-Jr | maaku: slow to verify? | 16:34 |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 16:34 | |
| Luke-Jr | hmm, I wonder if it would break pruning | 16:34 |
| maaku | Luke-Jr: yes. Not unacceptably, but yes. | 16:34 |
| nsh | where acceptably is understood as/ | 16:35 |
| nsh | ? | 16:35 |
| maaku | yes to slow to verify, no it wouldn't break pruning | 16:35 |
| nsh | ah | 16:35 |
| -!- nanasho [~nanasha25@141.39.226.229] has joined #bitcoin-wizards | 16:42 | |
| nanasho | short recap, upgraded nodes store sigs/witness data, but old nodes dont, they see anyone can spend transactions, correct? | 16:43 |
| -!- idClip [~idClip@HSI-KBW-149-172-40-171.hsi13.kabel-badenwuerttemberg.de] has joined #bitcoin-wizards | 16:44 | |
| -!- idClip [~idClip@HSI-KBW-149-172-40-171.hsi13.kabel-badenwuerttemberg.de] has left #bitcoin-wizards [] | 16:44 | |
| maaku | nanasho: they don't 'see' anything. they see 'other people's transactions' | 16:45 |
| maaku | full nodes don't bother classifying transactions as anyone can spend or otherwise | 16:46 |
| kanzure | and even if they did, that classification would be useless because "anyone can spend" is not a guarantee about ordering :P | 16:46 |
| maaku | but other than that quibble about meaning, your understanding of the technology is correct | 16:46 |
| -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards | 16:46 | |
| nanasho | hm ok | 16:48 |
| nanasho | old nodes see an empty sig ... wouldn't some people try to spend those outputs? | 16:48 |
| -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection] | 16:52 | |
| -!- joesmoe_ [~joesmoe@201.216.206.41] has joined #bitcoin-wizards | 16:53 | |
| -!- joesmoe [~joesmoe@201.216.206.41] has quit [Read error: Connection reset by peer] | 16:53 | |
| maaku | i guess. does it matter? | 16:54 |
| maaku | did you know that reused P2SH addresses are anyone can spend? | 16:54 |
| maaku | (under the old rules) | 16:54 |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards | 16:55 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 16:59 | |
| -!- joesmoe_ [~joesmoe@201.216.206.41] has quit [Ping timeout: 248 seconds] | 17:00 | |
| -!- voxelot [~voxelot@remote.digitalmoneycorp.com] has quit [Ping timeout: 246 seconds] | 17:02 | |
| -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] | 17:03 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds] | 17:04 | |
| -!- stqism [~coup_de_s@freebsd/user/stqism] has quit [Ping timeout: 250 seconds] | 17:05 | |
| -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has quit [Ping timeout: 250 seconds] | 17:06 | |
| -!- coup_de_shitlord [~coup_de_s@irc.toxme.se] has joined #bitcoin-wizards | 17:07 | |
| -!- Church- [~hatter@unaffiliated/church-] has joined #bitcoin-wizards | 17:08 | |
| -!- Dizzle [~Dizzle@104-6-36-162.lightspeed.austtx.sbcglobal.net] has quit [Quit: Leaving...] | 17:08 | |
| -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has joined #bitcoin-wizards | 17:08 | |
| -!- bramc [26632a82@gateway/web/freenode/ip.38.99.42.130] has quit [Ping timeout: 252 seconds] | 17:19 | |
| -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 248 seconds] | 17:20 | |
| -!- belcher [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer] | 17:21 | |
| -!- binaryatrocity [~quassel@unaffiliated/br4n] has quit [Ping timeout: 240 seconds] | 17:22 | |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Max SendQ exceeded] | 17:22 | |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards | 17:23 | |
| -!- Cory [~C@unaffiliated/cory] has joined #bitcoin-wizards | 17:23 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] | 17:29 | |
| -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards | 17:35 | |
| -!- joesmoe [~joesmoe@181.47.58.241] has joined #bitcoin-wizards | 17:42 | |
| -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection] | 17:43 | |
| -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards | 17:50 | |
| -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection] | 17:55 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] | 17:55 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 18:00 | |
| -!- joesmoe [~joesmoe@181.47.58.241] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] | 18:01 | |
| -!- joesmoe [~joesmoe@181.47.58.241] has joined #bitcoin-wizards | 18:02 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 248 seconds] | 18:05 | |
| -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [Read error: Connection reset by peer] | 18:05 | |
| -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards | 18:05 | |
| -!- roconnor [~roconnor@host-45-58-250-196.dyn.295.ca] has joined #bitcoin-wizards | 18:11 | |
| -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving] | 18:17 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 18:20 | |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-azboyycbtwyfpxwn] has quit [Quit: Connection closed for inactivity] | 18:21 | |
| -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards | 18:25 | |
| -!- everyBloc [~everybloc@c-73-158-140-36.hsd1.ca.comcast.net] has quit [Remote host closed the connection] | 18:29 | |
| -!- everyBloc [~everybloc@c-73-158-140-36.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 18:34 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 248 seconds] | 18:37 | |
| -!- joesmoe [~joesmoe@181.47.58.241] has quit [Ping timeout: 260 seconds] | 18:44 | |
| -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Quit: Later.] | 18:45 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] | 18:50 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards | 18:52 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 250 seconds] | 18:53 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 18:54 | |
| -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Read error: Connection reset by peer] | 18:54 | |
| -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards | 18:56 | |
| -!- jgarzik__ [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has quit [Quit: Leaving] | 18:58 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 19:01 | |
| -!- joesmoe [~joesmoe@181.47.58.241] has joined #bitcoin-wizards | 19:04 | |
| -!- voxelot [~voxelot@2605:e000:1525:802f:2f31:fc98:c9b5:8658] has joined #bitcoin-wizards | 19:04 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds] | 19:06 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 19:10 | |
| -!- Netsplit *.net <-> *.split quits: PsychoticBoy, jbenet, c0rw1n, roconnor, jannes, adams__, jtimon, harrow`, amiller, CodeShark, (+9 more, use /NETSPLIT to show all of them) | 19:19 | |
| -!- c0rw1n [~c0rw1n@225.139-67-87.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards | 19:22 | |
| -!- roconnor [~roconnor@host-45-58-250-196.dyn.295.ca] has joined #bitcoin-wizards | 19:25 | |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards | 19:25 | |
| -!- bliljerk101 [~bliljerk1@2601:547:c303:6cd0:d06b:c193:b43c:eaca] has joined #bitcoin-wizards | 19:25 | |
| -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards | 19:25 | |
| -!- bildramer [~bildramer@p5DC8ADCC.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 19:25 | |
| -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-wizards | 19:25 | |
| -!- amiller [~socrates1@unaffiliated/socrates1024] has joined #bitcoin-wizards | 19:25 | |
| -!- Iriez [xbins@distribution.xbins.org] has joined #bitcoin-wizards | 19:25 | |
| -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-wizards | 19:25 | |
| -!- roybadam1 [~roy@darla.gnomon.org.uk] has joined #bitcoin-wizards | 19:25 | |
| -!- harrow` [~harrow@2607:5300:100:200::160d] has joined #bitcoin-wizards | 19:25 | |
| -!- jbenet [sid17552@gateway/web/irccloud.com/x-hzavmlwqrutvpkih] has joined #bitcoin-wizards | 19:25 | |
| -!- PsychoticBoy [sid27029@pdpc/supporter/active/psychoticboy] has joined #bitcoin-wizards | 19:25 | |
| -!- adams__ [sid73416@gateway/web/irccloud.com/x-djxfbkylttuzvfbq] has joined #bitcoin-wizards | 19:25 | |
| -!- CodeShark [sid126576@gateway/web/irccloud.com/x-mryabbrtgwhzoqmj] has joined #bitcoin-wizards | 19:25 | |
| -!- SheffieldCrypto_ [sid28532@gateway/web/irccloud.com/x-yzkltreifrtrmdht] has joined #bitcoin-wizards | 19:25 | |
| -!- Jaamg [jhpiloma@gateway/shell/tkk.fi/x-lbbuxwiwwsnefkrg] has joined #bitcoin-wizards | 19:25 | |
| -!- aem [AEM@gateway/shell/elitebnc/x-twsakuasfqpyfefx] has joined #bitcoin-wizards | 19:25 | |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Max SendQ exceeded] | 19:25 | |
| -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards | 19:26 | |
| -!- markus-k_ [~markus-k@p4FCCC194.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 19:31 | |
| -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton] | 19:32 | |
| -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 19:33 | |
| -!- markus-k [~markus-k@p4FCCC251.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds] | 19:34 | |
| -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Client Quit] | 19:34 | |
| -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 19:36 | |
| -!- hashtag_ [~hashtag@cpe-174-97-254-80.ma.res.rr.com] has quit [Ping timeout: 268 seconds] | 19:37 | |
| bsm1175321 | proslogion: Re: Serenity, one of my big concerns is that they haven't actually solved the problem of sharding the blockchain. Instead they introduced an economic incentive to not-cross-shards, without any technical proposal to organize things in shards. This will cause tremendous breakage as expected gas costs go up because old contracts are (unknowingly) crossing shards. | 19:38 |
| bsm1175321 | Economic incentives are fuzzy and malleable and depend on ambient conditions and are not to be depended on, unless you're blocked by a theorem that forces you to consider it as the only way to achieve consensus. | 19:39 |
| -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] | 19:41 | |
| bsm1175321 | Economic conditions arise that cause assets to have a net negative value if you're holding them, which is why shorting exists, but is counter to the notion that technical problems can be solved by coin-quantity-maximizing miners. Technical solutions are always preferred over economic incentives. | 19:41 |
| -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton] | 19:41 | |
| -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Quit: Leaving] | 19:42 | |
| -!- crossing-styx [~crossing-@c-67-165-86-109.hsd1.pa.comcast.net] has quit [Ping timeout: 244 seconds] | 19:42 | |
| bsm1175321 | I'm not convinced that sharding is a problem that cannot be solved by purely technical means. | 19:42 |
| funkenstein_ | wrong channel bro? :) | 19:48 |
| bsm1175321 | No. funkmeister. Responding to a comment from earlier today. | 19:48 |
| -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 19:49 | |
| -!- jl2012 [uid133844@gateway/web/irccloud.com/x-chbkthvkuisyhwvm] has quit [Quit: Connection closed for inactivity] | 19:51 | |
| -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Read error: Connection reset by peer] | 20:00 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 20:01 | |
| -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-wizards | 20:02 | |
| -!- nuke1989 [~nuke@46-86-125.adsl.cyta.gr] has quit [Remote host closed the connection] | 20:05 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds] | 20:06 | |
| -!- e0 [~e0@c-66-30-116-211.hsd1.ma.comcast.net] has quit [Ping timeout: 248 seconds] | 20:09 | |
| -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton] | 20:14 | |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] | 20:24 | |
| -!- hashtag_ [~hashtag@cpe-174-97-254-80.ma.res.rr.com] has joined #bitcoin-wizards | 20:30 | |
| -!- wizkid057 [wizkid@unaffiliated/wizkid057] has quit [Ping timeout: 248 seconds] | 20:30 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has quit [Ping timeout: 260 seconds] | 20:32 | |
| -!- Church- [~hatter@unaffiliated/church-] has quit [Ping timeout: 240 seconds] | 20:32 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #bitcoin-wizards [] | 20:32 | |
| -!- wizkid057 [wizkid@unaffiliated/wizkid057] has joined #bitcoin-wizards | 20:35 | |
| -!- everyBlo_ [~everybloc@c-73-158-140-36.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 20:39 | |
| -!- everyBloc [~everybloc@c-73-158-140-36.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer] | 20:39 | |
| bsm1175321 | Taek: Just did some calculations: the minimum theoretically allowed bead time using a braid is 61ms. With a blockchain it is 200ms. (Both are due to the geometry of the Earth and speed of light). This is *far* too slow to have individually mined transactions. Details to follow... | 20:45 |
| bsm1175321 | Or another way to look at it: the braid structure buys more than a factor of 3 in increasing the speed of blockchains. | 20:45 |
| funkenstein_ | :o this i want to see | 20:46 |
| * bsm1175321 whips it out for funkenstein_ | 20:46 | |
| funkenstein_ | lol | 20:47 |
| -!- Church- [~hatter@unaffiliated/church-] has joined #bitcoin-wizards | 20:48 | |
| -!- iLearn [~ilearn@h-219-171.a240.priv.bahnhof.se] has joined #bitcoin-wizards | 20:48 | |
| bsm1175321 | One can push these average numbers down, at the cost of higher variance in the block/cohort time. | 20:48 |
| bsm1175321 | Taek: the problem is that if everyone on the surface of the earth is quickly transmitting transactions, there is no definable "checkpoint" which everyone can agree on a consistent ledger state. Each participant sees local transactions faster. In terms of the propagation time across the network, imagine each node is emitting transactions at 1000 per propagation time. The system would never converge. Cohort size | 20:51 |
| bsm1175321 | Here the logical analog of a "block" is "every participant sees the exact same ledger state". | 20:52 |
| funkenstein_ | consensus is always probabilistic | 20:52 |
| funkenstein_ | i see where you're coming from though, its helpful to have a limit | 20:54 |
| bsm1175321 | funkenstein_: no, it's not. | 20:54 |
| funkenstein_ | there's a chance of reorg which reduces exponentially with depth | 20:55 |
| bsm1175321 | This system has no possibility for reorgs. | 20:55 |
| funkenstein_ | all measurement is also probabilistic | 20:55 |
| -!- mrkent [~textual@unaffiliated/mrkent] has quit [] | 20:55 | |
| -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-wizards | 20:55 | |
| funkenstein_ | no reorgs? if i see one side of a double spend first, somebody else sees the other... one of us has to give | 20:57 |
| bsm1175321 | Well, let's put it this way: I'm assuming mining is equally distributed around the globe, and assuming a network which is has the same fairness/performance for all participants, in the above numbers. If you're willing to centralize mining and live close to it, you can get faster. But two mining centers on opposite sides of the globe will always decide on the side with more hashpower. | 20:57 |
| bsm1175321 | funkenstein_: reorgs today are caused almost entirely by the non-synchronicity of the network, and miners producing blocks at nearly the same time, not double-spends. My braiding work is intended to address that. Double-spends still revert to most-work-wins. | 20:59 |
| -!- mrkent [~textual@unaffiliated/mrkent] has quit [Ping timeout: 248 seconds] | 21:00 | |
| funkenstein_ | is there an implementation in the works? or other paper than your scalingbitcoin presentation? | 21:00 |
| bsm1175321 | Once I figure out all my shit...yes. It's hard to implement things you haven't figured out. ;-) | 21:01 |
| bsm1175321 | There is a paper that I've been distracted from finishing. Soon... | 21:01 |
| funkenstein_ | interesting stuff, looking forward to it :) | 21:02 |
| -!- iLearn [~ilearn@h-219-171.a240.priv.bahnhof.se] has quit [Remote host closed the connection] | 21:02 | |
| bsm1175321 | FWIW, some python code for generating braids, evaluating rewards, and plotting will be published alongside the paper. | 21:03 |
| bsm1175321 | The algorithms all rely on graph_tool which is based on the Boost Graph Library, so are straightforwardly importable into Bitcoin. | 21:05 |
| funkenstein_ | i see this as being more interesting towards decentralizing other types of database | 21:08 |
| bsm1175321 | Possibly. | 21:08 |
| bsm1175321 | What's your interest? | 21:08 |
| -!- iLearn [~ilearn@h-219-171.a240.priv.bahnhof.se] has joined #bitcoin-wizards | 21:09 | |
| funkenstein_ | something like a repository | 21:09 |
| funkenstein_ | git repo | 21:09 |
| bsm1175321 | funkenstein_: FWIW the structure deeply relies on the ability to determine that two transactions are not *conflicting*. In the context of Bitcoin this means double-spends (usually) but in the context of Ethereum it also means data dependency. In other words, transactions must commute. Or git commits must be reorderable without conflicts. | 21:10 |
| bsm1175321 | Depending on the complexity of your system, just determining that two transactions are reorderable can be extremely complex. I'm seriously worried that my work will be useless for Ethereum due to data dependencies. | 21:11 |
| funkenstein_ | right, but i guess your main point here is that sometimes different sets of transactions don't conflict | 21:11 |
| bsm1175321 | Exactly. For Bitcoin it's easy: the don't spend the same UTXO's. But for Ethereum, they have to leave the entire state the same if you reorder them. This can be very hard to determine. | 21:12 |
| bsm1175321 | Now in Ethereum if you ask for a pairwise commutator it's pretty easy, but now ask for pairwise commutators for all 1000 transactions in a block, and ask whether *any* reordering is possible? This is an exponentially complex problem. | 21:14 |
| bsm1175321 | Oddly, in the end, I think I can make Bitcoin faster than Ethereum because of this! | 21:14 |
| bsm1175321 | (or a bitcoin-like-coin without the Ethereum state machine) | 21:15 |
| funkenstein_ | that's better ;) | 21:15 |
| -!- mol11111 [~molly@unaffiliated/molly] has joined #bitcoin-wizards | 21:18 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards | 21:19 | |
| -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds] | 21:21 | |
| -!- MoALTz_ [~no@78-11-183-124.static.ip.netia.com.pl] has joined #bitcoin-wizards | 21:21 | |
| -!- MoALTz [~no@78-11-183-124.static.ip.netia.com.pl] has quit [Ping timeout: 244 seconds] | 21:25 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 21:33 | |
| -!- kisspunch [~za3k@71.19.156.60] has quit [Ping timeout: 276 seconds] | 21:35 | |
| bsm1175321 | By restricting Bitcoin scripts to be context free (they can't refer to blockchain state), Satoshi avoided this problem (but also delayed payment channels and Lightning by many years). | 21:36 |
| -!- everyBlo_ [~everybloc@c-73-158-140-36.hsd1.ca.comcast.net] has quit [Remote host closed the connection] | 21:40 | |
| -!- iLearn [~ilearn@h-219-171.a240.priv.bahnhof.se] has quit [Remote host closed the connection] | 21:46 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 21:53 | |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 22:03 | |
| Taek | the network would converge just fine, as long as everyone had enough bandwidth to see transactions as fast as they were appearing | 22:08 |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 248 seconds] | 22:08 | |
| Taek | meaning, if 1000 transactions are appearing per propagation period, but you can download 1200 per propagation period, you will be eventually convergent | 22:08 |
| Taek | your instant state will always be different from people in a different locality, but as far as anything with multiple propagation periods of confirmations go, you're fine | 22:09 |
| bsm1175321 | Define "convergent". In such a scenario, no two particpants ever see the same UTXO state. | 22:09 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 22:09 | |
| bsm1175321 | (this is not necessarily incompatible with consensus, mind you -- I just don't see how it works, right now) | 22:09 |
| Taek | it means that after a certain period of time they will be in agreement about whether a specific transaction appears in the full set | 22:10 |
| Taek | they may not have an identical UTXO set at any particular point, but they will have an identical interpretation for a certain output, provided no new transactions for that output have been produced recently | 22:10 |
| Taek | this is completely fine | 22:10 |
| bsm1175321 | So in such a scenario, there is no "checkpoint" in which UTXO sets can be compared. So how do I define "in agreement"? | 22:10 |
| Taek | you have an exact ordering for transactions | 22:10 |
| bsm1175321 | They would only be in agreement if new tx's stopped for a time period roughly the size of the propagation time across the network. | 22:11 |
| bsm1175321 | A braid does *not* have an exact ordering. You and I would disagree on the ordering. | 22:11 |
| Taek | it's the same thing with blocks though, you don't have any guarantee that the whole world has the same utxo set | 22:11 |
| bsm1175321 | (based on first-seen) | 22:11 |
| -!- joesmoe [~joesmoe@181.47.58.241] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] | 22:11 | |
| Taek | you can't know if someone else has seen a block that hasn't propagated to you yet | 22:12 |
| Taek | but you can know that a given transaction has 6 confirmations | 22:12 |
| Taek | in txn-POW, 6 confirmations would not be enough (because you might be doing 100 or 1000 txn per propagation period). You might want 10,000 confirmations before being certain | 22:12 |
| bsm1175321 | Ok so let me take your argument. Let's assume you and I have different UTXO sets because we've seen different sets of transactions, and the tx's happen so rapidly that you and I cannot clearly define a comparison point. How do we know that we have "consensus"? | 22:13 |
| Taek | we have consensus on older transactions | 22:13 |
| Taek | we don't need to be in perfect consensus about new stuff, we treat it as unconfirmed | 22:13 |
| bsm1175321 | So "older" defines a comparison point. | 22:13 |
| Taek | more or less | 22:13 |
| bsm1175321 | How do you define that comparison point? | 22:13 |
| Taek | so | 22:14 |
| Taek | I don't think there's any need to define an exact comparison point. I don't think there's utility in doing so | 22:14 |
| Taek | but, if you really want one, there's a fairly simple way to do it | 22:14 |
| bsm1175321 | I'm using "cohorts" which I've defined a few times, but ask if it's not clear. | 22:14 |
| Taek | For the time being I'm describing the system I designed, which has no sense of cohorts, given a set of transactions that point to eachother you can always arrive at an exact ordering | 22:14 |
| bsm1175321 | There is absolutely a need to define an exact comparison point. Or otherwise a different comparison mechanism. (what is it?) | 22:15 |
| bsm1175321 | I'm defining "consensus" as "agreement on UTXO set". If you want to define consensus in a different way, that's fine, but what is it? | 22:15 |
| Taek | in Bitcoin, there arrives a point in time where you've achieved certainty that a transaction will not be reorg'd out of the chain | 22:15 |
| Taek | often this is 6 known confirmations, but in some scenarios you may only need 2 or (like during the SPV mining incident) you may want 100+ confirmations | 22:16 |
| -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [Ping timeout: 260 seconds] | 22:16 | |
| -!- kisspunch [~za3k@za3k.com] has joined #bitcoin-wizards | 22:16 | |
| Taek | not everyone is going to arrive at 6 confirmations at the exact same point in time, because blocks take time to propagate | 22:16 |
| bsm1175321 | So, a "confirmation" is a total ordering. DAGs and braids are only partial ordered. A cohort defines a total ordering, and regardless of your assumptions, cohorts will exist, and still define a total order. | 22:16 |
| Taek | the graphs I described had an exact ordering, because they were not based on first-seen, they were based on total amount of work that they point to | 22:17 |
| bsm1175321 | In the presence of partial ordering (only) one needs a new notion of "confirmation". | 22:17 |
| Taek | and in the event of a tie, a deterministic random process was used to break the tie | 22:17 |
| Taek | the graphs I described do not have partial ordering, they have exact ordering! | 22:18 |
| bsm1175321 | BTW have you read the Iota whitepaper? They use a scoring which does something similar. | 22:18 |
| bsm1175321 | Ok, I see. | 22:18 |
| bsm1175321 | So what do you do with "siblings" as I define them? -- You use the mined work (not the target work)? | 22:19 |
| -!- phiche [~Adium@2.69.70.202.mobile.tre.se] has joined #bitcoin-wizards | 22:21 | |
| Taek | the target is defined by what parents you point to, and the amount of 'weight' added to the chain is defined by the target | 22:21 |
| bsm1175321 | Argh, here's the problem...as the tx rate increases, you have siblings of siblings of siblings. In order to order them, you have to have a starting point, and a subset you're going to order (a cohort). If the transaction rate is too high, the only starting point is the genesis block. If the tx rate is too high, you will *never* generate a cohort, and never be able to define a subset with a clear start and end p | 22:22 |
| -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards | 22:22 | |
| Taek | 'too high' would need to be higher than the amount of bandwidth available to the miner | 22:23 |
| Taek | but that's the whole reason we have a difficulty in the first place - it's a ratelimit | 22:23 |
| Taek | as long as you pick a sane ratelimit for the speed of transactions, you'll converge | 22:24 |
| bsm1175321 | It's not bandwidth, it's causality. If tx's are generated much faster than the propagation time across the network, you will never be able to decide a subset to total order. | 22:24 |
| Taek | that's not correct | 22:24 |
| Taek | so | 22:24 |
| Taek | transactions will always point to a finite number of parents | 22:24 |
| bsm1175321 | I agree with your previous statements up to "that's not correct". ;-) | 22:24 |
| Taek | and from those parents you can build a coherent exact ordering | 22:25 |
| Taek | so what happens is you end up with a bunch of different exact orderings from transaction chains that haven't seen eachother | 22:25 |
| Taek | oh | 22:25 |
| Taek | 'chaintips' is the word I've been using for it | 22:25 |
| Taek | so you might have any number of chaintips with ~equal work | 22:25 |
| bsm1175321 | I'm assuming (per your slides) tx = chaintips. | 22:26 |
| Taek | (or even exactly equal work, depending on how the difficulty is managed) | 22:26 |
| bsm1175321 | or tx per block/bead... | 22:26 |
| Taek | a chaintip is a txn for which there is no known child | 22:26 |
| bsm1175321 | agreed | 22:26 |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 22:26 | |
| Taek | so lets assume a system where the throughput is higher than the propagation speed, and therefore you always have ~10 chaintips | 22:27 |
| bsm1175321 | So you order possible parents. What happens when you're 18 levels deep in ordering parents? I argue a total order doesn't exist. | 22:27 |
| Taek | and by the time people have seen and merged those 10 chaintips, you have 10 new chaintips | 22:27 |
| bsm1175321 | fuck now I have to prove that... | 22:27 |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 22:28 | |
| Taek | no, you only pay attention to the longest chaintip you know of | 22:28 |
| Taek | just like in bitcoin | 22:28 |
| -!- zooko [~user@c-50-131-214-60.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 22:28 | |
| bsm1175321 | So...how do you relate the parents of your parent, to the parents you are choosing? | 22:28 |
| Taek | in Bitcoin, you only pay attention to the longest chain | 22:28 |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 22:28 | |
| Taek | oh | 22:28 |
| bsm1175321 | And how do you compare the merging of two sibling chains? | 22:28 |
| Taek | are you asking about how you arrive at an exact ordering? | 22:29 |
| bsm1175321 | yes | 22:29 |
| Taek | ok, this is described better in the slides | 22:29 |
| Taek | but | 22:29 |
| bsm1175321 | In graph theory it's called "total order" | 22:29 |
| Taek | noted | 22:29 |
| bsm1175321 | a > b vs. a >= b. | 22:29 |
| bsm1175321 | total vs. partial. | 22:29 |
| Taek | ah | 22:29 |
| Taek | okay, I will use that terminology going forward | 22:29 |
| -!- CrazyTruthYakDDS [uid67551@gateway/web/irccloud.com/x-wlfsidzkcejhihia] has quit [Quit: Connection closed for inactivity] | 22:30 | |
| Taek | so, each node has a collection of nodes in the DAG that it points to | 22:30 |
| Taek | I don't know what to call them, so temporarily I'll just say 'P' | 22:30 |
| bsm1175321 | parents, sure. | 22:31 |
| bsm1175321 | I find the geneaological analogies very useful in this... | 22:31 |
| Taek | I mean that it includes grand parent, great-grand-parents, etc. | 22:31 |
| bsm1175321 | ancestors | 22:31 |
| Taek | oh. huh we have I word for that after all | 22:31 |
| Taek | lol | 22:31 |
| Taek | ok | 22:31 |
| bsm1175321 | ;-) | 22:32 |
| moa | forbears | 22:32 |
| bsm1175321 | ancestors/descendants for all generations, parents/children for one generation. It's a useful analogy ;-) | 22:32 |
| Taek | so, if you are pointing to multiple parents, there is a rule that none of the parents can be ancestors to eachother | 22:32 |
| Taek | A <- B <- C ===> C is not allowed to point to both B and A, because B already includes A | 22:33 |
| bsm1175321 | Yeah. I tried to convince the Iota people of that without success. If you're using scoring of some kind, that rule *may* not be useful... but then I have to examine your scoring. | 22:33 |
| bsm1175321 | Anyway, agreed and understood. | 22:33 |
| Taek | so, you score things by counting the total amount of work in a node's ancestors (including the node itself) | 22:33 |
| Taek | then, when picking an ordering, you prefer the ancestor that has more total work | 22:34 |
| Taek | in the event of an exact tie, you use your own id (the POW hash) to randomly select a winner | 22:34 |
| bsm1175321 | Ok so the first conflict there is siblings, which are by definition an exact tie. | 22:34 |
| bsm1175321 | They're a depth-1 tie. | 22:34 |
| bsm1175321 | Ok, you can use the PoW hash like that... | 22:35 |
| bsm1175321 | Though I mentioned something similar in this channel a long time ago, and there was frothing at the mouth...I don't remember why... | 22:35 |
| -!- phiche [~Adium@2.69.70.202.mobile.tre.se] has quit [Read error: Connection reset by peer] | 22:36 | |
| bsm1175321 | IOW do you use the target difficulty, or the actual hash value to decide total collective work? | 22:36 |
| Taek | A <- B | A <- C | B <- D | C <- D ===> A has value 1, B & C have value 2, D has value 4. D randomly selects between B and C for which comes first, then you end up with a total ordering that is deterministically either A < B < C < D or A < C < B < D | 22:37 |
| Taek | (but it's deterministic) | 22:37 |
| Taek | ok, now we will add the final rule, which is the tricky part but I think what will sove your N-tie problem | 22:37 |
| bsm1175321 | In order to get (statistically) deterministic orderings, you need to use the hash value instead of the target difficulty. (which is the idea that caused frothing at the mouth...memory...jogging...) | 22:38 |
| Taek | let's add 2 new nodes: A <- E | E <- F | D <- F | 22:38 |
| Taek | (you need to use the target difficulty otherwise you open yourself to various forms of intelligent withholding attacks. Someone who unintentionally gets a very lucky number can withhold it and cause a huge reorg) | 22:39 |
| Taek | F is conirming 2 chaintips, E & D | 22:39 |
| bsm1175321 | Using the target difficulty means that siblings (diamond graphs) are undecidable for a total ordering. | 22:39 |
| Taek | A is a common ancestor in both, so it comes before anything that follows | 22:39 |
| Taek | (no you use the hash as a random variable that selects an ordering - it's not the same as favoring the hash value. The random number that's generated is separate, and therefore can't be abused) | 22:40 |
| Taek | Then D has more work, so all ancestors to D are next | 22:40 |
| Taek | then E, and finally F | 22:40 |
| bsm1175321 | Any hash value can be abused by grinding. | 22:41 |
| Taek | the total ordering is therefore A < B < C < D < E < F | 22:41 |
| bsm1175321 | So let me distill everything you're saying... | 22:41 |
| Taek | bsm1175321: that is true, except in this case you'd need to do enough grinding to find the target at least one more time, which takes the same amount of working as just adding another confirmation, which would achieve the same thing | 22:41 |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 248 seconds] | 22:42 | |
| bsm1175321 | You're arguing there's a way to define a total ordering on a DAG/braid, in a way that can't be gamed. No? | 22:42 |
| Taek | yes, I'm arguing that | 22:43 |
| bsm1175321 | Ok. | 22:44 |
| -!- funkenstein_ [~bowler@unaffiliated/funkenstein] has quit [Quit: Leaving] | 22:44 | |
| Taek | if you take a 4 node diamond, a bc d, you can use min(H(d || b), H(d || c)) to pick an exact ordering in a way that can't be gamed | 22:44 |
| bsm1175321 | So, I think one can still reorder beads within a cohort. | 22:45 |
| Taek | gaming would require finding an alternate value for 'd', which would require completely redoing the POW | 22:45 |
| bsm1175321 | So a cohort is an absolute, irrefutable total ordering on a DAG. | 22:46 |
| bsm1175321 | Everything you're saying is *within* a cohort. | 22:46 |
| Taek | (is the HK presentation the most recent public version of your work?) | 22:46 |
| bsm1175321 | So your argument is then that one can't gain an advantage by reordering within a cohort. | 22:46 |
| Taek | well, I'm aruging that reording within a cohort would take at least as much work as just adding more nodes | 22:47 |
| bsm1175321 | which I think means that a vendor/adversary should wait until the end of the cohort, and no possible DAG reordering is possible, no? | 22:47 |
| bsm1175321 | yes sadly I haven't published anything since HK, been busy. :-/ | 22:47 |
| Taek | can you redefine cohort? | 22:48 |
| Taek | I'm not 100% clear on the definition | 22:48 |
| bsm1175321 | It's pretty easy to add DAG nodes by withholding beads. | 22:48 |
| Taek | right, but I don't think there's any advantage you gain by withholding beads | 22:49 |
| bsm1175321 | \item[cohort] The union of $b$ with all its siblings and its siblings | 22:49 |
| bsm1175321 | siblings, recursively; the largest set of beads such that no bead in the | 22:49 |
| bsm1175321 | set is an ancestor or descendant of every other bead in the set. | 22:49 |
| Taek | *in my design, where each transaction is a bead with an acceptable POW | 22:49 |
| bsm1175321 | where $b$ is any bead (or txn in your case) | 22:49 |
| Taek | ok, so in my system, you might actually have infinite sized cohorts | 22:50 |
| bsm1175321 | semicolon separates equivalent definitinos. | 22:50 |
| bsm1175321 | yes. | 22:50 |
| Taek | but this is not an issue | 22:50 |
| bsm1175321 | And, I worry, an inability to define a total ordering. | 22:50 |
| bsm1175321 | If you use target difficulty as total ordering, it's definitely true, at high enough txn rate, you will always have siblings at equal depth/difficulty/block height, and cannot perform a total order. | 22:51 |
| bsm1175321 | Taek: which, I realized an hour or so ago, means there is a maximum bead rate, and you can use this to define a target difficulty in such a way as to maximize the (bead) throughput of the network. | 22:53 |
| bsm1175321 | But, I would love to hear an idea about consensus in the absence of cohorts! | 22:56 |
| -!- jaekwon [~jaekwon@2601:645:c001:263a:f080:eb43:8153:3b71] has joined #bitcoin-wizards | 22:56 | |
| Taek | there is a maximum bead rate in my system too, though I think that it's approximately the bandwidth of whatever node is listening. If your bandwidth is below that, you can't be sure you've got the longest chain because you can't see everything that's being built | 22:57 |
| Taek | but, it should be independent of latency. Higher latency means you need more confirmations before being certain that something is confirmed | 22:57 |
| -!- iLearn [~ilearn@h-219-171.a240.priv.bahnhof.se] has joined #bitcoin-wizards | 22:57 | |
| Taek | the key in my system is that you can take any set of nodes and built a total ordering | 22:58 |
| bsm1175321 | Don't forget about the geometry of the Earth. | 22:58 |
| Taek | *build | 22:58 |
| bsm1175321 | That defines being able to "see everything". | 22:58 |
| Taek | well, you need to have all the ancestors of every bead you are considering | 22:59 |
| bsm1175321 | And really I'm using "geometry of Earth" as a poor man's proxy for "topology of the network" | 22:59 |
| Taek | but your universe does not need to match anyone else's universe, and indeed the assumption is that it does not | 22:59 |
| Taek | the assumption is only that at some point you will see every node that they currently see | 22:59 |
| Taek | and you may have new nodes that they don't see at that point, but that's okay | 22:59 |
| Taek | things with enough confirmations (several propagation periods of confirmations) can be safely assumed to be in every set | 23:00 |
| -!- jaekwon [~jaekwon@2601:645:c001:263a:f080:eb43:8153:3b71] has quit [Ping timeout: 240 seconds] | 23:00 | |
| Taek | Just like in Bitcoin | 23:00 |
| Taek | hmm. I think I haven't broken it down all the way, but I'm not sure how to break it down further | 23:01 |
| Taek | I think of it like a zipper | 23:01 |
| Taek | *an infinite zipper | 23:01 |
| Taek | there are prongs in front of you that aren't confirmed yet, there's the zipper of consensus, and there's a weave of prongs behind the zipper that have confirmations | 23:01 |
| Taek | there's always stuff that's not fully woven, but there's also definitely stuff behind the zipper that would take great effort to unweave | 23:02 |
| bsm1175321 | So what I realized today: increasing difficulty (obviously) increases the cohort time, and your graph approximates a blockchain. But also *decreasing* cohort time also *increases* the cohort time because of the siblings-of-siblings effect. | 23:02 |
| Taek | I haven't written proof for it, and I'm only 90% sure it's true, but I believe that in my graph, in order to reorg a total ordering that has 10 confirmations, you would need to merge a chaintip that's got at least 10 nodes in it | 23:02 |
| Taek | *10 new nodes | 23:03 |
| bsm1175321 | eh. English. But also *decreasing* cohort /difficulty/ also *increases* the cohort time because of the siblings-of-siblings effect. | 23:03 |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 23:04 | |
| bsm1175321 | In other words, there's a local minima. ;-) And, a maximum network speed, that fundamentally comes from the network topology. | 23:04 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 244 seconds] | 23:04 | |
| Taek | if you need finite cohors, which in my design is not required | 23:04 |
| bsm1175321 | (given my definitions of total ordering in terms of cohorts) | 23:04 |
| bsm1175321 | Agreed. | 23:05 |
| -!- everyBloc [~everybloc@c-73-158-140-36.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 23:05 | |
| -!- everyBloc [~everybloc@c-73-158-140-36.hsd1.ca.comcast.net] has quit [Remote host closed the connection] | 23:05 | |
| Taek | in my design, if you've got on average unmerged chaintips of depth 10, then 10 confirmations would be equivalent to 1 propagation period of confirmatoins. You'd want to wait several, but a node with 50 or 500 confirmations is unlikely to be reorg'd away because in 1 propagation period a single chaintip only ever gets ahead by about 10 | 23:06 |
| bsm1175321 | So, let's assume a miner both mines and grinds to get his txn reordered with respect to your decided total ordering. | 23:06 |
| Taek | ok | 23:06 |
| bsm1175321 | We have to dump the notion of "confirmations" absent a total ordering. | 23:06 |
| -!- CrazyTruthYakDDS [uid67551@gateway/web/irccloud.com/x-wcgnxrgilnawjkfw] has joined #bitcoin-wizards | 23:06 | |
| Taek | but we do have a total ordering | 23:07 |
| bsm1175321 | Yes. | 23:07 |
| -!- iLearn [~ilearn@h-219-171.a240.priv.bahnhof.se] has quit [] | 23:07 | |
| bsm1175321 | So everyone is using the same target, no? | 23:07 |
| Taek | so, I'm going to simplify things a lot, we're going to assume that all txns have the same target | 23:07 |
| bsm1175321 | Let's say I make two txn's which are double-spends, with the same parent(s). | 23:07 |
| bsm1175321 | Ok good. | 23:08 |
| bsm1175321 | Now, I release the first one to be successfully mined, and continue to mine the second one until it satisfies your second condition which would total order it before the first. | 23:08 |
| -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 244 seconds] | 23:08 | |
| Taek | ok. So you first release A <- B, then you grind on 'C' until you get a result A < C < B | 23:09 |
| bsm1175321 | Yes. | 23:09 |
| Taek | so, minimally, you need to do 1 work to achieve that. After 1 work, you have 50% chance of success. After 2 works, 66% chance of success, 3:75%, ect | 23:10 |
| bsm1175321 | But you don't have cohorts. So there's no limit as to how long I can grind the second txn to achieve a favorable result. | 23:11 |
| Taek | oh, not fully accurate | 23:11 |
| -!- everyBloc [~everybloc@c-73-158-140-36.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 23:11 | |
| Taek | my probabilities are too low, but it's late and I don't want to derive the exact values | 23:11 |
| bsm1175321 | mmm ignoring %, I get your point | 23:11 |
| Taek | right, so I'm going to assume that you've got less than 50% hashrate | 23:12 |
| bsm1175321 | Yes. | 23:12 |
| Taek | After you release A <- B, everyone else is mining on top of B | 23:12 |
| bsm1175321 | That's fine though, since A<C and time is not measured. | 23:12 |
| Taek | well, by the time you find 'C', there likely already exists another node | 23:13 |
| bsm1175321 | Certainly. Now you've inserted time measurement into the system...which is something Bitcoin doesn't do... | 23:13 |
| Taek | so now you've got two chaintips, one that's A < B < D and one that's A < C < B | 23:13 |
| bsm1175321 | Damn laggy networks. | 23:14 |
| Taek | there's no sense of time here that Bitcoin doesn't have | 23:14 |
| Taek | Bitcoin nodes will prefer the chain they see first in the event of 2 competing chains at the same depth | 23:14 |
| Taek | we do the same | 23:14 |
| bsm1175321 | That's not true. Bitcoin prefers the chain with more work, using the hash value. | 23:15 |
| * Taek requests backup. | 23:15 | |
| Taek | :p | 23:15 |
| * bsm1175321 googles | 23:15 | |
| Taek | bitcoin nodes prefer the chain they see first, I'm 98% confident about this | 23:16 |
| bsm1175321 | As a -wizards conversation, I'm malleable on this point in any case. | 23:16 |
| Taek | ok | 23:17 |
| gwillen | Bitcoin prefers the chain it sees first, given the same work, but it always prefers more work | 23:18 |
| gwillen | so I think you're both correct because by 'depth' Taek probably meant 'work' | 23:18 |
| gwillen | (in non-pathological cases they'll be the same since every block mined at the same depth should have the same work) | 23:18 |
| bsm1175321 | gwillen: "same work" is a statistical impossibility unless we're talking about the actual hash value. | 23:18 |
| gwillen | same target | 23:19 |
| gwillen | a hash further below the target doesn't count more | 23:19 |
| gwillen | but blocks count for work based on their target | 23:19 |
| -!- voxelot [~voxelot@2605:e000:1525:802f:2f31:fc98:c9b5:8658] has quit [Ping timeout: 268 seconds] | 23:19 | |
| gwillen | which is what prevents someone mining a parallel chain starting at genesis with only 1 work in each block, to the same depth as the real chain, and winning | 23:20 |
| gwillen | but as long as someone doesn't mine a fork long enough to cause a retarget down to a lower difficulty... 'depth' and 'work' are the same because legitimate blocks at the same depth are going to have the same target | 23:21 |
| bsm1175321 | Taek: So I'm with gwillen on this, if you use the actual hash value, or some other grindable value, a total order is grindable (decidable) by the transaction writer. | 23:21 |
| gwillen | I'm trying to make sure I understand what 'total order' is being used to mean here before I comment | 23:22 |
| bsm1175321 | gwillen: so it's only between retargets that actual hash value is taken into account? | 23:22 |
| Taek | to satisfy the POW, the hash value has to be below some target, grinding on the hash value is as expensive as just adding more nodes | 23:22 |
| gwillen | but I do agree with what you're saying, bsm1175321, if 'total order' means what you're interpreting it to mean | 23:22 |
| gwillen | or what I think you are :-) | 23:22 |
| bsm1175321 | gwillen: "total" order is implicit in bitcoin/any blockchain... it's the block height. | 23:22 |
| gwillen | bsm1175321: the actual hash value is never taken into account -- retargets change the target hash value based on the average time to find a block using a preset formula, and work that counts for the chain is always based on the target hash value (the difficulty value) | 23:23 |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.] | 23:23 | |
| gwillen | any 'extra' amount that the actual hash is below the target hash is "wasted" | 23:23 |
| bsm1175321 | Taek: so per gwillen's response, your algorithm has many equal-ordered siblings, unless you wish to insert another tie-breaker, which can be ground, possibly. | 23:24 |
| bsm1175321 | (and I agree, it's easy to make this cost as much as the original mined block) | 23:25 |
| Taek | you can already reorg txns by doing work | 23:25 |
| Taek | but yes, if you have enough work, you can reorg txns | 23:26 |
| bsm1175321 | gwillen: mining is really first-seen? So it's easy to attack a mining pool by delaying their network? | 23:26 |
| Taek | I forget what point I was trying to make, what direction are we going? | 23:26 |
| gwillen | hmm, I feel like at one point I was convinced that a grindable tie-breaker was a bad idea for obvious reasons that are worse than just "you can reorg by doing work", but I can't come up with them right now | 23:26 |
| gwillen | bsm1175321: if you delay a mining pool's network, they will lose money, yeah | 23:26 |
| bsm1175321 | Taek: hahaaa we were talking whether total ordering with your scheme was doable. | 23:27 |
| gwillen | it will increase their orphan rate, which is the rate at which their successful blocks are ignored by the network because someone else got there first | 23:27 |
| Taek | oh, I think we have had a slightly different definition of total ordering | 23:27 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 23:27 | |
| bsm1175321 | You can easily achieve total ordering by network synchronicity (a la Bitcoin) or cohorts in braids. I'm yet to be convinced of another idea. ;-) | 23:28 |
| Taek | (one of the big advantages to the txn-POW scheme I've described is that miners on slower networks have a much smaller disadvantage. They are still disadvantaged, but the effect is probably an order of magnitude less) | 23:28 |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 23:28 | |
| bsm1175321 | Heh. I want to dis-incentivize the slow bastards off the network. I have no interest in a slow network. | 23:29 |
| Taek | bsm1175321: my graph scheme can achieve a total ordering from any set of nodes that you give it, and the ordering can only be changed by doing work. The amount of work required to change the ordering is minimally equal to the amount of work on top of whatever txn you are trying ot reorder | 23:29 |
| bsm1175321 | gwillen: the definition I'm using has no orphans, because rewards are decided later. | 23:30 |
| Taek | bsm1175321: requiring a fast network connection is a centralization pressure | 23:30 |
| bsm1175321 | Taek: I have no doubt that a total ordering can be achieved in the way you describe. I doubt that it can't be gamed. | 23:30 |
| -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards | 23:31 | |
| bsm1175321 | Taek: requiring a fast network is an anti-chinese-communisim-censorship measure. | 23:31 |
| bsm1175321 | I see no reason to enable censorship, or slow networks, in my financial system. | 23:32 |
| -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.] | 23:32 | |
| Taek | uh | 23:33 |
| bsm1175321 | Anyhoo...convince me you can achieve a total ordering... | 23:33 |
| Taek | I don't want to get into that now, maybe someone else can take that one later. Let it be known publically though that I actively think that decentralized mining requires slow connections to be nearly as equally profitable as fast connections. | 23:34 |
| Taek | bsm1175321: you are asking me to convince you that I have achieved a total ordering which can't be gamed | 23:34 |
| Taek | so I will provide a definition of 'gamed' | 23:34 |
| bsm1175321 | The system is as fast as its slowest connection. I desire fast finance... | 23:34 |
| Taek | and I desire decentralized finance :) | 23:35 |
| Taek | there's a direct tradeoff there | 23:35 |
| bsm1175321 | Decentralization behind the great firewall is not decentralization. | 23:35 |
| Taek | someone has to decide the speed limit of the network | 23:35 |
| Taek | and that speed limit decides who can participate | 23:35 |
| Taek | urg back to total ordering | 23:35 |
| bsm1175321 | Yeah. More interesting. | 23:36 |
| Taek | ok, so my assertion is that a txn with X confirmations (where every decendent counts as a confirmation) cannot be reordered unless a chaintip is merged with at least X previously unmerged txns | 23:37 |
| bsm1175321 | Taek: FWIW the 'total order' I define is due to causality...it's impossible for someone on one side of the Earth to know the block/bead a person on the other side of the Earth is constructing. | 23:37 |
| bsm1175321 | Bitcoin's "total order" is due to synchronicity: everyone must have seen everything. | 23:38 |
| bsm1175321 | Taek: Ok so I create a txn with a parent before your txn and release it after your txn has been "confirmed", what happens? | 23:39 |
| Taek | Bitcoin can have 2 nodes that have seen everything yet have different total orders: the case where the two most recent blocks are buidling of a common parent, and some set of nodes saw 1 block first and the other set of nodes saw the other block first | 23:39 |
| Taek | those nodes will remain inconsistent about which block is the 'real' block until one of the blocks gets more confirmations | 23:40 |
| Taek | bsm1175321: I'm not 100% sure what graph setup you are describing? | 23:41 |
| bsm1175321 | Taek: "confirmations" is a total-ordering concept. Can you redefine it in a partial-ordered world? What happens when two txns have the same number of confirmations? | 23:41 |
| -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] | 23:41 | |
| Taek | you mean two conflicting txns? | 23:41 |
| bsm1175321 | no. | 23:41 |
| bsm1175321 | mmmm maybe. | 23:41 |
| bsm1175321 | Ok, yes. | 23:42 |
| bsm1175321 | I've totally just discredited myself. | 23:42 |
| Taek | lol | 23:43 |
| Taek | so, if we're requiring a large number of confirmations, two conflicting transactions are unlikely to each get to that large number of confirmations because their respective chaintips will be diverging | 23:44 |
| Taek | one will get ahead of the other, and that chaintip will win the race | 23:44 |
| bsm1175321 | Ok, define confirmations? | 23:44 |
| Taek | every descendant is a confirmation. So in the (a bc d) diamond, 'a' has 4 confirmations (abcd) | 23:45 |
| Taek | b and c each have 2 confirmations, and d has 1 confirmation | 23:45 |
| bsm1175321 | The diamond, by assumption, has no conflicts. | 23:45 |
| Taek | right | 23:45 |
| bsm1175321 | Here we're talking about double-spends, no? | 23:45 |
| Taek | ok | 23:46 |
| Taek | so in the case of (a bc) 'a' actually only has 2 confirmations | 23:46 |
| Taek | itself and one of 'b' or 'c', because 'b' and 'c' have not been merged | 23:46 |
| Taek | and therefore the node will only be considering one of the worldviews (a b) or (a c) | 23:47 |
| bsm1175321 | So double spends define a fork. The UTXO set at the point of that fork is the (sub)set of parents of that txn. It doesn't have to be a full cohort... | 23:47 |
| Taek | digesting | 23:47 |
| bsm1175321 | So at that point, "confirmations" on the two forks generally will disagree. | 23:47 |
| Taek | yeah I think that's right | 23:48 |
| Taek | but a node doesn't see the world in terms of forks | 23:48 |
| bsm1175321 | There exists a point, that is a parent of both double-spends. | 23:48 |
| Taek | forks describe when two nodes have different worldviews | 23:49 |
| bsm1175321 | Mmmm yes it does. A node has to decide which to mine on top of. | 23:49 |
| Taek | hmm I guess that's not true | 23:49 |
| Taek | damn I hate the work fork | 23:49 |
| Taek | lol | 23:49 |
| Taek | it's overloaded | 23:49 |
| bsm1175321 | hahaahaa | 23:49 |
| bsm1175321 | Yeah, go fork yourself. ;-) | 23:49 |
| Taek | ok, so a node sees multiple potential chaintips, each with the same work, and some of which might be incompatible, and it's trying to figure out which chaintip to mine on | 23:50 |
| bsm1175321 | Title of a recent blog post with 0 readers... | 23:50 |
| bsm1175321 | Exactly. AFAIK in the event of such a tie, it *does* use the hash value. | 23:50 |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 264 seconds] | 23:50 | |
| Taek | gwillen: node will prefer the chaintip it saw first, correct? | 23:51 |
| Taek | assuming same height + total work? | 23:51 |
| -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 244 seconds] | 23:51 | |
| bsm1175321 | checking... | 23:51 |
| Taek | regardless, as soon as one of the chaintips has more work, the node will switch to that chaintip | 23:52 |
| bsm1175321 | Yes. | 23:53 |
| bsm1175321 | In this respect, my description of braids is identical to bitcoin. | 23:53 |
| Taek | ok. So you are worried about the world where there are consistently several conflicting chaintips | 23:53 |
| Taek | unmergeable | 23:53 |
| bsm1175321 | correct | 23:53 |
| Taek | as a brief aside | 23:54 |
| bsm1175321 | And that happens at high txn rate. | 23:55 |
| Taek | because you have total ordering for any given universe of nodes, you can actually allow illegal nodes to be merged | 23:55 |
| Taek | if two nodes are in conflict, the one that is earlier in the total ordering is the one that is accepted | 23:55 |
| Taek | but that's less interesting because it breaks SPV | 23:55 |
| bsm1175321 | I chose the word "bead" over "node" because I can't tell whether you're talking about Bitcoin AWS instances... | 23:55 |
| Taek | ah yeah | 23:56 |
| Taek | ok bead | 23:56 |
| bsm1175321 | How can illegal beads be merged? | 23:56 |
| Taek | you add them as parents. | 23:57 |
| bsm1175321 | Well...in your scheme a late-appearing bead could cause a reorg, no? | 23:57 |
| Taek | N late-appearing beads can cause a reorg as deep as N beads | 23:57 |
| bsm1175321 | Well conflicting parents define different braids... | 23:58 |
| bsm1175321 | And yes, braids can be reorged. | 23:58 |
| Taek | I'm debating whether to keep talking about the case where illegal beads can be merged, or switch back to the situation where illegal beads cannot be merged | 23:59 |
| --- Log closed Thu Mar 17 00:00:02 2016 | ||
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!