| --- Log opened Sun Jul 05 00:00:01 2015 | ||
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 00:00 | |
| -!- Mably [~Mably@unaffiliated/mably] has joined #bitcoin-wizards | 00:03 | |
| -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards | 00:20 | |
| -!- p15x_ [~p15x@111.193.190.75] has joined #bitcoin-wizards | 00:22 | |
| -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_] | 00:24 | |
| -!- p15x [~p15x@64.145.91.48] has quit [Ping timeout: 265 seconds] | 00:25 | |
| -!- Mably [~Mably@unaffiliated/mably] has quit [Ping timeout: 264 seconds] | 00:30 | |
| -!- erasmosp_ [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has quit [Remote host closed the connection] | 00:30 | |
| -!- sy5error [~sy5error@unaffiliated/sy5error] has quit [Remote host closed the connection] | 00:36 | |
| -!- davi [~davi@gnu/davi] has quit [Ping timeout: 246 seconds] | 00:42 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds] | 01:00 | |
| -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has joined #bitcoin-wizards | 01:03 | |
| -!- davi [~davi@gnu/davi] has joined #bitcoin-wizards | 01:19 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 01:20 | |
| -!- drwin [~drwin@88-103-255-166.jes.cz] has joined #bitcoin-wizards | 01:23 | |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 01:28 | |
| -!- Mably [~Mably@unaffiliated/mably] has joined #bitcoin-wizards | 01:52 | |
| -!- davi [~davi@gnu/davi] has quit [Ping timeout: 246 seconds] | 01:59 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Remote host closed the connection] | 02:01 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 02:02 | |
| -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Quit: Leaving] | 02:02 | |
| -!- davi [~davi@gnu/davi] has joined #bitcoin-wizards | 02:05 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds] | 02:20 | |
| -!- bosma is now known as superkai64 | 02:25 | |
| -!- superkai64 is now known as bosma | 02:25 | |
| -!- wallet42 [~wallet42@185.4.41.147] has quit [Quit: Leaving.] | 02:28 | |
| -!- davi [~davi@gnu/davi] has quit [Ping timeout: 246 seconds] | 02:42 | |
| -!- p15x_ [~p15x@111.193.190.75] has quit [Max SendQ exceeded] | 02:45 | |
| -!- p15x [~p15x@64.145.91.60] has joined #bitcoin-wizards | 02:46 | |
| -!- p15x_ [~p15x@64.145.91.75] has joined #bitcoin-wizards | 02:49 | |
| -!- p15x [~p15x@64.145.91.60] has quit [Ping timeout: 252 seconds] | 02:51 | |
| -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards | 02:53 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 02:59 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] | 03:01 | |
| -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has quit [] | 03:02 | |
| -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has joined #bitcoin-wizards | 03:07 | |
| -!- davi [~davi@gnu/davi] has joined #bitcoin-wizards | 03:08 | |
| -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has quit [Max SendQ exceeded] | 03:08 | |
| -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has joined #bitcoin-wizards | 03:09 | |
| -!- bedeho2 is now known as bedeho | 03:10 | |
| CodeShark_ | So is the revocation mechanism you're referring to something else, gmaxwell? | 03:10 |
|---|---|---|
| gmaxwell | no thats it, it wasn't clear to me that you were aware of it.. the point being you can do lots of transfers and revocations without any transactions. | 03:11 |
| gmaxwell | just one transaction to open at the beginning and one close the channel at the end. | 03:12 |
| gmaxwell | (well or two to close on a timeout close.) | 03:12 |
| CodeShark_ | Right...the part that's still a little annoying is the need to watch the blockchain and act within a particular timeframe or lose your money | 03:13 |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards | 03:14 | |
| CodeShark_ | that's probably the single greatest complication | 03:18 |
| CodeShark_ | if we could find a way around this it would make the idea potentially much more viable | 03:23 |
| CodeShark_ | I was pondering hypothetical schemes where it would be the noncooperating party responsible for this rather than the cooperative party | 03:29 |
| CodeShark_ | But you ultimately run into the retroactive invalidation issue... | 03:30 |
| -!- jtimon [~quassel@69.29.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards | 03:32 | |
| CodeShark_ | so poon-dryja "solve" this...but only at the cost of forcing the cooperative party to actively fight this | 03:32 |
| -!- chmod755 [~chmod755@unaffiliated/chmod755] has quit [Quit: Ex-Chat] | 03:36 | |
| -!- davi [~davi@gnu/davi] has quit [Ping timeout: 246 seconds] | 03:38 | |
| nsh | i think there's a kind of conservation at play. you can't gain efficiency and maintain trustworthiness without requiring attention/vigilance | 03:47 |
| CodeShark_ | Yes, that might in fact be the case | 03:47 |
| nsh | it reduces ultimately to ordering relations, and if you want to have a stake in the correctness of ordering, then you have to be willing to act within the granularity of network time | 03:48 |
| nsh | which is blocktime | 03:48 |
| -!- davi [~davi@gnu/davi] has joined #bitcoin-wizards | 03:49 | |
| CodeShark_ | I guess the next best thing is delegating this task to others (potentially for a fee) | 03:50 |
| nsh | offering that option while maintaining the flexibility for people to invest their own resources rather than delegate trust is optimal afaic | 03:51 |
| nsh | but there is clearly some... ideological divergence of position in this respect | 03:51 |
| -!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has joined #bitcoin-wizards | 03:53 | |
| CodeShark_ | the purist trustless perspective would insist that everyone be forever vigilant. But in the real world people delegate this stuff all the time - it's why we have lawyers and representatives in government, etc... | 03:53 |
| nsh | right | 03:55 |
| nsh | the issue isn't that we must avoid trust. the issue is that trust concretes and that authority tends towards corruption | 03:55 |
| nsh | so allowing for the bypassing of actors that have successfully carved themselves an indelible niches that allows for rent-seeking behaviour [and worse] is nice | 03:56 |
| nsh | it incentivizes new actors coming in and finding nominally-less-parasitical ways to interpose for the convenience of the hoi-polloi | 03:57 |
| nsh | *niche | 03:57 |
| CodeShark_ | right - so having the option to represent yourself without bureaucracy and corrupt institutions is great. But in practical terms not everyone will necessarily be capable of doing it themselves | 03:58 |
| nsh | but it's nice to allow for competition in the space of intermediaries | 03:58 |
| CodeShark_ | Right, absolutely | 03:58 |
| nsh | which regular capitalism does better in principle than practice | 03:58 |
| nsh | because of the accretion effect of power | 03:59 |
| nsh | and the general brokenness of political systems | 03:59 |
| nsh | but that's another matter :) | 03:59 |
| nsh | how compact are proofs-of-space? | 04:01 |
| nsh | (cc amiller) | 04:01 |
| CodeShark_ | It inevitably becomes political when we're talking either about rule changes or about dispute resolution where either the rules are unclear or we don't have all the facts. | 04:02 |
| nsh | spacecoin doesn't give a proof-size that i can see | 04:03 |
| -!- SDCDev [~quassel@unaffiliated/sdcdev] has quit [Read error: Connection reset by peer] | 04:03 | |
| nsh | CodeShark_, you can't squeeze the politics out, but you can approach it in a way that minimizes the worse parts of the miasma that tends to accompany politics :) | 04:04 |
| -!- SDCDev [~quassel@unaffiliated/sdcdev] has joined #bitcoin-wizards | 04:04 | |
| -!- p15x_ [~p15x@64.145.91.75] has quit [Ping timeout: 265 seconds] | 04:07 | |
| -!- erasmospunk [~erasmospu@176.92.61.74] has joined #bitcoin-wizards | 04:08 | |
| CodeShark_ | It might still be possible to refocus the vigilance. for instance if it were possible to have expiration with a sufficiently high level of granularity, rather than having to watch the blockchain and react, you'd instead only need to watch the counterparty | 04:09 |
| -!- erasmosp_ [~erasmospu@179.43.156.98] has joined #bitcoin-wizards | 04:10 | |
| CodeShark_ | or at least you could reduce the number of outputs you're looking for | 04:11 |
| * nsh nods | 04:11 | |
| -!- wallet42 [~wallet42@185.4.41.147] has joined #bitcoin-wizards | 04:12 | |
| -!- dEBRUYNE_ [~dEBRUYNE@239-196-ftth.onsbrabantnet.nl] has joined #bitcoin-wizards | 04:12 | |
| -!- erasmospunk [~erasmospu@176.92.61.74] has quit [Ping timeout: 244 seconds] | 04:12 | |
| nsh | tromp_ / amiller / andytoshi / gmaxwell: is there a good high-level overview of proof-of-space algorithms and their security basis? friend is investigating namecoiny applications involving additional commitments to space-hard work in identifier claiming/updating txes | 04:13 |
| -!- davi [~davi@gnu/davi] has quit [Ping timeout: 246 seconds] | 04:25 | |
| -!- spinza [~spin@197.89.10.176] has quit [Ping timeout: 244 seconds] | 04:28 | |
| -!- p15x [~p15x@64.145.91.58] has joined #bitcoin-wizards | 04:56 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards | 05:04 | |
| -!- spinza [~spin@197.89.186.249] has joined #bitcoin-wizards | 05:21 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-kbszivkytihirbvx] has quit [Ping timeout: 255 seconds] | 05:39 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-qywjseuybrysyogn] has joined #bitcoin-wizards | 05:40 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-qywjseuybrysyogn] has quit [Ping timeout: 256 seconds] | 05:47 | |
| -!- merlincorey [merlin@nginx/adept/merlincorey] has quit [Ping timeout: 246 seconds] | 05:48 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-jwmakwkrtwvkcusv] has joined #bitcoin-wizards | 05:49 | |
| -!- jae [~jae@2601:645:c001:263a:a110:f114:b3e0:ba50] has joined #bitcoin-wizards | 05:54 | |
| -!- jae is now known as Guest11434 | 05:55 | |
| -!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has quit [Ping timeout: 244 seconds] | 05:55 | |
| -!- p15x [~p15x@64.145.91.58] has quit [Ping timeout: 264 seconds] | 05:59 | |
| -!- merlincorey [merlin@69.42.217.140] has joined #bitcoin-wizards | 06:00 | |
| -!- p15x [~p15x@64.145.91.74] has joined #bitcoin-wizards | 06:03 | |
| -!- merlincorey [merlin@69.42.217.140] has quit [Read error: No route to host] | 06:03 | |
| -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards | 06:06 | |
| -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has quit [Ping timeout: 252 seconds] | 06:10 | |
| -!- shesek [~shesek@77.125.92.26] has joined #bitcoin-wizards | 06:11 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds] | 06:24 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-jwmakwkrtwvkcusv] has quit [Ping timeout: 256 seconds] | 06:28 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-vndyeplqqslffzgl] has joined #bitcoin-wizards | 06:29 | |
| -!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has quit [Ping timeout: 276 seconds] | 06:37 | |
| -!- theymos [~theymos@unaffiliated/theymos] has quit [Ping timeout: 264 seconds] | 06:46 | |
| -!- theymos [~theymos@unaffiliated/theymos] has joined #bitcoin-wizards | 06:50 | |
| -!- CodeShark_ [~androirc@cpe-76-167-237-202.san.res.rr.com] has quit [Remote host closed the connection] | 06:55 | |
| -!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has joined #bitcoin-wizards | 06:59 | |
| -!- wallet42 [~wallet42@185.4.41.147] has quit [Quit: Leaving.] | 07:03 | |
| -!- Guest11434 [~jae@2601:645:c001:263a:a110:f114:b3e0:ba50] has quit [Remote host closed the connection] | 07:03 | |
| -!- bedeho [~bedeho@195.159.234.190] has quit [Quit: Nettalk6 - www.ntalk.de] | 07:05 | |
| -!- www [~v3@x5ce13e5c.dyn.telefonica.de] has joined #bitcoin-wizards | 07:07 | |
| -!- p15x_ [~p15x@114.244.152.170] has joined #bitcoin-wizards | 07:15 | |
| -!- p15x [~p15x@64.145.91.74] has quit [Ping timeout: 250 seconds] | 07:16 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 07:18 | |
| -!- shesek [~shesek@77.125.92.26] has quit [Ping timeout: 264 seconds] | 07:23 | |
| -!- shesek [~shesek@77.125.92.26] has joined #bitcoin-wizards | 07:38 | |
| -!- erasmospunk [~erasmospu@176.92.66.240] has joined #bitcoin-wizards | 07:38 | |
| -!- erasmosp_ [~erasmospu@179.43.156.98] has quit [Ping timeout: 252 seconds] | 07:38 | |
| -!- erasmospunk [~erasmospu@176.92.66.240] has quit [Read error: Connection reset by peer] | 07:39 | |
| -!- erasmospunk [~erasmospu@179.43.134.162] has joined #bitcoin-wizards | 07:39 | |
| -!- erasmospunk [~erasmospu@179.43.134.162] has quit [Remote host closed the connection] | 07:40 | |
| -!- asciilifeform [~asciilife@unaffiliated/asciilifeform] has left #bitcoin-wizards ["Leaving"] | 07:45 | |
| -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards | 07:51 | |
| -!- www1 [~v3@f052068111.adsl.alicedsl.de] has joined #bitcoin-wizards | 07:52 | |
| -!- www [~v3@x5ce13e5c.dyn.telefonica.de] has quit [Ping timeout: 252 seconds] | 07:54 | |
| -!- davi [~davi@gnu/davi] has joined #bitcoin-wizards | 08:01 | |
| -!- mjerr [~mjerr@p578EAB34.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 08:16 | |
| -!- p15x [~p15x@64.145.91.35] has joined #bitcoin-wizards | 08:21 | |
| -!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has joined #bitcoin-wizards | 08:21 | |
| -!- c0rw|zZz is now known as c0rw1n | 08:23 | |
| -!- p15x_ [~p15x@114.244.152.170] has quit [Ping timeout: 264 seconds] | 08:23 | |
| -!- davi [~davi@gnu/davi] has quit [Remote host closed the connection] | 08:24 | |
| -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-ahclurwxfedpywrn] has joined #bitcoin-wizards | 08:26 | |
| -!- merlincorey [merlin@69.42.217.140] has joined #bitcoin-wizards | 08:40 | |
| -!- CodeShark_ [~androirc@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards | 08:48 | |
| iddo | nsh: there's academic paper but it's unpublished yet, also proof-of-space cryptocurrency has costless simulation problem | 08:51 |
| nsh | is this related to the cycle detection issue? | 08:56 |
| nsh | i think some of the newer proposals are based on better assumptions. tromp_'s cuckoo cycles should not be trivially simulatable, nor reductions to pebbling | 08:57 |
| -!- p15x_ [~p15x@64.145.91.19] has joined #bitcoin-wizards | 09:02 | |
| -!- p15x [~p15x@64.145.91.35] has quit [Ping timeout: 264 seconds] | 09:03 | |
| -!- Starduster [~sd@unaffiliated/starduster] has quit [Ping timeout: 256 seconds] | 09:10 | |
| iddo | nsh: are you talking about PoW that needs both intensive computations and large memory, or proof-of-space that rewards large storage space without need for CPU ? | 09:11 |
| iddo | i think that you meant the first, there's no costless simulation problem there | 09:12 |
| nsh | well, spacecoin is an example of the latter, and i can't see how you'd simulate it with lower cost than the storage required to do so honestly, except in exponential running time | 09:12 |
| nsh | exponential running time is not low cost :) | 09:13 |
| -!- tucenaber [~tucenaber@unaffiliated/tucenaber] has quit [Ping timeout: 256 seconds] | 09:17 | |
| iddo | there's subtle argument that you can outcompete the honest chain if you start at genesis for example, if it's proof-of-space without checkpointing / timestamping to disallow old reorgs | 09:17 |
| iddo | hmm i'm not up-to-date, i see that one academic team published spacecoin https://eprint.iacr.org/2015/528 | 09:18 |
| iddo | i actually talked with one of the authors last year, the basic construction wasn't so good then (similar problems to ppc/nxt) | 09:18 |
| * nsh nods | 09:22 | |
| amiller | iddo, what problems? | 09:25 |
| amiller | iddo, also is the newest one subject to whatever you have in mind or not? | 09:26 |
| iddo | problems where it's rational to work on forks that get created concurrently | 09:29 |
| iddo | seems like this paper tries to deal with it by using bonds | 09:29 |
| nsh | gmax has a name for that problem, but it evades me temporarily | 09:31 |
| iddo | i.e., some scheme with deposits that incentive to work on one of the forks, not sure yet about it | 09:31 |
| iddo | amiller: the other paper that i had in mind relies on having honest core of miners who are aware of the current time, security breaks if this honest core doesn't exist | 09:32 |
| iddo | nsh: nothing-at-stake ? actually it's amiller's name i think | 09:33 |
| nsh | ah yes | 09:34 |
| nsh | and apologies for misattribution | 09:34 |
| nsh | so yeah, some kind of fidelity is the usual go-to to prevent hedging across forks | 09:34 |
| nsh | but it seems to be difficult in practice | 09:34 |
| nsh | i might be possible to use the block-randomness to instantiate problems across the large file in such a way that it has to be completely rewritten to work on a different fork | 09:35 |
| nsh | that way you have to linear cost in storage to each fork you want to prove stake across | 09:36 |
| nsh | s/have to/have/ | 09:36 |
| iddo | well there are relevant questions here, if there's fork because two miners created a competing next block, the lucky miner who can create the following block can do it on both forks or only on one? | 09:39 |
| * nsh nods | 09:41 | |
| nsh | some amount of reorg has to be assumed, so you can't be too punitive about it | 09:41 |
| iddo | in ppc it's in both, this variant is better for what it's worth, because it makes it less rational to work on forks due to the risk of divergence into many forks | 09:42 |
| nsh | and that may adversely affect consensus convergence | 09:42 |
| nsh | in ways that are difficult to anticipate theoretically :/ | 09:42 |
| iddo | (by "both" i meant you can create the following block on both forks) | 09:42 |
| iddo | nsh: i agree that the ideas of deposits where you may lose you bond are problematic, in fact if you try to look at it formally by considering the state of the system at genesis, it isn't clear how to initialize this process | 09:45 |
| nsh | hmm | 09:46 |
| nsh | how do you mean, sorry? | 09:46 |
| iddo | the ethereum guys are trying to do this too, but not proof-of-space | 09:46 |
| iddo | nsh: well, you need to post your bond, and this bond needs to be part of the ledger history so that it will be recognized... and then you're allowed to create a block... so it's cyclic reasoning, you need to have the next block and to create the next block ? | 09:48 |
| -!- c0rw1n is now known as c0rw|away | 09:50 | |
| -!- Quanttek [~quassel@ip1f10af17.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards | 09:52 | |
| -!- p15x [~p15x@64.145.91.104] has joined #bitcoin-wizards | 09:56 | |
| -!- p15x_ [~p15x@64.145.91.19] has quit [Ping timeout: 250 seconds] | 09:56 | |
| -!- tucenaber [~tucenaber@unaffiliated/tucenaber] has joined #bitcoin-wizards | 09:58 | |
| -!- Starduster [~sd@unaffiliated/starduster] has joined #bitcoin-wizards | 09:58 | |
| -!- spinza [~spin@197.89.186.249] has quit [Excess Flood] | 09:59 | |
| -!- spinza [~spin@197.89.186.249] has joined #bitcoin-wizards | 10:08 | |
| -!- SubCreative [~SubCreati@unaffiliated/cannacoin] has joined #bitcoin-wizards | 10:10 | |
| -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.] | 10:13 | |
| -!- erasmospunk [~erasmospu@81.17.20.98] has joined #bitcoin-wizards | 10:23 | |
| -!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has quit [Ping timeout: 246 seconds] | 10:31 | |
| -!- erasmospunk [~erasmospu@81.17.20.98] has quit [Remote host closed the connection] | 10:32 | |
| -!- erasmospunk [~erasmospu@81.17.20.98] has joined #bitcoin-wizards | 10:32 | |
| -!- www1 [~v3@f052068111.adsl.alicedsl.de] has quit [Ping timeout: 250 seconds] | 10:34 | |
| -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards | 10:47 | |
| -!- www [~v3@f052068111.adsl.alicedsl.de] has joined #bitcoin-wizards | 10:50 | |
| -!- [d__d] [~d__d]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Remote host closed the connection] | 10:50 | |
| -!- [d__d] [~d__d]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-wizards | 10:51 | |
| -!- dEBRUYNE_ is now known as dEBRUYNE | 10:58 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-vndyeplqqslffzgl] has quit [Read error: Connection reset by peer] | 11:09 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-ptctwbduhexdjqhz] has joined #bitcoin-wizards | 11:13 | |
| -!- p15x_ [~p15x@64.145.91.122] has joined #bitcoin-wizards | 11:14 | |
| -!- p15x [~p15x@64.145.91.104] has quit [Ping timeout: 252 seconds] | 11:16 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-ptctwbduhexdjqhz] has quit [Ping timeout: 264 seconds] | 11:23 | |
| -!- nullbyte [~NSA@193.138.219.233] has joined #bitcoin-wizards | 11:24 | |
| -!- nullbyte [~NSA@193.138.219.233] has quit [Ping timeout: 252 seconds] | 11:29 | |
| -!- p15x [~p15x@111.193.183.199] has joined #bitcoin-wizards | 11:30 | |
| -!- p15x [~p15x@111.193.183.199] has quit [Read error: Connection reset by peer] | 11:30 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-xwcwcizbjmqoyfrb] has joined #bitcoin-wizards | 11:31 | |
| -!- p15x_ [~p15x@64.145.91.122] has quit [Ping timeout: 255 seconds] | 11:32 | |
| -!- p15x [~p15x@64.145.91.49] has joined #bitcoin-wizards | 11:33 | |
| -!- jae_ [~jae@c-98-234-63-169.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 11:34 | |
| -!- jae_ [~jae@c-98-234-63-169.hsd1.ca.comcast.net] has quit [Remote host closed the connection] | 11:38 | |
| -!- roconnor [~roconnor@e120-pool-d89a7a26.brdbnd.voicenetwork.ca] has joined #bitcoin-wizards | 11:39 | |
| -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards | 11:43 | |
| nsh | iddo, thanks (sorry was afk) | 11:47 |
| nsh | i'm not sure that's necessarily pathological. you can have garden-of-eden configurations in a stable decentralized system | 11:47 |
| nsh | e.g. a game of life instance which has a terminating timeline in the backwards direction | 11:47 |
| iddo | unique initial config? i don't really see the relevance of this analogy | 11:49 |
| iddo | basically you need to post bond at earlier block, it gets confirmed, and then you become eligible to be a miner, but this "earlier" block condition means you need to describe how to initialize this process | 11:51 |
| -!- btcdrak [uid52049@gateway/web/irccloud.com/x-qlepkiskztklqxle] has quit [Quit: Connection closed for inactivity] | 11:51 | |
| iddo | for example you can have protocol where first blocks after genesis are done with PoW only, that's one way to initialize i guess | 11:53 |
| -!- mjerr [~mjerr@p578EAB34.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds] | 11:53 | |
| nsh | right | 11:54 |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards | 11:57 | |
| -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 265 seconds] | 12:07 | |
| iddo | again looking briefly at spacecoin, they seem to avoid rational forks by using much earlier block to control who can mine the current block, which introduces risk of collusion for double-spending attacks | 12:08 |
| iddo | it actually becomes less clear why proof-of-space is needed at all, given the bonds/challenges aspects of this | 12:12 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte] | 12:18 | |
| -!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has joined #bitcoin-wizards | 12:18 | |
| -!- ryanxcharles [~ryan@2601:645:8202:4881:3030:39d0:1ef1:39e1] has quit [Ping timeout: 248 seconds] | 12:25 | |
| -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 276 seconds] | 12:31 | |
| -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: zoom zoom zoom] | 12:32 | |
| -!- wallet42 [~wallet42@60-227-202-46.pool.ukrtel.net] has joined #bitcoin-wizards | 12:33 | |
| -!- chmod755 [~chmod755@unaffiliated/chmod755] has joined #bitcoin-wizards | 12:34 | |
| -!- p15x_ [~p15x@64.145.91.71] has joined #bitcoin-wizards | 12:36 | |
| -!- vaalbara [~vaalbara@23.94.31.98] has joined #bitcoin-wizards | 12:36 | |
| -!- p15x [~p15x@64.145.91.49] has quit [Ping timeout: 248 seconds] | 12:37 | |
| -!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has quit [Quit: Leaving.] | 12:37 | |
| -!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has joined #bitcoin-wizards | 12:39 | |
| -!- wallet42 [~wallet42@60-227-202-46.pool.ukrtel.net] has quit [Quit: Leaving.] | 12:39 | |
| -!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has quit [Ping timeout: 246 seconds] | 12:43 | |
| -!- vaalbara [~vaalbara@23.94.31.98] has quit [Quit: Leaving] | 12:44 | |
| bramc | iddo, I have an idea for how to fix the re-mining from genesis block problem. It requires a little bit of bending the rules and a lot of careful engineering and some breaking open of the proof of space though, so I need to read though the construction in the spacecoin paper | 12:46 |
| bramc | Unfortunately the 'obvious' constructions have CPU/space tradeoffs | 12:46 |
| -!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has joined #bitcoin-wizards | 12:47 | |
| -!- vaalbara [~vaalbara@23.94.31.98] has joined #bitcoin-wizards | 12:47 | |
| -!- andytoshi [~andytoshi@wpsoftware.net] has quit [Ping timeout: 256 seconds] | 12:49 | |
| -!- scoria [~blaze@wpsoftware.net] has quit [Ping timeout: 244 seconds] | 12:49 | |
| -!- jae_ [~jae@204.14.159.153] has joined #bitcoin-wizards | 12:50 | |
| -!- Xh1pher [~Xh1pher@pD9E3A97A.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] | 12:51 | |
| -!- akrmn [~akrmn@192.95.51.167] has joined #bitcoin-wizards | 12:57 | |
| -!- vaalbara [~vaalbara@23.94.31.98] has quit [Quit: Leaving] | 12:58 | |
| -!- kmels [~kmels@186.151.61.56] has joined #bitcoin-wizards | 12:59 | |
| -!- vaalbara [~vaalbara@23.94.31.98] has joined #bitcoin-wizards | 13:00 | |
| CodeShark_ | bramc: hopefully something other than checkpoints :p | 13:18 |
| bramc | CodeShark_ Not checkpoints! Well no more than regular Bitcoin has 'checkpoints' anyway. | 13:19 |
| iddo | bramc: costless simulation is an inherent problem... you can see for example section 3 of my paper http://arxiv.org/abs/1406.5694 | 13:20 |
| -!- prodatalab [~prodatala@2601:6c4:200:d4e0:516e:dd82:12cd:f300] has quit [Remote host closed the connection] | 13:22 | |
| -!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards | 13:22 | |
| CodeShark_ | nice work, iddo :) | 13:23 |
| iddo | thanks, but it keeps getting rejected by clueless academic people :) | 13:24 |
| bramc | iddo, The trick is to throw in proofs of time | 13:25 |
| bramc | aka proofs of sequential work | 13:26 |
| iddo | sequential work? that doesn't sound costless... | 13:26 |
| bramc | iddo, You're in good company about having trouble getting published, most of the papers people in this channel find worth discussing have struggled to get publication | 13:27 |
| bramc | sequential work isn't costless, but it need only be done by the one fastest person in the whole network | 13:27 |
| iddo | do you need to re-adjust the difficulty of this work according to how fast the network is? | 13:29 |
| -!- sy5error [~sy5error@unaffiliated/sy5error] has joined #bitcoin-wizards | 13:29 | |
| -!- UllrSkis [~UllrSkis@c-66-41-201-92.hsd1.mn.comcast.net] has quit [Ping timeout: 264 seconds] | 13:29 | |
| iddo | then, an attacker can start from genesis with low difficulty for this work | 13:29 |
| CodeShark_ | To be fair, bramc, lots of stuff being published in this space is less than superb...so you do have to know a thing or two about this stuff to recognize the gems | 13:30 |
| iddo | and if you say that the chain with greater cumulative difficulty wins, then it's just PoW based, no? | 13:30 |
| bramc | iddo, Yes the speed of proof of time has to be part of the work difficulty reset | 13:30 |
| amiller | i spouted out in the SFdev talk that the cuckoo cycle paper went to Financial Crypto, but it was actually the Bitcoin Workshop (at financial crypto) so the level of review and recognition is much lower | 13:30 |
| iddo | bramc: right, so if chain with greater difficulty wins, how is it different than ordinary PoW ? | 13:32 |
| CodeShark_ | sounds like at best a hybrid | 13:32 |
| bramc | iddo, the difficulty of the proof of space and the proof of time have to be combined for the cumulative difficulty | 13:32 |
| amiller | hybrids like that are complicated to think through :/ | 13:32 |
| bramc | It's different because everybody does their proof of space, then compares to see whose is best, then the proof of time is only done on the best one while everybody else chills out saving power. | 13:33 |
| bramc | amiller, I didn't say it isn't complicated! | 13:33 |
| amiller | hmm. the idea that you compare all the proofs-of-space to see who's best is exactly what's suggested in the spacecoin paper | 13:33 |
| iddo | ok so you rely on PoW to make it non-costless, so maybe you lose nice properties of proof-of-space claims to have | 13:33 |
| amiller | that seems weird to me too though, since how do you know you're comparing against the correct set | 13:33 |
| iddo | one supposed nice property is that storage space is ASIC resistant, you cannot manufacture specialized hardware that outperform the common hardware for storage space ? | 13:35 |
| bramc | iddo, I think you meant to say rely on proof of time to make it non-costless, and that is sort of true | 13:35 |
| bramc | iddo, storage is completely and totally commodity, you can't make something which does it differently and better | 13:35 |
| iddo | yeah, i'm still not exactly sure whats the distinction between proof of time and PoW | 13:36 |
| bramc | Also there's a meaningful economic argument why storage is different: It's already sitting out there depreciating in mass quantities | 13:36 |
| -!- p15x [~p15x@64.145.91.47] has joined #bitcoin-wizards | 13:36 | |
| bramc | A proof of time shows that a certain amount of time passed between thing A and thing B, it can be as simple as repeatedly hashing something with checkpoints along the way so it can be spot-checked | 13:37 |
| -!- p15x_ [~p15x@64.145.91.71] has quit [Ping timeout: 246 seconds] | 13:37 | |
| phantomcircuit | bramc, the economics are clearly different, whether they provide similar security with less waste isn't clear to me | 13:37 |
| phantomcircuit | clearly there's less waste in such a system | 13:37 |
| phantomcircuit | but im not clear it provides the same economic incentives | 13:37 |
| bramc | phantomcircuit, Technically it's leveraging pre-existing waste | 13:37 |
| iddo | but you said that you require this proof to be more difficult if the network is faster | 13:37 |
| bramc | Oh I didn't mean the latency on the network, I meant the speed of the fastest proof of time server | 13:38 |
| phantomcircuit | (no capital investment, possibly means less incentive, but maybe sunk cost fallacy) | 13:38 |
| iddo | bramc: so if the network has 1000000 miners instead of 100 miners, it isn't more difficult to produce this proof of time ? | 13:39 |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-xwcwcizbjmqoyfrb] has quit [Ping timeout: 246 seconds] | 13:39 | |
| bramc | amiller, I'm not sure what your last question meant | 13:39 |
| iddo | if that's the case, why wouldn't an attacker be able to do costless simulation attack from genesis? | 13:40 |
| bramc | iddo, The number of miners doesn't matter for the work factor on the proofs of time, it's the amount of space devoted to the proofs of space | 13:40 |
| bramc | iddo, The system alternates between proofs of space and proofs of time, in pairs. The work factor on a pair is the product of the two of them. | 13:41 |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-xeltozveaeklicty] has joined #bitcoin-wizards | 13:41 | |
| bramc | Per what iddo was saying, it isn't a costless system, it's just picked winners beforehand so everybody but the one big winner can bow out | 13:41 |
| bramc | It winds up having stochastic block times like regular Bitcoin: The better the proof of space, the shorter the proof of time. | 13:42 |
| iddo | still seems to me that an attacker can start from genesis and always pick himself, if he has fast way to create proof of time | 13:43 |
| bramc | iddo, Nobody has a particularly faster proof of time than anybody else, and everybody who makes a faster proof of time can contribute to the proofs of time for the system as a whole to keep everybody else honest | 13:44 |
| bramc | But yes in principle if you have, say, a tenth of the space but more than ten times as fast of a proof of time as anybody else then you can eventually catch up and overtake. | 13:44 |
| -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 248 seconds] | 13:45 | |
| -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-wizards | 13:45 | |
| -!- andytoshi [~andytoshi@wpsoftware.net] has joined #bitcoin-wizards | 13:46 | |
| iddo | bramc: the nice propery of proof of space that we seek to have is that if you prove that your space was dedicated for the mining process i.e. wasn't being used for anything else, then you are more likely to get higher reward... this property gives efficient energy consumption unlike PoW | 13:46 |
| -!- kmels [~kmels@186.151.61.56] has quit [Ping timeout: 256 seconds] | 13:46 | |
| bramc | iddo, Yes that's why I'm talking about proof of time instead of proof of work (which boils down primarily to power and electricity) | 13:47 |
| iddo | so if an attacker can start from genesis and claim that he dedicated plenty of storage space, he will presumably win | 13:47 |
| -!- drwin [~drwin@88-103-255-166.jes.cz] has quit [] | 13:47 | |
| bramc | iddo, right but the proofs of time slow you down, so you can always catch up, but by then everything else will have moved on | 13:48 |
| iddo | (if he can claim that he dedicated the space for long time period and nobody can say that that's false) | 13:48 |
| -!- scoria [~blaze@wpsoftware.net] has joined #bitcoin-wizards | 13:48 | |
| iddo | bramc: so i don't really get what's this proof of time? how do you say that everyone can do it at same speed as anyone else? | 13:48 |
| bramc | You have an ability to prove space/second, and that applies to your attempts to catch up from genesis | 13:48 |
| iddo | how? | 13:49 |
| bramc | A proof of time is something like: Start with the output of the last thing, encrypt it X times. That's the most trivial one. A big improvement is to include checkpoints along the way so checking it can be parallelized and spot checked | 13:50 |
| -!- kmels [~kmels@186.151.61.56] has joined #bitcoin-wizards | 13:50 | |
| iddo | encrypt it X times? what does that prove? | 13:51 |
| bramc | Let's say, for the sake of argument, that everybody's proof of times are done at the exact same rate | 13:51 |
| bramc | It proves that an amount of time proportional to X was spent between the input and the output | 13:51 |
| iddo | but you can encrypt faster with faster hardware? | 13:51 |
| iddo | why encrypt instead of hash? | 13:52 |
| bramc | Hashing is really what you're doing, I just said encrypt on the theory than AES is what's already accelerated everywhere | 13:52 |
| bramc | Yes, you can go faster with faster hardware, but that will probably hit about the same limit for everybody | 13:53 |
| iddo | sha256 is accelerated on Bitcoin ASIC | 13:53 |
| bramc | And even if it doesn't the design of the network is made to screw everybody who's trying to get ahead that way | 13:53 |
| bramc | AES is accelerated on Intel :-P | 13:53 |
| bramc | The proofs of time are completely canonical, and there's no direct incentive to run one yourself. There's more than enough indirect incentive because of the advantage it gives you on your own proofs of space | 13:54 |
| iddo | i fail to see the difference between proof of time and PoW | 13:55 |
| bramc | So everybody takes the output of the last proof of time, runs their own proof of space on it, the best ones are published, and whoever's running a supercooled accelerated proof of time server does the proof of time on the best one | 13:56 |
| bramc | That way only a handful of machines are burning power | 13:56 |
| bramc | With PoW every machine is burning power the entire time | 13:57 |
| iddo | what's the incentive to compute the proof of time ? | 13:57 |
| bramc | The incentives are (a) to get a leg up on everybody else by having a proof of time server, and (b) to screw over the other assholes who are trying to do (a) | 13:58 |
| bramc | having a *faster* proof of time server I mean | 13:58 |
| iddo | so if you can do proof of time faster than others, you get more rewards | 13:59 |
| bramc | Right, but everybody else is likely trying to keep you from doing that | 14:00 |
| bramc | It only really helps you when there's a near-tie and you can win | 14:00 |
| iddo | i still fail to see the difference between this and PoW | 14:00 |
| bramc | When you've clearly lost this round you run your own proof of time server on the best thing published to the network | 14:01 |
| iddo | proof of time has to computed by someone, either you would want to get someone else to do it for you (and he would wish to be compensated for his effort), or you do it yourself... same as PoW, no? | 14:01 |
| bramc | The difference is in the amount of power used. With proofs of time used properly only a handful of machines are running the proofs of time: The really fast, well optimized ones. All the other machines do their proofs of space and then sit around chilling | 14:02 |
| bramc | The main cost of the proofs of time is getting your super fast machine set up. Their operating costs are very small compared to that | 14:02 |
| amiller | bramc, is it the case that the proof-of-time has no impact on the choice of block or transactions in a block? | 14:03 |
| -!- andytoshi [~andytoshi@wpsoftware.net] has quit [Changing host] | 14:03 | |
| -!- andytoshi [~andytoshi@unaffiliated/andytoshi] has joined #bitcoin-wizards | 14:03 | |
| amiller | like, the guy who can do the fastest proofs-of-time gets no influence? | 14:03 |
| bramc | amiller, The proof of time is 100% canonical on the output of the proof of space | 14:03 |
| iddo | ok but i claim that everybody will do proof of time themselves, or pay for someone else to do this part of the job for them... so it's just like PoW | 14:03 |
| bramc | amiller, Yes that's a very important feature! | 14:03 |
| bramc | iddo, Why would you do your own proof of time when your machine is slower? | 14:03 |
| -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards | 14:04 | |
| iddo | bramc: you buy faster machine so you can earn more rewards, or you pay someone who has faster machine than you | 14:04 |
| amiller | bramc, is there some marginal cost point where i'd be better off paying for faster proof-of-time instead of more storage? | 14:05 |
| bramc | iddo, It only matters for the very few who are the absolute fastest. There's this mutually assured destruction which happens between the handful of players who actually put in the money to make faster proofs of time servers | 14:05 |
| iddo | as far as i can see, you just added PoW component, and try to claim that it won't lead less efficient enery usage, but i don't see why your claim is supposed to be true, it seems just like ordinary PoW | 14:06 |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-xeltozveaeklicty] has quit [Read error: Connection reset by peer] | 14:07 | |
| iddo | s/lead/lead to | 14:07 |
| bramc | What winds up happening is that there's the fastest and second fastest proofs of time servers. The fastest one may be able to set up a racket where people can pay him to run their near-misses. The second fastest runs on the best thing they get because fuck that #1 guy | 14:07 |
| amiller | iddo, you're really missing how the Po(sequential)W component isn't meant to be competitive | 14:07 |
| -!- erasmospunk [~erasmospu@81.17.20.98] has quit [Remote host closed the connection] | 14:08 | |
| bramc | In practice the differences in speed between optimized PoT servers are likely to be extremely small | 14:08 |
| iddo | amiller: if you has PoW function that it would the same amount of time for everyone to compute? sure if that function existed... | 14:08 |
| amiller | iddo proofs of sequential work are well known | 14:09 |
| amiller | iddo they'd be rejected as uninteresting if proposed as a bitcoin-replacement on their own, because they are not "progess free" | 14:09 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 14:09 | |
| bramc | It turns out sequential hashing with checkpoints is the best approach to the PoT, because it's canonical and spot checkable | 14:09 |
| iddo | ok you mean timelock puzzles that are difficulty to parallelize.. | 14:10 |
| amiller | yes | 14:10 |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-fqqncxcedorghawc] has joined #bitcoin-wizards | 14:10 | |
| bramc | iddo, Calling them 'timelock puzzles' makes it sound like there's interesting match involved. In this case the math is quite trivial, because there's no public key component | 14:11 |
| bramc | interesting math I mean | 14:11 |
| iddo | but sequential isn't synonym to ASIC resistant ? | 14:12 |
| bramc | Regular timelock puzzles need an encoder to be able to create them quickly, these have no such requirement | 14:12 |
| bramc | Sequential does not mean ASIC resistant! | 14:13 |
| bramc | It mean non-parallelizable | 14:13 |
| amiller | bramc, by which you mean, ASICs might compute them much more cost/power efficiently, just not *faster* | 14:13 |
| bramc | Although, umm, some people who don't know what they're talking about might claim that sequentiality helps with ASIC resistance, which is wrong | 14:13 |
| iddo | also non progress-free is a problem here too? winstead of sending it to a server, you start working on it locally and you win | 14:14 |
| bramc | amiller, ASICs might also compute them faster, it would be a completely different ASIC than one designed for efficiency | 14:15 |
| bramc | amiller, You of course try to make it ASIC resistant (hence my comment about using AES because of the good Intel acceleration already) but the important feature is sequentiality | 14:15 |
| bramc | iddo, working on it locally doesn't save you anything more than the time for it to propagate across the network | 14:16 |
| iddo | yes so if you save propagation time then you win, everyting else being equal? | 14:16 |
| iddo | anyway i still don't see the point, either you pay some server to do this PoW for you, or you do it yourself, in either case someone has revenues/expenditures for doing PoW, just like Bitcoin | 14:17 |
| bramc | Propagation time is probably extremely small | 14:17 |
| iddo | you can ask, why aren't there only say 10 Bitcoin CPU miners now, it will be more energy efficient than all these ASICS | 14:18 |
| bramc | No with each block the best proofs of space are published and only the very best one is worked on. Everybody else doesn't waste their power | 14:18 |
| iddo | my argument is that everybody will or will not waste their power just like in Bitcoin, i don't see the difference | 14:19 |
| amiller | bramc, what happens if there is a #1 proof-of-space, and a #2 proof-of-space (the best two ones after all of them are compared), and only the proof-of-time for the #2 solution is published first | 14:20 |
| bramc | In Bitcoin you don't know if a mining attempt will work in advance, hence lots of power spent on unsuccessful mining attempts | 14:20 |
| bramc | amiller, Then the #1 is SOL | 14:21 |
| iddo | if someone outcompetes you then he creates the next block? whats the difference? | 14:21 |
| bramc | amiller, #1 should have published faster :-) | 14:21 |
| -!- davi [~davi@gnu/davi] has joined #bitcoin-wizards | 14:21 | |
| amiller | bramc, that seems like a hazard | 14:21 |
| bramc | amiller, It isn't any different from orphan blocks in regular Bitcoin | 14:22 |
| amiller | well there aren't many people computing proofs-of-time in yoru scenario so it would be easier to bribe them | 14:22 |
| amiller | and it *does* mean that they have significant influence after all | 14:22 |
| bramc | amiller, Yes that is a bit of a hazard | 14:23 |
| bramc | although they have to all cooperate to play those games, and there's no way for them to tell who's cheating if anybody is, and there's nothing stopping anybody else from jumping in | 14:23 |
| iddo | you cannot just declare there aren't many people doing PoT because that's how you envision it.. i can say that i envision Bitcoin with 10 CPU miners but it doesn't make it so | 14:25 |
| -!- erasmospunk [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has joined #bitcoin-wizards | 14:25 | |
| bramc | I don't understand what you aren't getting here | 14:27 |
| bramc | After every round of PoS, everybody publishes theirs to the network, unless they've gotten a better one already. It rapidly becomes clear what the best PoS is | 14:27 |
| bramc | Why would you run a PoT on a PoS which you know is going to finish late? | 14:28 |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-fqqncxcedorghawc] has quit [Ping timeout: 265 seconds] | 14:28 | |
| iddo | you run PoT on the winning PoS, or let someone else do it for you, in both cases doing the PoT has a cost | 14:29 |
| bramc | Even if everybody's PoT is the exact same speed, and it's run on the winner, that's still done exactly once | 14:29 |
| bramc | Everybody else gets a heads up that their PoS is deficient and gives up early. | 14:30 |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-rbesagxsuoimfuiq] has joined #bitcoin-wizards | 14:30 | |
| iddo | why wouldn't there be PoT race ? | 14:31 |
| -!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has quit [Ping timeout: 246 seconds] | 14:34 | |
| bramc | Because a PoS outputs a somewhat stochastic quality metric, and if that quality is half as good the PoT takes twice as long | 14:34 |
| bramc | So except on the margin where there's a near tie you know who's going to win in advance | 14:34 |
| bramc | (this is the part which I need to read through the spacecoin paper about. My simpler PoS technique has this property but it's busted) | 14:35 |
| bramc | (my PoS technique is busted I mean, not the property) | 14:35 |
| iddo | but it is required to produce the PoT on the highest quality PoS, so there will be a market for producing it, no? | 14:36 |
| bramc | Not sure what you mean. Any PoS needs a corresponding PoT for there to be a resulting block | 14:36 |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-rbesagxsuoimfuiq] has quit [Ping timeout: 250 seconds] | 14:37 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-mhhahwkhgarbejwf] has joined #bitcoin-wizards | 14:39 | |
| iddo | if i have an ability to produce the PoT in half the time that you can, is it a valuable ability? | 14:39 |
| bramc | That depends on whether there's a yet even faster PoT server just sitting out on the network working on whatever it's sent | 14:40 |
| iddo | for the sake of example suppose it's only you and i | 14:40 |
| bramc | Having the very fastest PoT server is potentially valuable because in case of near miss somebody can pay you to do their PoT | 14:41 |
| -!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has joined #bitcoin-wizards | 14:41 | |
| bramc | If there are only two miners, and one has a PoT twice as fast as the other, then that effectively doubles their space | 14:41 |
| bramc | Or rather, has the equivalent effect of doubling their space | 14:41 |
| iddo | suppose that only one very high quality PoS was created, is it valuable to do the PoT on it faster rather than slower? | 14:42 |
| bramc | Over time a faster PoT will get factored into the work difficulty and not change the rate of mining rewards | 14:43 |
| iddo | suppose you produced the high quality PoS, and there are 10 PoT servers competing to generate the PoT for you, then the fastest among those 10 will get paid by you? because if you wait for slower server then you take the risk that other PoS might suddenly outcompete you? | 14:45 |
| bramc | The idea is that there are PoT servers on the network which operate on the best PoS they can find, specifically because they want to undermine anybody else trying to get ahead based on a faster PoT server. | 14:46 |
| bramc | It's a little dicey paying for PoT services, because there's no way to verify that they did the work themselves | 14:47 |
| iddo | why do PoT servers do work if they don't get paid ? | 14:48 |
| bramc | Because it's of very little marginal cost to them, and it keeps other PoT servers honest | 14:48 |
| -!- Quanttek [~quassel@ip1f10af17.dynamic.kabel-deutschland.de] has quit [Ping timeout: 264 seconds] | 14:49 | |
| iddo | you rely on altruistic PoT servers for this system? | 14:49 |
| bramc | I thought about trying to create direct incentives for PoT servers, and everything was bad. | 14:49 |
| bramc | There's some slight altruism from PoT servers | 14:50 |
| -!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has quit [Ping timeout: 276 seconds] | 14:50 | |
| iddo | in what sense they aren't altruistic ? | 14:50 |
| bramc | Well, they might not be altruistic in that they can be paid directly | 14:51 |
| bramc | It only takes one 'jerk' with a fast one to make it hard for the others to get a jump though. | 14:52 |
| iddo | mandatory altruism is hard to enforce :) market may develop for this service | 14:53 |
| bramc | There will likely be some market for it. That's an interesting detail | 14:53 |
| bramc | Thankfully it doesn't require all that widespread of altruism. It also helps that clock times are all about the same. | 14:54 |
| -!- ryanxcharles [~ryan@adsl-108-80-229-7.dsl.pltn13.sbcglobal.net] has joined #bitcoin-wizards | 14:54 | |
| iddo | one extreme is just Bitcoin, many PoT servers competing for produce the proof and get paid for it | 14:55 |
| iddo | you claim that this extreme wouldn't be the case | 14:55 |
| iddo | would be nice to see analysis given the precise properties here and what'd be the likely outcome | 14:56 |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-mhhahwkhgarbejwf] has quit [Ping timeout: 248 seconds] | 14:57 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds] | 14:59 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-pttqsodjhtomxfwr] has joined #bitcoin-wizards | 14:59 | |
| -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has quit [Max SendQ exceeded] | 15:00 | |
| bramc | If there are competing PoT servers then most of them will go out of business quickly due to being less fast | 15:01 |
| -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Read error: Connection reset by peer] | 15:03 | |
| -!- davi [~davi@gnu/davi] has quit [Ping timeout: 246 seconds] | 15:03 | |
| -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-wizards | 15:03 | |
| gmaxwell | bramc: bitcoin network split again if you didn't get enough fireworks on the 4th. | 15:06 |
| iddo | yes, it isn't lottery as with random-looking hash | 15:06 |
| gmaxwell | bramc: if you locad bc.i you'll see it listing height ast 363999 ... but thats a fork of invalid blocks starting with megabigpower. | 15:06 |
| bramc | gmaxwell, This is me sitting in my cave | 15:07 |
| bramc | Blowing up doesn't seem to have a negative effect on the price of bitcoin, I wonder if people even know | 15:08 |
| -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 15:08 | |
| iddo | so transaction malleability cannot happen anymore with standard transactions, now that BIP 66 is deployed? or can still happen but less likely? | 15:09 |
| Luke-Jr | it can happen, and is not much less likely.. | 15:09 |
| Luke-Jr | BIP 66 doesn't really try to address malleability | 15:09 |
| Luke-Jr | that was BIP 62, which needs a rewrite or something now | 15:09 |
| iddo | oh :( | 15:09 |
| iddo | what's the importance of BIP 66 then ? | 15:10 |
| Luke-Jr | iddo: removing OpenSSL from the consensus-critical code (sortof) | 15:11 |
| Luke-Jr | iddo: it should be a lot easier to prove libsecp256k1 is consensus-compatible now | 15:11 |
| bramc | The price of bitcoin seems to be moving up based on stories claiming that greeks are using bitcoin | 15:11 |
| gmaxwell | It does close down one avenue of malleability but thats a side effect. | 15:11 |
| iddo | i see | 15:11 |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-pttqsodjhtomxfwr] has quit [Ping timeout: 244 seconds] | 15:13 | |
| bramc | I think it's more about 'follow a real spec instead of being dependent on the quirks of one particular implementation' | 15:13 |
| -!- ryanxcharles [~ryan@adsl-108-80-229-7.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 246 seconds] | 15:15 | |
| -!- nullbyte [~NSA@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has joined #bitcoin-wizards | 15:15 | |
| amiller | here is our new preprint https://eprint.iacr.org/2015/675 Hawk: The Blockchain Model of Cryptography and Privacy-Preserving Smart Contracts | 15:16 |
| bramc | *sigh* all the cryptocurrency news sites are declaring that greece voting no is a great thing for bitcoin, proving how valuable it is, and predicting its value will go up as a result. That misperception is probably causing a short-term bump, assuming it isn't just noise | 15:16 |
| -!- nullbyte [~NSA@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has quit [Ping timeout: 246 seconds] | 15:19 | |
| -!- nullbyte [~NSA@193.138.219.233] has joined #bitcoin-wizards | 15:21 | |
| -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection] | 15:21 | |
| -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards | 15:22 | |
| -!- shen_noe [~shen_noe@50.252.142.179] has joined #bitcoin-wizards | 15:25 | |
| -!- _whitelogger [whitelogge@fehu.whitequark.org] has quit [Ping timeout: 252 seconds] | 15:27 | |
| -!- ryanxcharles [~ryan@adsl-108-81-169-137.dsl.pltn13.sbcglobal.net] has joined #bitcoin-wizards | 15:28 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 15:28 | |
| -!- SubCreative [~SubCreati@unaffiliated/cannacoin] has quit [Remote host closed the connection] | 15:31 | |
| -!- nullbyte [~NSA@193.138.219.233] has quit [Read error: Connection reset by peer] | 15:32 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-zqsowkqazhclusjr] has joined #bitcoin-wizards | 15:33 | |
| -!- goregrind [~goregrind@unaffiliated/goregrind] has quit [Ping timeout: 264 seconds] | 15:35 | |
| -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 248 seconds] | 15:37 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-zqsowkqazhclusjr] has quit [Ping timeout: 252 seconds] | 15:39 | |
| -!- Mably [~Mably@unaffiliated/mably] has quit [Ping timeout: 276 seconds] | 15:39 | |
| gmaxwell | so I tested a bunch of APIs and explorers during this fork event (which just ended with the valid chain overtaking and a 3 block reorg for spv clients) | 15:40 |
| gmaxwell | the following services were not working: | 15:40 |
| gmaxwell | https://blockchain.info/block/000000000000000012dbd422d7bf1c4b55982c37b390d4613dcee00d31741c6a | 15:40 |
| gmaxwell | https://www.biteasy.com/blockchain/blocks/000000000000000012dbd422d7bf1c4b55982c37b390d4613dcee00d31741c6a | 15:40 |
| gmaxwell | http://blockexplorer.com/block/000000000000000006ecee94daaa034bbd026cad52a9d3c6a5b7972716e5d566 | 15:40 |
| gmaxwell | http://blockchains.io/btc/block/000000000000000012DBD422D7BF1C4B55982C37B390D4613DCEE00D31741C6A | 15:40 |
| gmaxwell | http://webbtc.com/block/000000000000000012dbd422d7bf1c4b55982c37b390d4613dcee00d31741c6a | 15:40 |
| gmaxwell | http://blockstrap.com/en/api/?function=block&chain=btc&id=363999#demo | 15:40 |
| gmaxwell | https://bkchain.org/ connect error | 15:40 |
| gmaxwell | https://helloblock.io/ down | 15:40 |
| gmaxwell | https://tradeblock.com/blockchain/block/363999 | 15:40 |
| gmaxwell | Toshi seemed correct but weird it claimed 363999 blocks when the valid chain had 363998, but on inspection of the bad tip it reported it as "Height 1" | 15:41 |
| -!- nullbyte [~NSA@193.138.219.233] has joined #bitcoin-wizards | 15:41 | |
| gmaxwell | I was unable to figure out what chain several things were on, including electrum servers and block.io | 15:41 |
| -!- _whitelogger [whitelogge@fehu.whitequark.org] has joined #bitcoin-wizards | 15:43 | |
| amiller | gmaxwell, from those links it seems like blockexplorer.com was actually OK? | 15:44 |
| -!- chmod755 [~chmod755@unaffiliated/chmod755] has quit [Quit: Ex-Chat] | 15:45 | |
| gmaxwell | amiller: hah, no. by okay means its actually stuck way back. | 15:45 |
| amiller | oh. i see, it literally thinks we're still on 358999 | 15:46 |
| gmaxwell | it reports the tip as 35_8_999 | 15:46 |
| CodeShark_ | Ironic that a rule change calling for stricter structure formatting revealed the fact that apparently nobody gives a shit about proper structure formatting :p | 15:51 |
| jouke | :D | 15:52 |
| -!- vaalbara [~vaalbara@23.94.31.98] has quit [Remote host closed the connection] | 15:53 | |
| amiller | we won't ever be able to click those links in the future and really figure out what's wrong | 15:53 |
| amiller | so the context that's necessary is, at the current or just prior to this time, all of those blocks are reported by the respective services as 'on the main chain' | 15:54 |
| amiller | it would be nice if the services, instead of just including blocks and whether or not they're currently "orphaned", also included whether they appeared to be invalid or valid | 15:55 |
| CodeShark_ | And perhaps some source code and a debug log :p | 15:55 |
| -!- goregrind [~goregrind@unaffiliated/goregrind] has joined #bitcoin-wizards | 15:56 | |
| -!- nullbyte [~NSA@193.138.219.233] has quit [Ping timeout: 248 seconds] | 15:57 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds] | 15:57 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-bkgdklvalylpjmpa] has joined #bitcoin-wizards | 15:59 | |
| -!- shen_noe [~shen_noe@50.252.142.179] has quit [Quit: quitquitquit] | 16:02 | |
| -!- Dr-G2 [~Dr-G@x4d08a093.dyn.telefonica.de] has quit [Ping timeout: 248 seconds] | 16:12 | |
| -!- Dr-G [~Dr-G@x4d08a093.dyn.telefonica.de] has joined #bitcoin-wizards | 16:16 | |
| -!- Dr-G [~Dr-G@x4d08a093.dyn.telefonica.de] has quit [Changing host] | 16:16 | |
| -!- Dr-G [~Dr-G@unaffiliated/dr-g] has joined #bitcoin-wizards | 16:16 | |
| -!- SubCreative [~SubCreati@unaffiliated/cannacoin] has joined #bitcoin-wizards | 16:17 | |
| -!- nephyrin` [~neph@nemu.pointysoftware.net] has quit [Quit: ... besides, it was hot] | 16:20 | |
| -!- nephyrin [~neph@nemu.pointysoftware.net] has joined #bitcoin-wizards | 16:20 | |
| -!- dEBRUYNE [~dEBRUYNE@239-196-ftth.onsbrabantnet.nl] has quit [Ping timeout: 255 seconds] | 16:35 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-bkgdklvalylpjmpa] has quit [Read error: Connection reset by peer] | 16:36 | |
| -!- nullbyte [~NSA@193.138.219.233] has joined #bitcoin-wizards | 16:40 | |
| -!- www [~v3@f052068111.adsl.alicedsl.de] has quit [Ping timeout: 256 seconds] | 17:10 | |
| -!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…] | 17:19 | |
| -!- elastoma [~elastoma@162.248.160.175] has quit [Ping timeout: 246 seconds] | 17:21 | |
| -!- c0rw|away is now known as c0rw1n | 17:25 | |
| -!- droark [~droark@209-6-53-207.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #bitcoin-wizards | 17:37 | |
| -!- jtimon [~quassel@69.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds] | 17:37 | |
| -!- elastoma [~elastoma@162.248.160.175] has joined #bitcoin-wizards | 17:38 | |
| -!- ryanxcharles [~ryan@adsl-108-81-169-137.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 246 seconds] | 17:44 | |
| -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has quit [Ping timeout: 256 seconds] | 17:45 | |
| -!- Tiraspol [~Tiraspol3@83.70.153.95.dyn.idknet.com] has joined #bitcoin-wizards | 17:45 | |
| -!- Tiraspol [~Tiraspol3@83.70.153.95.dyn.idknet.com] has quit [Changing host] | 17:45 | |
| -!- Tiraspol [~Tiraspol3@unaffiliated/tiraspol] has joined #bitcoin-wizards | 17:45 | |
| -!- nullbyte [~NSA@193.138.219.233] has quit [Read error: Connection reset by peer] | 17:54 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-djmyiaeetmyfkfhk] has joined #bitcoin-wizards | 17:56 | |
| -!- wallet42 [~wallet42@185.4.41.147] has joined #bitcoin-wizards | 17:56 | |
| -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has joined #bitcoin-wizards | 18:04 | |
| -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards | 18:07 | |
| -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving] | 18:24 | |
| -!- andytoshi [~andytoshi@unaffiliated/andytoshi] has quit [Read error: Connection reset by peer] | 18:28 | |
| -!- andytoshi [~andytoshi@wpsoftware.net] has joined #bitcoin-wizards | 18:29 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-djmyiaeetmyfkfhk] has quit [Ping timeout: 246 seconds] | 18:39 | |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-bahvuvixsywxqbrc] has joined #bitcoin-wizards | 18:41 | |
| -!- erasmospunk [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has quit [Remote host closed the connection] | 18:46 | |
| -!- Dr-G [~Dr-G@unaffiliated/dr-g] has quit [Disconnected by services] | 18:50 | |
| -!- Dr-G2 [~Dr-G@x4d08a124.dyn.telefonica.de] has joined #bitcoin-wizards | 18:50 | |
| -!- PRab [~chatzilla@2601:40a:8000:8f9b:f8ad:e3a0:cee6:bf3a] has joined #bitcoin-wizards | 19:05 | |
| -!- Giszmo [~leo@pc-185-201-214-201.cm.vtr.net] has joined #bitcoin-wizards | 19:05 | |
| -!- wallet42 [~wallet42@185.4.41.147] has quit [Quit: Leaving.] | 19:09 | |
| -!- wallet42 [~wallet42@185.4.41.147] has joined #bitcoin-wizards | 19:09 | |
| -!- wallet42 [~wallet42@185.4.41.147] has quit [Client Quit] | 19:09 | |
| -!- c0rw1n is now known as c0rw|zZz | 19:12 | |
| -!- flower [~user@189.116.150.203.sta.inet.co.th] has quit [Quit: -] | 19:15 | |
| -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-ahclurwxfedpywrn] has quit [Quit: Connection closed for inactivity] | 19:24 | |
| -!- p15x_ [~p15x@61.149.242.84] has joined #bitcoin-wizards | 19:37 | |
| -!- p15x [~p15x@64.145.91.47] has quit [Ping timeout: 248 seconds] | 19:38 | |
| -!- sergiohlb [~Sergio@unaffiliated/sergiohlb] has quit [Remote host closed the connection] | 19:39 | |
| -!- flower [~user@189.116.150.203.sta.inet.co.th] has joined #bitcoin-wizards | 19:43 | |
| -!- _whitelogger [whitelogge@fehu.whitequark.org] has quit [Read error: Connection reset by peer] | 19:46 | |
| -!- void_hero [~michael@c-98-224-165-72.hsd1.mi.comcast.net] has joined #bitcoin-wizards | 19:48 | |
| -!- _whitelogger_ [whitelogge@fehu.whitequark.org] has joined #bitcoin-wizards | 19:48 | |
| -!- shen_noe [~shen_noe@172.56.39.107] has joined #bitcoin-wizards | 19:52 | |
| -!- shen_noe [~shen_noe@172.56.39.107] has quit [Client Quit] | 19:52 | |
| -!- void_hero [~michael@c-98-224-165-72.hsd1.mi.comcast.net] has quit [Quit: Lost terminal] | 20:09 | |
| -!- akrmn1 [~akrmn@192.95.51.167] has joined #bitcoin-wizards | 20:22 | |
| -!- superobserver [~superobse@unaffiliated/superobserver] has joined #bitcoin-wizards | 20:23 | |
| -!- akrmn [~akrmn@192.95.51.167] has quit [Ping timeout: 264 seconds] | 20:23 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 246 seconds] | 20:29 | |
| -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards | 20:30 | |
| -!- __FranzKafka__ [~FranzKafk@unaffiliated/franzkafka] has joined #bitcoin-wizards | 20:30 | |
| -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has quit [Ping timeout: 256 seconds] | 20:32 | |
| -!- shreyas__ [~shreyas@106.51.133.31] has joined #bitcoin-wizards | 20:43 | |
| -!- ryanxcharles [~ryan@c-67-169-47-156.hsd1.ca.comcast.net] has joined #bitcoin-wizards | 20:43 | |
| dgenr8 | GreenIsMyPepper: what is the bitcoin address referred to in the LN paper? is it the multisig address funded in receiver's payment hub channel? | 20:52 |
| -!- sadoshi [~Sadoshi@31.220.4.123] has joined #bitcoin-wizards | 21:14 | |
| -!- p15x [~p15x@64.145.91.78] has joined #bitcoin-wizards | 21:16 | |
| -!- p15x_ [~p15x@61.149.242.84] has quit [Ping timeout: 264 seconds] | 21:17 | |
| bramc | On the plus side, the likelihood of miners ever getting their shit together to censor particular utxos is seeming extremely unlikely | 21:20 |
| bramc | In all seriousness, what implications does the current mess have on possible future 'lightly' backwards incompatible changes? | 21:21 |
| bramc | We can also infer that miners don't have their shit together to introduce incompatible honey-pot transactions into the network or we'd be seeing a lot more forks. | 21:23 |
| -!- shen_noe [~shen_noe@172.56.39.107] has joined #bitcoin-wizards | 21:28 | |
| -!- shen_noe [~shen_noe@172.56.39.107] has quit [Client Quit] | 21:28 | |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 21:32 | |
| leakypat | bramc is demonstrated to me on how use of the system is reliant on having access to an up to date full node | 21:32 |
| leakypat | Miners do a specific thing and with out an up to date full node, can't be held to account | 21:33 |
| CodeShark | the problem is that they lied | 21:33 |
| leakypat | It also shows they will take shortcuts regardless, if it gives them an advantage | 21:34 |
| CodeShark | we should have never gone to BIP66 95% | 21:34 |
| leakypat | Full nodes first? | 21:34 |
| leakypat | So soft fork= hard fork? | 21:34 |
| CodeShark | or rather, we should have...because I'm glad this came out now...and I think BIP66 is a good thing | 21:34 |
| CodeShark | but the soft fork process completely broke because miners vote for rules they don't even enforce | 21:34 |
| CodeShark | it wasn't supposed to be a hard fork | 21:35 |
| CodeShark | lol | 21:35 |
| leakypat | What percentage of full nodes need to upgrade though ? | 21:35 |
| CodeShark | it was a two phase transition | 21:35 |
| leakypat | Blockchain .info accounts for n% of wallets and are on 0.7.0 | 21:35 |
| CodeShark | a couple days ago we hit the second goal | 21:35 |
| CodeShark | of 95% | 21:35 |
| CodeShark | after 95%, miners are supposed to reject v2 blocks | 21:36 |
| CodeShark | but the miners voted for the change even though they were not checking this at all | 21:36 |
| dgenr8 | supporting v3 was easy. 1-byte change. | 21:36 |
| * dgenr8 has updated his working thesis to "nobody really knows how LN is supposed to work" | 21:37 | |
| leakypat | So we should have waited until we have proof no miner has built a v2 block for n blocks ? | 21:37 |
| CodeShark | the rule was 950 of the last 1001, I believe | 21:37 |
| CodeShark | v3 blocks | 21:37 |
| leakypat | Before full nodes start rejecting v3? | 21:37 |
| CodeShark | yes | 21:37 |
| leakypat | Makes sense | 21:37 |
| leakypat | Rejecting v2 sorry | 21:38 |
| -!- Giszmo [~leo@pc-185-201-214-201.cm.vtr.net] has quit [Quit: Leaving.] | 21:38 | |
| CodeShark | the scary part is if they can't even enforce a one line if statement, how can we trust them to enforce anything at all :p | 21:38 |
| leakypat | I think he lesson is they should never be trusted | 21:38 |
| leakypat | The | 21:38 |
| CodeShark | that's the way it was supposed to work - if wallets and explorer apps actually did proper validation it wouldn't be our problem | 21:39 |
| CodeShark | it would be the dumb miners' problem | 21:39 |
| CodeShark | but wallets and explorer apps don't do proper validation either...because they trust miners to do it...derp | 21:40 |
| leakypat | Quite honestly not enough companies engage with core development | 21:40 |
| leakypat | Or follow it | 21:40 |
| leakypat | They see it as an API they call | 21:40 |
| bramc | technically bip66 is a hard fork, but it's a trivial fix of no feature consequence whatsoever | 21:42 |
| leakypat | The problem is that there are companies like bc.i who probably can't upgrade their systems | 21:42 |
| leakypat | And could never be relied on too | 21:42 |
| gmaxwell | bramc: no it isn't. Go spin up 0.8 ... syncs the chain just fine. But BIP66 is in force. No hardfork. | 21:42 |
| CodeShark | bramc: is it? there are transactions that are invalid before BIP66 that are now valid | 21:42 |
| CodeShark | ? | 21:42 |
| bramc | er, well, maybe we need better vernacular. 'hard' fork means that older clients wouldn't accept it, which bip66 is clear of | 21:42 |
| leakypat | backwards compatible is the definition I believe | 21:43 |
| bramc | So I was wrong. What's the term for a change where older dumb miners might make invalid blocks? | 21:43 |
| -!- mjerr [~mjerr@p578EAB34.dip0.t-ipconnect.de] has joined #bitcoin-wizards | 21:43 | |
| bramc | That's somewhere between hard fork and soft fork | 21:44 |
| bramc | I mean, it's a soft fork, but it's more like a pillow than butter | 21:44 |
| leakypat | A rough fork | 21:44 |
| jcorgan | it's like semi-soft cheese | 21:44 |
| leakypat | A spork? | 21:44 |
| bramc | There are a few more things in the pipeline which are also rough forks, and it's fairly likely that miners will learn from this one that they can fuck over other miners by introducing subtly invalid transactions into the network | 21:46 |
| bramc | So the next one might be a lot rougher | 21:46 |
| CodeShark | so what's the solution? | 21:48 |
| CodeShark | I mean, I know what the long-term solution is | 21:48 |
| CodeShark | what's the short term solution? | 21:48 |
| -!- bedeho [~bedeho@195.159.234.190] has joined #bitcoin-wizards | 21:48 | |
| bramc | Uh... | 21:51 |
| bramc | I'm open to suggestions | 21:51 |
| bramc | Doing a soft fork where it's trivial to tell when old stuff is invalid seems about as easy as it gets | 21:51 |
| CodeShark | we should definitely place a moratorium on soft forks for the time being...that goes without saying :p | 21:52 |
| jcorgan | name and shame (where possible) | 21:52 |
| leakypat | Miners first | 21:52 |
| leakypat | Name and shame clean up etc | 21:52 |
| CodeShark | miners are in a way easier to target because a few big pools are enough to sway consensus | 21:52 |
| leakypat | Once proof exists that no invalid block has been built for n time | 21:52 |
| CodeShark | (which isn't necessarily such a good thing) | 21:52 |
| leakypat | Then nodes upgrade? | 21:52 |
| CodeShark | but the nodes that really should be validating are wallets, IMHO | 21:53 |
| leakypat | Major companies get big warnings | 21:53 |
| bramc | Maybe spv changeover should be integrated and wallets should be able to defend themselves against busted services? | 21:53 |
| leakypat | With lists confirming upgrades are done or not made public | 21:53 |
| jcorgan | though the constant pointing out of bc.i's incompetence doesn't seem to have made any difference | 21:53 |
| leakypat | But with a hard deadline | 21:53 |
| leakypat | jcorgan: you can only do so much , one has to wonder what hey will do in a hard fork | 21:54 |
| leakypat | If they are stuck on 0.7.0 | 21:54 |
| bramc | What you really want to do is burn the miners - make the ones who aren't doing it right *consistently* lose | 21:55 |
| gmaxwell | presumably they wildly misestimate what work dealing with it will take and think they can just make a small patch. | 21:56 |
| bramc | Like, right now they only lose if they happen to build on an invalid block which somebody else made. If they had to proactively set a flag indicating that they'd upgraded that would get their attention | 21:56 |
| bramc | Although of course they might set the flag without fixing anything, but at least it would burn the ones who literally did nothing | 21:56 |
| CodeShark | bramc: the solution ultimately needs to be economic...game theory | 21:57 |
| CodeShark | but... | 21:57 |
| CodeShark | we're far from that :p | 21:57 |
| leakypat | A lot of the block explorers probably use pre 0.10 because they expect the blocks to arrive in order | 21:58 |
| CodeShark | if the game theory is right people will do what needs to be done by themselves | 21:58 |
| CodeShark | but... | 21:58 |
| jcorgan | CodeShark: true, but sometimes the feedback loops have long delays | 21:58 |
| -!- zooko [~user@c-67-190-6-198.hsd1.co.comcast.net] has joined #bitcoin-wizards | 21:58 | |
| bramc | gmaxwell, Not sure what you mean, isn't support for the new thing a fairly trivial patch? | 21:58 |
| jcorgan | for miners, it seems the financial penalty of losing coinbase revenue after orphaning will at least put real pressure on them | 21:59 |
| CodeShark | jcorgan: if it happened more often perhaps that would be true | 21:59 |
| CodeShark | if it only happens once every few months many miners might still carry on with their current strategy | 22:00 |
| bramc | Yeah the amount of financial burn they've gotten this time hasn't been all that much. If they had to put in a flag that would get them consistently orphaned | 22:00 |
| bramc | Unfortunately many of the miners who are causing problems also don't accept any transactions, so keeping bad transactions circulating for a while just to fuck with them wouldn't help | 22:00 |
| bramc | That would be fun though - have full nodes circulate bad transactions for a few days after the changeover | 22:01 |
| jcorgan | hmm | 22:01 |
| CodeShark | ideally this would happen more often...but only the nonvalidating miners would suffer | 22:02 |
| bramc | Or somebody could 'altruistically' connect directly to all the full nodes they could and send some out of date transactions | 22:02 |
| -!- jae_ [~jae@204.14.159.153] has quit [Remote host closed the connection] | 22:02 | |
| bramc | CodeShark, Remember that this isn't actually a good state of affairs, as much fun as enacting vengeance might be | 22:02 |
| CodeShark | bramc: this isn't about vengeance - it's just economics :) | 22:02 |
| jcorgan | not vengeance, more like proactive antiseptic cleansing | 22:03 |
| CodeShark | we want those who aren't following the rules to be basically ignored by the rest of the network | 22:03 |
| CodeShark | but...lol | 22:04 |
| jcorgan | what's to stop someone from doing it now? | 22:04 |
| jcorgan | btw, did anyone do a diff on the chain tips after the fork resolved? were there any actual TXes affected? | 22:05 |
| CodeShark | I don't have an old node running | 22:05 |
| CodeShark | I'd have to grab the bad blocks from somewhere | 22:05 |
| jcorgan | i think one of the bad blocks had ~1600 transactions | 22:05 |
| -!- p15x [~p15x@64.145.91.78] has quit [Ping timeout: 256 seconds] | 22:05 | |
| bramc | It only takes one bad transaction to invalidate the whole thing | 22:06 |
| bramc | Presumably there were other forks which got orphaned fast so nobody noticed | 22:06 |
| jcorgan | what i mean is, i'm hoping that the valid chain mined all those from their own mempool, so there were no actual TXes that got confirmed on the bad chain that didn't also get confirmed on the valid one | 22:07 |
| bramc | jcorgan, *shrug* shit happens | 22:07 |
| bramc | Although that is an interesting question. Presumably there had to be a confused wallet which issued the bad transaction in the first place | 22:08 |
| CodeShark | could have been mempool backlog, no? | 22:08 |
| CodeShark | how deep did the fork go? | 22:08 |
| jcorgan | this one was 3 blocks | 22:08 |
| jcorgan | the first one was 6 | 22:08 |
| gmaxwell | this most recent event had a lot of transactions. | 22:08 |
| bramc | jcorgan, The one yesterday was 6 blocks | 22:09 |
| CodeShark | which of the three blocks was the 1600 tx one? | 22:09 |
| bramc | How smart are the wallets about the changeover? | 22:09 |
| CodeShark | not very | 22:09 |
| CodeShark | actually, not at all for the most part | 22:10 |
| bramc | Were wallets supposed to have all changed over a while ago to avoid problems? | 22:10 |
| CodeShark | but what's worse is that unless you run a full validator you still cannot invalidate a block | 22:10 |
| gmaxwell | of the three two had lots of transactions. | 22:10 |
| CodeShark | this was a special case, bramc, where the invalidation could have been done with headers only | 22:10 |
| CodeShark | in general it's not possible | 22:10 |
| bramc | It seems like it should be three step: 1) miners start accepting the new transaction type 2) wallets start defaulting to the new type 3) miners start orphaning the old type | 22:10 |
| gmaxwell | bramc: bitcoin core never saw these blocks, btcd never saw these blocks. Everything else did. | 22:10 |
| bramc | gmaxwell, That would seem to imply that they were propagating quite well | 22:11 |
| -!- shesek [~shesek@77.125.92.26] has quit [Ping timeout: 246 seconds] | 22:11 | |
| gmaxwell | the blocks had 1142/2315/1599 transactions respectively. | 22:12 |
| CodeShark | wow - that's quite a few | 22:12 |
| jcorgan | that's why i'm wondering what the actual TX diff was | 22:12 |
| CodeShark | what were the block numbers? | 22:12 |
| gmaxwell | yea, I hoped someone would do that while I was out. | 22:12 |
| jcorgan | me too :-) | 22:12 |
| bramc | followed by 4) regular full nodes stop distributing no-longer-valid transactions as part of the program to fuck with miners who haven't gotten with the program :-) | 22:12 |
| gmaxwell | 363999' 363998' 363997' | 22:13 |
| bramc | gmaxwell, Any idea how many of the transactions were invalid? | 22:13 |
| CodeShark | I would have if I had an older version node running - if anyone has the bad blocks I can do a diff | 22:13 |
| gmaxwell | bramc: almost certantly none of them. | 22:13 |
| gmaxwell | bramc: we haven't had a non-canonical signature at all in the chain for over three months. | 22:13 |
| bramc | gmaxwell, So, uh, what caused the invalidation? | 22:13 |
| gmaxwell | oh ha! I must be incorrect. | 22:14 |
| CodeShark | bc.i still has the three blocks apparently... | 22:14 |
| CodeShark | but... | 22:14 |
| CodeShark | lol | 22:14 |
| gmaxwell | bramc: I thought 7' was v2, but its tagged v3.. | 22:14 |
| CodeShark | I don't really want to use that as my source for data | 22:14 |
| gmaxwell | bramc: so it must actually have an encoding violation. | 22:14 |
| bramc | (Bram Doesn't Do Ops, hence my not having any info on blocks to share) | 22:15 |
| gmaxwell | CodeShark: they don't have a way to fetch the raw block AFAIK. | 22:15 |
| bramc | gmaxwell, It would seem like a strange coincidence for a new violation to show up right when they become illegal, wouldn't it? | 22:15 |
| CodeShark | gmaxwell: you can still grab the tx hashes | 22:15 |
| gmaxwell | oh sorry, I was looking at the wrong tab. | 22:15 |
| gmaxwell | bramc: 7' is just tagged with v2, thats the only invalidity. | 22:16 |
| CodeShark | in the worst of cases you can just scrape the site :p | 22:16 |
| bramc | gmaxwell, Uh... there's only so much you can do to save people from themselves | 22:16 |
| gmaxwell | bramc: the whole scheme is _intended_ to cause some orphaning, to get the stragling hashpower to upgrade or give up. | 22:16 |
| gmaxwell | bramc: the reason that there have been no violations is because miners have been rejecting those transactions since 0.8. People actually still create them all the time, in rather large volume. | 22:17 |
| bramc | Here I am, foolishly offering suggestions on the assumption that this scale of bad couldn't have happened if reasonable measures were followed, but no, it was all done right to begin with | 22:17 |
| gmaxwell | There are old versions of armory and bc.i's mobile wallet, for example, that pump them out. But then they don't get mined, and people go change their software. | 22:17 |
| bramc | that's... depressing | 22:18 |
| bramc | People still have this weird thing where they think end users get some advantage out of their software not being on autoupdate. It's nuts. | 22:19 |
| -!- CodeShark_ [~androirc@cpe-76-167-237-202.san.res.rr.com] has quit [Read error: Connection reset by peer] | 22:19 | |
| gmaxwell | bramc: yea, well we did have issues with the BIP16 deployment that we learned from. E.g. we made sure in BIP66 to phase out the transactions in question years before; and completely eliminated them from the network long before... then phased in with a very high threshold... I'm certantly interested in knowing what more we could do. | 22:19 |
| -!- CodeShark_ [~androirc@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards | 22:19 | |
| gmaxwell | I know a few things we could improve on-- e.g. we overly focused on miners and not enough of other bits of public infrastructure. | 22:19 |
| CodeShark | so the three blocks are 3ae1223... 63f97f... and 12dbd4... ? | 22:20 |
| bramc | Yes the public infrastructure clearly could use some help, but I for one am at a loss as to any major process improvements to be had | 22:20 |
| bramc | Set the 'lazy and incompetent' bit to false? | 22:21 |
| jcorgan | CodeShark: i think 12db is the first valid one, could be wrong though | 22:21 |
| gmaxwell | CodeShark: yea, and thats a weird way to truncate the hashes, I use the trailing bytes! :) | 22:21 |
| CodeShark | yeah, probably better to use the trailing bytes | 22:21 |
| leakypat | Ok, so we knew that there were v2 blocks still being produced but had assurances from 95% that they wouldn't be built on ? | 22:21 |
| bramc | leakypat, Yes that's the crux of the problem, the orphaning would have had no problems if they hadn't been lying | 22:21 |
| gmaxwell | leakypat: right, the v2 block at 363997' is unsurprising and harmless. | 22:22 |
| leakypat | gmaxwell: so not much more you can do on the miners side then, public lists of infrastructure not upgrading/ incompatible | 22:22 |
| bramc | Also, with regards to the transactions which got orphaned, I wonder how far back wallets go when noticing reorgs, and it might be good if somebody as a public service would collect those old orphan blocks and reintroduce their transactions (I think that was the conversation y'all were just having and I wasn't understanding) | 22:22 |
| leakypat | although hard to fully verify, public assurances from the main infra players that they have upgraded would at least focus them | 22:23 |
| bramc | Does bitcoin core keep old transactions in a stale mempool and bring them back in the case of a reorg? | 22:23 |
| gmaxwell | leakypat: basically 95% means that 5% will be producing orphans which is only a small multiple worse than the levels that happen ordinarily due to latency, they'd be unlikely to manage a two block reorg (0.05^2), plus the 5% presumably would drop rapidly once the orphaning started. | 22:23 |
| bramc | Yeah for it to get up to 6 means that something is busted | 22:24 |
| gmaxwell | bramc: every bitcoin node is a service which reintroduces transactions. They're returned to the mempool when disconnecting the old block. | 22:24 |
| jcorgan | yeah, in part this only grabbed our attention because the first instance was two miners that made up 40% of hashrate | 22:24 |
| bramc | gmaxwell, Well gee, how am I supposed to offer suggestions in the midst of basic competence already being in place? | 22:24 |
| gmaxwell | bramc: so the only reason there should be transactions that fell out of the chain is because they were conflicted via double spending at the time they were initially mined. | 22:25 |
| bramc | Note to self: Don't make a new cryptocurrency without at least using the existing bitcoin codebase as a reference | 22:25 |
| -!- shesek [~shesek@IGLD-84-229-153-73.inter.net.il] has joined #bitcoin-wizards | 22:25 | |
| jcorgan | so it went on 6 blocks before the system routed around it | 22:25 |
| zooko | bramc: ;-) | 22:26 |
| bramc | If we try to estimate how many miners are being 'bad', there needs to be separate estimates of how many miners are/were creating bad blocks vs. not doing their necessary validation | 22:27 |
| zooko | Yeah, you core folks do impressive work. | 22:28 |
| jcorgan | zooko: heh, i've staked my retirement on that fact :-) | 22:28 |
| jcorgan | no pressure guys | 22:28 |
| bramc | If we figure that it took a day for something bad to happen, and that 95% of new blocks were valid, that means... after 5 bad blocks got made, one of them got to 6. That seems highly implausible. If it were that bad it wouldn't have been able to self-heal at all | 22:29 |
| gmaxwell | bramc: its too little data to get a good esimate. | 22:29 |
| gmaxwell | bramc: well we can distinguish: non-upgraded blocks are v2, while lacking-validation-blocks are "v3". | 22:29 |
| gmaxwell | each of these two incidents have been a v2 and then a run of v3. There have also been a couple v2 orphans in the last two days that didn't get extended. | 22:30 |
| bramc | gmaxwell, Yes it's possible that the 6 was simply unlucky, but it seems likely that a fair number of miners kept making v2 blocks even after they voted for v3 | 22:30 |
| gmaxwell | e.g. there was one right before the run of 6. | 22:30 |
| -!- droark [~droark@209-6-53-207.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has quit [Quit: ZZZzzz…] | 22:30 | |
| gmaxwell | bramc: yea, no, we know for a fact that it was on the order of half the hashpower mining without validating there. | 22:31 |
| gmaxwell | but we also know that some of that have 'improved' their behavior. | 22:31 |
| bramc | gmaxwell, That's what I was afraid of. | 22:31 |
| gmaxwell | Though improved may only mean that they're also validating enough to reject v2 now. :) | 22:31 |
| bramc | In which case that run of 6 could easily have gotten way, way longer | 22:31 |
| gmaxwell | (but perhaps not a v3 block with a invalid transaction in it) | 22:32 |
| bramc | gmaxwell, That should be easy enough to test - make a peer which connects to as many full nodes as it can and drips bad transactions to them | 22:32 |
| gmaxwell | bramc: yes, it only was as short as it was because: it was mining blocks at ~half rate (due to the other half of the network being on the other side), and because the major operators responsible for that were able to be prodded. | 22:32 |
| leakypat | So we can't rely on miners to validate? | 22:32 |
| leakypat | Thy would rather hope for the best and get a speed advantage | 22:33 |
| gmaxwell | bramc: not so useful; because even non-upgraded nodes will not mine invalid txn. | 22:33 |
| bramc | Oh right, hmm | 22:33 |
| gmaxwell | I mean someone could burn ~25 bitcoin and intentionally create such a block. | 22:33 |
| bramc | It's unlikely that anybody has enough mining power that it's worth them sabotaging everybody else | 22:34 |
| leakypat | But also we can't reliably tell how many full nodes on the network have upgraded | 22:34 |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-bahvuvixsywxqbrc] has quit [Ping timeout: 248 seconds] | 22:34 | |
| gmaxwell | 4ish months ago there was a miner who was mining the invalid txn-- tracked him down, he was on current software but someone seems to have 'optimized' out all his signature validation. (he fixed it right away). | 22:34 |
| gmaxwell | so it's possible that there is another genius like that out there and flooding invalid txn will result in a block. | 22:35 |
| jcorgan | seems like a useful prophylactic measure | 22:35 |
| phantomcircuit | leakypat, we should figure out a way to make it so miners on margin make more money by validating blocks than by not | 22:35 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 276 seconds] | 22:35 | |
| gmaxwell | Then again, some kind soul on reddit (of the sort of typical kind souls on reddit) already accused Peter Todd and of having created an invalid transaction (even though there had been none) in order to make a point about blocksize... so uh.. yea, I'm not going to do it. | 22:35 |
| bramc | http://www.thedailywtf.com/ | 22:36 |
| phantomcircuit | which probably means they need to soft fork a massive drop in blocksize into place | 22:36 |
| phantomcircuit | which is maybe a bit circular... | 22:36 |
| phantomcircuit | fix the soft fork issues with a softfork | 22:36 |
| phantomcircuit | goto 1 | 22:36 |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-lfwqbtbciqsokmaa] has joined #bitcoin-wizards | 22:36 | |
| -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 276 seconds] | 22:36 | |
| leakypat | I see, hence bramc suggestion of getting invalid transactions into the miners blocks? | 22:38 |
| leakypat | They would have to check each one | 22:38 |
| phantomcircuit | leakypat, that probably wont work | 22:38 |
| -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Quit: Leaving] | 22:38 | |
| gmaxwell | bramc: a possible argument is that perhaps we've done soft-forks too infrequently... leaving people poor at handling them. | 22:39 |
| phantomcircuit | i dont think any of the major miners are including transactions they haven't verified | 22:39 |
| bramc | gmaxwell, They might not be much better after this mess, nobody got burned all that bad | 22:40 |
| zooko | gmaxwell: my trusted colleague Brian Warner recently said this to me. Something like: things that happen less often than every few weeks will fail when you try to make them happen. | 22:41 |
| zooko | gmaxwell: on the topic of software/protocol upgrades. | 22:41 |
| leakypat | Yeah, there is a monthly upgrade of the libraries where i work, regardless | 22:42 |
| leakypat | Everyone has to sync up | 22:42 |
| leakypat | With sometimes useless calls with dependent parties, but never the less, the process works | 22:42 |
| zooko | *nod* | 22:42 |
| gmaxwell | I worry that there are already a lot of marginal participants; too much throughput will push them out-- that isn't a good way to be inclusive. | 22:42 |
| zooko | Hm. | 22:43 |
| zooko | Isn't that sort of the opposite of what you were just saying? | 22:43 |
| zooko | If "marginal" = "careless/inattentive/etc." | 22:43 |
| leakypat | So there would be a monthly Bitcoin core release call of some kind | 22:43 |
| leakypat | Sounds logistically a nightmare :/ | 22:44 |
| gmaxwell | zooko: hm not quite, you can be resource strapped but still handle a big upgrade once a year. | 22:44 |
| gmaxwell | But not be able to handle one once a month. | 22:44 |
| zooko | Hm. | 22:45 |
| leakypat | You would think the 700m vc funding could throw in a few coordination heads | 22:45 |
| gmaxwell | and sure it looks like marginal == inattentive; but thats only because we only see the failures. | 22:45 |
| leakypat | (By heads I mean head counts) | 22:46 |
| bramc | leakypat, You didn't think any of that VC funding would go towards making the ecosystem healthier, did you? | 22:46 |
| leakypat | bramc: my naïveté is bottomless | 22:46 |
| bramc | A true malleability fix might be dicier than this, because it causes some utxos to be spent which older full nodes don't realize are already spent | 22:48 |
| gmaxwell | some of it has-- but really, who are you going to fund to do that? | 22:48 |
| jcorgan | gee, if only there were an industry consortium around bitcoin that could take on these sorts of longer term thinking, ecosystem related issues, and be funded by lots of ecosystem participants as a way of helping ensure the "system" will support their own more narrower goals | 22:49 |
| bramc | gmaxwell, A fair number of the entities which aren't doing validation properly probably have investment | 22:49 |
| bramc | jcorgan, I'm sure one could scrounge up a few thieves and pedophiles to sit on the board of such an entitiy | 22:50 |
| -!- roconnor [~roconnor@e120-pool-d89a7a26.brdbnd.voicenetwork.ca] has quit [Quit: Konversation terminated!] | 22:51 | |
| CodeShark | gmaxwell: I don't really have a good setup to do a diff on the transactions - but if you want me to I can scrape them | 22:52 |
| CodeShark | I have the tx hashes in files | 22:53 |
| jcorgan | in all seriousness, though, individual ecosystem particpants usually have too narrow a view to directly invest in "greater good" type things, but are often willing to set aside a portion of their investment capital to fund an organization that would focus exclusively on those type of things, as long as everyone else were putting money in the pot as well | 22:53 |
| CodeShark | if you have a node with txindex you can easily see which ones got dropped | 22:54 |
| CodeShark | unfortunately, I don't have such a node accessible atm | 22:54 |
| jcorgan | but bitcoin has never seen an organization that actually fulfills that role | 22:54 |
| CodeShark | the bitcoin foundation doesn't count? :p | 22:55 |
| jcorgan | lol | 22:55 |
| gmaxwell | CodeShark: if you've got the tx hashes in the orphaned blocks, skipping the coinbase txn (for obvious reasons) give to me and I can quickly check which made it into the main chain. | 22:56 |
| CodeShark | one of the blocks apparently is empty | 22:56 |
| bramc | So it's fair to say that the 95% which voted were fairly consistent about producing new valid blocks on schedule, but roughly half of them (weighted by mining power) aren't/weren't doing validation properly | 22:57 |
| CodeShark | 6053a7b0d5a2 appears to be empty | 22:57 |
| -!- p15x [~p15x@123.118.83.203] has joined #bitcoin-wizards | 22:58 | |
| bramc | It's hard to see how to avoid the moral hazard here. Validating causes at least a little bit of latency, which costs something, and the ones who aren't validating hardly got burned. | 22:58 |
| CodeShark | I can send you the other two minus the coinbase | 22:58 |
| bramc | On the other hand, since headers-only validation could have handled this just fine, maybe that would be enough and should be what's emphasized in the future. | 22:58 |
| gmaxwell | CodeShark: gimme gimme | 22:58 |
| CodeShark | ok, sending an email...one sec | 22:58 |
| gmaxwell | bramc: nah, just lucky in this case. in the BIP-16 change there were actual invalid txn mined. | 22:59 |
| leakypat | I'm sure there are volunteers out there who would coordinate things- it's a core dev stakeholder coordinator role | 22:59 |
| leakypat | They need to be able to understand stuff, but really good at bugging the crap out of people and tracking things | 22:59 |
| jcorgan | sometimes volunteers emerge with the time/effort/willingness to do that | 22:59 |
| gmaxwell | leakypat: if things weren't coordinated here it was only because it wasn't thought of, I mean, we got 95% (lol) hashpower in three months onto this; there was significant effort coordinating with miners, but they didn't exactly volunteer "oh btw, we're not actually validating" | 23:00 |
| bramc | Core devs tend to not be so big on that whole 'talking to people' thing | 23:00 |
| leakypat | gmaxwell: I meant more doing regular calls with the big companies etc | 23:00 |
| bramc | gmaxwell, 'We're only 5% of all hashpower, us not validating hardly breaks anything' | 23:01 |
| CodeShark | gmaxwell: sent | 23:01 |
| leakypat | don't get me wrong , I think it is the companies themselves that should be being proactive | 23:03 |
| gmaxwell | I don't. I mean, I don't think "should" matters. | 23:04 |
| gmaxwell | nothing good gets done by spending too much time worrying about should. | 23:04 |
| -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards | 23:05 | |
| jcorgan | a company might not invest $X directly in something that only has long term benefit, because it puts them at an immediate disadvantage to their competitors, but if if "everyone" were to invest $X in a common consortium type organization that look after those type of things, then they'd all benefit and not suffer relative to one another | 23:06 |
| jcorgan | the trick is in organizing the whole thing | 23:06 |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-lfwqbtbciqsokmaa] has quit [Ping timeout: 248 seconds] | 23:13 | |
| CodeShark | bramc: headers-only validation would still miss 99.999% of problems :p | 23:14 |
| -!- nullbyte [NSA@gateway/vpn/mullvad/x-bckktuvbyaqhppme] has joined #bitcoin-wizards | 23:15 | |
| CodeShark | this was one of the very few exceptions where it would have actually sufficed | 23:15 |
| -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards | 23:15 | |
| CodeShark | until someone included a bad DER in a v3 block :p | 23:15 |
| CodeShark | the fundamental problem is quite simple - it's too costly to verify, it isn't sufficiently costly not to | 23:17 |
| CodeShark | that's really what it boils down to :) | 23:17 |
| CodeShark | fix those things and as if by magic miners will miraculously stop doing this crap | 23:18 |
| CodeShark | I still think that ultimately wallets are the most important validator nodes | 23:21 |
| CodeShark | and ironically these are the nodes that are least likely to invest in full validation | 23:21 |
| CodeShark | relay nodes are also important - it would be better to err on the side of relaying invalid data than on not relaying valid data...and have the wallet nodes do final validation | 23:25 |
| CodeShark | but...it's a pipedream :p | 23:26 |
| gmaxwell | CodeShark: well there is a counter argument that relaying invalid data increases exposure for those behind you. | 23:29 |
| CodeShark | gmaxwell: true...but we probably shouldn't be relying on that :) | 23:30 |
| zooko | gmaxwell: +1 on 'down with "should"' | 23:31 |
| gmaxwell | sure sure, but its an argument against making it worse. The other is that its easy to open up DOS vectors that way. | 23:31 |
| -!- zooko [~user@c-67-190-6-198.hsd1.co.comcast.net] has quit [Quit: goodnight folks] | 23:31 | |
| -!- Mably [~Mably@unaffiliated/mably] has joined #bitcoin-wizards | 23:32 | |
| CodeShark | gmaxwell: ideally, relay nodes would also validate...and validate correctly. but wallets not validating correctly opens up even more attack vectors | 23:37 |
| CodeShark | and from an incentives perspective, the wallet node operators stand to lose a lot more from improper validation | 23:39 |
| bramc | Technically validating just creates a latency problem. You can accept new blocks immediately and start mining them, then invalidate in the background. But that requires some actual engineering | 23:39 |
| bramc | Like, an engineer might have to spend a few days or maybe even a few weeks getting it to work right. | 23:39 |
| gmaxwell | yea, a perfectly reasonable thing to do would be to start early but not relay until you've caught up the validation; but if you're getting it wrong the failure is silent. | 23:40 |
| CodeShark | it's unenforceable, though | 23:41 |
| CodeShark | the only way to enforce it is economically | 23:41 |
| bramc | gmaxwell, Or if you want to be a jerk about it, relay immediately but validate in the background and throw out the bad one in favor of a good one if it gets invalidated | 23:42 |
| CodeShark | many miners probably would run something like that if it didn't eat into profits...but it's unenforceable...and I think it's safe to say that most miners will not do this customization correctly :p | 23:43 |
| CodeShark | so it would have to come prepackaged | 23:44 |
| -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving] | 23:44 | |
| CodeShark | did you finish compiling the double-spend list, gmaxwell/ | 23:48 |
| CodeShark | ? | 23:48 |
| gmaxwell | CodeShark: no, turned out I'd broken my w/ txindex nodes to observe the fireworks the other day, reindexing now. :( | 23:49 |
| CodeShark | derp :p | 23:49 |
| gmaxwell | I can share the list with someone else if they have a txindex handy? | 23:50 |
| -!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-wizards | 23:50 | |
| -!- cornusammonis [~Cornus@pool-173-73-140-137.washdc.fios.verizon.net] has joined #bitcoin-wizards | 23:51 | |
| CodeShark | I used to always run a synched database with every single possible index you might find useful...but I stopped doing that a long time ago | 23:52 |
| CodeShark | I even indexed tx inputs that were in the same set of transactions | 23:52 |
| CodeShark | I'm considering revisiting that project...but I need a backend that is more efficient with insertions | 23:53 |
| -!- cornus_ammonis [~Cornus@pool-173-73-140-137.washdc.fios.verizon.net] has quit [Ping timeout: 256 seconds] | 23:55 | |
| -!- CoinMuncher [~jannes@178.132.211.90] has joined #bitcoin-wizards | 23:55 | |
| CodeShark | it's really nice to be able to do queries like "grab me all the dependencies back n generations from this transaction" | 23:55 |
| CodeShark | or "find whether input X connects to output Y via some chain" | 23:56 |
| CodeShark | lol | 23:56 |
| -!- sy5error [~sy5error@unaffiliated/sy5error] has quit [Remote host closed the connection] | 23:56 | |
| -!- shen_noe [~shen_noe@172.56.39.107] has joined #bitcoin-wizards | 23:56 | |
| CodeShark | it would be nice to store even invalid stuff for analysis | 23:58 |
| --- Log closed Mon Jul 06 00:00:02 2015 | ||
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!