--- Log opened Sun Jun 18 00:00:25 2017
00:07 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has quit [Remote host closed the connection]
00:15 -!- oleganza [~oleganza@c-73-170-224-149.hsd1.ca.comcast.net] has quit [Quit: oleganza]
01:04 -!- matozoid [~textual@197.226.60.197] has joined #bitcoin-wizards
01:07 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has joined #bitcoin-wizards
01:11 < sipa> bedeho: you can observe more than the top elements on the stack
01:12 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has quit [Ping timeout: 255 seconds]
01:23 -!- matozoid [~textual@197.226.60.197] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...]
01:30 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
01:33 -!- prime [~quassel@ip-178-203-235-79.hsi10.unitymediagroup.de] has joined #bitcoin-wizards
01:34 -!- prime is now known as Guest67587
01:55 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has joined #bitcoin-wizards
02:01 -!- Guest67587 [~quassel@ip-178-203-235-79.hsi10.unitymediagroup.de] has quit [Read error: Connection reset by peer]
02:02 -!- prime_ [~quassel@ip-178-203-235-79.hsi10.unitymediagroup.de] has joined #bitcoin-wizards
02:06 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds]
02:11 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has quit [Remote host closed the connection]
02:13 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has joined #bitcoin-wizards
02:13 -!- prime [~quassel@5.146.5.174] has joined #bitcoin-wizards
02:13 -!- prime is now known as Guest10568
02:16 -!- prime_ [~quassel@ip-178-203-235-79.hsi10.unitymediagroup.de] has quit [Ping timeout: 240 seconds]
02:18 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has quit [Ping timeout: 255 seconds]
02:18 -!- prime_ [~quassel@5.146.5.174] has joined #bitcoin-wizards
02:20 -!- thrmo [~thrmo@unaffiliated/thrmo] has joined #bitcoin-wizards
02:20 -!- Guest10568 [~quassel@5.146.5.174] has quit [Ping timeout: 240 seconds]
02:21 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
02:25 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has quit [Ping timeout: 246 seconds]
02:32 -!- kenshi84 [~kenshi84@2400:4027:2bd5:1200:69ce:75e9:85b4:9450] has quit [Read error: Connection reset by peer]
02:36 -!- kenshi84 [~kenshi84@2400:4027:2bd5:1200:b125:18cd:5942:e321] has joined #bitcoin-wizards
02:46 -!- blackwraith [~priidu@unaffiliated/priidu] has quit [Ping timeout: 240 seconds]
02:51 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has quit [Remote host closed the connection]
02:52 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has joined #bitcoin-wizards
03:32 -!- pro [~pro@unaffiliated/pro] has joined #bitcoin-wizards
03:36 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has quit [Remote host closed the connection]
03:37 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has joined #bitcoin-wizards
03:56 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has joined #bitcoin-wizards
03:58 -!- deusexbeer [~deusexbee@093-092-179-139-dynamic-pool-adsl.wbt.ru] has joined #bitcoin-wizards
04:06 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has quit [Remote host closed the connection]
04:11 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-szklfiwcpqphkswx] has joined #bitcoin-wizards
04:13 -!- MaxSan [~one@185.156.175.43] has joined #bitcoin-wizards
04:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
04:27 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 246 seconds]
04:29 -!- Alina-malina [~Alina-mal@37.157.223.80] has joined #bitcoin-wizards
04:37 -!- Alina-malina [~Alina-mal@37.157.223.80] has quit [Ping timeout: 240 seconds]
04:39 -!- Alina-malina [~Alina-mal@37.157.223.80] has joined #bitcoin-wizards
04:41 -!- UnrealLife [~UnrealLif@2001:16a2:4ab:8e00:7544:2b84:2bf3:1e63] has joined #bitcoin-wizards
04:45 -!- Alina-malina [~Alina-mal@37.157.223.80] has quit [Changing host]
04:45 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-wizards
04:46 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has joined #bitcoin-wizards
05:01 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has quit [Remote host closed the connection]
05:02 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has joined #bitcoin-wizards
05:09 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]
05:10 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-wizards
05:34 < stevenroose> Wait. Reading Jimmy Song about UASF
05:34 < stevenroose> BIP9 deployment times
05:34 < stevenroose> Are they blocknumber based or time-based?
05:34 < stevenroose> This is due to the fact that Segwit activation requires 95% of the blocks to signal in a 2 week network difficulty adjustment period before November 15. However, since the Users have <13% of the hash rate, a single network difficulty adjustment period will take >15 weeks. August 1 to November 15 is about 15 weeks, putting activation of Segwit (BIP141) on the Users' fork in doubt.
05:34 < stevenroose> I thought they were blocknumber based and the times are just indicative with a block number specified in the BIP
05:34 < stevenroose> (just like the retarget window)
05:41 < stevenroose> BIP 9 is weird
05:41 < stevenroose> start time and timeout are median time past based
05:42 < stevenroose> but the activation windows are retarget window-based which are block numbers regardless of block creation rate
05:42 < stevenroose> Was this considered when BIP 9 was designed?
05:45 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has quit [Remote host closed the connection]
05:59 < stevenroose> Lombrozo: "It is unlikely BIP9 will be ever used again." hehe, I hope not all future consensus changes will be contentious ..
06:04 < aj> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011022.html has a mention of heights versus timestamps
06:16 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
06:26 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]
06:31 -!- bedeho [~bedeho@138.62.237.156] has joined #bitcoin-wizards
06:31 -!- espes__ [~espes@205.185.120.132] has quit [Ping timeout: 246 seconds]
06:35 -!- espes__ [~espes@205.185.120.132] has joined #bitcoin-wizards
06:41 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
06:42 -!- bedeho [~bedeho@138.62.237.156] has quit [Remote host closed the connection]
06:42 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
06:50 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]
06:51 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
06:55 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]
06:56 -!- UnrealLife [~UnrealLif@2001:16a2:4ab:8e00:7544:2b84:2bf3:1e63] has quit [Quit: Leaving]
07:03 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
07:04 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
07:07 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Client Quit]
07:08 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Remote host closed the connection]
07:08 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
07:12 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
07:21 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Remote host closed the connection]
07:47 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has joined #bitcoin-wizards
07:56 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has quit [Quit: Three sheets to the wind]
07:57 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has joined #bitcoin-wizards
08:00 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
08:06 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Ping timeout: 240 seconds]
08:11 -!- mn3monic [~xxwa@unaffiliated/mn3monic] has joined #bitcoin-wizards
08:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
08:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
08:48 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
08:54 < kanzure> homomorphic hashes http://blog.notdot.net/2012/08/Damn-Cool-Algorithms-Homomorphic-Hashing
08:55 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
08:59 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Ping timeout: 240 seconds]
09:16 < stevenroose> aj thanks
09:16 < stevenroose> "Easier for code, but harder for BIP authors." not much of a mention, however
09:25 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-wizards
09:43 < sipa> stevenroose: yes
09:43 < sipa> stevenroose: i don't think that's a problem
09:44 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
09:44 -!- bedeho_ [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
09:45 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Remote host closed the connection]
09:49 < kanzure> https://people.csail.mit.edu/rivest/lcs35-puzzle-description.txt
09:50 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
09:51 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-wizards
09:54 -!- matozoid [~textual@197.226.60.197] has joined #bitcoin-wizards
09:54 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Read error: Connection reset by peer]
10:01 -!- matozoid [~textual@197.226.60.197] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...]
10:03 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
10:03 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
10:04 -!- matozoid [~textual@197.226.60.197] has joined #bitcoin-wizards
10:15 -!- matozoid [~textual@197.226.60.197] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...]
10:26 -!- bedeho_ [~bedeho@91.90-149-204.nextgentel.com] has quit [Remote host closed the connection]
10:28 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
10:47 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 268 seconds]
10:59 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
10:59 -!- prime [~quassel@ip-178-203-232-135.hsi10.unitymediagroup.de] has joined #bitcoin-wizards
10:59 -!- prime is now known as Guest47553
11:00 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
11:02 -!- prime_ [~quassel@5.146.5.174] has quit [Ping timeout: 258 seconds]
11:14 -!- prime_ [~quassel@5.146.5.174] has joined #bitcoin-wizards
11:17 -!- Guest47553 [~quassel@ip-178-203-232-135.hsi10.unitymediagroup.de] has quit [Ping timeout: 240 seconds]
11:31 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
11:53 -!- prime_ [~quassel@5.146.5.174] has quit [Remote host closed the connection]
12:27 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Remote host closed the connection]
12:42 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds]
12:43 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-wizards
12:50 -!- onabreak [55e4c13c@gateway/web/freenode/ip.85.228.193.60] has quit [Ping timeout: 260 seconds]
12:51 -!- pedrovian [~pedrovian@8.27.210.16] has quit [Quit: Leaving]
12:54 -!- onabreak [55e4c13c@gateway/web/freenode/ip.85.228.193.60] has joined #bitcoin-wizards
12:56 -!- pedrovian [~pedrovian@8.27.210.16] has joined #bitcoin-wizards
13:14 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
13:18 -!- bitbit [~ermm@bzq-79-183-12-31.red.bezeqint.net] has joined #bitcoin-wizards
13:33 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Remote host closed the connection]
13:34 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
13:35 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 268 seconds]
13:36 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-wizards
13:38 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-wizards
14:01 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 268 seconds]
14:07 < runeks> If we turn off signature verification, by how much is the duration of full verification reduced? A factor of ten, a hundred, more?
14:10 < runeks> I'm trying to get a sense of how much time could be saved, for full verification, if signature verification was offloaded to dedicated hardware.
14:14 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
14:26 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
14:29 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
14:30 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
14:31 < sipa> runeks: much less than 10
14:32 < sipa> though it depends on the hardware, and is sort of implementation specific
14:32 < sipa> signature validation is done in parallel over all your cores
14:32 < sipa> also, in steady state (after IBD), signatures are normally cached already
14:33 < sipa> as the transactions were usually seen before the block
14:35 < runeks> sips: I assume signature verification is the most time-consuming part, what are number two and three? Hashing? Script execution?
14:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
14:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
14:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
14:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
14:41 < sipa> runeks: utxo database management
14:43 < sipa> looking up the outputs being spent
14:57 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Remote host closed the connection]
15:04 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Ping timeout: 255 seconds]
15:18 -!- GAit [~GAit@unaffiliated/gait] has quit [Ping timeout: 240 seconds]
15:19 -!- mn3monic [~xxwa@unaffiliated/mn3monic] has quit [Ping timeout: 260 seconds]
15:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
15:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
15:50 -!- cluckj [~cluckj@static-98-114-202-142.phlapa.ftas.verizon.net] has quit [Ping timeout: 240 seconds]
16:03 -!- rmwb [~rmwb@129.180.75.159] has joined #bitcoin-wizards
16:06 -!- GAit [~GAit@unaffiliated/gait] has joined #bitcoin-wizards
16:13 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 246 seconds]
16:19 -!- cluckj [~cluckj@static-98-114-202-142.phlapa.ftas.verizon.net] has joined #bitcoin-wizards
16:27 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
16:27 -!- str4d [~str4d@27.110.123.91] has joined #bitcoin-wizards
16:35 -!- goofie_ [~goofie@104-7-174-119.lightspeed.hstntx.sbcglobal.net] has quit [Ping timeout: 240 seconds]
16:39 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
16:41 -!- jtimon [~quassel@S010600179a34a853.gv.shawcable.net] has joined #bitcoin-wizards
16:51 -!- goofie_ [~goofie@104-7-174-119.lightspeed.hstntx.sbcglobal.net] has joined #bitcoin-wizards
16:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
17:07 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Ping timeout: 255 seconds]
17:09 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]
17:25 -!- deusexbeer [~deusexbee@093-092-179-139-dynamic-pool-adsl.wbt.ru] has quit [Quit: Konversation terminated!]
17:42 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 240 seconds]
17:45 -!- jtimon [~quassel@S010600179a34a853.gv.shawcable.net] has quit [Ping timeout: 260 seconds]
17:47 -!- rmwb [~rmwb@129.180.75.159] has quit [Remote host closed the connection]
17:52 -!- rmwb [~rmwb@2001:df0:ce:1601:d90d:37a6:f9ec:5f24] has joined #bitcoin-wizards
17:57 -!- jtimon [~quassel@S010600179a34a853.gv.shawcable.net] has joined #bitcoin-wizards
18:07 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-wizards
18:22 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds]
18:23 -!- itsme [~textual@85.203.22.18] has joined #bitcoin-wizards
18:24 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]
18:27 -!- jtimon [~quassel@S010600179a34a853.gv.shawcable.net] has quit [Remote host closed the connection]
18:27 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
18:27 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has joined #bitcoin-wizards
18:37 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
18:37 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 268 seconds]
18:38 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-wizards
18:39 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has quit [Quit: mining]
18:41 -!- itsme [~textual@85.203.22.18] has quit [Quit: Textual IRC Client: www.textualapp.com]
18:54 -!- Samchun [~Samchun@static-176-158-43-15.ftth.abo.bbox.fr] has joined #bitcoin-wizards
19:00 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-szklfiwcpqphkswx] has quit [Quit: Connection closed for inactivity]
19:01 -!- thrmo [~thrmo@unaffiliated/thrmo] has quit [Quit: Waiting for .007]
19:01 -!- Samchun [~Samchun@static-176-158-43-15.ftth.abo.bbox.fr] has quit [Quit: Quitte]
19:06 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
19:09 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Client Quit]
19:30 -!- pro [~pro@unaffiliated/pro] has quit [Quit: Leaving]
19:57 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
19:58 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-wizards
20:04 -!- anon616 [anon616@gateway/shell/sameroom/x-yvpubfkncutxjmch] has quit [Remote host closed the connection]
20:07 -!- anon616 [anon616@gateway/shell/sameroom/x-ytpdcgngqpdalbnj] has joined #bitcoin-wizards
20:08 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has joined #bitcoin-wizards
20:09 -!- bedeho [~bedeho@91.90-149-204.nextgentel.com] has quit [Remote host closed the connection]
20:15 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]
20:20 -!- rmwb [~rmwb@2001:df0:ce:1601:d90d:37a6:f9ec:5f24] has quit [Remote host closed the connection]
20:20 -!- str4d [~str4d@27.110.123.91] has quit [Ping timeout: 246 seconds]
20:30 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Read error: Connection reset by peer]
20:32 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]
20:33 -!- PaulCape_ [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #bitcoin-wizards
20:46 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
20:48 -!- deusexbeer [~deusexbee@093-092-179-139-dynamic-pool-adsl.wbt.ru] has joined #bitcoin-wizards
20:50 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has quit [Quit: Three sheets to the wind]
20:51 < kanzure> high-dimensional stochastic gradient descent stuff https://cbmm.mit.edu/sites/default/files/publications/CBMM-Memo-067.pdf
21:00 -!- legogris [~legogris@128.199.205.238] has quit [Remote host closed the connection]
21:00 -!- legogris [~legogris@128.199.205.238] has joined #bitcoin-wizards
21:01 -!- coinsmurf [~packet@96-66-250-198-static.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds]
21:02 -!- MaxSan [~one@185.156.175.43] has quit [Quit: Leaving.]
21:06 -!- rmwb [~rmwb@129.180.75.159] has joined #bitcoin-wizards
21:10 -!- coinsmurf [~packet@96-66-250-198-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards
21:25 -!- DigiByteDev [~JT2@69.167.34.48] has joined #bitcoin-wizards
21:26 -!- coinsmurf [~packet@96-66-250-198-static.hfc.comcastbusiness.net] has quit [Ping timeout: 268 seconds]
21:31 -!- mn3monic [~xxwa@host240-89-dynamic.56-82-r.retail.telecomitalia.it] has joined #bitcoin-wizards
21:31 -!- mn3monic [~xxwa@host240-89-dynamic.56-82-r.retail.telecomitalia.it] has quit [Changing host]
21:31 -!- mn3monic [~xxwa@unaffiliated/mn3monic] has joined #bitcoin-wizards
21:40 -!- bedeho [~bedeho@cm-84.214.5.24.getinternet.no] has joined #bitcoin-wizards
21:45 -!- [7] [~quassel@rockbox/developer/TheSeven] has quit [Disconnected by services]
21:45 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
21:46 -!- DigiByteDev [~JT2@69.167.34.48] has quit [Quit: DigiByteDev]
21:52 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 255 seconds]
21:53 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 248 seconds]
21:53 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-wizards
21:58 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-wizards
22:11 -!- matozoid [~textual@197.226.33.167] has joined #bitcoin-wizards
22:11 -!- mn3monic [~xxwa@unaffiliated/mn3monic] has quit [Excess Flood]
22:11 -!- mn3monic [~xxwa@unaffiliated/mn3monic] has joined #bitcoin-wizards
22:29 < runeks> sipa: that makes sense, since the further we get into a chain, the larger the UTXO set, so I would assume that the lookup/update operations become increasingly expensive. Is this the primary performance bottleneck of UTXO DB management -- that the UTXO set grows, and thus the duration of the operations on it? Or is it just because it's updated sequentially, i.e. one transaction at a time is "folded" into the UTXO set?
22:37 < sipa> larger utxo set = slower operations on it
22:38 < sipa> we heavily cache the active parts of the set in memore, but for optimal speed you need several GB cache already
22:39 < sipa> there are some proposals that remove or reduce the load of utxo management from full nodes
22:39 < sipa> and replace them with wallet generated proofs of unspentness
22:39 < sipa> for example petertodd's txo mmr, or bram cohen's bitfield
22:40 < runeks> I'm wondering if we could gain a speedup in this area if we used a temporary data structure for the UTXO set which allows negative balances, meaning that if an input redeems an output not in the UTXO set, it's added to this temporary UTXO set with a negative balance. Then we chop up the chain in <num_cores> pieces, have each core produce a temporary UTXO set of this nature, and finish off by merging these temporary UTXO
22:40 < runeks> sets, which should end up with all the negative balances being cancelled out by a positive one (or the chain is invalid).
22:43 < sipa> you can't validate a script without looking up the output
22:43 < sipa> but perhaps the whole thing could be delayed
22:43 < runeks> sipa: everything we can't validate right now would be deferred until we merge temporary UTXO sets
22:47 < sipa> that sounds like ot could theoretically give some improvement
22:48 < sipa> but not so much... you can get the same effect by using a db engine that supports multiple asynchronous queries
22:48 < sipa> the idea of removing the concern of utxo sets from full nodes sounds far more appealing to mr
22:48 -!- coinsmurf [~packet@96-66-250-198-static.hfc.comcastbusiness.net] has joined #bitcoin-wizards
22:49 < runeks> I'll have to read up on that
22:49 -!- matozoid [~textual@197.226.33.167] has quit [Ping timeout: 268 seconds]
22:50 < runeks> Would that require a change in the protocol?
22:50 < sipa> yes
22:50 < sipa> proofs need to be sent along with transactions
22:50 < sipa> and blocks
22:51 < runeks> Ok, I see. I guess I'm mostly interested in speed-ups not requiring protocol changes.
22:52 -!- matozoid [~textual@197.226.33.167] has joined #bitcoin-wizards
22:55 < sipa> haha, those are certainly less invasive
22:55 < sipa> but the potential impact is also much smaller
22:56 < sipa> protocol change here btw does not mean consensus change
22:58 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.]
22:59 < runeks> I guess the speedup would depend on how many cores you have available. Although, the temporary UTXO sets, which would need to be merged, would keep increasing in size, until you have a merge operation with roughly two halves of the UTXO set. So here, too, performance degrades as we get closer to a final UTXO set.
23:00 < runeks> So are we walking a change to the P2P protocol only?
23:00 < runeks> *talking
23:00 < sipa> yes
23:00 < sipa> an invasive one, though
23:00 < sipa> and a change to wallet software, eventually
23:01 < runeks> Oh ok. That's much less of a problem.
23:01 < sipa> and they come with big tradeoffs
23:01 -!- str4d [~str4d@27.110.123.91] has joined #bitcoin-wizards
23:01 < sipa> transactions (on P2P) would become significantly bigger
23:05 < runeks> Hmm, I see. That's unfortunate. As far as I can see, the broadcast-all-to-all nature of the P2P network is Bitcoin's primary bottleneck.
23:07 < sipa> bandwidth usage is really not that high
23:07 -!- ryan-c [~ryan@znc.rya.nc] has quit [Quit: quitting]
23:07 < sipa> a non-serving bitcoin full node just needs a few kb/s
23:07 < sipa> (after IBD)
23:08 < runeks> I mean, if 1KB/s of transaction data needs to be spread out between 10,000 nodes, that's 10MB/s for
23:08 < runeks> all nodes cumulatively.
23:08 < sipa> yeah
23:15 -!- rmwb [~rmwb@129.180.75.159] has quit [Remote host closed the connection]
23:20 < runeks> Also, with regards to "you can get the same effect by using a db engine that supports multiple asynchronous queries", as far as I can see, this isn't possible unless each entry in the UTXO set has a monotonically increasing counter (e.g. <32_bit_block_num+32_bit_tx_num_in_block>), such that an output can only cancel out an input if it appears in an earlier tx (an output can only cancel out a negative-balance entry in
23:20 < runeks> the UTXO set if the output's counter is less than that of the negative-balance UTXO entry).
23:20 < sipa> instead of merging the sets, you just issue an asynchronous query in a single set
23:21 < sipa> and continue prcocessing when it comes back
23:21 < sipa> that should be just as fast, with lower latency
23:21 < sipa> the advantage of merging sets is that it's linear in time
23:22 < sipa> but the disadvantage is that most of the time you're not using your hardware at all
23:22 < runeks> sipa: but queries need to be handled in-order, such that only an output that was added earlier can be cancelled out by an input
23:22 < sipa> yes?
23:23 < sipa> the spend only happen after the send
23:23 < runeks> sipa: How can we make sure queries are handled in-order unless each UTXO entry contains a counter?
23:23 < sipa> i don't understand
23:23 < sipa> the blockchai  is the order
23:24 < sipa> spending a utxo before it is created is illegal
23:24 < runeks> Right, but the supposed speedup is from parallelizing UTXO operations. And then we lose the ordering.
23:24 < sipa> do a quick pass for finding utxos spent within the block itself
23:25 < sipa> anything else should also be created by an earlier block
23:25 < sipa> also, parallellizing utxo sets is not that hard
23:26 < sipa> just keep 256 parallel caches based on the first 8 bits of the txid
23:26 < sipa> the likelyhood of needing to modify two of them concurrently is low
23:27 < sipa> even when proxessing on multiple threads
23:27 -!- ryan-c [~ryan@znc.rya.nc] has joined #bitcoin-wizards
23:27  * sipa zzz
23:28 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-bkdoeblohskalhpd] has joined #bitcoin-wizards
23:33 < runeks> You can't modify the UTXO set in parallel unless each entry in it describes when the entry in question appeared in the blockchain.
23:35 < runeks> It's the same with all parallel databases, I believe: each operation needs a counter/timestamp such that only an "update(x) *after* create(x)" works, as opposed to "create(x) after update(x)".
23:40 < runeks> I believe most parallel DBs use a monotonically increasing counter, while a DB like Google Spanner uses an absolute timestamp from an atomic clock which is synchronized between all nodes. For Bitcoin this counter could be a 64 bit word, where the most significant 32 bits is the block count, and least significant 32 bits is tx_number_within_block.
23:40 -!- bitbit [~ermm@bzq-79-183-12-31.red.bezeqint.net] has quit [Ping timeout: 260 seconds]
23:43 < runeks> Using a strategy like this we can, essentially, separate each tx from its containing block, and fold them in parallel into the UTXO set, since the counter (for each tx) now makes sure that only earlier outputs can be redeemed by later inputs, and not the other way around.
23:46 < sipa> well, i'm still talking about a model where you fully process one block before moiving on to the next
23:46 < sipa> and utxos are incredibly easy structures
23:47 < sipa> they're created once, typically looked up once or twice, and deleted
23:47 -!- phayd [~phayd___@fs76eefa8d.tkyc516.ap.nuro.jp] has joined #bitcoin-wizards
23:47 < sipa> there's no sequencing of operations needed apart from making sure the spend hapoens after the creation
23:48 < sipa> the in-memory cache in bitcoin core takes advantage of that: utxos that are created and spent before a disk flush happens are just deleted and never hit disk at all
23:49 -!- thrmo [~thrmo@unaffiliated/thrmo] has joined #bitcoin-wizards
23:49 < sipa> and parallellizing is not hard with parallel caches
23:50 < sipa> just not implememted
23:52 < sipa> oh... you really need to make sure a block is valid as soon as possible in steady state
23:53 < sipa> otherwise you can't processing new mempool txn, which is essential for mini g
23:53 < sipa> in IBD some parallel processing with higher throughput but worse latency may make sense
23:57 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 255 seconds]
23:57 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-wizards
23:59 -!- matozoid_ [~textual@197.226.33.167] has joined #bitcoin-wizards
--- Log closed Mon Jun 19 00:00:26 2017