00:05:31 | gmaxwell: | https://bitcointalk.org/index.php?topic=949942.0 kind of disappointing that the author seems to have been somehow unaware of the state of the art in development (e.g. that Bitcoin core has validated off a utxo database for years now) |
00:05:42 | gmaxwell: | roconnor: perhaps of particular interest to you ^ |
00:10:27 | kanzure: | .title |
00:10:27 | yoleaux: | Ledger Theory Coq Development |
00:12:06 | gwillen: | interesting that they're working in Coq though |
00:13:26 | kanzure: | i have been meaning to pay a coq person to show up in here |
00:13:41 | kanzure: | perhaps i will pay him to review (and/or fix?) that work instead |
00:15:51 | gmaxwell: | there are coq people in here. (thus my bringing that to roconnor's attention) |
00:16:16 | kanzure: | oh good |
02:10:41 | roconnor: | cute |
02:11:39 | gmaxwell: | post by the author here: https://bitcointalk.org/index.php?topic=949880.0 |
02:14:13 | roconnor: | I'll have to read this later |
02:14:27 | kanzure: | .title |
02:14:27 | yoleaux: | Lightweight Cryptos without Block Chain Bloat (Coq Development and Paper) |
02:19:26 | phantomcircuit: | gmaxwell, it's not exactly SPV security |
02:19:48 | phantomcircuit: | you can take the UTXO from 2 weeks ago and replay the full blocks until now |
02:19:57 | phantomcircuit: | which gets you better than spv, but worse than a full node |
02:20:43 | gmaxwell: | phantomcircuit: it's strictly weaker SPV security with an equal block confirmation count. It's not 1:1 but the places where it's a win aren't super clear to me. |
02:21:40 | phantomcircuit: | " equal block confirmation count" hum? |
02:22:34 | gmaxwell: | e.g. if you'd take a utxo set from 2016 blocks back, then waiting 2016 blocks on a payment is strictly more secure. As in there is no attack where a 2016 block reorg would trick a SPV wallet there but couldn't just be used for your UTXO set syncers. |
02:24:02 | gmaxwell: | It complicates if you are using 'what miners could have gotten out of their attack' (e.g. an economic security assumption) rather than just "I'm assuming most hashpower will be honest no matter what". |
02:25:06 | phantomcircuit: | gmaxwell, possibly we're talking about different modes of spv operation, a trivial spv client would not trace the graph for it's transactions back to a coinbase |
02:25:22 | phantomcircuit: | for such a client the utxo commitment is of substantial benefit |
02:25:27 | phantomcircuit: | well... |
02:25:31 | phantomcircuit: | it's of benefit |
02:25:33 | gmaxwell: | phantomcircuit: huh. nope not at all. |
02:25:40 | gmaxwell: | read what I wrote again. |
02:26:29 | gmaxwell: | If you just accept the commitment at height X then it could (possibly) contain _anything_. You're just trusting it. Okay, well you could also just trust a regular old SPV transaction at that height. You're trusting height X completely. |
02:26:53 | phantomcircuit: | gmaxwell, oh |
02:26:58 | phantomcircuit: | yes we agree there |
02:27:32 | phantomcircuit: | im saying that the ability to walk from the trusted point many blocks ago to the tip provides a benefit over spv |
02:27:44 | gmaxwell: | Right, and the tracing example shows that you can also get 'in between' with a 'tracing SPV' |
02:27:51 | phantomcircuit: | k |
02:28:09 | phantomcircuit: | it's difficult to discuss this stuff |
02:28:21 | phantomcircuit: | easy with a whiteboard :/ |
02:28:39 | gmaxwell: | Sure I'm not saying it's useless, but at the limit it's the SPV security model; it's not free from a security perspective. And if you were really happy with SPV you could just use that. So I'm unsure of the utility. |
02:29:26 | gmaxwell: | esp since a committed UTXO set comes with a (say) 20 fold IO increase for full nodes in additional cost updating the utxo set hashes. |
02:31:39 | phantomcircuit: | wouldn't the normal full node only have to calculate the utxo set hash once when the block was checked? |
02:31:50 | phantomcircuit: | oh right that actually is a huge cost |
02:32:11 | phantomcircuit: | gmaxwell, utxo commitments every 2016 blocks? :P |
02:34:24 | gmaxwell: | if the UTXO set is large compared to the transaction count in N blocks, then the gain from batching is small; and of course it's not nice to have a big burst of cost all at once. |
02:38:33 | phantomcircuit: | true |
03:45:04 | everettForth: | when is that bitcoin roundtable thing? |
03:46:05 | sipa: | #bitcoin |
05:35:27 | fanquake_: | fanquake_ is now known as fanquake |
07:38:47 | lclc_bnc: | lclc_bnc is now known as lclc |
08:30:24 | lclc: | lclc is now known as lclc_bnc |
08:55:29 | lclc_bnc: | lclc_bnc is now known as lclc |
09:05:17 | cameron.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
09:05:17 | cameron.freenode.net: | Users on #bitcoin-wizards: andy-logbot kgk Mably wiz antgreen` tromp arubi aburan28 koshii bosma spinza fanquake TheSeven eslbaer_ SDCDev LarsLarsen bassguitarman justanotheruser d1ggy_ mappum Oizopower platinuum p15 jbenet use_zfs_yo ryanxcharles epscy_ Burrito shesek jaekwon_ iddo Alanius dgenr8 prodatalab Guest222 Emcy yoleaux espes__ luny michagogo Xzibit17 alawson cursive nick1234abcd__ PFate btcdrak yrashk BlueMatt SubCreative amincd grandmaster harrow sipa burcin |
09:05:17 | cameron.freenode.net: | Users on #bitcoin-wizards: brand0 rw_8197 @ChanServ dc17523b13 DoctorBTC MoALTz Starduster Adrian_G throughnothing Cory jgarzik maaku ebfull andytoshi brad__ helo NikolaiToryzin GAit nuke1989 melvster1 catcow PaulCapestany btc___ nsh K1773R HM2 kumavis Muis a5m0 TD-Linux berndj Hunger- Luke-Jr Logicwax azariah Krellan null_radix coryfields midnightmagic gmaxwell MRL-Relay waxwing morcos Anduck cryptowest Apocalyptic gavinandresen dansmith_btc gnusha_ Meeh tromp__ |
09:05:17 | cameron.freenode.net: | Users on #bitcoin-wizards: Tjopper qwopqwop huseby lclc indolering kinlo hollandais otoburb hguux__ ahmed_ PRab binaryatrocity wizkid057 so phedny stonecoldpat warptangent roasbeef gwillen CodeShark isis BrainOverfl0w sdaftuar wumpus nickler Iriez phantomcircuit sl01 earlz davout bobke_ comboy_ dasource amiller artifexd deego fluffypony dardasaba veox warren gribble CryptOprah optimator weex jcorgan Fistful_of_Coins EasyAt jaromil mr_burdell forrestv cfields Eliel_ |
09:05:17 | cameron.freenode.net: | Users on #bitcoin-wizards: nanotube s1w Keefe bbrittain petertodd tripleslash BananaLotus smooth ryan-c ajweiss sneak lnovy d9b4bef9 crescendo Taek eric livegnik asoltys_ pigeons catlasshrugged kanzure heath JonTitor fenn Graet lechuga_ |
11:25:30 | lclc: | lclc is now known as lclc_bnc |
11:34:27 | lclc_bnc: | lclc_bnc is now known as lclc |
15:15:06 | maaku: | gmaxwell: would be 2x, not 20x no? |
15:15:37 | maaku: | a balanced tree has twice as many nodes as leafs |
15:17:03 | sipa: | in a binary tree yes |
15:17:05 | tromp__: | any binary tree, balanced or not, has 1 fewer internal nodes than leafs, so total nodes = 2* leafs - 1 |
15:17:16 | sipa: | but leveldb is not a binary tree |
15:17:48 | sipa: | while any db commitment pretty much has to at least semantically impose a bimary tree structure |
15:17:59 | sipa: | plus uodate all parents for every write |
15:18:15 | maaku: | oh right. an update hits log(N) |
15:18:33 | sipa: | you can merge the top tree updates |
15:18:45 | sipa: | but those are only small in number anyway |
15:18:48 | Eliel_: | Eliel_ is now known as Eliel |
16:27:18 | lclc: | lclc is now known as lclc_bnc |
18:52:53 | [\\\]: | [\\\] is now known as tripleslash |
19:01:41 | lclc_bnc: | lclc_bnc is now known as lclc |
19:28:15 | [\\\]: | [\\\] is now known as tripleslash |
21:09:40 | Pan0ram1x: | Pan0ram1x is now known as Guest71345 |
22:18:52 | lclc: | lclc is now known as lclc_bnc |
22:27:28 | triplesl-: | triplesl- is now known as tripleslash |
22:29:48 | NewLiberty_: | NewLiberty_ is now known as NewLiberty |
23:02:22 | ryan-c: | maaku: still want to talk to you about the status of your utxo work |