--- Log opened Wed Mar 16 00:00:01 2016
00:02 -!- phiche [~Adium@37.250.84.214.bredband.tre.se] has quit [Quit: Leaving.]
00:12 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
00:15 -!- phiche [~Adium@193.89.191.214] has joined #bitcoin-wizards
00:21 -!- jaekwon [~jaekwon@c-98-234-63-169.hsd1.ca.comcast.net] has quit [Remote host closed the connection]
00:35 -!- spinza [~spin@197.89.233.166] has quit [Ping timeout: 244 seconds]
00:40 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]
00:42 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-wizards
00:44 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-azboyycbtwyfpxwn] has joined #bitcoin-wizards
00:47 -!- 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:48 -!- spinza [~spin@197.89.233.166] has joined #bitcoin-wizards
00:51 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds]
01:00 -!- JackH [~Jack@host-2-103-125-30.as13285.net] has joined #bitcoin-wizards
01:06 -!- Esper [~pkotbauer@m176-71-32-29.cust.tele2.se] has joined #bitcoin-wizards
01:15 -!- Esper [~pkotbauer@m176-71-32-29.cust.tele2.se] has quit [Ping timeout: 252 seconds]
01:16 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection]
01:17 -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-wizards
01:22 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
01:27 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
01:30 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds]
01:34 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards
01:35 -!- Esper_ [~pkotbauer@m176-71-32-29.cust.tele2.se] has joined #bitcoin-wizards
01:40 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards
01:45 -!- proslogion [~proslogio@90.199.33.154] has joined #bitcoin-wizards
01:48 -!- 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:52 -!- 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]
02:04 -!- roconnor [~roconnor@host-45-58-253-237.dyn.295.ca] has quit [Ping timeout: 268 seconds]
02:07 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has joined #bitcoin-wizards
02:16 < 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:17 < nsh> how wo9uld the effective blocksize go up to 8MB under 'adversarial conditions'?
02:22 -!- 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:23 -!- 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:24 < 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:26 -!- jaekwon [~jaekwon@2601:645:c001:263a:7d8e:29:ffc5:adda] has quit [Ping timeout: 250 seconds]
02:29 < 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:30 < nsh> but that's how they pick popes....
02:32 < 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:36 < 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:41 < nsh> hmm
02:48 -!- 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:53 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds]
02:54  * 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:55 < 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:56 < 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?
03:00 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 268 seconds]
03:01 < fluffypony> what if adlai == satoshi?
03:01 < fluffypony> dun dun dun DUN
03:02 -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.]
03:03 < proslogion> hi, so are we going anywhere with OP_SIDECHAINPROOFVERIFY? thanks
03:06 < JackH> or BIP65, 112 and 113?
03:08 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has quit [Ping timeout: 268 seconds]
03:12 < kanzure> proslogion: i think you can use these instead: OP_WITHDRAWALPROOFVERIFY OP_REORGPROOFVERIFYOP_CHECK_VOTES_VERIFY OP_CHECKMULTISIG
03:14 < nsh> how is a reorg proof verified?
03:14 < kanzure> oops yes those were two separate things, OP_REORGPROOFVERIFY OP_CHECK_VOTES_VERIFY
03:21 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards
03:23 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
03:29 -!- MoALTz_ is now known as MoALTz
03:30 -!- 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:31 < aj> JackH: bip65 is done? 68, 112 and 113 are pending versionbits implementation because classic mining messes up IsSuperMajority aiui
03:32 < JackH> so we have to wait for versionbits before we can enable them?
03:33 < 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:36 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has quit [Ping timeout: 248 seconds]
03:38 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
03:39 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
03:40 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
03:42 < JackH> so what, we are stalling because of classic now?
03:43 < JackH> and we cant deploy what is arguably the most important BIP's ever ?
03:47 < aj> more of a scenic detour than an outright stall
03:48 < 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:49 -!- 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:50 < 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:51 < 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:52 < 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:53 -!- atgreen [~green@CPE687f74122463-CM00fc8d24cab0.cpe.net.cable.rogers.com] has quit [Ping timeout: 260 seconds]
03:54 -!- 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:58 < aj> https://github.com/bitcoin/bitcoin/pull/7575 and https://github.com/bitcoin/bitcoin/pull/7648 i'd guess?
04:01 < JackH> alright, makes perfect sense now
04:04 -!- Esper_ [~pkotbauer@m176-71-32-29.cust.tele2.se] has quit [Ping timeout: 246 seconds]
04:09 -!- andytoshi [~andytoshi@wpsoftware.net] has quit [Ping timeout: 268 seconds]
04:14 < JackH> so merge it already
04:16 < 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:17 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has joined #bitcoin-wizards
04:18 < 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:19 < 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:20 < 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:23 < adlai> (and yes, satoshi was a man. cue Carlin's "no woman would've fucked things up this badly")
04:24 < 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:26 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
04:27 -!- Esper [~pkotbauer@m176-71-32-29.cust.tele2.se] has joined #bitcoin-wizards
04:28 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards
04:31 -!- 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:38 -!- murch [~murch@p4FE39668.dip0.t-ipconnect.de] has joined #bitcoin-wizards
04:42 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has quit [Ping timeout: 240 seconds]
04:45 -!- atgreen [~green@CPE687f74122463-CM00fc8d24cab0.cpe.net.cable.rogers.com] has joined #bitcoin-wizards
04:50 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
04:55 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds]
04:58 -!- nanasho [~nanasha25@195-154-136-40.rev.poneytelecom.eu] has joined #bitcoin-wizards
04:59 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has joined #bitcoin-wizards
05:01 -!- GAit1 [~GAit@93-38-252-172.ip73.fastwebnet.it] has joined #bitcoin-wizards
05:05 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Ping timeout: 240 seconds]
05:12 < nanasho> am i wrong to assume that coinwhomustnotbenamed will have the same blockchain growth issues
05:12 < nanasho> 28x as fast, actually?
05:15 -!- jaekwon [~jaekwon@2601:645:c001:263a:7d8e:29:ffc5:adda] has joined #bitcoin-wizards
05:16 -!- 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:19 -!- andytoshi [~andytoshi@wpsoftware.net] has joined #bitcoin-wizards
05:21 < 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:22 < 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:23 < 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:24 < proslogion> adlai: how? you need to pay fees to have your tx mined, in most of the cases
05:25 < 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:26 -!- Esper [~pkotbauer@m176-71-32-29.cust.tele2.se] has quit [Ping timeout: 264 seconds]
05:28 < proslogion> i think with OP_RETURN you need to burn some outputs, of coz in theory you can burn 0
05:44 -!- Esper [~pkotbauer@m176-71-32-29.cust.tele2.se] has joined #bitcoin-wizards
05:45 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has quit [Quit: Leaving]
05:49 -!- crossing-styx [~crossing-@c-67-165-86-109.hsd1.pa.comcast.net] has joined #bitcoin-wizards
05:51 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
05:55 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 244 seconds]
05:59 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 248 seconds]
06:06 -!- c0rw1n [~c0rw1n@225.139-67-87.adsl-dyn.isp.belgacom.be] has quit [Remote host closed the connection]
06:07 -!- 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:12 -!- GAit1 [~GAit@93-38-252-172.ip73.fastwebnet.it] has quit [Quit: Leaving.]
06:14 -!- iddo [~idddo@csm.cs.technion.ac.il] has quit [Ping timeout: 252 seconds]
06:15 -!- iddo [~idddo@csm.cs.technion.ac.il] has joined #bitcoin-wizards
06:28 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
06:36 -!- jaekwon [~jaekwon@c-98-234-63-169.hsd1.ca.comcast.net] has quit [Remote host closed the connection]
06:42 -!- Esper [~pkotbauer@m176-71-32-29.cust.tele2.se] has quit [Quit: Lost terminal]
06:48 -!- bildramer [~bildramer@p5DC8ADCC.dip0.t-ipconnect.de] has joined #bitcoin-wizards
06:51 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
06:56 -!- 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]
07:06 -!- sn0wmonster [~skifree@unaffiliated/sn0wmonster] has joined #bitcoin-wizards
07:08 -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards
07:27 -!- zooko [~user@50-79-43-161-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards
07:33 -!- proslogion [~proslogio@94.119.67.131] has joined #bitcoin-wizards
07:40 -!- proslogion [~proslogio@94.119.67.131] has quit [Ping timeout: 248 seconds]
07:42 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-nkjvcygsodsyflfq] has joined #bitcoin-wizards
07:43 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
07:45 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]
07:45 -!- Guyver2_ is now known as Guyver2
07:52 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
07:56 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
07:57 -!- proslogion [~proslogio@130.159.13.130] has joined #bitcoin-wizards
07:58 -!- GAit [~GAit@212.91.77.40] has quit [Quit: Leaving.]
08:04 -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards
08:08 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has quit [Ping timeout: 250 seconds]
08:13 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has joined #bitcoin-wizards
08:15 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
08:16 -!- 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:22 -!- 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:23 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-wizards
08:26 -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards
08:28 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 276 seconds]
08:31 -!- zooko [~user@50-79-43-161-static.hfc.comcastbusiness.net] has quit [Ping timeout: 244 seconds]
08:32 -!- GAit [~GAit@212.91.77.40] has quit [Quit: Leaving.]
08:32 -!- voxelot [~voxelot@remote.digitalmoneycorp.com] has joined #bitcoin-wizards
08:37 -!- funkenstein_ [~bowler@unaffiliated/funkenstein] has joined #bitcoin-wizards
08:52 -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards
08:53 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
08:56 -!- 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:58 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds]
09:03 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
09:06 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
09:13 -!- 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:19 -!- 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:22 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:d83:465a:de98:5e99] has quit [Read error: Connection reset by peer]
09:24 -!- 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:26 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards
09:27 -!- 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:28 -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards
09:39 -!- 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:44 -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards
09:49 -!- markus-k [~markus-k@p4FCCC251.dip0.t-ipconnect.de] has joined #bitcoin-wizards
09:54 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
09:56 -!- 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:57 -!- GAit [~GAit@212.91.77.40] has quit [Quit: Leaving.]
09:58 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 248 seconds]
10:01 -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards
10:02 -!- 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:06 -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards
10:07 -!- 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:11 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 276 seconds]
10:13 -!- GAit [~GAit@212.91.77.40] has quit [Quit: Leaving.]
10:16 -!- brianhoffman [~brianhoff@pool-173-79-161-229.washdc.fios.verizon.net] has joined #bitcoin-wizards
10:23 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards
10:30 -!- dEBRUYNE [~dEBRUYNE@unaffiliated/debruyne] has joined #bitcoin-wizards
10:31 -!- GAit [~GAit@212.91.77.40] has joined #bitcoin-wizards
10:33 -!- phiche [~Adium@193.89.191.214] has quit [Quit: Leaving.]
10:37 -!- GAit [~GAit@212.91.77.40] has quit [Ping timeout: 244 seconds]
10:38 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-wizards
10:41 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 260 seconds]
10:54 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
10:57 -!- proslogion [~proslogio@130.159.13.130] has quit [Ping timeout: 268 seconds]
10:59 -!- 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]
11:04 -!- gigq [~gigq@45-20-197-26.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-wizards
11:06 -!- molz [~molly@unaffiliated/molly] has quit [Write error: Connection reset by peer]
11:07 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-wizards
11:13 -!- wallet421 [~wallet42@172.58.104.227] has joined #bitcoin-wizards
11:16 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Ping timeout: 248 seconds]
11:17 -!- joesmoe_ [~joesmoe@201.216.206.41] has joined #bitcoin-wizards
11:19 -!- joesmoe [~joesmoe@201.216.206.41] has quit [Read error: Connection reset by peer]
11:42 -!- cluckj [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has joined #bitcoin-wizards
11:46 -!- binaryatrocity [~quassel@unaffiliated/br4n] has joined #bitcoin-wizards
11:50 -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection]
11:53 -!- CrazyTruthYakDDS [uid67551@gateway/web/irccloud.com/x-wlfsidzkcejhihia] has joined #bitcoin-wizards
11:55 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
11:56 -!- 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
12:00 -!- 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:05 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
12:12 -!- jaekwon [~jaekwon@173-13-150-22-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards
12:15 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
12:17 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Client Quit]
12:22 -!- 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:26 -!- mol11111 [~molly@unaffiliated/molly] has joined #bitcoin-wizards
12:27 -!- mol11111 is now known as moli
12:28 -!- 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:32 -!- jaekwon [~jaekwon@173-13-150-22-sfba.hfc.comcastbusiness.net] has joined #bitcoin-wizards
12:41 < 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:46 -!- Krellan [~krellan@2601:640:4000:1ee4:216d:f0a0:9e73:dc3c] has joined #bitcoin-wizards
12:56 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
12:57 -!- kaptah [kaptah@hilla.kapsi.fi] has quit [Ping timeout: 250 seconds]
13:01 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 276 seconds]
13:02 -!- jaekwon [~jaekwon@173-13-150-22-sfba.hfc.comcastbusiness.net] has quit [Ping timeout: 260 seconds]
13:07 -!- 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:14 -!- 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:17 -!- proslogion [~proslogio@90.199.33.154] has joined #bitcoin-wizards
13:18 -!- jaekwon [~jaekwon@173-13-150-22-sfba.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
13:19 -!- 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:23 -!- 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:25 -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards
13:26 -!- 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:27 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Remote host closed the connection]
13:28 -!- 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:29 -!- nanasho [~nanasha25@195-154-136-40.rev.poneytelecom.eu] has joined #bitcoin-wizards
13:44 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
13:55 -!- funkenstein_ [~bowler@unaffiliated/funkenstein] has joined #bitcoin-wizards
13:57 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
14:01 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 244 seconds]
14:08 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds]
14:23 -!- 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:26 -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection]
14:47 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
14:57 -!- koshii [~w@c-68-58-151-30.hsd1.in.comcast.net] has quit [Ping timeout: 246 seconds]
14:58 -!- 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
15:01 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards
15:02 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]
15:13 -!- kisspunch_ [~za3k@71.19.156.60] has joined #bitcoin-wizards
15:14 -!- 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:15 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
15:15 -!- kisspunch_ is now known as kisspunch
15:17 -!- 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:21 -!- adlai [~adlai@unaffiliated/adlai] has quit [Ping timeout: 250 seconds]
15:24 -!- 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:25 -!- earthris1 [~earthrise@S01065404a6902716.cg.shawcable.net] has quit [Remote host closed the connection]
15:26 -!- 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:28 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]
15:29 -!- 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:31 < 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:32 -!- HastaJun [~10339A764@c-98c5e455.02-226-6c6b701.cust.bredbandsbolaget.se] has joined #bitcoin-wizards
15:33 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
15:35 < JackH> what does it do
15:36 < 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:37 < 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:38 < 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:39 < maaku> sorry i wouldn't have time. just wanted to save you from wasting your time :\
15:41 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
15:42 < JackH> is it on github yet bramc
15:43 < 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:48 < bramc> Okay here you go https://github.com/bramcohen/NotValidAfter/blob/master/Transaction_expirations.txt
15:49 < bramc> Feedback much appreciated
15:49 < nanasho> can it only be done using segwit? :(
15:50 < bramc> nanasho: Unfortunately yes, the extension hooks pre-segwit suck too badly
15:50 < bramc> Otherwise I'd have written something months ago
15:51 < nanasho> i think segwit is an accounting trick to fool miners
15:52 -!- 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:53 < 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:55 < bramc> Actual feedback would be appreciated
15:55 -!- phiche [~Adium@37.250.84.214.bredband.tre.se] has quit [Quit: Leaving.]
15:57  * nsh science spideysense tingles
15:58 -!- 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:59 < 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
16:00 < 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:01 -!- nabu [~nabu@192.40.88.16] has joined #bitcoin-wizards
16:03 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
16:06 < Luke-Jr> nanotube: it is stored in blocks
16:08 < 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:09 < bramc> nsh: Unfortunately I can't. nullc told me that it's fairly trivial after segwit and I believe him
16:10 < nsh> kk
16:10 < nsh> i need to better understand segwit anyway. should read up
16:11 < 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:12 < 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:13 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
16:15 < 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:16 < 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:17 -!- 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:18 < 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:19 < 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:20 < 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:21 < 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:22 < 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:23 < 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:24 < 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:25 < 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:26 < 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:27 < 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:28 < 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:29 < 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:30 < 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:31 < 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:32 < 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:33 < 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:34 < 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:35 < 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:42 -!- nanasho [~nanasha25@141.39.226.229] has joined #bitcoin-wizards
16:43 < nanasho> short recap, upgraded nodes store sigs/witness data, but old nodes dont, they see anyone can spend transactions, correct?
16:44 -!- 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:45 < maaku> nanasho: they don't 'see' anything. they see 'other people's transactions'
16:46 < 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:48 < nanasho> hm ok
16:48 < nanasho> old nodes see an empty sig ... wouldn't some people try to spend those outputs?
16:52 -!- Yoghur114 [~jorn@g227014.upc-g.chello.nl] has quit [Remote host closed the connection]
16:53 -!- 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:54 < 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:55 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-wizards
16:59 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
17:00 -!- joesmoe_ [~joesmoe@201.216.206.41] has quit [Ping timeout: 248 seconds]
17:02 -!- voxelot [~voxelot@remote.digitalmoneycorp.com] has quit [Ping timeout: 246 seconds]
17:03 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
17:04 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds]
17:05 -!- stqism [~coup_de_s@freebsd/user/stqism] has quit [Ping timeout: 250 seconds]
17:06 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has quit [Ping timeout: 250 seconds]
17:07 -!- coup_de_shitlord [~coup_de_s@irc.toxme.se] has joined #bitcoin-wizards
17:08 -!- 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:19 -!- bramc [26632a82@gateway/web/freenode/ip.38.99.42.130] has quit [Ping timeout: 252 seconds]
17:20 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 248 seconds]
17:21 -!- belcher [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
17:22 -!- binaryatrocity [~quassel@unaffiliated/br4n] has quit [Ping timeout: 240 seconds]
17:22 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Max SendQ exceeded]
17:23 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards
17:23 -!- Cory [~C@unaffiliated/cory] has joined #bitcoin-wizards
17:29 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
17:35 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards
17:42 -!- joesmoe [~joesmoe@181.47.58.241] has joined #bitcoin-wizards
17:43 -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection]
17:50 -!- jaekwon [~jaekwon@75-101-96-71.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards
17:55 -!- 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.]
18:00 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
18:01 -!- joesmoe [~joesmoe@181.47.58.241] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
18:02 -!- joesmoe [~joesmoe@181.47.58.241] has joined #bitcoin-wizards
18:05 -!- 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:11 -!- roconnor [~roconnor@host-45-58-250-196.dyn.295.ca] has joined #bitcoin-wizards
18:17 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
18:20 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
18:21 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-azboyycbtwyfpxwn] has quit [Quit: Connection closed for inactivity]
18:25 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
18:29 -!- everyBloc [~everybloc@c-73-158-140-36.hsd1.ca.comcast.net] has quit [Remote host closed the connection]
18:34 -!- everyBloc [~everybloc@c-73-158-140-36.hsd1.ca.comcast.net] has joined #bitcoin-wizards
18:37 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 248 seconds]
18:44 -!- joesmoe [~joesmoe@181.47.58.241] has quit [Ping timeout: 260 seconds]
18:45 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Quit: Later.]
18:50 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
18:52 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards
18:53 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 250 seconds]
18:54 -!- 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:56 -!- veleiro [~veleiro@fsf/member/veleiro] has joined #bitcoin-wizards
18:58 -!- jgarzik__ [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has quit [Quit: Leaving]
19:01 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
19:04 -!- 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:06 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds]
19:10 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
19:19 -!- Netsplit *.net <-> *.split quits: PsychoticBoy, jbenet, c0rw1n, roconnor, jannes, adams__, jtimon, harrow`, amiller, CodeShark,  (+9 more, use /NETSPLIT to show all of them)
19:22 -!- c0rw1n [~c0rw1n@225.139-67-87.adsl-dyn.isp.belgacom.be] has joined #bitcoin-wizards
19:25 -!- 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:26 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards
19:31 -!- markus-k_ [~markus-k@p4FCCC194.dip0.t-ipconnect.de] has joined #bitcoin-wizards
19:32 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton]
19:33 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-wizards
19:34 -!- 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:36 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-wizards
19:37 -!- hashtag_ [~hashtag@cpe-174-97-254-80.ma.res.rr.com] has quit [Ping timeout: 268 seconds]
19:38 < 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:39 < 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:41 -!- 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:42 -!- 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:48 < funkenstein_> wrong channel bro?  :)
19:48 < bsm1175321> No.  funkmeister.  Responding to a comment from earlier today.
19:49 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-wizards
19:51 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-chbkthvkuisyhwvm] has quit [Quit: Connection closed for inactivity]
20:00 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Read error: Connection reset by peer]
20:01 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
20:02 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-wizards
20:05 -!- nuke1989 [~nuke@46-86-125.adsl.cyta.gr] has quit [Remote host closed the connection]
20:06 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds]
20:09 -!- e0 [~e0@c-66-30-116-211.hsd1.ma.comcast.net] has quit [Ping timeout: 248 seconds]
20:14 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton]
20:24 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
20:30 -!- 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:32 -!- 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:35 -!- wizkid057 [wizkid@unaffiliated/wizkid057] has joined #bitcoin-wizards
20:39 -!- 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:45 < 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:46 < funkenstein_> :o this i want to see
20:46  * bsm1175321 whips it out for funkenstein_
20:47 < funkenstein_> lol
20:48 -!- 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:51 < 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:52 < 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:54 < funkenstein_> i see where you're coming from though, its helpful to have a limit
20:54 < bsm1175321> funkenstein_: no, it's not.
20:55 < 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:57 < 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:59 < 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.
21:00 -!- 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:01 < 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:02 < 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:03 < bsm1175321> FWIW, some python code for generating braids, evaluating rewards, and plotting will be published alongside the paper.
21:05 < bsm1175321> The algorithms all rely on graph_tool which is based on the Boost Graph Library, so are straightforwardly importable into Bitcoin.
21:08 < 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:09 -!- 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:10 < 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:11 < 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:12 < 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:14 < 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:15 < bsm1175321> (or a bitcoin-like-coin without the Ethereum state machine)
21:15 < funkenstein_> that's better ;)
21:18 -!- mol11111 [~molly@unaffiliated/molly] has joined #bitcoin-wizards
21:19 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards
21:21 -!- 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:25 -!- MoALTz [~no@78-11-183-124.static.ip.netia.com.pl] has quit [Ping timeout: 244 seconds]
21:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
21:35 -!- kisspunch [~za3k@71.19.156.60] has quit [Ping timeout: 276 seconds]
21:36 < 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:40 -!- everyBlo_ [~everybloc@c-73-158-140-36.hsd1.ca.comcast.net] has quit [Remote host closed the connection]
21:46 -!- iLearn [~ilearn@h-219-171.a240.priv.bahnhof.se] has quit [Remote host closed the connection]
21:53 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
22:03 -!- RoboTeddy [~roboteddy@c-67-188-40-206.hsd1.ca.comcast.net] has joined #bitcoin-wizards
22:08 < 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:09 < 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:10 < 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:11 < 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:12 < 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:13 < 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:14 < 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:15 < 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:16 < 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:17 < 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:18 < 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:19 < bsm1175321> So what do you do with "siblings" as I define them?  -- You use the mined work (not the target work)?
22:21 -!- 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:22 < 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:23 < 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:24 < 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:25 < 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:26 < 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:27 < 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:28 -!- 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:29 < 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:30 -!- 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:31 < 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:32 < 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:33 < 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:34 < 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:35 < 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:36 -!- 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:37 < 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:38 < 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:39 < 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:40 < 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:41 < 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:42 -!- 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:43 < Taek> yes, I'm arguing that
22:44 < 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:45 < 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:46 < 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:47 < 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:48 < 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:49 < 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:50 < 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:51 < 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:53 < 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:56 < 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:57 < 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:58 < 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:59 < 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
23:00 < 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:01 < 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:02 < 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:03 < 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:04 -!- 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:05 < 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:06 < 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:07 < 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:08 < 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:09 < 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:10 < 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:11 < 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:12 < 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:13 < 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:14 < 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:15 < 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:16 < 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:17 < Taek> ok
23:18 < 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:19 < 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:20 < 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:21 < 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:22 < 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:23 < 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:24 < 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:25 < 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:26 < 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:27 < 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:28 < 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:29 < 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:30 < 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:31 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-wizards
23:31 < bsm1175321> Taek: requiring a fast network is an anti-chinese-communisim-censorship measure.
23:32 < 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:33 < Taek> uh
23:33 < bsm1175321> Anyhoo...convince me you can achieve a total ordering...
23:34 < 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:35 < 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:36 < bsm1175321> Yeah.  More interesting.
23:37 < 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:38 < bsm1175321> Bitcoin's "total order" is due to synchronicity: everyone must have seen everything.
23:39 < 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:40 < Taek> those nodes will remain inconsistent about which block is the 'real' block until one of the blocks gets more confirmations
23:41 < 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:42 < bsm1175321> Ok, yes.
23:42 < bsm1175321> I've totally just discredited myself.
23:43 < Taek> lol
23:44 < 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:45 < 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:46 < 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:47 < 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:48 < 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:49 < 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:50 < 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:51 < 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:52 < Taek> regardless, as soon as one of the chaintips has more work, the node will switch to that chaintip
23:53 < 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:54 < Taek> as a brief aside
23:55 < 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:56 < Taek> ah yeah
23:56 < Taek> ok bead
23:56 < bsm1175321> How can illegal beads be merged?
23:57 < 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:58 < bsm1175321> Well conflicting parents define different braids...
23:58 < bsm1175321> And yes, braids can be reorged.
23:59 < 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
--- Log closed Thu Mar 17 00:00:02 2016