--- Log opened Sun Jul 05 00:00:01 2015
00:00 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards
00:03 -!- Mably [~Mably@unaffiliated/mably] has joined #bitcoin-wizards
00:20 -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards
00:22 -!- p15x_ [~p15x@111.193.190.75] has joined #bitcoin-wizards
00:24 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has quit [Quit: sparetire_]
00:25 -!- p15x [~p15x@64.145.91.48] has quit [Ping timeout: 265 seconds]
00:30 -!- 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:36 -!- sy5error [~sy5error@unaffiliated/sy5error] has quit [Remote host closed the connection]
00:42 -!- davi [~davi@gnu/davi] has quit [Ping timeout: 246 seconds]
01:00 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds]
01:03 -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has joined #bitcoin-wizards
01:19 -!- davi [~davi@gnu/davi] has joined #bitcoin-wizards
01:20 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards
01:23 -!- drwin [~drwin@88-103-255-166.jes.cz] has joined #bitcoin-wizards
01:28 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]
01:52 -!- Mably [~Mably@unaffiliated/mably] has joined #bitcoin-wizards
01:59 -!- davi [~davi@gnu/davi] has quit [Ping timeout: 246 seconds]
02:01 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Remote host closed the connection]
02:02 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards
02:02 -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Quit: Leaving]
02:05 -!- davi [~davi@gnu/davi] has joined #bitcoin-wizards
02:20 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds]
02:25 -!- bosma is now known as superkai64
02:25 -!- superkai64 is now known as bosma
02:28 -!- wallet42 [~wallet42@185.4.41.147] has quit [Quit: Leaving.]
02:42 -!- davi [~davi@gnu/davi] has quit [Ping timeout: 246 seconds]
02:45 -!- p15x_ [~p15x@111.193.190.75] has quit [Max SendQ exceeded]
02:46 -!- p15x [~p15x@64.145.91.60] has joined #bitcoin-wizards
02:49 -!- p15x_ [~p15x@64.145.91.75] has joined #bitcoin-wizards
02:51 -!- p15x [~p15x@64.145.91.60] has quit [Ping timeout: 252 seconds]
02:53 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-wizards
02:59 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
03:01 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
03:02 -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has quit []
03:07 -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has joined #bitcoin-wizards
03:08 -!- davi [~davi@gnu/davi] has joined #bitcoin-wizards
03:08 -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has quit [Max SendQ exceeded]
03:09 -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has joined #bitcoin-wizards
03:10 -!- bedeho2 is now known as bedeho
03:10 < CodeShark_> So is the revocation mechanism you're referring to something else, gmaxwell?
03:11 < 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:12 < 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:13 < 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:14 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-wizards
03:18 < CodeShark_> that's probably the single greatest complication
03:23 < CodeShark_> if we could find a way around this it would make the idea potentially much more viable
03:29 < CodeShark_> I was pondering hypothetical schemes where it would be the noncooperating party responsible for this rather than the cooperative party
03:30 < CodeShark_> But you ultimately run into the retroactive invalidation issue...
03:32 -!- 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:36 -!- chmod755 [~chmod755@unaffiliated/chmod755] has quit [Quit: Ex-Chat]
03:38 -!- davi [~davi@gnu/davi] has quit [Ping timeout: 246 seconds]
03:47 < 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:48 < 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:49 -!- davi [~davi@gnu/davi] has joined #bitcoin-wizards
03:50 < CodeShark_> I guess the next best thing is delegating this task to others (potentially for a fee)
03:51 < 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:53 -!- 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:55 < 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:56 < 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:57 < 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:58 < 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:59 < 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 :)
04:01 < nsh> how compact are proofs-of-space?
04:01 < nsh> (cc amiller)
04:02 < 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:03 < 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:04 < 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:07 -!- p15x_ [~p15x@64.145.91.75] has quit [Ping timeout: 265 seconds]
04:08 -!- erasmospunk [~erasmospu@176.92.61.74] has joined #bitcoin-wizards
04:09 < 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:10 -!- erasmosp_ [~erasmospu@179.43.156.98] has joined #bitcoin-wizards
04:11 < CodeShark_> or at least you could reduce the number of outputs you're looking for
04:11  * nsh nods
04:12 -!- 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:13 < 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:25 -!- davi [~davi@gnu/davi] has quit [Ping timeout: 246 seconds]
04:28 -!- spinza [~spin@197.89.10.176] has quit [Ping timeout: 244 seconds]
04:56 -!- p15x [~p15x@64.145.91.58] has joined #bitcoin-wizards
05:04 -!- belcher [~belcher-s@unaffiliated/belcher] has joined #bitcoin-wizards
05:21 -!- spinza [~spin@197.89.186.249] has joined #bitcoin-wizards
05:39 -!- nullbyte [NSA@gateway/vpn/mullvad/x-kbszivkytihirbvx] has quit [Ping timeout: 255 seconds]
05:40 -!- nullbyte [NSA@gateway/vpn/mullvad/x-qywjseuybrysyogn] has joined #bitcoin-wizards
05:47 -!- nullbyte [NSA@gateway/vpn/mullvad/x-qywjseuybrysyogn] has quit [Ping timeout: 256 seconds]
05:48 -!- merlincorey [merlin@nginx/adept/merlincorey] has quit [Ping timeout: 246 seconds]
05:49 -!- nullbyte [NSA@gateway/vpn/mullvad/x-jwmakwkrtwvkcusv] has joined #bitcoin-wizards
05:54 -!- jae [~jae@2601:645:c001:263a:a110:f114:b3e0:ba50] has joined #bitcoin-wizards
05:55 -!- 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:59 -!- p15x [~p15x@64.145.91.58] has quit [Ping timeout: 264 seconds]
06:00 -!- merlincorey [merlin@69.42.217.140] has joined #bitcoin-wizards
06:03 -!- 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:06 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-wizards
06:10 -!- Quanttek [~quassel@2a02:8108:73f:f6e4:e23f:49ff:fe47:9364] has quit [Ping timeout: 252 seconds]
06:11 -!- shesek [~shesek@77.125.92.26] has joined #bitcoin-wizards
06:24 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds]
06:28 -!- nullbyte [NSA@gateway/vpn/mullvad/x-jwmakwkrtwvkcusv] has quit [Ping timeout: 256 seconds]
06:29 -!- nullbyte [NSA@gateway/vpn/mullvad/x-vndyeplqqslffzgl] has joined #bitcoin-wizards
06:37 -!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has quit [Ping timeout: 276 seconds]
06:46 -!- theymos [~theymos@unaffiliated/theymos] has quit [Ping timeout: 264 seconds]
06:50 -!- theymos [~theymos@unaffiliated/theymos] has joined #bitcoin-wizards
06:55 -!- CodeShark_ [~androirc@cpe-76-167-237-202.san.res.rr.com] has quit [Remote host closed the connection]
06:59 -!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has joined #bitcoin-wizards
07:03 -!- 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:05 -!- bedeho [~bedeho@195.159.234.190] has quit [Quit: Nettalk6 - www.ntalk.de]
07:07 -!- www [~v3@x5ce13e5c.dyn.telefonica.de] has joined #bitcoin-wizards
07:15 -!- p15x_ [~p15x@114.244.152.170] has joined #bitcoin-wizards
07:16 -!- p15x [~p15x@64.145.91.74] has quit [Ping timeout: 250 seconds]
07:18 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
07:23 -!- shesek [~shesek@77.125.92.26] has quit [Ping timeout: 264 seconds]
07:38 -!- 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:39 -!- 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:40 -!- erasmospunk [~erasmospu@179.43.134.162] has quit [Remote host closed the connection]
07:45 -!- asciilifeform [~asciilife@unaffiliated/asciilifeform] has left #bitcoin-wizards ["Leaving"]
07:51 -!- bramc [~bram@99-75-88-206.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-wizards
07:52 -!- www1 [~v3@f052068111.adsl.alicedsl.de] has joined #bitcoin-wizards
07:54 -!- www [~v3@x5ce13e5c.dyn.telefonica.de] has quit [Ping timeout: 252 seconds]
08:01 -!- davi [~davi@gnu/davi] has joined #bitcoin-wizards
08:16 -!- mjerr [~mjerr@p578EAB34.dip0.t-ipconnect.de] has joined #bitcoin-wizards
08:21 -!- 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:23 -!- c0rw|zZz is now known as c0rw1n
08:23 -!- p15x_ [~p15x@114.244.152.170] has quit [Ping timeout: 264 seconds]
08:24 -!- davi [~davi@gnu/davi] has quit [Remote host closed the connection]
08:26 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-ahclurwxfedpywrn] has joined #bitcoin-wizards
08:40 -!- merlincorey [merlin@69.42.217.140] has joined #bitcoin-wizards
08:48 -!- CodeShark_ [~androirc@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-wizards
08:51 < iddo> nsh: there's academic paper but it's unpublished yet, also proof-of-space cryptocurrency has costless simulation problem
08:56 < nsh> is this related to the cycle detection issue?
08:57 < 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
09:02 -!- p15x_ [~p15x@64.145.91.19] has joined #bitcoin-wizards
09:03 -!- p15x [~p15x@64.145.91.35] has quit [Ping timeout: 264 seconds]
09:10 -!- Starduster [~sd@unaffiliated/starduster] has quit [Ping timeout: 256 seconds]
09:11 < 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:12 < 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:13 < nsh> exponential running time is not low cost :)
09:17 -!- 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:18 < 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:22  * nsh nods
09:25 < amiller> iddo, what problems?
09:26 < amiller> iddo, also is the newest one subject to whatever you have in mind or not?
09:29 < 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:31 < 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:32 < 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:33 < iddo> nsh: nothing-at-stake ? actually it's amiller's name i think
09:34 < 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:35 < 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:36 < 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:39 < 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:41  * nsh nods
09:41 < nsh> some amount of reorg has to be assumed, so you can't be too punitive about it
09:42 < 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:45 < 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:46 < 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:48 < 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:50 -!- c0rw1n is now known as c0rw|away
09:52 -!- Quanttek [~quassel@ip1f10af17.dynamic.kabel-deutschland.de] has joined #bitcoin-wizards
09:56 -!- 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:58 -!- tucenaber [~tucenaber@unaffiliated/tucenaber] has joined #bitcoin-wizards
09:58 -!- Starduster [~sd@unaffiliated/starduster] has joined #bitcoin-wizards
09:59 -!- spinza [~spin@197.89.186.249] has quit [Excess Flood]
10:08 -!- spinza [~spin@197.89.186.249] has joined #bitcoin-wizards
10:10 -!- SubCreative [~SubCreati@unaffiliated/cannacoin] has joined #bitcoin-wizards
10:13 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]
10:23 -!- erasmospunk [~erasmospu@81.17.20.98] has joined #bitcoin-wizards
10:31 -!- orperelman [~orperelma@bzq-109-67-207-175.red.bezeqint.net] has quit [Ping timeout: 246 seconds]
10:32 -!- 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:34 -!- www1 [~v3@f052068111.adsl.alicedsl.de] has quit [Ping timeout: 250 seconds]
10:47 -!- sparetire_ [~sparetire@unaffiliated/sparetire] has joined #bitcoin-wizards
10:50 -!- 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:51 -!- [d__d] [~d__d]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-wizards
10:58 -!- dEBRUYNE_ is now known as dEBRUYNE
11:09 -!- nullbyte [NSA@gateway/vpn/mullvad/x-vndyeplqqslffzgl] has quit [Read error: Connection reset by peer]
11:13 -!- nullbyte [NSA@gateway/vpn/mullvad/x-ptctwbduhexdjqhz] has joined #bitcoin-wizards
11:14 -!- p15x_ [~p15x@64.145.91.122] has joined #bitcoin-wizards
11:16 -!- p15x [~p15x@64.145.91.104] has quit [Ping timeout: 252 seconds]
11:23 -!- nullbyte [NSA@gateway/vpn/mullvad/x-ptctwbduhexdjqhz] has quit [Ping timeout: 264 seconds]
11:24 -!- nullbyte [~NSA@193.138.219.233] has joined #bitcoin-wizards
11:29 -!- nullbyte [~NSA@193.138.219.233] has quit [Ping timeout: 252 seconds]
11:30 -!- 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:31 -!- nullbyte [NSA@gateway/vpn/mullvad/x-xwcwcizbjmqoyfrb] has joined #bitcoin-wizards
11:32 -!- p15x_ [~p15x@64.145.91.122] has quit [Ping timeout: 255 seconds]
11:33 -!- p15x [~p15x@64.145.91.49] has joined #bitcoin-wizards
11:34 -!- jae_ [~jae@c-98-234-63-169.hsd1.ca.comcast.net] has joined #bitcoin-wizards
11:38 -!- jae_ [~jae@c-98-234-63-169.hsd1.ca.comcast.net] has quit [Remote host closed the connection]
11:39 -!- roconnor [~roconnor@e120-pool-d89a7a26.brdbnd.voicenetwork.ca] has joined #bitcoin-wizards
11:43 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
11:47 < 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:49 < iddo> unique initial config? i don't really see the relevance of this analogy
11:51 < 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:53 < 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:54 < nsh> right
11:57 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-wizards
12:07 -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 265 seconds]
12:08 < 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:12 < iddo> it actually becomes less clear why proof-of-space is needed at all, given the bonds/challenges aspects of this
12:18 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte]
12:18 -!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has joined #bitcoin-wizards
12:25 -!- ryanxcharles [~ryan@2601:645:8202:4881:3030:39d0:1ef1:39e1] has quit [Ping timeout: 248 seconds]
12:31 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 276 seconds]
12:32 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Quit: zoom zoom zoom]
12:33 -!- wallet42 [~wallet42@60-227-202-46.pool.ukrtel.net] has joined #bitcoin-wizards
12:34 -!- chmod755 [~chmod755@unaffiliated/chmod755] has joined #bitcoin-wizards
12:36 -!- p15x_ [~p15x@64.145.91.71] has joined #bitcoin-wizards
12:36 -!- vaalbara [~vaalbara@23.94.31.98] has joined #bitcoin-wizards
12:37 -!- 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:39 -!- 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:43 -!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has quit [Ping timeout: 246 seconds]
12:44 -!- vaalbara [~vaalbara@23.94.31.98] has quit [Quit: Leaving]
12:46 < 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:47 -!- 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:49 -!- andytoshi [~andytoshi@wpsoftware.net] has quit [Ping timeout: 256 seconds]
12:49 -!- scoria [~blaze@wpsoftware.net] has quit [Ping timeout: 244 seconds]
12:50 -!- jae_ [~jae@204.14.159.153] has joined #bitcoin-wizards
12:51 -!- Xh1pher [~Xh1pher@pD9E3A97A.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
12:57 -!- akrmn [~akrmn@192.95.51.167] has joined #bitcoin-wizards
12:58 -!- vaalbara [~vaalbara@23.94.31.98] has quit [Quit: Leaving]
12:59 -!- kmels [~kmels@186.151.61.56] has joined #bitcoin-wizards
13:00 -!- vaalbara [~vaalbara@23.94.31.98] has joined #bitcoin-wizards
13:18 < CodeShark_> bramc: hopefully something other than checkpoints :p
13:19 < bramc> CodeShark_ Not checkpoints! Well no more than regular Bitcoin has 'checkpoints' anyway.
13:20 < 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:22 -!- 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:23 < CodeShark_> nice work, iddo :)
13:24 < iddo> thanks, but it keeps getting rejected by clueless academic people :)
13:25 < bramc> iddo, The trick is to throw in proofs of time
13:26 < bramc> aka proofs of sequential work
13:26 < iddo> sequential work? that doesn't sound costless...
13:27 < 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:29 < 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:30 < 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:32 < 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:33 < 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:35 < 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:36 < 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:37 < 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:38 < 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:39 < 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:40 < 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:41 < 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:42 < bramc> It winds up having stochastic block times like regular Bitcoin: The better the proof of space, the shorter the proof of time.
13:43 < 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:44 < 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:45 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 248 seconds]
13:45 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-wizards
13:46 -!- 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:47 < 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:48 < 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:49 < iddo> how?
13:50 < 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:51 < 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:52 < 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:53 < 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:54 < 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:55 < iddo> i fail to see the difference between proof of time and PoW
13:56 < 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:57 < 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:58 < 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:59 < iddo> so if you can do proof of time faster than others, you get more rewards
14:00 < 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:01 < 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:02 < 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:03 < 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:04 -!- 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:05 < 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:06 < 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:07 -!- 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:08 -!- 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:09 < 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:10 < 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:11 < 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:12 < 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:13 < 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:14 < 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:15 < 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:16 < 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:17 < 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:18 < 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:19 < iddo> my argument is that everybody will or will not waste their power just like in Bitcoin, i don't see the difference
14:20 < 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:21 < 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:22 < 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:23 < 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:25 < 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:27 < 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:28 < 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:29 < 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:30 < 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:31 < iddo> why wouldn't there be PoT race ?
14:34 -!- 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:35 < 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:36 < 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:37 -!- nullbyte [NSA@gateway/vpn/mullvad/x-rbesagxsuoimfuiq] has quit [Ping timeout: 250 seconds]
14:39 -!- 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:40 < 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:41 < 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:42 < 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:43 < bramc> Over time a faster PoT will get factored into the work difficulty and not change the rate of mining rewards
14:45 < 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:46 < 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:47 < bramc> It's a little dicey paying for PoT services, because there's no way to verify that they did the work themselves
14:48 < 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:49 -!- 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:50 < 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:51 < bramc> Well, they might not be altruistic in that they can be paid directly
14:52 < bramc> It only takes one 'jerk' with a fast one to make it hard for the others to get a jump though.
14:53 < 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:54 < 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:55 < 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:56 < iddo> would be nice to see analysis given the precise properties here and what'd be the likely outcome
14:57 -!- nullbyte [NSA@gateway/vpn/mullvad/x-mhhahwkhgarbejwf] has quit [Ping timeout: 248 seconds]
14:59 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds]
14:59 -!- nullbyte [NSA@gateway/vpn/mullvad/x-pttqsodjhtomxfwr] has joined #bitcoin-wizards
15:00 -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has quit [Max SendQ exceeded]
15:01 < bramc> If there are competing PoT servers then most of them will go out of business quickly due to being less fast
15:03 -!- 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:06 < 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:07 < bramc> gmaxwell, This is me sitting in my cave
15:08 < 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:09 < 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:10 < iddo> what's the importance of BIP 66 then ?
15:11 < 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:13 -!- 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:15 -!- 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:16 < 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:19 -!- nullbyte [~NSA@172-7-226-202.lightspeed.hstntx.sbcglobal.net] has quit [Ping timeout: 246 seconds]
15:21 -!- nullbyte [~NSA@193.138.219.233] has joined #bitcoin-wizards
15:21 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
15:22 -!- moa [~kiwigb@opentransactions/dev/moa] has joined #bitcoin-wizards
15:25 -!- shen_noe [~shen_noe@50.252.142.179] has joined #bitcoin-wizards
15:27 -!- _whitelogger [whitelogge@fehu.whitequark.org] has quit [Ping timeout: 252 seconds]
15:28 -!- 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:31 -!- SubCreative [~SubCreati@unaffiliated/cannacoin] has quit [Remote host closed the connection]
15:32 -!- nullbyte [~NSA@193.138.219.233] has quit [Read error: Connection reset by peer]
15:33 -!- nullbyte [NSA@gateway/vpn/mullvad/x-zqsowkqazhclusjr] has joined #bitcoin-wizards
15:35 -!- goregrind [~goregrind@unaffiliated/goregrind] has quit [Ping timeout: 264 seconds]
15:37 -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 248 seconds]
15:39 -!- 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:40 < 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:41 < 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:43 -!- _whitelogger [whitelogge@fehu.whitequark.org] has joined #bitcoin-wizards
15:44 < amiller> gmaxwell, from those links it seems like blockexplorer.com was actually OK?
15:45 -!- chmod755 [~chmod755@unaffiliated/chmod755] has quit [Quit: Ex-Chat]
15:45 < gmaxwell> amiller: hah, no. by okay means its actually stuck way back.
15:46 < amiller> oh. i see, it literally thinks we're still on 358999
15:46 < gmaxwell> it reports the tip as 35_8_999
15:51 < 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:52 < jouke> :D
15:53 -!- 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:54 < 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:55 < 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:56 -!- goregrind [~goregrind@unaffiliated/goregrind] has joined #bitcoin-wizards
15:57 -!- 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:59 -!- nullbyte [NSA@gateway/vpn/mullvad/x-bkgdklvalylpjmpa] has joined #bitcoin-wizards
16:02 -!- shen_noe [~shen_noe@50.252.142.179] has quit [Quit: quitquitquit]
16:12 -!- Dr-G2 [~Dr-G@x4d08a093.dyn.telefonica.de] has quit [Ping timeout: 248 seconds]
16:16 -!- 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:17 -!- SubCreative [~SubCreati@unaffiliated/cannacoin] has joined #bitcoin-wizards
16:20 -!- nephyrin` [~neph@nemu.pointysoftware.net] has quit [Quit: ... besides, it was hot]
16:20 -!- nephyrin [~neph@nemu.pointysoftware.net] has joined #bitcoin-wizards
16:35 -!- dEBRUYNE [~dEBRUYNE@239-196-ftth.onsbrabantnet.nl] has quit [Ping timeout: 255 seconds]
16:36 -!- nullbyte [NSA@gateway/vpn/mullvad/x-bkgdklvalylpjmpa] has quit [Read error: Connection reset by peer]
16:40 -!- nullbyte [~NSA@193.138.219.233] has joined #bitcoin-wizards
17:10 -!- www [~v3@f052068111.adsl.alicedsl.de] has quit [Ping timeout: 256 seconds]
17:19 -!- hearn [~mike@84-75-197-78.dclient.hispeed.ch] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
17:21 -!- elastoma [~elastoma@162.248.160.175] has quit [Ping timeout: 246 seconds]
17:25 -!- c0rw|away is now known as c0rw1n
17:37 -!- 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:38 -!- elastoma [~elastoma@162.248.160.175] has joined #bitcoin-wizards
17:44 -!- ryanxcharles [~ryan@adsl-108-81-169-137.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 246 seconds]
17:45 -!- 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:54 -!- nullbyte [~NSA@193.138.219.233] has quit [Read error: Connection reset by peer]
17:56 -!- nullbyte [NSA@gateway/vpn/mullvad/x-djmyiaeetmyfkfhk] has joined #bitcoin-wizards
17:56 -!- wallet42 [~wallet42@185.4.41.147] has joined #bitcoin-wizards
18:04 -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has joined #bitcoin-wizards
18:07 -!- NewLiberty [~NewLibert@76-255-129-88.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-wizards
18:24 -!- belcher [~belcher-s@unaffiliated/belcher] has quit [Quit: Leaving]
18:28 -!- andytoshi [~andytoshi@unaffiliated/andytoshi] has quit [Read error: Connection reset by peer]
18:29 -!- andytoshi [~andytoshi@wpsoftware.net] has joined #bitcoin-wizards
18:39 -!- nullbyte [NSA@gateway/vpn/mullvad/x-djmyiaeetmyfkfhk] has quit [Ping timeout: 246 seconds]
18:41 -!- nullbyte [NSA@gateway/vpn/mullvad/x-bahvuvixsywxqbrc] has joined #bitcoin-wizards
18:46 -!- erasmospunk [~erasmospu@gateway/vpn/privateinternetaccess/erasmospunk] has quit [Remote host closed the connection]
18:50 -!- 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
19:05 -!- 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:09 -!- 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:12 -!- c0rw1n is now known as c0rw|zZz
19:15 -!- flower [~user@189.116.150.203.sta.inet.co.th] has quit [Quit: -]
19:24 -!- c-cex-yuriy [uid76808@gateway/web/irccloud.com/x-ahclurwxfedpywrn] has quit [Quit: Connection closed for inactivity]
19:37 -!- p15x_ [~p15x@61.149.242.84] has joined #bitcoin-wizards
19:38 -!- p15x [~p15x@64.145.91.47] has quit [Ping timeout: 248 seconds]
19:39 -!- sergiohlb [~Sergio@unaffiliated/sergiohlb] has quit [Remote host closed the connection]
19:43 -!- flower [~user@189.116.150.203.sta.inet.co.th] has joined #bitcoin-wizards
19:46 -!- _whitelogger [whitelogge@fehu.whitequark.org] has quit [Read error: Connection reset by peer]
19:48 -!- 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:52 -!- 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]
20:09 -!- void_hero [~michael@c-98-224-165-72.hsd1.mi.comcast.net] has quit [Quit: Lost terminal]
20:22 -!- akrmn1 [~akrmn@192.95.51.167] has joined #bitcoin-wizards
20:23 -!- superobserver [~superobse@unaffiliated/superobserver] has joined #bitcoin-wizards
20:23 -!- akrmn [~akrmn@192.95.51.167] has quit [Ping timeout: 264 seconds]
20:29 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 246 seconds]
20:30 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
20:30 -!- __FranzKafka__ [~FranzKafk@unaffiliated/franzkafka] has joined #bitcoin-wizards
20:32 -!- FranzKafka [~FranzKafk@unaffiliated/franzkafka] has quit [Ping timeout: 256 seconds]
20:43 -!- 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:52 < 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?
21:14 -!- sadoshi [~Sadoshi@31.220.4.123] has joined #bitcoin-wizards
21:16 -!- p15x [~p15x@64.145.91.78] has joined #bitcoin-wizards
21:17 -!- p15x_ [~p15x@61.149.242.84] has quit [Ping timeout: 264 seconds]
21:20 < bramc> On the plus side, the likelihood of miners ever getting their shit together to censor particular utxos is seeming extremely unlikely
21:21 < bramc> In all seriousness, what implications does the current mess have on possible future 'lightly' backwards incompatible changes?
21:23 < 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:28 -!- 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:32 -!- 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:33 < 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:34 < 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:35 < 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:36 < 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:37  * 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:38 < 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:39 < 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:40 < 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:42 < 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:43 < 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:44 < 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:46 < 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:48 < 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:51 < 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:52 < 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:53 < 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:54 < 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:55 < bramc> What you really want to do is burn the miners - make the ones who aren't doing it right *consistently* lose
21:56 < 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:57 < 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:58 < 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:59 < 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
22:00 < 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:01 < bramc> That would be fun though - have full nodes circulate bad transactions for a few days after the changeover
22:01 < jcorgan> hmm
22:02 < 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:03 < 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:04 < CodeShark> but...lol
22:04 < jcorgan> what's to stop someone from doing it now?
22:05 < 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:06 < 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:07 < 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:08 < 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:09 < 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:10 < 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:11 < 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:12 < 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:13 < 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:14 < 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:15 < 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:16 < 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:17 < 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:18 < bramc> that's... depressing
22:19 < 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:20 < 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:21 < 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:22 < 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:23 < 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:24 < 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:25 < 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:26 < zooko> bramc: ;-)
22:27 < 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:28 < 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:29 < 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:30 < 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:31 < 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:32 < 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:33 < 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:34 < 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:35 < 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:36 < 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:38 < 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:39 < 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:40 < bramc> gmaxwell, They might not be much better after this mess, nobody got burned all that bad
22:41 < 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:42 < 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:43 < 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:44 < 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:45 < 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:46 < 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:48 < 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:49 < 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:50 < bramc> jcorgan, I'm sure one could scrounge up a few thieves and pedophiles to sit on the board of such an entitiy
22:51 -!- roconnor [~roconnor@e120-pool-d89a7a26.brdbnd.voicenetwork.ca] has quit [Quit: Konversation terminated!]
22:52 < 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:53 < 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:54 < 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:55 < CodeShark> the bitcoin foundation doesn't count? :p
22:55 < jcorgan> lol
22:56 < 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:57 < 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:58 -!- 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:59 < 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
23:00 < 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:01 < bramc> gmaxwell, 'We're only 5% of all hashpower, us not validating hardly breaks anything'
23:01 < CodeShark> gmaxwell: sent
23:03 < leakypat> don't get me wrong , I think it is the companies themselves that should be being proactive
23:04 < 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:05 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-wizards
23:06 < 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:13 -!- nullbyte [NSA@gateway/vpn/mullvad/x-lfwqbtbciqsokmaa] has quit [Ping timeout: 248 seconds]
23:14 < CodeShark> bramc: headers-only validation would still miss 99.999% of problems :p
23:15 -!- 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:17 < 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:18 < CodeShark> fix those things and as if by magic miners will miraculously stop doing this crap
23:21 < 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:25 < 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:26 < CodeShark> but...it's a pipedream :p
23:29 < gmaxwell> CodeShark: well there is a counter argument that relaying invalid data increases exposure for those behind you.
23:30 < CodeShark> gmaxwell: true...but we probably shouldn't be relying on that :)
23:31 < 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:32 -!- Mably [~Mably@unaffiliated/mably] has joined #bitcoin-wizards
23:37 < CodeShark> gmaxwell: ideally, relay nodes would also validate...and validate correctly. but wallets not validating correctly opens up even more attack vectors
23:39 < 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:40 < 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:41 < CodeShark> it's unenforceable, though
23:41 < CodeShark> the only way to enforce it is economically
23:42 < 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:43 < 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:44 < CodeShark> so it would have to come prepackaged
23:44 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Quit: Leaving]
23:48 < CodeShark> did you finish compiling the double-spend list, gmaxwell/
23:48 < CodeShark> ?
23:49 < 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:50 < 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:51 -!- cornusammonis [~Cornus@pool-173-73-140-137.washdc.fios.verizon.net] has joined #bitcoin-wizards
23:52 < 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:53 < CodeShark> I'm considering revisiting that project...but I need a backend that is more efficient with insertions
23:55 -!- 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:56 < 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:58 < CodeShark> it would be nice to store even invalid stuff for analysis
--- Log closed Mon Jul 06 00:00:02 2015