--- Log opened Sun Feb 25 00:00:02 2018
00:01 -!- knifeofpi [~Mutter@2600:380:9062:87a5:903f:d677:1007:227d] has joined #bitcoin-wizards
00:04 -!- knifeofpi [~Mutter@2600:380:9062:87a5:903f:d677:1007:227d] has quit [Client Quit]
00:14 -!- knifeofpi [~Mutter@2600:380:9062:87a5:903f:d677:1007:227d] has joined #bitcoin-wizards
00:18 -!- knifeofpi [~Mutter@2600:380:9062:87a5:903f:d677:1007:227d] has quit [Client Quit]
00:23 -!- jtimon_ [~quassel@41.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]
01:14 -!- flokie [~flokie@unaffiliated/flokie] has quit [Quit: Leaving]
01:23 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 268 seconds]
01:25 -!- hkjn0 [~hkjn@215.134.198.35.bc.googleusercontent.com] has quit [Ping timeout: 248 seconds]
01:29 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has quit [Ping timeout: 256 seconds]
01:30 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has joined #bitcoin-wizards
01:31 -!- rodarmor [sid210835@gateway/web/irccloud.com/x-tghtfpupftxepgpz] has quit [Ping timeout: 276 seconds]
01:32 -!- rodarmor [sid210835@gateway/web/irccloud.com/x-akrhoeurinqzgzou] has joined #bitcoin-wizards
01:33 -!- warren_ is now known as warren
01:34 -!- Netsplit *.net <-> *.split quits: yokwe, Guest53717, PsychoticBoy, roconnor, Alanius
01:35 -!- Netsplit *.net <-> *.split quits: eragmus, HSF_Prince_Loaf, spinza, wpalczynski, fronti, Madars, bildramer, arowser, Hunger-, zxzzt,  (+6 more, use /NETSPLIT to show all of them)
01:36 -!- Netsplit over, joins: Guest53717, Alanius, PsychoticBoy, yokwe, roconnor, zxzzt, HSF_Prince_Loaf, spinza, bildramer, Madars (+11 more)
01:36 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds]
01:37 -!- aem [AEM@gateway/shell/elitebnc/x-cjtkuwjqegtiiuem] has quit [Ping timeout: 256 seconds]
01:37 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has quit [Ping timeout: 240 seconds]
01:37 -!- AEM [AEM@gateway/shell/elitebnc/x-bkmviumrbvatqxeb] has joined #bitcoin-wizards
01:38 -!- shesek [~shesek@bzq-84-110-235-179.red.bezeqint.net] has joined #bitcoin-wizards
01:40 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
01:40 -!- shesek [~shesek@bzq-84-110-235-179.red.bezeqint.net] has quit [Changing host]
01:40 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-wizards
01:40 -!- instagibbs [~instagibb@pool-100-15-116-35.washdc.fios.verizon.net] has joined #bitcoin-wizards
01:41 -!- AEM is now known as Guest59762
01:42 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has joined #bitcoin-wizards
01:48 -!- roconnor [~roconnor@host-192.252-166-159.dyn.295.ca] has quit [Ping timeout: 256 seconds]
01:48 -!- roconnor_ [~roconnor@host-192.252-166-159.dyn.295.ca] has joined #bitcoin-wizards
01:54 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
01:58 -!- forrestv [forrestv@unaffiliated/forrestv] has quit [Max SendQ exceeded]
01:58 -!- wizkid057 [~wk@unaffiliated/wizkid057] has quit [Read error: Connection reset by peer]
02:00 -!- forrestv [forrestv@unaffiliated/forrestv] has joined #bitcoin-wizards
02:01 -!- michels [~Michdels@19.53.30.125.dy.iij4u.or.jp] has joined #bitcoin-wizards
02:01 -!- michels [~Michdels@19.53.30.125.dy.iij4u.or.jp] has left #bitcoin-wizards []
02:18 -!- circ-user-cTpdh [~circuser-@ool-4350bb0a.dyn.optonline.net] has joined #bitcoin-wizards
02:20 -!- wizkid057 [~wk@unaffiliated/wizkid057] has joined #bitcoin-wizards
02:22 -!- circ-user-cTpdh [~circuser-@ool-4350bb0a.dyn.optonline.net] has quit [Ping timeout: 252 seconds]
02:25 -!- hkjn0 [~hkjn@4.128.198.35.bc.googleusercontent.com] has joined #bitcoin-wizards
02:31 -!- dnaleor [~dnaleor@host-im1adb.cbn1.zeelandnet.nl] has joined #bitcoin-wizards
02:34 -!- b10c [~b10c@185.143.230.224] has joined #bitcoin-wizards
02:36 -!- orbital9 [4b668874@gateway/web/freenode/ip.75.102.136.116] has joined #bitcoin-wizards
02:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
02:42 -!- orbital9 [4b668874@gateway/web/freenode/ip.75.102.136.116] has quit [Quit: Page closed]
02:57 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-wizards
03:02 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
03:08 -!- nuke_bloodaxe [~nuke_bloo@125-238-249-162.jetstream.xtra.co.nz] has joined #bitcoin-wizards
03:11 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has quit [Remote host closed the connection]
03:11 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has joined #bitcoin-wizards
03:12 -!- nuke_bloodaxe [~nuke_bloo@125-238-249-162.jetstream.xtra.co.nz] has quit []
03:16 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has quit [Ping timeout: 245 seconds]
03:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 245 seconds]
03:32 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards
04:16 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds]
04:26 -!- airbreather_ [~airbreath@d149-67-99-43.nap.wideopenwest.com] has joined #bitcoin-wizards
04:29 -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has quit [Ping timeout: 240 seconds]
04:30 -!- airbreather_ is now known as airbreather
04:40 -!- b10c [~b10c@185.143.230.224] has quit [Remote host closed the connection]
04:42 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
04:43 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
04:57 -!- b10c [~b10c@185.143.230.224] has joined #bitcoin-wizards
04:59 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-wizards
05:03 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-lmlxkcluafoswbuh] has quit [Quit: Connection closed for inactivity]
05:13 -!- cryptojanitor [uid278088@gateway/web/irccloud.com/x-ntngjvdchwthdvio] has joined #bitcoin-wizards
05:18 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-kokuqozhpjpfxrqs] has joined #bitcoin-wizards
05:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds]
05:51 -!- Belkaar [~Belkaar@unaffiliated/belkaar] has quit [Read error: Connection reset by peer]
05:53 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
05:59 -!- Belkaar [~Belkaar@xdsl-87-79-149-74.netcologne.de] has joined #bitcoin-wizards
05:59 -!- Belkaar [~Belkaar@xdsl-87-79-149-74.netcologne.de] has quit [Changing host]
05:59 -!- Belkaar [~Belkaar@unaffiliated/belkaar] has joined #bitcoin-wizards
06:43 -!- bsm117532 [~mcelrath@c-65-96-61-129.hsd1.ma.comcast.net] has joined #bitcoin-wizards
06:48 -!- son0p [~ff@adsl201-232-238-252.epm.net.co] has quit [Quit: Lost terminal]
06:50 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
06:54 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has left #bitcoin-wizards ["Closing Window"]
06:56 -!- satwo [~textual@2602:306:378a:6fb0:8d36:4040:776e:ffaa] has joined #bitcoin-wizards
07:03 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
07:08 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-wizards
07:18 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
07:19 -!- Giszmo [~leo@ip-42-237-219-201.nextelmovil.cl] has quit [Quit: Leaving.]
07:33 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-kokuqozhpjpfxrqs] has quit [Quit: Connection closed for inactivity]
07:42 -!- Giszmo [~leo@ip-42-237-219-201.nextelmovil.cl] has joined #bitcoin-wizards
07:57 -!- PaulTroon [~Paul@155.4.14.27] has joined #bitcoin-wizards
08:09 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
08:10 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
08:10 -!- douglas_ [~douglas@c-73-234-93-65.hsd1.nh.comcast.net] has joined #bitcoin-wizards
08:15 -!- satwo [~textual@2602:306:378a:6fb0:8d36:4040:776e:ffaa] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
08:25 -!- b10c [~b10c@185.143.230.224] has quit [Ping timeout: 256 seconds]
08:25 < kanzure> "Simple proofs of sequential work" https://eprint.iacr.org/2018/183.pdf
08:33 -!- b10c [~b10c@185.143.230.224] has joined #bitcoin-wizards
08:39 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 256 seconds]
08:47 < kanzure> is the random oracle model from bellare the same bellare from bellare-neven?
08:48 < kanzure> Bellare, M., Rogaway, P.: Random oracles are practical: A paradigm for designing efficient protocols. ACM CCS 93.
08:50 < kanzure> from "The wonderful world of global random oracles" https://eprint.iacr.org/2018/165.pdf
08:53 -!- CubicEarths [~cubiceart@73.93.141.136] has joined #bitcoin-wizards
09:00 < kanzure> in this paper ("paralysis proofs") https://eprint.iacr.org/2018/096  the authors propose to use trusted hardware and periodic challenges against multisig members to prove that the authentication set needs to be updated to remove offline/dead/unavailable members. but isn't this going to be vulnerable to DoS attacking a member from submitting a challenge response?
09:01 < kanzure> i guess the idea is that the challenge response size is so small that anyone should be able to upload it through many different means. and assumes no long-term network partitions between any of the mmebers and the challenge server.
09:03 -!- b10c [~b10c@185.143.230.224] has quit [Remote host closed the connection]
09:12 < andytoshi> kanzure: yes, same bellare
09:13 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
09:13 < kanzure> "Reusing nonces in Schnorr signatures" https://eprint.iacr.org/2018/069.pdf
09:14 -!- JackH [~laptop@i25091.upc-i.chello.nl] has joined #bitcoin-wizards
09:17 < andytoshi> i like the brazenness of writing a paper in 2018 about schnorr signatures that has nothing at all to do with elliptic curves
09:17 < andytoshi> (and sadly, it doesn't look like this technique can be adapted to elliptic curves in any way)
09:20 < kanzure> fc18 seems to have jumped on to the "blockchain voting" bandwagon https://fc18.ifca.ai/voting/program.html
09:28 < Alanius> actually, the random oracle is often also credited to Fiat and Shamir (in addition to Bellare and Rogaway)
09:28 < CubicEarths> kanzure: Are you there?
09:28 < CubicEarths> fc18?
09:29 < kanzure> no
09:35 < sipa> kanzure: it's a separate workshop
09:39 -!- dnaleor [~dnaleor@host-im1adb.cbn1.zeelandnet.nl] has quit [Quit: Leaving]
09:40 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards
09:41 -!- b10c [~b10c@185.143.230.224] has joined #bitcoin-wizards
09:41 < CubicEarths> voting is a form of coordination. communities that have better coordination are at an advantage.
09:42 -!- b10c [~b10c@185.143.230.224] has quit [Client Quit]
09:43 < kanzure> alright well as soon as you solve secure voting please be sure to let the world know
09:44 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-arwwkmkvoqqugmhk] has joined #bitcoin-wizards
09:45 -!- meeh_ is now known as mikalv
09:46 < CubicEarths> voting doesn't seem much constrained by technical issues. its more social attempts to exclude people
09:47 -!- nuncanada [~dude@187.65.68.254] has joined #bitcoin-wizards
09:52 -!- itsme [~textual@x4d04d83b.dyn.telefonica.de] has joined #bitcoin-wizards
10:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
10:13 -!- Giszmo [~leo@ip-42-237-219-201.nextelmovil.cl] has quit [Ping timeout: 260 seconds]
10:23 < uiuc-slack> <stonecoldpat> CubicEarths: https://www.defcon.org/images/defcon-25/DEF%20CON%2025%20voting%20village%20report.pdf
10:24 -!- itsme__ [~textual@x4d04cac4.dyn.telefonica.de] has joined #bitcoin-wizards
10:25 < uiuc-slack> <stonecoldpat> https://benlog.com/2017/12/28/blockchain-and-voting/
10:25 -!- itsme [~textual@x4d04d83b.dyn.telefonica.de] has quit [Ping timeout: 256 seconds]
10:26 -!- daszorz [~daszorz@cpc106809-live29-2-0-cust896.17-2.cable.virginm.net] has joined #bitcoin-wizards
10:27 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
10:28 -!- Aaronvan_ is now known as AaronvanW_
10:29 < CubicEarths> "Ultimately, the list of eligible voters is set in a centralized way: it’s produced by the State"
10:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds]
10:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
10:33 -!- AaronvanW_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
10:37 < CubicEarths> States, not being efficient markets, seem to have an incentive to exclude participation. Due to the free-market ethos of blockchains, it seems they would benefit from an inclusionary stance.
10:37 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Quit: Textual IRC Client: www.textualapp.com]
10:38 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
10:40 < kanzure> stonecoldpat: do you have a good overview link for the numerous ways that secure voting isn't as secure as some folks might expect? your defcon link seems to be about various voting machines, which is a more specific problem but sort of pointless if there's no solution in the first place.
10:46 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
10:48 -!- Aaronvan_ is now known as AaronvanW_
10:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
11:00 < CubicEarths> kanzure: so many different types votes though. A coin-weighted vote could be constructed to be almost perfectly secure... obviously there is no expectation that would represent a count of humans
11:02 -!- ne1l [~dnv@95.143.195.108] has joined #bitcoin-wizards
11:02 -!- ne1l is now known as ne1ln
11:04 -!- ne1ln [~dnv@95.143.195.108] has quit [Client Quit]
11:05 < sipa> CubicEarths: miners can censor, if it's about something financially relevant to them
11:12 < CubicEarths> sipa: I think the votes can be cast blindly, and after voting closes, which side the vote was for can re revealed
11:30 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-wizards
11:33 < kanzure> reveals can also be censored
11:35 < CubicEarths> the reveals can exist off chain
11:35 < sipa> then who gets to reveal?
11:36 < CubicEarths> the people who cast votes
11:37 < sipa> if the chain is a means for censorshio reisstance, then what have you solved if you can't use it for revealing?
11:37 < kanzure> also: separately, i believe it's considered insecure to have a way to reveal a vote because otherwise you get into weirdo coercion scenarios
11:38 < sipa> exactly
11:38 < sipa> good voting schemes have no means to prove what you voted for at any time
11:38 < kanzure> (although i think others have proposed "instead of revealing the content of a vote, the presence of the vote can be guaranteed without revealing the content/valence")
11:38 < kanzure> s/guaranteed/verified
11:38 < sipa> only the sum of the votes gets revealed
11:41 -!- itsme__ [~textual@x4d04cac4.dyn.telefonica.de] has quit [Quit: Textual IRC Client: www.textualapp.com]
11:41 < kanzure> alsooo for large-scale voting systems, blockchain isn't going to work because of system capacity limitations.
11:42 < kanzure> and the only solution for the voter membership set problem seems to be "everyone knows all members and can independently verify that there's no hidden members in the membership set"
11:48 < CubicEarths> Just because you couldn't use the chain for reveals doesn't mean it was for nothing. The votes themselves need to be secure in a way the reveals do not. There is no double-vote issue with reveals, they can freely disseminated by any means. A more complete set of reveals would always give more information, and two partial sets could easily reconciled
11:49 < sipa> how do you solve coercion?
11:50 < CubicEarths> like a miner demanding a (at least private) reveal before being willing to include the vote?
11:50 < CubicEarths> that kind of coercion?
11:51 < sipa> no, someone that holds a gun to your head and says prove to me you voted for the right thing or i shoot you
11:51 < sipa> paper ballots are secure against this by not allowing others insode the booth
11:52 < Alanius> well, unless they take a picture of the ballot
11:52 < Alanius> the voters I mean
11:52 < sipa> good digital voting schemes also protect against this by only revealing the tally, and not the individual votes
11:52 < sipa> (under some assumptions)
11:53 < sipa> Alanius: make a picture, and go ask for a new paper
11:53 < esotericnonsense> ^ i'm not sure this is possible in the UK
11:53 < sipa> or at the very least you can afterwards invalidate your vote by marking two canfidates
11:53 < esotericnonsense> at least you'd have to show them the old paper that's ruined or whatever. otherwise you vote twice right.
11:53 < esotericnonsense> yeah
11:54 < sipa> and it doesn't need to be a gun; it also prevents people from being paid to vote
11:55 < esotericnonsense> i find all digital voting schemes a solution in search of a problem. it would make sense in the context of extremely frequent (relative to now) national votes. otherwise it just seems like automation for the sake of it.
11:56 < Alanius> the big benefit is universal verifiability
11:57 < CubicEarths> sipa: There are so many facets here, I think we are getting too meta, especially jumping right to the gun-to-head scenario. The gun-to-head problem transcends most things in life :(
11:57 < esotericnonsense> it seems to me that the problem of zero-knowledge verifiability in the context of a polling booth is intractable
11:58 < esotericnonsense> so you get a slip which allows you to verify inclusion in the voting set, without being able to prove you voted one way or another
11:58 < Alanius> there are clever attempts that do that
11:58 < esotericnonsense> but you need to prove at least to yourself, that you voted the way you voted (i.e. that the machine did not cheat you)
11:58 < esotericnonsense> how do you do the latter without showing it to everyone else, on hardware that is not your own / untrusted ?
11:59 < sipa> CubicEarths: it's a well established property of existing voting systems
12:00 < sipa> CubicEarths: the whole use a blockchain rah rah seems to ignore that
12:00 < esotericnonsense> basically, in the existing system you have an ephemeral proof to yourself that at least you entered the correct vote to begin with (it could be counted wrongly or ripped up or whatever)
12:01 < sipa> i guess i'm also generally skeptical about electronic voting in the first place
12:01 < esotericnonsense> i don't know how a machine can provide an ephemeral proof that when you press the button 'esotericnonsense' it doesn't behind the scenes substitute it for 'alanius'
12:01 < esotericnonsense> (if it's permanent, coercion)
12:01 < sipa> CubicEarths: as i said, no need for such an extreme context - it mostly prevents being paid to vote a certain way
12:02 < sipa> CubicEarths: though i guess if you want a coin-weighted vote that doesn't really matter
12:02 < CubicEarths> In most places in the US, there are vote-by-mail options...
12:02 < esotericnonsense> CubicEarths: same in the uk. i
12:02 < esotericnonsense> i'd argue this only works because we know it's limited.
12:02 < esotericnonsense> same for proxy votes
12:02 < CubicEarths> In a few US states, such as Washington, the votes are 100% by mail
12:03  * esotericnonsense wat.
12:03 < CubicEarths> okay, 99%
12:03 < esotericnonsense> i mean i can actualy send someone instead of me to vote for me. so buying votes is trivial. but it's trivial in the same way that many illegal things are trivial
12:03 < esotericnonsense> actually*
12:05 < Alanius> esotericnonsense: have a look at Prêt-à-Voter
12:07 < CubicEarths> sipa: There are so many complexities here, I think looking at what it takes to have a secure coin-weighted system is the place to start
12:08 < CubicEarths> Opinion may well differ on what such a system would be good for... and what it is good for will depend on exactly how it is constructed...
12:08 -!- Experiencecoin [ac590393@gateway/web/freenode/ip.172.89.3.147] has joined #bitcoin-wizards
12:08 < Experiencecoin> Hey guys, we are looking for a one or two blockchain developers to join our project. http://experiencecoin.org. We are currently a team of 4 people, and we are looking to expand to 6-7. Anyone interested in learning more?
12:10 < kanzure> nobody will ever be interested now that you have spammed.
12:10 < esotericnonsense> Alanius: seems like there's a trusted setup there
12:10 < esotericnonsense> Alanius: it states that the machine does not learn the ordering, but the machine learns the unique code, which is linked to the ordering, so if someone saved all of those it breaks
12:11 < Alanius> I agree with that conclusion, but you didn't say a trust-free setup was a requirement ;)
12:11 < esotericnonsense> haha. sure :P
12:12 < sipa> CubicEarths: but you can do a coin-weighted vote too where the actual voting doesn't use the chain
12:14 < Experiencecoin> join #bitcoin-dev
12:14 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-wizards
12:18 < CubicEarths> sipa: It is true
12:18 < CubicEarths> socially though, communities are already oriented around their chain as a source of authority
12:19 < CubicEarths> or at least as a source of accurate record keeping
12:19 < Alanius> I think it makes sense to authenticate the bulletin board, so as to guarantee that everyone sees the same set of ballots
12:23 < CubicEarths> voting is interesting because it starts from the premise of being inclusive, of *wanting* to know what people think and prefer.
12:25 < CubicEarths> Absolutely important to have a method to agree on ballot and authenticate ahead of time
12:29 < musalbas> If federated peg based sidechains were implemented on a blockchain that supported smart contracts, could we remove reliance on the federation being honest, by allowing the smart contract managing locked funds to only release funds if no fraud proofs were shown after X blocks?
12:30 < musalbas> That way, if a federation was being malicious by withholding block data availability to thwart fraud proofs, they'd have to maintain the attack for a long period of time
12:32 < andytoshi> the bulk of https://blockstream.com/sidechains.pdf discusses this
12:33 < andytoshi> the answer is that "X" parameterizes the extent to which majority hashpower is being trusted, so you have to decide whether there are any sensible values for X for which this would be better than a federation .. which then depends on your design goals
12:34 < andytoshi> also, BTW, bitcoin does support smart contracts, just not sufficiently expressive ones that you could check fraud proofs of other chains in them
12:34 < andytoshi> see also line 485 of that paper which discusses SNARKs
12:35 -!- nuke_bloodaxe [~nuke_bloo@101.100.144.170] has joined #bitcoin-wizards
12:37 < CubicEarths> andytoshi: Is the idea that 'trusting a majority of hashpower' for sidechains is worse than the trust the is extended in the managing of the regular chain because Bitcoin full nodes validate everything on the main chain, but they wouldn't be holding the miners accountable for sidechain accuracy?
12:39 < andytoshi> CubicEarths: yeah
12:39 < andytoshi> that's essentially what makes a sidechain a sidechain
12:39 < andytoshi> vs an extension block
12:39 < musalbas> Thanks. I was thinking of more than SPV reorganisation proofs though, which assume that the majority of the hashpower is honest, no? I was thinking that if the majority of the hashpower is dishonest, you could have SPV fraud proofs that prove some transaction was invalid (non-existent outputs, etc) - so the security of the sidechain would be extended to somehting similar to a full node
12:39 < musalbas> s/SPV fraud proof/fraud proof/
12:40 < andytoshi> if you're assuming majority hashpower is honest, you don't have anything resembling full-node security
12:40 < musalbas> exactly - so I'm saying if you use fraud proofs, then you don't have to assume that the majority hashpower is honest anymore
12:40 < musalbas> since you can get fraud proofs of transactions being invalid
12:40 < andytoshi> you do because miners have the ability to censor fraud proofs
12:41 < andytoshi> what does "invalid" mean
12:41 < musalbas> e.g. a tx that points to a non-existent transactions inputs (you can efficiently prove that a tx input doesn't exist using sparse merkle trees)
12:42 < musalbas> how can miners censor fraud proofs? whoever has them just submits them to the smart contract during a contestion period
12:42 < andytoshi> …
12:42 < andytoshi> what does "submits them to the smart contract" mean?
12:42 < sipa> miners can just not include the fraud proofs in the chain
12:42 < musalbas> the sidechain miners, or the mainchain miners?
12:42 < andytoshi> whichever blockchain is being used to for proof-of-pub of the fraud proofs
12:43 < sipa> i assume you're talking about the situation where a transfer back from thr sidechain to the main chain is contestable
12:43 < musalbas> yes
12:43 < sipa> so it is mainchain nkdes that need to see the fraud proof that the transfer was invalid
12:43 < sipa> so the mainchain miners can censor that fraud proof
12:43 < sipa> now mainchain nodes can't know it was invalid
12:44 < musalbas> That's assuming that there's a 51% attack on the mainchain?
12:44 < sipa> yes
12:44 < musalbas> that seems reasonable
12:44 < sipa> i don't agree
12:44 < musalbas> you're relying on 51% of mainchain to be honest, but not 51% of sidechain
12:44 < andytoshi> musalbas: the issue is that this 51% attack allows miners to take all of the coins on the sidechain
12:44 < sipa> but i don't want to rely on a hashrate majority to be honest
12:44 < sipa> anywhete
12:45 < andytoshi> which is way different than any existing vulnerability to 51%
12:45 < musalbas> hmm
12:45 < sipa> the reason we assume 51% is honest is exactly because of full node security - which makes it unprofitable to perform such an attack
12:45 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
12:46 < sipa> if you remove full node security, it becomes much harder to argue why 51% is going to be honest
12:46 < musalbas> sure, but if you assume that anyway in the sidechain paper, surely it would be stronger to assume that 51% of the mainchain is honest rather than the sidechain?
12:46 -!- circ-user-cTpdh [~circuser-@ool-4350bb0a.dyn.optonline.net] has joined #bitcoin-wizards
12:46 < sipa> i don't think sidechains (with spv proofs) are something people should want or use
12:47 < musalbas> but if people are going to use them anyway... might as well make them stronger? :p
12:47 < sipa> that paper was written in the context of dozens of altcoins popping up that claimed to need a new currency in order to experiment with new technology
12:47 < sipa> our paper showed that a construction was possible that doesn't need that
12:48 < sipa> without full node security i don't think they're something people should use
12:48 < sipa> as a production syste.
12:48 < musalbas> do you agree though that it would be better to assume that 51% of the mainchain is honest rather than the sidechain?
12:48 < sipa> i'm not sure there is much of a difference
12:49 < musalbas> If the mainchain has most of the hashing power, it allows people to create sidechains with very little hashingpower to test new features, while having the security of the mainchain
12:49 < andytoshi> well, in fairness in the sidechain paper you have to assume _both_ sets of miners are honest
12:49 < sipa> stop saying "security of the mainchain"
12:49 < musalbas> what should I say?
12:49 < andytoshi> so yes, eliminating trust in the sidechain miners is strictly an improvement. but i agree with sipa that it's not a useful one
12:49 < sipa> you don't have full node security; you can't argue that it's anyway comparable
12:50 < musalbas> okay, I mean hashing power of the main chain then
12:50 -!- circ-user-cTpdh [~circuser-@ool-4350bb0a.dyn.optonline.net] has quit [Ping timeout: 245 seconds]
12:50 < andytoshi> i also think that any future opcodes that'd allow sufficiently strong fraud proof verification could just be used directly to prove the sidechain rules, SNARK style
12:50 < sipa> sure, but that power can be used for good or for bad
12:52 < sipa> yes, things would fundamentally change if we had feasible compact proofs of full sidechain rule validity on the mainchain
12:52 -!- roconnor_ [~roconnor@host-192.252-166-159.dyn.295.ca] has quit [Ping timeout: 260 seconds]
12:52 < sipa> where you had to prove the entire history of the chain you're moving back from was valid - not just its hashrate was good enough
12:57 < musalbas> it could be argue that if you assume that if the data of blocks is always available to the network and not just the headers (*big* assumption), and your SPV node is not eclipsed, and there's at least one honest full node producing fraud proofs, then your SPV node has almost full node security
12:58 < musalbas> but of course, the first assumption doesn't hold
13:03 < sipa> yes, if you rely on strong censorshipfreeness properties, all kinds of things become possible
13:03 < sipa> like not needing a blockchain :)
13:05 < CubicEarths> sipa: are the compact proofs you are referring to, are these what you feel would be needed to effectively implement a plasma like system on Bitcoin?
13:05 < musalbas> well, the issue boils down to proof of block data being available... which the easiest way to do is download and redistribute a copy of the data yourself. That would at least make the scaling bottleneck of the network be network connectivity, rather than CPU/RAM/storage
13:05 < kanzure> musalbas: the problem with fraud proofs is that fraud-makers have no reason to give you enough information to prove fraud (information withholding problem)
13:05 < musalbas> kanzure, yes, that's what I mean by 'if you assume that if the data of blocks is always available to the network and not just the headers (*big* assumption)'
13:06 < musalbas> There's also a weird data availability proof scheme here I don't fully understand
13:06 < musalbas> .title https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding
13:06 < yoleaux> A note on data availability and erasure coding · ethereum/research Wiki · GitHub
13:07 < kanzure> my point was that it's not just a question of including fraud proofs into a blockchain
13:07 < musalbas> kanzure, I know, you're talking about miners not publishing the whole block
13:07 < kanzure> yes fraud proofs can be censored but it is bad to assume that fraud proof construction is possible if you do not have a requirement on everyone having all the data
13:09 < sipa> CubicEarths: i mean things like SNARKs or STARKs or Bulletproofs ... i don't know about plasma
13:10 < sipa> (none of these are feasible today to create full chain security proofs)
13:10 < kanzure> full chain security should only require a circuit with, what, 200 gates?
13:10 < sipa> ?
13:10 < kanzure> 200 gate constructions should fit into bulletproofs reasonably well. but i'm kidding; i know that's not enough.
13:11 < sipa> just SHA256 is 25000 gates :)
13:11 < Alanius> at what point can you bootstrap? I.e., present a proof that you correctly verified another proof and one additional operation
13:11 < sipa> Alanius: recursive proofs :)
13:12 < sipa> give a proof that you know a secret proof which you ran the validation algorithm for
13:12 < Alanius> exactly
13:12 < sipa> downside: proving is hard
13:13 < musalbas> sipa, btw isn't the miners censoring fraud proofs thing also applicable to payment channels? miners can censor transactions to close channels, causing problems
13:13 -!- daszorz [~daszorz@cpc106809-live29-2-0-cust896.17-2.cable.virginm.net] has quit [Read error: Connection reset by peer]
13:13 < andytoshi> with BPs there is never any benefit to bootstrapping AFAICT
13:13 < andytoshi> it's always faster to verify a BP than to verify a BP of a BP
13:14 < sipa> musalbas: yes, asolutely
13:14 < sipa> payment channels add extra security assumptions
13:14 < musalbas> why would sidechains be bad but not payment channels then? or do you disapprove of payment channels too?
13:15 < kanzure> payment channels do not require miners to validate sidechains...
13:15 < andytoshi> payment channels have only two participants per channel
13:15 < sipa> i disapprove of payment channels being lauded as a solution to everything
13:15 < andytoshi> also with taproot+scriptless script you can make payment channels usually look indistinguishable from other payments
13:15 < mryandao> taproot?
13:16 < kanzure> this seems like a vocabulary problem.   it would be nice to have named sidechains as something that made the security model more explicit.
13:16 < andytoshi> mryandao: https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg06673.html
13:17 < mryandao> andytoshi: thanks.
13:17 < musalbas> kanzure, it doesn't matter, it's the same as the relying-on-51%-mainchain-being-honest assumption I described above for sidechain fraud proofs
13:17 < sipa> musalbas: at least one difference is that i don't believe a widespread deployment of sidechains is possible that doesn't effectively require everyone to participate in all chains
13:17 < kanzure> bitcoin full nodes do not make an honesty assumption like that
13:17 < kanzure> the assumption that the software makes is much more restricted
13:17 < sipa> where payment channels effectively move much of the work actually to just the participants
13:18 < sipa> rather than just to another chain
13:18 < musalbas> kanzure, i know, see from 20:29 :)
13:18 -!- CubicEarths [~cubiceart@73.93.141.136] has quit [Remote host closed the connection]
13:18 < andytoshi> kanzure: i think that a many-party payment channel could sensibly be called a sidechain
13:18 < andytoshi> where every participant has to sign off on each state update
13:19 < sipa> yup, but it's more like a federated chain model than a hashrate-based one
13:19 < musalbas> andytoshi, yeah, we have something like that in a paper we just wrote (https://arxiv.org/abs/1802.07344), and called them 'sidechains' even though there's no chain involved, due to a lack of better vocabulary
13:19 < andytoshi> yep exactly
13:19 < sipa> the participants themselves are the "miners" for this new chain/channel
13:19 < sipa> rather than anonymous parties that just happen to have the right ASICs
13:19 < kanzure> sipa: in practice, i think people are going to call things sidechains that have really wacky/poor security models especially where not all bitcoin participants are validating the sidechain...
13:19 -!- ramajama [ac624fc6@gateway/web/freenode/ip.172.98.79.198] has quit [Ping timeout: 260 seconds]
13:20 < sipa> kanzure: yes, and that was the goal!
13:20 < musalbas> I wanted to called them 'sidechannels', but that sounds to similar to sidechannel attacks.
13:20 < musalbas> too*
13:20 < kanzure> sipa: elaborate?
13:20 < sipa> kanzure: if we expect everyone to verify a particular sidechain, you should do it as an extension block instead
13:20 < sipa> the whole point of a sidechain is that not everyone has to validate
13:20 < andytoshi> kanzure: the word 'sidechain' was deliberately super general, and the goal of sidechains was to allow experimentation with all sorts of things, including shitty trust models
13:20 < sipa> the downsdie of course is that not everyone validates!
13:21 < kanzure> if not everyone has to validate, then why so many "trust the miners to not steal coins" proposals? why not just fedpeg?
13:21 < sipa> what andytoshi just said :)
13:21 < andytoshi> because "trust the miners" is strictly different from "trust the federation" :P
13:21 < mryandao> isnt it also a requirement that coins can safely move from a "shit trust model" to the bitcoin trust model?
13:22 < kanzure> "trust the miners" isn't really what you're doing in bitcoin though. and adding these other things to their 'buden' increases security exposure problem.
13:22 < sipa> and also, sidechains are optional - which is great for experimentation
13:22 < sipa> they insulate the risk from the mainchain
13:22 < sipa> but only when their usage is negligable
13:23 < kanzure> they are optional to bitcoiners but i think some sidechain proposals seem to require bitcoin miners to behave and run some code and watch stuff.
13:23 < musalbas> <andytoshi> payment channels have only two participants per channel < are you saying that's good because that means any damage is limited to two participants?
13:24 -!- spinza [~spin@196.212.164.26] has quit [Ping timeout: 256 seconds]
13:24 < andytoshi> musalbas: yes, only two participants who both agree on the maximum possible loss under what circumstances (and they can only rob each other, miners can't rob them, at least if neither drops out)
13:24 < andytoshi> err "miners can't rob them except with cooperation of one of the parties"
13:25 < musalbas> well, where do you draw the line? what if we had sidechains with 5 participants, or 10 participants? could be some kind of sidechains that supported trustless tumbling, or something
13:25 < andytoshi> and with 2-party schemes it's way easier to coordinate the cooperative-close case, in which miners can't even distinguish closing txes from any other tx
13:25 < sipa> musalbas: if those participants are known and fixed you can just use a federation
13:25 < andytoshi> where do i draw what line?
13:26 < musalbas> '2' seems like an arbitrary number (except for your latter point about distinguishing closing txes from other txes)
13:26 < sipa> yes, but none of the arguments apply here to federated sidechains
13:27 < sipa> only to those relying on PoW
13:28 < andytoshi> musalbas: 2 is a special number. with 2 participants, every participant is interested in every state change so having a N-of-N threshold does not allow any disinterested parties to cause holdup
13:28 < musalbas> sipa, true re: federation (that's what we basically did in the paper i linked)
13:28 < andytoshi> it also makes things like scriptless scripts possible
13:33 -!- d9b4bef9 [~d9b4bef9@207.38.94.106] has quit [Remote host closed the connection]
13:34 -!- d9b4bef9 [~d9b4bef9@207.38.94.106] has joined #bitcoin-wizards
13:34 -!- spinza [~spin@196.212.164.26] has joined #bitcoin-wizards
13:35 < aj> andytoshi: "third wheel" should be the technical term for someone with an N-of-N threshold who's not interested in a particular update...
13:35 < musalbas> hmm. perhaps in some use cases it might be OK to take the risk of allowing disinterested parties to cause holdup (shittier security model). Assume a sidechain with 500 participants, but 1 node mining blocks (effectively centralised), with the fraud proofs, the centralised node can cause everyone to lose their funds by holding things up, but not steal money
13:37 < andytoshi> right, in a federated sidechain (unlike a payment channel) the set of custodians does not need to be the same as the set of people signing state updates
13:42 -!- Experiencecoin [ac590393@gateway/web/freenode/ip.172.89.3.147] has quit [Quit: Page closed]
14:00 -!- Guest59762 is now known as aem
14:03 -!- jb55 [~jb55@2605:8d80:4c2:4024:a2af:bdff:fef0:c102] has joined #bitcoin-wizards
14:09 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
14:11 -!- circ-user-cTpdh [~circuser-@ool-4350bb0a.dyn.optonline.net] has joined #bitcoin-wizards
14:19 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
14:21 -!- harrymm [~harrymm@104.207.83.8] has quit []
14:32 -!- DougieBot5000_ is now known as DougieBot5000
14:40 -!- Giszmo [~leo@ip-101-233.219.201.nextelmovil.cl] has joined #bitcoin-wizards
14:41 -!- Giszmo [~leo@ip-101-233.219.201.nextelmovil.cl] has quit [Client Quit]
14:41 -!- eklitzke [~evan@fsf/member/eck] has quit [Quit: bye]
14:42 -!- eklitzke [~evan@fsf/member/eck] has joined #bitcoin-wizards
14:44 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
14:55 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Ping timeout: 252 seconds]
15:07 -!- Giszmo [~leo@ip-101-233.219.201.nextelmovil.cl] has joined #bitcoin-wizards
15:07 -!- Giszmo [~leo@ip-101-233.219.201.nextelmovil.cl] has quit [Client Quit]
15:07 -!- Giszmo [~leo@ip-101-233.219.201.nextelmovil.cl] has joined #bitcoin-wizards
15:08 -!- Giszmo [~leo@ip-101-233.219.201.nextelmovil.cl] has quit [Client Quit]
15:08 -!- Giszmo [~leo@ip-101-233.219.201.nextelmovil.cl] has joined #bitcoin-wizards
15:09 -!- Giszmo [~leo@ip-101-233.219.201.nextelmovil.cl] has quit [Client Quit]
15:10 -!- jb55 [~jb55@2605:8d80:4c2:4024:a2af:bdff:fef0:c102] has quit [Ping timeout: 252 seconds]
15:11 -!- Giszmo [~leo@ip-101-233.219.201.nextelmovil.cl] has joined #bitcoin-wizards
15:12 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
15:21 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
15:45 -!- AaronvanW_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
15:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
15:50 -!- JC_acct [~JC_acct@45-172-16-94.dyn.cable.fcom.ch] has joined #bitcoin-wizards
15:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds]
15:52 -!- digi_james [~JC_acct@45-172-16-94.dyn.cable.fcom.ch] has quit [Ping timeout: 260 seconds]
15:53 -!- dnaleor [~dnaleor@host-im1adb.cbn1.zeelandnet.nl] has joined #bitcoin-wizards
15:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
15:55 -!- Giszmo [~leo@ip-101-233.219.201.nextelmovil.cl] has quit [Quit: Leaving.]
15:58 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Quit: Snoozing.]
15:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
16:00 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Remote host closed the connection]
16:00 -!- weez17 [~isaac@unaffiliated/weez17] has joined #bitcoin-wizards
16:33 -!- marxS [a9e52419@gateway/web/freenode/ip.169.229.36.25] has joined #bitcoin-wizards
16:33 < marxS> Hey
16:34 < marxS> Has there been any real research into the use of aggregate signatures in blocks?
16:34 < marxS> From rough sketches, I get that it'd result in close 100x tx throughput
16:46 -!- dnaleor [~dnaleor@host-im1adb.cbn1.zeelandnet.nl] has quit [Ping timeout: 252 seconds]
16:48 -!- dnaleor [~dnaleor@host-im1adb.cbn1.zeelandnet.nl] has joined #bitcoin-wizards
16:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
16:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
17:02 -!- circ-user-cTpdh [~circuser-@ool-4350bb0a.dyn.optonline.net] has quit [Ping timeout: 245 seconds]
17:05 -!- marxS [a9e52419@gateway/web/freenode/ip.169.229.36.25] has quit [Quit: Page closed]
17:17 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-wizards
17:19 -!- circ-user-cTpdh [~circuser-@ool-4350bb0a.dyn.optonline.net] has joined #bitcoin-wizards
17:30 -!- Belkaar [~Belkaar@unaffiliated/belkaar] has quit [Ping timeout: 252 seconds]
17:30 -!- Belkaar [~Belkaar@xdsl-81-173-178-112.netcologne.de] has joined #bitcoin-wizards
17:30 -!- Belkaar [~Belkaar@xdsl-81-173-178-112.netcologne.de] has quit [Changing host]
17:30 -!- Belkaar [~Belkaar@unaffiliated/belkaar] has joined #bitcoin-wizards
17:39 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
17:43 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-arwwkmkvoqqugmhk] has quit [Quit: Connection closed for inactivity]
17:44 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #bitcoin-wizards []
17:49 -!- JC_acct [~JC_acct@45-172-16-94.dyn.cable.fcom.ch] has quit [Ping timeout: 256 seconds]
17:50 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-wizards
17:53 -!- JC_acct [~JC_acct@45-172-16-94.dyn.cable.fcom.ch] has joined #bitcoin-wizards
18:09 -!- Giszmo [~leo@ip-58-233.219.201.nextelmovil.cl] has joined #bitcoin-wizards
18:19 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-zolrpsqgtcsdrcif] has joined #bitcoin-wizards
18:35 -!- nuncanada [~dude@187.65.68.254] has quit [Read error: Connection reset by peer]
18:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
19:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]
19:12 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Ping timeout: 256 seconds]
19:17 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
19:26 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 256 seconds]
20:05 -!- Giszmo [~leo@ip-58-233.219.201.nextelmovil.cl] has quit [Quit: Leaving.]
20:09 -!- itsme__ [~textual@x4d04cac4.dyn.telefonica.de] has joined #bitcoin-wizards
20:44 -!- satwo [~textual@2602:306:378a:6fb0:b505:7876:d1a:a886] has joined #bitcoin-wizards
20:49 -!- nuke_bloodaxe [~nuke_bloo@101.100.144.170] has quit [Remote host closed the connection]
20:50 -!- nuke_bloodaxe [~nuke_bloo@101.100.144.170] has joined #bitcoin-wizards
20:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
21:00 -!- legogris [~legogris@128.199.205.238] has quit [Remote host closed the connection]
21:00 -!- legogris [~legogris@128.199.205.238] has joined #bitcoin-wizards
21:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
21:03 -!- cryptojanitor [uid278088@gateway/web/irccloud.com/x-ntngjvdchwthdvio] has quit [Quit: Connection closed for inactivity]
21:17 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-wizards
21:31 -!- abomb [~abomb@node-1w7jra20l6y293cvy7e6vb4ko.ipv6.telus.net] has quit [Remote host closed the connection]
21:33 -!- abomb [~abomb@node-1w7jra20l6y293cvy7e6vb4ko.ipv6.telus.net] has joined #bitcoin-wizards
21:34 -!- abomb [~abomb@node-1w7jra20l6y293cvy7e6vb4ko.ipv6.telus.net] has quit [Remote host closed the connection]
21:35 -!- abomb [~abomb@node-1w7jra20l6y293cvy7e6vb4ko.ipv6.telus.net] has joined #bitcoin-wizards
21:35 -!- satwo [~textual@2602:306:378a:6fb0:b505:7876:d1a:a886] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
21:42 -!- CubicEarths [~cubiceart@73.93.142.144] has joined #bitcoin-wizards
21:46 -!- circ-user-cTpdh [~circuser-@ool-4350bb0a.dyn.optonline.net] has quit [Ping timeout: 248 seconds]
21:51 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Quit: Snoozing.]
21:56 -!- itsme__ [~textual@x4d04cac4.dyn.telefonica.de] has quit [Quit: Textual IRC Client: www.textualapp.com]
21:57 -!- satwo [~textual@2602:306:378a:6fb0:2585:126e:b9da:f297] has joined #bitcoin-wizards
22:00 -!- shpx [~shpx@unaffiliated/shpx] has joined #bitcoin-wizards
22:08 -!- satwo [~textual@2602:306:378a:6fb0:2585:126e:b9da:f297] has quit [Ping timeout: 245 seconds]
22:19 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
22:23 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-wizards
22:27 -!- bramc [40191be0@gateway/web/freenode/ip.64.25.27.224] has joined #bitcoin-wizards
22:27 < bramc> Hey everybody
22:31 -!- bsm117532 [~mcelrath@c-65-96-61-129.hsd1.ma.comcast.net] has quit [Quit: Leaving.]
22:37 < bramc> I have some thoughts on how script merkleization could be added to Bitcoin 'the easy way'
22:38 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has quit [Ping timeout: 276 seconds]
22:46 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has joined #bitcoin-wizards
22:52 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Quit: Snoozing.]
23:09 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Ping timeout: 256 seconds]
23:10 -!- bramc [40191be0@gateway/web/freenode/ip.64.25.27.224] has quit [Ping timeout: 260 seconds]
23:31 -!- douglas_ [~douglas@c-73-234-93-65.hsd1.nh.comcast.net] has quit [Ping timeout: 240 seconds]
23:32 -!- bramc [40191be0@gateway/web/freenode/ip.64.25.27.224] has joined #bitcoin-wizards
23:47 -!- harrymm [~harrymm@104.207.83.11] has joined #bitcoin-wizards
23:59 -!- cato_ [~cato@unaffiliated/cato/x-3294757] has joined #bitcoin-wizards
23:59 -!- CubicEarths [~cubiceart@73.93.142.144] has quit [Remote host closed the connection]
--- Log closed Mon Feb 26 00:00:03 2018