--- 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> <amiller> 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> <amiller> three weeks?
16:19 < uiuc-slack1> <amiller> 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> <amiller> what is wirehair?
16:19 < BlueMatt> amiller: the fec used in fibre
16:19 < uiuc-slack1> <amiller> 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