--- Log opened Thu Jul 09 00:00:05 2015 | ||
-!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep] | 00:00 | |
-!- venzen [~venzen@5.255.87.165] has joined #bitcoin-wizards | 00:04 | |
-!- alewis_btc [~antonylew@101.100.162.252] has joined #bitcoin-wizards | 00:04 | |
-!- Mably [~Mably@unaffiliated/mably] has quit [Ping timeout: 244 seconds] | 00:13 | |
-!- p15x_ [~p15x@111.194.197.10] has quit [Max SendQ exceeded] | 00:13 | |
-!- p15x [~p15x@111.194.197.10] has joined #bitcoin-wizards | 00:14 | |
-!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 00:18 | |
-!- Quanttek [~quassel@ip1f10af17.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 00:19 | |
-!- JackH [~Jack@host-80-43-142-154.as13285.net] has joined #bitcoin-wizards | 00:20 | |
-!- arubi_ [~ese168@unaffiliated/arubi] has quit [Quit: Leaving] | 00:22 | |
-!- drwin [~drwin@88-103-255-166.jes.cz] has joined #bitcoin-wizards | 00:26 | |
-!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has quit [Quit: Leaving.] | 00:29 | |
-!- Giszmo [~leo@pc-185-201-214-201.cm.vtr.net] has quit [Quit: Leaving.] | 00:31 | |
-!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has joined #bitcoin-wizards | 00:32 | |
-!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has quit [] | 00:33 | |
-!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards | 00:34 | |
-!- alewis_btc [~antonylew@101.100.162.252] has quit [Quit: alewis_btc] | 00:39 | |
-!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 264 seconds] | 00:44 | |
-!- Mably [56401ec5@gateway/web/freenode/ip.86.64.30.197] has joined #bitcoin-wizards | 00:49 | |
-!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has quit [Quit: Leaving.] | 00:51 | |
-!- alewis_btc [~antonylew@118.189.115.158] has joined #bitcoin-wizards | 01:13 | |
-!- rustyn [~rustyn@unaffiliated/rustyn] has quit [Quit: london] | 01:14 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards | 01:22 | |
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:25 |
---|---|---|
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 248 seconds] | 01:27 | |
-!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-wizards | 01:28 | |
-!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has joined #bitcoin-wizards | 01:30 | |
-!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has quit [Max SendQ exceeded] | 01:31 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] | 01:31 | |
-!- drwin [~drwin@88-103-255-166.jes.cz] has quit [] | 01:38 | |
-!- OneFixt_ [~OneFixt@unaffiliated/onefixt] has joined #bitcoin-wizards | 01:42 | |
-!- venzen [~venzen@5.255.87.165] has quit [Ping timeout: 250 seconds] | 01:44 | |
-!- theymos [~theymos@unaffiliated/theymos] has quit [Ping timeout: 250 seconds] | 01:45 | |
-!- theymos [~theymos@unaffiliated/theymos] has joined #bitcoin-wizards | 01:45 | |
-!- OneFixt [~OneFixt@unaffiliated/onefixt] has quit [Ping timeout: 250 seconds] | 01:46 | |
-!- venzen [~venzen@5.255.87.165] has joined #bitcoin-wizards | 01:47 | |
-!- Quanttek [~quassel@ip1f10af17.dynamic.kabel-deutschland.de] has quit [Ping timeout: 264 seconds] | 01:53 | |
-!- goregrind [~goregrind@unaffiliated/goregrind] has quit [Read error: Connection reset by peer] | 01:55 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 01:59 | |
-!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has joined #bitcoin-wizards | 02:03 | |
-!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_] | 02:07 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte] | 02:10 | |
-!- goregrind [~goregrind@unaffiliated/goregrind] has joined #bitcoin-wizards | 02:11 | |
-!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has joined #bitcoin-wizards | 02:18 | |
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:19 |
CodeShark | right | 02:20 |
-!- 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:21 |
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:22 |
-!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has joined #bitcoin-wizards | 02:23 | |
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:24 |
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:25 |
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:26 |
-!- 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:27 |
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:28 |
CodeShark | that would mean only the most contentious battles would tend to reach the global consensus level | 02:29 |
CodeShark | each level up costs more, of course - since you're asking more people to contribute computational resources to decide your case | 02:30 |
CodeShark | I mean, that's sort of how civil society works | 02:31 |
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:32 |
moa | nsh: https://github.com/bitcoin/bitcoin/pull/6402 jgarzik has a very similar idea with a cleaner implementation it looks like | 02:33 |
-!- alewis_btc [~antonylew@118.189.115.158] has joined #bitcoin-wizards | 02:34 | |
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:35 |
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:36 |
CodeShark | waxwing: doesn't seem very many people have always assumed that :p | 02:37 |
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:38 |
waxwing | CodeShark: this is kind of what i think: https://bitcointalk.org/index.php?topic=418071.msg6423270#msg6423270 | 02:39 |
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:40 |
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:41 |
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:42 |
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:43 | |
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:44 |
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:45 |
* waxwing nods | 02:46 | |
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:47 |
CodeShark | i.e. insurance, market makers, etc... | 02:48 |
CodeShark | and the ecosystem can involve humans that willingly take on the risk for potential profit | 02:49 |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 02:51 | |
-!- dEBRUYNE [~dEBRUYNE@239-196-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 02:54 | |
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 | 02:58 |
-!- 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:01 | |
leakypat | SWIFT can route your payment through jurisdictions without your knowledge | 03:06 |
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:07 |
leakypat | The letter of credit market for example | 03:08 |
-!- alewis_btc [~antonylew@118.189.115.158] has quit [Quit: alewis_btc] | 03:09 | |
-!- 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:11 |
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:13 |
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:14 |
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:15 |
-!- 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:16 |
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:17 | |
-!- dc17523be3 [unknown@gateway/vpn/mullvad/x-mrjmebcteisqxxqb] has joined #bitcoin-wizards | 03:18 | |
CodeShark | would money being frozen also fit into the "censorship" category? | 03:19 |
leakypat | For sure | 03:19 |
leakypat | It's risk being introduced by the system | 03:20 |
leakypat | That costs | 03:20 |
leakypat | fluffypony: where abouts? | 03:20 |
fluffypony | leakypat: South Africa | 03:21 |
-!- Emcy [~MC@unaffiliated/mc1984] has quit [Read error: Connection reset by peer] | 03:21 | |
-!- 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:24 | |
-!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 03:25 | |
-!- koshii [~w@c-68-58-151-30.hsd1.in.comcast.net] has joined #bitcoin-wizards | 03:26 | |
-!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [Ping timeout: 264 seconds] | 03:27 | |
-!- 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:28 | |
-!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has quit [Quit: Leaving.] | 03:29 | |
-!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has joined #bitcoin-wizards | 03:30 | |
-!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has quit [Ping timeout: 264 seconds] | 03:34 | |
-!- XXIII [~XXIII@67.70.121.248] has quit [Quit: Leaving] | 03:45 | |
-!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has joined #bitcoin-wizards | 03:49 | |
-!- p15x_ [~p15x@64.145.91.48] has joined #bitcoin-wizards | 03:59 | |
-!- p15x [~p15x@111.194.197.10] has quit [Ping timeout: 250 seconds] | 04:00 | |
-!- 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:15 | |
-!- p15x_ [~p15x@64.145.91.48] has quit [Ping timeout: 248 seconds] | 04:16 | |
-!- 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:24 | |
-!- dc17523be3 [unknown@gateway/vpn/mullvad/x-mrjmebcteisqxxqb] has quit [Ping timeout: 252 seconds] | 04:29 | |
-!- dc17523be3 [unknown@gateway/vpn/mullvad/x-kcsesyyfuohnlqnf] has joined #bitcoin-wizards | 04:30 | |
-!- hashtag [~hashtag@cpe-69-23-213-3.ma.res.rr.com] has joined #bitcoin-wizards | 04:34 | |
-!- c0rw|zZz is now known as c0rw1n | 04:44 | |
-!- hashtag [~hashtag@cpe-69-23-213-3.ma.res.rr.com] has quit [Ping timeout: 246 seconds] | 04:46 | |
-!- drwin [~drwin@88-103-255-166.jes.cz] has joined #bitcoin-wizards | 04:54 | |
-!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 250 seconds] | 04:59 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards | 05:00 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 244 seconds] | 05:04 | |
-!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 05:06 | |
-!- chmod755 [~chmod755@unaffiliated/chmod755] has joined #bitcoin-wizards | 05:11 | |
-!- 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:17 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 250 seconds] | 05:18 | |
-!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has joined #bitcoin-wizards | 05:22 | |
-!- 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:23 | |
-!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has quit [Ping timeout: 252 seconds] | 05:28 | |
-!- mjerr [~mjerr@p578EB7BE.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds] | 05:35 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards | 05:36 | |
-!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: This computer has gone to sleep] | 05:37 | |
-!- SDCDev [~quassel@unaffiliated/sdcdev] has quit [Ping timeout: 256 seconds] | 05:41 | |
-!- afk11 [~thomas@46.7.4.219] has quit [Ping timeout: 276 seconds] | 05:45 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Remote host closed the connection] | 05:48 | |
-!- eudoxia [~eudoxia@r167-57-48-151.dialup.adsl.anteldata.net.uy] has joined #bitcoin-wizards | 05:49 | |
-!- alewis_btc [~antonylew@103.252.202.207] has joined #bitcoin-wizards | 05:55 | |
-!- nickler_ is now known as nickler | 05:55 | |
-!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards | 05:56 | |
-!- shaul_ [~shaul@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-wizards | 05:57 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 05:58 | |
-!- shaul [~shaul@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Ping timeout: 246 seconds] | 06:00 | |
-!- shaul_ [~shaul@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 06:02 | |
-!- p15x [~p15x@111.194.197.114] has joined #bitcoin-wizards | 06:05 | |
-!- 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:06 | |
-!- hashtag [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has joined #bitcoin-wizards | 06:07 | |
-!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has joined #bitcoin-wizards | 06:09 | |
-!- 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:14 | |
-!- chmod755 [~chmod755@unaffiliated/chmod755] has quit [Ping timeout: 240 seconds] | 06:16 | |
-!- SDCDev [~quassel@unaffiliated/sdcdev] has joined #bitcoin-wizards | 06:25 | |
-!- cdecker [~cdecker@2001:67c:10ec:2a49:8000::8] has joined #bitcoin-wizards | 06:27 | |
-!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has joined #bitcoin-wizards | 06:29 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds] | 06:34 | |
-!- moa [~kiwigb@opentransactions/dev/moa] has quit [Quit: Leaving.] | 06:38 | |
-!- 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:56 | |
-!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 06:57 | |
-!- stonecoldpat [~a9380004@janus-nat-128-240-225-56.ncl.ac.uk] has quit [Quit: Leaving.] | 07:00 | |
-!- hearn [~mike@185.25.95.132] has quit [Ping timeout: 248 seconds] | 07:01 | |
-!- hearn [~mike@185.25.95.132] has joined #bitcoin-wizards | 07:02 | |
-!- ruby32 [~ruby32@38.121.165.30] has joined #bitcoin-wizards | 07:08 | |
-!- fkhan [~weechat@unaffiliated/loteriety] has joined #bitcoin-wizards | 07:09 | |
-!- 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:14 | |
-!- ruby32 [~ruby32@38.121.165.30] has joined #bitcoin-wizards | 07:15 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards | 07:15 | |
-!- 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:20 | |
-!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has quit [Ping timeout: 252 seconds] | 07:23 | |
-!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 07:24 | |
-!- SaltySalads [~SaltySala@24.96.148.142] has quit [Quit: Leaving] | 07:27 | |
-!- 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:39 | |
-!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has joined #bitcoin-wizards | 07:40 | |
-!- b_lumenkraft [~b_lumenkr@unaffiliated/b-lumenkraft/x-4457406] has joined #bitcoin-wizards | 07:49 | |
-!- 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:51 | |
-!- www1 [~v3@x5ce12d9c.dyn.telefonica.de] has joined #bitcoin-wizards | 07:52 | |
-!- www [~v3@x5ce16b33.dyn.telefonica.de] has quit [Ping timeout: 256 seconds] | 07:54 | |
-!- tlrobinson [~tlrobinso@204.14.159.161] has quit [Quit: tlrobinson] | 07:55 | |
-!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has quit [Ping timeout: 250 seconds] | 07:58 | |
-!- davi [~davi@gnu/davi] has joined #bitcoin-wizards | 07:59 | |
-!- p15x [~p15x@111.194.197.114] has quit [Ping timeout: 252 seconds] | 08:00 | |
-!- ruby32 [~ruby32@38.121.165.30] has quit [Quit: Leaving] | 08:01 | |
-!- ruby32 [~ruby32@38.121.165.30] has joined #bitcoin-wizards | 08:01 | |
-!- ruby32 [~ruby32@38.121.165.30] has quit [Client Quit] | 08:03 | |
-!- p15x [~p15x@64.145.91.5] has joined #bitcoin-wizards | 08:04 | |
-!- ruby32 [~ruby32@38.121.165.30] has joined #bitcoin-wizards | 08:04 | |
-!- CodeShark_ [~androirc@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 256 seconds] | 08:12 | |
-!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has joined #bitcoin-wizards | 08:13 | |
-!- chmod755_ [~chmod755@unaffiliated/chmod755] has quit [Quit: Ex-Chat] | 08:14 | |
-!- davi [~davi@gnu/davi] has quit [Ping timeout: 256 seconds] | 08:18 | |
-!- zooko [~user@c-71-229-205-98.hsd1.co.comcast.net] has joined #bitcoin-wizards | 08:27 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards | 08:37 | |
-!- 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:40 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 244 seconds] | 08:41 | |
-!- Xh1pher [~Xh1pher@pD9E3A97A.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 08:45 | |
-!- instagibbs [32f65962@gateway/web/freenode/ip.50.246.89.98] has joined #bitcoin-wizards | 08:46 | |
-!- instagibbs [32f65962@gateway/web/freenode/ip.50.246.89.98] has quit [Client Quit] | 08:47 | |
-!- davi [~davi@gnu/davi] has quit [Ping timeout: 256 seconds] | 08:49 | |
-!- metamarc [~snizysnaz@unaffiliated/agorist000] has quit [Ping timeout: 255 seconds] | 08:54 | |
-!- spinza [~spin@197.89.23.144] has quit [Ping timeout: 240 seconds] | 08:57 | |
-!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has joined #bitcoin-wizards | 08:59 | |
-!- JackH [~Jack@host-80-43-142-154.as13285.net] has quit [Ping timeout: 246 seconds] | 09:01 | |
-!- 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:03 | |
-!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 09:04 | |
-!- alewis_btc [~antonylew@103.252.202.207] has quit [Quit: alewis_btc] | 09:10 | |
-!- Giszmo [~leo@pc-185-201-214-201.cm.vtr.net] has joined #bitcoin-wizards | 09:13 | |
-!- hashtagg_ [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has joined #bitcoin-wizards | 09:19 | |
-!- hashtag [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has quit [Ping timeout: 255 seconds] | 09:20 | |
-!- p15x_ [~p15x@64.145.91.77] has joined #bitcoin-wizards | 09:21 | |
-!- 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:22 | |
-!- bendavenport [~bpd@96.90.231.161] has joined #bitcoin-wizards | 09:23 | |
-!- bblue [~textual@104.220.67.131] has joined #bitcoin-wizards | 09:26 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 265 seconds] | 09:31 | |
-!- HM [~HM@81.4.101.225] has quit [Quit: Segmentation fault] | 09:33 | |
-!- HM [~HM@81.4.101.225] has joined #bitcoin-wizards | 09:34 | |
-!- nullbyte [~NSA@cpe-66-68-54-206.austin.res.rr.com] has joined #bitcoin-wizards | 09:39 | |
-!- Iriez [wario@distribution.xbins.org] has quit [Ping timeout: 248 seconds] | 09:44 | |
-!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has quit [Quit: Leaving.] | 09:50 | |
-!- 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:53 | |
-!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.] | 09:58 | |
-!- p15x [~p15x@64.145.91.17] has joined #bitcoin-wizards | 10:09 | |
-!- Iriez [wario@distribution.xbins.org] has joined #bitcoin-wizards | 10:10 | |
-!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 246 seconds] | 10:10 | |
-!- p15x_ [~p15x@64.145.91.77] has quit [Ping timeout: 244 seconds] | 10:11 | |
-!- waxwing [~waxwing@62.205.214.125] has quit [Ping timeout: 252 seconds] | 10:13 | |
-!- Emcy [~MC@unaffiliated/mc1984] has joined #bitcoin-wizards | 10:13 | |
-!- waxwing [~waxwing@62.205.214.125] has joined #bitcoin-wizards | 10:14 | |
-!- nullbyte [~NSA@cpe-66-68-54-206.austin.res.rr.com] has quit [Ping timeout: 256 seconds] | 10:15 | |
-!- JackH [~Jack@host-80-43-142-154.as13285.net] has joined #bitcoin-wizards | 10:21 | |
-!- Mably [56401ec5@gateway/web/freenode/ip.86.64.30.197] has quit [Quit: Page closed] | 10:25 | |
-!- p15x_ [~p15x@111.193.165.202] has joined #bitcoin-wizards | 10:28 | |
-!- p15x [~p15x@64.145.91.17] has quit [Ping timeout: 265 seconds] | 10:30 | |
-!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards | 10:34 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 10:37 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards | 10:38 | |
-!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has quit [Quit: This computer has gone to sleep] | 10:41 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 256 seconds] | 10:42 | |
-!- 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:55 | |
-!- Mably [~Mably@unaffiliated/mably] has joined #bitcoin-wizards | 10:58 | |
-!- zwick is now known as orcus | 11:00 | |
-!- orcus is now known as zwick | 11:00 | |
-!- 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:01 | |
-!- shen_noe [~shen_noe@wired094.math.utah.edu] has joined #bitcoin-wizards | 11:02 | |
-!- mjerr [~mjerr@p578EB7BE.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 11:08 | |
-!- nullbyte [NSA@gateway/vpn/mullvad/x-ngmvlguwlaypniph] has joined #bitcoin-wizards | 11:12 | |
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:15 |
jcorgan | it's the disassembly of the scriptPubKey binary into opcodes | 11:17 |
frankenmint | just trying to make sense of the huge mempool | 11:18 |
frankenmint | (and learn about the inner workings of btc too) | 11:18 |
-!- davi [~davi@gnu/davi] has quit [Ping timeout: 246 seconds] | 11:29 | |
-!- Giszmo [~leo@pc-185-201-214-201.cm.vtr.net] has quit [Quit: Leaving.] | 11:40 | |
-!- maraoz [~maraoz@2601:647:4a01:25f0:80be:f9dc:5338:e39c] has joined #bitcoin-wizards | 11:44 | |
-!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 11:47 | |
-!- nullbyte [NSA@gateway/vpn/mullvad/x-ngmvlguwlaypniph] has quit [Read error: Connection reset by peer] | 12:03 | |
-!- nullbyte [NSA@gateway/vpn/mullvad/x-npkqakzztrzbjmln] has joined #bitcoin-wizards | 12:05 | |
-!- Xh1pher [~Xh1pher@pD9E3A97A.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] | 12:06 | |
-!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-wizards | 12:08 | |
-!- blackwraith [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 12:13 | |
-!- blackwraith [~priidu@unaffiliated/priidu] has quit [Client Quit] | 12:14 | |
-!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 264 seconds] | 12:14 | |
-!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 12:15 | |
-!- priidu is now known as priiduf | 12:16 | |
-!- priiduf is now known as priidu | 12:16 | |
-!- nullbyte [NSA@gateway/vpn/mullvad/x-npkqakzztrzbjmln] has quit [Ping timeout: 252 seconds] | 12:18 | |
-!- maraoz [~maraoz@2601:647:4a01:25f0:80be:f9dc:5338:e39c] has quit [Ping timeout: 248 seconds] | 12:19 | |
-!- nullbyte [NSA@gateway/vpn/mullvad/x-ynbrabnovfdxnbxs] has joined #bitcoin-wizards | 12:20 | |
-!- jae_ [~jae@75-101-96-71.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection] | 12:22 | |
-!- shen_noe [~shen_noe@wired094.math.utah.edu] has quit [Ping timeout: 255 seconds] | 12:24 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards | 12:27 | |
-!- bramc [~bram@38.99.42.130] has joined #bitcoin-wizards | 12:29 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 248 seconds] | 12:31 | |
-!- p15x_ [~p15x@111.193.165.202] has quit [Read error: Connection reset by peer] | 12:35 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Remote host closed the connection] | 12:36 | |
-!- 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:37 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 12:38 | |
-!- nullbyte [NSA@gateway/vpn/mullvad/x-jkcszubbtkxvkjpd] has joined #bitcoin-wizards | 12:39 | |
-!- goregrind [~goregrind@unaffiliated/goregrind] has quit [Read error: Connection reset by peer] | 12:42 | |
-!- zooko [~user@c-71-229-205-98.hsd1.co.comcast.net] has quit [Ping timeout: 248 seconds] | 12:46 | |
-!- goregrind [~goregrind@unaffiliated/goregrind] has joined #bitcoin-wizards | 12:58 | |
-!- shen_noe [~shen_noe@162.216.46.19] has quit [Quit: Leaving] | 12:59 | |
-!- jae [~jae@204.14.159.153] has joined #bitcoin-wizards | 13:01 | |
-!- jae is now known as Guest73286 | 13:01 | |
-!- nullbyte [NSA@gateway/vpn/mullvad/x-jkcszubbtkxvkjpd] has quit [Ping timeout: 246 seconds] | 13:04 | |
-!- spinza [~spin@197.83.246.141] has joined #bitcoin-wizards | 13:05 | |
-!- 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:13 | |
-!- maraoz [~maraoz@2601:647:4a01:25f0:80be:f9dc:5338:e39c] has joined #bitcoin-wizards | 13:16 | |
-!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has joined #bitcoin-wizards | 13:27 | |
-!- dc17523be3 [unknown@gateway/vpn/mullvad/x-spthklszzotanhue] has joined #bitcoin-wizards | 13:32 | |
-!- zooko` [~user@2601:281:8301:e87f:6451:9685:3e5:5019] has joined #bitcoin-wizards | 13:37 | |
-!- 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:44 | |
-!- rubensayshi [~ruben@91.206.81.13] has quit [Ping timeout: 252 seconds] | 13:59 | |
-!- hashtagg_ [~hashtag@cpe-98-157-219-44.ma.res.rr.com] has quit [Ping timeout: 248 seconds] | 14:03 | |
-!- 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:04 | |
-!- drwin [~drwin@88-103-255-166.jes.cz] has quit [] | 14:07 | |
-!- 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:08 | |
-!- jae is now known as Guest23680 | 14:09 | |
-!- SwedFTP [~SwedFTP@unaffiliated/swedftp] has quit [Ping timeout: 252 seconds] | 14:09 | |
-!- jtimon [~quassel@69.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds] | 14:10 | |
-!- zooko` [~user@2601:281:8301:e87f:6451:9685:3e5:5019] has quit [Ping timeout: 248 seconds] | 14:14 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards | 14:15 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 256 seconds] | 14:20 | |
-!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-dichdcwpuuxpmnpd] has joined #bitcoin-wizards | 14:23 | |
-!- SwedFTP [~SwedFTP@unaffiliated/swedftp] has joined #bitcoin-wizards | 14:24 | |
-!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has quit [Ping timeout: 246 seconds] | 14:26 | |
-!- Guest98688 [~username@5ec3231d.skybroadband.com] has joined #bitcoin-wizards | 14:27 | |
-!- Guest98688 [~username@5ec3231d.skybroadband.com] has quit [Client Quit] | 14:31 | |
-!- jtimon [~quassel@69.29.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards | 14:34 | |
-!- afk11 [~thomas@46.7.4.219] has joined #bitcoin-wizards | 14:38 | |
-!- priidu [~priidu@unaffiliated/priidu] has quit [Read error: Connection reset by peer] | 14:41 | |
-!- jtimon [~quassel@69.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds] | 14:49 | |
-!- 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:51 | |
-!- 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:52 | |
-!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has quit [Ping timeout: 248 seconds] | 14:53 | |
-!- flower [~user@189.116.150.203.sta.inet.co.th] has quit [Quit: -] | 14:56 | |
-!- Giszmo [~leo@pc-185-201-214-201.cm.vtr.net] has joined #bitcoin-wizards | 15:05 | |
-!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has joined #bitcoin-wizards | 15:08 | |
-!- XXIII [~XXIII@67.70.121.248] has joined #bitcoin-wizards | 15:09 | |
-!- mjerr [~mjerr@p578EB7BE.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds] | 15:11 | |
-!- bramc [~bram@38.99.42.130] has quit [Quit: This computer has gone to sleep] | 15:17 | |
-!- mats [sid23029@gateway/web/irccloud.com/x-odcymmhqskjwxcdr] has left #bitcoin-wizards [] | 15:21 | |
-!- Tebbo [~Jerry`@ip72-211-88-176.no.no.cox.net] has quit [Ping timeout: 246 seconds] | 15:25 | |
-!- Guest23680 [~jae@204.14.159.153] has quit [Remote host closed the connection] | 15:28 | |
-!- jae [~jae@204.14.159.153] has joined #bitcoin-wizards | 15:32 | |
-!- jae is now known as Guest9223 | 15:32 | |
-!- bramc [~bram@38.99.42.130] has joined #bitcoin-wizards | 15:37 | |
-!- Mably [~Mably@unaffiliated/mably] has quit [Ping timeout: 244 seconds] | 15:42 | |
-!- Guest70571 [~username@5ec3231d.skybroadband.com] has joined #bitcoin-wizards | 15:43 | |
-!- Guest70571 [~username@5ec3231d.skybroadband.com] has quit [Client Quit] | 15:43 | |
-!- 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:44 | |
-!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 15:48 | |
-!- 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:49 | |
-!- Starduster [~SD@unaffiliated/starduster] has joined #bitcoin-wizards | 15:53 | |
-!- erasmospunk [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has joined #bitcoin-wizards | 15:55 | |
-!- bramc [~bram@38.99.42.130] has quit [Quit: This computer has gone to sleep] | 15:57 | |
-!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards | 15:58 | |
-!- hashtag [~hashtag@cpe-69-23-213-3.ma.res.rr.com] has joined #bitcoin-wizards | 16:00 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards | 16:01 | |
-!- Zooko-phone [~androirc@2600:100e:b004:b82a:64cd:7754:92c:837c] has joined #bitcoin-wizards | 16:02 | |
-!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-wizards | 16:04 | |
-!- Guest71065 [~username@5ec3231d.skybroadband.com] has quit [Quit: Leaving] | 16:04 | |
-!- hashtag [~hashtag@cpe-69-23-213-3.ma.res.rr.com] has quit [Ping timeout: 255 seconds] | 16:05 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 248 seconds] | 16:06 | |
-!- afk11 [~thomas@46.7.4.219] has quit [Ping timeout: 240 seconds] | 16:18 | |
-!- hashtag [~hashtag@cpe-69-23-213-3.ma.res.rr.com] has joined #bitcoin-wizards | 16:21 | |
-!- rubensayshi [~ruben@92.110.255.64] has joined #bitcoin-wizards | 16:23 | |
-!- erasmospunk [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has quit [Remote host closed the connection] | 16:30 | |
-!- afk11 [~thomas@168.1.75.56-static.reverse.softlayer.com] has joined #bitcoin-wizards | 16:33 | |
-!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 16:37 | |
-!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has joined #bitcoin-wizards | 16:37 | |
-!- dEBRUYNE [~dEBRUYNE@239-196-ftth.onsbrabantnet.nl] has quit [Ping timeout: 240 seconds] | 16:39 | |
-!- Zooko-phone [~androirc@2600:100e:b004:b82a:64cd:7754:92c:837c] has quit [Ping timeout: 248 seconds] | 16:42 | |
-!- dabura667 [uid43070@gateway/web/irccloud.com/x-pnoouoouuzmbphbt] has joined #bitcoin-wizards | 16:49 | |
-!- n9270 [~user7540@94.197.121.110.threembb.co.uk] has joined #bitcoin-wizards | 16:51 | |
-!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] | 16:55 | |
-!- 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 | 16:58 | |
-!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 17:01 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards | 17:05 | |
-!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has quit [Quit: Leaving.] | 17:07 | |
-!- afk11 [~thomas@168.1.75.56-static.reverse.softlayer.com] has quit [Ping timeout: 256 seconds] | 17:08 | |
-!- rubensayshi [~ruben@92.110.255.64] has quit [Remote host closed the connection] | 17:10 | |
-!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has joined #bitcoin-wizards | 17:14 | |
-!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has quit [Max SendQ exceeded] | 17:15 | |
-!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has joined #bitcoin-wizards | 17:16 | |
-!- p15x_ [~p15x@64.145.91.16] has joined #bitcoin-wizards | 17:22 | |
-!- p15x [~p15x@114.248.216.31] has quit [Ping timeout: 248 seconds] | 17:23 | |
-!- harrow [~harrow@105.ip-167-114-152.net] has quit [Ping timeout: 248 seconds] | 17:25 | |
-!- afk11 [~thomas@178.162.211.213] has joined #bitcoin-wizards | 17:28 | |
-!- 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:30 | |
-!- p15x_ [~p15x@64.145.91.16] has quit [Ping timeout: 256 seconds] | 17:32 | |
-!- cryptoreach [~Kevin@90.192.38.248] has joined #bitcoin-wizards | 17:47 | |
-!- cryptoreach is now known as reach4thelasers | 17:49 | |
-!- c0rw1n is now known as c0rw|zZz | 17:59 | |
-!- bendavenport [~bpd@96.90.231.161] has quit [Quit: bendavenport] | 18:01 | |
-!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-wizards | 18:03 | |
-!- bramc [~bram@38.99.42.130] has joined #bitcoin-wizards | 18:10 | |
-!- 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:12 | |
-!- sadoshi [~Sadoshi@31.220.4.123] has joined #bitcoin-wizards | 18:13 | |
-!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds] | 18:14 | |
-!- shen_noe [~shen_noe@173-165-135-246-utah.hfc.comcastbusiness.net] has joined #bitcoin-wizards | 18:15 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Remote host closed the connection] | 18:23 | |
-!- alewis_btc [~antonylew@101.100.162.252] has joined #bitcoin-wizards | 18:24 | |
-!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards | 18:25 | |
-!- 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:30 | |
-!- Zooko-phone [~androirc@2600:100e:b027:aad8:1f69:fdb7:229f:d74a] has quit [Ping timeout: 248 seconds] | 18:35 | |
-!- 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:36 | |
-!- ruby32 [~ruby32@ool-4354b58f.dyn.optonline.net] has joined #bitcoin-wizards | 18:38 | |
-!- ruby32 [~ruby32@ool-4354b58f.dyn.optonline.net] has quit [Client Quit] | 18:40 | |
-!- jtimon [~quassel@69.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds] | 18:50 | |
-!- 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:52 | |
-!- 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:54 | |
-!- Dr-G2 [~Dr-G@x4d08dbc8.dyn.telefonica.de] has quit [Ping timeout: 256 seconds] | 18:55 | |
-!- dabura667 [uid43070@gateway/web/irccloud.com/x-pnoouoouuzmbphbt] has quit [Quit: Connection closed for inactivity] | 18:57 | |
-!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #bitcoin-wizards | 18:58 | |
-!- maaku is now known as Guest22663 | 18:59 | |
-!- maaku_ [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Ping timeout: 264 seconds] | 18:59 | |
-!- mrkent [~textual@unaffiliated/mrkent] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 19:00 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards | 19:24 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 265 seconds] | 19:29 | |
-!- afk11 [~thomas@178.162.211.213] has quit [Ping timeout: 264 seconds] | 19:54 | |
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 | 19:58 |
-!- p15x_ [~p15x@64.145.91.75] has joined #bitcoin-wizards | 20:02 | |
-!- p15x [~p15x@64.145.91.32] has quit [Ping timeout: 264 seconds] | 20:04 | |
-!- afk11 [~thomas@46.7.4.219] has joined #bitcoin-wizards | 20:11 | |
-!- afk11 [~thomas@46.7.4.219] has quit [Ping timeout: 252 seconds] | 20:16 | |
-!- p15x [~p15x@64.145.91.82] has joined #bitcoin-wizards | 20:19 | |
-!- p15x_ [~p15x@64.145.91.75] has quit [Ping timeout: 250 seconds] | 20:20 | |
-!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 246 seconds] | 20:24 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has joined #bitcoin-wizards | 20:26 | |
-!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 20:26 | |
-!- afk11 [~thomas@46.7.4.219] has joined #bitcoin-wizards | 20:28 | |
-!- tromp [~tromp@ool-18be0b4d.dyn.optonline.net] has quit [Ping timeout: 248 seconds] | 20:30 | |
-!- harrow [~harrow@105.ip-167-114-152.net] has joined #bitcoin-wizards | 20:40 | |
-!- alewis_btc [~antonylew@101.100.162.252] has quit [Quit: alewis_btc] | 20:42 | |
-!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has joined #bitcoin-wizards | 20:45 | |
-!- bendavenport [~bpd@c-50-131-42-132.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 20:47 | |
-!- jlrubin [~jlrubin@mass-toolpike.mit.edu] has joined #bitcoin-wizards | 20:49 | |
jlrubin | Oops I realize I'd been asking about my more theoretical 2 phase commit idea oon -dev rather than here... | 20:51 |
amiller | jlrubin, what about it? | 20:53 |
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:54 | |
jlrubin | (sorry for the delay, meant to send back2back but got cut off. Chinese internet man... | 20:55 |
jlrubin | ) | 20:55 |
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:56 |
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:57 |
jlrubin | The block does not need full acceptance. | 20:58 |
-!- RH311ish [~RH311ish@65.78.60.74] has quit [Read error: Connection reset by peer] | 20:59 | |
-!- 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:05 |
amiller | how about if instead of a pointer to a previous block, i just include the hash of a transaction to 'confirm' it | 21:06 |
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:07 |
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:09 |
jlrubin | amilller: that's why I feel it is similar to 2 phase commit. Different from a typical "full abort" though | 21:11 |
-!- p15x_ [~p15x@64.145.91.36] has joined #bitcoin-wizards | 21:22 | |
-!- p15x [~p15x@64.145.91.82] has quit [Ping timeout: 256 seconds] | 21:23 | |
-!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 21:24 | |
amiller | jlrubin, if a transaction isn't committed in the next block, can it be resubmitted again? | 21:29 |
-!- bblue [~textual@104.220.67.131] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] | 21:36 | |
jlrubin | yes/no | 21:40 |
jlrubin | In theory it's still in mempool then | 21:40 |
jlrubin | so the next miner will try to commit it | 21:41 |
jlrubin | * include, not commit | 21:41 |
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:42 |
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:43 |
jlrubin | https://gist.github.com/JeremyRubin/1a3260431b3ee4afbaa0 for reference | 21:44 |
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:45 |
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:46 |
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:47 |
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:49 |
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:50 |
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:51 |
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:52 |
jlrubin | Sure; but that would suggest they didn't get that block actually | 21:53 |
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:54 |
gmaxwell | Well obviously non-zero wouldn't be sufficient, as one could just set it to 1. | 21:55 |
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:56 |
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:57 |
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:58 |
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: | 21:59 |
-!- 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:00 |
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:01 |
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:03 |
-!- 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:04 |
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:05 |
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:06 |
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:07 |
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:08 |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
gmaxwell | I have not expressed any opinion on that subject. | 22:14 |
gmaxwell | (in this discussion) | 22:14 |
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:15 |
-!- 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:16 | |
jlrubin | Yes, so part of pointer selection, as mentioned in proposal, is also validation costs | 22:17 |
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:18 |
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:19 |
gmaxwell | jlrubin: I am not following what you're thinking there. | 22:20 |
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:21 |
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:22 |
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:23 |
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:24 |
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:25 | |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
jlrubin | B commits ab, then says my new block is cdefxyz | 22:31 |
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:32 |
gmaxwell | This would have required them to obtain the complete list of transactions from A, rather than a log() scale hashtree prefix proof. | 22:34 |
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:35 |
jlrubin | I think a better prevention of fee stealing is splitting the fee with the next miner | 22:36 |
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:37 |
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:38 |
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:40 |
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:41 |
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:42 |
-!- 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:43 |
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:44 |
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:45 |
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:46 |
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:47 |
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:48 |
jlrubin | reduced whose? | 22:49 |
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:50 |
jlrubin | Well | 22:51 |
jlrubin | same is true for 1 block now anyways | 22:51 |
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:52 |
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:53 |
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:55 |
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:56 |
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:57 |
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:58 |
gmaxwell | I didn't read that part; though I do not understand how you'd address conflicts in such a scheme. | 22:59 |
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:00 |
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:01 |
-!- 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:02 |
-!- 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:03 |
jlrubin | Yeah I was just typing that | 23:04 |
jlrubin | realized it violates | 23:04 |
jlrubin | perhaps "not larger than the first commit" | 23:04 |
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:05 |
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:06 |
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:07 |
-!- 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:08 |
jlrubin | great :) | 23:09 |
jlrubin | I have to run -- thank you for taking the time to go through this with me. | 23:10 |
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:11 |
gmaxwell | Yea maybe! interesting discussion. Thanks. | 23:12 |
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:14 |
-!- 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:15 |
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:16 |
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:17 |
-!- wallet42 [~wallet42@ppp046176089135.access.hol.gr] has joined #bitcoin-wizards | 23:19 | |
-!- 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:20 | |
-!- Mably [~Mably@unaffiliated/mably] has joined #bitcoin-wizards | 23:21 | |
-!- 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:22 | |
jlrubin | Ah, I see :) | 23:23 |
jlrubin | The extreme is Peter Todd's "just mine the raw bytes, let the client decide what it means" | 23:24 |
-!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards | 23:32 | |
-!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds] | 23:34 | |
-!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards | 23:39 | |
-!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 23:40 | |
-!- Xh1pher [~Xh1pher@pD9E3A97A.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 23:47 | |
-!- Mably [~Mably@unaffiliated/mably] has quit [Ping timeout: 252 seconds] | 23:52 | |
--- Log closed Fri Jul 10 00:00:06 2015 |
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!