--- Log opened Mon Jan 16 00:00:06 2017 00:09 -!- edvorg [~edvorg@116.58.254.251] has joined #bitcoin-wizards 00:15 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 00:15 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards 00:17 -!- dkings [~dkings@81.193.44.230] has joined #bitcoin-wizards 00:20 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 258 seconds] 00:22 -!- dkings [~dkings@81.193.44.230] has quit [Ping timeout: 248 seconds] 00:26 -!- BitBully [~Mutter@197.210.25.37] has joined #bitcoin-wizards 00:35 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-wizards 00:41 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection] 00:41 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards 00:42 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-wizards 00:52 -!- BitBully [~Mutter@197.210.25.37] has quit [Quit: Mutter: www.mutterirc.com] 00:56 -!- kenshi84 [~kenshi84@103.5.140.171] has joined #bitcoin-wizards 01:11 -!- dkings [~dkings@81.193.44.230] has joined #bitcoin-wizards 01:12 -!- kenshi84 [~kenshi84@103.5.140.171] has quit [Quit: Leaving...] 01:16 -!- dkings [~dkings@81.193.44.230] has quit [Ping timeout: 252 seconds] 01:31 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:c092:439b:71e3:67d1] has joined #bitcoin-wizards 01:35 -!- kenshi84 [~kenshi84@103.5.140.171] has joined #bitcoin-wizards 01:35 -!- cannon-c is now known as cannon-c_AFK 01:43 -!- kenshi84 [~kenshi84@103.5.140.171] has quit [Remote host closed the connection] 01:44 -!- kenshi84 [~kenshi84@103.5.140.171] has joined #bitcoin-wizards 01:48 -!- kenshi84 [~kenshi84@103.5.140.171] has quit [Ping timeout: 252 seconds] 02:02 -!- cannon-c_AFK is now known as cannon-c 02:19 -!- davec [~davec@cpe-24-243-230-253.hot.res.rr.com] has quit [Ping timeout: 240 seconds] 02:23 -!- Uglux [~uglux@unaffiliated/uglux] has joined #bitcoin-wizards 02:24 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards 02:34 -!- edvorg [~edvorg@116.58.254.251] has quit [Ping timeout: 240 seconds] 02:43 -!- BitBully [~Mutter@197.210.25.35] has joined #bitcoin-wizards 02:48 -!- Starduster [~guest@unaffiliated/starduster] has quit [Ping timeout: 240 seconds] 02:53 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards 03:07 -!- kenshi84 [~kenshi84@4.178.138.210.rev.vmobile.jp] has joined #bitcoin-wizards 03:19 -!- trotski2000 [uid206086@gateway/web/irccloud.com/x-hcoexleatsotfqna] has quit [Changing host] 03:19 -!- trotski2000 [uid206086@unaffiliated/trotski2000] has joined #bitcoin-wizards 03:19 -!- trotski2000 [uid206086@unaffiliated/trotski2000] has quit [Changing host] 03:19 -!- trotski2000 [uid206086@gateway/web/irccloud.com/x-hcoexleatsotfqna] has joined #bitcoin-wizards 03:32 -!- markus-k [~markus@server01.comtime-it.eu] has quit [Quit: ZNC 1.6.1 - http://znc.in] 03:33 -!- markus-k [~markus@server01.comtime-it.eu] has joined #bitcoin-wizards 03:33 -!- BitBully [~Mutter@197.210.25.35] has quit [Ping timeout: 240 seconds] 03:37 -!- BitBully [~Mutter@197.210.25.37] has joined #bitcoin-wizards 03:47 -!- kenshi84_ [~kenshi84@80.78.239.49.rev.vmobile.jp] has joined #bitcoin-wizards 03:48 -!- kenshi84 [~kenshi84@4.178.138.210.rev.vmobile.jp] has quit [Ping timeout: 245 seconds] 04:17 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:c092:439b:71e3:67d1] has quit [Ping timeout: 256 seconds] 04:25 -!- kenshi84_ [~kenshi84@80.78.239.49.rev.vmobile.jp] has quit [Read error: Connection reset by peer] 04:28 -!- reBrain [~quassel@unaffiliated/rebrain] has joined #bitcoin-wizards 04:30 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:4dac:381:ac6c:df94] has joined #bitcoin-wizards 04:37 -!- kenshi84 [~kenshi84@2400:7800:48db:9100:ed:6c3b:e1f5:c5e3] has joined #bitcoin-wizards 04:44 -!- BitBully [~Mutter@197.210.25.37] has quit [Read error: Connection reset by peer] 05:01 -!- daddinuz [~daddinuz@212.91.77.78] has joined #bitcoin-wizards 05:02 -!- daddinuz [~daddinuz@212.91.77.78] has quit [Client Quit] 05:14 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards 05:16 -!- BitBully [~Mutter@197.210.25.136] has joined #bitcoin-wizards 05:20 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 05:20 -!- BitBully [~Mutter@197.210.25.136] has quit [Client Quit] 05:28 -!- pro [~pro@unaffiliated/pro] has joined #bitcoin-wizards 05:50 -!- BitBully [~Mutter@197.210.24.16] has joined #bitcoin-wizards 05:58 -!- BitBully [~Mutter@197.210.24.16] has quit [Quit: Mutter: www.mutterirc.com] 06:00 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has quit [Quit: Page closed] 06:01 -!- BitBully [~Mutter@197.210.25.12] has joined #bitcoin-wizards 06:03 -!- reBrain [~quassel@unaffiliated/rebrain] has quit [Read error: Connection reset by peer] 06:05 -!- BitBully [~Mutter@197.210.25.12] has quit [Client Quit] 06:21 -!- kenshi84 [~kenshi84@2400:7800:48db:9100:ed:6c3b:e1f5:c5e3] has quit [Quit: Leaving...] 06:21 -!- kenshi84 [~kenshi84@2400:7800:48db:9100:ed:6c3b:e1f5:c5e3] has joined #bitcoin-wizards 06:24 -!- Jeremy_Rand[m] [jeremyrand@gateway/shell/matrix.org/x-wtrcmtnwgqhksaei] has quit [Remote host closed the connection] 06:26 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds] 06:26 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards 06:39 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 06:49 -!- Jeremy_Rand[m] [jeremyrand@gateway/shell/matrix.org/x-eezjggiytxfrmbwn] has joined #bitcoin-wizards 06:58 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards 07:03 -!- testnetting [b27545ce@gateway/web/freenode/ip.178.117.69.206] has joined #bitcoin-wizards 07:07 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 07:07 < testnetting> hey 07:07 < testnetting> anyone here ... ? 07:09 < testnetting> That day Voldemort logged on .. 07:10 < testnetting> he didn't hide his IP adress ... 07:10 < testnetting> Did one hide it on purpose ? 07:24 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds] 07:24 < kanzure> tor exit node, yo 07:24 < kanzure> no doxxing. 07:26 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards 07:28 < testnetting> access.telenet.be/178.117.69. ... 07:31 < testnetting> i bet - access.telenet.be/178.117.69 .... shows up before he supp. used the Tor exit node? Anyway to check ? 07:31 < kanzure> do you need his identity for some reason? 07:32 < testnetting> No - i know his identity. 07:34 < testnetting> I am merely trying to find out how easy ore hard it is to find that ip address 07:36 < testnetting> Do you remember that day ? 07:37 < kanzure> what do you need 07:38 < testnetting> Did you ask him if he was Satoshi ? 07:42 -!- kenshi84 [~kenshi84@2400:7800:48db:9100:ed:6c3b:e1f5:c5e3] has quit [Quit: Leaving...] 07:42 -!- kenshi84 [~kenshi84@2400:7800:48db:9100:ed:6c3b:e1f5:c5e3] has joined #bitcoin-wizards 07:49 < testnetting> ? 07:49 < testnetting> Yes 07:50 < testnetting> His reply ... 07:50 < testnetting> I have to say no ? 07:50 < testnetting> better - 07:51 < testnetting> I have to say no. 07:51 < testnetting> ? 07:51 < testnetting> True ore False ? 07:51 < testnetting> Kanzure ? 07:57 < gmaxwell> testnetting: please cut out the subject; it's invasive and weird and making me uncomfortable. 08:00 < testnetting> It is important " to me " so someone can answer that question ? 08:04 -!- mode/#bitcoin-wizards [+o gmaxwell] by ChanServ 08:04 -!- mode/#bitcoin-wizards [+b *!*@gateway/web/freenode/ip.178.117.69.206] by gmaxwell 08:04 -!- testnetting was kicked from #bitcoin-wizards by gmaxwell [testnetting] 08:04 -!- mode/#bitcoin-wizards [-o gmaxwell] by gmaxwell 08:08 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 08:25 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards 08:35 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 08:49 -!- Pr0t3us [~Pr0t3us@unaffiliated/pr0t3us] has quit [Quit: Leaving] 08:50 -!- JayDugger [~jwdugger@47.185.237.246] has left #bitcoin-wizards [] 08:52 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-wizards 09:00 -!- mmeijeri [3efb099d@gateway/web/freenode/ip.62.251.9.157] has joined #bitcoin-wizards 09:01 < mmeijeri> I've been thinking about weak blocks some more. It would seem that with weak blocks there is no longer any need/point to using something like NG, is that correct? 09:08 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Ping timeout: 255 seconds] 09:09 -!- AlineGomes [uid198215@gateway/web/irccloud.com/x-zhkdjhuqpwofkzoj] has quit [Quit: Connection closed for inactivity] 09:20 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 09:21 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards 09:22 -!- BitBully [~Mutter@197.210.24.47] has joined #bitcoin-wizards 09:23 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards 09:26 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 255 seconds] 09:29 -!- BitBully [~Mutter@197.210.24.47] has quit [Quit: Mutter: www.mutterirc.com] 09:31 -!- anon616 [~nobody@ec2-52-207-226-93.compute-1.amazonaws.com] has quit [Remote host closed the connection] 09:40 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards 09:47 -!- davec [~davec@cpe-24-243-230-253.hot.res.rr.com] has joined #bitcoin-wizards 09:50 -!- anon616 [~nobody@ec2-52-207-226-93.compute-1.amazonaws.com] has joined #bitcoin-wizards 09:53 -!- Davasny [~quassel@78.10.231.191] has joined #bitcoin-wizards 10:03 -!- Uglux [~uglux@unaffiliated/uglux] has quit [Quit: Leaving] 10:14 -!- reBrain [~quassel@unaffiliated/rebrain] has joined #bitcoin-wizards 10:17 -!- atgreen [~green@CPE10da438ecb59-CM00fc8d24cab0.cpe.net.cable.rogers.com] has quit [Ping timeout: 260 seconds] 10:29 -!- atgreen [~green@CPE10da438ecb59-CM00fc8d24cab0.cpe.net.cable.rogers.com] has joined #bitcoin-wizards 11:05 -!- reBrain [~quassel@unaffiliated/rebrain] has quit [Remote host closed the connection] 11:15 -!- forrestv [forrestv@unaffiliated/forrestv] has quit [Ping timeout: 252 seconds] 11:18 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has joined #bitcoin-wizards 11:23 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has joined #bitcoin-wizards 11:28 -!- mol [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer] 11:31 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds] 11:35 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards 11:41 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 11:41 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 11:43 -!- bitcoin-wizards0 [bcbc1c8d@gateway/web/freenode/ip.188.188.28.141] has joined #bitcoin-wizards 11:43 < bitcoin-wizards0> Test 11:44 -!- bitcoin-wizards0 [bcbc1c8d@gateway/web/freenode/ip.188.188.28.141] has quit [Client Quit] 11:45 -!- bitcoin-wizards2 [bcbc1c8d@gateway/web/freenode/ip.188.188.28.141] has joined #bitcoin-wizards 11:47 -!- bitcoin-wizards2 [bcbc1c8d@gateway/web/freenode/ip.188.188.28.141] has quit [Client Quit] 11:48 -!- bitcoinbilly [bcbc1c8d@gateway/web/freenode/ip.188.188.28.141] has joined #bitcoin-wizards 11:55 < bitcoinbilly> Does everyone agree we will have to alter the bitcoin protocol ? 11:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards 11:58 -!- bramc [634b58ce@gateway/web/freenode/ip.99.75.88.206] has joined #bitcoin-wizards 11:58 -!- ipwn [~ipwn@bl18-232-89.dsl.telepac.pt] has quit [Ping timeout: 255 seconds] 11:58 < bramc> Hey everybody 11:59 -!- ipwn [~ipwn@bl18-232-89.dsl.telepac.pt] has joined #bitcoin-wizards 11:59 < kanzure> what's up 11:59 < bitcoinbilly> MimbleWimble sidechains integrated smart contracts script a new verification systen 11:59 -!- mode/#bitcoin-wizards [+o kanzure] by ChanServ 12:00 < bramc> On the topic of weak blocks: There are several different approaches one could take. A lot of it depends on whether you're assuming that blocks are full or not. Mostly weak blocks act as a form of compression 12:00 < bitcoinbilly> ' lighting network on top of that .. 12:01 < bramc> When a weak block goes out it's safe to propagate it because there's enough work behind it that you don't have to worry about spam. A 'real' block can then be compressed later as a delta to a weak block, which will make it propagate faster 12:02 < bitcoinbilly> a new concept I like to introduce - satoshi group flooder. 12:03 < bitcoinbilly> This can be implemented after one payment channel settles 12:07 < mmeijeri> I was wondering if NG had any remaining advantages over weak blocks. 12:07 < bitcoinbilly> A satoshi group flooder is a automated system wich evenly distributes the in bitcoin transaction terms the flooding output in and from a payment channel. If 12:08 < bitcoinbilly> If any 12:08 < bitcoinbilly> If any in the current payment channel scheme .. 12:10 -!- dkings [~dkings@81.193.44.230] has joined #bitcoin-wizards 12:13 -!- dkings [~dkings@81.193.44.230] has quit [Remote host closed the connection] 12:13 < bitcoinbilly> Is this already discussed ? 12:13 -!- dkings [~dkings@bl4-44-230.dsl.telepac.pt] has joined #bitcoin-wizards 12:15 -!- dkings [~dkings@bl4-44-230.dsl.telepac.pt] has quit [Remote host closed the connection] 12:17 < bramc> I'm not sure what you're describing Billy 12:17 < bramc> mmeijeri: What is NG? 12:19 -!- gigq [~gigq@45-20-197-26.lightspeed.austtx.sbcglobal.net] has quit [Ping timeout: 272 seconds] 12:19 <@kanzure> bramc: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011528.html 12:19 <@kanzure> http://diyhpl.us/wiki/transcripts/scalingbitcoin/blockchain-testbed/ (start near "Speaking of beyond") 12:20 -!- dkings [~dkings@bl4-44-230.dsl.telepac.pt] has joined #bitcoin-wizards 12:20 <@kanzure> and http://diyhpl.us/~bryan/papers2/bitcoin/Bitcoin-NG:%20A%20scalable%20blockchain%20protocol.pdf 12:20 -!- gigq [~gigq@2602:302:d14c:51a0:155b:252a:803b:495e] has joined #bitcoin-wizards 12:23 < bitcoinbilly> When the MimbleWimble chain enherates the bitcoin from the transaction these coins wil be used in unidirectional payment channels I'm trying to establish if these coins wil be held in a wallet deducted to a end user ore the MimbleWimble payment/fund group 12:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds] 12:24 -!- jcluck [~cluckj@pool-173-49-237-221.phlapa.fios.verizon.net] has joined #bitcoin-wizards 12:25 < bitcoinbilly> When the value of such a group doesn't change -meaning no mimblewimblebitcoin leave this group anyone in the group should and could use the coins ? 12:25 < bramc> I was going to say that weak blocks increase time to commit a bit but, uh, NG does far more of that 12:27 < bitcoinbilly> Sharing our Welt 12:27 < bitcoinbilly> Welth ss 12:27 < mmeijeri> My feeling is that NG, though interesting, is not as good as weak blocks. 12:27 -!- dkings [~dkings@bl4-44-230.dsl.telepac.pt] has quit [Remote host closed the connection] 12:28 -!- cluckj [~cluckj@pool-173-49-237-221.phlapa.fios.verizon.net] has quit [Ping timeout: 256 seconds] 12:28 -!- ratbaneb_ [~ratbanebo@ptr-fyxkxbuxs24c6r8u331.18120a2.ip6.access.telenet.be] has quit [] 12:28 < bitcoinbilly> The only value leaving this system would be tax money witch one still has to pay of course. . 12:28 -!- dkings [~dkings@81.193.44.230] has joined #bitcoin-wizards 12:29 < bitcoinbilly> This must not be done bye the sharing our wealth system 12:29 < bitcoinbilly> Of course :) 12:33 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 12:33 < bramc> mmeijeri: That's my feeling as well, and why I never proposed anything like NG myself. 12:36 < bitcoinbilly> Bitcoin is the way of the future haven't you heard? 12:36 < bitcoinbilly> Smile 12:36 <@kanzure> i think bitcoinbilly == testnetting ? 12:36 <@kanzure> gonna kick 12:37 < bitcoinbilly> yes baby kick me and be a fool 12:37 -!- bitcoinbilly was kicked from #bitcoin-wizards by kanzure [bitcoinbilly] 12:37 <@kanzure> gladly. 12:37 -!- mode/#bitcoin-wizards [-o kanzure] by kanzure 12:39 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards 12:40 -!- bitcoin-wizards9 [bcbc1c8d@gateway/web/freenode/ip.188.188.28.141] has joined #bitcoin-wizards 12:43 -!- jcluck is now known as cluckj 12:44 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:cd2b:f49d:fe68:cdf9] has quit [Quit: .] 12:44 < bitcoin-wizards9> We are dead serious! Has anyone thought about what I just described ? Sleep on it - unkick me tomorrow ... Goodnight 12:47 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-wizards 12:50 < bramc> I didn't follow what was described 12:51 < kanzure> i think it was the same user causing more trouble from earlier today 12:57 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 256 seconds] 12:58 < bramc> Anyone who wants to play along can now watch me make commits all with the comment 'bug fix' for the next month https://github.com/bramcohen/MerkleSet 12:58 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 13:02 < mmeijeri> Are weak blocks superior to having smaller but more frequent normal blocks? If so, what are the advantages? 13:03 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [] 13:04 < bitcoin-wizards9> If asking questions is causing trouble maybe we can stop developing bitcoin into what we immagenid it would be. 13:04 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has quit [Ping timeout: 252 seconds] 13:04 < kanzure> what is your question 13:04 -!- priidu [~priidu@unaffiliated/priidu] has quit [Remote host closed the connection] 13:08 -!- bildeamer1 is now known as bildramer 13:08 < bramc> mmeijeri: Much lower orphan rate from weak blocks. More frequent smaller blocks makes for faster commit times and more orphans. Weak blocks make fewer orphans with slightly slower commit times 13:08 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards 13:09 < mmeijeri> why doesn't the smaller size compensate for the shorter interblock interval? 13:11 < bramc> Because the latencies which cause orphaning are not primarily caused by block sizes. Peter R is lying to you. 13:11 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has joined #bitcoin-wizards 13:15 < bitcoin-wizards9> read the log - and remove the ban ! 13:17 < Eliel_> mmeijeri: also, once a large majority of miners are using weak blocks to coordinate their transaction selection, the weak blocks start having some value as weaker confirmations as well. 13:18 < mmeijeri> right. as for orphan rates: I know that Rizun's claim is false, but I thought it was true for the block transmission mechanism as it was before compact blocks. Is that not the case? 13:18 < bramc> Eliel_: They provide some confirmation of the block they're on top of, particularly if you let them be chained, but they don't resurrect zeroconf 13:19 < Eliel_> bramc: I don't expect them to do that 13:19 < bramc> mmeijeri: BlueMatt's backbone thing makes latencies very low as long as you use it verbatim. It's a fairly unpleasant point of centralization though. 13:19 < mmeijeri> sure 13:20 < mmeijeri> but still, it would be nice to try to narrow the gap between the general p2p transmission mechanism and RN/Fibre 13:20 < Eliel_> bramc: although, I'm not sure if you're aware, but there are still services accepting zeroconfs. Even without weak blocks. 13:20 < bramc> Yes weak blocks would be a good thing, particularly if they're soft forked in nicely 13:21 < bramc> Eliel_: Not My Problem 13:21 < Eliel_> bramc: I'm just trying to make the point that zeroconf isn't exactly dead yet. 13:22 < bramc> It's undead 13:22 < Eliel_> I expect lightning to take over for those services once we get the malleability problem dealt with once and for all. 13:23 < mmeijeri> It would be nice if we could go back to 100kb blocks for a while after LN to see what would happen to the full node count 13:24 < BlueMatt> bramc: if someone bothered to audit the thing I'd be perfectly happy with people using it in ip-multicast mode :p 13:24 < Eliel_> mmeijeri: I'm not too hopeful about that, but it's possible. 13:24 < BlueMatt> but, then, everyone would have to be on sprint's backbone 13:24 < bramc> BlueMatt: The internet supports multicast? 13:24 < BlueMatt> bramc: only if you're on sprint 13:24 < BlueMatt> "internet" 13:25 * BlueMatt is still confused why people love weakblocks....they really dont do all that much better than fibre for reasonable block sizes 13:25 < BlueMatt> especially if you soft-forked in a fibre commitment (which is slightly infeasiable without putting it at the root of the merkle tree, but....) 13:26 < bramc> What do you mean by fibre? Is that your backbone? 13:26 < BlueMatt> its the software that powers the backbone, but it could be used p2p-ish 13:26 < BlueMatt> the only reason i dont recommend that is lack of audit for the pile of code I wrote that no one has really ever looked at 13:26 < bramc> Mostly weak blocks are more decentralized 13:26 < BlueMatt> not really, though? 13:27 < Eliel_> BlueMatt: what's the main difference between fibre and weakblocks? 13:27 < bramc> If implemented properly weak blocks could be almost as performant as fibre with no centralized infrastructure at all 13:27 < BlueMatt> weak blocks disadvantage those who cant reliably create weak blocks quickly 13:27 < BlueMatt> eg if you cant create a weak block reliably within a few tens of seconds after new blocks then you're not able to select transactions 13:27 < BlueMatt> and are forced to use whatever selection bigger miners do 13:28 < BlueMatt> Eliel_: they're pretty fundamentally different - fibre is gonna stream everything at block-creation-time, whereas weak blocks are an attempt to frontload that 13:28 < bramc> Uh... That depends on a lot of details. There are a few approaches 13:28 < BlueMatt> Eliel_: for current block sizes streaming at line rate at block-creation-time is really not a problem 13:28 < BlueMatt> if you want 100MB blocks, it would be moreso, but not for 1/2/4/10MB 13:29 < bramc> Also the way you design weak blocks varies a lot depending on whether you're assuming blocks are full all the time and transactions are constantly getting replaced with higher value versions 13:29 < Eliel_> ah right, not when a block is found but when you start attempting to find a block. 13:29 < BlueMatt> bramc: maybe I'm missing some modern variants? last I spoke with gmaxwell on the subject I remained unconvinced 13:29 < BlueMatt> (though, admittedly, I seem to be rather alone in that opinion) 13:29 < bramc> There's also a reasonable argument that blocks should be propagated with just the headers at first so others can start mining off the new one immediately even before validation happens 13:30 < BlueMatt> my concern is that weak blocks do not provide much advantage over fibre with a good fec (which is now being used) - ultimately if you want to select transactions which are not pre-relayed you're gonna have to send them 13:30 < kanzure> what is the reasonable argument 13:30 < bramc> I haven't walked through all the variants with you or gmaxwell yet. It's an interesting engineering problem. 13:30 < Eliel_> BlueMatt: although, would you need to slap some kind of a PoW on to fibre eventually to limit the bandwidth use? That'd seem to remove the difference mostly. 13:30 < BlueMatt> whereas with weakblocks you can only pre-relay transactions which have hashpower behind them, fibre you can pre-forward anything 13:31 < BlueMatt> Eliel_: one idea is to have miners commit to each fibre packet with a merkle tree 13:31 < BlueMatt> Eliel_: the current implementation does not do cut-through, ie it must receive the full block and check its sanity before relaying on 13:31 < BlueMatt> (except in "trusted networks") 13:32 < BlueMatt> sadly the commitment stuff is only realistically doable if you put it at the root of the bitcoin-tx merkle root 13:32 < BlueMatt> otherwise it takes up just barely too many bytes to be practical on internet-sized packets 13:33 < BlueMatt> bramc: I think most any protocol will do that (fibre does so, but really most stuff anyone designs ends up doing that at least by accident because you naturally send the header first) 13:34 < Eliel_> BlueMatt: it seems to me that the only major difference in a p2p versions of each would be that fibre as you described doesn't come with a built-in PoW mechanism to limit network usage. 13:35 < BlueMatt> Eliel_: nothing has a mechanism to limit inbound bandwidth, limiting outbound bandwidth is easy by just checking pow before you relay? 13:35 < BlueMatt> (or are you asking about rate control, ie the thing udp makes you do manually?) 13:35 < Eliel_> BlueMatt: no, just limiting relay bandwidth. 13:38 < BlueMatt> wait, what are you asking about? I mean there's a few issues - not knowing how much data the other side needs, ie how much to send (you could come up with clever protocols here where you pairwise keep track of /roughly/ what your peers have and only send a small amount of fec) 13:39 < mmeijeri> aren't weak blocks synergistic with Fibre? 13:39 < mmeijeri> preconsensus means sketches can be smaller, no? 13:39 < mmeijeri> and of course they do narrow the gap between the p2p network and Fibre 13:40 < mmeijeri> or rather: sketches can remain small even as blocks grow 13:41 < BlueMatt> slightly, yes...I mean weak blocks are another method of pre-forward, except that they're a bit more rigid 13:41 < Eliel_> or, let's put it this way. With weakblocks, if you're receiving more blocks than you have processing power to verify, you can just pick the ones with highest PoW on them and check&relay them and the end result will be that the choices will be reasonably cohesive on the whole network. 13:41 < BlueMatt> I'd be happy to see weak blocks combined with fibre (ie to allow miners to select txn which have low fees for pre-forward) 13:41 < BlueMatt> but only weak blocks I think is shit 13:41 < BlueMatt> Eliel_: oh, you super dont want to do that 13:42 < BlueMatt> Eliel_: that highly encourages matching transaction selection across the network 13:42 < BlueMatt> and forces smaller miners to just use the tx selection from larger ones 13:43 < mmeijeri> precisely why would weak blocks only and no fibre be shit compared to just fibre or both fibre and weak blocks? (I'm all in favour of combining the two, just trying to understand the tradeoffs) 13:43 < BlueMatt> of course I dont think thats neccessary - a) you dont need to validate weak blocks unless you care about latency (ie are a miner), b) you should be able to (mostly) trivially compress them - they're super duplicative 13:43 < BlueMatt> mmeijeri: purely concerns over encouraging matching transaction selection 13:43 < mmeijeri> right 13:44 < BlueMatt> imagine you set your weakblocks difficulty pretty high, now you're kinda forced as a small miner to use the tx selection from larger miners 13:44 < BlueMatt> which is shit 13:44 -!- bramc [634b58ce@gateway/web/freenode/ip.99.75.88.206] has quit [Ping timeout: 260 seconds] 13:44 < Eliel_> BlueMatt: I don't think there needs to be a set weakblocks difficulty. 13:44 < mmeijeri> got it. so what's the latest thinking on the relative strength of weak blocks? 13:44 < BlueMatt> lol, did I scare bramc off? 13:45 < BlueMatt> mmeijeri: I think I have a unique viewpoint in not being a huge fan of weak blocks, so not sure what "the latest thinking" is 13:45 < Eliel_> nodes just start dropping the weakest ones if they can't handle all of them for whatever reason. 13:45 < BlueMatt> Eliel_: sure, but you want to make sure its pretty low 13:45 < mmeijeri> sorry, I meant how much weaker do we want them to be, 10x, 100x? 13:45 < BlueMatt> (the minium weak blocks requirement, that is) 13:46 < BlueMatt> mmeijeri: look at it this way - if you're censored today on bitcoin, you can spin up some hashrate for relatively cheap that will confirm your transaction by mining a block once a day or every 2 days or once a week 13:46 < Eliel_> BlueMatt: I don't think there really needs to be a minimum difficulty. Rather, node admins should be able to set a bandwidth limit for them and that'd lead to the difficulty. 13:46 < BlueMatt> if we just used weak blocks (and actually had issues with propagation), you couldnt do that 13:47 < mmeijeri> that's an interesting yardstick 13:47 < BlueMatt> I havent run the numbers (someone bored and want to?) but I think even being able to mine your block once a day would be pretty hard on the above yardstick 13:47 < kanzure> Eliel_: it's a consensus parameter, though (difficulty) 13:47 < Eliel_> kanzure: for weak blocks? 13:47 < BlueMatt> (assume you need to get a single weak block and then also, during the same block time, mine a full block) 13:47 < BlueMatt> kanzure: only if you soft-fork in weak blocks 13:47 < BlueMatt> which i think is a shit idea 13:48 < kanzure> ok. 13:48 < mmeijeri> soft fork it in? why isn't this outside the consensus layer? 13:48 < BlueMatt> (again, probably not in the majority in my viewpoint there) 13:48 < mmeijeri> it's just the network layer, right? 13:48 < BlueMatt> well, or maybe am for consensus 13:50 < Eliel_> BlueMatt: anyway, I do see the concern with the censorship resistance weakening if you need lots of PoW to get transactions included in any blocks. 13:51 < BlueMatt> admittedly any reasonable weak blocks impl would have a differential encoding 13:51 < BlueMatt> so it may not be a massive concern 13:52 < BlueMatt> but my point, more, is that we have a great differential encoding in fibre/compact blocks already, and unless we're concerned with with miners being able to include transactions which do not have a high fee (ie are not otherwise propagating) then I dont see a ton of gain 13:52 < Eliel_> although, wouldn't that just mean that you'd need to add bigger fees to get around censorship? Big enough to convince miners to include the transactions despite the increased orphaning potential 13:53 < BlueMatt> potentially 13:54 < BlueMatt> these stats are now out of date due to my being too lazy to fix the script given the fibre cuts in india/singapore, but take a look at http://bitcoinfibre.org/stats.html 13:54 < Eliel_> although, if majority of hashpower colludes to censor transactions, they can just completely block them anyway. 13:54 < BlueMatt> mostly how super flat the prop. times are 13:54 -!- bitcoinbilly [bcbc1c8d@gateway/web/freenode/ip.188.188.28.141] has joined #bitcoin-wizards 13:55 * BlueMatt concludes propagation is a "solved problem" 13:55 < mmeijeri> would that remain the case if blocks became significantly larger though? 13:55 < BlueMatt> pretty mch 13:55 < BlueMatt> much 13:55 < mmeijeri> how do you know? 13:55 < BlueMatt> would have to find a fatter link out of china, maybe 13:55 < bitcoinbilly> Hello. 13:56 < BlueMatt> because the amount of data usually used to transmit a block over the fibre network is almost always in the 10-20 packet range 13:56 < mmeijeri> wouldn't that be a percentage of the block size? 13:56 -!- bitcoin-wizards9 [bcbc1c8d@gateway/web/freenode/ip.188.188.28.141] has quit [Ping timeout: 260 seconds] 13:56 < mmeijeri> more or less fixed 13:56 < BlueMatt> and when its not you can almost always divide the size of the differential encoding by the link speed and get the time-to-transmit plus a handful of ms 13:56 < BlueMatt> nope, not at all 13:56 < BlueMatt> its a function of compact block encoding size 13:57 < BlueMatt> which is (mostly) disconnected from block size 13:57 < BlueMatt> see-also https://github.com/bitcoin/bitcoin/pull/9499 13:57 < mmeijeri> that's the bit I'm not getting 13:57 < BlueMatt> there are a few things we can do to better get transactions pre-forwarded across the p2p network 13:57 < mmeijeri> you are basically trying to predict what the other side hasn't heard, no? 13:57 < BlueMatt> nope 13:57 < BlueMatt> you arent predicting anything 13:58 < mmeijeri> ok, then I'm confused 13:58 < BlueMatt> you're sending everything...it just so happens that the other side can reconstruct the instant it has all the transactions 13:58 < mmeijeri> right 13:58 < BlueMatt> and that means, roughly, the size of the differential encoding 13:58 < mmeijeri> ah yes, but that's what I meant, the size of the differential encoding 13:58 < BlueMatt> it turns out on the network today you pretty much never miss more than one or three transactions per block 13:58 < mmeijeri> I'm not talking about packet loss 13:58 < BlueMatt> especially if you include transactions you rejected as double-spends in your mempool 13:59 < mmeijeri> I know you aren't trying to predict packet loss, the fec takes care of that 13:59 < BlueMatt> well I'm saying you dont have to do anything interactive to predict missing txn 13:59 < mmeijeri> but in the differential encoding aren't you sort of predicting what txs the other side doesn't have in its mempool? 13:59 < BlueMatt> you stream everything and even if the other side has no txn in its mempool you still send the same encoding 13:59 < BlueMatt> and it still works just as well 13:59 < Eliel_> mmeijeri: you can send to the data in a form that will get you all the missing txn, no matter which ones you're missing. 13:59 < BlueMatt> the encoding is disconnected from the txn missing on the other side 14:00 < BlueMatt> it just so happens that you will reconstruct after you've received the number of packets which totals in size the same as the txn you're missing 14:00 < BlueMatt> because the fec is good 14:01 < mmeijeri> ok hang on, let me see if I'm getting this right 14:01 < Eliel_> mmeijeri: you can basically just treat the missing txns like they're packet loss. 14:01 < Eliel_> and send the fec data 14:01 < mmeijeri> in fibre today, you are using fec to compensate both for missing txs and lost packets? 14:01 < BlueMatt> (required pump of the guy who wrote the fec's bitcoin donation address: https://github.com/catid/wh256/issues/4) 14:01 < BlueMatt> mmeijeri: yes 14:02 < mmeijeri> ah great, that's what I was asking you a while back and you seemed to be saying no 14:02 < mmeijeri> (already donated) 14:02 < BlueMatt> ok, sorry, irc communication is hard 14:02 < mmeijeri> ok, but that's pretty spectacular! 14:02 < mmeijeri> I thought this was the hard part that had remained unimplemented 14:03 < BlueMatt> yes, see stats page...95th percentile gets blocks around whole network in 18ms + speed of light 14:03 -!- Peter__R [b8448a62@gateway/web/freenode/ip.184.68.138.98] has joined #bitcoin-wizards 14:03 < mmeijeri> does this mean that if you receive incoming blocks from two peers simultaneously the are synergystic? 14:03 < BlueMatt> so I'd call block propagation a solved problem on the technical level until we have much bigger blocks...needs solving on the social level still (getting peers on the public fibre network, getting audits on the fibre codebase so that we can get public connections using it, etc) 14:04 < Eliel_> mmeijeri: as long as they aren't sending you identical data, yes. 14:04 < mmeijeri> great 14:04 < BlueMatt> mmeijeri: this is where the "trusted" thing come in from before 14:04 < BlueMatt> fibre has two modes, one where that is true, one where it isnt 14:04 < mmeijeri> I knew this was in Greg maxwell's sketch, but I didn't know it had been implemented yet 14:04 < BlueMatt> in "private trusted network" mode, where you trust the data coming from everyone in your network, yes, they are synnergistic 14:05 < BlueMatt> and fibre is designed to relay packets in funny order to help this 14:05 < BlueMatt> sadly, the fec isnt designed to handle malicious or corrupted data 14:05 < bitcoinbilly> image a closed system where we can interact extensively and share our accumulated welth. If al members of the system interact within the system the original value remains equal. 14:05 < mmeijeri> I'm enormously impressed. great work! 14:06 < BlueMatt> so in order to extend it to work in public networks with the same cut-through+synnergistic data properties, miners would need to commit to the fibre chunks 14:06 < mmeijeri> I've been leveling up my old algebra skills to understand the maths behind it 14:06 < BlueMatt> there was some private-chain project where they actually did this 14:06 < BlueMatt> and it worked super well 14:06 < mmeijeri> finite fields and Frobenius automorphisms for the win 14:06 < BlueMatt> sadly to fit in the 1500 byte - overhead limit on the internet, we'd have to have the commitments be at the top of the merkle tree :( 14:07 < BlueMatt> (and have the merkle tree use a reduced-length hash, but thats probably fine) 14:07 < mmeijeri> just to check today's other bit of unexpectedly good news: are you saying that, audits aside, the nontrusted mode is basically ready to be integrated with the p2p layer? 14:07 < Eliel_> BlueMatt: isn't it possible to have the protocol use an efficient encoding in the protocol and just reconstruct the actual structure afterward? 14:08 < BlueMatt> mmeijeri: not quite - it needs flow control 14:08 < BlueMatt> right now you manually commit bandwidth to it 14:08 < mmeijeri> right 14:08 < BlueMatt> and it doesnt have negotiation of said bandwidth 14:08 < Peter__R> mmeijeri: It's easy to see why decreasing the interblock time increases orphan rates. For simplicity, assume that propgation time = t0 + zQ where Q is the number of bytes transmitted and z and t0 are constants. 14:08 < Peter__R> Going to a smaller interblock time makes the "t0" constant portion of block transmission a larger fraction of the interblock time. 14:08 < BlueMatt> but aside from that, yes 14:08 < mmeijeri> we've talked about this before, but maybe quic or some other protocol bramc and I were briefly discussing the other day might help 14:08 < Peter__R> And thus makes orphan races more likely. 14:09 < BlueMatt> mmeijeri: yes, streaming it over something that handles the flow control for you might work 14:09 < BlueMatt> though quic is overkill since it does ordering and serialization 14:09 < BlueMatt> which we dont need/want 14:09 < BlueMatt> plus quic is, itself, adding fec 14:10 < BlueMatt> which would be overkill 14:10 < BlueMatt> Eliel_: E_NO_PARSE 14:10 < mmeijeri> I forget the name of the other protocol. it sounded a bit like PEBKAC 14:10 < bitcoinbilly> For now taxes would need to be paid sepperatly and the intrinsic value is volatile. Miners exchange coins to pay there cost. This doesn't affect the closed system mutch 14:11 < Eliel_> BlueMatt: the commitment size problem. 14:11 < BlueMatt> still confused? 14:11 < kanzure> bitcoinbilly: what is your question 14:11 < BlueMatt> the issue (i hate irc, always hard to tell what was and wasnt effectively communicated and what was misread) is you need to be able to tell, after receiving each packet, that it was faithfully calculated from the given block 14:12 < BlueMatt> otherwise you end up in some hellscape where you're trying to figure out which packet was bad, or if the whole thing was garbage 14:12 < BlueMatt> (there are FECs which handle corruption, so maybe that would be sufficient here, but that is a whole nother level of complexity) 14:13 -!- bramc [6b4dd440@gateway/web/freenode/ip.107.77.212.64] has joined #bitcoin-wizards 14:14 < bramc> Ordering and serialization don't really hurt performance 14:14 < BlueMatt> bramc: they do if you miss enough packets to have to do a rtt 14:14 < BlueMatt> but, otherwise, yes, sure 14:14 < mmeijeri> @bramc: do you remember the name of that protocol we were discussing the other day? It was developed by a guy who worked with you on Bittorrent. 14:14 < bitcoinbilly> Why not ? If we redistribute the value token we spent again into the closed system . The only fluctuation is the mining fee. 14:14 < bramc> If you miss enough packets your congestion control might want to slow down anyway. 14:15 < bramc> mmeijeri: ledbat? uTP? 14:15 < BlueMatt> bramc: the whole point of fibre is to literally never wait for an rtt 14:15 < BlueMatt> which, yea, blows up flow control 14:15 < mmeijeri> ledbat was what I was looking for. The thing that sounded like PEBKAC :-) 14:15 < BlueMatt> oh, yea, that one 14:16 < BlueMatt> i mean decent flow control is kinda at odds with low-latency communication 14:16 < BlueMatt> unless your window size is big enough to get the whole block in it 14:16 < bramc> BlueMatt: It could be that bittorrent-live style flow control would help 14:16 < BlueMatt> have you explained that one to me? i forget? 14:17 < bramc> The basic idea is that there are a bunch of 'clubs' (specifically 6 in the BitTorrent Live case), each peer is a member of a club, and every piece of data is assigned to a club. You blast out data within your own club with no flow control and download everything else with real flow control from someone who is in the club 14:17 < BlueMatt> oh, yes, ok, i remember this 14:18 < bramc> It's a trick for getting the low latency of a screamer protocol while still having efficiency and flow control 14:18 < BlueMatt> yea, that would probably work fine 14:18 < BlueMatt> the annoying thing is fibre is super random - sometimes you need 100kb sometimes (usually) only 5 14:19 < BlueMatt> so with no flow control you throw away a ton of bw 14:19 < BlueMatt> luckily its already separated into chunks - the first is the header + a bit of compact block metadata 14:19 < BlueMatt> so you could scream that out to all your peers all the time for pretty cheap 14:19 < BlueMatt> the second is transaction data, which you could scream out based on a club-like thing 14:19 < BlueMatt> and then request from other clubs if you didnt get enough 14:20 < BlueMatt> yea, club stuff would probably work super well here if you want it to be p2p 14:21 < bitcoinbilly> Imagine 3.5 billion people participating 14:22 < bramc> The main trick is to have 2 or 3 incoming and outgoing connections within your own club so you don't waste too much. There are attacks on peer selection though. 14:22 < BlueMatt> yea, sounds about right 14:22 < BlueMatt> peer selection is always a bitch :( 14:24 -!- kenshi84 [~kenshi84@2400:7800:48db:9100:ed:6c3b:e1f5:c5e3] has quit [Remote host closed the connection] 14:24 -!- kenshi84 [~kenshi84@i118-17-11-238.s41.a008.ap.plala.or.jp] has joined #bitcoin-wizards 14:24 < bitcoinbilly> There are possibilitys available wich can be used to prevent drainage 14:25 < mmeijeri> found it, this was the protocol we were talking about the other day: https://www.anmolsarma.in/post/dccp/ 14:26 < bitcoinbilly> bitcoin economics :) a new field of economy 14:26 < mmeijeri> but according to wikipedia it is old hat: https://en.wikipedia.org/wiki/Datagram_Congestion_Control_Protocol 14:27 < bitcoinbilly> read the log - end the ban ! 14:28 * BlueMatt kanzure now would be an opportune time to ban bitcoinbilly with a fun joke 14:29 -!- mode/#bitcoin-wizards [+o kanzure] by ChanServ 14:29 < BlueMatt> one day I'll learn the difference between /me and /ms 14:29 < BlueMatt> g 14:29 < BlueMatt> but not today 14:29 -!- bildramer1 [~bildramer@p2003004D2B28FF00F0304CF43923D2EC.dip0.t-ipconnect.de] has joined #bitcoin-wizards 14:29 -!- kenshi84 [~kenshi84@i118-17-11-238.s41.a008.ap.plala.or.jp] has quit [Ping timeout: 256 seconds] 14:29 <@kanzure> bitcoinbilly: perhaps you should go to #bitcoin instead 14:30 -!- bildramer [~bildramer@p2003004D2B28FF00AC9BCCA14258DFA9.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds] 14:31 -!- bitcoinbilly [bcbc1c8d@gateway/web/freenode/ip.188.188.28.141] has quit [Ping timeout: 260 seconds] 14:32 < mmeijeri> Explicit connection establishment between hosts Selectable congestion control schemes Path MTU discovery to avoid fragmentation Service Codes for identifying applications 14:33 < mmeijeri> but still unreliable and no fec, so less overlap with Fibre 14:33 < mmeijeri> and therefore perhaps a better fit than QUIC? 14:33 -!- bitcoin-wizards8 [bcbc1c8d@gateway/web/freenode/ip.188.188.28.141] has joined #bitcoin-wizards 14:34 < BlueMatt> probably, though doint something protocol-specific like bramc's club-based suggestion might be better yet 14:35 < bramc> mmeijeri: AUGH! 14:35 < bramc> That shit doesn't work, trust me, I'm the world's leading expert in this space 14:35 < mmeijeri> dccp you mean? 14:36 < BlueMatt> bramc: when you say shit like that I have a knee-jerk reaction to punch you in the face....until I realize its you and you're not wrong 14:36 < bramc> mmeijeri: No it's the preset tree which doesn't work not the particular congestion scheme you use along links 14:37 < BlueMatt> yea, preset trees sound like a bad idea 14:37 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] 14:38 < mmeijeri> I've no idea what that means but I'll take your word for it. @bluematt: is the only reason for trusted mode that it would screw up joint reconstruction from two sources if one were malicious or is there more to it? 14:38 -!- Peter__R [b8448a62@gateway/web/freenode/ip.184.68.138.98] has quit [Ping timeout: 260 seconds] 14:39 < BlueMatt> mmeijeri: i read "preset trees" to be a tree along which you distribute blocks isntead of a blind swarm-y thing 14:39 < BlueMatt> mmeijeri: exactly 14:40 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards 14:40 < BlueMatt> well, malicious or generating garbage, but...same thing 14:40 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 14:40 < mmeijeri> I thought DCCP was purely point-to-point 14:41 < BlueMatt> mmeijeri: note that fibre also does cut-through routing in trusted mode, so each packet you receive you forward along to all your (trusted) peers without any validation/reconstruction 14:42 < BlueMatt> (this gives it the wonderful scalability property where nodes in the network tend to receive blocks with the same amount of time needed for receive (ie time from first packet to reconstruction) irrespective of the number of hops passed through on the way 14:42 < BlueMatt> ) 14:42 -!- kenshi84 [~kenshi84@126.179.138.210.rev.vmobile.jp] has joined #bitcoin-wizards 14:45 < mmeijeri> ah yes, that's great too 14:45 < mmeijeri> another question about the fec and missing txs: does this mean that we're closing to being able to implement p2p mempool synchronisation too? 14:45 < BlueMatt> but makes the malicious peer poblem worse 14:45 < BlueMatt> I'm not sure where we are on p2p mempool sync 14:46 < BlueMatt> I think someone was talking about doing it using the old invertable bloom stuff 14:46 < mmeijeri> why can't you do it with the same fec you are using for fibre? 14:46 < BlueMatt> greg had some ideas, but never got around to actually running numbers on them, iir 14:46 < BlueMatt> c 14:47 < BlueMatt> i suppose you could shove all the txids in your mempool over a certain feerate in a simple fec and send it 14:47 < mmeijeri> and you could negotiate the fee rate 14:48 < mmeijeri> and signal the other side to stop sending info once they have everything 14:48 < BlueMatt> yea, last i heard any discussion of mempool sync you want to eg do "top 2MB of my mempool" after every block, and have more backoff for lower down in your mempool 14:48 < BlueMatt> would have to ask gmaxwell 14:48 < BlueMatt> he had some ideas, and is way more equipped to answer that question than I 14:48 < mmeijeri> anyway, I'm really excited this stuff has progressed so far already 14:49 < BlueMatt> yea, its pretty cool 14:49 < BlueMatt> fibre is pretty awesome in its effectiveness 14:49 < BlueMatt> i mean the stats are like astoundingly reliable 14:49 < BlueMatt> it pretty much never takes any more time than a handful of ms + the actual data you wanted to send 14:49 < BlueMatt> except when my vm in chain pauses randomly 14:49 * BlueMatt hates vms 14:50 < BlueMatt> but all the non-china servers are physical servers so they tend to be rock solid 14:51 < BlueMatt> well, except for fiber cuts in india/singapore right now causing things from southeast asia to europe to be slightly delayed :( 14:52 < BlueMatt> with expected fix times in like....march 14:52 -!- bramc [6b4dd440@gateway/web/freenode/ip.107.77.212.64] has quit [Ping timeout: 260 seconds] 14:58 -!- kenshi84 [~kenshi84@126.179.138.210.rev.vmobile.jp] has quit [Ping timeout: 240 seconds] 14:59 < mmeijeri> on flow control: how much of that do you need when you sporadically blast out relatively small amounts of data vs streaming lots of data for a long time as with bittorrent? 15:00 < mmeijeri> wouldn't reasonable estimation of your e2e bandwidth be enough? 15:00 < BlueMatt> depends on your link 15:00 < BlueMatt> if its gonna take 10ms to blast it? probably doesnt matter much 15:00 < BlueMatt> if its gonna take a second, its probably a big deal 15:00 < BlueMatt> esp given buffbloat issues 15:00 < BlueMatt> hence why i like bram's suggestion of using groups 15:00 < mmeijeri> I'm glad we have a bunch of network experts on board 15:01 < BlueMatt> sidesteps the issue somewhat 15:01 < BlueMatt> (because you can limit the groups to relatively small amounts of data - ie many groups) 15:01 < mmeijeri> you, bram, rusty, teitelbaum 15:01 < BlueMatt> and then its always 10ms 15:02 < BlueMatt> as if anyone has time to build this :P 15:02 < BlueMatt> does sound like fun, but man...annoying as fuck to build 15:05 < mmeijeri> if we do it incrementally we could start by reusing something that already exists like quic or more likely dccp 15:06 < mmeijeri> and then later replace it with something that's optimised for our application 15:06 -!- kenshi84 [~kenshi84@134.64.239.49.rev.vmobile.jp] has joined #bitcoin-wizards 15:11 -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has quit [Quit: WeeChat 1.6] 15:13 -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has joined #bitcoin-wizards 15:19 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 15:21 -!- dkings [~dkings@81.193.44.230] has quit [] 15:23 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 258 seconds] 15:35 -!- kenshi84 [~kenshi84@134.64.239.49.rev.vmobile.jp] has quit [Read error: Connection reset by peer] 15:38 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 15:43 -!- ptrx [~ptrx@80-121-134-161.adsl.highway.telekom.at] has joined #bitcoin-wizards 15:43 -!- Davasny [~quassel@78.10.231.191] has quit [Remote host closed the connection] 15:44 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 252 seconds] 15:44 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 15:50 < BlueMatt> mmeijeri: yea, I mean really I think getting an audit (or even some basic fuzzing on the receive-end) is the first step 15:50 < BlueMatt> problem is you're not gonna get a standard audit firm that will do an audit of this 15:50 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 255 seconds] 15:50 < BlueMatt> too much dense linear algebra even for me to audit 15:50 < mmeijeri> audit for remote exploits you mean? 15:50 < BlueMatt> yea 15:51 < BlueMatt> I'm rather afraid of exposing the fibre ports publicly right now because I'm sure you could find at least some assert crashes 15:51 < BlueMatt> even if not anything rce-ish 15:51 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 15:51 < mmeijeri> why would we need it for the p2p layer and not for fibre? or rather, why doesn't fibre need it? 15:51 < BlueMatt> certainly wh256 is wayyy better built than the previous stuff i had been using 15:51 < BlueMatt> because the very first thing it does when receiving a packet is checks the hmac on it 15:52 < BlueMatt> and I'm pretty confident at least that much is fine 15:52 < BlueMatt> so as long as they dont steal your symmetric hmac keys and you trust the other side to not pwn you its probably fine 15:52 < mmeijeri> for trusted mode only? 15:53 < BlueMatt> hmm? no, like I wouldnt be surprised if you found some crashes in sending certain malformed packets 15:53 < BlueMatt> or in bad order 15:53 < BlueMatt> like its a big pile of networking code that is entirely unreviewed 15:53 < mmeijeri> right 15:53 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds] 15:53 < BlueMatt> its super stable in regular use, but that doesnt mean much if you want to expose it to the internet.... 15:54 -!- blackwraith [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 15:55 < mmeijeri> is the audit the main reason you think implementing this in Core will be a lot of work? 15:55 -!- blackwraith [~priidu@unaffiliated/priidu] has quit [Read error: Connection reset by peer] 15:55 < BlueMatt> yes 15:55 < mmeijeri> ok 15:55 < BlueMatt> i mean the way its written it could pretty much be merged tomorrow, i think....except that no one in their right mind would review it 15:55 < BlueMatt> or think they had sufficiently reviewed it to merge 15:56 < BlueMatt> (of course using it p2p would be more work, but at least the private network stuff is cool on its own) 15:57 -!- blackwraith [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards 15:58 < mmeijeri> and is the fec code the part that would take the most time to audit? 15:58 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...] 15:58 < mmeijeri> that would surprise me a bit 15:58 < mmeijeri> after all, we would be auditing it for exploits, not correctness 15:59 < BlueMatt> probably, though the actual logic is also quite a bear...1500 lines of pure conditional checks and message formatting logic 15:59 < BlueMatt> and of course getting any part of it wrong and youre sending garbage uninitialized memory on the wire 15:59 < mmeijeri> I think I'll have a look at it 15:59 < mmeijeri> I'm wondering if it needs to be refactored first 16:00 < mmeijeri> would be a nice little side project 16:00 < BlueMatt> naa, the wirehair stuff is super well optimized - its written to be fast and smart about memory usage, not neccessarily perfect against people giving it garbage data, I think 16:00 < mmeijeri> though I need to need to start making some money soon... 16:00 < mmeijeri> ah ok 16:00 < BlueMatt> but the guy who wrote it seems to be a pretty competent engineer, so I wouldnt be surprised if there werent any major issues 16:00 < BlueMatt> heh, what, bitcoin holdings arent enough to live on? :p 16:01 < BlueMatt> https://github.com/bitcoinfibre/bitcoinfibre/blob/master/src/udpnet.cpp <-- the vast majority of the meat is here 16:01 < mmeijeri> not selling anything until it's enough to make a dent in my mortgage... 16:01 < BlueMatt> heh 16:02 < mmeijeri> does it have unit tests? 16:02 < BlueMatt> https://github.com/bitcoinfibre/bitcoinfibre/blob/master/src/udpnet.cpp#L690 is the "main" function 16:02 < BlueMatt> no lol 16:02 < BlueMatt> it has production tests 16:02 < BlueMatt> :p 16:02 < mmeijeri> heh 16:02 < BlueMatt> if it crashes in production i fix it 16:03 < BlueMatt> i think there actually may be some constants which are too small for segwit blocks now that i look at this 16:03 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards 16:03 < BlueMatt> oh well, ive got a while to fix that yet 16:05 < BlueMatt> oh shit, dont review that branch 16:05 < BlueMatt> review beta-0.14 16:05 < BlueMatt> or matts-servers, same thing, pretty much 16:05 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 16:05 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 16:05 < BlueMatt> if (msg.msg.block.obj_length > 2000000) { 16:05 < BlueMatt> yea, thats wrong 16:06 < BlueMatt> oh well 16:06 < petertodd> amiller: proofs-of-proofs-of-work is an interactive proof; has anyone made any progress on a non-interactive version? 16:07 < BlueMatt> petertodd: like the header-tree-compression stuff? 16:08 < petertodd> BlueMatt: http://fc16.ifca.ai/bitcoin/papers/KLS16.pdf 16:08 < petertodd> BlueMatt: uh, I think so 16:08 < petertodd> BlueMatt: my understanding was there's a variance exploit with previous attempts at this stuff 16:09 < BlueMatt> previous attempts included a "compressed section" as well as an uncompressed section on top to address that (at least slightly), yes 16:09 < petertodd> BlueMatt: right 16:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards 16:12 < BlueMatt> somehow i remembered the numbers on doing that being more than sufficient, but i may be wrong 16:15 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] 16:18 < uiuc-slack1> petertodd: i and a couple others are working on that, its not too hard 16:18 < petertodd> amiller: good to hear 16:18 < petertodd> amiller: eta? 16:19 < uiuc-slack1> three weeks? 16:19 < uiuc-slack1> ive learend my lesson, two weeks isn't prudent, so 3 seems reasonable 16:19 < BlueMatt> lol 16:19 < petertodd> amiller: heh, looking forward to it then! 16:19 < mmeijeri> @bluematt: would putting the wirehair stuff into a separate process help? 16:19 < uiuc-slack1> what is wirehair? 16:19 < BlueMatt> amiller: the fec used in fibre 16:19 < uiuc-slack1> ah, neat 16:20 < BlueMatt> its actually super impressive...if you ever need a fec for something, I'd highly recommend it instead of all of the other random garbage floating around 16:20 < BlueMatt> mmeijeri: i suppose that would alleviate some concerns, yes? 16:21 < BlueMatt> specifically the wh256 variant 16:21 < mmeijeri> might help with scaling too, if that's an issue 16:21 < BlueMatt> you mean to be able to freely thread it? 16:21 < mmeijeri> yeah, possibly using docker swarm 16:22 < BlueMatt> you'd probably blow too much time streaming the data back and forth between instances, I'd think 16:22 < mmeijeri> all inside a data center though 16:22 < BlueMatt> and i dont think its super scalable, but would have to go dig 16:22 < BlueMatt> so if you're in trusted mode i dont think it'll help much 16:23 < mmeijeri> but then you'd lose the advantage of joint reconstruction, so it's probably not a good idea 16:23 < BlueMatt> i mean...the single-threaded performance of the thing is like a few ms to encode/decode...dont think its a big deal 16:23 < mmeijeri> right 16:23 < BlueMatt> might help if you're doing multi-untrusted-peer reconstruction 16:23 < mmeijeri> let's not prematurely optimise it then! 16:23 < BlueMatt> because those use different fec instances 16:23 < mmeijeri> of course it has been enormously optimised already 16:24 < BlueMatt> yea, all this stuff is pretty heavily tuned already, im not too worried about it 16:25 < BlueMatt> i would have to go revisit if we're talking about 10MB blocks, but for what its targeted at its pretty good 16:27 -!- kenshi84 [~kenshi84@103.5.140.189] has joined #bitcoin-wizards 16:29 -!- rusty2 is now known as rusty 16:30 < BlueMatt> rusty: did you ever go back and sync up with greg about mempool sync using iblts? 16:30 < BlueMatt> (or the tradeoffs between iblt and other encoding schemes for that) 16:31 -!- blackwraith [~priidu@unaffiliated/priidu] has quit [Ping timeout: 260 seconds] 16:33 < rusty> BlueMatt: no... I guess there are two reasons for mempool sync, one is to save inv bandwidth, and second is to use that knowledge of others' mempool state for more aggressive block compression. But there's enough hair involved in any scheme (how often do you send, how do you handle privacy issues with new txs, etc) that it's more than I'm prepared to chew right now. 16:34 < BlueMatt> I'm not convinced about the second option, but there is a better second option: to improve privacy by relaying transactions slower 16:35 < BlueMatt> ie if you're only relaying transactions once per minute to your peers, they're all bucketed 16:35 < BlueMatt> and its harder to do transaction-origin attacks 16:35 < BlueMatt> of course this assumes we dont want to get rid of the mempool command and associated expose-your-mempool attacks 16:35 < BlueMatt> though I think policy has generally be to not fix such issues, because too hard 16:36 < BlueMatt> (such issues being fingerprinting that two nodes, connected to over different networks, are actually the same node) 16:41 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] 16:42 -!- bildramer1 is now known as bildramer 16:45 < rusty> BlueMatt: yeah, you need to share state if you want to close down those last few missing txs without a RTT. It's unclear if we need that in the short term though. 16:46 < BlueMatt> agreed 16:46 < BlueMatt> and think likely not 16:46 < BlueMatt> esp if we use double-spends in compact block reconstruction 16:47 < rusty> ? 16:47 < BlueMatt> eg txn that dont make it into our mempool because we saw a conflicting one first 16:47 < BlueMatt> remember some limited number of them 16:47 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-pcadvggjguxiiakl] has quit [Quit: Connection closed for inactivity] 16:47 < BlueMatt> and use for compact block reconstruction 16:48 < BlueMatt> attacker always wins, obviously, but not a huge deal 16:48 -!- AnHry [~x@a94-132-78-87.cpe.netcabo.pt] has joined #bitcoin-wizards 16:48 < BlueMatt> i mean you can also use a fibre-like encoding over tcp 16:48 < BlueMatt> or just fibre's encoding 16:48 < rusty> BlueMatt: yeah, with RBF that may become a thing. Though in practice, perhaps not, since that will mainly be used for things unlikely to get into a block. 16:48 < BlueMatt> send limited amount of fec along with block to recover top 10k of missing txn or so 16:49 < BlueMatt> rusty: well rbf should, in theory, converge across the network 16:49 < BlueMatt> but, yea, have to remember limited number of rbf txn as well 16:49 < rusty> BlueMatt: yeah, but miners tend to lag creating new blocktemplates AFAICT, so may happen more than naively expected? 16:50 < BlueMatt> well many miners are giving up $$$$ to avoid running rbf 16:50 < BlueMatt> plus, yes, there is lots of lag there 16:50 < rusty> Anyway, we can always beat any scheme with more direct knowledge of mempools, by knowing missing txs. Of course, once we're under a handful of packets it's theoretical. 16:51 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has joined #bitcoin-wizards 16:51 < BlueMatt> I'd prefer to send 10kb of fibre fec over keeping knowledge.... 16:54 < BlueMatt> i mean if you end up needing much more than that the numebr of tcp rtts is gonna be nontrivial, so doing a protocol-level rtt shouldnt matter much 17:02 < rusty> BlueMatt: with fees a thing now, I think we'll see more "like I expected" blocks, so the problem becomes easier. Some heuristics as to how much FEC data to send may end up being Good Enough (eg. get aggressive if block is exactly what I expected). 17:03 < BlueMatt> yea 17:30 -!- AlineGomes [uid198215@gateway/web/irccloud.com/x-tbbpjpnsyvpivqkz] has joined #bitcoin-wizards 17:36 -!- ptrx [~ptrx@80-121-134-161.adsl.highway.telekom.at] has quit [Ping timeout: 260 seconds] 17:44 < mmeijeri> why are miners avoiding running rbf? 17:44 * mryandao is curious too 17:50 -!- propumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-wizards 17:53 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Ping timeout: 256 seconds] 17:56 -!- bramc [634b58ce@gateway/web/freenode/ip.99.75.88.206] has joined #bitcoin-wizards 17:56 < bramc> Looking at my code coverage is a bit depressing. Days of debugging and I'm still staring at a sea of red 17:57 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Read error: Connection reset by peer] 17:57 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards 18:07 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 18:09 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards 18:12 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds] 18:29 -!- bramc [634b58ce@gateway/web/freenode/ip.99.75.88.206] has quit [Ping timeout: 260 seconds] 18:48 -!- mmeijeri [3efb099d@gateway/web/freenode/ip.62.251.9.157] has quit [Quit: Page closed] 18:59 -!- pro [~pro@unaffiliated/pro] has quit [Read error: Connection reset by peer] 19:00 -!- pro [~pro@unaffiliated/pro] has joined #bitcoin-wizards 19:08 -!- AnHry [~x@a94-132-78-87.cpe.netcabo.pt] has quit [Quit: Konversation terminated!] 19:12 -!- uiuc-slack1 [~uiuc-slac@li175-104.members.linode.com] has quit [Remote host closed the connection] 19:12 -!- uiuc-slack [~uiuc-slac@li175-104.members.linode.com] has joined #bitcoin-wizards 19:21 -!- cyphase [~cyphase@unaffiliated/cyphase] has quit [Ping timeout: 258 seconds] 19:24 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 19:26 -!- cyphase [~cyphase@unaffiliated/cyphase] has joined #bitcoin-wizards 19:32 < gmaxwell> BlueMatt: I'm of the opinion that iblt is not that interesting because the constant factor overheads are considerable. 19:32 < gmaxwell> And at least on the numbers I was modling for mempool sync, wiped out a lot of the potential gains. 19:32 < gmaxwell> (also we don't care if it's super cpu fast.) 19:41 -!- JayDugger [~jwdugger@47.185.237.246] has joined #bitcoin-wizards 20:03 < bitcoin-wizards8> to gmaxwell - how do you c bitcoin change in the next 2 years? 20:04 < bitcoin-wizards8> wil there be new functions ? 20:04 -!- JayDugger [~jwdugger@47.185.237.246] has quit [Quit: Leaving.] 20:05 < bitcoin-wizards8> What is the developers vision ? 20:05 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-wizards 20:09 -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving] 20:13 -!- pro [~pro@unaffiliated/pro] has quit [Quit: Leaving] 20:27 -!- bitcoin-wizards8 [bcbc1c8d@gateway/web/freenode/ip.188.188.28.141] has quit [Ping timeout: 260 seconds] 20:31 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 20:48 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-wizards 21:00 -!- legogris [~legogris@128.199.205.238] has quit [Remote host closed the connection] 21:01 -!- legogris [~legogris@128.199.205.238] has joined #bitcoin-wizards 21:12 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:4dac:381:ac6c:df94] has quit [Ping timeout: 255 seconds] 21:13 -!- NewLiberty_ [~NewLibert@2602:306:b8e0:8160:4dac:381:ac6c:df94] has joined #bitcoin-wizards 21:17 -!- NewLiberty_ [~NewLibert@2602:306:b8e0:8160:4dac:381:ac6c:df94] has quit [Ping timeout: 256 seconds] 21:21 < fluffypony> wut 21:22 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 240 seconds] 21:23 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards 22:03 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-wizards 22:05 -!- propumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Ping timeout: 248 seconds] 23:01 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-biqbxepyceufmjcf] has joined #bitcoin-wizards 23:05 -!- Fibonacci [uid136497@gateway/web/irccloud.com/x-tpopxrjoylgnvwal] has joined #bitcoin-wizards 23:07 < Fibonacci> I have an idea to improve forks in crypto 23:08 < Fibonacci> Rather than simply a double which can be disruptive to a coins ecosystem so to speak 23:08 < Fibonacci> Use a more optimal ratio 23:08 < Fibonacci> Namely the Golden ratio 23:11 < Fibonacci> This mimics natural growth and could be a much more fluid way to achieve a more equitable trading value for coins that require inflationary methods 23:11 < Fibonacci> 1.61803398875 23:12 < Fibonacci> I call it a Fibonacci Fork 23:13 < Fibonacci> Because the Golden ratio can be approximated as you add and divide the numbers of the Fibonacci sequence 23:14 < Fibonacci> For coins containing 21m coins this works quite nicely because it happens to be a Fibonacci number 23:15 < Fibonacci> So inflation to the next number of coins at the golden ratio falls to another fibonacci number 34. Adding the zeros still keeps the ratio harmonious. 23:17 < Fibonacci> This natural growth progression is optimal for many reasons and a dramatic improvement on traditional halving methods.u 23:21 < Fibonacci> I propose we implement this method on a project and see if there are advantages that can be gleaned and perhaps even implementation can be further progressive in other financial arenas. 23:24 < Fibonacci> Coins or stocks without a fibonacci number of units can simply be forked or split at the golden ratio 1.61803398875 23:25 < Fibonacci> Thanks for considering my concept for improving this important aspect of global trade 23:25 < Fibonacci> JordanBockart@gmail.com for feedback 23:25 < Fibonacci> Best regards 23:30 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-wizards 23:57 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam] --- Log closed Tue Jan 17 00:00:07 2017