--- Log opened Tue Jun 16 00:00:43 2015 00:03 -!- Mably [56401ec3@gateway/web/freenode/ip.86.64.30.195] has joined #bitcoin-wizards 00:04 -!- hktud0 [~ncidsk@unaffiliated/fluffybunny] has quit [Read error: Connection reset by peer] 00:05 -!- _biO_ [~biO_@ip-37-24-195-112.hsi14.unitymediagroup.de] has quit [Read error: Connection reset by peer] 00:06 -!- hktud0 [wq@unaffiliated/fluffybunny] has joined #bitcoin-wizards 00:06 -!- jrayhawk [~jrayhawk@unaffiliated/jrayhawk] has quit [Ping timeout: 265 seconds] 00:08 -!- jrayhawk [~jrayhawk@unaffiliated/jrayhawk] has joined #bitcoin-wizards 00:10 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 00:21 -!- antanst [~Adium@ppp-2-86-206-246.home.otenet.gr] has joined #bitcoin-wizards 00:21 -!- antanst [~Adium@ppp-2-86-206-246.home.otenet.gr] has left #bitcoin-wizards [] 00:23 -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards 00:24 < weex> theymos: phantomcircuit do dns seeds do that sort of checking of nodes they're advertising? 00:24 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 00:24 <@gmaxwell> weex: sipa's DNS seed (and other seeds running his software) perform some limit tests. 00:25 < weex> my other question is what does an spv node do when post-fork it ends up on the other side, rebuild from genesis block or just get all inconsistent with itself 00:26 <@gmaxwell> I don't understand the question, where do you think an inconsistency is coming from? 00:26 < weex> first of all i don't know how it handles peers that are different forks 00:26 -!- b_lumenkraft [~b_lumenkr@unaffiliated/b-lumenkraft/x-4457406] has joined #bitcoin-wizards 00:27 < weex> does it drop the minority or the ones that disagree with what it stored as its best block 00:27 <@gmaxwell> SPV nodes follow the chain with the most apparent proof of work. 00:27 <@gmaxwell> Number of peers is irrelevant unless you're partitioned. 00:28 < weex> most apparent being highest difficulty? 00:28 < theymos> weex: AFAIK none of the DNS seeds do any in-depth checks. I think they'd include hardforking XT nodes, for example. 00:29 <@gmaxwell> weex: the most work. Not highest difficulty, if you just mean difficulty at the tip. The sum of difficulty of the blocks. Perhaps #bitcoin for basics questions. :) 00:30 < weex> heh, ok...i was just trying to figure out how the world of coffees might be affected by this proposed hard fork 00:30 -!- justanot1erusr [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 244 seconds] 00:31 < weex> i imagine a lot of code doesn't assume this kind of thing might happen so lots of conjecture is to be expected 00:31 -!- JackH [~Jack@host-80-43-142-154.as13285.net] has joined #bitcoin-wizards 00:32 -!- Sub|afk [~SubCreati@2601:601:400:1f04:ad8a:bb10:3b9b:d2a7] has quit [Ping timeout: 256 seconds] 00:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 264 seconds] 00:38 < theymos> Peer discovery is something I've been thinking about for a while. I feel like Bitcoin Core should maintain more info about past peers and try to always connect to a few that seem long-term-reliable/trustworthy (in addition to some newer ones), and this data should also be used for the DNS seeds. 00:39 < theymos> I suppose it's difficult to do this in a way that wouldn't make things even easier for a patient Sybil attacker. But the current way of mostly connecting to "fresh" peers doesn't seem very solid. 00:41 <@gmaxwell> theymos: it does. it maintains two tables, one of peers that have proven functional in the past; and one for the rest. If a peer is evicted from the first list it goes into the second. Obviously it could do more health testing of the first, but the gain from doing so may not be big since peers are not authenticated. 00:41 -!- go1111111 [~go1111111@162.244.138.37] has quit [Read error: Connection reset by peer] 00:41 <@gmaxwell> theymos: its initial connections are to old peers, not fresh ones. (also in current versions it won't DNS seed probe at all if it successfully gets connected fast enough) 00:44 < theymos> I know a little about the current mechanism, but it seems too simple. I don't have any testing supporting this, but I worry that it's too easy for you to fill up your tested-good table with relatively bad peers and evict excellent peers. I was thinking that it should maintain a score for peers, so peers would be considered a lot more trustworthy/valuable if they were the first peer to relay a ne 00:44 < theymos> w block to you, for example. I guess authentication would be necessary for this to be useful long-term. 00:45 <@gmaxwell> theymos: tested good table can't be replaced, they can just age out by not working. 00:45 <@gmaxwell> (thats something that was changed somewhat recently) 00:45 -!- _biO_ [~biO_@80.156.183.43] has joined #bitcoin-wizards 00:45 < theymos> oh, cool! 00:46 <@gmaxwell> (in response to an academic paper that presented some attacks against the scheme.. some we knew about, some that were new) 00:46 -!- gill3s [~gill3s@pat35-3-82-245-143-153.fbx.proxad.net] has joined #bitcoin-wizards 00:47 <@gmaxwell> right now the biggest problems with it, I think, are that its awfully slow to try more peers, and also learns nothing about the network once it's already connected up (e.g. no connection probing/rotation) 00:47 -!- JackH [~Jack@host-80-43-142-154.as13285.net] has quit [Ping timeout: 240 seconds] 00:52 < theymos> Yeah, probing/rotation would probably be good. Only one of your peers needs to be honest, so there's a lot of room for connecting to possibly-untrustworthy peers. I feel like there's a ton of network data that Core could be collecting (but isn't) to ensure that it has at least one good peer. 00:52 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 00:53 <@gmaxwell> theymos: the trick there is that you want the opposite behavior for wallet privacy. 00:54 <@gmaxwell> because you want to not connect to _any_ spy nodes. 00:54 <@gmaxwell> so then there are perhaps hybrid approaches where you have 4 long time consistent sockets which you never rotate and you do all your txn announcenet via those, and 4 that you rotate, and only take in txn via those... 00:55 <@gmaxwell> theymos: though if someone builds an out-of-band relayer using the new functionality for that in 0.11 perhaps thats less of an issue. 00:55 <@gmaxwell> but the fact that right now people are incentivized to setup socket sucking spy nodes is irritating. 00:56 <@gmaxwell> and there are several commercial players effectively attacking the network at varrious levels in order to gather information on users. 00:56 <@gmaxwell> (even if I were indifferent to user privacy, reducing the incentive to goof with the network would be good) 00:57 < theymos> It's pretty hard to protect against spying because you can never tell when a peer is spying. You pretty much have to use Tor, I guess. 00:57 < theymos> What do you think about including a high-latency mix network in Bitcoin? No commonly-used ones exist AFAIK. 00:58 <@gmaxwell> The non-existance problem is what I think is the main barrier. Wumpus added a feature so you can disable p2p broadcast of wallet txn with a switch. Then a seperate (not yet existing, could be external) process can go broadcast for you. 00:58 <@gmaxwell> e.g. over tor into a high latency mix network. 00:58 <@gmaxwell> I'd like to ship such a think in bitcoin core if it existed and was reasonable. 00:59 <@gmaxwell> high latency is relatively, some of the tor devs have been coauthors on papers about mixes where you can signal your desired latency... and even low latency traffic improves privacy for high latency traffic through the same relay. 00:59 -!- c0rw|zZz is now known as c0rw1n 01:00 -!- dEBRUYNE [~dEBRUYNE@239-196-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 01:01 <@gmaxwell> if the process is single hop you can largely prevent dos attacks by checking that the tx is valid, but if its multihop I dunno how to prevent dos. 01:01 <@gmaxwell> other than hashcash. 01:01 < theymos> The no-broadcast thing is a good feature. I was thinking of creating a little script that would accept email containing a tx and then broadcast it on the network. Then you could use the old mixmaster-type networks (are these networks still maintained anymore, though?). 01:02 -!- go1111111 [~go1111111@162.244.138.37] has joined #bitcoin-wizards 01:02 <@gmaxwell> theymos: Yes, exactly. I hoped that it would be a reasonable starter project for someone since they could fuss around with whatever programming tools they want. 01:03 -!- c0rw1n is now known as c0rw|away 01:03 <@gmaxwell> theymos: I don't know, they were kind of a couple years ago, the email exit points are always weak because they get harassment complaints. Thats one reason why a bitcoin centric service would be easier to maintain. 01:03 -!- andy-logbot [~bitcoin--@wpsoftware.net] has quit [Remote host closed the connection] 01:03 -!- andy-logbot [~bitcoin--@wpsoftware.net] has joined #bitcoin-wizards 01:03 * andy-logbot is logging 01:04 -!- b_lumenkraft [~b_lumenkr@unaffiliated/b-lumenkraft/x-4457406] has quit [Read error: Connection reset by peer] 01:06 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 265 seconds] 01:08 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 01:09 -!- sl01 [~sl01@li431-44.members.linode.com] has joined #bitcoin-wizards 01:09 < amiller> (in response to an academic paper that presented some attacks against the scheme.. some we knew about, some that were new) 01:10 < amiller> which ones? are there new papers out on this out I don't know about yet? 01:10 <@gmaxwell> Bitcoin eclipse attacks paper, lemme get you the cite. 01:10 -!- kgk [~kgk@76.14.85.43] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 01:10 <@gmaxwell> https://eprint.iacr.org/2015/263.pdf 01:10 < amiller> ok got it 01:15 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] 01:20 -!- n0n0_ [~n0n0___@x5f7696dc.dyn.telefonica.de] has joined #bitcoin-wizards 01:21 -!- dEBRUYNE [~dEBRUYNE@239-196-ftth.onsbrabantnet.nl] has quit [Ping timeout: 272 seconds] 01:22 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 01:23 -!- AaronvanW [~ewout@x55b28519.dyn.telefonica.de] has joined #bitcoin-wizards 01:23 -!- AaronvanW [~ewout@x55b28519.dyn.telefonica.de] has quit [Changing host] 01:23 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 01:27 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 01:29 -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-wizards 01:30 -!- wallet42 [~wallet42@85.100.40.253] has joined #bitcoin-wizards 01:43 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 01:45 -!- p15 [~p15@111.193.182.42] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 01:47 -!- JackH [~Jack@host81-154-202-222.range81-154.btcentralplus.com] has joined #bitcoin-wizards 02:07 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_] 02:11 -!- zebedee [~Neil@ae041057.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-wizards 02:11 -!- kyuupichan [~Neil@ae041057.dynamic.ppp.asahi-net.or.jp] has quit [Read error: Connection reset by peer] 02:11 -!- p15 [~p15@182.50.108.109] has joined #bitcoin-wizards 02:14 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds] 02:20 -!- Logicwax [~Logicwax@c-76-126-174-152.hsd1.ca.comcast.net] has joined #bitcoin-wizards 02:30 -!- GAit [~lnahum@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer] 02:31 -!- dEBRUYNE [~dEBRUYNE@239-196-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 02:32 -!- GAit [~lnahum@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards 02:46 -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [Ping timeout: 240 seconds] 02:47 -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards 03:02 -!- MrTratta [~MrTratta@2-228-102-98.ip191.fastwebnet.it] has quit [Ping timeout: 252 seconds] 03:07 -!- wallet42 [~wallet42@85.100.40.253] has quit [Quit: Leaving.] 03:11 -!- wallet42 [~wallet42@85.100.40.253] has joined #bitcoin-wizards 03:20 -!- wallet42 [~wallet42@85.100.40.253] has quit [Quit: Leaving.] 03:20 -!- wallet42 [~wallet42@85.100.40.253] has joined #bitcoin-wizards 03:23 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards 03:26 -!- wallet42 [~wallet42@85.100.40.253] has quit [Quit: Leaving.] 03:26 -!- wallet42 [~wallet42@85.100.40.253] has joined #bitcoin-wizards 03:35 -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has joined #bitcoin-wizards 03:38 -!- rustyn_ [~rustyn@unaffiliated/rustyn] has joined #bitcoin-wizards 03:38 -!- rustyn [~rustyn@unaffiliated/rustyn] has quit [Ping timeout: 264 seconds] 03:38 -!- rustyn_ is now known as rustyn 03:39 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 03:48 -!- metamarc [~snizysnaz@unaffiliated/agorist000] has quit [Read error: Connection reset by peer] 03:49 -!- metamarc [~snizysnaz@97.95.172.50] has joined #bitcoin-wizards 03:49 -!- metamarc [~snizysnaz@97.95.172.50] has quit [Changing host] 03:49 -!- metamarc [~snizysnaz@unaffiliated/agorist000] has joined #bitcoin-wizards 03:49 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 04:02 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:2d49:e35d:dbf8:2fed] has joined #bitcoin-wizards 04:07 -!- gill3s [~gill3s@pat35-3-82-245-143-153.fbx.proxad.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 04:07 -!- Crowley2k [~Crowley2k@93.113.62.93] has quit [Ping timeout: 244 seconds] 04:19 -!- dEBRUYNE [~dEBRUYNE@239-196-ftth.onsbrabantnet.nl] has quit [Ping timeout: 244 seconds] 04:19 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Remote host closed the connection] 04:20 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 04:24 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Ping timeout: 255 seconds] 04:26 -!- wallet42 [~wallet42@85.100.40.253] has quit [Quit: Leaving.] 04:30 -!- wallet42 [~wallet42@85.100.40.253] has joined #bitcoin-wizards 04:31 -!- wallet42 [~wallet42@85.100.40.253] has quit [Client Quit] 04:31 -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has joined #bitcoin-wizards 04:33 < midnightmagic> adam3us: fwiw, your writing is easy to read and calm. Thank you; the clarity of your posts is much appreciated. 04:33 -!- airbreather [~airbreath@d149-67-99-43.nap.wideopenwest.com] has quit [Remote host closed the connection] 04:41 -!- chmod755 [~chmod755@unaffiliated/chmod755] has joined #bitcoin-wizards 04:57 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 04:59 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 04:59 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 04:59 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 05:00 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 05:04 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Ping timeout: 250 seconds] 05:08 -!- damethos [~damethos@unaffiliated/damethos] has quit [Quit: Bye] 05:10 -!- p15 [~p15@182.50.108.109] has quit [Max SendQ exceeded] 05:11 -!- p15 [~p15@182.50.108.109] has joined #bitcoin-wizards 05:16 -!- GreenIsMyPepper [~GreenIsMy@altcoins.are-on-my.ignorelist.com] has quit [Ping timeout: 265 seconds] 05:16 -!- gill3s [~gill3s@pat35-3-82-245-143-153.fbx.proxad.net] has joined #bitcoin-wizards 05:18 -!- p15 [~p15@182.50.108.109] has quit [Max SendQ exceeded] 05:20 -!- p15 [~p15@182.50.108.109] has joined #bitcoin-wizards 05:22 -!- eudoxia [~eudoxia@r167-57-87-222.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards 05:24 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds] 05:27 -!- zebedee [~Neil@ae041057.dynamic.ppp.asahi-net.or.jp] has quit [Ping timeout: 240 seconds] 05:28 -!- kyuupichan [~Neil@ae041057.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-wizards 05:35 -!- MrTratta [~MrTratta@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-wizards 05:36 -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has quit [Ping timeout: 252 seconds] 05:40 < adam3us> midnightmagic: thanks. i try. here's hoping gavinandresen & Mike Hearn can be yet persuaded to abandon the unilateral fork and bypass of the code review and maintainership of bitcoin. 05:40 < adam3us> midnightmagic: its kind of ambiguous whats going to happen. 05:41 < gavinandresen> adam3us: stop with the FUD, please 05:41 < adam3us> but thanks to jgarzik for helping steer the conversation to a BIP review oriented approach. hopefully we'll have a few more BIPs and can review it in the context of a decentralisation plan also. 05:41 < gavinandresen> code has to be written before it can be reviewed 05:41 < adam3us> gavinandresen: pardon me? your clarification on the dev-list is welcome 05:42 < kanzure> gavinandresen: forcing a hard-fork is also FUD :-) 05:42 < gavinandresen> I'm busy writing code.... then I'll be busy writing a BIP.... 05:42 < kanzure> gavinandresen: you sent a nuclear email just last week; surely you remember this. "fuck you guys, i'm forking the network whether you like it or not" 05:42 < kanzure> (you used much better language though!) 05:42 < gavinandresen> kanzure: how do you think the tech should be governed? Council of Elders? 05:42 < kanzure> ((i would never imply that you have used poor language; i was paraphrasing in an uncharitable way)) 05:42 < adam3us> gavinandresen: thats is good. but the question clearly that concerns people would be that you submit that BIP for review beside Jeff's and other proposals, and publicly not support the unilateral hard fork threat that Mike is pushing 05:43 < gavinandresen> you have an odd definition of 'unilateral' 05:43 < gavinandresen> ... if supermajority of exchanges, merchants and miners is 'unilateral' then I'm not sure what to say 05:43 < kanzure> the question of governance here is completely irrelevant 05:43 < adam3us> gavinandresen: do you see anyone other than mike in here agreeing with you? 05:44 < gavinandresen> governance is completely relevant: is Bitcoin goverened by the code people choose to run, or is it / should it be governed in some other way? 05:44 < kanzure> false dichotomy 05:44 -!- prodatalab_ [~prodatala@78.sub-70-209-52.myvzw.com] has joined #bitcoin-wizards 05:44 < gavinandresen> I'll say again: I'm happy to get behind some other proposal that reaches rough consensus. I like Jeff's proposal... 05:45 < kanzure> does that mean you are no longer threatening the hard-fork? 05:45 < gavinandresen> But I won't just sit on my hands and do nothing about scaling up because how and when is controversial 05:45 < adam3us> gavinandresen: as you know bitcoin is very technical and so if the entire technical community is telling you a unilateral fork is dangerous, that should be concerning no? 05:46 < gavinandresen> again, you have a very odd definition of unilateral. I'm 82% sure I've described the rollout plan to you before, and it is NOT unilateral 05:47 < adam3us> gavinandresen: not to discount the desire of the merchants exchanges at CEO level etc but i doubt they know the details at the level to judge safety, and seem completely unaware of the review and code change governance process which is in place for security & integrity of the system. 05:48 -!- prodatalab [~prodatala@2602:306:ceef:a750:61aa:cc2f:860f:81c2] has quit [Ping timeout: 256 seconds] 05:48 < kanzure> yeah, if those people actually have judged safety in a strict and rigorous way then i think that would be FANTASTIC news that we should be spreading all over the place; "bitcoin ceos most technically oriented ever"-- that would be like the greatest news ever. 05:48 < kanzure> "it turns out that all of the bitcoin company owners are actually coq wizards" 05:48 < gavinandresen> ok... so what is unsafe about bigger blocks? 05:49 < adam3us> gavinandresen: i thought i covered all of these topics mostly in my post to bitcoin-dev. but do you acknowledge the consensus review process for security review? 05:49 < kanzure> gavinandresen: wrong question... what is unsafe about hard-forks? 05:49 < gavinandresen> adam3us: not if Peter Todd is involved. He loves to think up miners-dancing-on-the-head-of-a-pin attacks that will never ever happen in practice. 05:49 < adam3us> gavinandresen: there are multiple questions but that is not the issue. that kind of issue could be, and is being hashed out in the technical discussion eg with jgarik's BIP 05:49 -!- helo [~helo@unaffiliated/helo] has quit [Read error: Connection reset by peer] 05:50 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 05:50 < adam3us> gavinandresen: i think this is not just petertodd.. it seems to be every core dev and everyone else who has made significant number of patches. 05:50 < gavinandresen> really? I haven't seen any discussion of jgarzik's BIP, where has that been taking place? 05:50 < gavinandresen> (well, I saw the reddit discussion....) 05:50 -!- p15 [~p15@182.50.108.109] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 05:50 < kanzure> there was a bunch of discussion in #bitcoin-dev but i believe there were also emails? 05:51 < gavinandresen> If the safety argument is "hard forks are risky, therefore we can never do one" then... uhh... I dunno what to say. 05:51 < adam3us> gavinandresen: a number of people have been talking with him myself included (probably 6 or 7 technical people i think) 05:51 < adam3us> gavinandresen: that is a mischaracterisation 05:51 < gavinandresen> adam3us: great, so some secret Technical Council.... 05:51 < kanzure> if you misharacterize basic conversation like this, why would you not make the same mistakes with bitcoin consensus code -_- 05:51 < adam3us> gavinandresen: he's been updating his BIP with the changes he's considered 05:52 < adam3us> gavinandresen: its public. i think some of this discussion would be better on list. 05:52 < gavinandresen> yes, and I've been wondering where the discussion for that is coming from. 05:52 < adam3us> gavinandresen: so i agree with you there. 05:52 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 05:52 < adam3us> gavinandresen: discussion for what? 05:52 < kanzure> bip100 05:53 < gavinandresen> discussion for the changes to jgarzik's BIP. e.g. he suddenly went from 2MB to start to 1MB to start, I hadn't seen any discussion about that, have no idea what the reasoning was... 05:53 < gavinandresen> ... or the "I'll put in a 32MB cap so we have to go through this whole hard fork controversy again in a few years" 05:54 < adam3us> gavinandresen: so i think if you would post a BIP and retract the unilateral hard fork ultimatum that mike hearn is promoting daily, you would see more productive discussion on list. many people dont like controversy so this is creating the environment which fosters this kind of working is my guess. 05:54 < gavinandresen> I have a bunch of technical nits with that BIP, but I have little idea what gmaxwell/sipa think of it 05:54 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Ping timeout: 246 seconds] 05:54 -!- helo [~helo@unaffiliated/helo] has joined #bitcoin-wizards 05:55 < gavinandresen> Well, I'm not going to write a BIP until I've finished writing the code/unit tests/regression tests. And it seems to me that there is no danger to deploy that code for early testing to merchants and exchanges 05:56 < gavinandresen> It will do NOTHING until past a switchover date and a miner vote... 05:56 < adam3us> i have heard a whole lot of people - as far as i can tell its everyone who has a bunch of code checkins, saying that a hard-fork without consensus is unnecessarily dangers. we need to foster collaboration and consensus to reduce the risks. 05:56 < kanzure> if merchants, exchanges and miners just accept unreviewed code then i fear this network is going to implode 05:56 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Ping timeout: 246 seconds] 05:56 < gavinandresen> So if we DO need to do "an emergency hardfork" it will be much easier, because only the miners would need to update their systems. 05:56 < jgarzik> gavinandresen, private comments. reducing risk by starting out at 1MB, and then letting market take it from there 05:57 < jgarzik> gavinandresen, people dislike "unlimited" so 32MB seemed a compromise, where 2 hard forks are required to get beyond 32MB - thus two major user endorsements 05:57 < gavinandresen> jgarzik: cool. I actually have no problem with taking feedback privately, but I was reacting to the "but you've been TALKING to people in private!" comments from earlier.... 05:57 < jgarzik> since we needed 32MB anyway 05:57 < adam3us> gavinandresen: it takes a while to get to 32MB if there are growth rate caps. so its not like today 05:57 < kanzure> feeding them private patches can easily change, in the future, to "feeding them patches that forks the network on their end into an altcoin". they can run whatever they want, but at the same time they might not be aware of the economic ramifications of hard-forking. 05:58 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 05:58 < kanzure> private unreviewed patches, even 05:58 < kanzure> and how do they know that you didn't feed the other parties a different patchset anyway? 05:58 < kanzure> this is just... wtf. 05:59 < gavinandresen> kanzure: THE CODE IS NOT YET WRITTEN. IT WILL BE PUBLIC AND REVIEWED AND THEN ROLLED OUT IN AN XT RELEASE. 05:59 < gavinandresen> geez 05:59 < kanzure> okay using caps is nice, but you said: "And it seems to me that there is no danger to deploy that code for early testing to merchants and exchanges" 05:59 < gavinandresen> yes, after testing and review. 05:59 < kanzure> and if there are nacks everywhere? 06:00 < kanzure> well anyway; yes that will fix the different-patchsets concern. 06:00 < gavinandresen> This conversation would go better if we all could assume that we all have best intentions and are competent. I try really hard to do that.... 06:00 < kanzure> it is hard to make that assumption when we receive nuclear threats 06:00 < adam3us> gavinandresen: you might have noticed that i do to. at least i try to explain that. 06:00 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-wizards 06:01 < gavinandresen> oh please, forking the open source project for a limited period of time is not a 'nuclear threat' 06:01 < kanzure> uh, that's not what you threatened 06:01 < adam3us> gavinandresen: you nor mike have been particularly clear about how its going to be limited in time 06:01 < gavinandresen> that is how open source works. If you're unhappy with the direction the project is going, fork the code.... 06:01 < kanzure> you're misconstruing the history here 06:01 < kanzure> we are talking about blockchain history forks, not repository forking 06:01 < nsh> forking a project is a notably different proposition to forking a distributed consensus system :) 06:02 < adam3us> gavinandresen: its not how a consensus system works though. fork the code fine, whatever. lobby non-technical people in private to run it without a balanced presentation of risks, that is not an open or safe way to behave. 06:02 < gavinandresen> adam3us: I thought we were pretty clear: either the network will upgrade to bigger blocks, in which case Core will be forced to follow and re-integrate. 06:02 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Ping timeout: 240 seconds] 06:02 < gavinandresen> Or it won't, in which case XT will drop the bigger block patches and go with whatever Core does. 06:02 < kanzure> no, you were not clear at all; you said "i have convinced all these companies to run it anyway, already, and also even if i see nacks it will go forward" (actually you didn't say this; mike did) 06:02 < adam3us> gavinandresen: you know that gmaxwell, sipa, heck everyone has said that a non-consensus hard fork is the worst possible risk. 06:03 < adam3us> kanzure: precisely. 06:03 < nsh> well, if we can a priori exclude all the possibilities where something goes wrong, then i agree there's nothing to worry about 06:03 < kanzure> ((i apologize for misconstruing gavin vs mike comments)) 06:03 < nsh> i'm glad we got this cleared up :) 06:03 < gavinandresen> A 50/50 split with half merchants/miners on one side and half on the other WOULD be terrible. That is not going to happen, CANNOT happen, with the patch I'm working on 06:04 < nsh> then the patch will be a proof of a hypothesis about byzantine consensus and i'll help proof read the paper the results 06:04 < adam3us> gavinandresen: i dont see how you can assure that it wont happen. that assumes the rest of the world takes your threat and runs with it. 06:05 < nsh> sorry, byzantine-consensus, macroeconomic and game-theory. prodigious :) 06:05 < nsh> *economics 06:05 < adam3us> gavinandresen: ie in the interests of pragmatism etc that you are going to force the issue and impose your BIP parameters over the majority views of everyone else, you are willing to play chicken with $3b of other peoples money? 06:05 < gavinandresen> adam3us: RE: lobbying in private: I have been extremely public this entire year about the need for bigger blocks. I've given at least three public talks, given interviews, posted to the -dev mailing list, written blog entries.... 06:05 < adam3us> gavinandresen: yes and before that you had i gather many more months of private discussions where everyone technical NACKed the proposal. 06:05 < gavinandresen> adam3us: ... and my "lobbying" consisted of asking people whenever I met them: "what do you think needs to be done RE: scaling up?" 06:06 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 06:06 < kanzure> yes and if you ask a bunch of economists they will say get rid of the scarcity; who cares? 06:06 < adam3us> gavinandresen: look i think that is a poor question to shape here. everyone who is sane wants to scale bitcoin. the question is a technical one of how within safety, security etc 06:06 < kanzure> indeed 06:06 < gavinandresen> adam3us: the NACKs were "lets wait" and/or "more testing/analysis" . Well, it's been 6 months of waiting and testing and analysis.... 06:07 < adam3us> gavinandresen: well u and mike did one good thing which was to remind everyone we are only within 3x-4x excess capacity. 06:07 < gavinandresen> adam3us: see, for example, sipa's analysis of block size / fees posted to bitcoin-dev mailing list. I am perturbed that he didn't respond to my questions about that analysis.... 06:07 < adam3us> gavinandresen: but you could say you did that job, and there are public attempts to do this by consensus, which i think you have to admit, is less risky 06:08 < gavinandresen> consensus is great, I'll say again: I'm happy to follow consensus on another proposal, if another reasonable proposal can get consensus. Heck, I'll even write the code.... 06:08 < adam3us> gavinandresen: pieter is very distressed by the escalation of model of working, so as i said above, i expect his non-public interaction is more to do with not liking to interact in a perceived hostile space. 06:08 < kanzure> in case it's not clear, we are concerned that you haven't taken back the nuke threat 06:09 < adam3us> gavinandresen: so at this point i dont see why you dont just climb down from the threat gracefully and persuade mike to abandon the bitcoin-XT fork. 06:09 < adam3us> gavinandresen: if your proposal is better than jeff's or others based on merit i think people would be very happy to ACK it. 06:10 -!- SDCDev [~quassel@unaffiliated/sdcdev] has joined #bitcoin-wizards 06:10 -!- lnsybrd [~lnsybrd@ip98-167-192-68.ph.ph.cox.net] has joined #bitcoin-wizards 06:10 < gavinandresen> well, I need to finish writing the code before I even HAVE a proposal. Pragmatic concerns like "how easy or hard will this be to backport" will influence the proposal 06:10 < kanzure> do you know which nuke threat we are talking about? 06:11 < adam3us> gavinandresen: i think the two things that are alarming people more than you seemed to account for, and i did warn about this privately, is overriding the code change governance model which is there for good reason; and secondly to push out a hard-fork without consensus 06:11 < gavinandresen> Releasing a version of XT that supports bigger blocks? Then asking merchants/exchanges to run it and announce "We're Big Block Ready!" 06:11 < kanzure> no, that's not what your email said specifically 06:11 * kanzure looks 06:12 < adam3us> gavinandresen: ^^ those are the questions which you are under-estimating the gravity of. 06:12 < gavinandresen> There is no "code change governance model" for Bitcoin-the-project. There is for Bitcoin Core, but I think it has been breaking down. 06:12 < adam3us> gavinandresen: i dont think anyone else thinks so. other than mike of course. 06:12 < adam3us> gavinandresen: you're well aware of the scalability work that has been done this past year for example. 06:12 * ThomasV grabs popcorn 06:12 < kanzure> adam3us: where's this email :-( 06:13 < gavinandresen> Yes, the scalability work is great! 06:13 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 06:13 < gavinandresen> I would LOVE LOVE LOVE to be helping rusty with IBLT work instead of endlessly arguing in blogs, on IRC, etc..... 06:13 < adam3us> gavinandresen: and without that work changing a constant to 20MB might be problematic even on a host basis 06:13 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 06:13 < adam3us> gavinandresen: well there's a simple answer to that… 06:14 < adam3us> gavinandresen: go do it and stop? 06:14 < gavinandresen> Ok, well, THERE's a fundamental difference where I think reasonable people can disagree. I think we need to create headroom for that scalability work, so we can grow into it. 06:14 < kanzure> "encourage miners to roll out a soft-fork to start producing bigger blocks" 06:14 < gavinandresen> I don't think that is dangerous 06:14 < gavinandresen> ... because miners aren't idiots. 06:14 < kanzure> hmm that wasn't the threat.. let's see... 06:14 < adam3us> gavinandresen: no i agree with that as does everyone else 06:14 < gavinandresen> If their blocks propgate slowly, they'll create smaller blocks. 06:14 -!- hearn [~mike@77-59-61-48.dclient.hispeed.ch] has joined #bitcoin-wizards 06:14 < gavinandresen> Yay! agreement! 06:15 < adam3us> gavinandresen: i prefer jeff's proposal over yours, and if you want to later move the conversation back on list i'll be happy to comment on both publicl 06:15 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 06:15 < gavinandresen> adam3us: cool 06:15 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 06:15 < kanzure> http://sourceforge.net/p/bitcoin/mailman/message/34155307/ 06:15 < gavinandresen> If Jeff's proposal gets consensus quickly, that'd be spiffy, I'll implement THAT instead of what I'm working on. 06:15 < kanzure> it was in this email that you threatened to hand everything over to the miners? hmm 06:16 < kanzure> still looking. i think there was one more. 06:16 < adam3us> gavinandresen: "There is no "code change governance model" for Bitcoin-the-project.  There is for Bitcoin Core, but I think it has been breaking down." i think that is a non-constrictive statement. yuo just admitted ^^ that you thought the work done under this model over the last year was great work. 06:16 < gavinandresen> kanzure: I don't think I ever said that. If I did, then I was high on crack. 06:16 < kanzure> i doubt it; most people write great code when on crack. 06:16 * nsh smiles 06:16 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 06:17 < JackH> poor gavin lately :/ so much fighting 06:17 < adam3us> gavinandresen: and when you've implemented jgarzik proposal or your proposal or someone elses will you get mike to push it via Bitcoin-XT 06:17 < kanzure> ((actually now i'm curious to hear how you think crack influences you; but that's off-topic i guess.)) 06:17 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 06:17 < adam3us> JackH: no this is good, talking is better than not talking *always* 06:17 < gavinandresen> adam3us: Bitcoin Core process works OK for incremental changes. For anything controversial... not so much. See the P2SH controversy for the first good example. 06:18 < nsh> that analysis may not take account of all of the terrible changes that haven't been made, and their value 06:18 < JackH> I know, I have been following this alot myself. nice to see gavin in here, but still a rotten page in the book of Bitcoin with all this 06:18 < adam3us> gavinandresen: i dont know if you have this view, but the consensus afterwards was that the one you pushed for was worse than the one you overrode 06:18 < adam3us> gavinandresen: on p2sh. people just didnt care enough to fight. size limits on it. 06:18 < gavinandresen> adam3us: "get mike to push it..." Well, I'm being really mean to Mike-- I'm making him be Benevolent Dictator of the XT project 06:19 -!- kyuupichan [~Neil@ae041057.dynamic.ppp.asahi-net.or.jp] has quit [Remote host closed the connection] 06:19 < adam3us> gavinandresen: well collaborate with mike, rather. 06:19 -!- kyuupichan [~Neil@ae041057.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-wizards 06:19 < JackH> what surprises me the most about this debate: gavin, is how you have fought so hard to keep in implementing XT 06:19 -!- kyuupichan [~Neil@ae041057.dynamic.ppp.asahi-net.or.jp] has quit [Remote host closed the connection] 06:19 -!- llllllllll [~lllllllll@6d482698.ftth.concepts.nl] has joined #bitcoin-wizards 06:19 < gavinandresen> Sure, I think Mike and I will continue to encourage merchants/exchanges (and eventually miners) to upgrade to a codebase that supports bigger blocks. 06:19 < JackH> you made it into a goal 06:19 < adam3us> gavinandresen: the question is serious and the crux of it however: going ahead with unilateral actions. 06:19 < gavinandresen> If Core supports bigger blocks, then cool! 06:20 < kanzure> (isn't there something broken about using block version number "voting" from miners for a hard-fork about max block size. isn't that one of the things in the list of things that should never be done?) 06:20 < Eliel> There will be a chain with support for higher transaction throughput and lot of people will migrate to it. What I don't know is if it'll end up being named Bitcoin. It doesn't look like everyone here understands this. 06:20 < adam3us> gavinandresen: so as that looks to be happening anyway within the consensus process .. thanks in part to you and mike reminding people .. why is there a need even for bitcoin-XT as a vehicle now? 06:20 -!- kyuupichan [~Neil@ae041057.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-wizards 06:20 < gavinandresen> So... I've called Bitcoin Core the "reference implementation" .... implying that there will be other implementations. And there are, but none of them have really taken off yet. 06:20 < Eliel> it doesn't matter even if everyone here agrees 1MB blocks are the way to go. It will still happen. 06:21 < kanzure> Eliel: that's not helpful 06:21 < kanzure> Eliel: although your previous comment was more helpful 06:21 < adam3us> gavinandresen: you could save a lot of devs a lot of stress, and reduce risk etc etc by just retracting (even just temporarily!) the unilateral assertions that you and mike have been making about forking the codebase tied to a network fork overuling the rest of the core deve teams advice 06:21 < gavinandresen> If Bitcoin is successful, there will be a LOT of implementations. I think I agree with Mike that the governance model for Bitcoin Core (NOT the bitcoin project) cannot work in the long run 06:21 < adam3us> gavinandresen: yes but this is why libconsensus is being worked on, it can be dangerous to diverge via subtle bugs 06:22 -!- kyuupichan [~Neil@ae041057.dynamic.ppp.asahi-net.or.jp] has quit [Remote host closed the connection] 06:22 -!- kyuupichan [~Neil@ae041057.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-wizards 06:22 < kanzure> gavinandresen: so more specifically it sounds like you do not want to participate in the bitcoin-core development team long-term? 06:22 < adam3us> gavinandresen: lets give you a hypothetical, say bitcoin is not $3b but $30 trillion. do you really think its appropriate that one person who disagrees with the rest of the technical experts can get away with bypassing all other opinions? 06:22 < kanzure> long-term, mind you 06:23 < kanzure> adam3us: he has already said yes- that's mike's position, yo 06:23 < adam3us> kanzure: but thats not rational 06:23 < kanzure> neither is mike 06:23 < JackH> so you just want to work on another reference implementation? 06:23 < gavinandresen> adam3us: sure, if that one person can convince a supermajority of people that their vision is correct. 06:23 < adam3us> kanzure: nah mike is rational, just pragmatic, and has different assumptions about scaling that ends with fiber channel links in datacenters. 06:23 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 06:23 < JackH> but, cant you do that without forking the network? 06:23 < kanzure> adam3us: fair enough 06:24 < kanzure> JackH: agreed; working on a different implementation can still occur without forking the network, or convincing miners to start pumping out hard-fork block version numbers 06:24 < adam3us> gavinandresen: should the super-majority include the technical people who understand the technical risks? 06:24 < gavinandresen> adam3us: history is full of times when one expert was right but conventional wisdom of the time was wrong... 06:24 < gavinandresen> If I was an asshole I'd claim I was the Galileo of Bitcoin :-) 06:24 < adam3us> gavinandresen: this thing feels like reactor design by lynchmob on the receiving end 06:24 < hearn> my ears were tingling ... 06:25 < kanzure> gavinandresen: nobody has ever claimed that the bitcoin currency will disappear with 20 MB blocks. they have claimed lots of risk related to a controversial hard-fork. these are separate topics dude. 06:25 -!- lnsybrd [~lnsybrd@ip98-167-192-68.ph.ph.cox.net] has quit [Quit: lnsybrd] 06:25 < adam3us> kanzure: exactly. 06:25 < nsh> (history is devoid of times precedent here) 06:25 < gavinandresen> adam3us: there's another place reasonable people can disagree-- what are the risks versus benefits of proposed changes ? 06:25 < nsh> (to suggest otherwise is inexcusable folly) 06:25 < nsh> -times 06:25 < adam3us> hearn: afternoon. some air clearing, which hopefully gets somewhere productive. 06:25 < hearn> adam3us: with due respect, i think there's something important here. you and a few others have some deep expertise in a very narrow area of the bitcoin project (theoretical cryptography). as you have yourself said, many other areas are not really your cup of tea. for example, UX. 06:26 < hearn> now what i'm seeing in these discussions is a dismissal of everyone elses expertise. bitcoin needs everyone, with all their backgrounds 06:26 < nsh> ($10 billion is not secured on cutting-edge UX) 06:26 < hearn> gavin and myself have both been around longer and written far more code 06:26 < kanzure> hearn: argument from authority; boring predictable try again please. 06:26 < JackH> but hearn, if we dont agree with that? 06:26 < kanzure> hearn: you can surely do better tha nthat 06:26 < hearn> so it would be nice if we could all start by recognising each others experience 06:26 < adam3us> gavinandresen: why would it be worth even the controversy to impose a view for your preferreed parameters vs jeff's for example thats where we are right now. 06:26 < hearn> kanzure: shush 06:26 < JackH> I mean, you need all the business to go along with your ideas 06:26 < kanzure> hearn: no; we should start yb abjectly rejecting all prior experience. we should not be speaking from authority. 06:26 < JackH> our business for sure wont switch to XT 06:26 < JackH> not under these circumstances 06:26 < adam3us> hearn: ack. 06:27 < kanzure> gavinandresen: there are some limits to where reasonable people can disagree. 06:27 < hearn> adam3us: do you recognise and understand the concerns myself and most other wallet developers have about what happens when blocks get full? we can start here, i think 06:27 < hearn> adam3us: that is, we think our wallets will break and our users will get very upset. understandably so. 06:27 < hearn> (well, we are already starting to see complaints, but that will get a lot worse) 06:27 < kanzure> block size topic is different from the nuclear threat prevention we were attempting above 06:28 < Eliel> ... I'm appalled that people are using words like "impose" in this context... no single person is able to do that in this context. You'd have to misunderstand the most basic nature of Bitcoin to claim anything like that. 06:28 < kanzure> it is wrong to misconstrue these topics as the same one 06:28 < nsh> so best would be to try and formally model how your perception of that risk increases in line with the projections of transaction volume tend to the current capacity ceiling 06:28 < adam3us> gavinandresen: i think things have shifted - there are now multiple proposals in review in bitcoin-dev. why would you not once written submit a BIP there and see which one wins the design review and safety parameters etc and then help implement whichever that is? 06:28 < nsh> and to see where the point of transition is relative to the risk of problems associated with non-consensus hard-fork 06:29 < nsh> because it may vary between interest, and that might help us discuss facts, and not perceptions 06:29 < hearn> adam3us: a BIP is a document that describes what is being done - as the patch and its parameters are not yet finalised, it would make sense to write a BIP after the patch is written, or alongside it. which is what gavin is doing, i believe 06:29 < kanzure> i think that gavinandresen should consider that he can work on an alternative reference implementation without forking the network; if that's really what he wants, then he should be happy to learn that network blockchain forking is unnecessary for that to happen. 06:29 < adam3us> hearn: of course. i never said i didnt want to see a throughput increase that feeds into decentralisatoin work and later algorithmic work. i spelled it out at the bottom of my post you responded to 06:29 < hearn> beforethen other documents have been written and debated. they don't have numbers, but that doesn't seem like a big deal. 06:29 < hearn> adam3us: alright. then you understand why we are so concerned. that is good. 06:29 < kanzure> hearn: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08183.html 06:29 < adam3us> gavinandresen: i think things have shifted - there are now multiple proposals in review in bitcoin-dev.  why would you not once written submit a BIP there and see which one wins the design review and safety parameters etc and then help implement whichever that is? 06:30 -!- Madars [~null@unaffiliated/madars] has quit [Ping timeout: 255 seconds] 06:30 < hearn> adam3us: so do you understand why we feel the block size needs to be increased, with the process starting now? 06:30 < kanzure> this is unrelated 06:30 < nsh> everyone understands why. the divergence is on the urgency 06:30 < gavinandresen> yes, that's what I'm doing. As I implement, tiny little details become clear-- for example, the code is much simpler if all of the information needed to decide how large a block can be is in the block header... (so dependent only on timestamp and version) 06:30 < hearn> adam3us: and why we feel frustration with the apparent inability to start that process? 06:30 < adam3us> hearn: the process seems to be moving along now.. (with some thanks to you and gavinandresen) 06:31 < nsh> is it not started? what would be the formal start, hearn? 06:31 < adam3us> hearn: i refer to the list of proposals kanzure just posted for evidence 06:31 < gavinandresen> adam3us: my impression is that until sidechains launched the process wasn't going to go anywhere, because greg and pieter were busy..... 06:31 < hearn> and yet this morning when i read my mail, i see a message from one of your coworkers (mark) saying that there's no consensus around any proposal 06:31 < kanzure> gavinandresen: completely wrong; gmaxwell was posting and discussing the most comments perhaps he ever has, during the weeks leading up to the sidechain release 06:32 < hearn> so who am i to believe? ultimately the decider is wladimir. but he has said for as long as a change is controversial, it won't be accepted. 06:32 < hearn> hence -> deadlock 06:32 < kanzure> gavinandresen: if you go look at his timestamps on his reddit comments emails etc. it's truly impressive that he was able to type on two keyboards at once one for bitcoin discussion and the other for sidechain development 06:32 < adam3us> gavinandresen: well i think fwiw sipa spent > 75% of his work time and free time on bitcon-core work with the exception perhaps of a week or two on crunch to push sidechains out. 06:32 < kanzure> ((i am only an amateur at two-keyboard typing)) 06:33 < kanzure> ((( http://www.seanwrona.com/typeracer/profile.php?username=kanzure ))) 06:33 < gavinandresen> kanzure: sure, but my last several emails to gmaxwell were just ignored, so I had no idea what he was thinking or what was going on. Hence, frustration on my part.... 06:33 < adam3us> hearn: not everyone agrees on the ordering of things, maaku has a different view. we have independence in bitcoind matters 06:33 < kanzure> gavinandresen: fair enough 06:33 < kanzure> hearn: everyone is always going to point out when you misconstrue hard-fork threats for max block size scalability issues 06:33 < JackH> hearn: why dont you just accept that people think 20MB is too much? 06:34 < kanzure> JackH: i believe he has said other numbers he's okay with 06:34 < hearn> the exact number is certainly open to negotiation 06:34 < kanzure> JackH: so that's not fair 06:34 < hearn> i see today the chinese miners have reached consensus on 8mb 06:34 < hearn> 8 is a lucky number, right? 06:34 < adam3us> gavinandresen: so now that the process has started (again thanks to you and hearn for pushing it forward) how about we work cordially and abandon the threat of unilateral hard-fork. work on reviewing and implementing various BIPs and decide a winner and plan and go deploy it? 06:34 < hearn> i am waiting to see what gavinandresen's patch does. 06:34 < kanzure> JackH: all i ask is that everyone has perfect recall and perfect memory of all statements that everyone has ever made; is that too much to ask? :-) 06:34 < helo> the sign of a stable government is slow (or no) change 06:34 < gavinandresen> 8 IS a lucky number. Not as good as eleven.... 06:34 < nsh> so there is discussion, there is interest, there is plenty of good-faith, there is code being made ready to present, and then BIP being written. seems to me things are moving along 06:34 < hearn> gavinandresen: haha :) 06:34 * hearn doesn't have any favourite number, he feels left out ... 06:34 < hearn> maybe 99 06:34 < helo> NULL? 06:34 < hearn> i got 99 problems by 1 ain't 1 06:35 < hearn> oops. that joke was a bit mangled by bad typing 06:35 < nsh> aleph-gamel 06:35 < JackH> kazure: I know of the 8BM yes, but I am not sure if hearn explicitly said he was ok with that 06:35 < adam3us> gavinandresen: coincidentally i had suggested to jeff some different parameters including 8MB as a hard-cap. that will see that lasting for enough years to do quite a lot of other work. 06:35 < kanzure> JackH: i was kidding dude; i don't expect you to have perfect memory or to follow all posts simultaneously. 06:35 < adam3us> hearn: 1GB ;) 06:35 < kanzure> i am concerned by how nobody has disarmed the nuclear threat 06:35 < adam3us> hearn: sorry that was maybe not constuctive, perhaps not time for humor. 06:36 < JackH> yeah hearn, I actually posted something on bitcointalk, about how neither you or gavin can answer the question to what happens when we reach 20MB 06:36 < nsh> has anyone actually analyzed whether or not it's academic (like, if some other bottleneck will manifest before 32MB blocks) 06:36 < nsh> ? 06:36 < nsh> at some size it becomes academic, certainly 06:36 < JackH> and if we should increase again 06:36 < hearn> nsh: i'm absolutely sure it will 06:36 < adam3us> nsh: gavinandresen tested somthings up to 8MB I believe 06:36 < hearn> nsh: there will probably be many bottlenecks on the way up. it's the nature of scaling things. 06:36 * nsh nods 06:36 < nsh> might be worth trying to simulate 06:36 < gavinandresen> Parameters for the patch I'm working on: 8MB cap, earliest fork time 11 Jan 2016, requires 75% hashpower to support, two-week grace period (no big blocks) once 75% reached, cap doubles every two years. 06:36 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-wizards 06:36 < hearn> nsh: what's more simply making bitcoin popular enough to hit scaling problems is a whole other kettle of fish 06:36 * nsh nods 06:37 < gavinandresen> ... oh, and stops doubling after 20 years. 06:37 < nsh> hah 06:37 < hearn> nsh: at some point Bloom filtering will stop scaling, for instance. i have kicked around a few ideas for what comes after. but ..... let's cross these hurdles as we come to them. our understanding and resources will be better by then anyway. 06:37 * nsh nods 06:37 < gavinandresen> That should be enough parameters to make EVERYBODY unhappy...... 06:37 < JackH> you guys seriously actually believe that nodes will be serving many hundreds of gigabytes eh? eventually? 06:38 < hearn> JackH: it's kind of tough to imagine, isn't it 06:38 < gavinandresen> JackH: Sure, why not? 06:38 < kanzure> i think that not threatening people is a good start to making everyone happy 06:38 < adam3us> gavinandresen: oh auto-doubling? i think jgarzik had or review comments for example growth limiter at 50% or below/year. 06:38 < gavinandresen> JackH: if they can't serve hundreds of gigabytes, then they wont. 06:38 < hearn> JackH: but then i remember when the only person i could send bitcoins to was satoshi. the whole story of bitcoin has been unexpected and hard to imagine 06:38 < adam3us> gavinandresen: no growth rate limit? 06:39 < gavinandresen> adam3us: doubling every two years is 40% growth per year. 06:39 < hearn> JackH: anyway, the fact is, no technology grows exponentially for very long. growth slows and plateaus eventually. it's hard or impossible to guess exactly where 06:39 < adam3us> gavinandresen: sorry i thought you said per year. 06:39 < Eliel> kanzure: I think it'd be a good idea to realize that the very fact that those threats are credible means that gavin is actually just messenger. Not the origin of what you label a "threat". 06:39 < hearn> JackH: that's why successful systems tend to build the system they need to manage the next phase of growth, rather than try to design something that can handle infinite growth right up front 06:39 < JackH> the way I see it, is that your "patch" is killing my efforts of becoming a full node, thus I cannot verify, thus I cannot be part of the network 06:39 < adam3us> gavinandresen: but whats doubling the cap? 06:39 < kanzure> Eliel: can you elaborate? 06:40 < JackH> thus you are creating central points, like ISP's 06:40 < JackH> and then its bye bye to Bitcoin as a perfectly decentral system 06:40 < gavinandresen> adam3us: hmm? 8MB in 2016, cap would be 16 MB blocks in 2018, etc 06:40 < adam3us> Eliel: its clear everyone wants bitcoin to scale so that everyone can benefit 06:40 < kanzure> Eliel: they are credible only because i believe that companies miners and exchanges can be convinced to use patches that are against their interest or the interest of the network. 06:40 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 06:40 < leakypat> The nuclear threat should be withdrawn, creates a lot of uncertainty and divisiveness , I'm sure wallet makers are way more concerned about a split than the blocks hitting the hard cap at some point 06:41 < helo> 50% max blocksize growth mid-subsidy starting from the first block 06:41 < adam3us> gavinandresen: ok. jgarziks' is 32MB hard-cap (that does not grow) and a growth limiter (i think 2x every 18mo) by soft-cap 06:41 < JackH> Despite the fact that our payment gateway, (yes we are running a payment gateway for Bitcoin in EU), is serving a full node and can scale hugely, this is still not enough for me. 06:41 < adam3us> adam3us: however not sure were exactly he is on the growth-limiter. someone could look at bip-100 latest 06:41 < helo> that would put it at 2.25MB right now, i think 06:42 < hearn> JackH: there are people who can't afford to run a full node today. shall we fix that by evicting the transactions your payment processor is handling so we get smaller blocks? the line has to be drawn somewhere. 06:42 < nsh> adam3us, what is the concern regarding unlimited growth? 06:42 < gavinandresen> adam3us: yup. As I said, that's OK with me, too, although the code is trickier. 06:42 < adam3us> gavinandresen: it does seem sensible to not provide system shocks, as a general principle. so jeff had mentioned that. 06:42 -!- Mably [56401ec3@gateway/web/freenode/ip.86.64.30.195] has quit [Ping timeout: 246 seconds] 06:42 < hearn> JackH: anyway, this has been debated to death. look at http://www.gavinandresen.ninja for many articles discussing this topic 06:42 < adam3us> gavinandresen: ok so this sounds all agreeable and reasonable and i am sort of puzzled why we let this get so far out of whack. 06:42 < JackH> hearn: And even less will be able to run a full node. And if we get too many transactions we wont use Bitcoin itself anyway, but some sidechain or lighting. I wont take the risk of double spend for 10 min if we have 10 million transactions 06:42 < nsh> (is it wrong to assume abnormally-large blocks will be disincentivized by propagation time) 06:43 < helo> and it would be trivial to implement 06:43 < gavinandresen> adam3us: Bad timing maybe? I know everybody at blockstream has been super-stressed to get sidechains out.... 06:43 < JackH> I have everything to gain in a sense from increased block sizes, from the point of view of the Bitcoin payment business. But I have everything to loose for allowing it to happen, by killing Bitcoin in the process 06:43 < adam3us> gavinandresen: so i think the thing that can simply return things to normal and get people focussed back on review simulations and network stats etc. is to clarify that (if you agree) you will participate with the BIP review process and take the winning outcome. 06:43 < helo> and it would be more likely to stay well below any system performance growth (bandwidth, etc) 06:44 < helo> and encourage off-chain uses for things that don't need to be on-chain 06:44 < Eliel> kanzure: There's enough pressure from the community to do something about this by now that if gavin doesn't do it, someone else will. Which is most likely very bad idea unless that someone else ends up being the entire bitcoin core team. 06:44 < kanzure> gavinandresen: blaming blockstream for your threats is poor form 06:44 < nsh> kanzure, that wasn't how i read it 06:44 < kanzure> nsh: go on 06:44 < adam3us> gavinandresen: there were a few too many 18hr days there for a few weeks for sure. 06:44 < helo> ^ 06:44 < leakypat> kanzure: come on dude 06:44 < kanzure> leakypat: i'm listening 06:44 -!- wallet42 [~wallet42@85.100.40.253] has joined #bitcoin-wizards 06:44 < gavinandresen> adam3us: mmmm.... see BIP16 versus BIP17 for what I think is likely to happen with a "BIP review process" 06:45 < adam3us> gavinandresen: that was the p2sh one? 06:45 < gavinandresen> adam3us: yup 06:45 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Ping timeout: 250 seconds] 06:45 < helo> kanzure: "everyone that would be commenting was busy working on sidechains" 06:45 < gavinandresen> adam3us: Eventually I was just the bad guy and said "It's gonna be BIP16" 06:45 < kanzure> Eliel: i think that others forking the network is less likely to get wide adoption; companies are used to centralized systems so gavin going to them and saying "here's some patches yo" is something they would likely accept whereas anyone else bringing the patches would perhaps get significantly more suspicion. 06:45 < adam3us> gavinandresen: so you do realise that gmaxwell, luke-jr and others preferred luke-jrs bip over yours, and especially in hindsight realised that there is a defect in yours and luke's would have been better. 06:46 < hearn> please guys. let's not re-open P2SH 06:46 < hearn> it's done. it works. the world continues. 06:46 < kanzure> it can be used as a learning experience 06:46 < hearn> i agree with gavin that a "use the winner" process is rather the core of the problem here 06:46 < kanzure> i'm confused why you two are spouting different histories 06:46 < hearn> as there is no process to pick a winner 06:46 < gavinandresen> Yes, hindsight is 20/20, learn from mistakes and move on, perfect is enemy of the good, etc etc 06:46 < kanzure> was there a disagreement regarding which patch got merged? 06:46 -!- Mably [56401ec5@gateway/web/freenode/ip.86.64.30.197] has joined #bitcoin-wizards 06:47 < kanzure> e.g. i mean an issue of historical fact 06:47 < hearn> e.g. the consensus that is so often discussed is a consenus of ....... who? who gets to be in that group and how did they get there? so i'm not sure how such a process would work 06:47 < adam3us> kanzure: its because gavin tried to exercise sort of initiative to short-cut the discussion he's suggesting this is relevant here. which i think could be discussed. 06:47 -!- Giszmo [~leo@pc-185-201-214-201.cm.vtr.net] has joined #bitcoin-wizards 06:47 < kanzure> adam3us: yes, i can see why others might not want to discuss that 06:47 < Eliel> kanzure: There isn't a shortage of people who can be convincing enough. Especially when almost everyone feels like some kind of a solution is needed. 06:47 < adam3us> gavinandresen: but as you brought it up i thought it relevant to actually point out that if you had not done that the other would have won, and they had misgivings and turned out to be correct. 06:47 < hearn> for what it's worth, i was not totally sold on P2SH either, but in the end realised i had got it wrong. i wanted a pure payment protocol based approach and hoped that requiring BIP70 to do multisig would incentivise (uh oh) the creation of the necessary infrastructure 06:48 < hearn> in practice that didn't happen. gavin was right - people weren't ready to leave bitcoin addresses 06:48 < kanzure> Eliel: yes, but the difference is how the solutions are implemented :-) 06:48 < hearn> lesson learned: trying to "incentivise" people to build what you want by blocking other solutions isn't a good idea 06:48 < JackH> hearn: would you change your mind if satoshi was to say that 20MB is not the right way forward? 06:48 < kanzure> helo: i didn't forget your message; i'm just confused what you wanted me to do or say in response to it. 06:48 < nsh> likewise consensus code updates, perhaps 06:48 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 06:48 < hearn> JackH: lol, he already did 06:48 < JackH> hearn: those were different times and you know that 06:49 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 06:49 < nsh> clearing your throat to get a discussion started is fine, and indicated 06:49 < nsh> growling the whole time to direct that discussion isn't 06:49 < hearn> JackH: satoshi said several times that the 1mb limit was only there until SPV clients existed, and after that the limit could be entirely removed. 06:49 < JackH> hearn: back then anything was a go 06:49 -!- www [~v3@p50897479.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds] 06:49 < nsh> and i'm sure no-one is trying to do the latter :) 06:49 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 06:49 < kanzure> this rewrite of history is inappropriate 06:49 < JackH> hearn: we were like what? 200 dudes? 06:49 < hearn> JackH: so why ask me what i'd do if satoshi said X, when he already said it, if you're just going to immediately say "oh well that was different times"? seems like not a very useful question. 06:49 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 06:50 < adam3us> gavinandresen: so given that there's momentum on multiple proposals in review it and its safer not have controversy for the success of the hard fork, and generally for public communication if the development people are acting colaboratively, how about using the process and implementing the winner? 06:50 -!- instagibbs [417d1202@gateway/web/freenode/ip.65.125.18.2] has joined #bitcoin-wizards 06:50 < helo> kanzure: how i read what gavin said re: bad timing 06:50 < hearn> adam3us: can you outline *specifically* what the process you have in mind is? 06:50 < adam3us> gavinandresen: it seems like you are OK for example with jgarzik's proposal or presumably variants of it because the parameters are quite different from yours. 06:50 < JackH> hearn: I asked if he was to say something now, not back then. But an updated satoshi idea 06:50 < instagibbs> hearn: I agree "consensus" is fuzzy. But (N-1)-core dev opposition clearly isn't it. "I"ll know it when I see it" sort of applies here 06:50 < kanzure> helo: ah; but the evidence is that the sidechain developers were actually actively commenting on reddit and in emails. look at the timestamps. 06:50 < hearn> adam3us: e.g. to the level we could implement it in a little web app or something 06:51 < gavinandresen> adam3us: how about not putting all our eggs in one basket and not putting some fuzzy process with no clear endpoint on the critical path? 06:51 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 06:51 < kanzure> gavinandresen: so network consensus is definitely a basket 06:51 < kanzure> that's called a blockchain 06:51 < instagibbs> You clearly wouldn't say N/2 For, N/2 Against was consensus 06:51 < instagibbs> why is N-1 "maybe consensus" 06:51 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 06:51 < hearn> instagibbs: what is N equal to here? 06:51 -!- dEBRUYNE [~dEBRUYNE@239-196-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 06:51 -!- darwin__ [~darwin@88-103-255-166.jes.cz] has joined #bitcoin-wizards 06:51 < instagibbs> Specifically core dev set, to be clear 06:51 < adam3us> gavinandresen: because it is safer on several aspects that i explained in my post. its constructive, collaborative, benefits from peer review, gets more public discussion, stops us looking bad in public as the tech brains behind bitcoin, etc 06:52 < nsh> hearn, it's the bagholders of technical debt 06:52 -!- darwin_ [~darwin@88-103-255-166.jes.cz] has quit [Read error: Connection reset by peer] 06:52 < nsh> (you do not want to be the sole bagholder of bitcoin's technical debt) 06:52 < hearn> instagibbs: and who is in that set? 06:52 < nsh> (i promise you) 06:52 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 06:53 < instagibbs> hearn: Can you show me your list of core devs that have consensus for a fork? 06:53 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 06:53 < instagibbs> including dissenters 06:53 < kanzure> hearn: btw i think your time would be better spent replying to adam3us' email than replying in here 06:53 < kanzure> someone requested in-line responses 06:53 < adam3us> gavinandresen: i'm not sure you maybe explained very clearly and perhaps that bit wasnt what you were focussing on, but the message that hearn would be in sole control of bitcoin maintainership of bitcoin for a non-trivial period is not good for security, integrity, avoidance of speciali interest lobbying, blackmail, getting hit by a truck etc etc. and jsut perception wise. (no offence to hearn - same would be true of any one person) 06:54 < hearn> in the event that i have a bad date with a truck, the github fork button will still work :) 06:54 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 06:54 < hearn> but anyway, yes if bitcoin XT gets serious traction i would make gavin a maintainer 06:54 < kanzure> further misinterpretation 06:54 < gavinandresen> adam3us: you're confounding bitcoin-the-project with various implementations... 06:54 < kanzure> the fork button does not cause network hard-forks 06:54 < JackH> hearn: you will never get our business to follow you. I think that is all that remains to be said. Go ahead, fork away, try to split the network. But you wont gain consensus and we will never bow to centralisation from the people that paid you and Gavin 06:54 < hearn> i wouldn't worry about the mechanics of this. i have run several successful open source projects 06:54 < kanzure> you are clearly unable to read 06:54 < kanzure> do you really think adam3us meant "forking an open source project's source code repository"? 06:55 < kanzure> really? 06:55 < nsh> perhaps we need to use different words 06:55 < adam3us> gavinandresen: there is also quite a bit of infrastructure around bitcoin. the reviewer process requireing consensus approval to stop bugs getting snuck in if someones children were captive and they blackmailed for example. 06:55 < nsh> if this continues to be a problem :) 06:55 < nsh> what was the event that lead to the split between the western and eastern roman empires? 06:55 -!- StephenM347 [~stephenm3@static-64-223-246-218.port.east.myfairpoint.net] has joined #bitcoin-wizards 06:55 < hearn> kanzure: he was talking about maintainership so yes 06:55 < nsh> i'm sure it has a suitably cataclysmic name 06:55 < kanzure> hearn: okay so you think that maintainership has nothing to do with hard-forking? 06:56 < gavinandresen> ok, I think my time is better spent finishing writing regression and unit tests.... 06:56 < adam3us> gavinandresen: and the security incident management etc 06:56 < JackH> we will never bow to XT 06:56 < adam3us> gavinandresen: no comment on choosing the winner from the BIP process to normalise relations and act with a unified technical view in public? 06:56 < kanzure> (why would anyone want to use a fork of bitcoin-core if the maintainers are incapable of distinguishing between repository forks and consensus hard-forks and multiple blockchains?) 06:57 < adam3us> gavinandresen: its not like you coudlnt back out if you though the process selection was supremely bad even… 06:57 -!- temujin [2679a51e@gateway/web/freenode/ip.38.121.165.30] has joined #bitcoin-wizards 06:57 < helo> the 20MB patch probably won't become more popular in the near future than it is right now. so the window of opportunity to shove it through is closing. 06:57 < kanzure> gavinandresen: to make it clear, we're still trying to get you to admit that the threat should be revoked, and replaced with the previous procedures instead 06:58 < helo> "if we can just postpone its depoloyment long enough" vs "if we can just deploy it post-haste" 06:58 < kanzure> gavinandresen: i think many good reasons have been presented for this 06:58 < gavinandresen> adam3us: consensus is, ultimately, the code people choose to run. I'm happy to propose a BIP, would be even happier if there was only one BIP that everybody agreed was best. 06:58 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 06:58 < nsh> so developer consensus is valueless :/ 06:58 < adam3us> gavinandresen: proposing to fork it seems kind of pointless now that there are multiple public process, so why not just join the fray? 06:58 < kanzure> gavinandresen: do you think that asking companies to run your fork would be more or less likely to result in companies to run a hard-forking network, regardless of technical merits? 06:59 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Ping timeout: 256 seconds] 06:59 < adam3us> gavinandresen: it deescalates teh situation leads to better open public communication and should lead to a better technical result 06:59 < hearn> nsh: i would say it's rather, undefined 06:59 < gavinandresen> ... but I'm not going to propose a BIP until I've written code that implements it, because I think BIPs should be descriptive, not proscriptive. 06:59 < adam3us> gavinandresen: thats fine of course. i dont know if jgarzik started implementing but i presume people would expect that. 07:00 < nsh> and of course you can't lobby without code or a proposal anyway 07:00 < kanzure> nsh: on the contrary? 07:00 < nsh> because peopel would be silly to sign up to something that doesn't exist :) 07:00 < nsh> unfortunately, people are silly 07:00 < kanzure> nsh: that's what the claims have been, so far 07:00 < nsh> so try not to lobby :) 07:00 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 272 seconds] 07:00 -!- mjerr [~mjerr@p578EB3B1.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds] 07:00 < gavinandresen> I think that is a reasonable bar for BIPs : if you care enough to actually implement it, then your BIP deserves serious consideration. Otherwise the BIP process gets overwhelmed with half-thought-out proposals.... 07:00 < nsh> it's just a matter of phrasing the solicitation that *is* required to draft a proposal such that it doesn't seem like a request for endorsement 07:00 < adam3us> gavinandresen: but again, sorry to keep badgering on this one topic, but its just sooo much more constructive and i rdo think will result in a better outcome if you would just agree to suspend the hard-fork threat for now. its not a big ask in the context that you even seemed to be ok with jgarziks proposal. 07:00 < nsh> and there, problem solved 07:02 < nsh> (i did market research. you don't end a survey with 'and will you buy the product we make with this feedback') 07:02 < nsh> (that would be prohibited, even) 07:02 < gavinandresen> adam3us: there will absolutely, positively be no hard fork before January. Is that sufficient? 07:02 < adam3us> gavinandresen: it will also save 100s of wasted bitcoin developer cycles lobbying companies CEOs and things like the bitcoin.org site that i'm sure you saw 07:02 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Ping timeout: 244 seconds] 07:02 < kanzure> gavinandresen: we're not talking about "any possible hard-fork", we're talking about the one you threatened.... 07:02 < adam3us> gavinandresen: i'm not sure what you mean. is that the date code is rolled out. or rather when deployed hard-fork deployed in the next month that will trigger by 1st jan? 07:02 < helo> gavinandresen: so you're sticking with your contentious hard fork plan as-is? 07:03 < gavinandresen> adam3us: that's the trigger date. Obviously the code needs to be rolled out before then.... 07:03 < nsh> great, now the nuke has a trigger 07:03 < gavinandresen> (well, that's the earliest-possible-trigger date) 07:03 < adam3us> gavinandresen: so then that wasnt really an answer i think. 07:03 * nsh can't wait for the launch codes 07:03 < nsh> :) 07:03 < JackH> nuke indeed 07:04 < Eliel> adam3us: in other words, you don't think gavin should be placing the issue of whether or not to fork to a public vote. 07:04 < hearn> the answer is "no", adam 07:04 < JackH> impressive the person that was handed the reigns from Satoshi is the person that is trying to destroy that very same project now 07:04 < kanzure> Eliel: that's not what he claimed he was doing 07:04 < kanzure> Eliel: he claimed he was getting companies to adopt the patch regardless of bip process, and that a hard-fork will occur anyway 07:04 < adam3us> gavinandresen: i'm trying to be constructive here. this is causing a lot of very productive coders working on bitcoin-dev a huge amount of stress. i'm not asking you to give much up if you're anyway basically agreeing with jgarzik's proposal or ones similar to it. 07:04 < Eliel> kanzure: I don't care what he claimed he's doing. That is what he's doing. 07:04 < kanzure> Eliel: public vote was never an option 07:05 < Taek> JackH: no personal attacks please. 07:05 < helo> JackH: less hyperbole ;) 07:05 < kanzure> cool 07:05 < gavinandresen> adam3us: how about: I commit to writing a BIP, and I will ask Mike to not rollout an XT release until that BIP and the code has had at least... ummm, three weeks of review. 07:05 < hearn> please be aware of something important. i'm starting to hear from people that investors both current and "thinking about it" are realising that Blockstream appears to be able to block a change that has extremely strong, widespread commercial support. and they are freaking out about it. 07:05 < JackH> Taek: not a personal attack, just witnessing the irony of it all 07:05 < kanzure> gavinandresen: how about more specifically, "I will not ask companies to run this hard-fork, and I will not ask them to join me on hard-forking the network." 07:05 * dgenr8 notes gavin broke is his self-imposed rule of only discussing alternative blocksize solutions that were implemented 07:06 < nsh> gavinandresen, can you submit a BIP about the three-week review hard-limit first? 07:06 < nsh> :) 07:06 < hearn> if you guys are really such strong supporters of decentralisation, you *must* accept that hard forks are a way to resolve problems when other paths have failed 07:06 < JackH> hearn: that is a lie, nobody is thinking anyone is blocking anything, people just think you are trying to destroy Bitcoin by forking it 07:06 < kanzure> hearn: that's good! companies can be threatened by the us government in general, even to accept bad or broken patches. 07:06 < nsh> hearn, we just don't believe in waving failure around as a bat 07:06 < hearn> otherwise what you are asking for is basically, a dictatorship of blockstream 07:06 < adam3us> gavinandresen: that seems good, but i was kind of assuming you would put the code for review anyway. the question is more about will you put your bip in parallel code review beside jgarziks and similar alternatives and let the technical reviews which include you and hearn agree on which is best. 07:06 < JackH> hearn: the only problem is XT 07:06 < hearn> and that's not really decentralisation, is it? 07:06 < dgenr8> has anybody other than gavin actually written any code around this? 07:06 < adam3us> gavinandresen: the proposals dont seem different enough to make an issue out of this. you already agreed to jgarziks 07:06 < kanzure> hearn: nice try, but that's not a good argument at all 07:07 < hearn> it's not an "argument". it's me repeating what i'm hearing other people conclude. and can you blame them? 07:07 < kanzure> yes, i can blame anyone i want 07:07 < kanzure> wtf? 07:07 < hearn> adam3us: you have failed to describe what this "BIP process" is, in anywhere near sufficient detail for anyone to agree to it. 07:07 < JackH> hearn: do you realize nobody in this very IRC chat right now seems to think what you are doing is a good idea? or does that not matter? XT 4 ever right? 07:07 < hearn> adam3us: what's the decision making algorithm, here? 07:08 < gavinandresen> adam3us: I have a bunch of technical nits with jgarzik's proposal, and I HATE the 32MB cap (just means we go through this again at some point), but sure, if that is consensus, then spiffy. 07:08 < kanzure> hearn: it really doesn't matter what delusions you inject into the conversation 07:08 < hearn> title: "Should the Bitcoin block size limit be raised within the next two years? - Poll Results" 07:08 < helo> gavinandresen: hearn: not deploying contentious hardforks > * 07:08 < hearn> http://www.poll-maker.com/results329839xee274Cb0-12#tab-2 07:08 < hearn> results: 92% say yes 07:08 < kanzure> haha 07:08 < JackH> LMAO 07:08 < adam3us> gavinandresen: well the point of the review process is that you get to pick nits in jgarziks and others and vice versa. so thats good. jgarzik i believe already made several updates based on feedback. (which would have been better made in public) 07:09 < nsh> how much did the measure that defined pi to be 3 in some US state pass by? 07:09 -!- b_lumenkraft [~b_lumenkr@unaffiliated/b-lumenkraft/x-4457406] has joined #bitcoin-wizards 07:09 < nsh> i bet it was a strong, godfearing majority 07:09 * hearn shrugs 07:09 < JackH> hearn: nice pool, odd it is closed and doesnt really prove anything. 07:09 < adam3us> gavinandresen: but it kind of makes a lie of the review process if one party is saying that they will overrule its outcome. i dont want to paint you wrongly as having said that. but clarification would really help just to clear the air and move forwards. 07:09 < helo> you obviously have the PR battle in pocket for your hard fork. but a lot of people that care about (and understand very well) bitcoin are in that 8%. 07:09 < kanzure> okay, so it sounds like gavinandresen is not going to answer adam3us at all 07:09 < hearn> ignore whatever evidence you like. i guess 10 minutes in #bitcoin-wizards is all the polling needed :) 07:10 < kanzure> hearn: yeah, because polling makes sooo much sense to decide the value of pi 07:10 < adam3us> hearn: no one is disputing that everyone wants to scale bitcoin. 07:10 < JackH> hearn: We have 20.000 clients right now for Bitcoin processing 07:10 -!- Xh1pher [~Xh1pher@pD9E38632.dip0.t-ipconnect.de] has joined #bitcoin-wizards 07:10 < JackH> I can assure you one thing. NOT ONE of those will ever use XT 07:10 < hearn> the poll didn't ask about "scaling" in a general sense. it asked about raising the block size limit. 07:10 < JackH> you can poll whatever you want, we are all capable of seeing through this 07:10 < adam3us> hearn: including most saying they think the first step of which is a proposal to create extra throughput and time to work on a longer term solution. 07:11 < hearn> JackH: alright. just so i can keep track of things in my lists, which payment processor is yours? 07:11 < helo> so you can choose to leverage your (likely temporary) PR victory now and try to push through, or defer to the relevance of all of the people pleading with you to backpedal a bit. 07:11 < JackH> http://uk.prweb.com/releases/2015/04/prweb12672463.htm 07:11 < kanzure> .title 07:11 < yoleaux> NorthPayments, a leading payment processor in the UK, collaborate with BitcoinPayGate.com to introduce an alternative payment option for customers 07:11 < JackH> Go ahead and DDoS us now since we dont agree to bow to you 07:11 < dgenr8> gavinandresen: do you plan to submit the patch to both bitcoin and bitcoinxt? 07:11 * nsh doesn't claim any relevance, for the record :) 07:11 < hearn> ok, thanks 07:11 < hearn> um, no, i don't DDoS people who disagree with me 07:11 < kanzure> you can't prove that 07:11 < kanzure> nobody could 07:11 < nsh> JackH, please.. :) 07:11 < JackH> no you just try to remove Bitcoin from the equation ;) 07:12 < JackH> how much did you get paid? 07:12 < JackH> seriousy now? 07:12 < JackH> 7 figures? 07:12 < kanzure> uh... 07:12 < hearn> lol 07:12 < JackH> 50% now, 50% upon hard-fork? 07:12 -!- davi [~davi@gnu/davi] has joined #bitcoin-wizards 07:12 < nsh> maybe it's time for a break :) 07:12 < gavinandresen> dgenr8: I've been told no patch for increasing the blocksize is acceptable for Core, Wladimir and Greg will just NACK no matter what. 07:12 < helo> by pushing forward based on popular polling, you are presenting the view that the opinions of the people disagreeing with you in here are not relevant 07:12 < nsh> gavinandresen, why is jgarzik proposing one then? 07:12 < kanzure> gavinandresen: i think it reflects poorly on everyone that we're leaving adam3us hanging 07:12 < nsh> is he naive? 07:12 < adam3us> gavinandresen: thats not accurate 07:12 < hearn> helo: hardly. look at how much we've written in response to every raised concern. 07:13 -!- kyuupichan [~Neil@ae041057.dynamic.ppp.asahi-net.or.jp] has quit [Remote host closed the connection] 07:13 < dgenr8> gavinandresen: so wha 07:13 < adam3us> gavinandresen: re-circling back to the discussion how about if you tell us what your conditions would be to participate in the bip review process and go with the winner of the process. 07:13 -!- kyuupichan [~Neil@ae041057.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-wizards 07:13 < gavinandresen> I'm happy to be wrong, and happy to submit a patch to Core 07:13 < helo> hearn: they've all read that stuff, and it has been inadequate (obviously) 07:13 < kanzure> we already knew you were planning a patch, but we were asking something else, gavinandresen 07:13 < adam3us> gavinandresen: i dont know who said that but they are wrong to the best of my knowledge 07:13 < dgenr8> gavinandresen: well it sends a message that you want it in core 07:14 < gavinandresen> adam3us: I'm happy to participate. I have no idea what "the winner of the process" means, though. 07:14 < kanzure> 07:09 < adam3us> gavinandresen: but it kind of makes a lie of the review process if one party is saying that they will overrule its outcome. i dont want to paint you wrongly as having said that. but clarification would really help just to clear the air and move forwards. 07:14 < kanzure> gavinandresen: you made a public threat, we're asking you for clarification still 07:14 < gavinandresen> public threat? I'm going to write some code and then make it available for people to run. 07:15 < gavinandresen> They can run it or not.... 07:15 < hearn> this is a stupid channel 07:15 < kanzure> hahaha 07:15 < dgenr8> it's actually already available. some crazy person could run it right now 07:15 < adam3us> gavinandresen: i think you do. the same way as the other BIPs over the last years have been decided (with the exception of BIP16/17 which in hindsight didnt work out ideally though it is a marginal loss only) 07:15 < morcos> gavinandresen: a lot of very reasonable people think you are taking this too far. you want progress, progress has started. i'd even go so far to say as most people are resigned to accepting an increase in the blocksize before they think its actually appropriate in order to maintain consensus. but please let that process play out. waiting 3 weeks for review of your one implementation before you roll it out to people 07:15 < kanzure> gavinandresen: you specifically said you already have companies committed to it 07:15 < JackH> they are paid off 07:16 < kanzure> gavinandresen: that's a threat. to fork the network. do you see why? 07:16 < JackH> no reason to talk any longer 07:16 < nsh> kanzure, i'm sure you misread that anyone had committed to it 07:16 < nsh> as gavinandresen is being assiduous not to get endorsements of something that doesn't exist yet 07:16 < JackH> this is by far the easiest way to take out Bitcoin 07:16 < hearn> morcos: i'm planning on letting the patch bake for a bit publicly before we spin some binaries, no worries 07:16 < nsh> i can only assume 07:16 < nsh> i want to live in the world where i can assume that safely 07:16 < dgenr8> morcos: nobody would be paying any attention at all but for gavin's work and actions 07:17 * nsh nods 07:17 < nsh> there are no villains here 07:17 < morcos> if i go along with ACK'ing some proposal like jgarzik's at this point, i will feel coerced into doing it already at this point. but at least we'll all agree whether under pressure or not... if the momentum to do something dies down in a month or so, then no doubt you can pursue this path and not listen to entreaties to stop any more if you choose 07:18 < morcos> but i don't want to find out what happens when a substantial minority is left behind in a hard fork 07:18 < nsh> i do 07:18 < morcos> i think thats the danger of letting people pick which code to run 07:18 < nsh> i just want to find out without billions being lost 07:18 < dgenr8> morcos: with a flag day a year in the future, nothing is final upon release of some software product 07:18 < nsh> because simulating systems is tractable, undoing history isn't 07:18 < hearn> i don't think there's much chance of that. they'd have to choose to be left behind, or somehow be so disconnected from the bitcoin community and their own node logs AND -alertnotify etc, that they had no idea it was coming 07:18 < hearn> in which case their node is on autopilot anyway 07:18 < gavinandresen> Again, I think it is irresponsible not to plan for scaling up NOW. Reasonable people can disagree about that, but that's my strong feeling. 07:18 < kanzure> i think that in general you should assume the best in people, but in cases where safety is critical it is bad to assume the best, instead we should proceed with caution 07:19 < kanzure> gavinandresen: i think you should answer the exact question :-( 07:19 < gavinandresen> kanzure: what exact question? 07:19 < helo> when is the "upgrade to bitcoin XT!" alert going out? 07:19 < hearn> helo: i think Core already prints messages saying "Upgrade now" when it notices new block versions it doesn't know about 07:19 < kanzure> gavinandresen: are you going to campaign companies to run the hard fork even in the presence of nacks? 07:19 < hearn> helo: so that'd depend on miner adoption. at least that's my vague recollection of how the code works. 07:19 < kanzure> and even in the presence of limited miner adoption 07:19 < JackH> gavinandresen: you are not giving people a choice to upgrade . you are forcing them to upgrade by contacting them one by one and telling them what to do 07:20 < adam3us> gavinandresen: that is not what the vast majority of people are saying. it seems like most will support something in the ballpark of jgarik's with minor differences or something like it with those differences applied. 07:20 < gavinandresen> kanzure: yes, I will encourage companies to announce that they are "big block ready" by running code that will accept bigger blocks. If consensus emerges for some variant of how big / when / etc then I'll encourage them to run THAT code. 07:20 < helo> JackH: that still is a choice, as he's not in a position to fine them or anything 07:20 -!- www [~v3@p50897479.dip0.t-ipconnect.de] has joined #bitcoin-wizards 07:21 < adam3us> gavinandresen: consider: if we proceed like this people will be working in haste, in a distressed state of mind, and it is more likely that a mistake will be made. 07:21 < JackH> helo: he is using his star status to do it. the choice is not: "select A or B" 07:21 < kanzure> welp there's our answer folks 07:21 < JackH> helo: he is telling them what the best choice according to himself is, that is a huge difference 07:21 < JackH> again, having seen all this chat today, I no longer believe Hearn nor Gavin are having any intention of keeping Bitcoin going. They are either paid off or something else is happening 07:22 < adam3us> gavinandresen: i gave you an example of that in PM why this affects people. some people do not react well to stress. 07:22 < helo> JackH: again, rise above the conspiracy theories 07:22 * nsh nods 07:22 < morcos> JackH: thats obviously not the case, but I think they place different priorities on what's most important for the health of bitcoin 07:22 < hearn> JackH: lol, you're hilarious. "you are forcing people by talking to them" 07:22 < kanzure> helo: at what size of the bitcoin network do you think it would be prudent to watch out for conspiracies? 07:22 < JackH> helo: and they should rise above the craziness or pushing 20x the amount of data through nodes 07:22 * dgenr8 plans to go mine a hard fork, just for enlightenment. i can finally experience the thrill of mining bitcoin-ish 07:22 < helo> what you mention is possible, but not meaningfully actionable to any extent because there is no evidence 07:22 < kanzure> hearn: pretending to be an authority can be very damaging 07:23 < kanzure> hearn: companies are used to the authority model. it makes sense to them. 07:23 < JackH> hearn: if you think people dont implicitly trust you more than some random dude, you dont understand stardom. People will naturally listen to "core-devs" more. It is maybe wrong to say forced, but its definitely coerced 07:23 < helo> "convinced" 07:24 < hearn> it's quite debateable whether i'm a "core dev" or not. i've never much liked that label. it's about as well defined as the term "developer consensus" 07:24 < nsh> consent i'm sure will be giving willingly; informed-consent cannot be given by all 07:24 < hearn> if people listen to me or gavin, it's only because they think what we say makes sense. 07:24 < hearn> it's not like we have some kind of mind control rays 07:24 < kanzure> that sounds pretty close to "the development model doesn't match other systems or networks, therefore it must be wrong" 07:24 < JackH> hearn: if you had the best intentions, you would give people a choice without contacting them personally. You did not, thus we can assume you have another agenda 07:25 < hearn> rest assured, we have not and cannot contact everyone personally 07:25 < kanzure> hearn: you really think that the only reason that people listen to gavinandresen is because he makes sense? really? 07:25 < kanzure> you don't think that anyone, will ever make the mistake of trusting gavinandresen for reasons other than sensemaking? 07:25 < nsh> hearn, you can't discount that people must, by definition, but some degree of blind trust in the recommendations of developers 07:25 < nsh> because no-one can understand all the code 07:25 < JackH> I must however give it to you. You are admirable in your struggle to get everyone to switch to XT. Most people would have given up by now. 07:26 -!- zooko [~user@c-24-9-63-159.hsd1.co.comcast.net] has joined #bitcoin-wizards 07:26 < JackH> We had this conversation for what, 2 months now, reddit, bitcointalk, here in multiple channels, on sourceforge etc 07:26 < helo> i prefer the anti-occam theory that their contentious hard fork announcement is what they thought was the best way to get everyone riled up and tackling the scalability problem in earnest 07:26 * nsh nods 07:26 < helo> because in any case, that is what it is doing 07:26 < nsh> but, as said, it could transition from useful to counter-productive as people's anxieties rises 07:26 < nsh> *rise 07:27 < nsh> and we are trying to avoid that by making it seem less of a threat than a way to spur a multilateral process 07:27 < nsh> and that doesn't seem like much of a rhetorical compromise to be honest 07:27 < wallet42> hear: can xt nodes be pruned while still supporting getutxos? 07:27 < helo> the process has kicked off now, so yes... now would be a perfect time to back down and see what the process comes up with 07:28 < nsh> or soften the phrasing 07:28 < nsh> diplomatic words go a long way and cost little 07:28 < helo> WOTD 07:28 < helo> Q 07:28 < kanzure> the alternative is an immune response of massive proportions i think 07:28 < kanzure> alternatives (like in the presence of no disarming) should be better considered 07:29 < sturles> JackH: What is the point of switching to XT, except for the HD wallet features? I haven't seen the discussions you refer to. 07:29 < kanzure> i believe adam3us mentioned an interesting strategy of soft-forking the network ahead of a contentious partial hard-fork 07:30 < JackH> strules: there is no point of switching to XT at all 07:30 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 07:30 < JackH> XT is build to centralize Bitcoin in the hands of few people by killing off nodes 07:30 < sturles> Hmm, yes. It relays and highlights double spends. That's a feature. 07:30 -!- cosmo [~james@unaffiliated/cosmo] has joined #bitcoin-wizards 07:30 < sturles> Huh? In which way does Bitcoin XT centralize anything? 07:31 -!- damethos [~damethos@unaffiliated/damethos] has quit [Remote host closed the connection] 07:33 < JackH> sturles: go ahead and download 20mb every 10 min. Let me know how it works for you relaying that at the same time 07:33 < kanzure> (also, communication is a form of mind control; it's how you control the perceptions of others and communicate or relay information. audio and vocal communication uses mechanical vibrations that are often emitted from other forms of rays.) 07:33 < kanzure> ((perhaps my favorite is ultrasound rays)) 07:33 < sturles> JackH: You are talking in riddles. Bitcoin XT doesn't download 20 MB every minute. 07:33 -!- zooko` [~user@c-24-9-63-159.hsd1.co.comcast.net] has joined #bitcoin-wizards 07:34 < JackH> not yet 07:34 < JackH> it is supposed to 07:34 < adam3us> kanzure: i didnt put much thought into it but it might be possible yes. 07:34 < JackH> basically its a "patch" that is supposed to knock out nodes in the network 07:34 < JackH> it will then be cheap to ringfence the rest of the network with malicious nodes and serve crap data 07:35 < JackH> and then its bye bye Bitcoin 07:35 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Ping timeout: 250 seconds] 07:35 -!- instagibbs [417d1202@gateway/web/freenode/ip.65.125.18.2] has quit [Quit: Page closed] 07:35 < gavinandresen> JackH: I thought I just said the patch I was working on is 8MB....... 07:35 < sturles> JackH: Ah, you haven't grasped the basic concepts of bitcoin yet, it seems. Sure you didn't mean to be in #bitcoin-clueless? 07:35 < GAit> hearn: you and Gavin have been the most public media friendly developers around Bitcoin, people aren't following you because you are right but because you are more famous. gavinandresen, you should follow the consensus process with the BIP, not threaten to hard fork if things don't go your way oki doki 07:35 < JackH> gavinandresen: if that is the case then we are all the sudden aligned in what we want 07:35 -!- zooko [~user@c-24-9-63-159.hsd1.co.comcast.net] has quit [Ping timeout: 264 seconds] 07:36 < JackH> if you work on some of jgarzik proposals then I think it is a completely different situation 07:37 < JackH> if we get the chance to review the code, and not having it stuffed on us, and it sounds feasible in terms of increasing the block size, well then that is a completely different talk 07:37 < sturles> JackH: Bitcoin XT doesn't even support 20 MB blocks, and what you write now is the opposite of what the devopers wite here, so I don't get it. What is your _real_ problem with Bitcoin XT? 07:37 < JackH> and if its a BIP, that would be even better ;) 07:37 < kanzure> sturles: nobody cares that there is another patch set out there, really. nobody has ever brought that up as a problem. 07:37 < sturles> For a merchant the double spend detection feature is a good one. 07:38 < GAit> gavinandresen: I think is important to bring things back to collaborative state, no forced hard forking 07:38 < hearn> there will be a chance to review the code and comment on it before it's merged into XT, there will be a BIP and it's very likely that patch+bip will be for 8mb+stuff, which is, i think, what has been said all along. 07:38 < sturles> kanzure: What patch set? 07:38 < kanzure> sturles: xt is a patch set.... 07:38 < GAit> hearn: the problem is your going ahead regardless of NACK 07:38 < kanzure> GAit: no, it's convincing companies regardless of NACKs 07:39 < adam3us> so here's a thought what if jgarzik and gavinandresen pooled BIPs. 07:39 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards 07:39 < adam3us> they seem moderately similar and gavinandresen seemed reasonably ok with jgarzik's current parameters. 07:39 -!- GAit [~lnahum@2-230-161-158.ip202.fastwebnet.it] has left #bitcoin-wizards [] 07:39 < adam3us> combined them. 07:39 -!- GAit [~lnahum@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards 07:39 < adam3us> make BIP 102 out of 100+101 07:40 < JackH> Gavin and Hearn, I think you may also misunderstand people here. What we dont want is fragmentation and the possibility of the network effort to diminish in any way. 07:40 < GAit> adam3us: that would be great, collaboration between jeff and gavinandresen but is important gavinandresen calls off the contentious no matter what hard fork in XT, I am not sure Mike is prepared to support problems when they inevitably arise 07:41 -!- darwin__ [~darwin@88-103-255-166.jes.cz] has quit [Read error: Connection reset by peer] 07:41 < GAit> fragmenting a blockchain is much worse than fragmenting an open source project 07:41 < JackH> And by network effort, I mean, risking miner amounts and node amounts 07:41 < helo> back in P2SH days, there was some dissent (luke). the majority of the devs discussed and decided on a particular approach, and the minority dissenting devs aquiesced. 07:41 < adam3us> helo: exactly. 07:41 < kanzure> GAit: unfortunately they have both demonstrated an inability to understand "forking an opne-source repository" and "forking a blockchain using a contentious hard-fork". 07:42 < helo> luke never went on a big PR campaign to convince the ignorant masses and force a change that most developers disagreed with, although he could have 07:42 -!- darwin_ [~darwin@88-103-255-166.jes.cz] has joined #bitcoin-wizards 07:42 < kanzure> helo: i believe there were some differences there like limitations on the damage that could be caused or something, so the others were okay because of that reason 07:42 < kanzure> (not entirely sure i remember the details correctly?) 07:42 -!- nwilcox [~nwilcox@68.233.157.2] has joined #bitcoin-wizards 07:43 < kanzure> GAit: whoops i mean that the two things i quoted are different topics 07:43 < GAit> kanzure: here's hoping that people can come to a more collaborative approach. gavinandresen is declaring "WAR" to bitcoin core if he goes ahead with his contentious hard fork 07:43 < kanzure> GAit: right; and it's not related to forking the open-source project. it's related to campaigning companies to run a contentious hard-fork. 07:44 < adam3us> kanzure: "forking an opne-source repository" and"forking a blockchain using a contentious hard-fork". no i think thats not accurate. gavin said in answer to this kind of question on panel discussion etc that in his view others would see the trend line and follow it. 07:44 < kanzure> adam3us: please continue/elaborate 07:44 -!- zooko` is now known as zooko 07:45 < adam3us> the point is more that we should strive for minimum dissent as it is the fact that people are upset and feel overruled or that th ebest proposal might not win that they would go propose alternatiave and also lobbyg companies or make soft-forks to break the hard-fork in flight. 07:45 -!- cosmo [~james@unaffiliated/cosmo] has quit [Remote host closed the connection] 07:45 < kanzure> for example, are you saying that he thinks that the companies he campaigns to are going to see the trend of the other companies following, therefore they will adopt the hard-fork and the rest of the network wont? 07:45 < adam3us> we minimise that if we get into a constructive mode of working in development 07:45 < kanzure> i agree that constructive mode minimizes that 07:46 < adam3us> (not to put words into gavinandresen mouth) but i understood from what was he thinks that game-theory wise its too much of a loss that everyone would get on the same page or risk armageddon. 07:46 < kanzure> right, that's what makes it a nuclear threat 07:46 < adam3us> which is why i characterised it as a game of chicken. 07:46 < kanzure> indeed..... 07:46 < hearn> a vote is not a "nuclear threat". 07:46 < kanzure> it's not a vote 07:46 < adam3us> kanzure: yes its a risk calculus something kind of like the risk of mutual assured destruction. some is expected to back down 07:46 < GAit> hearn: this is not a vote 07:46 < Eliel> GAit: I think it's unfair to call XT a "contentious no matter what hard fork". It's not "no matter what" since there's the 75% threshold that's required for an actual chain fork to happen. 07:47 < GAit> Eliel: what thereshold, the block version and some two weeks grace period? miners can game that all they want 07:47 < kanzure> Eliel: xt is not a contentious hard-fork. that's wrong. 07:47 < Mably> just wondering: aren't the miners the ones who decide at the end? 07:47 < kanzure> Eliel: xt is a fork of an open-source repository. it's unrelated to what we're talking about. 07:47 < kanzure> it is wrong to characterize forks of an open-source repository as causing a contentious hard-fork 07:48 < GAit> Eliel: the problem is that gavinandresen and hearn are threatening the security of the blockchain by going by hard forking without any technical consensus from the people most familiar with the details and with the people that contributed the most, is that not enough? 07:48 < kanzure> anyone can generate an unlimited quantity of open-source repository forks 07:48 < kanzure> without damaging the network 07:48 < GAit> running XT with 20MB patches is a contentious hard fork 07:48 < Eliel> kanzure: I'm quite aware of what the difference is in forking a repository and forking the blockchain. Thank you very much. 07:48 < kanzure> Eliel: alright 07:49 -!- wallet42 [~wallet42@85.100.40.253] has quit [Quit: Leaving.] 07:49 < Mably> Won't you have to convince more than 50% of the mining power to run XT for the hard fork to succeed? 07:49 < kanzure> what do you mean by "succeed"? 07:50 < Mably> longuest chain 07:50 < Eliel> Mably: over 75% is what the code will require before it even makes an attempt. 07:50 < Mably> Ah ok 07:50 < kanzure> there's ways around that, like hardcoded checkpoints (someone threatened this recently) (adam3us might remember who?) 07:50 < hearn> GAit: for what it's worth i have been around longer and written vastly more code than any of {adam,gregory,peter todd,etc}. that code included a reimplementation of bitcoin in another language. so, i rather think we are quite familiar with the details and are amongst those who are contributed the most. 07:50 < kanzure> what are you replying to 07:51 < kanzure> as far as i can tell that does not answer any question GAit has ever asked you 07:51 -!- Quanttek [~quassel@ip1f10af17.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards 07:51 -!- SDCDev [~quassel@unaffiliated/sdcdev] has quit [Ping timeout: 276 seconds] 07:51 < Mably> Eliel: could you explain your 75%? 07:51 < hearn> his message to eliel 07:52 < kanzure> looking 07:52 < GAit> hearn: writing an SPV library is quite different from core work, you are not the first nor only one 07:52 < GAit> hearn: but again, irrelevant to the current discussion, which is going ahead with nuclear threats 07:52 < kanzure> yeah, i don't think your response to GAit's message to Eliel makes any sense. 07:53 < adam3us> kanzure: must've been someone else i dont remember hardcoded checkpoint. i think. could be misunderstanding what you mean 07:53 < kanzure> okay, yeah nevermind 07:53 < kanzure> i'll drop it since i can't cite it 07:53 < hearn> GAit: bitcoinj also has code to do full verification in it 07:53 < hearn> GAit: but the SPV mode is the focus, indeed. 07:53 < hearn> GAit: regardless, i was the first actually 07:54 < helo> direct democracy on a global scale is probably one of the worst approaches to deciding anything 07:54 < hearn> GAit: so you have said several things now that just aren't correct. and by the way, i've done work on Core too. for instance i proposed and then implemented support for leveldb 07:54 < GAit> hearn: is this an ego problem? you are good enough but your proposal are scary and risky, we can work on them with consensus, why threatening the others? 07:54 < hearn> along with designing BIP70, proposing and working on the design for Bloom filtering, etc 07:55 < adam3us> kanzure: but it seems plausible that someone so minded could harden existing code to against in-flight hard-fork in various ways. i don thtink anyone put a lot of thought into it. 07:55 < hearn> anyway, my point is, your comment about "without consensus by those most familiar with the details and the people that contributed the most" is really not that accurate nor helpful 07:55 < helo> hearn: my grandma's vote on what codebase to run is absolutely worthless 07:55 < GAit> hearn: i didn't mean to minimize your contributions to non consensus code but this area you are touching now is dangerous (and there have been problems with the leveldb migration if im not mistaken) 07:56 < hearn> no 07:56 < helo> popular vote is a terrible way to decide policy 07:56 < gavinandresen> GAit: Mike wrote the first draft of the BIP that is the March 15 fork post-mortem.... 07:56 < kanzure> it's not really even policy 07:56 < kanzure> it's wrong to misconstrue this as policy 07:56 < hearn> GAit: as a refresher, BDB had design problems in it that made it hopelessly unsuitable for consensus work. Satoshi did not know that, and nor did we until the network spontaneously forked. 07:57 < adam3us> GAit: i think its not correct to blame mike for the leveldb.. he checked it in but others changed much afterwards, no one saw it coming. 07:57 < hearn> GAit: specifically, BDB could get itself into a position where two nodes, given the same inputs, could arrive at different decisions about a block! 07:57 < kanzure> so are you trying to say that "because we have written bips in the past, companies should be safe listneing to us for all time in the future"? 07:57 < hearn> GAit: LevelDB is a vastly better codebase and did not suffer such problems. good thing i proposed we use it, no? 07:57 < GAit> adam3us: I don't think I blamed him, I am suggesting that consensus related changes are dangerous 07:57 < adam3us> GAit: fair enough. and this is a very relevant point right now. 07:57 < GAit> nowhere in my phrasing i suggested Mike is at fault for it 07:57 < gavinandresen> I'll say it: not all developers have experience scaling up systems. I listen much harder to those who do. 07:58 < hearn> GAit: as LevelDB improved consensus robustness quite dramatically. unfortunately, bdb exploded before the LevelDB rollout was complete 07:58 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 07:58 < gwillen> kanzure: here's the message where mike threatened hardcoded checkpoints to fork off 50+% of chinese miners: http://sourceforge.net/p/bitcoin/mailman/message/34162353/ 07:58 < GAit> gavinandresen: i doesn't seem like you are listening at all to the rest of the core team 07:59 < GAit> hearn: details, the point is that consensus changes are dangerous, stop thinking everyone is here to bite you or stop getting your *ego* in the way 07:59 < zooko> Hi, gwillen! 07:59 < gwillen> zooko: \o 07:59 < hearn> sigh. GAit, I am answering your concerns. you have said several times that gavinandresen and myself are ignoring experts who understand the details. when i told you about our own expertise, suddenly we're guilty of being all about ego. 07:59 < hearn> there is no way to satisfy you, i think 08:00 < zooko> hearn: In my opinion, you could just stop replying to GAit on this channel, at least for now, and nothing bad would happen. 08:00 < hearn> yeah, i'm getting rather tired of it myself. 08:00 -!- SDCDev [~quassel@unaffiliated/sdcdev] has joined #bitcoin-wizards 08:00 < zooko> No offense, GAit, but while I sympathize with your concerns, I don't think your current comments are helping. 08:00 < gavinandresen> GAit: so... some of the core team was pretty busy with their own projects, and there was no feedback to listen to. I am ALWAYS happy to listen. I reserve the right to disagree.... 08:00 < kanzure> there was lots of feedback; look at the timestamps 08:00 < kanzure> they were doing sidechain last minute work plus also commenting everywhere 08:01 < kanzure> there were volumes of text written on reddit, for example 08:01 < GAit> forget one second about the block size increase, you are underestimating the dangers of hard forks without consensus, I don't get why we don't put that option away from the table 08:02 < temujin> just fork the network already so i can buy $70 coins again and profit off the recovery 08:02 < GAit> it's like having a guy with the gun pointed at you, it makes everything more stressful 08:02 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Ping timeout: 255 seconds] 08:03 < zooko> GAit: I'm sorry you're feeling high anxiety. That makes it hard to do good work. 08:03 < GAit> you were quite quick to attack my qualitative assessment of contributions to core but very slow [read never] to answer about putting down the nuclear option 08:03 < moa> i'd rather listen to the people who actually making commits and technical contributions than al the part-timers who use threats and drama 08:03 < Eliel> gwillen: it's unfair to characterize that message as a (personal) threat. It's a potential scenario that's not completely impossible, that might happen regardless of whether mike does anything to push things that way or not. 08:04 < adam3us> moa: i get the concern. but we should acknowledge that gavinandresen wrote a ton of the code (if you look at github stats) etc. 08:04 < helo> gavinandresen: disagree as much as you want, but you should do what excellent bitcoin developers in the past have done, and ultimately go along with developer consensus. please, can't you publicly withdraw your contentious hardfork threat? 08:05 < GAit> gavinandresen: i also ask to please withdraw the contentious hardfork threat 08:06 < helo> your view deserves its equal consideration, and will get it 08:06 < helo> your proposal does not deserve to overcome the others based on your own popularity 08:07 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 08:07 -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] 08:07 < helo> which is what a public vote (or patched bitcoin xt release) would be. 08:08 < zooko> FWIW, I think adam3us's email has unnecessarily alarmed you, and that you are not actually in dire danger and you do not actually need to urgently plead and persuade someone else to do something or not-do-something in order to save yourself. 08:08 < Eliel> GAit: even if gavin withdraws this so called "threat", people are still liable to jump ship to an altcoin that is able to scale if nothing happens in Bitcoin Core. 08:08 < GAit> Eliel: one would think that if the alt is scalable people would notice and update bitcoin long before the alt takes over 08:08 < kanzure> zooko: there was an actual threat email, you know. this was before adam3us' email. 08:08 < GAit> or if the alt is better and bitcoin can't be fixed, i say so be it 08:09 < Eliel> GAit: yep, and that situation is almost exactly the same. The only difference is the name of the altcoin. 08:09 < GAit> zooko: the danger is very real, people failing to see dangers in contentious hard fork != no danger 08:10 -!- cosmo [~james@unaffiliated/cosmo] has joined #bitcoin-wizards 08:11 -!- NewLiberty [~NewLibert@2602:304:cff8:1580:2d49:e35d:dbf8:2fed] has quit [Ping timeout: 265 seconds] 08:11 -!- wallet42 [~wallet42@85.100.40.253] has joined #bitcoin-wizards 08:11 -!- zooko` [~user@c-24-9-63-159.hsd1.co.comcast.net] has joined #bitcoin-wizards 08:11 < kanzure> zooko: specifically there was mention of campaigning to companies to run a hard-fork patchset that had received nacks.... this was sent before adam3us' email. 08:11 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Ping timeout: 264 seconds] 08:12 < Eliel> GAit: the point I'm making is that it'd only be a false sense of security that resulted if gavin withdrew his plan. 08:13 -!- zooko [~user@c-24-9-63-159.hsd1.co.comcast.net] has quit [Disconnected by services] 08:13 -!- zooko` is now known as zooko 08:13 -!- lnsybrd [~lnsybrd@fwsm-io-azp-dmz.phx1.ip.io.com] has joined #bitcoin-wizards 08:14 < Eliel> If gavin and hearn don't go through with Bitcoin XT plans, the most likely scenario is more fragmentation of the community than with it. 08:14 < zooko> kanzure: I am aware. 08:15 < Eliel> (assuming of course, that bitcoin core doesn't get anything done in regards to scaling implementation) 08:15 < kanzure> zooko: alright 08:17 < adam3us> back in a bit. getting hungry 08:17 -!- jtimon [~quassel@137.30.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards 08:18 < Eliel> From my point of view, Bitcoin XT hard fork is a necessary plan B. Plan A being that Bitcoin Core implements something that solves the issue. 08:18 < gavinandresen> helo: I already said I'm happy to go along with developer consensus, if such a consensus emerges. But I am not happy to sit on my hands and do nothing in case there is no clear consensus, doing that would, in my humble opinion, be irresponsible. 08:18 < gavinandresen> ... and now I'm going to go back to writing regression tests.... 08:18 < helo> o/ 08:18 < GAit> gavinandresen: are you taking responsability for any loss caused by the fork? 08:19 < kanzure> what 08:19 < GAit> saying if consensus emerges otherwise i will do X is akin to say that you don't consider a possibility where status quo + plan is consensus 08:19 -!- instagibbs [417d1202@gateway/web/freenode/ip.65.125.18.2] has joined #bitcoin-wizards 08:19 < gavinandresen> GAit: nope, if you are an idiot and refuse to upgrade when your software tells you it is time to upgrade then I have no sympathy. 08:20 < zooko> gavinandresen: Write good regression tests! 08:20 < GAit> what makes you think that core won't also upgrade the block version and cut off connectivity to XT? 08:20 < GAit> to even higher so that XT will tell you upgraden and you'd be an idiot not to 08:20 < gavinandresen> GAit: I think Wladimir would NACK that. 08:21 < GAit> in a situatuon where you need to protect the network and it requires a small change without soft or hard fork I'd say people may consider such things, node operators and miners could do such thing without asking Wlad 08:22 < GAit> it's quite simple to recognize XT with its getutxo, you'd have to make it look as much as possible to core 08:22 < GAit> it's a war 08:22 < GAit> which nobody wants 08:22 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 08:23 < gavinandresen> gotta ignore everybody now and write some code..... 08:23 < GAit> which could cause a fork of XT miners earlier than real threshold 08:23 < Eliel> GAit: treating it like a war will only serve to make things worse. 08:23 < GAit> gavinandresen: you shouldn't ignore security concerns about contentious hard forks, i'm sorry, you are being unresonable 08:23 < GAit> Eliel: people won't sit waiting for Gavin to destroy things 08:23 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 08:23 -!- instagibbs [417d1202@gateway/web/freenode/ip.65.125.18.2] has quit [Client Quit] 08:24 -!- blackwraith [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 08:24 < GAit> not that he wants to but it's one of the possible outcomes 08:24 -!- blackwraith [~priidu@unaffiliated/priidu] has quit [Client Quit] 08:25 -!- eennaam [~eennaam@unaffiliated/eennaam] has joined #bitcoin-wizards 08:26 < Eliel> GAit: things blowing up is a possible outcome even if gavin does nothing. More likely in that case I think. 08:26 < GAit> Eliel: consensus disagrees, but good attempt 08:26 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Ping timeout: 246 seconds] 08:28 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: This computer has gone to sleep] 08:28 -!- melvster1 [~melvster@ip-89-176-99-192.net.upcbroadband.cz] has joined #bitcoin-wizards 08:29 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 08:30 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 08:30 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 08:31 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 08:31 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 08:31 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 08:32 -!- badmofo [~badmofo@btc.alpha61.com] has quit [Remote host closed the connection] 08:33 -!- badmofo [~badmofo@ec2-177-71-246-238.sa-east-1.compute.amazonaws.com] has joined #bitcoin-wizards 08:33 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 08:33 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 08:35 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 08:35 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 08:35 -!- hearn [~mike@77-59-61-48.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 08:36 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 08:36 -!- jae [~jae@c-98-234-63-169.hsd1.ca.comcast.net] has joined #bitcoin-wizards 08:37 -!- jae is now known as Guest31906 08:37 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 08:38 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 08:39 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 08:39 < richardus> mr. gavin please be sure to use your key to advertise bitcoin xt 08:40 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 08:41 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 08:45 -!- wallet42 [~wallet42@85.100.40.253] has quit [Quit: Leaving.] 08:45 -!- wallet42 [~wallet42@85.100.40.253] has joined #bitcoin-wizards 08:47 -!- dEBRUYNE [~dEBRUYNE@239-196-ftth.onsbrabantnet.nl] has quit [Ping timeout: 255 seconds] 08:47 < wallet42> gavinandresen, sorry one more question: will I be able to run a pruned XT node which supports getutxos? 08:50 -!- badmofo [~badmofo@ec2-177-71-246-238.sa-east-1.compute.amazonaws.com] has quit [Quit: Leaving] 08:51 -!- Guest31906 [~jae@c-98-234-63-169.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 08:52 -!- Quanttek [~quassel@ip1f10af17.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 08:55 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 08:56 -!- badmofo [~badmofo@ec2-177-71-246-238.sa-east-1.compute.amazonaws.com] has joined #bitcoin-wizards 08:57 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 08:57 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 08:59 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 08:59 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 09:00 -!- dEBRUYNE [~dEBRUYNE@239-196-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards 09:00 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 09:00 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 09:01 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 09:02 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 09:05 -!- nwilcox [~nwilcox@68.233.157.2] has quit [Ping timeout: 244 seconds] 09:07 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Ping timeout: 264 seconds] 09:17 -!- eudoxia [~eudoxia@r167-57-87-222.dialup.adsl.anteldata.net.uy] has quit [Ping timeout: 256 seconds] 09:17 -!- nwilcox [~nwilcox@68.233.157.2] has joined #bitcoin-wizards 09:19 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-ofwrzulehbykpakt] has quit [Ping timeout: 265 seconds] 09:20 -!- JackH [~Jack@host81-154-202-222.range81-154.btcentralplus.com] has quit [Ping timeout: 250 seconds] 09:20 -!- c0rw|away is now known as c0rw1n 09:21 -!- dc17523be3 [~unknown@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards 09:22 -!- hearn [~mike@77-59-46-44.dclient.hispeed.ch] has joined #bitcoin-wizards 09:23 -!- _biO__ [~biO_@ip-37-24-195-112.hsi14.unitymediagroup.de] has joined #bitcoin-wizards 09:26 -!- dc17523be3 [~unknown@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 246 seconds] 09:28 -!- hearn_ [~mike@84-75-197-78.dclient.hispeed.ch] has joined #bitcoin-wizards 09:30 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 09:30 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 09:31 -!- hearn [~mike@77-59-46-44.dclient.hispeed.ch] has quit [Ping timeout: 256 seconds] 09:31 -!- hearn_ [~mike@84-75-197-78.dclient.hispeed.ch] has quit [Read error: Connection reset by peer] 09:32 -!- chmod755 [~chmod755@unaffiliated/chmod755] has quit [Quit: Leaving] 09:32 -!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has joined #bitcoin-wizards 09:33 -!- Mably [56401ec5@gateway/web/freenode/ip.86.64.30.197] has quit [Quit: Page closed] 09:33 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 09:33 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 09:34 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 09:35 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 09:35 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 09:36 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 09:37 -!- _biO_ [~biO_@80.156.183.43] has quit [Remote host closed the connection] 09:37 -!- _biO__ is now known as _biO_ 09:37 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 09:38 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 09:38 -!- nwilcox [~nwilcox@68.233.157.2] has quit [Ping timeout: 256 seconds] 09:39 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 09:39 -!- melvster1 [~melvster@ip-89-176-99-192.net.upcbroadband.cz] has quit [Remote host closed the connection] 09:39 -!- nwilcox [~nwilcox@68.233.157.2] has joined #bitcoin-wizards 09:39 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 09:40 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 09:40 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 09:42 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 09:42 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 09:42 -!- mjerr [~mjerr@p578EB3B1.dip0.t-ipconnect.de] has joined #bitcoin-wizards 09:43 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 09:43 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 09:43 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 09:44 -!- jtimon [~quassel@137.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 265 seconds] 09:44 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 09:44 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-wizards 09:44 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host] 09:44 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards 09:45 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 09:46 -!- dc17523be3 [~unknown@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards 09:46 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 09:50 -!- dc17523be3 [~unknown@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 256 seconds] 09:51 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-pwfugkqztmbazalo] has joined #bitcoin-wizards 09:51 -!- hearn_ [~mike@84-75-197-78.dclient.hispeed.ch] has joined #bitcoin-wizards 09:53 -!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has quit [Ping timeout: 252 seconds] 09:54 -!- Quanttek [~quassel@ip1f10af17.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards 09:58 -!- Mably [~Mably@unaffiliated/mably] has joined #bitcoin-wizards 09:59 -!- zooko` [~user@c-24-9-63-159.hsd1.co.comcast.net] has joined #bitcoin-wizards 10:00 -!- zooko [~user@c-24-9-63-159.hsd1.co.comcast.net] has quit [Disconnected by services] 10:00 -!- zooko` is now known as zooko 10:04 -!- hearn_ [~mike@84-75-197-78.dclient.hispeed.ch] has quit [Read error: Connection reset by peer] 10:05 -!- antanst [~Adium@adsl-66.37.6.208.tellas.gr] has joined #bitcoin-wizards 10:07 -!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has joined #bitcoin-wizards 10:14 -!- Quanttek [~quassel@ip1f10af17.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 10:17 -!- Quanttek [~quassel@ip1f10af17.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards 10:27 -!- gill3s [~gill3s@pat35-3-82-245-143-153.fbx.proxad.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 10:28 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-oiylulkoqynrofdo] has joined #bitcoin-wizards 10:29 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards 10:30 -!- zooko` [~user@c-24-9-63-159.hsd1.co.comcast.net] has joined #bitcoin-wizards 10:32 -!- zooko [~user@c-24-9-63-159.hsd1.co.comcast.net] has quit [Ping timeout: 252 seconds] 10:33 -!- zooko` is now known as zooko 10:33 -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards 10:34 -!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 10:36 < hulkhogan_> that was quite a read... 10:37 < hulkhogan_> gmaxwell: earlier, were you speaking of a mixnet for bitcoin transactions? imo it would be easy to hack up in python with some hardcoded nodes, possibly with p2p/discovery to find other mixers ... simple design might be too simple, though 10:38 <@gmaxwell> hulkhogan_: should be super easy. 10:39 < hulkhogan_> gmaxwell: awesome, appreciate that, i think i have time to fiddle on it a bit today actually... will update if something fruitful is produced. 10:39 < kanzure> wouldn't it need to be sybil resistant? 10:40 < hulkhogan_> kanzure: yea... this is one of the things i didn't think about wrt simple design, i think so /but/ there might be some encryption tricks that make snooping on relayed transactions harder 10:41 < hulkhogan_> i was planning on reading the mixmaster papers a bit to see how they figured that stuff out. 10:41 -!- antanst [~Adium@adsl-66.37.6.208.tellas.gr] has left #bitcoin-wizards [] 10:41 <@gmaxwell> if it's hardcoded its inherently sybil resistant. 10:41 < kanzure> well i'm sure it's at minimum the usual tricks: increase the size and diversity of your anonymity set, increase your tolerance for ridiculously long delays, etc. 10:41 <@gmaxwell> My recommendation would be to make the network itself only reachable over tor. Therefor the lower bound on privacy is that which is provided by tor. 10:42 < kanzure> (if using tor correctly) 10:42 < hulkhogan_> well, and this is off the deep end because i havent done any reading-- what if you encrypted the transactions up until the last hop/hardcoded node? 10:43 < hulkhogan_> that might preserve privacy, but the first daemon/server you pinged might also ID you, so yes tor support should be baked in 10:43 <@gmaxwell> hulkhogan_: thats what a mixmaster like system would do, an unfortunate issue there is that you can't then use the validity of the transaction as your anti-dos token. 10:43 < kanzure> i agree that hardcoding is a nice solution, and it doesn't seem particularly dangerous here 10:43 < hulkhogan_> gmaxwell: you might have trusted entry nodes that validate + encrypt, but thats a pretty bad idea, wrt privacy 10:43 <@gmaxwell> which isn't the end of the world or anything. 10:44 < kanzure> well, the privacy alternative is much worse actually 10:44 <@gmaxwell> hulkhogan_: that kinda moots the encryption part, might as well have a one hop network then. 10:44 < kanzure> so trusting some random group of people is an additional option that is presently unavailable in other schemes 10:44 < kanzure> er, i'm sure there's a better way for me to word that 10:44 < hulkhogan_> let me think some more... very unbaked thoughts 10:45 <@gmaxwell> and a one hop network wouldn't be a bad starting point. e.g. single server, you reach over tor. You send it 64KB every 5 minutes... either a real transaction, if you have one, or a randomly selected new mempool txn, or nothing. then according to parameters set with the transaction it randomly dequeues into the network. 10:45 < hulkhogan_> well, what if the last node was the node you encrypt to- that way you decrypt + verify at the last hop? 10:46 < hulkhogan_> hmm 10:47 < hulkhogan_> could you explain some of those params, 64KB, 5minutes, i'm not completely following there 10:48 -!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards 10:48 < hulkhogan_> also, is this something that needs to be set behind a hidden service? i feel there might be a simpler way to accomplish the goal ... the simple case, basically 10:49 < kanzure> 5 minutes is probably for the delay attribute 10:49 -!- zooko` [~user@c-24-9-63-159.hsd1.co.comcast.net] has joined #bitcoin-wizards 10:49 < kanzure> otherwise if you send everything as fast as possible there's timing attacks and correlations that are much easier 10:49 < hulkhogan_> yea, bulk sends etc 10:49 < hulkhogan_> right, if possible i'd like to keep tor support as a feature for later 10:49 < hulkhogan_> (lots of gotchas) 10:50 -!- www [~v3@p50897479.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds] 10:50 -!- zooko [~user@c-24-9-63-159.hsd1.co.comcast.net] has quit [Ping timeout: 246 seconds] 10:50 < kanzure> http://diyhpl.us/~bryan/papers2/security/Comparison%20Between%20Two%20Practical%20Mix%20Designs%20-%202004.pdf 10:51 < kanzure> http://diyhpl.us/~bryan/papers2/security/The%20Pynchon%20Gate:%20A%20secure%20method%20of%20pseudonymous%20mail%20retrieval%20-%20Len%20Sassaman%20-%20Bram%20Cohen%20-%20Nick%20Mathewson.pdf 10:51 < hulkhogan_> here's the easy case: run a daemon that accepts tx's from other daemons, that eventually forwards it to a hardcoded node that sends it on the network 10:51 < kanzure> http://diyhpl.us/~bryan/papers2/security/Towards%20an%20information%20theoretic%20metric%20for%20anonymity%20-%202004.ps 10:52 -!- Emcy [~MC@unaffiliated/mc1984] has quit [Ping timeout: 256 seconds] 10:52 < hulkhogan_> so p2p-bitcoin-tx-submission-as-a-p2p-service... privacy guarantees are hard to say with the scheme, but tor support would be a plus 10:52 < hulkhogan_> heh, thanks kanzure, i'll cache those for later reading :) 10:55 -!- zooko` is now known as zooko 10:58 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 10:59 < hulkhogan_> also, wrt sybil: you can just create arbitrary entry critera (like uptime, pow) to limit that 10:59 < hulkhogan_> think uptime is used for tor guard nodes, so something along those lines 11:02 -!- nessence [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Ping timeout: 244 seconds] 11:03 <@gmaxwell> hulkhogan_: tor has a centeralized trust model, makes many thing easier! 11:04 < hulkhogan_> yeah, and for this project it makes sense to keep the trust within a few known params (hardcoded) (at least, initally, to get started..) 11:08 < hulkhogan_> but i think its a good effort, having a p2p-like system to submit txes is useful.. some block explorers expose this... indeed it can be useful for masking the originating node/IP (if you use a VPN) and a more robust/accessible soln would be useful.. 11:09 -!- JackH [~Jack@host-80-43-142-154.as13285.net] has joined #bitcoin-wizards 11:10 -!- droark [~droark@209-6-53-207.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #bitcoin-wizards 11:13 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.] 11:15 -!- SubCreative [~SubCreati@2601:601:400:1f04:25d5:1ff0:7178:1a09] has joined #bitcoin-wizards 11:15 -!- SubCreative [~SubCreati@2601:601:400:1f04:25d5:1ff0:7178:1a09] has quit [Changing host] 11:15 -!- SubCreative [~SubCreati@unaffiliated/cannacoin] has joined #bitcoin-wizards 11:16 -!- droark [~droark@209-6-53-207.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has quit [Quit: Later.] 11:17 -!- nessence [~alexl@166.170.23.115] has joined #bitcoin-wizards 11:20 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 255 seconds] 11:20 < nickler> is the purpose of this network to hide the origin of a transaction from the network peers? 11:22 -!- nwilcox [~nwilcox@68.233.157.2] has quit [Ping timeout: 276 seconds] 11:23 <@gmaxwell> nickler: correct. 11:24 -!- nwilcox [~nwilcox@68.233.157.2] has joined #bitcoin-wizards 11:24 <@gmaxwell> nickler: there is existing functionality in bitcoin core (0.11+) to not relay transactions created by the local wallet, which allows some rpc-speaking daemon to go handle it for you 'somehow'. 11:24 < kanzure> does it continue to not relay beyond a restart? 11:28 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds] 11:30 <@gmaxwell> yes. until you switch the option back, unless there is some bug. 11:33 < nickler> I just want to remark that according to my calculations, 'trickling' does a surprisingly good job. Assume an attacker is connected to all peers of node A and we assume a reasonably small prior probability that the tx originated from A. 11:33 < nickler> So if an attacker first gets the transaction from A the posterior is still negligible. 11:33 < nickler> Trickling doesn't help of course when the attacker is connected to all nodes, as this University of Luxemburg paper showed 11:34 -!- gill3s [~gill3s@pat35-3-82-245-143-153.fbx.proxad.net] has joined #bitcoin-wizards 11:35 < nickler> The paper 'Deanonymisation of clients in Bitcoin P2P network' by biryukov et al. 11:35 -!- darwin_ [~darwin@88-103-255-166.jes.cz] has quit [] 11:35 <@gmaxwell> nickler: yes, but it creates incentives to sybil attack the network, which we've seen commercial entities doing. :( 11:36 <@gmaxwell> nickler: the trickling also loses its effectiveness fairly quickly when transactions are repeated. 11:36 -!- rubensayshi [~ruben@91.206.81.13] has quit [Remote host closed the connection] 11:37 < nickler> ok, just wanted to learn the purpose of the mixnet 11:37 <@gmaxwell> ::nods:: 11:37 < nickler> you mean repeated broadcasting 11:37 < nickler> ? 11:37 -!- Xh1pher [~Xh1pher@pD9E38632.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 11:37 <@gmaxwell> nickler: actually no, I meant when a single party transacts many times (with linkable transactions). But it also applies to rebroadcast if the transaction doesn't confirm. 11:38 < nickler> yeah linkable transactions would really degrade trickling 11:39 <@gmaxwell> nickler: right, and people will make small payments to old addresses to increase linkability. 11:39 < nickler> speaking of that, are there already ideas how to get unlinkability onto a sidechain? :D 11:40 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 11:40 < zooko> speaking of that, here's a new blog post, fresh from the oven: 11:41 < zooko> https://leastauthority.com/blog/zerocash_and_confidential_transactions.html 11:41 <@gmaxwell> nickler: what kind of unliability? (like do you mean make the transaction to the sidechain unlinkable? or unlinkable transactions on the sidechain?) 11:41 < nickler> gmaxwell: the latter 11:43 <@gmaxwell> nickler: step 1. take your particular scheme, step 2. put in sidechain? :P dunno if you saw, elements/alpha has a kind of privacy scheme. By itself it doesn't create transaction unlinkability, but it can be combined with coinjoin and/or coinswap. It's certantly not the only way to do improved privacy/fungibility, see zooko's link. :) 11:43 -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards 11:44 < nickler> gmaxwell: could something like monero style ringsigs be reasonably implemented in bitcoin? 11:45 <@gmaxwell> Sure, though I think CT+CJ is strictly superior. 11:45 <@gmaxwell> (to the bytecoin/monero approach) 11:46 <@gmaxwell> though there are a number of ways to improve that approach, e.g. the combination with OWAS is really nice. I haven't come up with a way to combine CT with it though; adam has tried some without success. 11:48 <@gmaxwell> (I mean to do so while staying in the realm of boring cryptography, ZC is strictly superior from a privacy perspective) 11:48 < nickler> gmaxwell: ah thanks a lot. Last remark for today: you seemed to be very ambitious to make your confidential tx writeup understandable for the layman. I personally drop out at (In1 + In2 + In3 + plaintext_input_amount*H...) - (Out1 + Out2 + Out3 + ... fees*H) == 0. 11:49 < nickler> Would have rather expected to find a xG somewhere and (In1 + In2 + In3 + plaintext_input_amount)*H 11:49 -!- davi [~davi@gnu/davi] has quit [Ping timeout: 265 seconds] 11:50 <@gmaxwell> nickler: ah. well the values themselves are In1 = blind G + value H hm. not sure how to make that clear, perhaps expand it out. 11:50 < nickler> ok that would make sense :D 11:50 < fluffypony> zooko: Table 1 is incorrect - Monero (and I think CryptoNote coins) mask the amount, unless you have a magic way of telling which outputs are change outputs 11:51 < zooko> fluffypony: Hm... :-/ 11:51 <@gmaxwell> fluffypony: I don't think that change uncertant really is enough to qualify there. 11:52 <@gmaxwell> (I'd missed that the table mentioned cryptonote) 11:52 < fluffypony> fair enough 11:52 < nickler> what's OWAS? 11:52 < kanzure> one-way aggregate signatures 11:52 < nickler> thx 11:52 <@gmaxwell> nickler: one way aggreatble signatures. Clever trick using aggregate signatures to get you something that works like a whole block level coinjoin which is non-interactive. 11:53 < kanzure> i was thinking of aggregate signatures for a multisig or coinjoin style payment channel approach, but didn't hash out the details yet 11:53 < kanzure> (where i could possibly use those funky history-free aggregate signatures to remove intermediate history) 11:53 < nickler> is there a bitcointalk thread about that? 11:54 <@gmaxwell> for a while, for the privacy feature for elements/alpha I'd wanted to do monero RS + OWAS, but then the prospect of reduced sized range proofs started looking pretty attractive instead. 11:54 <@gmaxwell> nickler: on OWAS? https://bitcointalk.org/index.php?topic=290971.0 11:55 < nickler> ah perfect 11:56 < kanzure> i think you could remove intermediate history if you could communicate with the original transaction signer to sign a different transaction instead 11:56 -!- cluckj [~cluckj@pool-108-16-231-242.phlapa.fios.verizon.net] has joined #bitcoin-wizards 11:56 <@gmaxwell> kanzure: well that sounds like the coinswap transform. 11:57 < kanzure> i want something like "bob sends 10,000 transactions to 10k hapless users, then each user sends 1k transactions to 1k other hapless users, and then bob's software rewrites his transactions so that the 1k transactions at the end are the only ones that get committed to the blockchain" 11:57 < kanzure> (or whatever the numbers work out to) 11:58 < nsh> loss of information is sufficient [just harder to guarantee]. equivocal histories requires more interaction 11:58 <@gmaxwell> coinswap works by applying a general transformation to an atomic cross chain swap. The general transformation makes any two party contract indistinguishable from a 2 of 2 multisig (assuming the players cooperate). 11:58 <@gmaxwell> (and where schnorr signatures are available, 2 of 2 easily looks just like 1 of 1) 11:59 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards 11:59 < nsh> 'The notion of compressing all the signatures in a block into a constant size output is very attractive, even if it retains a linear validation cost. The improvement of anonymity could be viewed as a side benefit.' # how is this done in the OWAS proposal? 11:59 < nsh> (the pdf link is 404) 12:00 < nsh> mirror: https://download.wpsoftware.net/bitcoin/wizardry/horasyuanmouton-owas.pdf 12:01 <@gmaxwell> nsh: the BLS signatures just have this property where you can aggregate them. 12:01 * nsh reads: http://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf 12:02 < nsh> (A Survey of Two Signature Aggregation Techniques, Boneh, et al.) 12:02 < nsh> oh, i see 12:02 <@gmaxwell> Boneh tells me there is a way to do an efficient batch verification but I didn't see how to make it work with the aggregation (haven't tried to hard). One of the bigger costs in that system (beyond needing the bilinear strong assumption) is that it needs two pairing operations per transaction to verify. If those could be batched out it would be nice. 12:02 * nsh nods 12:04 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Read error: No route to host] 12:04 -!- pavel_ [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-wizards 12:04 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards 12:05 < nsh> i guess it's not easily possible to use sequential aggregation (weaker / more accepted assumptions) and delegate the strict ordering to miners 12:06 < nsh> nope 12:07 < kanzure> not sure why 2-of-2 multisig is the goal there? 12:07 < kanzure> oh, you were just describing coinswap's mechanism 12:07 <@gmaxwell> kanzure: hides the contract. network never sees the script, which in an atomic swap breaks privacy. 12:09 * nsh wonders if it's believed that all GDH groups are bilinear maps 12:09 < nsh> or those are just the ones we've found 12:09 -!- www [~v3@p50897479.dip0.t-ipconnect.de] has joined #bitcoin-wizards 12:09 < fluffypony> http://www.vdiscover.org/OS-fuzzing.html 12:09 < fluffypony> .title 12:09 < yoleaux> Using Machine Learning to predict the outcome of a zzuf fuzzing campaign 12:11 -!- darwin_ [~darwin@88-103-255-166.jes.cz] has joined #bitcoin-wizards 12:12 < nsh> (no, 'Consequently, if a group G is a bilinear group then G is also a GDH group. (The converse is probably not true.)') 12:12 -!- pavel_ [~paveljani@79-98-72-216.sys-data.com] has quit [Quit: Leaving] 12:13 <@gmaxwell> nsh: yea, I expected that. since it's easy to see how you get the DDH test from bilinearity, but I could certatly imagine DDH being possible without bilinearity. 12:14 * nsh nods 12:14 -!- www [~v3@p50897479.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 12:14 -!- www1 [~v3@p50897479.dip0.t-ipconnect.de] has joined #bitcoin-wizards 12:16 -!- wallet42 [~wallet42@85.100.40.253] has quit [Quit: Leaving.] 12:17 < nsh> is it possible to find/contrive curves of arbitrary bilinear security parameter? or is there some tradeoff between the useful size of the subgroup and the difficulty of the transport 12:18 -!- wallet42 [~wallet42@85.100.40.253] has joined #bitcoin-wizards 12:18 * nsh curses pdfs with unreadable-in-linux fonts :/ 12:20 < nsh> also is the security parameter (alpha) equivalent to the embedding degree, or is that another thing? (latter is used here: http://theory.stanford.edu/~dfreeman/papers/ants-embedding.pdf ) 12:20 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Quit: Reconnecting] 12:20 -!- justanot1eruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards 12:20 <@gmaxwell> nsh: going a little deep into the blackbox for me; there are several different known famlies for getting pairing friendly groups. 12:20 * nsh nods 12:21 < nsh> oh, this says there is a construction for arbitrary degree, but it seems ~6-8 is commensurate with 2^160 bit ECC security 12:21 < nsh> so it may be academic 12:21 <@gmaxwell> nsh: for security you want the CDH to be hard on both sides, so if your smaller group is size x then you need some k such that x*k is as strong a size for integer discrete log as x is. 12:21 < nsh> right 12:22 <@gmaxwell> since e(G,P) = e(G,xG) = e(G,G)^x if you can solve the discrete log in the transfer.... 12:23 <@gmaxwell> (should have said and if you can...) 12:23 * nsh nods 12:24 <@gmaxwell> lots of handwave thoug that the special structure doesn't make things easier than expected. 12:24 -!- darwin_ [~darwin@88-103-255-166.jes.cz] has quit [] 12:24 -!- lnsybrd [~lnsybrd@fwsm-io-azp-dmz.phx1.ip.io.com] has quit [Quit: lnsybrd] 12:25 < nsh> right 12:25 < nsh> i am apprehensive when i see the phrase "infinite family of [such] curves" 12:25 < nsh> because that's a lot of potential pathology 12:29 < hulkhogan_> quick q, if, when sending messages to a mix, the mix encrypts and sends to either A)another mix or B)the final destination are there any vulnerabilities that are easy to spot in this config? 12:30 < hulkhogan_> need to note, if passing through to another mix, its not re-encrypted 12:30 < hulkhogan_> the encryption is to the final destination's public key 12:30 -!- zooko [~user@c-24-9-63-159.hsd1.co.comcast.net] has quit [Ping timeout: 264 seconds] 12:31 -!- www1 [~v3@p50897479.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds] 12:31 < hulkhogan_> verification happens at the final destination, and since messages are batched, ddos shouldn't be an issue 12:32 <@gmaxwell> hulkhogan_: hm? whats the 'mix encrypts' for? do you just mean transport level encryption? 12:33 <@gmaxwell> the normal constructions for mixnets are with nested messages where each inner layer is encrypted to the next hop. 12:33 <@gmaxwell> keep in mind that if the goal is to thwart traffic analysis (it is!) it may be important to make all messages constant size. 12:33 < hulkhogan_> yea i think so... in this case thats basically the use, and so the inner mixes dont receive any information about the transactions being passed through 12:33 < hulkhogan_> thats a good point... 12:34 < hulkhogan_> yeah, well the thinking is - expose a webservice to take in new transactions (Accessible via tor for privacy), those get handed to either another mix or the final node, we dont want to leak information if we are going over 1-hop, so we encrypt until the final dest 12:35 < hulkhogan_> you can think of it as three webservices, one to handle relay/broadcast, one that sits infront of the node for handling encryption/other necessary things, and perhaps a status webservice to get information on avaible mixes.. 12:37 < hulkhogan_> i havent thought it all the way through, there may not be a need to have additional mixes, for example 12:37 <@gmaxwell> it really should be tor reachable only, otherwise some idiots will reach it over the plain web (even if just accidentally) and then there will be big incentives to monitor the entry. :) 12:37 <@gmaxwell> well a single hop doesn't provide any privacy (beyond the use of tor to reach it) from the operator of it. 12:38 < hulkhogan_> well, what if you're at a coffeeshop and want to submit with privacy? i think ip masquing tricks (vpn, coffeeshop) allow for some level of privacy, we shouldn't throw away those users, is my pov here 12:38 -!- damethos [~damethos@unaffiliated/damethos] has joined #bitcoin-wizards 12:39 < hulkhogan_> ack, perhaps i need to do more reading.. 12:41 < nsh> .title https://www.youtube.com/watch?v=oEmcKBLu8pg 12:41 < yoleaux> On the Cryptographic Hardness of Finding a Nash Equilibrium - YouTube 12:43 <@gmaxwell> hulkhogan_: hm, tor should work from the coffeeshop. :) 12:43 < hulkhogan_> yea very true 12:44 < hulkhogan_> well it sounds like this should be set up as a hidden service, possibly 12:44 < nsh> (it's debatable whether anything should be set up as anything other than hidden service) 12:45 < hulkhogan_> well, originally i was thinking it was ok to expose a service/webpage accessible over tor, for IP masquing reasons 12:45 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards 12:45 < hulkhogan_> so visiting the site over tor would not allow the service to id you via IP 12:46 <@gmaxwell> yea, I wouldn't have done anything other than a hidden service, otherwise it's just too interesting to attack. Some idiot would start using it without tor and then getting traffic data from the site is suddenly very interesting. 12:46 < hulkhogan_> there are a lot of other ID leaks if you use a browser, so perhaps hidden service is best.. 12:46 * nsh nods 12:46 < nsh> "if your laptop can't find it, then neither can the market" 12:47 -!- davi [~davi@2001:4b98:dc0:51:216:3eff:feae:792] has joined #bitcoin-wizards 12:47 < nsh> (would be nice to have the converse of this unlearned from a few people) 12:47 -!- davi [~davi@2001:4b98:dc0:51:216:3eff:feae:792] has quit [Changing host] 12:47 -!- davi [~davi@gnu/davi] has joined #bitcoin-wizards 12:49 < hulkhogan_> heh, privacy is tough /goes to think more 12:50 < hulkhogan_> i think having a check on the user-agent to ensure you use tor-browser would be important 12:51 < hulkhogan_> so then you get the assurance of tor + tor-browser to eliminate fingerprinting 12:52 <@gmaxwell> using a plain socket and a uniform client is far far far less attack surface than even tor browser. 12:52 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 12:53 < hulkhogan_> although i dont know how to answer this, 'what makes this scheme better than starting tor and submitting transactions over socks to various block explorers that support pushing txs' 12:54 < kanzure> which ones support that 12:54 < kanzure> other than bci? 12:54 < hulkhogan_> a few, blockr?, coinbelly? 12:55 <@gmaxwell> hulkhogan_: because the server would protect the user from traffic analysis. 12:55 <@gmaxwell> by making private the amount of data sent and the timing. 12:55 <@gmaxwell> (perhaps go read up on what mixmaster does!) 12:55 < kanzure> .wik mixmaster 12:55 < yoleaux> kanzure: Sorry, that command (.wik) crashed. 12:55 < kanzure> gah 12:55 < nsh> (bah) 12:56 < nsh> .wik Mixmaster anonymous remailer 12:56 < yoleaux> nsh: Sorry, that command (.wik) crashed. 12:56 < kanzure> perhaps this is related to their https rollout 12:56 < nsh> "Mixmaster is a Type II anonymous remailer which sends messages in fixed-size packets and reorders them, preventing anyone watching the messages go in and out of remailers from tracing them." - https://en.wikipedia.org/wiki/Mixmaster_anonymous_remailer 12:57 < nsh> ( https://en.wikipedia.org/wiki/Mix_network#How_it_works ) 12:57 < hulkhogan_> yea i have one of the comparsion papers kanzure posted ready to be read... it was helping, i should finish that first probably 13:01 -!- zooko [~user@c-67-161-139-15.hsd1.co.comcast.net] has joined #bitcoin-wizards 13:04 -!- shen_noe [~shen_noe@172.56.17.45] has joined #bitcoin-wizards 13:06 -!- gill3s [~gill3s@pat35-3-82-245-143-153.fbx.proxad.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 13:10 -!- wallet42 [~wallet42@85.100.40.253] has quit [Quit: Leaving.] 13:11 -!- chmod755 [~chmod755@unaffiliated/chmod755] has joined #bitcoin-wizards 13:12 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards 13:15 -!- nessence [~alexl@166.170.23.115] has quit [Read error: Connection reset by peer] 13:15 -!- nessence_ [~alexl@166.170.23.115] has joined #bitcoin-wizards 13:21 -!- Crowley2k [~Crowley2k@93.113.62.93] has joined #bitcoin-wizards 13:23 -!- b_lumenkraft [~b_lumenkr@unaffiliated/b-lumenkraft/x-4457406] has quit [Quit: b_lumenkraft] 13:26 -!- darwin_ [~darwin@88-103-255-166.jes.cz] has joined #bitcoin-wizards 13:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 13:31 -!- nwilcox [~nwilcox@68.233.157.2] has quit [Ping timeout: 252 seconds] 13:33 -!- darwin_ [~darwin@88-103-255-166.jes.cz] has quit [] 13:33 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-pwfugkqztmbazalo] has quit [Read error: Connection reset by peer] 13:33 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 252 seconds] 13:34 -!- SDCDev [~quassel@unaffiliated/sdcdev] has quit [Ping timeout: 255 seconds] 13:34 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-meotyvwbbbbvgvtt] has joined #bitcoin-wizards 13:37 -!- melvster [~melvster@ip-86-49-18-198.net.upcbroadband.cz] has joined #bitcoin-wizards 13:38 -!- wallet42 [~wallet42@85.100.40.253] has joined #bitcoin-wizards 13:38 -!- nwilcox [~nwilcox@68.233.157.2] has joined #bitcoin-wizards 13:40 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 252 seconds] 13:40 -!- jmcn_ [~jamie@2.24.158.53] has joined #bitcoin-wizards 13:43 -!- jmcn [~jamie@2.24.158.81] has quit [Ping timeout: 276 seconds] 13:46 -!- SDCDev [~quassel@unaffiliated/sdcdev] has joined #bitcoin-wizards 13:52 < isis> a vpn will give you privacy, which isn't at all like anonymity. however, a vpn will also fail open, along with other various disaster modes within the design, making it an excellent footshotgun if you actually care about privacy or anonymity 13:55 < isis> gmaxwell is correct that a single hop of encryption for the tx isn't going to do anything w.r.t. privacy/anonymity. you actually do need a bare minimum of three, otherwise there are way too many attacks upon the mix network which become excessively easy… like path bias attacks with only two hops in between the client and the destination would be brutal. 13:58 < hulkhogan_> the designs changed a bit since then... using a hidden service protects against snooping the client/dest, the rest of the components would sit behind that in another network 13:58 -!- Quanttek [~quassel@ip1f10af17.dynamic.kabel-deutschland.de] has quit [Ping timeout: 264 seconds] 13:58 -!- _biO_ [~biO_@ip-37-24-195-112.hsi14.unitymediagroup.de] has quit [Read error: Connection reset by peer] 13:59 < hulkhogan_> i think originally i had pseudoanonymity as the goal, reading more, i have tweaked the model towards anonymity a bit more 13:59 -!- Tebbo` [~Jerry`@ip72-211-88-176.no.no.cox.net] has joined #bitcoin-wizards 13:59 <@gmaxwell> the whole thougth there was that tor gets you many advantages (including a bigger anonymity set) but not traffic analysis resistance, something riding inside tor can give traffic analysis resistance. 14:01 < hulkhogan_> i was just too concerned with accessibilty not considering the endgoal in mind 14:01 < isis> pseudonymity == anonymity, i.e. how can you have multiple (unlinked) identities without being able to have unlinked identities? 14:01 -!- nwilcox [~nwilcox@68.233.157.2] has quit [Ping timeout: 264 seconds] 14:02 < isis> they are not exactly the same, but for purposes of designing a mixnet, they do go hand in hand, since an attack on one is usually an attack on the other 14:02 < hulkhogan_> isis: can you cite a reference? i'd be interested to read more 14:03 -!- Tebbo [~Jerry`@ip72-211-88-176.no.no.cox.net] has quit [Ping timeout: 256 seconds] 14:03 < isis> oh god, if i have a paper for that, it's going to be so old… but i'll look 14:04 -!- mjerr [~mjerr@p578EB3B1.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 14:05 < hulkhogan_> np 14:05 < hulkhogan_> but i think keeping things off clearnet, only hosting over hidden services eliminate 90% of the concerns earlier 14:06 < hulkhogan_> other concerns like sybil/ddos mostly something the software needs to handle using pow or uptime schemes, not sure 14:11 -!- SDCDev [~quassel@unaffiliated/sdcdev] has quit [Ping timeout: 256 seconds] 14:13 -!- SDCDev [~quassel@unaffiliated/sdcdev] has joined #bitcoin-wizards 14:13 < isis> http://freehaven.net/anonbib/cache/terminology.pdf http://freehaven.net/anonbib/bibtex.html#terminology 14:15 < nsh> 23hr ago -- https://www.youtube.com/watch?v=HZlIRr6Xwe8 14:15 < nsh> .title 14:15 < yoleaux> How to use Bitcoin to Enhance Secure Computation - YouTube 14:16 < nsh> How to Use Bitcoin to Incentivize Correct Computations -- http://people.csail.mit.edu/ranjit/papers/incentives.pdf 14:16 < nsh> How to Use Bitcoin to Design Fair Protocols -- https://eprint.iacr.org/2014/129.pdf 14:18 < isis> the lagginess of hidden services might be viewed in a more glass-half-full manner as providing builtin (D)DoS resistance :) 14:19 < isis> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt describes the upcoming changes to hidden services, for those interested in building future systems on top of them 14:20 <@gmaxwell> isis: did it ever gain some hashcash like DOS mitigation (not sure if you're aware but there is a proposal for TLS to support doing that) 14:22 -!- jtimon [~quassel@137.30.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards 14:24 < isis> we haven't added overt DOS mitigation yet… there have been a few rather fragile bugs which are fixed in the new design which should provide what you could call increased DOS mitigation/rate limiting, but other than that, no. 14:24 -!- shen_noe [~shen_noe@172.56.17.45] has quit [Quit: quitquitquit] 14:25 -!- davi [~davi@gnu/davi] has quit [Ping timeout: 265 seconds] 14:26 < isis> gmaxwell: the hashcash DOS mitigation, that means just the actual proof-of-work system, correct? or did hashcash have an additional mechanism? 14:26 -!- go1111111 [~go1111111@162.244.138.37] has quit [Ping timeout: 252 seconds] 14:28 -!- rht__ [uid86914@gateway/web/irccloud.com/x-kjxbmfruknooelnd] has quit [Quit: Connection closed for inactivity] 14:34 -!- nwilcox [~nwilcox@68.233.157.2] has joined #bitcoin-wizards 14:34 -!- Crowley2k [~Crowley2k@93.113.62.93] has quit [Ping timeout: 252 seconds] 14:36 -!- damethos [~damethos@unaffiliated/damethos] has quit [Ping timeout: 276 seconds] 14:38 -!- go1111111 [~go1111111@gateway/vpn/privateinternetaccess/go1111111] has joined #bitcoin-wizards 14:38 <@gmaxwell> thats all 14:40 -!- jtimon [~quassel@137.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 272 seconds] 14:40 < hulkhogan_> isis: thanks for sharing that terminology piece, its very helpful in decoding some of the stuff i was reading earlier 14:41 <@Luke-Jr> gavinandresen: BIP16 vs 17 was a different situation IMO: both proposals were reasonable, and everyone agreed we needed one of them 14:42 -!- darwin_ [~darwin@88-103-255-166.jes.cz] has joined #bitcoin-wizards 14:43 -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards 14:45 -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards 14:50 < Giszmo> sudo npm install -g cordova 14:51 < Giszmo> (oops. wrong chat :/ ) 14:52 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards 14:54 -!- prodatalab_ [~prodatala@78.sub-70-209-52.myvzw.com] has quit [Ping timeout: 256 seconds] 14:54 -!- nwilcox [~nwilcox@68.233.157.2] has quit [Ping timeout: 264 seconds] 14:59 -!- StephenM347 [~stephenm3@static-64-223-246-218.port.east.myfairpoint.net] has quit [] 15:01 -!- nwilcox [~nwilcox@68.233.157.2] has joined #bitcoin-wizards 15:05 -!- JackH [~Jack@host-80-43-142-154.as13285.net] has quit [Ping timeout: 256 seconds] 15:14 -!- zooko [~user@c-67-161-139-15.hsd1.co.comcast.net] has quit [Ping timeout: 265 seconds] 15:14 -!- darwin_ [~darwin@88-103-255-166.jes.cz] has quit [Remote host closed the connection] 15:15 -!- darwin_ [~darwin@88-103-255-166.jes.cz] has joined #bitcoin-wizards 15:21 < waxwing> andytoshi: i got my py script to verify a sig out of the tests.c :) 15:22 < nsh> \o/ 15:29 -!- temujin [2679a51e@gateway/web/freenode/ip.38.121.165.30] has quit [Ping timeout: 246 seconds] 15:34 -!- nwilcox [~nwilcox@68.233.157.2] has quit [Ping timeout: 246 seconds] 15:35 -!- rustyn [~rustyn@unaffiliated/rustyn] has quit [] 15:40 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds] 15:41 -!- nwilcox [~nwilcox@68.233.157.2] has joined #bitcoin-wizards 15:41 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has quit [Ping timeout: 265 seconds] 15:42 -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving] 15:43 -!- robogoat [~robogoat@c-24-126-240-124.hsd1.ga.comcast.net] has quit [Ping timeout: 264 seconds] 15:45 -!- belcher [~belcher-s@5ec33c53.skybroadband.com] has joined #bitcoin-wizards 15:45 -!- belcher [~belcher-s@5ec33c53.skybroadband.com] has quit [Changing host] 15:45 -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards 15:48 -!- Mably [~Mably@unaffiliated/mably] has quit [Ping timeout: 245 seconds] 15:48 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards 15:50 -!- justanot1eruser [~Justan@unaffiliated/justanotheruser] has quit [Quit: Reconnecting] 15:55 -!- adam3us [~Adium@c3-219.i07-1.onvol.net] has quit [Quit: Leaving.] 15:56 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Remote host closed the connection] 15:56 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards 15:58 -!- nessence_ [~alexl@166.170.23.115] has quit [Read error: Connection reset by peer] 15:59 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] 16:01 -!- nessence [~alexl@166.170.23.115] has joined #bitcoin-wizards 16:02 -!- adam3us [~Adium@195.138.228.17] has joined #bitcoin-wizards 16:03 -!- blahblah [88988e22@gateway/web/cgi-irc/kiwiirc.com/ip.136.152.142.34] has joined #bitcoin-wizards 16:08 -!- nubbins` [~leel@unaffiliated/nubbins] has joined #bitcoin-wizards 16:09 -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving] 16:10 -!- blahblah [88988e22@gateway/web/cgi-irc/kiwiirc.com/ip.136.152.142.34] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 16:12 -!- eennaam [~eennaam@unaffiliated/eennaam] has left #bitcoin-wizards [] 16:17 -!- someguy [88988e22@gateway/web/cgi-irc/kiwiirc.com/ip.136.152.142.34] has joined #bitcoin-wizards 16:21 -!- alephbet [88988e22@gateway/web/cgi-irc/kiwiirc.com/ip.136.152.142.34] has joined #bitcoin-wizards 16:25 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined #bitcoin-wizards 16:29 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 16:34 < nsh> .t https://www.youtube.com/watch?v=2L25KE61a4w 16:34 < yoleaux> nsh: Sorry, I don't know a timezone by that name. 16:34 < nsh> .title 16:34 < yoleaux> Provably Secure Blockchain Protocols and Applications to Secure Computation - YouTube 16:37 -!- dEBRUYNE [~dEBRUYNE@239-196-ftth.onsbrabantnet.nl] has quit [Read error: Connection reset by peer] 16:38 -!- nubbins` [~leel@unaffiliated/nubbins] has quit [Quit: Quit] 16:40 < nsh> -- 16:40 < nsh> We overview recent and ongoing work investigating blockchain protocols from a provable security perspective. We discuss properties such as common prefix and chain quality and introduce proof techniques for establishing such properties in a synchronous anonymous communication model assuming bounded access to a random oracle. We discuss the consensus problem in this setting and its relation to robust transaction ledgers. We also introduce a new model and 16:40 < nsh> a construction for secure computation with fairness and output delivery guarantees that are conditional on a global transaction ledger. 16:40 < nsh> -- 16:46 -!- nessence [~alexl@166.170.23.115] has quit [Remote host closed the connection] 16:47 < kanzure> was this the yahoo group 16:48 -!- adam3us1 [~Adium@c3-219.i07-1.onvol.net] has joined #bitcoin-wizards 16:48 -!- adam3us [~Adium@195.138.228.17] has quit [Ping timeout: 264 seconds] 16:50 -!- nwilcox [~nwilcox@68.233.157.2] has quit [Ping timeout: 264 seconds] 16:57 -!- nwilcox [~nwilcox@68.233.157.2] has joined #bitcoin-wizards 16:58 < nsh> (Aggelos Kiayias, University of Athens) 17:02 -!- d1ggy_ [~d1ggy@dslc-082-082-192-234.pools.arcor-ip.net] has joined #bitcoin-wizards 17:04 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 17:05 -!- d1ggy [~d1ggy@dslb-088-070-190-085.088.070.pools.vodafone-ip.de] has quit [Ping timeout: 244 seconds] 17:06 -!- PRab [~chatzilla@2601:40a:8000:8f9b:ed5a:7b56:d036:5b1b] has quit [Quit: ChatZilla 0.9.91.1 [Firefox 38.0.5/20150525141253]] 17:06 -!- PRab [~chatzilla@2601:40a:8000:8f9b:ed5a:7b56:d036:5b1b] has joined #bitcoin-wizards 17:06 -!- someguy [88988e22@gateway/web/cgi-irc/kiwiirc.com/ip.136.152.142.34] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 17:07 -!- alephbet [88988e22@gateway/web/cgi-irc/kiwiirc.com/ip.136.152.142.34] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 17:15 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-oiylulkoqynrofdo] has quit [Quit: Connection closed for inactivity] 17:15 -!- prodatalab_ [~prodatala@2602:306:ceef:a750:81f7:5c72:6494:e780] has joined #bitcoin-wizards 17:24 -!- prodatalab_ [~prodatala@2602:306:ceef:a750:81f7:5c72:6494:e780] has quit [Quit: Konversation terminated!] 17:25 -!- prodatalab__ [~prodatala@2602:306:ceef:a750:81f7:5c72:6494:e780] has joined #bitcoin-wizards 17:33 -!- jouke [~jouke@unaffiliated/komkommer] has quit [Ping timeout: 245 seconds] 17:34 -!- nemild [~nemild@104.207.195.34] has joined #bitcoin-wizards 17:34 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 246 seconds] 17:35 -!- chmod755 [~chmod755@unaffiliated/chmod755] has quit [Quit: Leaving] 17:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 17:37 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Remote host closed the connection] 17:38 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has joined #bitcoin-wizards 17:38 -!- darwin_ [~darwin@88-103-255-166.jes.cz] has quit [Read error: No route to host] 17:40 -!- jouke [~jouke@a83-163-42-163.adsl.xs4all.nl] has joined #bitcoin-wizards 17:41 -!- darwin_ [~darwin@88-103-255-166.jes.cz] has joined #bitcoin-wizards 17:42 -!- nessence_ [~alexl@c-68-51-194-2.hsd1.mi.comcast.net] has quit [Ping timeout: 265 seconds] 17:43 -!- prodatalab [~prodatala@2600:1006:b164:8d88:81f7:5c72:6494:e780] has joined #bitcoin-wizards 17:45 -!- prodatalab__ [~prodatala@2602:306:ceef:a750:81f7:5c72:6494:e780] has quit [Ping timeout: 256 seconds] 17:50 -!- ThinThread [~far@onegrandcircle.com] has joined #bitcoin-wizards 17:52 < ThinThread> can i make a relay program that listens to public channel like twitter hashtag for covert control messages that adversary who siezes machine relay program running cannot determine controller? 17:54 < ThinThread> i was thinking i could multiply each tweet by cipher text with homomorphic encryption 17:54 < ThinThread> dont really see how to impelement the desired functionality as matrix multiplies but maybe is possible 17:57 -!- someguy [a9e578bd@gateway/web/cgi-irc/kiwiirc.com/ip.169.229.120.189] has joined #bitcoin-wizards 17:57 -!- alephbet [a9e578bd@gateway/web/cgi-irc/kiwiirc.com/ip.169.229.120.189] has joined #bitcoin-wizards 17:59 -!- llllllllll [~lllllllll@6d482698.ftth.concepts.nl] has quit [Ping timeout: 244 seconds] 18:01 -!- shen_noe [~shen_noe@172.56.17.45] has joined #bitcoin-wizards 18:06 -!- nwilcox [~nwilcox@68.233.157.2] has quit [Ping timeout: 240 seconds] 18:06 -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 265 seconds] 18:19 -!- snakesandbarrels [~snizysnaz@97.95.172.50] has joined #bitcoin-wizards 18:22 -!- metamarc [~snizysnaz@unaffiliated/agorist000] has quit [Ping timeout: 265 seconds] 18:30 -!- n0n0_ [~n0n0___@x5f7696dc.dyn.telefonica.de] has quit [Ping timeout: 264 seconds] 18:30 -!- prodatalab [~prodatala@2600:1006:b164:8d88:81f7:5c72:6494:e780] has quit [Read error: No route to host] 18:35 -!- prodatalab [~prodatala@2600:1006:b164:8d88:81f7:5c72:6494:e780] has joined #bitcoin-wizards 18:36 -!- cypher__ [~snizysnaz@97.95.172.50] has joined #bitcoin-wizards 18:37 -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving] 18:40 -!- snakesandbarrels [~snizysnaz@97.95.172.50] has quit [Ping timeout: 272 seconds] 18:42 -!- c0rw1n is now known as c0rw|zZz 18:45 -!- snakesandbarrels [~snizysnaz@97.95.172.50] has joined #bitcoin-wizards 18:47 -!- metamarc [~snizysnaz@unaffiliated/agorist000] has joined #bitcoin-wizards 18:48 -!- cypher__ [~snizysnaz@97.95.172.50] has quit [Ping timeout: 240 seconds] 18:49 -!- alephbet [a9e578bd@gateway/web/cgi-irc/kiwiirc.com/ip.169.229.120.189] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 18:49 -!- someguy [a9e578bd@gateway/web/cgi-irc/kiwiirc.com/ip.169.229.120.189] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 18:49 -!- alephbet [a9e578bd@gateway/web/cgi-irc/kiwiirc.com/ip.169.229.120.189] has joined #bitcoin-wizards 18:49 -!- someguy [a9e578bd@gateway/web/cgi-irc/kiwiirc.com/ip.169.229.120.189] has joined #bitcoin-wizards 18:50 -!- cypher__ [~snizysnaz@97.95.172.50] has joined #bitcoin-wizards 18:50 -!- snakesandbarrels [~snizysnaz@97.95.172.50] has quit [Ping timeout: 240 seconds] 18:53 -!- metamarc [~snizysnaz@unaffiliated/agorist000] has quit [Ping timeout: 245 seconds] 18:54 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards 18:58 -!- Dr-G2 [~Dr-G@xd9bf7197.dyn.telefonica.de] has quit [Ping timeout: 276 seconds] 18:58 -!- p15 [~p15@61.149.242.188] has joined #bitcoin-wizards 19:00 -!- cypher__ [~snizysnaz@97.95.172.50] has quit [Ping timeout: 245 seconds] 19:12 <@gmaxwell> ThinThread: you want a wet paper code. 19:12 <@gmaxwell> though temporal sequencing, if visible to the attacker can break the privacy. 19:13 <@gmaxwell> but if you assume that the attacker can't tell what order messages were authored in, then you can make it so that it's undecidable which message conveyed the secret message, even if there is only a small amount of malleability. 19:15 -!- goregrind [~goregrind@unaffiliated/goregrind] has quit [Read error: Connection reset by peer] 19:16 -!- zooko [~user@c-73-181-114-84.hsd1.co.comcast.net] has joined #bitcoin-wizards 19:23 -!- zooko [~user@c-73-181-114-84.hsd1.co.comcast.net] has quit [Remote host closed the connection] 19:24 -!- AlexStraunoff [~stqism@freebsd/user/stqism] has quit [Ping timeout: 252 seconds] 19:25 -!- zooko [~user@c-73-181-114-84.hsd1.co.comcast.net] has joined #bitcoin-wizards 19:30 -!- AlexStraunoff [~stqism@freebsd/user/stqism] has joined #bitcoin-wizards 19:36 -!- shen_noe [~shen_noe@172.56.17.45] has quit [Quit: Leaving] 19:36 -!- goregrind [~goregrind@unaffiliated/goregrind] has joined #bitcoin-wizards 19:38 -!- zooko [~user@c-73-181-114-84.hsd1.co.comcast.net] has quit [Ping timeout: 250 seconds] 19:46 -!- RoboTeddy [~roboteddy@2601:645:8200:137d:44f0:19b1:3d4d:c2] has joined #bitcoin-wizards 19:56 -!- rht__ [uid86914@gateway/web/irccloud.com/x-odqjgyfgkmnfiscu] has joined #bitcoin-wizards 20:02 -!- kgk [~kgk@ip-64-134-226-8.public.wayport.net] has joined #bitcoin-wizards 20:03 -!- go1111111 [~go1111111@gateway/vpn/privateinternetaccess/go1111111] has quit [Ping timeout: 255 seconds] 20:18 -!- go1111111 [~go1111111@162.244.138.37] has joined #bitcoin-wizards 20:20 < amiller> here's my advisor elaine giving a talk at the same thing, on work i helped a lot with https://www.youtube.com/watch?v=FQ6Hii69b5U 20:20 < amiller> Cryptocurrencies and Smart Contracts 20:21 < amiller> nsh, ^ 20:22 -!- prodatalab [~prodatala@2600:1006:b164:8d88:81f7:5c72:6494:e780] has quit [Read error: No route to host] 20:22 -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards 20:23 < kanzure> .title 20:23 < yoleaux> Cryptocurrencies and Smart Contracts - YouTube 20:23 < kanzure> oh. 20:38 -!- kgk [~kgk@ip-64-134-226-8.public.wayport.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 20:41 -!- kgk [~kgk@ip-64-134-226-8.public.wayport.net] has joined #bitcoin-wizards 20:42 -!- zooko [~user@87.sub-70-196-200.myvzw.com] has joined #bitcoin-wizards 20:47 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Disconnected by services] 20:47 -!- [7] [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards 20:54 -!- p15 [~p15@61.149.242.188] has quit [Max SendQ exceeded] 20:56 -!- p15 [~p15@182.50.108.23] has joined #bitcoin-wizards 21:14 -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] 21:20 -!- RoboTeddy [~roboteddy@2601:645:8200:137d:44f0:19b1:3d4d:c2] has quit [Remote host closed the connection] 21:21 -!- RoboTeddy [~roboteddy@2601:645:8200:137d:44f0:19b1:3d4d:c2] has joined #bitcoin-wizards 21:32 -!- alephbet [a9e578bd@gateway/web/cgi-irc/kiwiirc.com/ip.169.229.120.189] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 21:32 -!- someguy [a9e578bd@gateway/web/cgi-irc/kiwiirc.com/ip.169.229.120.189] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 21:32 -!- alephbet [a9e578bd@gateway/web/cgi-irc/kiwiirc.com/ip.169.229.120.189] has joined #bitcoin-wizards 21:32 -!- zooko [~user@87.sub-70-196-200.myvzw.com] has quit [Ping timeout: 246 seconds] 21:32 -!- someguy [a9e578bd@gateway/web/cgi-irc/kiwiirc.com/ip.169.229.120.189] has joined #bitcoin-wizards 21:34 -!- nemild [~nemild@104.207.195.34] has quit [Quit: nemild] 21:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds] 21:36 -!- mjerr [~mjerr@p578EB3B1.dip0.t-ipconnect.de] has joined #bitcoin-wizards 21:42 -!- wallet42 [~wallet42@85.100.40.253] has quit [Quit: Leaving.] 21:43 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 244 seconds] 21:45 -!- Musdom_ [71d202b4@gateway/web/freenode/ip.113.210.2.180] has joined #bitcoin-wizards 21:49 -!- p15 [~p15@182.50.108.23] has quit [Max SendQ exceeded] 21:49 -!- p15 [~p15@182.50.108.23] has joined #bitcoin-wizards 21:52 -!- gill3s [~gill3s@pat35-3-82-245-143-153.fbx.proxad.net] has joined #bitcoin-wizards 21:53 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards 22:12 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 22:23 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 22:25 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards 22:26 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 276 seconds] 22:26 -!- kgk [~kgk@ip-64-134-226-8.public.wayport.net] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] 22:28 -!- mjerr [~mjerr@p578EB3B1.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds] 22:35 -!- _biO_ [~biO_@ip-37-24-195-112.hsi14.unitymediagroup.de] has joined #bitcoin-wizards 22:39 -!- Mably [~Mably@unaffiliated/mably] has joined #bitcoin-wizards 22:44 -!- cosmo [~james@unaffiliated/cosmo] has quit [Quit: Leaving] 22:44 -!- gill3s [~gill3s@pat35-3-82-245-143-153.fbx.proxad.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 22:46 -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Quit: Leaving] 22:48 -!- www [~v3@f052000057.adsl.alicedsl.de] has joined #bitcoin-wizards 22:55 -!- gill3s [~gill3s@pat35-3-82-245-143-153.fbx.proxad.net] has joined #bitcoin-wizards 23:04 -!- luny [~luny@unaffiliated/luny] has quit [Ping timeout: 276 seconds] 23:09 -!- BitName [~user@71-90-215-93.dhcp.spbg.sc.charter.com] has quit [Ping timeout: 252 seconds] 23:11 -!- Xh1pher [~Xh1pher@pD9E38632.dip0.t-ipconnect.de] has joined #bitcoin-wizards 23:16 -!- gill3s [~gill3s@pat35-3-82-245-143-153.fbx.proxad.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 23:19 -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 246 seconds] 23:22 -!- kgk [~kgk@76.14.85.43] has joined #bitcoin-wizards 23:24 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 245 seconds] 23:27 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] 23:28 -!- rht__ [uid86914@gateway/web/irccloud.com/x-odqjgyfgkmnfiscu] has quit [Quit: Connection closed for inactivity] 23:29 -!- GAit [~lnahum@2-230-161-158.ip202.fastwebnet.it] has quit [Remote host closed the connection] 23:32 -!- ebfull [~ebfull@c-76-120-40-34.hsd1.co.comcast.net] has quit [Quit: cya] 23:32 < andytoshi> waxwing: baller! :) 23:41 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 23:51 -!- Mably [~Mably@unaffiliated/mably] has quit [Ping timeout: 250 seconds] 23:53 -!- _biO_ [~biO_@ip-37-24-195-112.hsi14.unitymediagroup.de] has quit [Remote host closed the connection] 23:55 -!- Musdom_ [71d202b4@gateway/web/freenode/ip.113.210.2.180] has quit [Quit: Page closed] 23:59 -!- pollux-bts [uid52270@gateway/web/irccloud.com/x-jsqedoiycyxelsow] has quit [Quit: Connection closed for inactivity] --- Log closed Wed Jun 17 00:00:44 2015