--- Log opened Thu Sep 08 00:00:48 2016
00:04 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-wizards
00:06 -!- PeterR [cf5125a7@gateway/web/freenode/ip.207.81.37.167] has quit [Ping timeout: 264 seconds]
00:09 -!- danrobinson [~danrobins@cpe-68-175-4-89.nyc.res.rr.com] has quit [Quit: Textual IRC Client: www.textualapp.com]
00:09 -!- r0ach [~r0ach@107-217-214-192.lightspeed.jcvlfl.sbcglobal.net] has quit []
00:11 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards
00:12 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 244 seconds]
00:28 -!- sipi [~sipi@165.64.broadband12.iol.cz] has joined #bitcoin-wizards
00:32 -!- oleganza [~oleganza@c-73-170-224-149.hsd1.ca.comcast.net] has quit [Quit: oleganza]
00:34 -!- daddinuz [~daddinuz@212.91.77.78] has joined #bitcoin-wizards
00:46 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 276 seconds]
00:47 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has left #bitcoin-wizards []
00:51 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 250 seconds]
01:08 -!- daddinuz [~daddinuz@212.91.77.78] has quit [Quit: Leaving]
01:12 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-wizards
01:14 < amiller> Taek, pipelining wouldn't increase the throughput, at least the assumption there at least is that the slowest node on a path is the one that constrains the throughput
01:14 < Taek> so, my guesstimate of the network propagation that was happening there is that a node would get a block in full, validate it, then propagate it
01:15 < Taek> which means that if a block was large, it'd download the *whole* block before doing any validation or uploading, and that would cause a severe bottleneck
01:15 < Taek> elsewhere in the paper it was stated that the bandwidth for the 90 percentile nodes was 3mbps
01:16 < Taek> but I could see where a single node bottleneck could cause issues
01:16 < Taek> I still imagine that pipelining would get you large gains
01:17 < Taek> also, would it be safe to assume in a continuous bandwidth scenario that the slowest node could be routed around via other peers?
01:17 < Taek> perhaps that's too optimistic
01:17 < midnightmagic> Oh, what a surprise. Ban-evading again.
01:33 -!- alan_ [~alan@flyingarm.bar] has joined #bitcoin-wizards
01:34 -!- alan_ is now known as Alanius
01:36 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
01:36 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer]
01:37 -!- sipi [~sipi@165.64.broadband12.iol.cz] has quit [Quit: Leaving]
01:43 < sipa> Taek: fibre relays before receiving the full block
01:43 < sipa> and it seems to help a lot
01:44 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
01:59 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards
01:59 -!- cdecker [~cdecker@2a02:aa16:1105:4a80:8c99:8bd4:ce43:c5e7] has quit [Ping timeout: 264 seconds]
01:59 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 265 seconds]
02:03 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-wizards
02:05 -!- cdecker [~cdecker@2a02:aa16:1105:4a80:8c99:8bd4:ce43:c5e7] has joined #bitcoin-wizards
02:12 -!- Hunger- [~hunger@prodevops.net] has quit [Ping timeout: 260 seconds]
02:22 -!- Hunger- [~hunger@prodevops.net] has joined #bitcoin-wizards
02:25 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Read error: Connection reset by peer]
02:26 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards
02:26 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-wizards
02:40 < vega4> Taek: thank you for posting the paper, I haven't seen it before
02:41 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
02:41 -!- pro [~pro@unaffiliated/pro] has joined #bitcoin-wizards
02:43 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards
02:54 -!- Emcy_ [~MC@unaffiliated/mc1984] has quit [Quit: Leaving]
02:54 -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards
03:04 -!- lmatteis_ is now known as lmatteis
03:06 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-wizards
03:11 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
03:20 -!- JackH [~Jack@79-73-191-94.dynamic.dsl.as9105.com] has quit [Ping timeout: 240 seconds]
03:21 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards
03:30 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
03:39 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
03:45 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards
03:53 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-wizards
04:08 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 265 seconds]
04:12 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards
04:15 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 244 seconds]
04:20 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
04:25 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards
04:38 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
04:44 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards
05:01 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
05:01 -!- laurentmt [~Thunderbi@80.215.210.95] has joined #bitcoin-wizards
05:04 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-wizards
05:08 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 264 seconds]
05:09 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.]
05:11 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards
05:12 -!- laurentmt [~Thunderbi@80.215.210.95] has quit [Quit: laurentmt]
05:16 -!- xeon-enouf [~xeon-enou@unaffiliated/xeon-enouf] has joined #bitcoin-wizards
05:17 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
05:17 -!- jtimon [~quassel@38.110.132.37.dynamic.jazztel.es] has joined #bitcoin-wizards
05:21 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards
05:41 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
05:47 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards
05:50 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards
05:59 -!- vega4 [~pc_rafals@user-31-175-254-216.play-internet.pl] has quit [Ping timeout: 250 seconds]
06:12 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam]
06:19 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has joined #bitcoin-wizards
06:19 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
06:19 -!- vega4 [~pc_rafals@c0-100.icpnet.pl] has joined #bitcoin-wizards
06:20 -!- cdecker [~cdecker@2a02:aa16:1105:4a80:8c99:8bd4:ce43:c5e7] has quit [Ping timeout: 260 seconds]
06:22 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 252 seconds]
06:22 -!- Guyver2_ is now known as Guyver2
06:23 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
06:24 -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Ping timeout: 250 seconds]
06:34 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
06:50 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-wizards
06:55 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
07:05 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
07:07 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer]
07:08 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 252 seconds]
07:08 -!- Guyver2_ is now known as Guyver2
07:08 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards
07:10 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam]
07:17 -!- assder [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-wizards
07:23 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards
07:28 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
07:30 -!- contrapumpkin is now known as copumpkin
07:35 -!- face_ [~face@mail.hmel.org] has joined #bitcoin-wizards
07:37 < bsm1175321> Just caught up on that conversation... Taek keep in mind that the "fastest block time" as defined by creating a total-ordering on the braid (finding cohorts) is around 10 seconds.  Pushing the block time down below that results in exponentially-increased time between total-ordering (cohort) events, because you're waiting for the network to be accidentally quiescent for a time proportional to the network size.
07:38 < bsm1175321> That result can be found at the bottom of: https://rawgit.com/mcelrath/braidcoin/master/Braid%2BExamples.html
07:39 -!- face_ is now known as face
07:40 < bsm1175321> (so confirmation time goes up exponentially fast at that point...maybe that was your point?)
07:47 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:b8e2:1c9c:fe32:8ba2] has quit [Ping timeout: 250 seconds]
07:51 -!- edvorg [~edvorg@14.169.88.102] has joined #bitcoin-wizards
07:55 -!- MoALTz [~no@78-11-247-26.static.ip.netia.com.pl] has joined #bitcoin-wizards
07:59 -!- edvorg [~edvorg@14.169.88.102] has quit [Remote host closed the connection]
08:08 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:6030:44b1:fd43:a0c4] has joined #bitcoin-wizards
08:09 -!- edvorg [~edvorg@14.169.88.102] has joined #bitcoin-wizards
08:11 -!- vega4 [~pc_rafals@c0-100.icpnet.pl] has quit [Ping timeout: 265 seconds]
08:11 -!- rubensayshi [~ruben@82.201.93.169] has quit [Remote host closed the connection]
08:12 -!- vega4 [~pc_rafals@c0-100.icpnet.pl] has joined #bitcoin-wizards
08:12 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-wizards
08:14 < tromp> make
08:16 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
08:18 < vega4> have you got any papers at hand related to the subject of incentives which would enchance exchange of transactions among full nodes?
08:22 < assder> What are the components of MimbleWimble I should read up on to understand it properly?
08:22 < andytoshi> assder: there's not much out there yet aside from the original 'paper'
08:23 < sipa> the only building block that matters is CT, i think
08:23 < assder> Didn't it utilize "cut-through" something?
08:23 < kanzure> there are OWAS and signature aggregation things that you could look at
08:24 < kanzure> like http://diyhpl.us/~bryan/papers2/bitcoin/Increasing%20anonymity%20in%20bitcoin%20using%20one-way%20aggregatable%20signatures.pdf
08:24 < andytoshi> assder: https://download.wpsoftware.net/bitcoin/wizardry/mimblewimble.txt is the MW paper
08:24 < sipa> but OWAS is not a building block for MW
08:24 < sipa> though it may help understand things, as it works similarly
08:25 < assder> Ok, thanks for the links! I'll buckle down and study.
08:25 < kanzure> also there are some other explanations available here:
08:25 < kanzure> https://www.reddit.com/r/Bitcoin/comments/4vub3y/mimblewimble_noninteractive_coinjoin_and_better/
08:25 < kanzure> https://www.reddit.com/r/Bitcoin/comments/4woyc0/mimblewimble_interview_with_andrew_poelstra_and/
08:25 < kanzure> https://www.reddit.com/r/Bitcoin/comments/4xge51/mimblewimble_how_a_strippeddown_version_of/
08:25 < kanzure> https://www.reddit.com/r/Bitcoin/comments/4y4ezm/mimblewimble_how_a_strippeddown_version_of/
08:25 < kanzure> http://diyhpl.us/wiki/transcripts/mimblewimble-podcast/
08:26 < assder> kanzure: Wow, thank you
08:26 < kanzure> also there was a big section on signature aggregation here https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html
08:26 < kanzure> and here http://diyhpl.us/wiki/transcripts/simons-institute/pairing-cryptography/
08:27 < kanzure> and a little bit here http://diyhpl.us/wiki/transcripts/2016-july-bitcoin-developers-miners-meeting/dan-boneh/ although i think the previous one is more canonical
08:32 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Remote host closed the connection]
08:32 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-wizards
08:37 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]
08:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
08:55 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
08:55 -!- Mazz_ [~mazznilla@unaffiliated/mazznilla] has quit [Ping timeout: 244 seconds]
08:58 -!- AaronvanW [~ewout@77pc231.sshunet.nl] has joined #bitcoin-wizards
08:58 -!- AaronvanW [~ewout@77pc231.sshunet.nl] has quit [Changing host]
08:58 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards
08:58 -!- Mazz_ [~mazznilla@unaffiliated/mazznilla] has joined #bitcoin-wizards
09:02 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
09:03 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Ping timeout: 276 seconds]
09:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
09:25 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has joined #bitcoin-wizards
09:34 < Taek> <bsm1175321> Taek keep in mind that the "fastest block time" as defined by creating a total-ordering on the braid (finding cohorts) is around 10 seconds
09:34 < Taek> our ordering algorithms are different
09:35 < bsm117532> Well the fundamental time scale of consensus is the size of the network, and is ~few seconds, you can't get faster than that and maintain consensus.
09:35 < Taek> mine can :)
09:35 < Taek> total ordering is based on the highest block that you know about
09:35 < bsm117532> Uh...no, if I'm on the other side of the Earth, I can't possibly know...
09:36 < bsm117532> Consensus is defined globally.
09:36 < Taek> right, so instead of getting consensus on the immediate block, you get consensus on a block with X confirmations
09:36 < Taek> beyond X confirmations, I can prove that causing a reorg would require Y much work, and I can show that, assuming no 51% attackers, Y much work is practically impossible to achieve
09:37 < Taek> all that without requiring that we aren't actually seeing the same list of confirmations
09:37 < Taek> as long as we each have X confirmations, the merging takes care of the rest
09:37 < bsm117532> Can you define "confirmation" for you in the context of a DAG?
09:37 < Taek> Where X confirmations needs to be sufficiently large, on the order of 5-30 minutes
09:38 < Taek> the number of confirmations on a block is all known descendents of that block
09:38 < bsm117532> I'm using "cohort" = total order as the definition of "confirmation" -- you mean something different.
09:38 < Taek> yes
09:38 < Taek> that is perhaps what is causing the confusion then
09:38 < Taek> my merging algorithm doesn't have any cohorts
09:39 < Taek> actually, I've completed the full description of my merging algorithm. I'll post it to pastebin
09:39 < Taek> the security proofs and txn fee handling isn't finished yet
09:39 < Taek> hopefully today though
09:39 < bsm117532> But consider a DAG where one node branches to two, and then merges (a diamond).  Now take one side of that diamond and insert several nodes.
09:39 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Read error: Connection reset by peer]
09:39 < bsm117532> Yeah I've been ignoring txn fees too :-/
09:40 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-wizards
09:40 < Taek> This week I came up with a pretty great solution to ensure miner fairness when including txn fees
09:40 < bsm117532> The diagram I describe has two notions of "confirmations" seen by different participants, before the merge.  You don't have consensus until the merge.
09:40 < Taek> pastebin sadly does not render markdown
09:41 < Taek> so you'll have to navigate to the beautiful pictures manually
09:41 < Taek> http://pastebin.com/HzCgGhVx
09:41 < bsm117532> github renders markdown :-D
09:41 < Taek> maybe I can find a trash repo then for it
09:42 < bsm117532> (the "merge" defines a cohort, and a global notion of consensus)
09:42 < Taek> ha kindly forgive me for the other dumb stuff in this repo
09:43 < Taek> https://github.com/DavidVorick/Experimental/blob/master/jute-merging.md
09:44 < sipa> Taek: gist.github.com
09:45 < bsm117532> All of your diagrams are complete cohorts (in other words they start and end with a single block).  Sure, you can further define an ordering within a cohort if you desire.
09:45 < bsm117532> But that ordering is impossible until the merge happens.
09:46 < Taek> sipa: thanks
09:46 < Taek> https://gist.github.com/DavidVorick/20a1f9f47fa56390039144d7f8dec074
09:47 < Taek> bsm117532: these cohorts can be assumed to be incomplete
09:47 < Taek> e.g. people on the other side of the network may be viewing a different set of blocks
09:47 < Taek> the 6th image sort of demonstrates that
09:48 < Taek> it shows what happens when a block gets 100 confirmations, and then 200 new blocks are added to the longest known chain
09:48 < bsm117532> And they could be seeing double spends.  You can't know what you don't know, and you don't have consensus until you do.
09:49 < Taek> the handling of double spends is explained at the bottom
09:49 < Taek> and then it says 'we'll restore SPV later' because you're only seeing an excerpt of the full post
09:49 < Taek> the part where we bring back SPV is not fully written yet
09:50 < Taek> but basically, we make it so that you don't need to know if there's a double spend or not, you just include all the blocks and all the transactions
09:50 < Taek> then you use post-processing to determine which parts of the block get included in consensus.
09:51 -!- vega4 [~pc_rafals@c0-100.icpnet.pl] has quit [Quit: Leaving]
09:52 < bsm117532> What I'm saying is that you do post processing when a merge happens (or more generally, when a cohort is formed).  Prior to the merge you can't order the blocks.
09:54 < bsm117532> Ordering, (within a cohort) for the purpose of resolving double spends can be done in many ways, I'm just using the usual "highest difficulty" rule.  I'm not sure why you need to invent a new ordering...
09:59 -!- bsm117532- [~AndChat70@172.56.36.131] has joined #bitcoin-wizards
10:00 < bsm117532-> Any other ordering will be gamed using mining hash power anyway. So "highest difficulty" is really the only ordering should use.
10:01 < bsm117532-> e.g. you can order a cohort just using block hashes. But someone will grind that hash to dictate the order in their favor.
10:03 < bsm117532-> I can show how to compute "highest work" in the presence of a DAG, and in the presence of non-constant difficulty targets among the blocks to be ordered.
10:03 < Taek> well, you always have an ordering based on the full list of blocks you know about
10:03 < Taek> my ordering description is also highest-work
10:03 < katu> one fun approach is to make the grind itself the PoW function. each block projection into the future is still 1 bit of difficulty...
10:04 < bsm117532-> Take: there's exactly one correct answer to "highest work" and if that's what you have it will be identical to mine. :-)
10:04 < bsm117532-> *Taek damn autocorrect
10:04 < katu> (imposes limit on minimum unique inputs and block size)
10:05 < Taek> I count work by summing all of the work of all known unique ancestors
10:05 < Taek> so any given block has a 'relative height' determined by all known ancestors directly for that block
10:05 < bsm117532-> A sum only works for constant difficulty (a la Satoshi's longest chain rule)
10:06 < Taek> well, if that given block is the highest work block you know about, relative height is the same as absolute height
10:06 < Taek> no you take into account the difficulty differences
10:06 < bsm117532-> Now we have to talk about how retargets happen...
10:06 < Taek> you sum the difficulties of the ancestors
10:07 < Taek> naively, retargets can work just the same as in Bitcoin
10:08 < Taek> you get some funky incentives, but it ends up making a difference of only a small percent, and only applies a small percent of the time, so imho it's not worth worrying about
10:08 < Taek> but that's also dicussed in a portion of my writeup that's incomplete atm
10:11 < bsm117532-> Retargets are a synchronous event, and the DAG is intended to be asynchronous. It's not so trivial. :-)
10:11 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
10:11 < Taek> you use a block's relative height (the parents it was pointing at) to determine which side of the retarget it is on
10:12 < Taek> after the merge, it may be on the other side of the retarget, but you just forgive the block
10:12 < Taek> the funky incentives come in because if the difficulty goes up, miners will want to have their blocks be on the pre-adjustment side of the fork
10:12 < bsm117532-> I've moved to a window of acceptable difficulty targets, so that retargets are continuous (the window changes over time)
10:12 < Taek> which means you'll get a bunch of blocks with high gaps as the miners compete for that extra revenue
10:13 < Taek> I was at one point trying to design a continuous difficulty adjustment
10:13 < Taek> but decided it added too much complexity
10:14 < Taek> primarlily for the purposes of making it more easily understandable, I've chosen to accept the awkward incentive tradeoff, because ultimately it only makes a difference of like 0.1% in revenue for a miner that is strategically mining around the diffiulty gap vs. a miner that is not
10:14 < bsm117532-> It's not so hard... Basically the size of the network can be directly translated into the window. Just a little math...
10:15 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
10:16 < katu> huh?
10:16 < katu> i thought the only gauging factor of network size is miner competition, assuming you allow it to manifest somehow (orphans etc)
10:16 < katu> and that its often a prtetty unstable guess
10:17 -!- bsm117532- [~AndChat70@172.56.36.131] has quit [Read error: Connection reset by peer]
10:17 -!- bsm117532- [~AndChat70@172.56.36.131] has joined #bitcoin-wizards
10:17 -!- AndChat-7049 [~AndChat70@38.121.165.30] has joined #bitcoin-wizards
10:18 < bsm117532> "size" is measured in seconds, and is the transit time for data across the network.
10:19 < bsm117532> Your reward schedule is a function of time R(t), and given a window of time dt defined by the network size, you can compute dR, the reward window, from the derivative dR/dt
10:19 -!- [7] [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 255 seconds]
10:20 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
10:20 < katu> so, you mean adjusting window to observed latency of propagation. again, how do you actually plan to measure latency?
10:21 < bsm117532> That latency is measured implicitly by the orphan rate in bitcoin, and the "width" of a braid/DAG -- average number of siblings.
10:21 -!- bsm117532- [~AndChat70@172.56.36.131] has quit [Ping timeout: 260 seconds]
10:22 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards
10:22 < katu> well, in bitcoin it's clear cut - adversary does not have much incentive to inflate orphan rate, as they'd hurt themselves.
10:22 < katu> but with dag, the whole point is to reward "orphans"
10:24 < bsm117532> Yes.  I argue for "Equal pay for equal (proof-of-) work"...all valid PoW hashes get rewarded.
10:24 < bsm117532> Because an asymmetry in rewards creates the selfish mining incentive.
10:25 < katu> just saying that using the dag width to influence *anything* does not strike me as good idea
10:25 < katu> given that said width can be inflated at no cost, since you explicitly adjust for it
10:26 < bsm117532> Good point.
10:27 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Ping timeout: 264 seconds]
10:27 -!- jtimon [~quassel@38.110.132.37.dynamic.jazztel.es] has quit [Remote host closed the connection]
10:27  * bsm117532 ponders
10:28 < katu> i suppose it can be fixed by still slightly disincentivizing wide dag, but unsure how
10:28 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
10:29 < NewLiberty> So it becomes what could be considered a traditional block chain at each old-enough merged braid?
10:29 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
10:29 < bsm117532> NewLiberty: yes.  By defining total-ordering events (what I call a "cohort" -- a group of blocks) those transactions can be grouped and organized into a chain.
10:30 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
10:31 < bsm117532> The simplest merging event is having a block where *all* previous blocks are its ancestors.  But you can have a 2-block parallel merge if both blocks have all preceeding blocks as ancestors.  And so on for 3, 4, etc.
10:34 -!- oleganza [~oleganza@104.193.169-200.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards
10:35 < NewLiberty> this complicates references to braid states somewhat, except at cohorts.  To refer to a transaction within several blocks at differing heights from the most previous cohort.
10:37 < katu> hmm, this sounds almost like fast chain of blocks + slow superblocks in p2pool fashion
10:37 < bsm117532> A transaction can be mined into multiple blocks, but by the "highest work" rule or Taek's ordering, only the first one is considered.  The second appearance of the same transaction doesn't modify the UTXO set.
10:37 < bsm117532> katu: it is indeed very similar
10:38 < Taek> (in the simple organization)
10:38 < Taek> (to deal with transaction fees fairly... you establish 'consensus points' and then select transactions at random to be the 'real' transaction)
10:38 < bsm117532> So NewLiberty I'd say, don't hand out references to the second appearance of the transaction...
10:39 < katu> bsm117532: so, the "slow" superblock (which tries to canonicalize all precedeing transactions, if possible) would behave pretty much same as bitcoin, like NewLiberty said.
10:39 < katu> their orphaning could be rare, but it could still happen.
10:39 < NewLiberty> defining second appearance is the complication was contemplating
10:39 < Taek> katu: depending on how you define when a cohort counts as a 'superblock', you can make orphaning extremely rare, like 1-in-quintillion rare
10:39 < NewLiberty> It works only from a reference frame
10:40 < Taek> *assuming no 51% attacker
10:40 < bsm117532> katu: There is no synchronous point where a single actor can create said superblock.  The superblocks (cohorts) are decided by examining the graph structure instead.
10:40 < bsm117532> There can be no orphaning of cohorts.
10:41 < katu> Taek: superblocks can't be reliably paced, typically they're simply blessed by bing, say, 1 in 256 blocks by blessing all blocks with 256x higher difficulty as blessed, in same way as p2pool does.
10:41 < katu> or is there a way to pace those non-stochastically?
10:41 < Taek> bsm117532: what happens if a completely new alternate history is provided where no blocks are in common, but the new history has substantially more work?
10:41 < bsm117532> Cohorts are stochastically paced, since they're derived from individual blocks, which are themselves stochastically paced.
10:41 < katu> then you'll inevitably get close races
10:41 < katu> and orphans
10:42 < Taek> katu: at least in my merging process, a 'superblock' is more of a rolling idea, and it's essentially 'anything with X confirmations', where X is on the order of 600
10:42 < Taek> *300
10:42 < Taek> but block times are on the order of 1 second
10:42 < Taek> so you get confirmations in about 5 minutes
10:42 < Taek> *
10:42 < bsm117532> Taek: When a block appears naming your new chain and the old one, their UTXO sets are merged.  Double-spends are decided in favor of the side with higher work.
10:44 < NewLiberty> If the number of threads grows to a very large number, could there become a point past which there will never again be a cohort?
10:44 < bsm117532> What changes is the definition of "confirmation" -- that is a calculation that takes into account the (known) amount of work, resulting in a probability.  There's no rule like "6 blocks deep" that makes sense...
10:44 < Taek> ah yeah, I'm not being perfectly consistent with the definitions. Sorry about that, I will try to keep things clear
10:44 < bsm117532> NewLiberty: As the block time decreases, the probability of that happening goes up exponentially fast -- because you're waiting for an accidental quiescent period on a Poisson process.
10:45 < bsm117532> NewLiberty: that's what's happening on the right side of the last graph here: https://rawgit.com/mcelrath/braidcoin/master/Braid%2BExamples.html (bottom of page)
10:49 < bsm117532> katu: an "orphan" is just an unmerged chain tip.  Any miner can add that chain tip as one of his block's parents, merging it back into the main chain.  Miners are incentivized to do this because it increases the total work behind their own block.
10:52 < Taek> yeah but if you allow orphans to be merged from arbitrary points back you get problems with long range attacks
10:52 < bsm117532> How do you perform such an attack?
10:52 < Taek> e.g. someone mines blocks for weeks and then presents hundreds of unmerged blocks all at once
10:53 < bsm117532> How is that an attack, and what does the attacker gain by doing that?
10:53 < bsm117532> (algorithmically, we can handle it...)
10:53 < Taek> how do you order blocks?
10:53 < Taek> say we have the historic chain, that's 50,000 blocks
10:53 < Taek> and then we have some new parts of the chain, that's 100 blocks
10:53 < Taek> and then the attacker dumps in 200 blocks that he's been mining for weeks
10:53 < bsm117532> I see where you're going.
10:54 < Taek> how does the merging algorithm handle that?
10:54 < Taek> if the attacker blocks ignore the 100 blocks, does the attacker's block get ordered first?
10:54 < Taek> but also, you get this data flood, which is a DoS attack on the network
10:55 < bsm117532> Define the notion of "cohort" recursively (so, sub-cohorts).  Use the network size parameter to define when you switch algorithms from including things in the cohort, to creating sub-cohorts.
10:55 < NewLiberty> A DoS attack with quite a large reward for resolving it however, yes?
10:55 < bsm117532> IOW if a bunch of blocks appear late, it's one giant cohort, according to my definition.
10:55 < Taek> if the tip of those 200 blocks have references to the 100 recent blocks, does it create a giant cohort of 300 blocks?
10:56 < Taek> with the 100 block sub-cohort?
10:56 < bsm117532> So you need a second definition of "sub-cohorts" so that you can recurse.
10:56 < bsm117532> Taek: correct.
10:57 < Taek> wouldn't that cause problems with achieving consensus? When do you know that a transaction is confirmed if there's this constant threat of 200+ blocks being dumped into the network?
10:58 < NewLiberty> It sort of relies upon the transactions and the mining using a similar network, so that information about transactions flows in the same ways that the mining does.
10:58 < bsm117532> Confirmation is defined by using the visible hashpower compared to the "high water mark" of the highest hashpower ever seen.  When I see 95% of the hashpower, an attacker with 5% won't be able to reverse any transactions.  When he broadcasts his 100 blocks, they will be a minority fork.
10:58 < NewLiberty> Or that the mining has better flow or not much worse
10:59 < katu> i still like satoshi's fix to selfish mining more
10:59 < bsm117532> katu: what's that?
10:59 < katu> it "fixes" itself over time with decreasing reward and higher fees
11:04 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
11:05 < katu> bsm117532: still, that does not invalidate what you're doing, especially for new altcoins, selfish mining could prove destructive way before diminishing coinbase reward incentive kicks in
11:05 < katu> but for bitcoin, fees already start being somewhat lucrative, they account for what, 5-10% now?
11:06 < bsm117532> I had some argument that a fee-only coin was unworkable.  It's escaping me now though...
11:07 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer]
11:07 < katu> yeah, all other bootstrap schemes seem just less appaling than fair mining race
11:08 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards
11:08 -!- Wazza [~Wazza@2001:41d0:2:2766::1] has joined #bitcoin-wizards
11:15 < NewLiberty> This system could resolve some otherwise problematic very far distant edge cases.  Like science fiction edge... consider interplanetary crypto-currencies with travelers to and from...
11:15 -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has quit [Ping timeout: 250 seconds]
11:15 -!- mdavid6131 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has joined #bitcoin-wizards
11:19 < bsm117532> I've thought a bit about that...the timescale I'm referencing is fundamentally related to the size of the Earth.  Expanding to interplanetary usage would increase the network size, and cohort time.  I think you'd want planetary coin networks, and a sidechain-like interconnection between them.
11:19 -!- jtimon [~quassel@38.110.132.37.dynamic.jazztel.es] has joined #bitcoin-wizards
11:20 < katu> NewLiberty: or more realistically - blockchains which can work over sneakernet
11:20 < katu> with enormous latencies
11:24 < NewLiberty> Either way it is a novel solution to problems that we don't really have in practice now.
11:26 < bsm117532> I'm trying to think of a use for a sneakernet coin.  Your mining hardware could be totally offline, and occasionally you grab the latest blocks and transmit your own.  The network can measure the speed of the sneakernet by the width of the braid...(yeah it's slow, but measurable)
11:26 < katu> yeah, confirm times would be proportionally large too
11:26 < katu> ie matters of days/weeks
11:26 < katu> but hey, its a sneakernet, it basically works offline
11:31 < bsm117532> Yeah, fundamentally, the braid is asynchronous where the blockchain is synchronous.  And it really doesn't care about the time scale of that asynchronicity...
11:31 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Ping timeout: 255 seconds]
11:32 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
11:34 < katu> bsm117532: well, i'd definitely focus on that. dont you make some assumptions about partitioning, though?
11:36 -!- cdecker [~cdecker@2a02:aa16:1105:4a80:8c99:8bd4:ce43:c5e7] has joined #bitcoin-wizards
11:37 < bsm117532> katu: yes, to define recursive cohorts I need a timescale at which to group things into a single cohort, or break them into sub-cohorts.  It can be a constant factor times the (measured) network size though.
11:38 < katu> sneakernets have very pronounced latency long trails. you get 80% reachability in a day, but 99% in a month
11:39 < katu> will the lagged "backwater" partitions be able to participate, or would whole network need to lag to include those?
11:39 < Taek> katu: in this sneakernet do you care about that extra 20% being able to be effective miners?
11:40 < Taek> A lot of the assumptions here is that your 90% propagation rate is hitting *miners* and not just normal nodes
11:40 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has quit [Ping timeout: 255 seconds]
11:40 < Taek> if your miners are a little tighter than your general nodes, then you can have fast consensus without risk
11:40 < bsm117532> katu: As long as that long tail is a minority, they don't affect everyone else's confirmation times.  But their transactions can never take priority over another one appearing faster.
11:41 < bsm117532> Confirmation times are basically defined by time scale at which the sneakernet reaches 50% hashpower.
11:42 < bsm117532> If one adopts my "Equal pay for equal (proof-of-)work" then the tail *can* be effective miners.
11:44 < Taek> until revenue is dominated by transaction fees
11:44 < katu> bsm117532: im more thinking of local partitions operating completely independently, and reconciling with rest of network when they happen to sync. this scenario would most likely be pow/pos mixed system, as the local communities are unlikely to have the hashpower.
11:45 < katu> it can be modelled somewhat as a sidechain already
11:45 < bsm117532> Taek: if revenue is dominated by tx fees, a "tail miner" is still profitable unless he broadcasts the transactions he's mining for other miners to mine before him.
11:46 < bsm117532> If he's doing that, why is he on the (latency) tail?
11:46 < Taek> presumably he's drawing his transactions from the mempool
11:46 < Taek> the other miners are going to have similar mempools
11:46 < bsm117532> Only if they're online ;-)
11:46 < Taek> why wouldn't they be?
11:46 < bsm117532> It's a sneakernet!  ;-)
11:46 < Taek> oh
11:46 < katu> miners are incentivized to be well connected of course, but the operating assumption is that real time communication cost is extremely high
11:47 < Taek> but I also mean in a non-sneakernet environment
11:47 -!- edvorg [~edvorg@14.169.88.102] has quit [Ping timeout: 265 seconds]
11:47 -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 244 seconds]
11:47 < Taek> katu: the goal (at least for me) is equitable mining - as long as you meet some minimum requirement for connectivity, your expected revenue per-hash is identical, regardless of connectivity or hashpower
11:48 < bsm117532> Yeah in that case a high latency miner would never win transaction fees.
11:48 < katu> so at one hand, you have to reward well-connectness in proportion to match real world well-connectness cost.
11:49 < katu> Taek: ie fixed point cutoff, either youre in a club or not.
11:49 < katu> im not sure that could work.
11:49 < Taek> I am confident that it can be made to work :)
11:49 < Taek> because I'm writing the propsal right now ha
11:50 < bsm117532> What kind of proposal?
11:50 < Taek> but yes, it's a fixed point cutoff, if you have latency to the global network in less than X seconds, you have equal revenue per-hash
11:50 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards
11:50 < Taek> and if you are below the cutoff, you basically can't participate at all
11:50 < Taek> *as a miner
11:50 < Taek> you can still participate as a node, you just need to wait for more confirmations
11:51 -!- bsm117532- [~AndChat70@172.56.18.44] has joined #bitcoin-wizards
11:52 < Taek> I'm working on a proposal for scaling bitcoin
11:52 < Taek> I was hoping to have a sample implementation by the deadline tomorrrow, but that's not going to happen
11:52 < Taek> but maybe I can have a working implementation by Milan
11:52 < Taek> I will have simulation code though that provides security bounds
11:54 -!- AndChat-7049 [~AndChat70@38.121.165.30] has quit [Ping timeout: 244 seconds]
11:54 < instagibbs_> Taek: for jute?
11:55 < Taek> yes
11:55 -!- AndChat-7049 [~AndChat70@38.121.165.60] has joined #bitcoin-wizards
11:56 -!- bsm117532- [~AndChat70@172.56.18.44] has quit [Ping timeout: 265 seconds]
11:58 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-wizards
12:00 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam]
12:02 < bsm117532> We should really work together Taek
12:02 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
12:02 < bsm117532> What's the deadline for tomorrow?
12:02 < Taek> Our methodologies are pretty different up to this point
12:03 < Taek> proposal deadline for Milan presentations is 7pm EST tomorrow
12:03 < bsm117532> From the above conversation it seems like we're converging on the same thing.  :-D
12:03 < Taek> my goal is to have a system that is fully described by that time
12:03 < Taek> including accounting for transactions fees, difficulty adjustments, etc.
12:03 < Taek> also including security arguments
12:04 < Taek> once we have that, people who have been waiting for a fully described system can join the discussion :)
12:04 < bsm117532> I see I'm not getting any sleep tonight... *sigh*
12:05 < instagibbs_> you don't have to have a fully finished presentation for proposal. You can if you want I guess
12:05 < Taek> My proposal is just going to be a blog post heh
12:06 < Taek> hopefully that's acceptable
12:12 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:6030:44b1:fd43:a0c4] has quit [Ping timeout: 250 seconds]
12:12 < instagibbs_> *shrug* I hope so, my proposal was pretty concise
12:18 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:6030:44b1:fd43:a0c4] has joined #bitcoin-wizards
12:22 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam]
12:36 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
12:38 -!- instagibbs_ [602c9182@gateway/web/freenode/ip.96.44.145.130] has quit [Ping timeout: 264 seconds]
12:40 -!- assder [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has quit [Ping timeout: 264 seconds]
12:56 -!- vega4 [~pc_rafals@c0-100.icpnet.pl] has joined #bitcoin-wizards
12:57 -!- AndChat-7049 [~AndChat70@38.121.165.60] has quit [Ping timeout: 240 seconds]
12:58 -!- vega4 [~pc_rafals@c0-100.icpnet.pl] has quit [Client Quit]
12:58 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has joined #bitcoin-wizards
13:01 -!- vega4 [~JBouncer@static.88-198-5-245.clients.your-server.de] has joined #bitcoin-wizards
13:14 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
13:16 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards
13:19 -!- rusty2 is now known as rusty
13:36 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 265 seconds]
13:45 -!- JHistone [~JHistone@cpc104808-sgyl39-2-0-cust135.18-2.cable.virginm.net] has joined #bitcoin-wizards
13:49 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
13:59 -!- e4xit_ [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-wizards
14:00 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has quit [Ping timeout: 265 seconds]
14:01 -!- e4xit_ is now known as e4xit
14:01 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has quit [Remote host closed the connection]
14:03 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam]
14:08 -!- Wazza [~Wazza@2001:41d0:2:2766::1] has quit [Read error: Connection reset by peer]
14:10 -!- kurti [~kurti@unaffiliated/kurti] has quit [Ping timeout: 276 seconds]
14:15 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]
14:20 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #bitcoin-wizards []
14:22 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
14:24 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards
14:29 -!- kurti [~kurti@unaffiliated/kurti] has joined #bitcoin-wizards
14:29 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Ping timeout: 244 seconds]
14:37 -!- MoALTz [~no@78-11-247-26.static.ip.netia.com.pl] has quit [Quit: Leaving]
14:41 -!- JHistone [~JHistone@cpc104808-sgyl39-2-0-cust135.18-2.cable.virginm.net] has quit [Quit: Leaving]
14:42 -!- JHistone [~JHistone@cpc104808-sgyl39-2-0-cust135.18-2.cable.virginm.net] has joined #bitcoin-wizards
15:07 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer]
15:07 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards
15:11 -!- Hunger- [~hunger@prodevops.net] has quit [Ping timeout: 260 seconds]
15:12 -!- Hunger- [~hunger@prodevops.net] has joined #bitcoin-wizards
15:12 -!- da2ce7_ [~da2ce7@opentransactions/dev/da2ce7] has quit [Ping timeout: 260 seconds]
15:14 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-wizards
15:23 -!- JHistone [~JHistone@cpc104808-sgyl39-2-0-cust135.18-2.cable.virginm.net] has quit [Quit: Leaving]
15:44 -!- RedEmerald [~RedEmeral@c-73-231-129-86.hsd1.ca.comcast.net] has quit [Ping timeout: 244 seconds]
15:53 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]
16:02 -!- RedEmerald [~RedEmeral@c-73-231-129-86.hsd1.ca.comcast.net] has joined #bitcoin-wizards
16:06 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-wizards
16:09 -!- r0ach [~r0ach@107-217-214-192.lightspeed.jcvlfl.sbcglobal.net] has joined #bitcoin-wizards
16:16 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 276 seconds]
16:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
16:26 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wgsjxxbsndygdrip] has quit [Quit: Connection closed for inactivity]
16:40 -!- jtimon [~quassel@38.110.132.37.dynamic.jazztel.es] has quit [Remote host closed the connection]
17:07 -!- oleganza [~oleganza@104.193.169-200.PUBLIC.monkeybrains.net] has quit [Quit: oleganza]
17:11 -!- oleganza [~oleganza@104.193.169-200.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards
17:15 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds]
17:17 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer]
17:44 -!- oleganza [~oleganza@104.193.169-200.PUBLIC.monkeybrains.net] has quit [Ping timeout: 244 seconds]
17:47 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-otfglfdrjaqxsnwa] has quit [Quit: Connection closed for inactivity]
17:55 -!- oleganza [~oleganza@md62736d0.tmodns.net] has joined #bitcoin-wizards
17:58 -!- vega4 [~JBouncer@static.88-198-5-245.clients.your-server.de] has quit [Excess Flood]
18:00 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
18:03 -!- mdavid6131 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has quit [Quit: Leaving.]
18:08 -!- oleganza [~oleganza@md62736d0.tmodns.net] has quit [Quit: oleganza]
18:12 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards
18:12 -!- vega4 [~pc_rafals@user-31-175-254-216.play-internet.pl] has joined #bitcoin-wizards
18:14 -!- vega4 [~pc_rafals@user-31-175-254-216.play-internet.pl] has quit [Read error: Connection reset by peer]
18:18 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has quit [Quit: ZNC]
18:18 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has joined #bitcoin-wizards
18:37 -!- Mazz_ [~mazznilla@unaffiliated/mazznilla] has quit [Remote host closed the connection]
19:11 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
19:16 -!- N0S4A2 [~weechat@24.35.69.143] has quit [Quit: WeeChat 1.5]
19:17 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 244 seconds]
19:18 -!- gsdgdfs [~Trans@modemcable017.144-178-173.mc.videotron.ca] has quit [Ping timeout: 276 seconds]
19:19 -!- Transisto2 [~Trans@modemcable017.144-178-173.mc.videotron.ca] has joined #bitcoin-wizards
19:27 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
19:38 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 265 seconds]
19:42 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
19:45 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]
19:45 < amiller> hi e0
19:50 < amiller> trying to understand a few parts of tumblebit better, a) if you want to create N^2 micropayments, from N senders to N receivers, how many blockchain transactions do you need, just 2N or N^2?
19:53 -!- pro [~pro@unaffiliated/pro] has quit [Quit: Leaving]
19:54 < amiller> b) you keep saying for unlinkability "we assume T does not collude with the other players" is that really necessary? it would suck if so.... if the tumbler colluded with a few payers/payees, and it wanted to try to deanonymize some other users, would it be able to?
19:54 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 265 seconds]
19:54 < amiller> i think whats happening is you're defining security with just a simple game A B and T, and clearly A and B must know that a payment is made between them
19:58 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
20:01 < amiller> c) isn't a fully formed question, just trying to undersatnd the fair exchange RSA details better
20:08 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 260 seconds]
20:13 < amiller> ah it's not really like a gradual fair release or anything
20:13 < amiller> it's in principle the same as ZKCP but with a custom proof scheme rather than a generic scheme
20:13 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
20:13 < amiller> i think you are doing amortized fair exchange though
20:14 < amiller> that's another way of viewing the micropayment channels
20:14 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:6030:44b1:fd43:a0c4] has quit [Ping timeout: 250 seconds]
20:15 < e0_> amiller: hi!
20:16 < e0_> you need 4N on-chain transactions: 2 for each payer and 2 for each payee.
20:18 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
20:18 < e0_> If Alice is paying Bob and Bob colludes with T, when they can together figure out which payee Alice is.
20:19 < e0_> The collusion only works if the party being paid works with T to reveal who the payer is.
20:19 < e0_> "if the tumbler colluded with a few  payers/payees, and it wanted to try to deanonymize some other  users, would it be able to?
20:20 < e0_> "
20:20 < e0_> No, but the payees could be eliminated for the set of suspects.
20:22 < e0_> TumbleBit in payment hub mode is very similar to the unlinkability in eCash. For instance in eCash Alice can tell the Bank the SN of her coin so that when Bob redeems that coin, the bank knows it was Alices coin.
20:22 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 255 seconds]
20:23 < e0_> In eCash Alice the payer can break the unlinkability of a particular payment that she participates in by colluding with the bank.
20:23 < e0_> In TumbleBit Bob the payee can break the unlinkability of a particular payment that he receives by colluding with the Tumbler.
20:25 < amiller> in TumbleBit that collusion can go in either direction right
20:26 < e0_> amiller  We are doing a highly performant ZKCP. The puzzle-promise-protocol is a ZKCP for an RSA encrypted ECDSA signature on a particular Bitcoin transaction. The puzzle-solver-protocol is a ZKCP for an RSA decryption of a value choosen by Alice.
20:27 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
20:27 < e0_> amiller Our does not claim to resist collusion in either direction, but payee can probably protect themself from the payer.
20:28 < e0_> amiller We didn't want to worry about that case in the proofs since it didn't seem that important and there are more important features of the protocol to improve.
20:31 < e0_> tumblebits RSA puzzles are like backwards Chaumian eCash tokens, but unlike basic Chaumian eCash the issuer of the puzzles can inspect ever puzzle it issues (similar in some respects to partially blind eCash).
20:33 < e0_> I'm pretty tired so I might not be making total sense. Shoot me an email and I can provide more thoughtful answers at a moment of more sleep.
20:33 < amiller> ok cheers thanks for the discussion here so far that was super useful :)
20:34 < amiller> also i noticed you used the Ideal/Real modeling approach, i love that :) i'm working as fast as i can on a haskell implementation and a new type system so you can implement Ideal/Real protocols, a) so you can actually run them, b) so you can c) so you can use the type checker as a sanity check and catch many errors d) it's a big step towards formal verification https://github.com/amiller/haskell-saucy
20:34 < amiller> b) was supposd to be: so you can disambiguate some of the unclear/undefined parts, like what happens when you have "reentrant functionalities"
20:35 < e0_> woah! thats awesome!
20:35 < e0_> ttyl
20:35 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 265 seconds]
20:37 < qpm> tx:<Jeremy_Rand> e0_ / amiller: I realize that the mathematical feasibility of a security property has no correlation to whether I'd like it to exist, but I think a financial anonymity system where someone whom I do business with can collude with a trusted 3rd party to deanonymize me, is a pretty big problem.  Not trying to denigrate the excellent work done here, but it does seem like something that I hope is improved in the future.
20:37 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
20:39 < amiller> yeah
20:40 -!- e0_ [~e0@cs10-dhcp127.bu.edu] has quit [Ping timeout: 244 seconds]
20:40 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
20:41 < amiller> i remember thinking about this kind of thing when we were working on Mixcoin, i think in a way this is most similar to that
20:41 < qpm> tx:<Jeremy_Rand> amiller: I'm not actually familiar with Mixcoin.  (Or if I am, I don't remember it by name.)
20:42 < amiller> we ended up only showing a protocol that had the server see the payer/payee addresses in plaintext
20:43 < amiller> we argued that you could use them in a chain like tor though
20:43 < amiller> blindcoin was an improvement to that that did what we originally wanted to do but didn't think through
20:44 -!- Mazz_ [~mazznilla@unaffiliated/mazznilla] has joined #bitcoin-wizards
20:44 < qpm> tx:<Jeremy_Rand> amiller: Yeah, Tor-like chaining would probably help, but Tor-like systems usually only are Sybil-resistant with dirauths as trusted parties.
20:44 < amiller> what the tumblebit paper says matches my memory, which is that blindcoin doesn't automatically ensure you can get your collateral back
20:45 < amiller> i wonder why you can't fix blindcoin to automatically do that?
20:46 < amiller> blindcoin is this: http://fc15.ifca.ai/preproceedings/bitcoin/paper_3.pdf
20:48 < amiller> Mixcoin and Blindcoin provide "accountability" which i think means in general you could do this on Ethereum and make it so that the mix can't see anyone or steal funds, just as good as tumblebit
20:48 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 276 seconds]
20:49 < qpm> tx:<Jeremy_Rand> Interesting
20:52 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
20:54 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:6030:44b1:fd43:a0c4] has joined #bitcoin-wizards
20:57 < amiller> you could always just mix your coin whenever you close your channel
21:02 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 276 seconds]
21:06 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
21:10 -!- Mazz_ [~mazznilla@unaffiliated/mazznilla] has quit [Ping timeout: 244 seconds]
21:14 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 250 seconds]
21:16 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 265 seconds]
21:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards
21:17 -!- Mazz_ [~mazznilla@unaffiliated/mazznilla] has joined #bitcoin-wizards
21:19 -!- bitcoin-wizards2 [6b4da102@gateway/web/freenode/ip.107.77.161.2] has joined #bitcoin-wizards
21:20 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-wizards
21:20 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
21:22 -!- pero [~pero@unaffiliated/pero] has joined #bitcoin-wizards
21:23 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
21:26 -!- bitcoin-wizards2 [6b4da102@gateway/web/freenode/ip.107.77.161.2] has quit [Ping timeout: 264 seconds]
21:28 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:30 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards
21:31 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
21:38 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 264 seconds]
21:43 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
21:45 < e0> qpm To split hairs they wouldn't deanonymize you, they would link your payment. That is the Tumbler would know that a payment from addr A was made to addr B with the assistance of the person receiving the payment at addr B.
21:48 < e0> qpm They won't learn any details of any of your other payments. I agree I wish TB protected against this and it isn't seem like an impossibility (in fact the zCash payment hub BOLT protects against this very attack).
21:49 < e0> doesn't seem like an impossibility
21:50 < e0> night
21:58 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 250 seconds]
21:58 < qpm> tx:<Jeremy_Rand> e0: I usually use the term "anonymous" to mean "no information is known about the user's identity", which implies unlinkability, whereas "pseudonymous" means that linkability is present between at least some of the user's activity.  I realize that there are varying definitions of this.
21:59 < qpm> tx:<Jeremy_Rand> So yes, I think we're talking about the same thing, just using slightly different nomenclature.
22:01 < qpm> tx:<Jeremy_Rand> I'm not incredibly familiar with the high-level differences between TB and BOLT (and perhaps it's not feasible for me to glean that from the papers given that my math knowledge may not be sufficient).
22:03 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
22:08 < e0> qpm BOLT achieves stronger anonymity than TumbleBit, but requires new op codes specifically designed for BOLT to be added to zCash. TumbleBit works with today's Bitcoin and has running code that did a 800 user mix on mainnet.
22:08 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:6030:44b1:fd43:a0c4] has quit [Ping timeout: 250 seconds]
22:09 < qpm> tx:<Jeremy_Rand> e0: I see.  That's a good high-level explanation, thank you.
22:11 < e0> qpm The real accomplishment with TumbleBit IMO is getting all this complex privacy and fairness machinary to work via a few op_hashes and to be performant (0.6 seconds of CPU time).
22:12 < qpm> tx:<Jeremy_Rand> e0: Yes, it is definitely impressive that TB can do what it does within those script and performance constraints.
22:16 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 250 seconds]
22:20 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
22:41 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 244 seconds]
22:44 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has quit [Quit: Verlassend]
22:45 -!- oleganza [~oleganza@c-73-170-224-149.hsd1.ca.comcast.net] has joined #bitcoin-wizards
22:46 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
22:59 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 265 seconds]
22:59 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-umqvfhiestmlvalq] has joined #bitcoin-wizards
23:03 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
23:04 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
23:12 -!- assder [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-wizards
23:16 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:6030:44b1:fd43:a0c4] has joined #bitcoin-wizards
23:17 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 265 seconds]
23:20 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 265 seconds]
23:21 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
23:34 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 250 seconds]
23:38 -!- oleganza [~oleganza@c-73-170-224-149.hsd1.ca.comcast.net] has quit [Quit: oleganza]
23:38 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
23:44 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 240 seconds]
23:45 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards
23:48 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-wizards
23:54 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 255 seconds]
23:56 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
23:58 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards
--- Log closed Fri Sep 09 00:00:49 2016