00:05:31gmaxwell: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:42gmaxwell:roconnor: perhaps of particular interest to you ^
00:10:27yoleaux:Ledger Theory Coq Development
00:12:06gwillen:interesting that they're working in Coq though
00:13:26kanzure:i have been meaning to pay a coq person to show up in here
00:13:41kanzure:perhaps i will pay him to review (and/or fix?) that work instead
00:15:51gmaxwell:there are coq people in here. (thus my bringing that to roconnor's attention)
00:16:16kanzure:oh good
02:11:39gmaxwell:post by the author here: https://bitcointalk.org/index.php?topic=949880.0
02:14:13roconnor:I'll have to read this later
02:14:27yoleaux:Lightweight Cryptos without Block Chain Bloat (Coq Development and Paper)
02:19:26phantomcircuit:gmaxwell, it's not exactly SPV security
02:19:48phantomcircuit:you can take the UTXO from 2 weeks ago and replay the full blocks until now
02:19:57phantomcircuit:which gets you better than spv, but worse than a full node
02:20:43gmaxwell: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:40phantomcircuit:" equal block confirmation count" hum?
02:22:34gmaxwell: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:02gmaxwell: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:06phantomcircuit: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:22phantomcircuit:for such a client the utxo commitment is of substantial benefit
02:25:31phantomcircuit:it's of benefit
02:25:33gmaxwell:phantomcircuit: huh. nope not at all.
02:25:40gmaxwell:read what I wrote again.
02:26:29gmaxwell: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:53phantomcircuit:gmaxwell, oh
02:26:58phantomcircuit:yes we agree there
02:27:32phantomcircuit:im saying that the ability to walk from the trusted point many blocks ago to the tip provides a benefit over spv
02:27:44gmaxwell:Right, and the tracing example shows that you can also get 'in between' with a 'tracing SPV'
02:28:09phantomcircuit:it's difficult to discuss this stuff
02:28:21phantomcircuit:easy with a whiteboard :/
02:28:39gmaxwell: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:26gmaxwell: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:39phantomcircuit:wouldn't the normal full node only have to calculate the utxo set hash once when the block was checked?
02:31:50phantomcircuit:oh right that actually is a huge cost
02:32:11phantomcircuit:gmaxwell, utxo commitments every 2016 blocks? :P
02:34:24gmaxwell: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.
03:45:04everettForth:when is that bitcoin roundtable thing?
05:35:27fanquake_:fanquake_ is now known as fanquake
07:38:47lclc_bnc:lclc_bnc is now known as lclc
08:30:24lclc:lclc is now known as lclc_bnc
08:55:29lclc_bnc:lclc_bnc is now known as lclc
09:05:17cameron.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:17cameron.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:17cameron.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:17cameron.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:17cameron.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:30lclc:lclc is now known as lclc_bnc
11:34:27lclc_bnc:lclc_bnc is now known as lclc
15:15:06maaku:gmaxwell: would be 2x, not 20x no?
15:15:37maaku:a balanced tree has twice as many nodes as leafs
15:17:03sipa:in a binary tree yes
15:17:05tromp__:any binary tree, balanced or not, has 1 fewer internal nodes than leafs, so total nodes = 2* leafs - 1
15:17:16sipa:but leveldb is not a binary tree
15:17:48sipa:while any db commitment pretty much has to at least semantically impose a bimary tree structure
15:17:59sipa:plus uodate all parents for every write
15:18:15maaku:oh right. an update hits log(N)
15:18:33sipa:you can merge the top tree updates
15:18:45sipa:but those are only small in number anyway
15:18:48Eliel_:Eliel_ is now known as Eliel
16:27:18lclc:lclc is now known as lclc_bnc
18:52:53[\\\]:[\\\] is now known as tripleslash
19:01:41lclc_bnc:lclc_bnc is now known as lclc
19:28:15[\\\]:[\\\] is now known as tripleslash
21:09:40Pan0ram1x:Pan0ram1x is now known as Guest71345
22:18:52lclc:lclc is now known as lclc_bnc
22:27:28triplesl-:triplesl- is now known as tripleslash
22:29:48NewLiberty_:NewLiberty_ is now known as NewLiberty
23:02:22ryan-c:maaku: still want to talk to you about the status of your utxo work