| --- Log opened Thu Sep 08 00:00:48 2016 | ||
| -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-wizards | 00:04 | |
| -!- PeterR [cf5125a7@gateway/web/freenode/ip.207.81.37.167] has quit [Ping timeout: 264 seconds] | 00:06 | |
| -!- 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:09 | |
| -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards | 00:11 | |
| -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 244 seconds] | 00:12 | |
| -!- sipi [~sipi@165.64.broadband12.iol.cz] has joined #bitcoin-wizards | 00:28 | |
| -!- oleganza [~oleganza@c-73-170-224-149.hsd1.ca.comcast.net] has quit [Quit: oleganza] | 00:32 | |
| -!- daddinuz [~daddinuz@212.91.77.78] has joined #bitcoin-wizards | 00:34 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 276 seconds] | 00:46 | |
| -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has left #bitcoin-wizards [] | 00:47 | |
| -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 250 seconds] | 00:51 | |
| -!- daddinuz [~daddinuz@212.91.77.78] has quit [Quit: Leaving] | 01:08 | |
| -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-wizards | 01:12 | |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| -!- alan_ [~alan@flyingarm.bar] has joined #bitcoin-wizards | 01:33 | |
| -!- alan_ is now known as Alanius | 01:34 | |
| -!- 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:36 | |
| -!- sipi [~sipi@165.64.broadband12.iol.cz] has quit [Quit: Leaving] | 01:37 | |
| sipa | Taek: fibre relays before receiving the full block | 01:43 |
| sipa | and it seems to help a lot | 01:43 |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 01:44 | |
| -!- 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] | 01:59 | |
| -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-wizards | 02:03 | |
| -!- cdecker [~cdecker@2a02:aa16:1105:4a80:8c99:8bd4:ce43:c5e7] has joined #bitcoin-wizards | 02:05 | |
| -!- Hunger- [~hunger@prodevops.net] has quit [Ping timeout: 260 seconds] | 02:12 | |
| -!- Hunger- [~hunger@prodevops.net] has joined #bitcoin-wizards | 02:22 | |
| -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Read error: Connection reset by peer] | 02:25 | |
| -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards | 02:26 | |
| -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-wizards | 02:26 | |
| vega4 | Taek: thank you for posting the paper, I haven't seen it before | 02:40 |
| -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds] | 02:41 | |
| -!- pro [~pro@unaffiliated/pro] has joined #bitcoin-wizards | 02:41 | |
| -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards | 02:43 | |
| -!- Emcy_ [~MC@unaffiliated/mc1984] has quit [Quit: Leaving] | 02:54 | |
| -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards | 02:54 | |
| -!- lmatteis_ is now known as lmatteis | 03:04 | |
| -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-wizards | 03:06 | |
| -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds] | 03:11 | |
| -!- JackH [~Jack@79-73-191-94.dynamic.dsl.as9105.com] has quit [Ping timeout: 240 seconds] | 03:20 | |
| -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards | 03:21 | |
| -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds] | 03:30 | |
| -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 03:39 | |
| -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards | 03:45 | |
| -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-wizards | 03:53 | |
| -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 265 seconds] | 04:08 | |
| -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards | 04:12 | |
| -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 244 seconds] | 04:15 | |
| -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds] | 04:20 | |
| -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards | 04:25 | |
| -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds] | 04:38 | |
| -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards | 04:44 | |
| -!- 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:01 | |
| -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-wizards | 05:04 | |
| -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 264 seconds] | 05:08 | |
| -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] | 05:09 | |
| -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards | 05:11 | |
| -!- laurentmt [~Thunderbi@80.215.210.95] has quit [Quit: laurentmt] | 05:12 | |
| -!- xeon-enouf [~xeon-enou@unaffiliated/xeon-enouf] has joined #bitcoin-wizards | 05:16 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 05:17 | |
| -!- jtimon [~quassel@38.110.132.37.dynamic.jazztel.es] has joined #bitcoin-wizards | 05:17 | |
| -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards | 05:21 | |
| -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds] | 05:41 | |
| -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards | 05:47 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-wizards | 05:50 | |
| -!- vega4 [~pc_rafals@user-31-175-254-216.play-internet.pl] has quit [Ping timeout: 250 seconds] | 05:59 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 06:12 | |
| -!- 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:19 | |
| -!- cdecker [~cdecker@2a02:aa16:1105:4a80:8c99:8bd4:ce43:c5e7] has quit [Ping timeout: 260 seconds] | 06:20 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 252 seconds] | 06:22 | |
| -!- Guyver2_ is now known as Guyver2 | 06:22 | |
| -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds] | 06:23 | |
| -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Ping timeout: 250 seconds] | 06:24 | |
| -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards | 06:34 | |
| -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-wizards | 06:50 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 06:55 | |
| -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards | 07:05 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer] | 07:07 | |
| -!- 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:08 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 07:10 | |
| -!- assder [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-wizards | 07:17 | |
| -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-wizards | 07:23 | |
| -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] | 07:28 | |
| -!- contrapumpkin is now known as copumpkin | 07:30 | |
| -!- face_ [~face@mail.hmel.org] has joined #bitcoin-wizards | 07:35 | |
| 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:37 |
| bsm1175321 | That result can be found at the bottom of: https://rawgit.com/mcelrath/braidcoin/master/Braid%2BExamples.html | 07:38 |
| -!- face_ is now known as face | 07:39 | |
| bsm1175321 | (so confirmation time goes up exponentially fast at that point...maybe that was your point?) | 07:40 |
| -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:b8e2:1c9c:fe32:8ba2] has quit [Ping timeout: 250 seconds] | 07:47 | |
| -!- edvorg [~edvorg@14.169.88.102] has joined #bitcoin-wizards | 07:51 | |
| -!- MoALTz [~no@78-11-247-26.static.ip.netia.com.pl] has joined #bitcoin-wizards | 07:55 | |
| -!- edvorg [~edvorg@14.169.88.102] has quit [Remote host closed the connection] | 07:59 | |
| -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:6030:44b1:fd43:a0c4] has joined #bitcoin-wizards | 08:08 | |
| -!- edvorg [~edvorg@14.169.88.102] has joined #bitcoin-wizards | 08:09 | |
| -!- 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:11 | |
| -!- vega4 [~pc_rafals@c0-100.icpnet.pl] has joined #bitcoin-wizards | 08:12 | |
| -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-wizards | 08:12 | |
| tromp | make | 08:14 |
| -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 265 seconds] | 08:16 | |
| vega4 | have you got any papers at hand related to the subject of incentives which would enchance exchange of transactions among full nodes? | 08:18 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| -!- 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:32 | |
| -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds] | 08:37 | |
| -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards | 08:52 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection] | 08:55 | |
| -!- Mazz_ [~mazznilla@unaffiliated/mazznilla] has quit [Ping timeout: 244 seconds] | 08:55 | |
| -!- 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 | 08:58 | |
| -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving] | 09:02 | |
| -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Ping timeout: 276 seconds] | 09:03 | |
| -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds] | 09:04 | |
| -!- mdavid613 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has joined #bitcoin-wizards | 09:25 | |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| -!- 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:40 |
| 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:41 |
| 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:42 |
| Taek | https://github.com/DavidVorick/Experimental/blob/master/jute-merging.md | 09:43 |
| sipa | Taek: gist.github.com | 09:44 |
| 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:45 |
| Taek | sipa: thanks | 09:46 |
| Taek | https://gist.github.com/DavidVorick/20a1f9f47fa56390039144d7f8dec074 | 09:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| -!- vega4 [~pc_rafals@c0-100.icpnet.pl] has quit [Quit: Leaving] | 09:51 | |
| 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:52 |
| 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:54 |
| -!- bsm117532- [~AndChat70@172.56.36.131] has joined #bitcoin-wizards | 09:59 | |
| bsm117532- | Any other ordering will be gamed using mining hash power anyway. So "highest difficulty" is really the only ordering should use. | 10:00 |
| 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:01 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| Taek | naively, retargets can work just the same as in Bitcoin | 10:07 |
| 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:08 |
| 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:11 |
| 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:12 |
| Taek | I was at one point trying to design a continuous difficulty adjustment | 10:13 |
| Taek | but decided it added too much complexity | 10:13 |
| 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:14 |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 10:15 | |
| 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:16 |
| -!- 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:17 | |
| bsm117532 | "size" is measured in seconds, and is the transit time for data across the network. | 10:18 |
| 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:19 | |
| -!- 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:20 |
| 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:21 | |
| -!- 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:22 |
| 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:24 |
| 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:25 |
| bsm117532 | Good point. | 10:26 |
| -!- 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:27 | |
| 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:28 | |
| 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:29 |
| -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] | 10:30 | |
| 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:31 |
| -!- oleganza [~oleganza@104.193.169-200.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards | 10:34 | |
| 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:35 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:44 |
| 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:45 |
| 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:49 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 10:59 |
| -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards | 11:04 | |
| 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:05 |
| bsm117532 | I had some argument that a fee-only coin was unworkable. It's escaping me now though... | 11:06 |
| -!- 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:07 |
| -!- 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:08 | |
| 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:15 | |
| 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:19 | |
| katu | NewLiberty: or more realistically - blockchains which can work over sneakernet | 11:20 |
| katu | with enormous latencies | 11:20 |
| NewLiberty | Either way it is a novel solution to problems that we don't really have in practice now. | 11:24 |
| 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:26 |
| 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:31 | |
| -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] | 11:32 | |
| katu | bsm117532: well, i'd definitely focus on that. dont you make some assumptions about partitioning, though? | 11:34 |
| -!- cdecker [~cdecker@2a02:aa16:1105:4a80:8c99:8bd4:ce43:c5e7] has joined #bitcoin-wizards | 11:36 | |
| 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:37 |
| katu | sneakernets have very pronounced latency long trails. you get 80% reachability in a day, but 99% in a month | 11:38 |
| 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:39 |
| 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:40 |
| bsm117532 | Confirmation times are basically defined by time scale at which the sneakernet reaches 50% hashpower. | 11:41 |
| bsm117532 | If one adopts my "Equal pay for equal (proof-of-)work" then the tail *can* be effective miners. | 11:42 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| -!- bsm117532- [~AndChat70@172.56.18.44] has joined #bitcoin-wizards | 11:51 | |
| 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:52 |
| -!- AndChat-7049 [~AndChat70@38.121.165.30] has quit [Ping timeout: 244 seconds] | 11:54 | |
| instagibbs_ | Taek: for jute? | 11:54 |
| Taek | yes | 11:55 |
| -!- AndChat-7049 [~AndChat70@38.121.165.60] has joined #bitcoin-wizards | 11:55 | |
| -!- bsm117532- [~AndChat70@172.56.18.44] has quit [Ping timeout: 265 seconds] | 11:56 | |
| -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-wizards | 11:58 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 12:00 | |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| Taek | hopefully that's acceptable | 12:06 |
| -!- 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:12 |
| -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:6030:44b1:fd43:a0c4] has joined #bitcoin-wizards | 12:18 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 12:22 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 12:36 | |
| -!- instagibbs_ [602c9182@gateway/web/freenode/ip.96.44.145.130] has quit [Ping timeout: 264 seconds] | 12:38 | |
| -!- assder [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has quit [Ping timeout: 264 seconds] | 12:40 | |
| -!- vega4 [~pc_rafals@c0-100.icpnet.pl] has joined #bitcoin-wizards | 12:56 | |
| -!- AndChat-7049 [~AndChat70@38.121.165.60] has quit [Ping timeout: 240 seconds] | 12:57 | |
| -!- 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 | 12:58 | |
| -!- vega4 [~JBouncer@static.88-198-5-245.clients.your-server.de] has joined #bitcoin-wizards | 13:01 | |
| -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 13:14 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards | 13:16 | |
| -!- rusty2 is now known as rusty | 13:19 | |
| -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 265 seconds] | 13:36 | |
| -!- JHistone [~JHistone@cpc104808-sgyl39-2-0-cust135.18-2.cable.virginm.net] has joined #bitcoin-wizards | 13:45 | |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 13:49 | |
| -!- e4xit_ [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-wizards | 13:59 | |
| -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has quit [Ping timeout: 265 seconds] | 14:00 | |
| -!- 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:01 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] | 14:03 | |
| -!- Wazza [~Wazza@2001:41d0:2:2766::1] has quit [Read error: Connection reset by peer] | 14:08 | |
| -!- kurti [~kurti@unaffiliated/kurti] has quit [Ping timeout: 276 seconds] | 14:10 | |
| -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds] | 14:15 | |
| -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #bitcoin-wizards [] | 14:20 | |
| -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards | 14:22 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards | 14:24 | |
| -!- kurti [~kurti@unaffiliated/kurti] has joined #bitcoin-wizards | 14:29 | |
| -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Ping timeout: 244 seconds] | 14:29 | |
| -!- MoALTz [~no@78-11-247-26.static.ip.netia.com.pl] has quit [Quit: Leaving] | 14:37 | |
| -!- JHistone [~JHistone@cpc104808-sgyl39-2-0-cust135.18-2.cable.virginm.net] has quit [Quit: Leaving] | 14:41 | |
| -!- JHistone [~JHistone@cpc104808-sgyl39-2-0-cust135.18-2.cable.virginm.net] has joined #bitcoin-wizards | 14:42 | |
| -!- 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:07 | |
| -!- Hunger- [~hunger@prodevops.net] has quit [Ping timeout: 260 seconds] | 15:11 | |
| -!- Hunger- [~hunger@prodevops.net] has joined #bitcoin-wizards | 15:12 | |
| -!- da2ce7_ [~da2ce7@opentransactions/dev/da2ce7] has quit [Ping timeout: 260 seconds] | 15:12 | |
| -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-wizards | 15:14 | |
| -!- JHistone [~JHistone@cpc104808-sgyl39-2-0-cust135.18-2.cable.virginm.net] has quit [Quit: Leaving] | 15:23 | |
| -!- RedEmerald [~RedEmeral@c-73-231-129-86.hsd1.ca.comcast.net] has quit [Ping timeout: 244 seconds] | 15:44 | |
| -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] | 15:53 | |
| -!- RedEmerald [~RedEmeral@c-73-231-129-86.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 16:02 | |
| -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-wizards | 16:06 | |
| -!- r0ach [~r0ach@107-217-214-192.lightspeed.jcvlfl.sbcglobal.net] has joined #bitcoin-wizards | 16:09 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 276 seconds] | 16:16 | |
| -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards | 16:17 | |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wgsjxxbsndygdrip] has quit [Quit: Connection closed for inactivity] | 16:26 | |
| -!- jtimon [~quassel@38.110.132.37.dynamic.jazztel.es] has quit [Remote host closed the connection] | 16:40 | |
| -!- oleganza [~oleganza@104.193.169-200.PUBLIC.monkeybrains.net] has quit [Quit: oleganza] | 17:07 | |
| -!- oleganza [~oleganza@104.193.169-200.PUBLIC.monkeybrains.net] has joined #bitcoin-wizards | 17:11 | |
| -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds] | 17:15 | |
| -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] | 17:17 | |
| -!- oleganza [~oleganza@104.193.169-200.PUBLIC.monkeybrains.net] has quit [Ping timeout: 244 seconds] | 17:44 | |
| -!- btcdrak [uid165369@gateway/web/irccloud.com/x-otfglfdrjaqxsnwa] has quit [Quit: Connection closed for inactivity] | 17:47 | |
| -!- oleganza [~oleganza@md62736d0.tmodns.net] has joined #bitcoin-wizards | 17:55 | |
| -!- vega4 [~JBouncer@static.88-198-5-245.clients.your-server.de] has quit [Excess Flood] | 17:58 | |
| -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] | 18:00 | |
| -!- mdavid6131 [~Adium@cpe-104-172-191-85.socal.res.rr.com] has quit [Quit: Leaving.] | 18:03 | |
| -!- oleganza [~oleganza@md62736d0.tmodns.net] has quit [Quit: oleganza] | 18:08 | |
| -!- 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:12 | |
| -!- vega4 [~pc_rafals@user-31-175-254-216.play-internet.pl] has quit [Read error: Connection reset by peer] | 18:14 | |
| -!- 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:18 | |
| -!- Mazz_ [~mazznilla@unaffiliated/mazznilla] has quit [Remote host closed the connection] | 18:37 | |
| -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards | 19:11 | |
| -!- N0S4A2 [~weechat@24.35.69.143] has quit [Quit: WeeChat 1.5] | 19:16 | |
| -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 244 seconds] | 19:17 | |
| -!- gsdgdfs [~Trans@modemcable017.144-178-173.mc.videotron.ca] has quit [Ping timeout: 276 seconds] | 19:18 | |
| -!- Transisto2 [~Trans@modemcable017.144-178-173.mc.videotron.ca] has joined #bitcoin-wizards | 19:19 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards | 19:27 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 265 seconds] | 19:38 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards | 19:42 | |
| -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] | 19:45 | |
| amiller | hi e0 | 19:45 |
| 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:50 |
| -!- pro [~pro@unaffiliated/pro] has quit [Quit: Leaving] | 19:53 | |
| 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:54 |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards | 19:58 | |
| amiller | c) isn't a fully formed question, just trying to undersatnd the fair exchange RSA details better | 20:01 |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 260 seconds] | 20:08 | |
| 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:13 |
| 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:14 | |
| e0_ | amiller: hi! | 20:15 |
| e0_ | you need 4N on-chain transactions: 2 for each payer and 2 for each payee. | 20:16 |
| -!- 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:18 |
| 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:19 |
| e0_ | " | 20:20 |
| e0_ | No, but the payees could be eliminated for the set of suspects. | 20:20 |
| 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:22 | |
| 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:23 |
| amiller | in TumbleBit that collusion can go in either direction right | 20:25 |
| 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:26 |
| -!- 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:27 |
| 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:28 |
| 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:31 |
| 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:33 |
| 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:34 |
| e0_ | woah! thats awesome! | 20:35 |
| e0_ | ttyl | 20:35 |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 265 seconds] | 20:35 | |
| 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:37 | |
| amiller | yeah | 20:39 |
| -!- e0_ [~e0@cs10-dhcp127.bu.edu] has quit [Ping timeout: 244 seconds] | 20:40 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards | 20:40 | |
| 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:41 |
| amiller | we ended up only showing a protocol that had the server see the payer/payee addresses in plaintext | 20:42 |
| 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:43 |
| -!- 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:44 |
| amiller | i wonder why you can't fix blindcoin to automatically do that? | 20:45 |
| amiller | blindcoin is this: http://fc15.ifca.ai/preproceedings/bitcoin/paper_3.pdf | 20:46 |
| 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:48 | |
| qpm | tx:<Jeremy_Rand> Interesting | 20:49 |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards | 20:52 | |
| -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:6030:44b1:fd43:a0c4] has joined #bitcoin-wizards | 20:54 | |
| amiller | you could always just mix your coin whenever you close your channel | 20:57 |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 276 seconds] | 21:02 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards | 21:06 | |
| -!- Mazz_ [~mazznilla@unaffiliated/mazznilla] has quit [Ping timeout: 244 seconds] | 21:10 | |
| -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 250 seconds] | 21:14 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 265 seconds] | 21:16 | |
| -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-wizards | 21:17 | |
| -!- Mazz_ [~mazznilla@unaffiliated/mazznilla] has joined #bitcoin-wizards | 21:17 | |
| -!- bitcoin-wizards2 [6b4da102@gateway/web/freenode/ip.107.77.161.2] has joined #bitcoin-wizards | 21:19 | |
| -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-wizards | 21:20 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards | 21:20 | |
| -!- pero [~pero@unaffiliated/pero] has joined #bitcoin-wizards | 21:22 | |
| -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds] | 21:23 | |
| -!- bitcoin-wizards2 [6b4da102@gateway/web/freenode/ip.107.77.161.2] has quit [Ping timeout: 264 seconds] | 21:26 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] | 21:28 | |
| -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards | 21:30 | |
| -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 21:31 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 264 seconds] | 21:38 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards | 21:43 | |
| 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:45 |
| 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:48 |
| e0 | doesn't seem like an impossibility | 21:49 |
| e0 | night | 21:50 |
| -!- 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:58 |
| qpm | tx:<Jeremy_Rand> So yes, I think we're talking about the same thing, just using slightly different nomenclature. | 21:59 |
| 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:01 |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards | 22:03 | |
| 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:08 | |
| qpm | tx:<Jeremy_Rand> e0: I see. That's a good high-level explanation, thank you. | 22:09 |
| 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:11 |
| qpm | tx:<Jeremy_Rand> e0: Yes, it is definitely impressive that TB can do what it does within those script and performance constraints. | 22:12 |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 250 seconds] | 22:16 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards | 22:20 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 244 seconds] | 22:41 | |
| -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has quit [Quit: Verlassend] | 22:44 | |
| -!- oleganza [~oleganza@c-73-170-224-149.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 22:45 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards | 22:46 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 265 seconds] | 22:59 | |
| -!- Ylbam [uid99779@gateway/web/irccloud.com/x-umqvfhiestmlvalq] has joined #bitcoin-wizards | 22:59 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards | 23:03 | |
| -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards | 23:04 | |
| -!- assder [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-wizards | 23:12 | |
| -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:6030:44b1:fd43:a0c4] has joined #bitcoin-wizards | 23:16 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 265 seconds] | 23:17 | |
| -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 265 seconds] | 23:20 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards | 23:21 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 250 seconds] | 23:34 | |
| -!- 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:38 | |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 240 seconds] | 23:44 | |
| -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-wizards | 23:45 | |
| -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-wizards | 23:48 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 255 seconds] | 23:54 | |
| -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] | 23:56 | |
| -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards | 23:58 | |
| --- Log closed Fri Sep 09 00:00:49 2016 | ||
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!