--- Log opened Thu Jul 09 00:00:05 2015
00:00 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep]
00:04 -!- venzen [~venzen@5.255.87.165] has joined #bitcoin-wizards
00:04 -!- alewis_btc [~antonylew@101.100.162.252] has joined #bitcoin-wizards
00:13 -!- Mably [~Mably@unaffiliated/mably] has quit [Ping timeout: 244 seconds]
00:13 -!- p15x_ [~p15x@111.194.197.10] has quit [Max SendQ exceeded]
00:14 -!- p15x [~p15x@111.194.197.10] has joined #bitcoin-wizards
00:18 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]
00:19 -!- Quanttek [~quassel@ip1f10af17.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards
00:20 -!- JackH [~Jack@host-80-43-142-154.as13285.net] has joined #bitcoin-wizards
00:22 -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Quit: Leaving]
00:26 -!- drwin [~drwin@88-103-255-166.jes.cz] has joined #bitcoin-wizards
00:29 -!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has quit [Quit: Leaving.]
00:31 -!- Giszmo [~leo@pc-185-201-214-201.cm.vtr.net] has quit [Quit: Leaving.]
00:32 -!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has joined #bitcoin-wizards
00:33 -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has quit []
00:34 -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards
00:39 -!- alewis_btc [~antonylew@101.100.162.252] has quit [Quit: alewis_btc]
00:44 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 264 seconds]
00:49 -!- Mably [56401ec5@gateway/web/freenode/ip.86.64.30.197] has joined #bitcoin-wizards
00:51 -!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has quit [Quit: Leaving.]
01:13 -!- alewis_btc [~antonylew@118.189.115.158] has joined #bitcoin-wizards
01:14 -!- rustyn [~rustyn@unaffiliated/rustyn] has quit [Quit: london]
01:22 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards
01:25 < gmaxwell> rusty: I cheated, got transaction size down to 81 bytes for 2-in-2-out: https://www.reddit.com/r/Bitcoin/comments/3cmr2v/showerthought_what_if_instead_of_making_the/csx7pbj
01:27 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 248 seconds]
01:28 -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-wizards
01:30 -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has joined #bitcoin-wizards
01:31 -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has quit [Max SendQ exceeded]
01:31 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds]
01:38 -!- drwin [~drwin@88-103-255-166.jes.cz] has quit []
01:42 -!- OneFixt_ [~OneFixt@unaffiliated/onefixt] has joined #bitcoin-wizards
01:44 -!- venzen [~venzen@5.255.87.165] has quit [Ping timeout: 250 seconds]
01:45 -!- theymos [~theymos@unaffiliated/theymos] has quit [Ping timeout: 250 seconds]
01:45 -!- theymos [~theymos@unaffiliated/theymos] has joined #bitcoin-wizards
01:46 -!- OneFixt [~OneFixt@unaffiliated/onefixt] has quit [Ping timeout: 250 seconds]
01:47 -!- venzen [~venzen@5.255.87.165] has joined #bitcoin-wizards
01:53 -!- Quanttek [~quassel@ip1f10af17.dynamic.kabel-deutschland.de] has quit [Ping timeout: 264 seconds]
01:55 -!- goregrind [~goregrind@unaffiliated/goregrind] has quit [Read error: Connection reset by peer]
01:59 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
02:03 -!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has joined #bitcoin-wizards
02:07 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_]
02:10 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte]
02:11 -!- goregrind [~goregrind@unaffiliated/goregrind] has joined #bitcoin-wizards
02:18 -!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has joined #bitcoin-wizards
02:19 < CodeShark> gmaxwell: if you're looking to optimize something with the transaction encoding, optimize verification complexity before optimizing space :)
02:19 < gmaxwell> I pointed out in the message that its optimizing the wrong thing.
02:20 < CodeShark> right
02:21 -!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has quit [Ping timeout: 244 seconds]
02:21 < gmaxwell> though with batch schnorr in elements, it's actualyl bandwidth limited on bitcoin transactions up through most consumer broadband speeds.
02:22 < CodeShark> well, the ultimate goal would be to have something like SPV but that actually works :p
02:22 < gmaxwell> and I think _generally_ its easier to scale your cpu power than bandwidth, as cpu power comes in pretty little boxes from newegg.
02:22 < gmaxwell> CodeShark: well any of that would be generally applicable-ish.
02:23 -!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has joined #bitcoin-wizards
02:24 < CodeShark> if we're going to allow all this cheating, can't we come up with a protocol that doesn't require downloading the entire transaction history from the beginning of time to validate the present? (besides the summary commitments of lightning and such)
02:25 < CodeShark> can we do better than SNARKs?
02:25 < gmaxwell> CodeShark: what I was describing didn't change the security model at all.
02:25 < CodeShark> I
02:25 < gmaxwell> or even require crypto younger than 15 years old or so.
02:26 < gmaxwell> maybe 14 years old.
02:26 < CodeShark> I'm well aware of that - I was trying to do a segue... :p
02:26 < gmaxwell> CodeShark: well if you want a segue, go figure out a way to do that and suggest it. :)
02:27 -!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has joined #bitcoin-wizards
02:27 < CodeShark> I was thinking a nested consensus mechanism of some sort...so that lightning doesn't necessarily need to resort to the global consensus structure for dispute resolution
02:28 < CodeShark> then perhaps we can cut down the number of global commitments even further
02:28 < CodeShark> you continue to appeal if there's still a dispute
02:28 < CodeShark> until you reach the global consensus structure
02:29 < CodeShark> that would mean only the most contentious battles would tend to reach the global consensus level
02:30 < CodeShark> each level up costs more, of course - since you're asking more people to contribute computational resources to decide your case
02:31 < CodeShark> I mean, that's sort of how civil society works
02:32 < CodeShark> civil society does not work by making sure everyone knows that I paid my gardner yesterday
02:32 < CodeShark> unless I failed to pay the gardner or the gardner failed to provide services
02:32 -!- alewis_btc [~antonylew@118.189.115.158] has quit [Quit: alewis_btc]
02:32 < waxwing> i've always assumed bitcoin would evolve like that
02:33 < moa> nsh: https://github.com/bitcoin/bitcoin/pull/6402 jgarzik has a very similar idea with a cleaner implementation it looks like
02:34 -!- alewis_btc [~antonylew@118.189.115.158] has joined #bitcoin-wizards
02:35 < gmaxwell> CodeShark: great you've just described what lightning does; it only elevates most activity to the public network if there is a dispute.
02:36 < CodeShark> gmaxwell: there could be a tiered structure - doesn't have to go straight to ground...you can have lightning bolts that just hit clouds with a slightly different voltage :)
02:37 < CodeShark> waxwing: doesn't seem very many people have always assumed that :p
02:38 < CodeShark> consider those who are trying to use the blockchain as a ledger for every single asset for every single individual in the world :p
02:39 < waxwing> CodeShark: this is kind of what i think: https://bitcointalk.org/index.php?topic=418071.msg6423270#msg6423270
02:40 < waxwing> but, i'd say, there's a fairly big proportion of people who see bitcoin as more like SWIFT or somesuch ... well, i don't know, it still seems to be a controversial question
02:41 < gmaxwell> People expect bitcoin to be both floor wax and dessert topping; and miss the fact that even if it can be all things to all people that might only be possible at the expense of being very poor at all of them.
02:42 < waxwing> gmaxwell: yes, difficult to argue with that. but which is it? :)
02:42 < CodeShark> reversibility and recourse for dispute resolution should be optional features in a payment system that could be waived
02:42 < gmaxwell> Well the question I ask is what does (/can) Bitcoin do uniquely better in a fundimental way compared to alternatives.
02:43 < waxwing> optional, agreed CodeShark
02:43 < waxwing> gmaxwell: resist censorship
02:43 < gmaxwell> I do not think bitcoin can out-swift swift.. if its better at being swift at all, in any way, it's only because swift is asleep at the switch.
02:43 < gmaxwell> But right, someone once asked me if I thought Bitcoin was more for paying wikileaks or for replacing credit cards.
02:43 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
02:44 < waxwing> SWIFT I just use as a placeholder for : "serious" payments which may cross jurisdictional boundaries
02:44 < waxwing> and it's in exactly that context that censorship resistance matters most
02:44 < gmaxwell> And I poninted out that I have a 2% cashback credit card that it seems hard for bitcoin payments to compete with for plain retail payments;  but that same creditcard cannot pay wikileaks-- mastercard shut that down, even without a government demand to do so.
02:45 < gmaxwell> But its not just edgy uses, if you want to create a layer above to do interesting things; you need to be able to count on the contracts underlying it are absolte ... or every step requires complex risk analysis that computers cannot do.  Thats something: be very predictable, that bitcoin can possibly do that traditional systems cannot, because meddling with them arbritarily is too easy.
02:46  * waxwing nods
02:47 < waxwing> that's kind of what i was trying to get at in that post, it should be obvious that the whole thing 'works' one way round (uncensorable at the bottom) and doesn't work the other.
02:47 < moa> "If you try to mix in those higher layers to the underlying protocol, you destroy it.: waxwing here's the danger, cramming things in that are better kicked upstairs
02:47 < CodeShark> even if the contracts at the edges of the network imply risk, the risk could be managed by a separate layer
02:48 < CodeShark> i.e. insurance, market makers, etc...
02:49 < CodeShark> and the ecosystem can involve humans that willingly take on the risk for potential profit
02:51 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
02:54 -!- dEBRUYNE [~dEBRUYNE@239-196-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards
02:58 < CodeShark> so I don't think that necessarily every step requires complex risk analysis
02:58 < CodeShark> the risk can be isolated from the predictable layers
03:01 -!- freewil [~freewil@unaffiliated/freewil] has joined #bitcoin-wizards
03:01 -!- freewil [~freewil@unaffiliated/freewil] has left #bitcoin-wizards []
03:01 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
03:06 < leakypat> SWIFT can route your payment through jurisdictions without your knowledge
03:07 < leakypat> A lot of local banks around the world are corrupt / insolvent, so for international trade I think the censorship resistance property is valuable
03:08 < leakypat> The letter of credit market for example
03:09 -!- alewis_btc [~antonylew@118.189.115.158] has quit [Quit: alewis_btc]
03:11 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-oomktsnheulxpvbm] has quit [Ping timeout: 250 seconds]
03:11 < leakypat> How many use this system just because it's the way things are done and always have been
03:11 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards
03:11 < CodeShark> there are very few cryptocurrency applications right now that really make much use of any features that go beyond just the traditional payment systems people are used to
03:13 < leakypat> The current system introduced unnecessary risk into a lot of transactions just by virtue of the fact it is a closed system
03:13 -!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has quit [Quit: Leaving.]
03:13 < leakypat> So I want to pay a supplier in Nigeria but I can't because my bank doesn't trust their bank
03:14 < CodeShark> never send money to Nigeria for any reason :p
03:14 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards
03:14 < leakypat> Well, I have friends in Nigeria who I would totally trust to send money to.. Just not via the local banks
03:15 < CodeShark> are they princes?
03:15 < leakypat> I'm sensing your reference point for Africa is scam nails and /or "coming to America"
03:15 < leakypat> *mails
03:16 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 244 seconds]
03:16 < CodeShark> anyhow, your point is well taken - if we could choose how to route payments ourselves we could avoid this "my bank doesn't trust theirs" issue
03:16 < leakypat> In any case, Nigeria can be any country
03:16 < CodeShark> I know, I was just kidding
03:17 < leakypat> Even Europe, transactions between Sweden and Germany
03:17 < leakypat> Routed through the states
03:17 < leakypat> Money frozen
03:17 < leakypat> Why? Cuban cigars
03:17  * fluffypony lives in Africa
03:17 -!- www [~v3@x5ce16b33.dyn.telefonica.de] has joined #bitcoin-wizards
03:18 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-mrjmebcteisqxxqb] has joined #bitcoin-wizards
03:19 < CodeShark> would money being frozen also fit into the "censorship" category?
03:19 < leakypat> For sure
03:20 < leakypat> It's risk being introduced by the system
03:20 < leakypat> That costs
03:20 < leakypat> fluffypony: where abouts?
03:21 < fluffypony> leakypat: South Africa
03:21 -!- Emcy [~MC@unaffiliated/mc1984] has quit [Read error: Connection reset by peer]
03:24 -!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has joined #bitcoin-wizards
03:24 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer]
03:24 -!- koshii [~w@c-68-58-151-30.hsd1.in.comcast.net] has quit [Ping timeout: 252 seconds]
03:25 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards
03:26 -!- koshii [~w@c-68-58-151-30.hsd1.in.comcast.net] has joined #bitcoin-wizards
03:27 -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [Ping timeout: 264 seconds]
03:28 -!- Tiraspol [~Tiraspol3@83.70.153.95.dyn.idknet.com] has joined #bitcoin-wizards
03:28 -!- Tiraspol [~Tiraspol3@83.70.153.95.dyn.idknet.com] has quit [Changing host]
03:28 -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards
03:29 -!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has quit [Quit: Leaving.]
03:30 -!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has joined #bitcoin-wizards
03:34 -!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has quit [Ping timeout: 264 seconds]
03:45 -!- XXIII [~XXIII@67.70.121.248] has quit [Quit: Leaving]
03:49 -!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has joined #bitcoin-wizards
03:59 -!- p15x_ [~p15x@64.145.91.48] has joined #bitcoin-wizards
04:00 -!- p15x [~p15x@111.194.197.10] has quit [Ping timeout: 250 seconds]
04:15 -!- p15x [~p15x@64.145.91.19] has joined #bitcoin-wizards
04:15 -!- www [~v3@x5ce16b33.dyn.telefonica.de] has quit [Ping timeout: 252 seconds]
04:16 -!- p15x_ [~p15x@64.145.91.48] has quit [Ping timeout: 248 seconds]
04:24 -!- shaul [~shaul@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-wizards
04:24 -!- www [~v3@x5ce16b33.dyn.telefonica.de] has joined #bitcoin-wizards
04:29 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-mrjmebcteisqxxqb] has quit [Ping timeout: 252 seconds]
04:30 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-kcsesyyfuohnlqnf] has joined #bitcoin-wizards
04:34 -!- hashtag [~hashtag@cpe-69-23-213-3.ma.res.rr.com] has joined #bitcoin-wizards
04:44 -!- c0rw|zZz is now known as c0rw1n
04:46 -!- hashtag [~hashtag@cpe-69-23-213-3.ma.res.rr.com] has quit [Ping timeout: 246 seconds]
04:54 -!- drwin [~drwin@88-103-255-166.jes.cz] has joined #bitcoin-wizards
04:59 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 250 seconds]
05:00 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards
05:04 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 244 seconds]
05:06 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
05:11 -!- chmod755 [~chmod755@unaffiliated/chmod755] has joined #bitcoin-wizards
05:17 -!- p15x_ [~p15x@64.145.91.27] has joined #bitcoin-wizards
05:17 -!- p15x [~p15x@64.145.91.19] has quit [Ping timeout: 264 seconds]
05:18 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 250 seconds]
05:22 -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has joined #bitcoin-wizards
05:23 -!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
05:23 -!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has joined #bitcoin-wizards
05:23 -!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has quit [Client Quit]
05:28 -!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has quit [Ping timeout: 252 seconds]
05:35 -!- mjerr [~mjerr@p578EB7BE.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
05:36 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards
05:37 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: This computer has gone to sleep]
05:41 -!- SDCDev [~quassel@unaffiliated/sdcdev] has quit [Ping timeout: 256 seconds]
05:45 -!- afk11 [~thomas@46.7.4.219] has quit [Ping timeout: 276 seconds]
05:48 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Remote host closed the connection]
05:49 -!- eudoxia [~eudoxia@r167-57-48-151.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards
05:55 -!- alewis_btc [~antonylew@103.252.202.207] has joined #bitcoin-wizards
05:55 -!- nickler_ is now known as nickler
05:56 -!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards
05:57 -!- shaul_ [~shaul@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-wizards
05:58 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
06:00 -!- shaul [~shaul@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Ping timeout: 246 seconds]
06:02 -!- shaul_ [~shaul@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
06:05 -!- p15x [~p15x@111.194.197.114] has joined #bitcoin-wizards
06:06 -!- p15x_ [~p15x@64.145.91.27] has quit [Ping timeout: 264 seconds]
06:06 -!- binaryatrocity [~atr0phy.n@unaffiliated/br4n] has quit [Remote host closed the connection]
06:07 -!- hashtag [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has joined #bitcoin-wizards
06:09 -!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has joined #bitcoin-wizards
06:14 -!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has quit [Ping timeout: 276 seconds]
06:14 -!- chmod755_ [~chmod755@dsl-29-161.utaonline.at] has joined #bitcoin-wizards
06:14 -!- chmod755_ [~chmod755@dsl-29-161.utaonline.at] has quit [Changing host]
06:14 -!- chmod755_ [~chmod755@unaffiliated/chmod755] has joined #bitcoin-wizards
06:16 -!- chmod755 [~chmod755@unaffiliated/chmod755] has quit [Ping timeout: 240 seconds]
06:25 -!- SDCDev [~quassel@unaffiliated/sdcdev] has joined #bitcoin-wizards
06:27 -!- cdecker [~cdecker@2001:67c:10ec:2a49:8000::8] has joined #bitcoin-wizards
06:29 -!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has joined #bitcoin-wizards
06:34 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds]
06:38 -!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.]
06:56 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
06:56 -!- fkhan [~weechat@unaffiliated/loteriety] has quit [Ping timeout: 248 seconds]
06:56 -!- mats [sid23029@gateway/web/irccloud.com/x-odcymmhqskjwxcdr] has joined #bitcoin-wizards
06:57 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards
07:00 -!- stonecoldpat [~a9380004@janus-nat-128-240-225-56.ncl.ac.uk] has quit [Quit: Leaving.]
07:01 -!- hearn [~mike@185.25.95.132] has quit [Ping timeout: 248 seconds]
07:02 -!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards
07:08 -!- ruby32 [~ruby32@38.121.165.30] has joined #bitcoin-wizards
07:09 -!- fkhan [~weechat@unaffiliated/loteriety] has joined #bitcoin-wizards
07:14 -!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has quit [Ping timeout: 246 seconds]
07:14 -!- ruby32 [~ruby32@38.121.165.30] has quit [Quit: Leaving]
07:15 -!- ruby32 [~ruby32@38.121.165.30] has joined #bitcoin-wizards
07:15 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards
07:20 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 246 seconds]
07:20 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards
07:20 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Client Quit]
07:23 -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has quit [Ping timeout: 252 seconds]
07:24 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
07:27 -!- SaltySalads [~SaltySala@24.96.148.142] has quit [Quit: Leaving]
07:39 -!- alewis_btc [~antonylew@103.252.202.207] has quit [Quit: alewis_btc]
07:39 -!- tlrobinson [~tlrobinso@204.14.159.161] has joined #bitcoin-wizards
07:40 -!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has joined #bitcoin-wizards
07:49 -!- b_lumenkraft [~b_lumenkr@unaffiliated/b-lumenkraft/x-4457406] has joined #bitcoin-wizards
07:51 -!- dasource [uid48409@gateway/web/irccloud.com/x-knkimullxsdsuheq] has quit [Quit: Connection closed for inactivity]
07:51 -!- alewis_btc [~antonylew@103.252.202.207] has joined #bitcoin-wizards
07:51 -!- CodeShark [~textual@cpe-76-167-237-202.san.res.rr.com] has quit [Quit: Textual IRC Client: www.textualapp.com]
07:52 -!- www1 [~v3@x5ce12d9c.dyn.telefonica.de] has joined #bitcoin-wizards
07:54 -!- www [~v3@x5ce16b33.dyn.telefonica.de] has quit [Ping timeout: 256 seconds]
07:55 -!- tlrobinson [~tlrobinso@204.14.159.161] has quit [Quit: tlrobinson]
07:58 -!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has quit [Ping timeout: 250 seconds]
07:59 -!- davi [~davi@gnu/davi] has joined #bitcoin-wizards
08:00 -!- p15x [~p15x@111.194.197.114] has quit [Ping timeout: 252 seconds]
08:01 -!- ruby32 [~ruby32@38.121.165.30] has quit [Quit: Leaving]
08:01 -!- ruby32 [~ruby32@38.121.165.30] has joined #bitcoin-wizards
08:03 -!- ruby32 [~ruby32@38.121.165.30] has quit [Client Quit]
08:04 -!- p15x [~p15x@64.145.91.5] has joined #bitcoin-wizards
08:04 -!- ruby32 [~ruby32@38.121.165.30] has joined #bitcoin-wizards
08:12 -!- CodeShark_ [~androirc@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 256 seconds]
08:13 -!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has joined #bitcoin-wizards
08:14 -!- chmod755_ [~chmod755@unaffiliated/chmod755] has quit [Quit: Ex-Chat]
08:18 -!- davi [~davi@gnu/davi] has quit [Ping timeout: 256 seconds]
08:27 -!- zooko [~user@c-71-229-205-98.hsd1.co.comcast.net] has joined #bitcoin-wizards
08:37 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards
08:40 -!- hearn [~mike@185.25.95.132] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
08:40 -!- davi [~davi@gnu/davi] has joined #bitcoin-wizards
08:41 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 244 seconds]
08:45 -!- Xh1pher [~Xh1pher@pD9E3A97A.dip0.t-ipconnect.de] has joined #bitcoin-wizards
08:46 -!- instagibbs [32f65962@gateway/web/freenode/ip.50.246.89.98] has joined #bitcoin-wizards
08:47 -!- instagibbs [32f65962@gateway/web/freenode/ip.50.246.89.98] has quit [Client Quit]
08:49 -!- davi [~davi@gnu/davi] has quit [Ping timeout: 256 seconds]
08:54 -!- metamarc [~snizysnaz@unaffiliated/agorist000] has quit [Ping timeout: 255 seconds]
08:57 -!- spinza [~spin@197.89.23.144] has quit [Ping timeout: 240 seconds]
08:59 -!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has joined #bitcoin-wizards
09:01 -!- JackH [~Jack@host-80-43-142-154.as13285.net] has quit [Ping timeout: 246 seconds]
09:03 -!- metamarc [~snizysnaz@97.95.172.50] has joined #bitcoin-wizards
09:03 -!- metamarc [~snizysnaz@97.95.172.50] has quit [Changing host]
09:03 -!- metamarc [~snizysnaz@unaffiliated/agorist000] has joined #bitcoin-wizards
09:04 -!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
09:10 -!- alewis_btc [~antonylew@103.252.202.207] has quit [Quit: alewis_btc]
09:13 -!- Giszmo [~leo@pc-185-201-214-201.cm.vtr.net] has joined #bitcoin-wizards
09:19 -!- hashtagg_ [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has joined #bitcoin-wizards
09:20 -!- hashtag [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has quit [Ping timeout: 255 seconds]
09:21 -!- p15x_ [~p15x@64.145.91.77] has joined #bitcoin-wizards
09:22 -!- StephenM347 [~stephenm3@static-64-223-246-218.port.east.myfairpoint.net] has joined #bitcoin-wizards
09:22 -!- p15x [~p15x@64.145.91.5] has quit [Ping timeout: 246 seconds]
09:23 -!- bendavenport [~bpd@96.90.231.161] has joined #bitcoin-wizards
09:26 -!- bblue [~textual@104.220.67.131] has joined #bitcoin-wizards
09:31 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 265 seconds]
09:33 -!- HM [~HM@81.4.101.225] has quit [Quit: Segmentation fault]
09:34 -!- HM [~HM@81.4.101.225] has joined #bitcoin-wizards
09:39 -!- nullbyte [~NSA@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards
09:44 -!- Iriez [wario@distribution.xbins.org] has quit [Ping timeout: 248 seconds]
09:50 -!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has quit [Quit: Leaving.]
09:53 -!- jae_ [~jae@75-101-96-71.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards
09:53 -!- davi [~davi@gnu/davi] has joined #bitcoin-wizards
09:58 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.]
10:09 -!- p15x [~p15x@64.145.91.17] has joined #bitcoin-wizards
10:10 -!- Iriez [wario@distribution.xbins.org] has joined #bitcoin-wizards
10:10 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 246 seconds]
10:11 -!- p15x_ [~p15x@64.145.91.77] has quit [Ping timeout: 244 seconds]
10:13 -!- waxwing [~waxwing@62.205.214.125] has quit [Ping timeout: 252 seconds]
10:13 -!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards
10:14 -!- waxwing [~waxwing@62.205.214.125] has joined #bitcoin-wizards
10:15 -!- nullbyte [~NSA@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 256 seconds]
10:21 -!- JackH [~Jack@host-80-43-142-154.as13285.net] has joined #bitcoin-wizards
10:25 -!- Mably [56401ec5@gateway/web/freenode/ip.86.64.30.197] has quit [Quit: Page closed]
10:28 -!- p15x_ [~p15x@111.193.165.202] has joined #bitcoin-wizards
10:30 -!- p15x [~p15x@64.145.91.17] has quit [Ping timeout: 265 seconds]
10:34 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards
10:37 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
10:38 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards
10:41 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep]
10:42 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 256 seconds]
10:55 -!- zwick [~zwick@fsf/member/zwick] has joined #bitcoin-wizards
10:55 -!- zwick is now known as fornax
10:55 -!- fornax is now known as zwick
10:58 -!- Mably [~Mably@unaffiliated/mably] has joined #bitcoin-wizards
11:00 -!- zwick is now known as orcus
11:00 -!- orcus is now known as zwick
11:01 -!- zwick [~zwick@fsf/member/zwick] has left #bitcoin-wizards ["WeeChat 1.2"]
11:01 -!- frankenmint [~frankenmi@174-25-28-8.ptld.qwest.net] has joined #bitcoin-wizards
11:02 -!- shen_noe [~shen_noe@wired094.math.utah.edu] has joined #bitcoin-wizards
11:08 -!- mjerr [~mjerr@p578EB7BE.dip0.t-ipconnect.de] has joined #bitcoin-wizards
11:12 -!- nullbyte [NSA@gateway/vpn/mullvad/x-ngmvlguwlaypniph] has joined #bitcoin-wizards
11:15 < frankenmint> What is ASM?  is it the same context as this:https://en.wikipedia.org/wiki/Automatic_Storage_Management?
11:15 -!- eudoxia [~eudoxia@r167-57-48-151.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving]
11:15 < frankenmint> http://mempool.info/tx/35d42e5a44d40c41e0de50d16052f49da67608bb0ce454d11e39def905f0bf3c
11:17 < jcorgan> it's the disassembly of the scriptPubKey binary into opcodes
11:18 < frankenmint> just trying to make sense of the huge mempool
11:18 < frankenmint> (and learn about the inner workings of btc too)
11:29 -!- davi [~davi@gnu/davi] has quit [Ping timeout: 246 seconds]
11:40 -!- Giszmo [~leo@pc-185-201-214-201.cm.vtr.net] has quit [Quit: Leaving.]
11:44 -!- maraoz [~maraoz@2601:647:4a01:25f0:80be:f9dc:5338:e39c] has joined #bitcoin-wizards
11:47 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
12:03 -!- nullbyte [NSA@gateway/vpn/mullvad/x-ngmvlguwlaypniph] has quit [Read error: Connection reset by peer]
12:05 -!- nullbyte [NSA@gateway/vpn/mullvad/x-npkqakzztrzbjmln] has joined #bitcoin-wizards
12:06 -!- Xh1pher [~Xh1pher@pD9E3A97A.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
12:08 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards
12:13 -!- blackwraith [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
12:14 -!- blackwraith [~priidu@unaffiliated/priidu] has quit [Client Quit]
12:14 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 264 seconds]
12:15 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
12:16 -!- priidu is now known as priiduf
12:16 -!- priiduf is now known as priidu
12:18 -!- nullbyte [NSA@gateway/vpn/mullvad/x-npkqakzztrzbjmln] has quit [Ping timeout: 252 seconds]
12:19 -!- maraoz [~maraoz@2601:647:4a01:25f0:80be:f9dc:5338:e39c] has quit [Ping timeout: 248 seconds]
12:20 -!- nullbyte [NSA@gateway/vpn/mullvad/x-ynbrabnovfdxnbxs] has joined #bitcoin-wizards
12:22 -!- jae_ [~jae@75-101-96-71.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection]
12:24 -!- shen_noe [~shen_noe@wired094.math.utah.edu] has quit [Ping timeout: 255 seconds]
12:27 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards
12:29 -!- bramc [~bram@38.99.42.130] has joined #bitcoin-wizards
12:31 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 248 seconds]
12:35 -!- p15x_ [~p15x@111.193.165.202] has quit [Read error: Connection reset by peer]
12:36 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Remote host closed the connection]
12:37 -!- nullbyte [NSA@gateway/vpn/mullvad/x-ynbrabnovfdxnbxs] has quit [Ping timeout: 246 seconds]
12:37 -!- p15x [~p15x@114.248.216.31] has joined #bitcoin-wizards
12:37 -!- shen_noe [~shen_noe@162.216.46.19] has joined #bitcoin-wizards
12:38 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
12:39 -!- nullbyte [NSA@gateway/vpn/mullvad/x-jkcszubbtkxvkjpd] has joined #bitcoin-wizards
12:42 -!- goregrind [~goregrind@unaffiliated/goregrind] has quit [Read error: Connection reset by peer]
12:46 -!- zooko [~user@c-71-229-205-98.hsd1.co.comcast.net] has quit [Ping timeout: 248 seconds]
12:58 -!- goregrind [~goregrind@unaffiliated/goregrind] has joined #bitcoin-wizards
12:59 -!- shen_noe [~shen_noe@162.216.46.19] has quit [Quit: Leaving]
13:01 -!- jae [~jae@204.14.159.153] has joined #bitcoin-wizards
13:01 -!- jae is now known as Guest73286
13:04 -!- nullbyte [NSA@gateway/vpn/mullvad/x-jkcszubbtkxvkjpd] has quit [Ping timeout: 246 seconds]
13:05 -!- spinza [~spin@197.83.246.141] has joined #bitcoin-wizards
13:13 -!- b_lumenkraft [~b_lumenkr@unaffiliated/b-lumenkraft/x-4457406] has quit [Quit: b_lumenkraft]
13:13 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-kcsesyyfuohnlqnf] has quit [Read error: Connection reset by peer]
13:16 -!- maraoz [~maraoz@2601:647:4a01:25f0:80be:f9dc:5338:e39c] has joined #bitcoin-wizards
13:27 -!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has joined #bitcoin-wizards
13:32 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-spthklszzotanhue] has joined #bitcoin-wizards
13:37 -!- zooko` [~user@2601:281:8301:e87f:6451:9685:3e5:5019] has joined #bitcoin-wizards
13:44 -!- shen_noe [~holoirc@172.56.31.49] has joined #bitcoin-wizards
13:44 -!- shen_noe [~holoirc@172.56.31.49] has quit [Remote host closed the connection]
13:59 -!- rubensayshi [~ruben@91.206.81.13] has quit [Ping timeout: 252 seconds]
14:03 -!- hashtagg_ [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has quit [Ping timeout: 248 seconds]
14:04 -!- Guest73286 [~jae@204.14.159.153] has quit [Remote host closed the connection]
14:04 -!- shen_noe [~shen_noe@173-165-135-246-utah.hfc.comcastbusiness.net] has joined #bitcoin-wizards
14:07 -!- drwin [~drwin@88-103-255-166.jes.cz] has quit []
14:08 -!- maraoz [~maraoz@2601:647:4a01:25f0:80be:f9dc:5338:e39c] has quit [Ping timeout: 248 seconds]
14:08 -!- jae [~jae@204.14.159.153] has joined #bitcoin-wizards
14:09 -!- jae is now known as Guest23680
14:09 -!- SwedFTP [~SwedFTP@unaffiliated/swedftp] has quit [Ping timeout: 252 seconds]
14:10 -!- jtimon [~quassel@69.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds]
14:14 -!- zooko` [~user@2601:281:8301:e87f:6451:9685:3e5:5019] has quit [Ping timeout: 248 seconds]
14:15 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards
14:20 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 256 seconds]
14:23 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-dichdcwpuuxpmnpd] has joined #bitcoin-wizards
14:24 -!- SwedFTP [~SwedFTP@unaffiliated/swedftp] has joined #bitcoin-wizards
14:26 -!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has quit [Ping timeout: 246 seconds]
14:27 -!- Guest98688 [~username@5ec3231d.skybroadband.com] has joined #bitcoin-wizards
14:31 -!- Guest98688 [~username@5ec3231d.skybroadband.com] has quit [Client Quit]
14:34 -!- jtimon [~quassel@69.29.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards
14:38 -!- afk11 [~thomas@46.7.4.219] has joined #bitcoin-wizards
14:41 -!- priidu [~priidu@unaffiliated/priidu] has quit [Read error: Connection reset by peer]
14:49 -!- jtimon [~quassel@69.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds]
14:51 -!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has quit [Quit: Leaving.]
14:51 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-spthklszzotanhue] has quit [Ping timeout: 246 seconds]
14:52 -!- dasource [uid48409@gateway/web/irccloud.com/x-swebhduuzcfpbzdz] has joined #bitcoin-wizards
14:52 -!- dc17523be3 [unknown@gateway/vpn/mullvad/x-agtbfkxpufwlpnrj] has joined #bitcoin-wizards
14:52 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte]
14:53 -!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has quit [Ping timeout: 248 seconds]
14:56 -!- flower [~user@189.116.150.203.sta.inet.co.th] has quit [Quit: -]
15:05 -!- Giszmo [~leo@pc-185-201-214-201.cm.vtr.net] has joined #bitcoin-wizards
15:08 -!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has joined #bitcoin-wizards
15:09 -!- XXIII [~XXIII@67.70.121.248] has joined #bitcoin-wizards
15:11 -!- mjerr [~mjerr@p578EB7BE.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds]
15:17 -!- bramc [~bram@38.99.42.130] has quit [Quit: This computer has gone to sleep]
15:21 -!- mats [sid23029@gateway/web/irccloud.com/x-odcymmhqskjwxcdr] has left #bitcoin-wizards []
15:25 -!- Tebbo [~Jerry`@ip72-211-88-176.no.no.cox.net] has quit [Ping timeout: 246 seconds]
15:28 -!- Guest23680 [~jae@204.14.159.153] has quit [Remote host closed the connection]
15:32 -!- jae [~jae@204.14.159.153] has joined #bitcoin-wizards
15:32 -!- jae is now known as Guest9223
15:37 -!- bramc [~bram@38.99.42.130] has joined #bitcoin-wizards
15:42 -!- Mably [~Mably@unaffiliated/mably] has quit [Ping timeout: 244 seconds]
15:43 -!- Guest70571 [~username@5ec3231d.skybroadband.com] has joined #bitcoin-wizards
15:43 -!- Guest70571 [~username@5ec3231d.skybroadband.com] has quit [Client Quit]
15:44 -!- StephenM347 [~stephenm3@static-64-223-246-218.port.east.myfairpoint.net] has quit []
15:44 -!- Guest71065 [~username@5ec3231d.skybroadband.com] has joined #bitcoin-wizards
15:44 -!- JackH [~Jack@host-80-43-142-154.as13285.net] has quit [Ping timeout: 255 seconds]
15:48 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]
15:49 -!- ruby32 [~ruby32@38.121.165.30] has quit [Ping timeout: 252 seconds]
15:49 -!- Starduster [~sd@unaffiliated/starduster] has quit [Ping timeout: 256 seconds]
15:49 -!- shen_noe [~shen_noe@173-165-135-246-utah.hfc.comcastbusiness.net] has quit [Quit: quitquitquit]
15:53 -!- Starduster [~SD@unaffiliated/starduster] has joined #bitcoin-wizards
15:55 -!- erasmospunk [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has joined #bitcoin-wizards
15:57 -!- bramc [~bram@38.99.42.130] has quit [Quit: This computer has gone to sleep]
15:58 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards
16:00 -!- hashtag [~hashtag@cpe-69-23-213-3.ma.res.rr.com] has joined #bitcoin-wizards
16:01 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards
16:02 -!- Zooko-phone [~androirc@2600:100e:b004:b82a:64cd:7754:92c:837c] has joined #bitcoin-wizards
16:04 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards
16:04 -!- Guest71065 [~username@5ec3231d.skybroadband.com] has quit [Quit: Leaving]
16:05 -!- hashtag [~hashtag@cpe-69-23-213-3.ma.res.rr.com] has quit [Ping timeout: 255 seconds]
16:06 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 248 seconds]
16:18 -!- afk11 [~thomas@46.7.4.219] has quit [Ping timeout: 240 seconds]
16:21 -!- hashtag [~hashtag@cpe-69-23-213-3.ma.res.rr.com] has joined #bitcoin-wizards
16:23 -!- rubensayshi [~ruben@92.110.255.64] has joined #bitcoin-wizards
16:30 -!- erasmospunk [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has quit [Remote host closed the connection]
16:33 -!- afk11 [~thomas@168.1.75.56-static.reverse.softlayer.com] has joined #bitcoin-wizards
16:37 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
16:37 -!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has joined #bitcoin-wizards
16:39 -!- dEBRUYNE [~dEBRUYNE@239-196-ftth.onsbrabantnet.nl] has quit [Ping timeout: 240 seconds]
16:42 -!- Zooko-phone [~androirc@2600:100e:b004:b82a:64cd:7754:92c:837c] has quit [Ping timeout: 248 seconds]
16:49 -!- dabura667 [uid43070@gateway/web/irccloud.com/x-pnoouoouuzmbphbt] has joined #bitcoin-wizards
16:51 -!- n9270 [~user7540@94.197.121.110.threembb.co.uk] has joined #bitcoin-wizards
16:55 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
16:58 -!- n9270 [~user7540@94.197.121.110.threembb.co.uk] has left #bitcoin-wizards []
16:58 -!- Zooko-phone [~androirc@2600:100e:b027:aad8:1f69:fdb7:229f:d74a] has joined #bitcoin-wizards
17:01 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
17:05 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards
17:07 -!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has quit [Quit: Leaving.]
17:08 -!- afk11 [~thomas@168.1.75.56-static.reverse.softlayer.com] has quit [Ping timeout: 256 seconds]
17:10 -!- rubensayshi [~ruben@92.110.255.64] has quit [Remote host closed the connection]
17:14 -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has joined #bitcoin-wizards
17:15 -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has quit [Max SendQ exceeded]
17:16 -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has joined #bitcoin-wizards
17:22 -!- p15x_ [~p15x@64.145.91.16] has joined #bitcoin-wizards
17:23 -!- p15x [~p15x@114.248.216.31] has quit [Ping timeout: 248 seconds]
17:25 -!- harrow [~harrow@105.ip-167-114-152.net] has quit [Ping timeout: 248 seconds]
17:28 -!- afk11 [~thomas@178.162.211.213] has joined #bitcoin-wizards
17:30 -!- jtimon [~quassel@69.29.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards
17:30 -!- p15x [~p15x@64.145.91.32] has joined #bitcoin-wizards
17:32 -!- p15x_ [~p15x@64.145.91.16] has quit [Ping timeout: 256 seconds]
17:47 -!- cryptoreach [~Kevin@90.192.38.248] has joined #bitcoin-wizards
17:49 -!- cryptoreach is now known as reach4thelasers
17:59 -!- c0rw1n is now known as c0rw|zZz
18:01 -!- bendavenport [~bpd@96.90.231.161] has quit [Quit: bendavenport]
18:03 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-wizards
18:10 -!- bramc [~bram@38.99.42.130] has joined #bitcoin-wizards
18:12 -!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has quit [Ping timeout: 240 seconds]
18:12 -!- sadoshi [~Sadoshi@31.220.4.123] has quit [Remote host closed the connection]
18:13 -!- sadoshi [~Sadoshi@31.220.4.123] has joined #bitcoin-wizards
18:14 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds]
18:15 -!- shen_noe [~shen_noe@173-165-135-246-utah.hfc.comcastbusiness.net] has joined #bitcoin-wizards
18:23 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Remote host closed the connection]
18:24 -!- alewis_btc [~antonylew@101.100.162.252] has joined #bitcoin-wizards
18:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
18:30 -!- shen_noe [~shen_noe@173-165-135-246-utah.hfc.comcastbusiness.net] has quit [Quit: quitquitquit]
18:30 -!- bramc [~bram@38.99.42.130] has quit [Quit: This computer has gone to sleep]
18:35 -!- Zooko-phone [~androirc@2600:100e:b027:aad8:1f69:fdb7:229f:d74a] has quit [Ping timeout: 248 seconds]
18:36 -!- shen_noe [~shen_noe@173-165-135-246-utah.hfc.comcastbusiness.net] has joined #bitcoin-wizards
18:36 -!- shen_noe [~shen_noe@173-165-135-246-utah.hfc.comcastbusiness.net] has quit [Client Quit]
18:38 -!- ruby32 [~ruby32@ool-4354b58f.dyn.optonline.net] has joined #bitcoin-wizards
18:40 -!- ruby32 [~ruby32@ool-4354b58f.dyn.optonline.net] has quit [Client Quit]
18:50 -!- jtimon [~quassel@69.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds]
18:52 -!- Dr-G [~Dr-G@xd9bf704c.dyn.telefonica.de] has joined #bitcoin-wizards
18:52 -!- Dr-G [~Dr-G@xd9bf704c.dyn.telefonica.de] has quit [Changing host]
18:52 -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards
18:54 -!- frankenmint [~frankenmi@174-25-28-8.ptld.qwest.net] has quit []
18:54 -!- Tebbo [~Jerry`@ip72-211-88-176.no.no.cox.net] has joined #bitcoin-wizards
18:55 -!- Dr-G2 [~Dr-G@x4d08dbc8.dyn.telefonica.de] has quit [Ping timeout: 256 seconds]
18:57 -!- dabura667 [uid43070@gateway/web/irccloud.com/x-pnoouoouuzmbphbt] has quit [Quit: Connection closed for inactivity]
18:58 -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards
18:59 -!- maaku is now known as Guest22663
18:59 -!- maaku_ [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Ping timeout: 264 seconds]
19:00 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
19:24 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards
19:29 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 265 seconds]
19:54 -!- afk11 [~thomas@178.162.211.213] has quit [Ping timeout: 264 seconds]
19:58 < dgenr8> <CodeShark> then perhaps we can cut down the number of global commitments even further
19:58 < dgenr8> global commitments are not the problem.  the merkle tree allows effectively unlimited commitments, all guaranteed directly by the full network proof of work
19:58 < dgenr8> the problem, if there is one, is various parties who would like to keep up with all this activity, being able to do so
20:02 -!- p15x_ [~p15x@64.145.91.75] has joined #bitcoin-wizards
20:04 -!- p15x [~p15x@64.145.91.32] has quit [Ping timeout: 264 seconds]
20:11 -!- afk11 [~thomas@46.7.4.219] has joined #bitcoin-wizards
20:16 -!- afk11 [~thomas@46.7.4.219] has quit [Ping timeout: 252 seconds]
20:19 -!- p15x [~p15x@64.145.91.82] has joined #bitcoin-wizards
20:20 -!- p15x_ [~p15x@64.145.91.75] has quit [Ping timeout: 250 seconds]
20:24 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 246 seconds]
20:26 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards
20:26 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
20:28 -!- afk11 [~thomas@46.7.4.219] has joined #bitcoin-wizards
20:30 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 248 seconds]
20:40 -!- harrow [~harrow@105.ip-167-114-152.net] has joined #bitcoin-wizards
20:42 -!- alewis_btc [~antonylew@101.100.162.252] has quit [Quit: alewis_btc]
20:45 -!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has joined #bitcoin-wizards
20:47 -!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has joined #bitcoin-wizards
20:49 -!- jlrubin [~jlrubin@mass-toolpike.mit.edu] has joined #bitcoin-wizards
20:51 < jlrubin> Oops I realize I'd been asking about my more theoretical 2 phase commit idea oon -dev rather than here...
20:53 < amiller> jlrubin, what about it?
20:54 < jlrubin> What do you all think about https://gist.github.com/JeremyRubin/1a3260431b3ee4afbaa0
20:54 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-dichdcwpuuxpmnpd] has quit [Quit: Connection closed for inactivity]
20:55 < jlrubin> (sorry for the delay, meant to send back2back but got cut off. Chinese internet man...
20:55 < jlrubin> )
20:56 < jlrubin> I realize that there are definitely large flaws in such a change, but I'm curious because a phased commit structure might have some other uses that are interesting to cryptocurrency.
20:57 < amiller> jlrubin, my first concern is you can include an invalid transaction or a txhash for which there is no corresponding preimage
20:57 < amiller> jlrubin, if you never reveal those transactions, can't subsequent miners just keep building on your block and get stuck?
20:57 < jlrubin> Yes
20:57 < jlrubin> but then
20:57 < jlrubin> they can just set a pointer below it
20:57 < jlrubin> and it will never be considered valid
20:58 < jlrubin> The block does not need full acceptance.
20:59 -!- RH311ish [~RH311ish@65.78.60.74] has quit [Read error: Connection reset by peer]
21:05 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
21:05 < amiller> jlrubin, does the first step even accomplish anything
21:06 < amiller> how about if instead of a pointer to a previous block, i just include the hash of a transaction to 'confirm' it
21:07 < amiller> this doesn't seem to have much in common with two-phase-commit
21:07 < jlrubin> formally would accomplish the same thing, but less efficient implementation
21:07 < jlrubin> It does
21:07 < jlrubin> Think of first write as a journaling phase
21:09 < jlrubin> and you write a checksum of the data at that point. Then, you begin to write to disk by broadcasting the transactions for that header. '
21:09 < jlrubin> On "crash" (or not enough network bandwidth compared to mining time, it leaves the disk in a consistent state
21:11 < jlrubin> amilller: that's why I feel it is similar to 2 phase commit. Different from a typical "full abort" though
21:22 -!- p15x_ [~p15x@64.145.91.36] has joined #bitcoin-wizards
21:23 -!- p15x [~p15x@64.145.91.82] has quit [Ping timeout: 256 seconds]
21:24 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
21:29 < amiller> jlrubin, if a transaction isn't committed in the next block, can it be resubmitted again?
21:36 -!- bblue [~textual@104.220.67.131] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
21:40 < jlrubin> yes/no
21:40 < jlrubin> In theory it's still in mempool then
21:41 < jlrubin> so the next miner will try to commit it
21:41 < jlrubin> * include, not commit
21:42 < jgarzik> amiller, it is the client's responsibility to resubmit until confirmation
21:42 < jgarzik> amiller, of course, your network nodes will ignore that resubmit if they've already seen it
21:43 < jlrubin> jgarzik:his comment is in reference to the gist I shared earler, not sure if you caught it
21:43 < jgarzik> ah, didn't see that in scrollback, sorry
21:44 < jlrubin> https://gist.github.com/JeremyRubin/1a3260431b3ee4afbaa0 for reference
21:45 < jgarzik> jlrubin, just read it - my comments appear to be applicable
21:45 < jlrubin> amiller: in theo also, if it is in mempool then the miner should have comitted it so maybe it isn't there, and would need more broadcasting as per jgarziks comment
21:46 < jlrubin> jgarzik: yep, they are, but I figured you missed it ;)
21:46 < amiller> i'm still trying to figure out what having it 'precomitted' in a block accomplishes
21:46 < amiller> it guarantees that *if accepted in the next block* that they'd be in a particular order
21:47 < jlrubin> That's not the focus
21:47 < jlrubin> the focus is to decouple mining from other bottlenecks
21:47 < gmaxwell> jlrubin: I am unable to determine from this document what utility this scheme has. In particular the phrase "double spend" does not occure in it, so I cannot tell what-- if any-- role these scheme intends to play in the fundimental purpose of the blockchain.
21:49 < jlrubin> gmaxwell: no fundamental role, but then again, neither do merkle trees either or script etc. This is inteneded to help better utilize network resources.
21:50 < gmaxwell> jlrubin: better utilizae resource by potentially decreasing goodput? (sending block data which will subsiquently be ignored?)
21:50 < jlrubin> Ah no
21:50 < jlrubin> 'well
21:50 < jlrubin> yes; in that you would also need to broadcast bits and pieces of the merkle tree for proofs which reduces goodput
21:51 < gmaxwell> I don't think thats necessary for what you're describing in fact.
21:51 < gmaxwell> other than a single stroke for truncation.
21:51 < jlrubin> but the transactions to 'the right' of the pointer are not broadcast
21:52 < jlrubin> gmaxwell: it is necessary to make it a "streaming" proof
21:52 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds]
21:52 < gmaxwell> jlrubin: consider, someone makes a 1MB block. then the next miner sets the pointer to 0  and moots the content of that block-- that was 1 MB sent without moving the system forward.
21:52 < gmaxwell> (1MB to roughly every particiapant)
21:53 < jlrubin> Sure; but that would suggest they didn't get that block actually
21:54 < jlrubin> gmaxwell: I think I mention an incentive for nonzero pointer maybe being needed
21:54 -!- alewis_btc [~antonylew@101.100.162.252] has joined #bitcoin-wizards
21:54 < gmaxwell> But everyone else may well have. And; it seems according to 'Antagonistic Pointer Selection' those transaction then can never be included?  How do you know if you accidentally included a transaction which you just hadn't previously fetched?
21:55 < gmaxwell> Well obviously non-zero wouldn't be sufficient, as one could just set it to 1.
21:56 < jlrubin> gmaxwell: "previously fetched"?
21:56 < gmaxwell> (but I'm trying to understand at a higher level what this is intending to accomplish)
21:56 < jlrubin> Ah
21:56 < jlrubin> let me jump back a bit then
21:56 < jlrubin> Right now, mining is tightly coupled to resource allocation
21:56 < gmaxwell> jlrubin: someone creates a 1MB block. You only recieve the first 500k.  Then you create a block pointing halfway into it, and include a duplicate transaction with the latter 500k (seems quite likely).
21:57 < gmaxwell> jlrubin: Expand on what you mean by "tightly coupled to resource allocation"
21:57 < jlrubin> Yes that is the intent, however one of my hopes (and mentioned in the pointer allocation bit) is that a pointer "filter" could minimize this but I don't know a good masking pointer algorithm
21:58 < jlrubin> A miner, when creating a block, has to gauge carefully if the network will be able to work with that block
21:58 < jlrubin> ie, Disk, Network Bandwitch, CPU for Crypto
21:59 < gmaxwell> jlrubin: I don't believe thats actually correct.
21:59 < jlrubin> by changing it to something like what I am proposing, they always try to make it as-big-as-possible
21:59 < jlrubin> and then stream it to the network
21:59 -!- p15x_ [~p15x@64.145.91.36] has quit [Quit: Textual IRC Client: www.textualapp.com]
21:59 < gmaxwell> Today, using state of the art softwhere here is what the transmission of a block looks like:
22:00 -!- p15x [~p15x@64.145.91.36] has joined #bitcoin-wizards
22:00 < jlrubin> Sure, today miners perform this function by fixing the size to 1mb
22:00 < jlrubin> this is with the idea that you would want blocks larger than 1mb
22:00 < jlrubin> so it's a dynamic sizing idea
22:01 < jlrubin> (but I'm interested to see the transmission stats)
22:01 < gmaxwell> jlrubin: no, the 1MB constrain does not have anything to do with miners; it's enforced by all full nodes, which are not paid for their activities and need to keep up auditing the system to align the economic incentives of miners.
22:01 < jlrubin> Yes, correct.
22:03 < gmaxwell> So what actual block transmission with state of the art software looks like is this:  I send you a list of few (e.g. 2) byte indexes into a an array of transactions that had been shared or rumored previously between us (over the lats hours), plus a small number of transactions that hadn't yet made it across. You reconstruct the block compute the hashroots. You do no signature validation, as it's
22:03 < gmaxwell> all cached, except for the small amount of new transactions.
22:04 -!- zooko [~user@2601:281:8301:e87f:ac9c:6bd5:8df9:2016] has joined #bitcoin-wizards
22:04 < gmaxwell> There is linearity there that can-- in theory, with fancier protocols-- be eliminated... but it's very small owing to the constant factors.
22:04 < jlrubin> gotcha
22:04 < jlrubin> I thought it wasn't yet amortized as such.
22:04 < jlrubin> By reconstruct
22:05 < jlrubin> you are refering to invertable bloom?
22:05 < jcorgan> gmaxwell: is there a name i can google on for prior discussions of the concept you just described?
22:05 < jgarzik> it is low hanging fruit to avoid sending transactions twice (once at initial broadcast, and second when it appears in a block).   the metadata needed to reconstruct a block is quite small, even without IBLT.
22:05 < jgarzik> larger blocks of course slow down sync'ing nodes which are not caught up
22:06 < gmaxwell> No. This is the relay network protocol; it's implemented here https://github.com/TheBlueMatt/RelayNode/tree/master/client  Most of the hashpower uses it.
22:06 < jlrubin> I thought it's about full nodes not hashpower ;)
22:07 < gmaxwell> jlrubin: lets rewind what you said above.
22:07 < gmaxwell> 22:00 < jlrubin> A miner, when creating a block, has to gauge carefully if the network will be able to work with that block
22:07 -!- Emcy [~MC@unaffiliated/mc1984] has quit [Read error: Connection reset by peer]
22:07 < gmaxwell> Miners don't care if some fraction full nodes fall behind-- they'll continue to produce the longest valid chain.
22:07 < jlrubin> sure
22:08 < jlrubin> but if they make a block too large to propagate
22:08 -!- mjerr [~mjerr@p578EB7BE.dip0.t-ipconnect.de] has joined #bitcoin-wizards
22:08 < gmaxwell> And they don't need to suffer any of these latency mediated sizing concerns due to the use of efficient relay.
22:08 < gmaxwell> jlrubin: there is no such thing. As I pointed out, the block does not propagate "in the raw", it can be transmitted efficiently.
22:08 < gmaxwell> (and is, in practice, most of the time)
22:09 < jlrubin> That's a best case though, in the worst case it is orthogonal
22:09 < jlrubin> Perhaps that forcing for non-orthogonal is good for getting txns in
22:09 < gmaxwell> Beyond that, to the extent that there is a loss related to propagation miners can eliminate that loss by pooling (which was what drove the development of the efficient relaying software; to reduce the incentive do to that)
22:09 < phantomcircuit> jlrubin, the average case and the best case are very similar in practice
22:10 < gmaxwell> jlrubin: Well, I'm trying to spare you from wasting your time on trying to optimize a toy case that doesn't even reflect reality today. :)
22:11 < jlrubin> gmaxwell: appreciated
22:11 < gmaxwell> I think you fundimentally misunderstand what the purpose of having a limited blocksize is, it isn't to arbritrate things between miners-- if miners wanted they could simply refuse to extend blocks they though were too big to handle, and through that mechnism enforce a defacto blocksize which is acceptable to at least half the hashpower (though that would be rather messy)
22:12 < gmaxwell> Miners have substantial income which can be used to pay for resources to process transactions as well, or (unfortunately) can amortorize all validation and propagation costs to almost nothig (one shared system for the whole world) by pooling.
22:12 < jlrubin> gmaxwell: I think there are differing schools of thoughts on that
22:13 < jlrubin> gmaxwell: that's no good if only one validator
22:13 < gmaxwell> On what in particular? at least the factual points I'm making are really not disputable.
22:13 < gmaxwell> E.g. that combining into a single validator reduces the total validation costs to a small constant, and that it eliminates propagation related costs between miners.
22:13 < jlrubin> gmaxwell: I think the two major schools are "scarcity of txns is good", "abundance of txns is good"
22:13 < gmaxwell> It is highly undesirable, I agree.
22:14 < gmaxwell> I have not expressed any opinion on that subject.
22:14 < gmaxwell> (in this discussion)
22:15 < jlrubin> I thought that's where you were leding to with "fundamental purpoe of limited blocksize"
22:15 < gmaxwell> (and I don't see how it connects but if I were to express an opinion I don't see how it can be other than an abundance is great-- assuming all other things equal!)
22:15 -!- sneak [~sneak@unaffiliated/sneak] has quit [Ping timeout: 256 seconds]
22:15 < jlrubin> Well
22:16 -!- sneak [~sneak@2a01:4f8:141:ffc:c5db:4d1f:b28c:ad8b] has joined #bitcoin-wizards
22:16 < jlrubin> From what I've heard, some people feel that scarcity of transactions is good otherwise miners won't be paid in the future
22:16 < gmaxwell> jlrubin: No the primary purpose is to preserve a system that other parties will audit, which is essential to the assumption of honesty on the part of the anonymous self-selecting miners; secondarily avoiding keeping the costs which can be perfectly amortized via centeralization from dominating. There are orther arguments, but I think they're unrelated to this discussion right now.
22:16 -!- sneak [~sneak@2a01:4f8:141:ffc:c5db:4d1f:b28c:ad8b] has quit [Changing host]
22:16 -!- sneak [~sneak@unaffiliated/sneak] has joined #bitcoin-wizards
22:17 < jlrubin> Yes, so part of pointer selection, as mentioned in proposal, is also validation costs
22:18 < gmaxwell> jlrubin: well I'm leaving long term questions aside. There is a long term issue about what pays for POW in the future, if all costs are going to verification ... POW is open loop and can adapt to zero; but ... I think thats an independant question from the rest.
22:18 < jlrubin> agreed
22:19 < gmaxwell> jlrubin: Almost no resource are spent on validation is performed at the time a block is broadcast, the costly parts have already been performed.
22:19 < jlrubin> Well that's a artifact of current sizes
22:19 < rusty> gmaxwell: that's more true with IBLT, where there's pressure to match the expected block contents.
22:20 < gmaxwell> jlrubin: I am not following what you're thinking there.
22:21 < jlrubin> Ie, if the number of tps a node gets goes up, overlap would be less likely and harder to enforce
22:21 < gmaxwell> jlrubin: to be included in a block a transaction must be sent to the network. Doing so also primes the caches from the participating system, allowing them to take validation out of the cricial, highly latency sensitive path of block relay.
22:21 < jlrubin> Ie, flood node A with X1, flood node b with set X2
22:21 < jlrubin> will keep them orthogonal
22:22 < gmaxwell> jlrubin: I don't know why you believe this, the requirement is one sided-- so for example you can delay including a block in your template until a second after you've recieved it, in order to ensure that it will have achieved comprehensive forwarding and validation.
22:22 < gmaxwell> replace "including a block" with "including a transaction"
22:22 < jlrubin> gotcha, was confused
22:23 < jlrubin> I think that's fair
22:23 < jlrubin> You can ping your other miners too
22:23 < jlrubin> asking if they got that one/forwarding it
22:23 < jlrubin> but the problem is
22:23 < jlrubin> at a certain saturation point
22:24 < jlrubin> you still cause a latency partition
22:24 < jlrubin> ie, littles law. the ones coming out of the queue will be there for a while
22:25 < jlrubin> so if one queue is [x1, x2] and the other [x2, x1] then you are likely to mine a block while orthogonal
22:25 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards
22:26 < jlrubin> so I think the "real world case" while it can be used (ie, most pointers should be 100%), having a byzantine fallback is good IMO
22:26 < gmaxwell> If you exceede the throughput capability of the other miners overall, then yes the system will backlog.  Though at that level verification costs have become quite substantial and other problems dominate:  Non-miners cannot afford to audit, reducing the incentive to conform to the protocol for miners among other issues, and miners can make significant cost reductions by centeralizing.
22:27 < gmaxwell> jlrubin: perhaps, if it doesn't open new attacks (otherwise its an improvement in a case which should be rare or which the system would have already failed in; which might open a more pratical attack).
22:28 < jlrubin> Miners could pool their peers for recommended pointer
22:28 < gmaxwell> so going to my earlier question say block X sets the pointer at 50%.  later X includes transactions that were in the latter 50%  ... or perhaps block >X does?  the proposal seems to prohibit this, which sounds bad, but also I don't see how this can be enforced efficiently without assuming hosts would have obtained the data in that latter half.
22:28 < jlrubin> Ah
22:28 < jlrubin> No it isn't forbididden
22:29 < jlrubin> more noted that
22:29 < gmaxwell> also given the above desynchronization between validation and blocks, I am not sure that a pointer in to a particular blocks tree is likely to meaningfully map to the validation work any participant has done.
22:29 < jlrubin> A possible attack is lying about what you put in
22:29 < gmaxwell> jlrubin: okay if it isn't forbidden, why isn't this a free mechenism to steal transaction fees?
22:29 < jlrubin> but lying creates a proof of lying
22:30 < jlrubin> which could be used to reject such blocks
22:30 -!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 256 seconds]
22:30 < gmaxwell> I am not following you now. Who is lying about what at what point?
22:30 < jlrubin> A puts abcdefgh into a block
22:31 < jlrubin> B commits ab, then says my new block is cdefxyz
22:32 < jlrubin> The block could be treated as invalid because they could have selected cdef
22:32 < gmaxwell> Right B did not fetch all of A's block and has no idea whats in it beyond ab.  Both parties behaved honestly.
22:32 < jlrubin> well no
22:32 < jlrubin> they had cdef
22:32 < gmaxwell> If it would be invalid in that case then B was obligated to fetch the whole thing all along.
22:32 < jlrubin> so they were not honest
22:32 < jlrubin> becsue they should have updated their pointer
22:34 < gmaxwell> This would have required them to obtain the complete list of transactions from A, rather than a log() scale hashtree prefix proof.
22:35 < gmaxwell> So now B must recieve O(N) IDs. There is no need to send tree fragments, since you can reconstruct the root hash from the full list. (the talk of hashtrees is why I assumed your scheme did not require transmitting the full list)
22:35 < jlrubin> (I should note, proposal is far from complete, sections like this were more of an attempt to consider design space and weaknesses)
22:36 < jlrubin> I think a better prevention of fee stealing is splitting the fee with the next miner
22:37 < gmaxwell> jlrubin: it's not clear that any kind of fee sharing scheme is workable; old result.  The problem is that participants can pay fees 'out of band'  e.g. by just using a dedicated output or via other mechenisms, and this is actually widely done in bitcoin today: many large miners have tx processing deals.
22:38 < gmaxwell> maybe in this case it would fly because those deals would just have to also split or otherwise partiicpants will set the pointer low.
22:40 < jlrubin> yep
22:40 < jlrubin> It can even be set such that there is no fee for mining a block
22:40 < jlrubin> only for the pointer selection
22:41 < jlrubin> replace mining a block with including txns
22:41 < gmaxwell> okay, so next issue. So txn A goes in in block a,  then in block B, pointer is tet to exclude A and instead the double spend A' is included. So in this case the first block does not provide protection against double spend. The second does, if it doesn't set too low a pointer. From the user's perspective; why not just have their transaction accepted in the second block when it was widely enough di
22:41 < gmaxwell> stributed to be accepted, as it could have been doublespent until that point in any case?
22:42 < gmaxwell> well if there is no fee for mining a block, why would I bother including any transactions at all? or rather, why not fill up all my lists with 'transactions' storing your banned pornography collection in the blockchain, which you're paying me on the side to do? :P
22:43 -!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has quit [Ping timeout: 256 seconds]
22:43 < jlrubin> hah!
22:43 < jlrubin> So the game theory would work out such that
22:43 < jlrubin> if you include no txns
22:43 < jlrubin> no one would mine your block!
22:43 < jlrubin> No reward
22:44 < jlrubin> (I think sharing is better, but I think the curve can go to that point and work out)
22:44 < gmaxwell> jlrubin: lets assume, for a second, that I have 50% hashpower.  Now the actual nodes are going to follow whatever chain I'm on. So no reward elsewhere either! :)
22:45 < jlrubin> Let's not pretend you have 50%
22:45 < gmaxwell> this also applies if I have less
22:45 < jlrubin> Tht would be the least of the problems ;)
22:45 < gmaxwell> say I have 20%, someone extends me still has an advantage in being in the longest chain, so I could include transactions inversely proportional to my hashrate and still get in the chain.
22:46 < gmaxwell> and with the rest of my capacity, include 0 fee transactions where I am paid under the table.
22:46 < jlrubin> I think the meta-reason on why commit is more valuable than include is that for include you are saying one person knows this, on include you are saying the network knows this (more likely)
22:46 < gmaxwell> (or at least very low fee) That would be an efficient strategy.
22:46 < jlrubin> (for why fees could go to commit)
22:47 < gmaxwell> Esp if the other data is not bitcoin transactions but some other data packed in.
22:47 < jlrubin> gmaxwell: re your earlier question, this is an attempt to define a byzantine tolerant notion of "enough distribution'
22:47 < gmaxwell> (e.g. it may not care if it ever gets the commitment pointer)
22:48 < jlrubin> Yes; other data may not care
22:48 < gmaxwell> jlrubin: so on that point, you only go finitely deep here. It's two party, and so I think your scheme is actually isomorphic to selection by the second miner, though not quite because you've reduced his degree of freedom slightly.
22:49 < jlrubin> reduced whose?
22:50 < gmaxwell> As I was saying before, from the users perspective he is not confirmed (protected from double spends) at all until a second block sets a pointer past him. So he might as well just wait to be in the second block to begin with (from his perspective).  E.g. the first phase bought him nothing of value.
22:50 < jlrubin> gmaxwell: I'm not sure on the exact mechanics, but I think the easy answer is don't put the ratio fixed, let the miner chose the amount of fee to give to the next miner
22:51 < jlrubin> Well
22:51 < jlrubin> same is true for 1 block now anyways
22:52 < jlrubin> and, assuming a linear pointer (not a mask), then you get more confidence the earlier in the tree you re
22:52 < gmaxwell> No, not quite, when someone decides to not accept a block they lose the advantage of its work and start at a very costly disadvantage against it.
22:52 < gmaxwell> So to say there is an equivilence I believe you must at least linearly derate the work credited for the prior block when the pointer is moved back.
22:53 < gmaxwell> (and probably worse than linear because fees are not homogenous)
22:53 < jlrubin> Can you say that in other words
22:53 < jlrubin> "lineraly derate the work credited"
22:55 < gmaxwell> Sure. right now I am a miner and I can choose to extend block X or mine a fork at X'.   If I choose to extend X I take all thats in it even if I'd like to censor some of it or take some of its fees.  If I fork, I can censor at will and take fees at will.. BUT I start a whole block behind, the network has progress on me, and I am quite likely to be unsuccessful unless my hashrate is substantial co
22:55 < gmaxwell> mpared to the network's.
22:56 < gmaxwell> Now in your scheme as I understand it,  I could set the backpointer to a low value and take some (or maybe all) of X's transactions and replace them with conflicts, or censor or maybe steal fees (however you work out fees, not clear, but regardless I can still censor)  and yet I gain the consensus-success advantage of having built on X.
22:56 < jlrubin> yes
22:56 < jlrubin> near the end of the proposal
22:57 < jlrubin> I discuss this a little
22:57 -!- akrmn [~akrmn@192.95.51.167] has joined #bitcoin-wizards
22:57 < gmaxwell> So to make these cases equivilent I think that when I reduce the pointer when I build on X you must dededuct a proportion of X's weight. And if all fees were the same it would need to be at least linear to make that equivilent.
22:57 < jlrubin> i guess not explicitly
22:58 < jlrubin> but what I discuss with n-phase
22:58 < gmaxwell> But fees are not all homogenous, and presumably the higehst fees are first, so the deduction has to be faster than linear to make it equal otherwise lower fee txn are not protected by inclusion in a block with higher ones.
22:58 < jlrubin> would distribute the pointer selection more
22:58 < jlrubin> such that one bad miner wouldn't spoil it
22:59 < gmaxwell> I didn't read that part; though I do not understand how you'd address conflicts in such a scheme.
23:00 < jlrubin> ie, imagine needing 3 commits
23:00 < gmaxwell> E.g. X includes abcd  X+1 confirms ab and includes c' d' efg   (where ' denotes a conflicting alternative).   then X+2 does what? he cannot confirm more of a without undoing the effect of B'c confirmation.
23:00 < jlrubin> and you sect the middle size'
23:00 < jlrubin> So you have the following properties needed (for 3 blocks)
23:01 < jlrubin> No spends on a txn in the window
23:01 < jlrubin> (ie, 6 block wait)
23:01 < gmaxwell> (and so in that case I think poor user observing all this doesn't get his first resistance to double spends until the third block; and again he is asking why not dispense with all this and just put his transaction in the third block after its good and propagated :) )
23:01 < jlrubin> Pointer can only monotonicly decrease
23:02 -!- p15x_ [~p15x@64.145.91.94] has joined #bitcoin-wizards
23:02 < jlrubin> Well so the point is a byzantine tolerant propogation proof
23:02 < gmaxwell> jlrubin: well that gives more miners more ability to censor transactions they do not like.
23:02 < jlrubin> So yes, give me one of those
23:02 < jlrubin> and then just put it in the t-0th block ;)
23:02 < gmaxwell> So you have increased tolerance for one kind of fault at the expnse of making it massively easier to obstruct.
23:02 < jlrubin> Well so that's the poit of the "middle " size
23:03 -!- p15x [~p15x@64.145.91.36] has quit [Ping timeout: 240 seconds]
23:03 < gmaxwell> (which seems like a common tradeoff in threshold signatures; the ability to unilatterally cause action is always in tension with the ability to unilatterally block an action)
23:03 < gmaxwell> jlrubin: I don't see how middle of several blocks meets your monotone critera.
23:04 < jlrubin> Yeah I was just typing that
23:04 < jlrubin> realized it violates
23:04 < jlrubin> perhaps "not larger than the first commit"
23:05 < jlrubin> double spends from the rejected pointer block could be ignored
23:05 < jlrubin> (but that adds complexity.... not very elegant)
23:05 < gmaxwell> right so in any case, this indeed creates a trade-off where it becomes cheaper to unilatterally block action, at the expense of transactions neeing to wait longer for confidence in their state to build.
23:06 < gmaxwell> and I think we do already have this, in the aggreate. For example, imagine that every block had just one transaction. I think your scheme and bitcoin are identical in that case.
23:06 -!- cryptoreach [~Kevin@90.192.38.248] has joined #bitcoin-wizards
23:06 < jlrubin> Correct, that is equivalent
23:06 < jlrubin> minus the work argument you raised prior
23:06 < gmaxwell> (Actually your scheme with N infinity and linear deduction penalities, and a bunch of other handwaving to ignore discontinuities)
23:07 < gmaxwell> (and constant fees and so on)
23:07 -!- shen_noe [~shen_noe@172.56.31.125] has joined #bitcoin-wizards
23:07 < gmaxwell> jlrubin: I think most of us have considered the shared fate in blocks and the ability to unilaterally cause action to be critical censorhsip resistant properties in bitcoin. So I'm not sure that fixing them is desirable.
23:08 -!- reach4thelasers [~Kevin@90.192.38.248] has quit [Ping timeout: 246 seconds]
23:08 < jlrubin> I think you are correct in that trade-off, and I agree that it is not desired
23:08 < gmaxwell> (actually I'm working on some work that will make that property much stronger)
23:09 < jlrubin> great :)
23:10 < jlrubin> I have to run -- thank you for taking the time to go through this with me.
23:11 < jlrubin> I still think that there may be something interesting which a multiple phase rule could be used for, and perhaps there are solutions to the censorship tradeoff.
23:12 < gmaxwell> Yea maybe! interesting discussion. Thanks.
23:14 < jlrubin> Excited to hear about your new work -- any links for reading available?
23:14 < gmaxwell> (As a parting thought-- consider my expample from the user perspective, and also consider the efficient relaying meaning that the blocks only have to be small enough to stay within a throuput bound (so long as we don't care about auditing or decenteralization). ... might want to think about how your scheme is superior to miners deciding how big the next block can be; rather than expostfacto decid
23:14 < gmaxwell> ing how big the prior really was)
23:14 < gmaxwell> jlrubin: not yet.
23:15 -!- mjerr [~mjerr@p578EB7BE.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
23:15 < jlrubin> Yeah, I have a draft sitting in my todo pile of an idea to force validation.
23:15 < jlrubin> It's high overhead
23:15 < jlrubin> but the general idea is
23:16 < jlrubin> chaffing in bad transactions
23:16 < jlrubin> and making the next miner include a filter for the wheat transactions
23:16 < jlrubin> (I really like two phase if you couldn't tell ;) )
23:17 < jlrubin> If the chaffe can be such that a miner has to check the whole block to know, it can put (hoepfully) sufficient pressure to validate fully
23:17 < jlrubin> but maybe, you know, they will have learned the lesson this time
23:19 -!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has joined #bitcoin-wizards
23:20 -!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has quit [Read error: Connection reset by peer]
23:20 < gmaxwell> jlrubin: ah, well man of my own heart, I had suggested requiring miners commit to a both a good block and a bad block; in order to make fraud proofs that actually worked... but generally most people regard that kind of thing as crazy.
23:20 -!- shen_noe [~shen_noe@172.56.31.125] has quit [Quit: quitquitquit]
23:21 -!- Mably [~Mably@unaffiliated/mably] has joined #bitcoin-wizards
23:22 -!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has joined #bitcoin-wizards
23:22 -!- Guest9223 [~jae@204.14.159.153] has quit [Remote host closed the connection]
23:23 < jlrubin> Ah, I see :)
23:24 < jlrubin> The extreme is Peter Todd's "just mine the raw bytes, let the client decide what it means"
23:32 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards
23:34 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds]
23:39 -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards
23:40 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]
23:47 -!- Xh1pher [~Xh1pher@pD9E3A97A.dip0.t-ipconnect.de] has joined #bitcoin-wizards
23:52 -!- Mably [~Mably@unaffiliated/mably] has quit [Ping timeout: 252 seconds]
--- Log closed Fri Jul 10 00:00:06 2015