--- Log opened Sat Mar 18 00:00:01 2017
00:08 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]
00:34 -!- dodomojo [~goksinen@2604:2000:c591:8400:247e:d5c9:9a52:4321] has quit [Remote host closed the connection]
00:39 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-wizards
00:41 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-otidttnfbnfyaieo] has joined #bitcoin-wizards
00:42 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Remote host closed the connection]
00:54 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has joined #bitcoin-wizards
00:58 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has quit [Ping timeout: 240 seconds]
01:13 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-wizards
01:16 -!- DisasterButton [~PaulSimps@host86-187-175-82.range86-187.btcentralplus.com] has joined #bitcoin-wizards
02:19 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-eoiapfnuwquicnea] has joined #bitcoin-wizards
02:19 -!- stiell [~stian@fsf/member/stiell] has joined #bitcoin-wizards
02:29 -!- stiell [~stian@fsf/member/stiell] has quit [Ping timeout: 261 seconds]
02:47 -!- MtWGA [~whatlol@94.242.252.14] has joined #bitcoin-wizards
02:57 -!- skeuomorf [~skeuomorf@unaffiliated/skeuomorf] has quit [Ping timeout: 258 seconds]
03:00 -!- thrmo_ [~thrmo@unaffiliated/thrmo] has joined #bitcoin-wizards
03:01 -!- thrmo [~thrmo@unaffiliated/thrmo] has quit [Ping timeout: 260 seconds]
03:22 -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has quit [Ping timeout: 256 seconds]
03:24 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:e010:f40e:b2c6:f8cd] has joined #bitcoin-wizards
03:36 -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has joined #bitcoin-wizards
03:37 -!- stiell [~stian@fsf/member/stiell] has joined #bitcoin-wizards
03:37 -!- lmatteis [uid3300@gateway/web/irccloud.com/x-wuoxpziweybfipmr] has joined #bitcoin-wizards
03:40 -!- afk11 [~afk11@176.61.69.103] has quit [Read error: Connection reset by peer]
03:41 -!- MoALTz [~no@77-254-9-16.adsl.inetia.pl] has joined #bitcoin-wizards
03:42 -!- afk11 [~afk11@176.61.69.103] has joined #bitcoin-wizards
03:43 -!- thrmo_ is now known as thrmo
03:55 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has joined #bitcoin-wizards
03:59 -!- stiell [~stian@fsf/member/stiell] has quit [Ping timeout: 246 seconds]
04:00 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has quit [Ping timeout: 260 seconds]
04:08 -!- AaronvanW [~AaronvanW@203.red-83-43-123.dynamicip.rima-tde.net] has joined #bitcoin-wizards
04:08 -!- AaronvanW [~AaronvanW@203.red-83-43-123.dynamicip.rima-tde.net] has quit [Changing host]
04:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
04:15 -!- stiell [~stian@fsf/member/stiell] has joined #bitcoin-wizards
04:20 -!- stiell [~stian@fsf/member/stiell] has quit [Ping timeout: 260 seconds]
04:22 -!- stiell [~stian@fsf/member/stiell] has joined #bitcoin-wizards
04:28 -!- stiell [~stian@fsf/member/stiell] has quit [Ping timeout: 260 seconds]
04:41 -!- DisasterButton [~PaulSimps@host86-187-175-82.range86-187.btcentralplus.com] has quit [Ping timeout: 240 seconds]
04:49 -!- kenshi84 [~kenshi84@2400:7800:48db:9100:69ce:75e9:85b4:9450] has quit [Read error: Connection reset by peer]
04:57 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has quit [Remote host closed the connection]
04:58 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has joined #bitcoin-wizards
05:06 -!- stiell [~stian@fsf/member/stiell] has joined #bitcoin-wizards
05:10 -!- javax [~johan@wyckoff.naqua.se] has joined #bitcoin-wizards
05:18 -!- stiell [~stian@fsf/member/stiell] has quit [Ping timeout: 240 seconds]
05:25 -!- Jeremy_Rand[m] [jeremyrand@gateway/shell/matrix.org/x-xkoonszujtchtkkq] has quit [Remote host closed the connection]
05:25 -!- herzmeister[m] [herzmeiste@gateway/shell/matrix.org/x-eyhmlmjedvtrxgem] has quit [Remote host closed the connection]
05:25 -!- frabrunelle [frabrunell@safenetwork/frabrunelle] has quit [Write error: Connection reset by peer]
05:25 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-qaoczcvfvpcxdgqz] has quit [Remote host closed the connection]
05:25 -!- bjorn[m]1 [bjornwgnrm@gateway/shell/matrix.org/x-lxlulxkswmraoawq] has quit [Read error: Connection reset by peer]
05:29 -!- qpm [~qpm@unaffiliated/midnightmagic/bot/qpm] has quit [Ping timeout: 246 seconds]
05:33 -!- Davasny [~quassel@78.10.231.191] has joined #bitcoin-wizards
05:34 -!- Davasny is now known as Guest64361
05:34 -!- Guest64361 is now known as Dav2
05:34 -!- qpm [~qpm@unaffiliated/midnightmagic/bot/qpm] has joined #bitcoin-wizards
05:43 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
05:43 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
05:44 -!- bjorn[m]1 [bjornwgnrm@gateway/shell/matrix.org/x-gnbegabwgihwpbou] has joined #bitcoin-wizards
05:52 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-yexupwruylwelolv] has joined #bitcoin-wizards
05:52 -!- herzmeister[m] [herzmeiste@gateway/shell/matrix.org/x-zdfzuxhgbgmjojls] has joined #bitcoin-wizards
05:52 -!- Jeremy_Rand[m] [jeremyrand@gateway/shell/matrix.org/x-supgmjrnxqebkjua] has joined #bitcoin-wizards
05:52 -!- frabrunelle [frabrunell@safenetwork/frabrunelle] has joined #bitcoin-wizards
05:57 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has joined #bitcoin-wizards
06:02 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has quit [Ping timeout: 268 seconds]
06:06 -!- pro [~pro@unaffiliated/pro] has joined #bitcoin-wizards
06:11 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-wizards
06:12 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Remote host closed the connection]
06:14 -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards
06:18 -!- kenshi84 [~kenshi84@2400:7800:48db:9100:c968:94f3:7250:a596] has joined #bitcoin-wizards
06:21 -!- JackH [~laptop@79-73-184-8.dynamic.dsl.as9105.com] has joined #bitcoin-wizards
06:22 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has joined #bitcoin-wizards
06:35 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has quit [Remote host closed the connection]
06:38 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has joined #bitcoin-wizards
06:42 -!- TheMagnificentCo [~bewareoft@s204-191-22-141.ab.hsia.telus.net] has joined #bitcoin-wizards
06:45 -!- ComputronTheMagn [~bewareoft@s204-191-22-141.ab.hsia.telus.net] has quit [Ping timeout: 260 seconds]
06:49 -!- bildramer1 is now known as bildramer
06:50 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards
06:57 -!- Pachurter [~Pachurter@unaffiliated/pachurter] has quit [Ping timeout: 264 seconds]
06:58 -!- Pachurter [~Pachurter@unaffiliated/pachurter] has joined #bitcoin-wizards
07:00 -!- thrmo [~thrmo@unaffiliated/thrmo] has quit [Quit: Waiting for .007]
07:02 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
07:03 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-wizards
07:04 -!- thrmo [~thrmo@unaffiliated/thrmo] has joined #bitcoin-wizards
07:07 -!- thrmo_ [~thrmo@unaffiliated/thrmo] has joined #bitcoin-wizards
07:09 -!- thrmo [~thrmo@unaffiliated/thrmo] has quit [Ping timeout: 256 seconds]
07:12 -!- shesek [~shesek@bzq-84-110-232-242.red.bezeqint.net] has joined #bitcoin-wizards
07:20 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
07:31 -!- thrmo_ is now known as thrmo
07:32 -!- vo8co [~vo8co@c-24-4-204-123.hsd1.ca.comcast.net] has joined #bitcoin-wizards
08:15 -!- MtWGA [~whatlol@94.242.252.14] has quit [Quit: MtWGA]
09:04 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
09:09 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Ping timeout: 264 seconds]
09:14 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-wizards
09:14 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Read error: Connection reset by peer]
09:14 -!- dodomojo [~goksinen@2604:2000:c591:8400:91ae:ddf:5894:b6cc] has joined #bitcoin-wizards
09:27 -!- fibonacci [uid136497@gateway/web/irccloud.com/x-adhfctknbmdnfqww] has joined #bitcoin-wizards
09:38 -!- nabu [~jm@192.40.88.10] has joined #bitcoin-wizards
09:38 -!- kankles [~kankles@104.200.154.4] has quit [Ping timeout: 260 seconds]
09:54 -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has quit [Ping timeout: 240 seconds]
09:58 -!- dodomojo [~goksinen@2604:2000:c591:8400:91ae:ddf:5894:b6cc] has quit [Remote host closed the connection]
10:03 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-wizards
10:12 -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has joined #bitcoin-wizards
10:16 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-wizards
10:21 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
10:21 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Remote host closed the connection]
10:23 -!- Noldorin [~noldorin@unaffiliated/noldorin] has joined #bitcoin-wizards
10:27 -!- kankles [~kankles@104.200.154.4] has joined #bitcoin-wizards
10:34 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-wizards
10:34 -!- stiell [~stian@fsf/member/stiell] has joined #bitcoin-wizards
10:36 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-wizards
10:40 -!- Pr0t3us [~Pr0t3us@gateway/vpn/privateinternetaccess/pr0t3us] has joined #bitcoin-wizards
10:42 -!- Pr0t3us [~Pr0t3us@gateway/vpn/privateinternetaccess/pr0t3us] has quit [Remote host closed the connection]
10:44 -!- thrmo [~thrmo@unaffiliated/thrmo] has quit [Killed (sinisalo.freenode.net (Nickname regained by services))]
10:52 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Remote host closed the connection]
10:55 -!- stiell [~stian@fsf/member/stiell] has quit [Ping timeout: 240 seconds]
11:02 -!- dodomojo [~goksinen@2604:2000:c591:8400:841f:cda8:8d82:17cb] has joined #bitcoin-wizards
11:03 -!- dodomojo [~goksinen@2604:2000:c591:8400:841f:cda8:8d82:17cb] has quit [Remote host closed the connection]
11:13 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has left #bitcoin-wizards []
11:13 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has joined #bitcoin-wizards
11:28 -!- ratbanebo [~ratbanebo@ptr-fyxkxbvgqp0kx74u8la.18120a2.ip6.access.telenet.be] has joined #bitcoin-wizards
11:29 -!- stiell [~stian@fsf/member/stiell] has joined #bitcoin-wizards
11:29 -!- dodomojo [~goksinen@2604:2000:c591:8400:f8f4:7b12:d7dc:7433] has joined #bitcoin-wizards
11:35 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards
11:37 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 260 seconds]
12:02 -!- stiell [~stian@fsf/member/stiell] has quit [Ping timeout: 240 seconds]
12:08 -!- itsme [~textual@46.166.164.80] has joined #bitcoin-wizards
12:14 -!- dodomojo [~goksinen@2604:2000:c591:8400:f8f4:7b12:d7dc:7433] has quit [Read error: Connection reset by peer]
12:18 -!- stiell [~stian@fsf/member/stiell] has joined #bitcoin-wizards
12:28 -!- dodomojo [~goksinen@2604:2000:c591:8400:f8f4:7b12:d7dc:7433] has joined #bitcoin-wizards
12:35 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has quit [Remote host closed the connection]
12:38 -!- Belkaar [~Belkaar@unaffiliated/belkaar] has quit [Ping timeout: 240 seconds]
12:39 -!- stiell [~stian@fsf/member/stiell] has quit [Ping timeout: 268 seconds]
12:39 -!- Belkaar [~Belkaar@xdsl-89-0-47-115.netcologne.de] has joined #bitcoin-wizards
12:39 -!- Belkaar [~Belkaar@xdsl-89-0-47-115.netcologne.de] has quit [Changing host]
12:39 -!- Belkaar [~Belkaar@unaffiliated/belkaar] has joined #bitcoin-wizards
12:50 -!- Dav2 is now known as Davasny
12:57 -!- afk11_ [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]
12:57 -!- afk11_ [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-wizards
12:58 -!- afk11 [~afk11@176.61.69.103] has quit [Disconnected by services]
12:58 -!- afk11_ is now known as afk11
13:00 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection]
13:01 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-wizards
13:07 -!- fibonacci [uid136497@gateway/web/irccloud.com/x-adhfctknbmdnfqww] has quit [Quit: Connection closed for inactivity]
13:18 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
13:20 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
13:22 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
13:26 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
13:32 -!- Pachurter [~Pachurter@unaffiliated/pachurter] has quit [Ping timeout: 260 seconds]
13:36 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has joined #bitcoin-wizards
13:37 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds]
13:40 -!- itsme [~textual@46.166.164.80] has quit [Quit: Textual IRC Client: www.textualapp.com]
13:41 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has quit [Ping timeout: 260 seconds]
13:41 -!- Pachurter [~Pachurter@unaffiliated/pachurter] has joined #bitcoin-wizards
13:48 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards
13:49 -!- nabu [~jm@192.40.88.10] has quit [Quit: Konversation terminated!]
13:51 -!- mol is now known as moli
13:57 -!- ratbanebo [~ratbanebo@ptr-fyxkxbvgqp0kx74u8la.18120a2.ip6.access.telenet.be] has quit [Remote host closed the connection]
13:58 -!- ratbanebo [~ratbanebo@ptr-fyxkxbvgqp0kx74u8la.18120a2.ip6.access.telenet.be] has joined #bitcoin-wizards
13:58 -!- lmatteis [uid3300@gateway/web/irccloud.com/x-wuoxpziweybfipmr] has quit [Quit: Connection closed for inactivity]
13:59 -!- Davasny [~quassel@78.10.231.191] has quit [Remote host closed the connection]
14:02 -!- ratbanebo [~ratbanebo@ptr-fyxkxbvgqp0kx74u8la.18120a2.ip6.access.telenet.be] has quit [Ping timeout: 240 seconds]
14:14 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]
14:14 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-wizards
14:32 -!- vo8co [~vo8co@c-24-4-204-123.hsd1.ca.comcast.net] has quit [Remote host closed the connection]
14:38 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye]
14:51 -!- ratbanebo [~ratbanebo@ptr-fyxkxbtmw5veauq771x.18120a2.ip6.access.telenet.be] has joined #bitcoin-wizards
14:57 -!- ratbanebo [~ratbanebo@ptr-fyxkxbtmw5veauq771x.18120a2.ip6.access.telenet.be] has quit [Ping timeout: 264 seconds]
15:07 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has left #bitcoin-wizards ["Closing Window"]
15:34 -!- skeuomorf [~skeuomorf@unaffiliated/skeuomorf] has joined #bitcoin-wizards
15:44 -!- bramc [268265f3@gateway/web/freenode/ip.38.130.101.243] has joined #bitcoin-wizards
15:44 < bramc> So I had this funny idea about keeping the utxo set size under control
15:45 -!- ratbanebo [~ratbanebo@ptr-fyxkxbuqdihqkw73jmu.18120a2.ip6.access.telenet.be] has joined #bitcoin-wizards
15:46 < bramc> The idea is that you impose a cost on adding an entry to the utxo, but then return it when the entry is removed. It's calculated by number of bytes, so adding something to the utxo set costs, say, 100 bytes towards the block size limit. If you remove one you get an extra 100. Most transactions have one input and one output so they cancel out
15:48 < belcher> im not sure about the last point, many many transactions have two outputs (destination and change)
15:48 < belcher> but that doesnt change your argument
15:49 < bramc> The interesting question comes in how you handle cashing old dust - it's a bit of a pain to coordinate with other transactions which should happen. But then I got a crazy idea: How about allowing transactions to have negative miner fees? Then the miner can let the transaction through and collect more fees from other transactions which get allowed in
15:49 -!- mmeijeri [3efb099d@gateway/web/freenode/ip.62.251.9.157] has joined #bitcoin-wizards
15:49 < mmeijeri> @bramc: Ripple does something like that
15:50 -!- ratbanebo [~ratbanebo@ptr-fyxkxbuqdihqkw73jmu.18120a2.ip6.access.telenet.be] has quit [Ping timeout: 240 seconds]
15:50 < bramc> Allowing negative fees seems like a strange idea but makes a lot of sense. There's no particular reason why they couldn't be allowed
15:54 < bramc> A slightly stranger idea: It seems like some of amiller's recent smart transaction stuff runs into problems related to not being able to predict later transaction ids. Why does a transaction need to include its inputs when calculating its id? That might require some salt under some circumstances, but it doesn't seem to have any real security problem, and it makes a lot of smart transactions unambiguously simpler
15:54 < bramc> Both of these are probably not soft-forkable
15:55 < kanzure> SIGHASH_NOINPUT?
15:55 < kanzure> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010759.html
15:57 < kanzure> as for soft-forkability there's some tricks you can do with anyonecanspend
15:57 < bramc> kanzure Also there should be a sighash type which signs one input and all the outputs, but that doesn't fix the txid problem
16:01 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection]
16:01 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-wizards
16:02 < bramc> Or maybe the smart contracts can by having the signatures still be valid despite the input txid changing, thus pushing the problem back a level
16:02 < bramc> I'll need to understand the contracts better before having an opinion on that.
16:03 < bramc> checking none of the inputs seems dodgier than verifying just the one input, but maybe it's fine
16:14 -!- mmeijeri [3efb099d@gateway/web/freenode/ip.62.251.9.157] has quit [Quit: Page closed]
16:19 -!- fibonacci [uid136497@gateway/web/irccloud.com/x-pxgvupfymikhkrem] has joined #bitcoin-wizards
16:37 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has joined #bitcoin-wizards
16:39 -!- ratbanebo [~ratbanebo@ptr-fyxkxbtpg79g8ril52w.18120a2.ip6.access.telenet.be] has joined #bitcoin-wizards
16:42 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has quit [Ping timeout: 264 seconds]
16:44 -!- ratbanebo [~ratbanebo@ptr-fyxkxbtpg79g8ril52w.18120a2.ip6.access.telenet.be] has quit [Ping timeout: 264 seconds]
16:58 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection]
16:59 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-wizards
17:15 -!- bramc [268265f3@gateway/web/freenode/ip.38.130.101.243] has quit [Ping timeout: 260 seconds]
17:21 < amiller> i'd assume pretty much anything is possible once you start with anyone-can-spend
17:22 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Quit: Leaving]
17:23 < kanzure> great
17:26 -!- MoALTz [~no@77-254-9-16.adsl.inetia.pl] has quit [Quit: Leaving]
17:28 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
17:28 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Remote host closed the connection]
17:34 -!- ratbanebo [~ratbanebo@ptr-fyxkxbtpg79g8ril52w.18120a2.ip6.access.telenet.be] has joined #bitcoin-wizards
17:38 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has joined #bitcoin-wizards
17:38 -!- ratbanebo [~ratbanebo@ptr-fyxkxbtpg79g8ril52w.18120a2.ip6.access.telenet.be] has quit [Ping timeout: 264 seconds]
17:48 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
18:27 -!- fibonacci [uid136497@gateway/web/irccloud.com/x-pxgvupfymikhkrem] has quit [Quit: Connection closed for inactivity]
18:31 -!- oleganza [~oleganza@c-73-170-224-149.hsd1.ca.comcast.net] has joined #bitcoin-wizards
18:32 -!- vo8co [~vo8co@c-24-4-204-123.hsd1.ca.comcast.net] has joined #bitcoin-wizards
18:35 -!- kenshi84_ [~kenshi84@2400:7800:48db:9100:c968:94f3:7250:a596] has joined #bitcoin-wizards
18:37 -!- kenshi84 [~kenshi84@2400:7800:48db:9100:c968:94f3:7250:a596] has quit [Ping timeout: 256 seconds]
18:50 -!- oleganza [~oleganza@c-73-170-224-149.hsd1.ca.comcast.net] has quit [Quit: oleganza]
19:22 -!- ratbanebo [~ratbanebo@ptr-fyxkxbtpg79g8ril52w.18120a2.ip6.access.telenet.be] has joined #bitcoin-wizards
19:23 -!- bramc [268265f3@gateway/web/freenode/ip.38.130.101.243] has joined #bitcoin-wizards
19:23 < bramc> amiller: Fair enough, in principle anyone can spend can be soft forked into the underlying transactions just being an accounting system with the authentication done by something new
19:26 < amiller> bramc, it's pretty tricky still, because the problem is that the *next* transaction has to refer to the previous one by its TXID, which necessarily includes its inputs
19:26 -!- ratbanebo [~ratbanebo@ptr-fyxkxbtpg79g8ril52w.18120a2.ip6.access.telenet.be] has quit [Ping timeout: 240 seconds]
19:27 < amiller> so the MULTIINPUT idea is what iddo came up with for getting around that in a soft-fork compatible way
19:27 < amiller> i *think* it is soft-fork compaitble
19:28 < bramc> amiller: But you could have the 'real' signing layer refer to transactions using a different id. That requires potentially two utxo databases, which would be annoying
19:29 < amiller> yeah, i thought for a while it was possible to do softfork for this without having to resort to building a whole new UTXO and somehow putting all anyonecanspend coins in thre
19:29 < bramc> amiller: MULTIINPUT fixes the one case, but it would be nice if inputs just plain didn't go into the txid. That seems to be the way you'd do it starting from scratch
19:29 < amiller> actually that is sort of an interesting thing, i don't think the "make an entire anyonecan spend special account" has been fleshed out as a general concept here
19:30 < amiller> sidechains is the only proposal that really does that i think
19:31 < bramc> sidechains doesn't include inputs in the txid/
19:31 < bramc> ?
19:31 < kanzure> http://elementsproject.org/ is where segwit came from
19:32 < gmaxwell> the idea of leaving out the @#$@ signatures from the hashes predates any of that, and I believe many people have independantly suggested that it would have been a better design over time.
19:33 < gmaxwell> In elements we made one such construction and worked through things like for engineering reasons you still need commitments to the signatures.
19:40 < bramc> gmaxwell: What do you mean by commitments to the signatures?
19:41 < gmaxwell> the block has to have a hash of the witnesses; or otherwise there is a trivial denial of service attack where you can feed a node malleated blocks with invalidated signatures. (and it's generally useful for accountablity to know what signature was actually used, when multiple administratively distinct signatures are possible)
19:45 < bramc> Oh of course that's needed
19:45 < bramc> But I wasn't 100% sure dropping the inputs is okay, sounds like it is
19:46 < sipa> dropping the _inputs_, not just the input scripts?
19:46 < sipa> elements does not drop the inputs
19:46 < sipa> that would enable replay attacks
19:47 < bramc> sipa: Salt in the transactions can prevent replay attacks
19:47 < gmaxwell> and then require a perpetually growing used salt database.
19:48 < bramc> If the salt's long enough choosing it at random should work fine
19:48 < gmaxwell> except for the unprunable perpetually growing salt database...
19:48 < bramc> Why do you need a salt database? Each transaction creator can make sure their own salt is fine by making it long enough and random
19:49 < sipa> if you don't have address reuse, it is possible
19:49 -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving]
19:51 < bramc> Without address reuse you don't need the salt at all. It only applies in the case where, for example, someone's accepting donations, and then pays someone else for something, and that other person snarfs an identical-sized donation
19:52 < sipa> right
19:52 < bramc> And in that case both of the people doing donations can just choose long enough random salt and the problem goes away
19:53 < gmaxwell> it's very hard to reliably prevent all possible cases of reuse, due to concurrency and state (e.g. restarts.)
19:54 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-eoiapfnuwquicnea] has quit [Quit: Connection closed for inactivity]
19:54 < bramc> Maybe there's an attack where I send you a payment which is a duplicate of another in exchange for something, then get a payment back from you for something else and reclaim the original payment
19:55 < bramc> But then, a duplicate payment can be rejected for already being in the utxo set and won't go through until the old one is spent
19:56 < sipa> assuming there is only one per block
19:56 -!- eck [~eck@unaffiliated/eck] has joined #bitcoin-wizards
19:56 < eck> is this bitcoin lizards?
19:57 < bramc> sipa: It would be totally reasonable to check the utxo set and reject transactions which have outputs which are already in there
19:58 < sipa> bramc: yes, but the utxo set only has outputs from confirmed transactions
19:58 < sipa> you can't prevent multiple concurrent unconfirmed payments to the same address
19:59 < sipa> though i guess you introduce the concept of 'double pay' to the mempool as well, mimicking double spend prevention
19:59 < bramc> sipa: right but that attack only matters when multiple senders are intentionally using duplicate salt
19:59 < bramc> and yes it should be backed up in the mempool as well
20:01 < bramc> There could be a compression trick where 'unsalted' transactions make their salt by hashing the inputs, and the size of those bytes doesn't count to the block size
20:02 -!- jjj [689cf085@gateway/web/freenode/ip.104.156.240.133] has joined #bitcoin-wizards
20:05 < sipa> bramc: btw, as the discussion stopped afterwards, do you understand how TXO commitments can give you proof of unspentness?
20:05 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Quit: Textual IRC Client: www.textualapp.com]
20:07 < bramc> sipa: Uh, no, they only seem useful for proofs of spentness
20:08 < bramc> having STXO commitments can work but only if the STXO set format is one which allows for proofs of non-inclusion which append-only formats don't
20:08 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has quit [Remote host closed the connection]
20:08 < sipa> bramc: TXO commitments (as proposed by peter todd) are append only, but still mutable
20:09 -!- skeuomorf [~skeuomorf@unaffiliated/skeuomorf] has quit [Ping timeout: 240 seconds]
20:09 < sipa> so the spent entries are overwritten
20:09 < sipa> but there just is no rebalancing
20:09 < sipa> as there is no rebalancing, wallets can easily keep track of where their own outputs in that tree are
20:10 < bramc> Oh that, yeah, that seems to combine the worst of everything
20:10 < sipa> while full nodes can completely forget it (i.e., the have no database or UTXO set at all anymore)
20:10 < sipa> *they
20:11 < sipa> wallets provide a proof that their inputs are in the tree, with enough information for full nodes to recompute the root after adding outputs and overwriting inputs
20:11 < bramc> Not sure how that all works. Wallets wanting to prove unspentness of their own things still have to get updates to new roots
20:11 < sipa> sure, they need to see the blocks
20:12 < sipa> they can also outsource it
20:12 < sipa> and full nodes can keep a partial utxo tree for recently created outputs, so the proofs are only needed for spending old coins
20:12 < bramc> They can also outsource updating their unspent proofs in a much simpler format
20:13 < bramc> And full nodes can remember what the recent updates were in a simpler format as well
20:13 < sipa> i really like the idea of making the UTXO set size something that doesn't impact full node scalability anymore
20:13 < sipa> of course, it comes with very different costs elsewhere
20:14 < bramc> A simpler format gets all the same advantages
20:14 < sipa> what do you mean by simpler format?
20:15 < bramc> I mean having a simple utxo root like I proposed
20:15 < sipa> oh, there are certainly many alternatives to the commitment structure
20:15 < sipa> i still haven't read your proposal, and i plan to
20:16 < sipa> but this idea of moving the (U)TXO set out of full nodes changes the priorities
20:16 < bramc> My proposal is a really simple patricia trie with one performance trick thrown into the semantic definition and a bunch of tricks in the non-reference implementation to improe cache coherence
20:17 -!- ratbanebo [~ratbanebo@ptr-fyxkxbu059v5y9b6n9a.18120a2.ip6.access.telenet.be] has joined #bitcoin-wizards
20:17 < bramc> Fully relying on that is potentially problematic because a wallet which has been asleep for a while still needs to find a truly full node to get its proofs
20:18 < bramc> But that issue is orthogonal to any issues of UTXO or TXO format, at least among the ones we're discussing. They all support it.
20:19 < sipa> Absolutely.
20:19 < sipa> But if for example no (or few) nodes will actually keep the full dataset around anymore, something like memory compactness becomes relatively unimportant.
20:20 < sipa> So I just wanted to make sure you understood the idea.
20:20 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has joined #bitcoin-wizards
20:20 < bramc> Yeah I understand the idea, but having the whole world rely on a relatively small number of nodes to actually keep everything around is alarming to me
20:21 < sipa> Nobody needs to keep everything.
20:21 < sipa> And the blockchain still exists, you only need to replay it and apply it to your own subset.
20:21 -!- jjj is now known as jjj_f3hr
20:21 -!- ratbanebo [~ratbanebo@ptr-fyxkxbu059v5y9b6n9a.18120a2.ip6.access.telenet.be] has quit [Ping timeout: 264 seconds]
20:22 < bramc> *somebody* needs to keep everything around, because wallets reanimating after years of being asleep and wanting to spend is an important use case
20:22 < sipa> well, sure, just replay old blocks
20:22 < sipa> dumb storage is easy
20:22 < bramc> That might be quite a bit of replaying
20:23 < sipa> indeed, but it's much simpler than fully validating history
20:23 < bramc> My thought is that it's possible to get away with doing everything the dumb way by using an efficient implementation
20:24 < sipa> my opinion is pretty much the opposite
20:24 < sipa> i think UTXO lookup/updating is already too slow, and it's only getting worse
20:24 < bramc> Any of these formats will allow a simple proof of validity of every block
20:24 < sipa> and any commitment structure that needs updating in real time will make it an order of magnitude worse
20:24 < bramc> What's involved in it currently?
20:24 -!- pro [~pro@unaffiliated/pro] has quit [Quit: Leaving]
20:25 < sipa> looking up an entry in the database, deleting it, and adding a new one
20:25 < sipa> those are batched for hundreds of blocks, and cached in memory
20:25 < sipa> and the occasionally flushed to disk
20:26 < bramc> Not knowing how these databases work it's hard for me to evaluate. This sounds very strange
20:26 < sipa> a disk lookup can be multiple milliseconds
20:26 < sipa> you're not going to do better than that times the number of inputs
20:26 < bramc> Well yes you want the utxo set to easily fit in memory
20:27 < sipa> it's several GB already
20:27 < sipa> if the whole thing is in memory, it's easy
20:27 < sipa> but for many devices, it already can't
20:27 < bramc> The inputs can be easily verified if they're hashes
20:28 < sipa> so we'd need consensus rules to curb the utxo set growth
20:28 < sipa> (which we probably should have anyway... but blah blah political drama)
20:29 < bramc> Well *for now* it all fits in memory easily on most full nodes and having nodes do the dumb thing before it's necessary to require the much more complicated thing would give lots of lead time
20:30 < sipa> it only fits in memory on dedicated machines, really
20:31 < sipa> the representation in memory is several times larger than the one on disk
20:31 < sipa> http://bitcoin.sipa.be/utxo_size.png <- i should redo this
20:31 < gmaxwell> (as the one on disk is compressed in a multitude of ways.)
20:31 < bramc> In the data structure I made the representation in memory is only slightly bigger than the list of hashes concatenated
20:32 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:e010:f40e:b2c6:f8cd] has quit [Ping timeout: 246 seconds]
20:32 < sipa> but we'd pretty much need to replace the whole database with your representation?
20:33 < sipa> or can it deal with just having a subset loaded from disk?
20:34 < bramc> Not sure what you mean by 'a subset'
20:34 < sipa> right now, the full utxo set is only on disk
20:34 < bramc> or what exactly is currently stored on disk
20:34 < sipa> and there is a cache/write buffer in memory
20:34 < sipa> on disk there is LevelDB datbase with txid -> [list of unspent outputs] map
20:35 < sipa> i'm working on changing that to a [txid,vout] -> {unspent output} map
20:35 < sipa> and there is a cache in memory that keeps a subset of it around
20:35 < sipa> if you set the cache size very high, it can become effectively the entire set
20:36 < sipa> but we can't assume that you can just load the whole thing in memory
20:36 < bramc> I haven't implemented it as a cache
20:36 < sipa> most devices that run bitcoin core can't do that
20:37 < bramc> You could easily tune my thing so that the leaves were kept on disk, that would result in a block update being done as basically a single scan across the whole set
20:38 < sipa> that's why i like delayed commitments... they can be computed asynchronously, and can use a commitment structure that is independent from the database implementation
20:38 < sipa> just read through the whole database once per week, and compute its hash (by merkleizing the items on the fly)
20:38 < bramc> Commitments need to be delayed, it's just a question of how delayed
20:39 < sipa> if it's delayed enough, you don't need any efficient updating at all; just recompute the whole thing
20:40 < bramc> Yes that's the easy way, but there's no harm in using a format which makes incremental updates possible
20:40 < sipa> absolutely
20:40 < sipa> especially if it's something that is easily constructible from a sorted list of entries
20:41 < bramc> I need to implement on-the-fly computation of my format on a sorted list of entries, also need to mention that on list because it came up
20:41 < sipa> but at this point, my biggest uncertainty is whether we want UTXO commitments at all... or at least whether we want mandatory UTXO commitments at all, as they preclude any future change that removes the full utxo set from full nodes
20:42 < bramc> Well full nodes need the full utxo set to validate blocks
20:42 < sipa> not in a TXO+proofs model
20:42 < sipa> which i'll very readily admit is not nearly researched enough to consider for the short term
20:42 < bramc> You can also have utxo+proofs and it's a lot simpler. Apples to apples it's all the same data flows
20:43 < sipa> ah yes, if blocks are easily applicable to subsets of UTXOs in it
20:43 < sipa> agree!
20:44 < bramc> Proofs of blocks could be shipped around with blocks easily enough
20:44 < sipa> cool
20:44 < sipa> i'll read more about this
20:44 < sipa> it's been useful to bring it up :)
20:45 < bramc> How are nodes validating blocks currently?
20:46 < sipa> go through the inputs, find them in the database (with big caching layer in between), then build a batch of updates to apply to the database (which removes inputs and add outputs), iterate through the scriptsigs and validate them, and if they are all good, apply the batch to the cache (and perhaps trigger a flush to disk, if memory is low)
20:47 -!- skeuomorf [~skeuomorf@unaffiliated/skeuomorf] has joined #bitcoin-wizards
20:48 < bramc> Using my non-reference implementation with the leaves on disk should be able to utterly ream that in terms of performance
20:49 -!- jjj_f3hr [689cf085@gateway/web/freenode/ip.104.156.240.133] has quit [Quit: Page closed]
20:50 < sipa> how so?
20:51 < sipa> i don't see how a commiting version would not do any of the steps that are already being done
20:52 < bramc> It has a much better idea of exactly where everything is, there's semantic simplicity in knowing that you've just got a hash set
20:52 < sipa> LevelDB also knows exactly where everything is...
20:52 < bramc> hrm, fair enough, mostly after that it's just more compact
20:53 < sipa> why would it be more compact
20:53 < bramc> hashes are all the exact same size
20:53 < sipa> so? the current implementation has no hashes at alll
20:53 < sipa> and you still need the full utxos *somewhere*
20:53 < sipa> which are not constant size
20:53 < bramc> although if leveldb is really doing things right it should be about the same, but with the calculation of hash roots doing no harm
20:54 < bramc> Yeah I'm assuming the full utxos are somewhere else
20:54 < sipa> well, *all* the current time is spent dealing with the full utxos
20:55 < bramc> right the current world is basically proofless, so when there's a reference to a utxo you need to go look up what the pkscript is
20:55 < sipa> indeed
20:56 < sipa> so in my view (but i'm glad to be proven wrong) any commitment structure is going to be purely additive to what we're already doing
20:57 < sipa> and perhaps that extra is negligable or insignificant, but i'm skeptical about that
20:57 < bramc> In a better world whenever you get a block it comes with all the earlier pkscripts and a proof of inclusion of its inputs in the current utxo set
20:57 < sipa> yup
20:57 < bramc> This better world is annoying because it requires no lag on utxo commitments at all
20:58 < bramc> So it both enables and requires aggressive commitments
21:00 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection]
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:06 < bramc> There are different levels of functionality here. One is to allow pruning of old history, that can be accomplished with occasional commitments. Another is to allow proofs of validity of nodes. That second one really sucks
21:06 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]
21:07 < bramc> Basically it can be done, but it requires a completely up to date root in every block, and peter todd's txo commitment structure doesn't change that requirement any
21:08 < bramc> So wallets are stuck asking for updates to proofs of their own utxos still being u from nodes, which are cheap on an ongoing basis but get expensive when the gap is long enough because they require either a fresh lookup or re-running everything
21:09 < bramc> On the plus side, each of those lookups is done by *one* node, and the proof is simply included in the block and verified by everyone else, so yeah it's a big win
21:10 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.]
21:11 -!- ratbanebo [~ratbanebo@78-23-23-157.access.telenet.be] has joined #bitcoin-wizards
21:11 < bramc> And merging together proofs is actually pretty easy - a wallet can give a proof of unspentness from a milestone a while back and the full node can merge in the update since then easily
21:12 < bramc> Those milestones don't even have to be baked into the format, they can be conventions of the peer protocol
21:13 < sipa> i believe peter todd has work on delayed txo commitments as well that merge proofs from multiple blocks, but i haven't read up on that either
21:13 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 268 seconds]
21:14 < bramc> He's doing all the same stuff in obfuscated form
21:14 < sipa> haha
21:15 -!- ratbanebo [~ratbanebo@78-23-23-157.access.telenet.be] has quit [Ping timeout: 256 seconds]
21:15 < bramc> There are some performance optimizations he's doing which might or might not help, and there are simpler ways of doing those same optimizations (simpler than what he's doing, more complicated than what I've built)
21:17 < bramc> But all that doesn't change the algorithmic structure: There's a commitment at every block which can be used to prove the very next block
21:18 -!- teslax [Elite19141@gateway/shell/elitebnc/x-mruavbtcxyjwline] has quit [Ping timeout: 240 seconds]
21:19 < bramc> His approach does help a bit if you want servers to be able to rolling calculate that root without the benefit of the proofs. That doesn't seem particularly useful
21:21 < bramc> or rather, you can get that same benefit by making everything trail a bit
21:21 < bramc> Maybe it's possible to keep the trailing just a little bit and the constant proofs. Need to think about that a bit more.
21:23 < sipa> the insertion ordering is nice for those that need to keep subsets around, as the vast majority of spends are recent
21:24 < sipa> but perhaps the idea of having a structure that is not insertion-ordered but can be used for both utxo commitments and a full-nodes-utxo-less world is appealing enough to consider
21:28 < bramc> Insertion ordering is a constant factor optimization
21:28 < sipa> depends for what, and depends on usage pattern
21:28 < bramc> And the same effect can be had with a much more general purpose data structure
21:29 < bramc> Basically you make a trie which stores variable length strings and store the insertion numbers
21:30 < bramc> That gets you all the performance benefits of insertion ordering without something so bespoke
21:31 -!- eck [~eck@unaffiliated/eck] has left #bitcoin-wizards ["WeeChat 1.0.1"]
21:39 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has quit [Remote host closed the connection]
21:40 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has joined #bitcoin-wizards
21:41 < bramc> The current UTXO set could probably be compacted down into less than half a gig in memory with an insertion ordered data structure. Problem being that it's all insertion numbers and you need to go from txids to insertion numbers
21:42 < sipa> eh, no
21:42 < bramc> no what?
21:44 < sipa> it's 1838178283 bytes, just serializing the entries back to back without any commitment structure
21:44 < bramc> How many entries?
21:45 < sipa> 46812974, from 18331102 different transactions
21:45 < bramc> At the extreme of aggression of compacting the transaction ordered set it's a bit field
21:46 < sipa> i'm confused
21:46 < sipa> just the txids of 18331102 transactions takes more than 500 MB
21:47 < bramc> Yeah that's the problem: The transaction ordered set isn't so useful without going from txid -> entry number. The txids by themselves are quite a bit bigger
21:49 < bramc> But the commitment structure could be made much smaller. You could trivially represent it all as a commitment to a bitfield
21:50 < bramc> Maybe that isn't a bad idea. Proofs of txid -> position are taken directly out of the block chain
21:54 < bramc> Then the math is: for about 50 million txids, adding commitments roughly doubles the size of storage, and the underlying storage is 50 million divided by 8 because it's only one bit per. That's about 12 megabytes.
21:56 < bramc> If the size of the utxo set isn't much less than 1/10 the size of the txo set it's going to be really, really hard to beat this data structure
21:57 -!- Guest11920 [Elite19141@gateway/shell/elitebnc/x-jiwenbqahahhelwu] has joined #bitcoin-wizards
22:00 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has quit [Remote host closed the connection]
22:03 < bramc> Presumably the txo set is much bigger but ever 120 megabytes wouldn't be a big deal
22:05 -!- ratbanebo [~ratbanebo@ptr-fyxkxbtw5bsyrru33vu.18120a2.ip6.access.telenet.be] has joined #bitcoin-wizards
22:05 < sipa> there have been 206M transactions total
22:06 < sipa> over 91% have had all their outputs spent
22:07 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Disconnected by services]
22:07 -!- [7] [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
22:07 < bramc> How many outputs from those 206M transactions?
22:08 < sipa> i don't have the number for that
22:09 < bramc> One hacky but serviceable thing to do would be to start the set at a particular block and everything before that is positioned by its place in the utxo set at that time, to make it smaller
22:10 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:f457:f67b:4154:7fa0] has joined #bitcoin-wizards
22:10 -!- ratbanebo [~ratbanebo@ptr-fyxkxbtw5bsyrru33vu.18120a2.ip6.access.telenet.be] has quit [Ping timeout: 240 seconds]
22:13 < bramc> Then presto it's down to 12 megs today, and even if every block is full it's only growing at a rate of 30 megs/year
22:24 -!- bramc [268265f3@gateway/web/freenode/ip.38.130.101.243] has quit [Ping timeout: 260 seconds]
22:28 -!- ahmedsfhtagn [~ahmeds42@212.0.149.80] has joined #bitcoin-wizards
22:30 -!- ahmedsfhtagn [~ahmeds42@212.0.149.80] has quit [Max SendQ exceeded]
22:30 -!- ahmedsfhtagn [~ahmeds42@212.0.149.80] has joined #bitcoin-wizards
22:32 -!- ahmedsfhtagn [~ahmeds42@212.0.149.80] has quit [Max SendQ exceeded]
22:33 -!- ahmedsfhtagn [~ahmeds42@212.0.149.80] has joined #bitcoin-wizards
22:35 -!- ahmedsfhtagn [~ahmeds42@212.0.149.80] has quit [Max SendQ exceeded]
22:35 -!- ahmedsfhtagn [~ahmeds42@212.0.149.80] has joined #bitcoin-wizards
22:37 -!- ahmedsfhtagn [~ahmeds42@212.0.149.80] has quit [Max SendQ exceeded]
22:38 -!- ahmedsfhtagn [~ahmeds42@212.0.149.80] has joined #bitcoin-wizards
22:39 -!- ahmedsfhtagn [~ahmeds42@212.0.149.80] has quit [Max SendQ exceeded]
22:39 -!- ahmedsfhtagn [~ahmeds42@212.0.149.80] has joined #bitcoin-wizards
22:43 -!- ahmedsfhtagn [~ahmeds42@212.0.149.80] has quit [Remote host closed the connection]
22:43 -!- ahmedsfhtagn [~ahmeds42@212.0.149.80] has joined #bitcoin-wizards
22:44 -!- ahmedsfhtagn [~ahmeds42@212.0.149.80] has quit [Max SendQ exceeded]
23:01 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has joined #bitcoin-wizards
23:03 -!- oleganza [~oleganza@c-73-170-224-149.hsd1.ca.comcast.net] has joined #bitcoin-wizards
23:06 -!- tromp [~tromp@ool-944bc443.dyn.optonline.net] has quit [Ping timeout: 260 seconds]
23:07 -!- oleganza_ [~oleganza@172.58.91.72] has joined #bitcoin-wizards
23:07 -!- oleganza [~oleganza@c-73-170-224-149.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
23:07 -!- oleganza_ is now known as oleganza
23:24 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has quit [Remote host closed the connection]
23:25 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]
23:25 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has joined #bitcoin-wizards
23:26 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-wizards
23:33 -!- skang404 [~skang404@2405:205:4285:de3d:f193:4325:e9d8:8f0f] has joined #bitcoin-wizards
23:48 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has quit [Remote host closed the connection]
23:49 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has joined #bitcoin-wizards
23:51 -!- bildramer1 [~bildramer@p2003004D2B673100F00750046972E1A2.dip0.t-ipconnect.de] has joined #bitcoin-wizards
23:53 -!- bildramer [~bildramer@p2003004D2B67310095B2992139B8D410.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
23:53 -!- ratbanebo [~ratbanebo@78-23-23-157.access.telenet.be] has joined #bitcoin-wizards
23:54 -!- oleganza [~oleganza@172.58.91.72] has quit [Quit: oleganza]
23:58 -!- ratbanebo [~ratbanebo@78-23-23-157.access.telenet.be] has quit [Ping timeout: 260 seconds]
--- Log closed Sun Mar 19 00:00:02 2017