00:11:16NewLiberty:NewLiberty is now known as NewLiberty2
00:11:33NewLiberty-afk:NewLiberty-afk is now known as NewLiberty
00:28:41atgreen:gmaxwell: just read TinyRAM spec. The ISAs are pretty similar. TinyRAM has a conditional jump, and numerous compare instructions, while moxie has one compare instruction and numerous conditional branch instructions. I like the moxie approach because you can reuse the compare result with multiple branches.
00:29:20atgreen:They don't have an arithmetic shift right, which is a nice to have, I suppose. GCC likes emitting them.
00:30:11atgreen:They just have a single addressing mode, which is not great from a code density perspective.
00:30:30atgreen:I had a quick look for the size comparison docs but haven't found them yet.
00:40:31gmaxwell:re: addressing mode, I assume thats a result of the circuit size, IIRC the vast majority of the size is in the sorting network that checks agrement with memory access history, so probably any memory instruction complexity is trouble for them.
00:40:49gmaxwell:atgreen: https://eprint.iacr.org/2013/507.pdf page 12 has the code size graphs
00:43:19atgreen:yes, I just found that. it's only word addressable?
00:43:23atgreen:hmm.. yes
00:43:56gmaxwell:For their application though you could always subset an instruction set. E.g. someone could make a proof system that verified moxie transacripts, and if instruction $foo was burdensome, you could just be forbidden from using it... at least so long as omitting that instruction didn't hose the code density.
00:47:42gmaxwell:(e.g. if $foo make the circuit to verify the transcript awful)
00:53:56sipa:ok, arm assembly is unreadable to me :)
00:55:25gmaxwell:Also, I think a primary optimization criteria for them was the amount of idle logic (esp mux logic), they'd probably never include an instruction that could be emulated by two instructions. The reason for this is the prover complexity is basically linear in the unrolled circuit size. E.g. if you repeat the cpu circuit for each cycle it runs. So adding one gate to the CPU adds $cycles gates to t
00:55:31gmaxwell:he whole proof. An extra instruction has to save a lot of cycles before is a win for them.
00:56:01gmaxwell:sipa: did you just dive in and try reading it or did you read something on arm asm first?
00:56:20sipa:gmaxwell: i have never seen arm assembly in my life; this is a totally expected result :)
00:56:24gmaxwell:arm does a bunch of interesting things esp in non-thumb mode, like packing immediates into the instructions.
00:56:44gmaxwell:or packing in shift modifiers.
00:57:01sipa:i couldn't write x86_64 assembly either, but at least i had seen plenty of disassemblies :)
00:57:48sipa:i should try to write a naive extgcd based modular inverse, and see how it compares to a fixed ladder
00:57:59gmaxwell:sipa: wumpus may have a better resource but http://people.xiph.org/~tterribe/daala/neon_tutorial.pdf the first few pages here cover basic arm.
00:58:50sipa:yeah, i'll read up - i just wonder how to assure myself that wumpus' code is correct
00:59:10gmaxwell:sipa: I think the GMP code had a comment that their sub-quadratic algorithim started to be a win at about 200-ish bits. so perhaps that wouldn't be much worse than gmp?
00:59:30sipa:interesting
01:00:45gmaxwell:(though win may not be vs a completely plain approach either)
01:16:21sipa:gmaxwell, wumpus: my memory was failing; we did merge a version of dettman's parallel multiply (and that's what wumpus converted); it's just an additional optimization he implemented that didn't seem beneficial on x86
01:17:45gmaxwell:ohh
01:19:49gmaxwell:atgreen: might be interesting to compile some large divers corpus of code (specint? ugh) and compare the per function sizes between x86,arm,ppc,moxie and see if there are any functions that are gratitiously expanded on moxie. Though; while saying that I bet the lack of super-optimizer-created peephole optimiztions hurts moxie (and to a lesser extent non-x86) pretty substantially.
01:20:42sipa:wumpus code having a comment about c and d gave it away (the original code only had c)
01:47:53Pan0ram1x:Pan0ram1x is now known as Guest58177
02:26:51petertod1:petertod1 is now known as petertodd
02:54:16petertodd:rusty, maaku: note that there is acounter-argument to the idea that the UTXO set tree should be deterministic based on it's contents, which is that if it isn't all nodes are forced to recalculate it from actual blockchain data, which incentivises actually doing just that. it's not clear yet whether that's a stronger argument than the arguments for content determinism - depends a lot on how things like fraud proofs and so on are constructed.
02:58:41petertodd:rusty: FWIW (U)TXO commitments can end up breaking the security of bitcoin quite badly by removing the need for miners to validate history - the incentive to actually broadcast blockchain data is pretty fragile right now
03:14:16wumpus:petertodd: I agree that validating history is good, but there is a decreasing merit to validating the further-back you go, some blocks must have been validated well enough at some point
03:16:31gmaxwell:wumpus: he's just making the point that it enables anti-social behavior like writing botnet grade nodes that never validate anything except the tip and believe whatever the last block was from the network.
03:16:58wumpus:also because it ceases to matter at some point if it was wrong, say if bitcoin exists 50 years, only someone very idle would validate everything all the way back, and what if you find a mistake, re-do 50 years of transactions
03:16:58gmaxwell:Though I'm not sure I full agree at least today. You can already make those botnet nodes, just don't include any transactions at all.
03:17:49wumpus:it would be good to set some window though, not have 'start from yesterday' be acceptable
03:18:35gmaxwell:wumpus: careful that you don't fall into some trap with simulation there. "50 year" well how do you know it was 50 years back if you weren't there? What happens when I give you a blockchain that claims 10 years of history that didn't happen and starts with 1 trillion bitcoin for me in the block right before your 'window' would create it?
03:20:22wumpus:gmaxwell: indeed, you don't know that for sure. But if it's the blockchain everyone that youre transacting with agrees on, what can you do.
03:21:10gmaxwell:wumpus: How do you know that it is? there isn't a mechenism right now that tells you if the blockchain you're transacting on and I'm transacting on are the same.
03:21:45wumpus:gmaxwell: ok...
03:22:11phantomcircuit:petertodd, the real cost of validation is virtually zero, utxo commitments are a 90% solution... but if it costs virtually nothing to do the 100% solution
03:22:13phantomcircuit:why not?
03:22:32gmaxwell:phantomcircuit: because people.
03:22:38wumpus:gmaxwell: the utxo hash could be used for that I suppose
03:22:56phantomcircuit:gmaxwell, 90% solution caries non-zero risk of reward loss
03:23:01gmaxwell:I think we've seen enough to know that if you can say 10% of coding effort in exchange for 99.9% of your users security, a lot of developers will take that option. :)
03:23:16wumpus:if you have a different utxo hash at the same height then you (or the other person) forked from the real truth somewhere
03:23:29phantomcircuit:it's easier to use getblocktemplate from bitcoind than to parse utxo commitments...
03:23:40gmaxwell:phantomcircuit: see also the person complaining on bitcoin core github that their blind mining from headers scraped from other pools got orphaned.
03:23:51phantomcircuit:wat
03:24:05phantomcircuit:lol well that does demonstrate my incentives point quite clearly
03:24:06phantomcircuit::P
03:24:31gmaxwell:phantomcircuit: it sure is but look at all those people who've gone and implemeted their own inevitably wrong "full" nodes for reasons that probably need a sociology class to explain.
03:25:09phantomcircuit:well as long as they all have *different* bugs that might not matter so much
03:25:21gmaxwell:phantomcircuit: well yes/no. None of us here would have doubted the risks/costs side of your argument: but there you see it, people did it inspite of those obvious risks.
03:25:42gmaxwell:phantomcircuit: it wouldn't except all of this stuff ends up with a power law distribution.
03:26:29phantomcircuit:hmm
03:27:01gmaxwell:e.g. it won't be 1000 equally popular differently broken versions, it'll be 30 differently broken versions which copy the same bugs from 8 different implementations, and have distributions like 60% 30% 5% 1% 0.5% 0.5%....
03:27:39gmaxwell:plus personal saftey isn't saved by many bugs only system wide.
03:28:24gmaxwell:like okay say no bug has more than 10% penetration. And you're foo exchange on one of those versions. Well, it's no real consolation to you that the overall consistency of the network was preserved after someone ran off with 1000 btc from you.
03:29:15phantomcircuit:gmaxwell, right
03:29:21phantomcircuit:and that would suck
03:29:28phantomcircuit:but well... that's your own fault
03:30:02gmaxwell:perhaps, but it's a rational (not just market effect) reason for not equal distribution...
03:48:20wumpus:sipa: RE: ARM assembly, it's really easy once you get the hang of the syntax, the instructions do a single thing and do that to just the provided registers, no x86-ish "oh, the mul instruction always writes to dx:ax" weirdness
03:51:54wumpus:arithmethic instructions even have to be explicitly told to update the condition flags, e.g., adds instead of add
04:16:51maaku:petertodd: sure, let's just leave the system in a near-useless, crippled state for most people. that way it will be more convenient to use legacy systems instead.
04:26:58wumpus:not useless for 'most people', there is always the alternative to use a SPV client and have SPV-level security, but for full nodes and miners it will get increasingly hard to get started if they have to validate from the genesis block. I'm convinced we need utxo commitments of some form.
04:28:44wumpus:maybe we should commit to the utxo of 10000 blocks ago? :-)
04:29:12wumpus:nah, that doesn't help
04:49:13maaku:wumpus: the alternatives for scaling petertodd advocates for lack an SPV mode
04:52:25gmaxwell:Anyone with long running IPv4 plublically reachable nodes mind sharing your getpeerinfo with me? Just trying to get a quick list of IPs that are agressively connecting to everyone they can.
04:56:18kanzure:sent by pm
04:57:44maaku:wumpus: i think the simulation threat prevents one from forgetting history entirely. you have to validate to genesis. but a utxo commitment does bring nice benefits like transferring validator state with SPV security
04:58:46maaku:(not recommended for bootstrapping your own node from untrusted peers, but perhaps has applications within an organization or from known but external peers
05:00:09maaku:for non-mining full nodes bootstrapping the UTXO set from the network could make sense
05:03:43wumpus:isn't it the case that the deeper you go into the chain, the smaller the simulation threat?
05:05:09gmaxwell:wumpus: no. The more total work is done the more costly, though you may not have an objective benchmark for cost.
05:05:10wumpus:e.g. if you start from a utxo commitment 100000 blocks back, that would take impossible amounts of computing power to fake, or am I missing something?
05:05:56wumpus:ok... well yes that makes it pretty useless then
05:08:19gmaxwell:wumpus: well wrt impossible: this is the amount of work at the current hashrate that it would take to replace the whole chain: http://bitcoin.sipa.be/powdays-50k.png
05:08:27gmaxwell:in days.
05:09:27wumpus:I expect that to be the case because bitcoin is still so young
05:10:23gmaxwell:in any case a metric like "learn many chains, and you can do reduced checking along the path when best work chain has at least 60 days advantage at the highest hasrate seen"
05:10:52wumpus:there is so much more hash power now than in the early days
05:11:25wumpus:yes
05:15:51maaku:wumpus: actually most long-term models of bitcoin hash rate end up showing that there will be more unused capacity than now
05:16:07maaku:meaning startup capital costs to creating a simulation would be a lot lower
05:16:45wumpus:maaku: well sure that's one direction things can go in
05:18:35maaku:wumpus: i'm not sure how it doesn't go in that direction, since it is more than likely that people will overshoot on the last round of asics during the exponential growth stage
05:18:47maaku:*super-exponential
05:22:22wumpus:maaku: in the case the hashrate is stable for a long time, and the number of miners or amount of mining hardware is no longer increasing significantly, ie at most a few % per year, it becomes unfeasible to simulate all from the beginning
09:05:15sendak.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:15sendak.freenode.net:Users on #bitcoin-wizards: andy-logbot Guyver2 adam3us d1ggy mortale coiner bit2017 siraj Shiftos cbeams HaltingState fanquake Guest58177 Luke-Jr luny prodatalab Elio20 null_radix smk berndj adlai hktud0 dgenr8 ebfull OneFixt jgarzik Starduster @ChanServ zooko atgreen waxwing e1782d11df4c9914 Transisto koshii Aquent tacotime nuke1989 Guest55861 jaromil_ jbenet poggy_ petertodd Apocalyptic gmaxwell Meeh_ harrow` tromp__ hashtagg shesek wiz PaulCapestany Tjopper tromp
09:05:15sendak.freenode.net:Users on #bitcoin-wizards: cluckj Emcy samson_ DougieBot5000_ helo copumpkin v3Rve c0rw1n midnightmagic spinza devrandom espes__ Iriez fluffypony hollandais ryanxcharles Cory epscy thrasher` butters nickler Logicwax lnovy ahmed_ sl01_ gavinandresen SubCreative warren Krellan fenn LarsLarsen jchp mkarrer pi07r phantomcircuit mr_burdell Graet optimator morcos lclc_bnc isis NikolaiToryzin [\\\] michagogo mappum Muis Baz__ kanzure gribble MRL-Relay maaku wizkid057 Graftec
09:05:15sendak.freenode.net:Users on #bitcoin-wizards: bobke rfreeman_w huseby [d__d] BananaLotus amiller artifexd iambernie kumavis Guest2104 BrainOverfl0w phedny Keefe so crescendo throughnothing Taek burcin livegnik sipa harrigan sneak s1w yoleaux azariah kinlo iddo Guest38445 HM2 Fistful_of_Coins warptangent lechuga_ andytoshi pigeons Nightwolf eordano btcdrak comboy a5m0 K1773R asoltys_ JonTitor Alanius mmozeiko smooth roasbeef ryan-c TD-Linux catcow danneu starsoccer EasyAt DoctorBTC
09:05:15sendak.freenode.net:Users on #bitcoin-wizards: bbrittain go1111111 heath toddf dansmith_btc eric stonecoldpat wumpus btc__ CryptOprah gwillen digitalmagus AdrianG hguux_ nanotube Eliel Anduck cfields BlueMatt coutts BigBitz coryfields nsh
09:33:26lclc_bnc:lclc_bnc is now known as lclc
09:54:02petertodd:maaku: did you even read what I said above? I didn't say a thing about scaling, just that a UTXO commitment deterministic on full blockchain history rather than UTXO contents may have some advantages - you're knee is seriously jerking...
09:56:01petertodd:maaku: secondly it's very mistaken to say the scaling alternatives I propose lack SPV - implementing SPV on them is harder, but it's clear there are viable approaches and more research on them should be done - at least I am proposing things that can scale up - your camp isn't proposing any new ideas for scaling, and many of your proposed ideas make scaling up worse
09:57:52gmaxwell:petertodd: maaku was a bit reactionary above to your off the cuff comment, But "your camp".... come now. If I'm to presume that includes me-- a signficant fraction of all the improved scaling ideas in this space have come from me.
09:58:47petertodd:gmaxwell: and as you know, a significant fraction have come from me
09:58:55gmaxwell:absolutely.
09:59:20petertodd:gmaxwell: point is *blockstream* isn't proposing new scaling ideas beyond off-chain txs
09:59:26Luke-Jr:are we having a camp-out?
09:59:27gmaxwell:(I did agree maaku was reading too much into your remart! but no need to fight about it, it's a fine clarification)
09:59:39gmaxwell:remark*
10:00:08petertodd:Luke-Jr: get the marshmellows
10:00:16Luke-Jr:gmaxwell's living room again? :p\
10:00:32Luke-Jr:oh, maybe it'll have to be my place then
10:00:37gmaxwell:hehe. it's cold here. otoh my living room is mostly empty.
10:00:38Luke-Jr:* Luke-Jr has 2 fireplaces
10:00:41petertodd:Luke-Jr: I'm not sure if a fire would make that place better or worse...
10:00:47petertodd:gmaxwell: oh that's a change
10:01:16gmaxwell:petertodd: I did eventually get the shelves installed and the boxes unpacked.
10:01:23Luke-Jr:XD
10:02:05petertodd:gmaxwell: ha, so that's why bitcoin development slowed down...
10:02:29Luke-Jr:so we should release 0.11 in a week and all go on a camping trip without internet
10:02:44Luke-Jr:we'd come home to find the dev team doubled maybe
10:03:22petertodd:Luke-Jr: do you mean immediately, or in 9 months?
10:03:55Luke-Jr:petertodd: immediately; merge all the PRs and go :P
10:04:11Luke-Jr:there's gotta be some chaos to attract the new devs, after all
10:04:54rusty:* rusty wakes up.... petertodd, I'm not sure that UTXO makes it worse, but I share your concern about miners not validating blocks. I doubt it's happening now, but it's one of those things which would go under the radar until things exploded.
10:05:59rusty:petertodd: of course, a genuinely greedy miner should probably just ignore all txs and chase block rewards right now.
10:07:19petertodd:rusty: yeah, that they don't is due to social stuff - miners rarely do optimal things, which is both good and bad
10:08:15petertodd:rusty: I'm not sure that UTXO makes it worse either, but I am sure it might :P
10:09:30petertodd:anyway, bbl, 31c3...
10:09:37gmaxwell:Tail risk is a big concern. But what maaku was focusing on is an issue too. I mean, doesn't matter if miners are/aren't if people won't even run nodes.
10:09:46gmaxwell:petertodd: say hi to BlueMatt if you see him
10:10:14rusty:petertodd: oh, CCC... am jealous.
10:14:05lclc:lclc is now known as lclc_bnc
10:16:17rusty:gmaxwell: are there are set of more concrete OP_SIDECHAINPROOFVERIFY proposals in the works? The details for how to decide how much work the sidechain needs to do before the tx is accepted, for example, and of course, which SPV proof anti-cheat mechanism.
10:16:36gmaxwell:Yup.
10:16:44gmaxwell:(soon!)
10:17:40rusty:gmaxwell: is it going to be before the 16th of January, thus requiring me to hurriedly rewrite my linux.conf.au "What pettycoin should have done" talk?
10:34:18lclc_bnc:lclc_bnc is now known as lclc
10:50:39jaromil_:jaromil_ is now known as jaromil
11:47:15wallet42:wallet42 is now known as Guest51429
11:47:15wallet421:wallet421 is now known as wallet42
11:58:43gmaxwell:a3f98002ded279ad4a60d2a99a872f5e39e2db20
11:59:08copumpkin:I disagree
12:04:32Luke-Jr:well I don't disagree.
12:12:44lclc:lclc is now known as lclc_bnc
13:05:29lclc_bnc:lclc_bnc is now known as lclc
13:22:55rusty:maaku: OK, a new winner! mmr tree got us down (for 8M blocks) to 108-2048(736.812+/-4.6e+02) hashes, but using a cache of blocks which provided the optimum CSPV path for the previous block gets us down to 51-1410(429.75+/-3.2e+02).
13:23:38rusty:pushed... but it's very late here, so might be completely smoking crack.
14:43:31lclc:lclc is now known as lclc_bnc
14:48:14gmaxwell:Someone pointed me to http://blog.bettercrypto.com/?p=1004 and it irritated me enough that I spent some time writing a response (though I know I shouldn't feed the troll...). Un(?)fortunately the site doesn't actually allow responding, it just gobbles the response. I went through the effort to save the post from my browser process ram, so I might as well link it here for your edification http://
14:48:20gmaxwell:people.xiph.org/~greg/re_Courtois_1004.txt
14:51:03sipa:heh, i've written a response on one of the blog posts there too
14:51:37gmaxwell:also to find that it didn't work?
14:53:15sipa:it ended up being 'pending approval;
14:53:23sipa:not sure which post anymore
14:54:44sipa:oh, it ended up on the site!
14:54:50sipa:http://blog.bettercrypto.com/?p=916
14:58:32wallet42:wallet42 is now known as Guest1451
14:58:32wallet421:wallet421 is now known as wallet42
15:00:33wallet42:wallet42 is now known as Guest97504
15:00:34wallet421:wallet421 is now known as wallet42
15:02:07gmaxwell:I'm up to 7 getpeerinfo snapshots. Anyone want to help me reach my goal of 8?
15:15:38midnightmagic:i guess you aren't interested in a sample from anytime other than today? I have this: home/btc/sample/bitcoind-getpeerinfo-20140513-01:06:01.gz
15:16:15gmaxwell:thats interesting.
15:16:26midnightmagic:as well as about 20 days prior, 5 minute sample intervals (or so)
15:16:46gmaxwell:midnightmagic: send to me. might be interesting to have a long term view there.
15:16:54midnightmagic:okie dokie.
15:17:28ahmed_:ahmed_ is now known as ahmed_afk
15:18:22maaku:gmaxwell: you have shamed me into running a public bitcoind node again
15:25:08midnightmagic:gmaxwell: see pm :)
16:05:06lclc_bnc:lclc_bnc is now known as lclc
18:35:25ahmed_afk:ahmed_afk is now known as ahmed_
19:12:09Meeh_:Meeh_ is now known as Meeh
19:15:07omni:omni is now known as Guest46848
20:51:17wallet421:wallet421 is now known as wallet42
21:42:28brand0:is publishing a bitcoin pubkey considered a security risk, assuming you're only going to use the corresponding address once
21:45:59Luke-Jr:brand0: it reduces security, but I'm not sure I'd call it a risk
21:46:14Luke-Jr:I would avoid it if possible
21:46:33brand0:a pubkey swap is necessary for generating a multisig address, though, correct?
21:46:57Luke-Jr:not strictly, but it may be worth it in that case
21:47:22Luke-Jr:frankly, in that case, you probably want to swap HD chains
21:48:08brand0:interesting
21:48:38brand0:does the rpc interface support that? i was only aware of addmultisigaddress
21:49:54Luke-Jr:no
21:50:06Luke-Jr:there's not really any significant HD wallet support in Bitcoin Core today
21:50:20Luke-Jr:also, these topics seem like #bitcoin-dev material
21:50:34brand0:that's true
21:51:20brand0:my last "security" question got way off track so I landed here
21:51:33brand0:thanks for your help tho, Luke-Jr
21:52:36Luke-Jr:np
22:33:07phantomcircuit: [04:26:58] not useless for 'most people', there is always the alternative to use a SPV client and have SPV-level security, but for full nodes and miners it will get increasingly hard to get started if they have to validate from the genesis block. I'm convinced we need utxo commitments of some form.
22:33:33phantomcircuit:the maximum growth of 55GB/year should be well within the reach of any financially viable pool/miner
22:48:49phantomcircuit:brand0, the window to attack a pubkeyhash is very short if the pubkey is only published once when the tx out is spent
22:49:06phantomcircuit:it's just bad engineering to increase that window without a very good reason
22:51:57op_null:phantomcircuit: I'd hate to be trlying on that as a security feature though. with enough at stake it's conceivable someone would force reorgs to break a key.
22:52:32phantomcircuit:op_null, that still potentially substantially narrows the time to attack
22:53:03phantomcircuit:maybe you now have 30m-2h instead of months
22:53:09op_null:have we seen any cases of races with non-CHECKSIG transactions?
22:53:12op_null:* op_null nods
22:53:50phantomcircuit:or in the case of some of the first mined blocks years
22:53:57phantomcircuit:(they pay directly to a pubkey)
22:54:26op_null:becomes more dangerous if you have groups like blockchain.info retaining non-hardened BIP32 public keys. it turns into a very valuable resource if someone can break a single private key with ~years of compute time.
22:55:26op_null:op_null is now known as op_mul
23:01:47op_mul:phantomcircuit: I suppose that is actually quite a nice safe guard. you have very good incentives to crack early keys and alert people to the fact that you have an ECDSA 0day.
23:15:54rusty2:gmaxwell: hmm, I liked your response. Of course, we're assuming secp256r1 isn't NSA-as-good-guys protecting from some as-yet-unknown attack (a-la DES s-boxen); maybe he's an optimist :)
23:15:57rusty2:rusty2 is now known as rusty
23:18:41gmaxwell:rusty: Yep. I've raised that possibility before too; I think most people would rather take their chances with the unknown than with maybe-help from the NSA.
23:23:04omni:omni is now known as Guest94906
23:24:19sipa:gmaxwell: is your courtois answer gone?
23:30:23maaku:rusty: that's at the cost of incremental construction though, right?
23:32:06maaku:phantomcircuit: we must prepare for significantly bigger block sizes (on mainchain or a sidechain)
23:36:31gmaxwell:sipa: no, same place it was.
23:37:28brand0:https://lists.torproject.org/pipermail/tor-talk/2013-September/029956.html
23:37:46brand0:I feel like that was a decent summary of the issue
23:37:53rusty:maaku: Off the top of my head, yes. You can't determine shortest path to genesis without every block, really.
23:38:32maaku:rusty: not sure that justifies even a 50% reduction ...
23:38:34rusty:maaku: I think there's a question on whether we should insist that the "cache" be optimal, however.
23:39:08rusty:maaku: ie. put whatever you want (as long as it's valid) on the left branch of the tree.
23:39:30rusty:maaku: or maybe we only update that every 2016 blocks?
23:41:26phantomcircuit:maaku, on mainchain? probably not
23:41:41phantomcircuit:on sidechains? probably, but those should at least in theory scale ~horizontally
23:42:00phantomcircuit:each one being independent
23:42:08maaku:phantomcircuit: eh, that's not so clear-cut in terms of mining incentives
23:42:28maaku:arguments can be made that miners will have to mine them all (or defer, but that's a suboptimal situation)
23:43:00phantomcircuit:maaku, there are various possible tradeoffs miners can make
23:43:12phantomcircuit:very large miners can run all the sidechains & validation logic
23:43:52phantomcircuit:smaller ones that cant justify the overhead can outsource the work to a trusted third party (federated being trivial)
23:44:29phantomcircuit:with an incentive to do full validation as the federated model collusion could steal from the miner potentially
23:44:42gmaxwell:The the whole story around some curves maybe being bad is a bit iffy in any case. If you're really worried about that you should also be worried about isogenys; most randomly selected curves are members of enormous classes of curves where there exists a bijection or surjection onto another curve where point arithmetic holds; these maps can be expensive to compute but are often not intractable. So
23:44:48gmaxwell:if discrete log is hard in some random fraction of curves, you can keep trying random isogenys until find one where the discrete log is magically easy. If this were really a concern you'd want to select curves constructed the class of isogenys is known small; but generally no one is doing that. (Uh well, actually I think thats an unintentional side effect of the GLV construction used for our c
23:44:54gmaxwell:urve; but I'm out of my depth on the number theory here).
23:53:04maaku:rusty: the problem with "put whatever you want" is that it is now consensus-critical data that must be relayed with the block
23:55:22maaku:the problem with non-incremental structures is similar, although not as bad -- you can't validate the root without the entire block header history
23:55:47maaku:in other words it's not just efficiency arguments at play here
23:58:07rusty:maaku: Well, it's log(depth) hashes though, for the cache, so that's not much data to carry.