00:11:19 did petertodds pooled-solo mining thing from May go anywhere? 00:16:38 Emcy: petertodd's? :P 00:16:58 BIP 22 is from Feb 2012 ;) 00:22:52 sorry, he did say it was more you and greg 00:23:03 im going over the dev list again 00:23:57 you guys send a lot of mail to that list now 00:26:38 i think when people take discussions private then start ccing list again it breaks threads in my program :( 01:51:02 has anyone assessed this new paper about blockchain confirm security? 01:51:10 counting orphaned blocks as a confirmation 01:54:37 there's a pretty good thread on it https://bitcointalk.org/index.php?topic=359582.0;topicseen 01:55:55 are there disadvantages for when a wallet client uses a server to read through the blockchain, rather than load it all locally, as armory does 02:39:08 Mike_B: I'm not sure that's an accurate explanation. it doesn't count orphaned blocks as confirmation, but uses work spent on orphans is determining the most-work chain 02:42:04 It seems strange somehow that you can force the network to switch to another sibling by mining multiple side-by-side siblings, and potentially roll back a retarget. 02:44:39 midnightmagic: that requires a 51% attack ... nothing strange about that 02:49:15 as far as I know, a 51% attack can't *roll back* a retarget though can it? the 51% must linearly reach a longer sibling fork which itself is beyond the retarget. 02:50:42 this provides an additional consideration for a 51% direction that an attacker can take the chain. 02:50:45 * midnightmagic finishes reading 02:51:02 midnightmagic: it most certainly can 02:52:05 there is no limitation on how far back a rollback can go, except for checkpoints 02:53:13 maaku: What I mean is, it must extend it using post-retarget mined blocks. but if you reveal a GHOST-based subtree which is heavier but hasn't yet reached retarget, the network as a whole rewinds to that. 02:53:49 in essence, the retarget can be rewound as though no retarget has happened yet because a heavier subtree exists that hasn't reached retarget. 02:54:11 midnightmagic: the reorg code doesn't care squat about retargetting, as far as I am aware 02:54:14 any limit creates a potential for an unresolvable fatal partition in the network if there is a reorg right at the boundary. So you argue "boundary X is safe because making a reorg that deep is infeasable" I respond "boundary X is pointless because it defends against an attack you just told me can never happen" :) 02:54:15 i don't know if it matters, was just thinking of possibilities. 02:54:57 midnightmagic: yea, I dunno if thats especially concerning subtle things to think through for sure. 02:56:32 maaku: I guess the retarget boundary may not be relevant, but it looks like a heavy subtree can make the main chain length *shorter*.. 02:56:48 gmaxwell, "checkpoints are a performance feature not a security feature" 02:57:22 phantomcircuit: hm? yes. 02:57:41 midnightmagic: it extends the length of the sub-tree, i don't see how it reduces the length of the main chain 02:58:19 maaku: well for security you actually care about the relative distance to the next best tree that doesn't include your txn. 02:58:37 since thats the amount of work required to change the decision. 02:58:54 maaku: It is possible that mining could indefinitely create a reorg which switches back and forth between two trees without actually extending the main chain length. 02:59:42 I don't think a 51% attack right now could do that. I think it must *extend* some tree in order to increase main chain length. 02:59:51 midnightmagic: I dunno that that matters though. I worry more about details like how the heck do you make sure that everyone actually agrees on longest. 03:00:30 gmaxwell: well, if boundary X is there to try and keep nodes from getting DOS'd, even if it is infeasible to split the network that far back it is a useful boundary 03:00:36 yes, a problem here is that you no longer have global knowledge about how much weaker a distant subtree (which you're ignoring due to DoS considerations) is, until it overtakes you 03:01:10 but it would take the nuclear 51% for the subtree to have any effect, which is why it's not a very weighty concern from where I'm sitting... 03:01:53 andytoshi: header flooding alone isn't really an interesting dos though, esp as you don't forward them 03:02:34 well, it could be interesting if you've gotta keep them all in memory at once 03:03:04 hey btw gmaxwell - did you ever find that hashcash paper? 03:03:09 i'd really love to read it if you did. 03:03:12 i thought that was the crux of this "diff-1 flood" attack we are discussing 03:03:17 Mike_B: haven't had a chance. 03:03:37 gmaxwell: do you remember the title? i was searching stuff like "hashcash progress-free" on google but without much luck. 03:06:53 Mike_B: if I did I would have just given you the result. 03:06:53 ah, footnote #10 was what I was looking for 03:07:08 andytoshi: I haven't been following the discussion here, and don't have time to. 03:09:26 andytoshi: but with a 'sutiable' headers first implementation diff-1 flooding basically reduces to a boring "peer can send me unwanted packets" problem... though I don't know if anyone would ever bother with the really dos hardened version since incrementing the minimum difficulty (and then fixating the old chain as a one time thing) is a simpler thing to do. 03:10:57 (if you don't mind potentially fetching fork headers multiple times you can basically bound the space uning a hierarchy of bloom filters to accept headers for inspection) 03:13:44 hmm, i'd have to think about what a 'suitable' headers first implemetation would look like, since if you are weighing entire trees you can have a situation where two peers each have half the tree 03:13:52 but neither is aware of the other half 03:15:03 oh if you're talking about that fast blocks paper, I think it destroys every anti-dos mechenism for block flooding I'm aware of (other thain incremeinting the minimum diff) 03:15:28 oh, i am :P i think we have been talking past each other 03:15:43 well okay other than that, and other than SNARKs for membership in a chain of some total diff. 03:16:05 andytoshi: which is totally fine... 03:16:16 e.g. you could build a snark for summing the diff of a chain which commits to a hashtree of headers. And then you can prove each header incrementally is a member of a chain with some sum diff. 03:17:13 maaku: it's fine? really? if you end up with half the hashrate on one subtree and half on another subtree.. thats not good. what triggers resyncing the missing blocks to make them ever converge? 03:17:43 gmaxwell: reverting to IBD mode when one tree is longer, which it will be eventually 03:17:47 right, my concern is that no node can make a snark because nobody individually has a heavy enough subtree 03:17:56 but together, their subtrees could add up to a lot, so you have to listen to them all 03:18:25 maaku: I don't follow but I think I'm too worn out to think now. 03:19:26 gmaxwell: the point is the question amounts to "assume a situation only possible as the result of a 51% attack, here's a problem" - and my response is "that problem will sort itself out, and beyond that is not worth thinking about because you're assuming a devistating attack" 03:20:29 maaku: I don't see that. assume the network ends up in a state where half the nodes know fork blocks ABC and half know DEF and as a result you have half hashpower on each subtree and they stay tied. What makes them eventually converge? 03:21:10 gmaxwell: block generation being a stochastic process. they will diverge from each other randomly 03:21:38 maaku, they *might* but you have no guaratee 03:21:41 we like those 03:21:44 maaku: sure, but there are three extra blocks on each side. how long until one gets three ahead when they have an even split of hashpower? 03:22:02 and how much hashpower does it take to maintain that state? 03:22:07 (by adding extra orphans) 03:22:30 i'm not sure i follow - why the magic number 3? 03:22:38 I just picked a number. 03:22:45 obviously the Holy Trinity 03:23:02 1, 2, many. Three is the smallest many. 03:23:49 gmaxwell: well you just need a single block more on either chain 03:23:50 once one half of the split gets one block ahead, that should be enough to draw hashpower toward it 03:24:08 which is the way that their "eventually you always reconverge" theorem works 03:24:08 anyways, point I'm trying to make is I think you can put this system into a state where it will probably never converge, even without an (active) attacker. 03:24:28 and chances are you'll get that ... unless the attacker is >51% of the network and censoring his own blocks, in which case :shrug: 03:24:48 i think maaku is right, but only when everybody is sharing all the available blocks -- and then i think we have DoS potential 03:24:54 maaku: hm? no the nodes with the A B C orphans need the D E F orphan chain to be 4 blocks longer before they think its longer. 03:25:30 andytoshi: but _how_ do you share all blocks? how do you actually know if you have them all? how do you know if you don't to go get them? and how doesn't any anti-dos not mess that up? 03:26:17 gmaxwell: ah ok i misunderstood your description of the initial state 03:26:38 well, you have a master chain, and if you say, ignore any blocks more than 10000 behind the head of the chain, that would be an anti-DOS which doesn't affect this business of reconvergence 03:26:51 unless you get a 10000-deep split, and then you're totally screwed 03:27:07 but 10000 blocks ago the diff should be high enough that spamming blocks is impossible 03:27:07 you know for sure you have all the blocks normally, because of the linked list structure of the chain, but this stuff creates relationships which are not unidirectional. E.g. newer orphans make older blocks (which are later in the chain) better. 03:27:20 gmaxwell: getting ahead (or behind) 3 blocks would take a while, but it will happen - and i should point out the chance of it happening is the same as getting into that state in the first place 03:27:40 since you're presuming the forks have equal hash power, but somehow one has 3 more proof of works than the other 03:28:14 right 3 will happen buy may take a long time. .. a semi-active attacker with fairly modest hashpower who keeps mining more orphans only on the shortest subtree could prolong that. 03:29:50 but "in reality" there will be some miners which only have one orphan stored - and they will jump ship first 03:30:08 i think you're still balancing on a pin to set this up 03:32:01 maaku: but its a balance that could even happen without an attacker— which I agree is unlikely, and attacker could make it happen for sure. wait for a natural split, buy a burst of hashing power to build two blocks and give them in a censored manner... repeat as needed to keep it imbalanced. I don't know that its fatal, but its a whole class of attack that doesn't exist in the current system because we have jamming resistant ... 03:32:07 ... communication of blocks 03:32:13 I guess building additional orphans is less of a good idea than building ones that are likely to become canonical due to coinbase payments. 03:32:34 midnightmagic: someone breaking the system is short coins and doesn't care about the coinbase payments. 03:32:46 hrm 03:33:09 joker effect. 03:33:23 "byzantine failure" 03:34:04 though perhaps its sufficient if miners commit to all the blocks they're using to contribute to the difficulty they're using ... maybe that gets it back to the same communications model. 03:34:21 e.g. if blocks get censored you'll know it if you hear the tip.. and then you can go looking for the contributors. 03:34:27 well it's pretty neat they did this paper, it's a cool idea. i wonder if it can work in a p2pool-like sharechain where orphans themselves could count towards the whole. 03:34:32 gmaxwell: if the attacker is in a position to buy more than the entire hashpower of the network, there's a lot more they can do than just that 03:34:47 are you saying they can do it without maintaining that hash advantage? 03:34:59 maaku: only for a brief window? no way. I'm saying they don't have to maintain a hashing advantage. 03:35:38 as you note, once its on-the-head-of-a-pin its unlikely to converge by chance... so they just have to keep proding it to equlibrium if its gets out. 03:35:55 they could have an average hashpower a small fraction of the networks and make the split continue to diverge. 03:36:27 e.g. 10% of the network hashpower they're adding 1 block to the smallest subtree per 10 blocks added to the network. 03:37:05 gmaxwell: i'm not certain of that ... it's not explained how they're able to maintain this partition of knowledge about the orphans 03:37:40 maaku: i think the idea is, the nodes don't think to ask for the missing orphans, because they don't see any new blocks referencing them 03:37:46 it's not knoweldge, they're making them and handing them out 03:38:40 gmaxwell: i mean the orphans which resulted in the split in the first place 03:38:52 andytoshi: a GHOST client would benefit from gossiping about orphans 03:40:30 midnightmagic: i'd edit your post. it is perfectly possible to rewind past a difficulty retarget. we don't want to be spreading misinformation to the people who read that 03:41:17 maaku: It's a sub-point of stripping blocks off head..? 03:41:53 midnightmagic: you can have a two-block reorg when the difficulty retarget was 1 block ago 03:42:06 (and have a different retarget as the result, due to different timestamps) 03:42:31 maaku: Yes but after that reorg the head work count is not shorter, correct? 03:42:53 correct 03:43:03 but you post states "This includes rewinding back past a difficulty retarget, which is currently impossible" 03:43:13 that *sounds* like diff retarget == checkpoint 03:43:19 whether that is what you meant or not 03:43:45 I am editing the post, but that is a semantic difference of the meaning of the term "rewind" which I'd hoped was made clear by the fact I'd put it as a subpoint of *stripping off blocks from head without replacing them.* 03:45:32 That is, you have to replace it with a *greater* amount of work, and thus substitute one reorg for another. I'm assuming by now you know what I mean and just don't think the vocabulary I'm using is appropriate. 03:47:23 midnightmagic: correct 04:59:44 yo dawg, i heard you liked vanity https://people.xiph.org/~greg/qr.png 05:32:39 lol. 07:29:27 Fistful_of_LTC is now known as Fistful_of_AFK 07:41:51 hahaha nice gmaxwell 08:31:32 gmaxwell: so does that actually generate keys, convert to an address, create a qr code, and match to some target image or so? 08:33:18 or is the actual information in the qr code not important and it just makes use of the redundancy in the representation? 08:43:44 wumpus: i would assume it's making use of redundancy, just from visual inspection 08:46:14 maaku: it seems that way, just found the paper: http://dl.dropboxusercontent.com/u/12405967/qrsem.pdf 08:47:22 I suppose that if one generated vanity keys one could get even closer to the target image, but it's not needed for the effect at all 08:48:28 yeah that's why i figured it was redundancy 08:48:33 it could have been a cleaner image without 08:48:40 er, with a vanitygen approach 11:00:17 gmaxwell: Nice. (my phone couldn't read that, but zxing.org could) 11:57:45 Guest8413 is now known as jarpiain 13:45:03 t7 has left #bitcoin-wizards 19:18:37 hm. An interesting point about cryptocurrencies with perfect anonymity and fungibility is that they have— assuming spherical cryptography— fundimentally better scalablity. not having privacy means communicating more information. 19:19:56 you could imagine a cryptocurrency based on encrypted commitments and state outsourcing where a block doesn't communicate transactions at all, just the final state commitments and proofs that they're correct. 19:20:35 what is spherical cryptography ? 19:21:24 iddo_: I mean with tools that achieve everything we know is theoretically possible, "spherical cow", without pratical considerations or constant factors. 19:21:52 ahh 19:21:55 e.g. imagine a block that doesn't carry transactions, it just commits to the final state after all transactions were applied, and proves that the updates met the rules. 19:22:54 so with anonymous cryptocurrency, you mean that it's less communication complexity, but more computational complexity locally? 19:24:20 well I'm ignoring the complexity of the proof systems, in theory SNARKS can give quasi linear work on the prover, and constant communication and verifier complexity or similar efficiency. 19:24:28 gmaxwell: why did you say several days ago that Bitcoin mining power is about 2^74 now? i see about 64 leading zeros in the PoW hash of blocks now, isn't that 2^64 complexity? 19:24:34 So, a distributed blockchain model where the data contained within the blocks would be of much smaller size because of the the intentional absence of the bulk of the transaction data... wouldn't miners that solved the block still see the entire contents of the transactions? 19:24:49 iddo_: aggregate vs each blocks. 19:25:04 eristisk: sure, but only the block they produced. 19:25:27 gmaxwell: aggregate means what in this context? all the work that has been done since the genesis block? 19:25:59 Maybe my point was too abstract, but I'm only pointing out that the theoretical limits of cryptocurrency efficiency can only be achieved if the cryptocurrency is anonymous... because adding identifyable information increases that communication complexity to at least linear. 19:26:05 iddo_: correct. 19:26:19 cool 19:26:38 74.63 right now. Smalleast hash so far is 000000000000000000028c32e6952731326747bae4be8db0f832d6eea0362050 19:26:58 Right, you'd have to have widespread miner collusion to consistently publish or backhandedly share the data in order to get all data. The other important part you brought up is something I'd personally like to see in Bitcoin (and other "complete blockchain" altcoins) itself anyway, which is encrypted commitments. 19:28:26 eristisk: well, there are ways to construct this stuff so that its anonymous even against miners. Doing so has pratical engineering challenges today, but they're solvable. It also has significant political challenges. 19:28:59 But perhaps the point I'm making eases the political challenges: anonymity is pretty much a mandatory outcome of optimal efficiency. 19:29:35 politicians care about efficiency ? :) 19:29:51 Uh, did you just say "spherical cryptography" ? 19:29:52 What's that? 19:30:05 Oh, someone already asked. 19:30:26 It could be argued that there is space enough for a model as Bitcoin exists today (accelerating technological burdens of the large distributed data set notwithstanding) as well as an altcoin which successfully implements fully encrypted transport streams between nodes as well as transactionless blockchains as you are speaking of. 19:31:13 like a spherical cow, sorry. :) I just am talking about the theoretical asymptotic efficiency. The pratical implementations of the required tools are not there yet. 19:31:19 eristisk: money likes a monopoly. 19:31:41 More like: people like a money monopoly :P 19:32:14 And confidence in cryptocurrencies probably depends on a reasonably high degree of stickyness. "Why do I want your foo coins when next year bar coins will be the new hotness?" 19:33:18 thing about zerocoin is that CRS is exactly the kind of thing that people who are attracted to zerocoin don't like... i already see thread on that http://www.reddit.com/r/ZeroCoin/comments/1rxwvh/zerocoin_has_a_master_key/ 19:33:31 So yea, sure alternatives can and will exist... but I suspect that in enough time, as the engineering tradeoffs mature and stop being tradeoffs anymore it will just become a no-brainer to do thing like use snarks to compress bitcoin... and at the limit you end up making it anonymous even if that wasn't your goal. 19:33:47 iddo_: yea the CRS stuff is ... not good. But it's not fundimental. 19:34:47 we know from theoretical work that publically verifyable non-CRS sub-linear communication cost SNARKs can exist. 19:35:33 yes:) 19:35:38 Ah I see. Well, encrypted commitments could be added to Bitcoin with reasonably smaller fundamental changes in comparison to rewriting the protocol spec to remove transactions from the blockchain data. I get your point about "selling" it under the premise of solving the spiralling problem of storing such an increasingly massive distributed dataset whilst simultaneously arriving at a more... 19:36:03 ...anonymous system architecture, but wouldn't such a large change in the protocol be extremely difficult? 19:36:27 Well, not just selling. I don't mean that there is room for pretext... that I think if you optimize for scalablity OR privacy you end up with the same system. 19:37:00 You'd also make RMS happier. :) 19:37:03 eristisk: In practice everything is difficult. 19:37:25 s/pretext... that I think/pretext... I mean that I think/ 19:38:02 e.g. in either case you end up with a system that does state commitments and then succinct proofs that the state updates were faithful. 19:39:29 In my admittedly imperfect understanding of how that might be implemented exactly, it would seem that the blocks would have 'metadata' about the transactions to proove that they were valid instead of transaction data itself. 19:39:36 and you learn nothing about the details of the transactions, except that which is disclosed by the final state as compared to the prior state... (meaning you lose all the information about transactions chains that happened entirely in a block) 19:40:40 with headers-only sync, Bitcoin blocks also wouldn't contain transactions, just txid hashes ? 19:41:06 eristisk: No, they don't... :) 19:41:14 iddo_: no, headers are just the 80 byte bitcoin headers. 19:41:17 no txids. 19:42:18 gmaxwell: but we could have blocks only with the txids, and miners keep locally the txns themselves (and transmit txns to peers upon request) ? 19:42:26 eristisk: so some quick background. It's possible to construct cryptographic proofs that a given output was the faithful product of running a specified program on a specified input (along with additional private inputs, optionally). 19:42:52 iddo_: filtered blocks can do that, via the bloom filter stuff with just a trivial set. 19:43:05 * eristisk goes back to study the byte map of transactions to try to figure out what could realistically be ommitted in a state outsourcing system 19:43:16 eristisk: everything can be omitted. 19:43:46 I suppose so... kind of the point of hashing algorithms. 19:44:06 * nsh is dubious 19:44:15 gmaxwell: is it the devs plan to incorporate filtered blocks to Bitcoin in the future? 19:44:33 iddo_: it's already there, for over a year. 19:44:45 oh? 19:45:19 satoshi client already sends blocks without txns? and txns separately upon request? 19:45:20 iddo_: it's not used for fetching between bitcoind nodes, someone ought to do some testing to show if its actually faster once you consider the overhead of sending txids and the roundtrip latency. 19:45:27 iddo_: it can, if you ask it to. 19:45:35 cooool 19:45:54 eristisk: if you finish the prior block with a commitment to— say, in bitcoin today,— the UTXO set. Then you can have a program that takes in a prior utxo root hash as a public input, and then a bunch of transactions and utxo fragments as private inputs.. and it gives a public output as the new root hash of the utxo set. 19:47:41 and then a proof of this program's execution can be attached to the blocks. (and proofs can be constructed which are sublinear in the programs execution— even constant just constant depending on the security parameters) 19:52:14 * nsh frowns 19:52:17 there's a catch 19:52:25 i'm pretty sure there's a catch... 19:53:33 ...essentially replacing the bulky transaction data itself with different data in the blocks containing the proofs of the cryptographic solution in the form of the new root hash to be used as public input for the next unsolved block? 19:55:24 eristisk: right. plus the extra data needed in the final state. e.g. if this was dones directly to bitcoin today it would be new utxo created, and the data required to remove the old utxo. But intermediate ones (created and destroyed within a block) are not ever communicated. 19:56:19 Very large pools could analyse and save significant amounts of transactions in secret, however. 19:56:21 There have been some proposed blockchain redesigns that would reduce that further. 19:56:56 eristisk: perhaps, but you still don't know whats happening in blocks created by other parties. 19:57:48 (these same techniquies can be applied to transactions themselves, and then you get what the zerocoin people are going to propose in their update. I'm just raising the level you do the proofs at to the whole block instead of the transactions. 19:57:51 gmaxwell, i'd sure like to see some toy model of SNARK proof verification in aciton over a distributed system 19:58:06 because i just can't shake this niggling feeling that there's a catch... 19:58:09 nsh: go grab the pantry stuff then. 19:58:16 pantry stuff? 19:58:29 nsh: oh there are all kinds of _pratical_ engineering catches right now. 19:58:55 But the only fundimental catch is that you only get cryptographic soundness, not perfect soundless like bitcoin has now. 19:59:07 modulo what assumptions? 19:59:31 * nsh checks https://github.com/srinathtv/pantry/ 20:01:00 nsh: you can construct these things out of serveral different cryptographic assumptions. Including ones that basically just depend on the existance of one way functions. (though those do not achieve optimal effiency so far) 20:01:18 * nsh nods 20:02:12 ;;google knowledge-of-exponent assumption 20:03:58 http://crypto.stackexchange.com/questions/6117/how-much-do-we-trust-kea1-assumption 20:05:43 nsh: the real catch in the system used behind that has nothing to do with KEA1 (and really what you'd need to ask about is just crypto in bilinear groups more than N-th power KEA) 20:06:12 hmmm 20:06:15 it's that it's only publically verifyable in the CRS model— e.g. there is a trusted magic value that everyone needs to be using. 20:06:34 * nsh reads amiller's post http://comments.gmane.org/gmane.comp.file-systems.tahoe.devel/7942 20:06:54 But as mentioned, it's possible to build such systems without that limitation. (though the proofs are not as insanely small in the things people have been coming up with) 20:07:38 * nsh nods 20:09:42 can you formalize the argument that privacy is in some way proportional to communicative efficiency in a system of distributed ledger (or more generally a distributed many-party-input dataset)? 20:10:10 it makes sense intuitively that there's an overhead to bearing deanonymising information 20:10:18 nsh: probably. I mean, I gave the adhoc outline of the argument... right. 20:10:19 but it's be nice to think about it more mathematically perhaps 20:11:37 oh, i wonder 20:11:49 if you can apply a thermodynamic analysis to the system 20:12:21 with information that can be destroyed/discarded without affecting the security of the system being analogous to waste heat 20:12:35 there is a counting argument. 20:12:42 midnightmagic_ is now known as midnightmagic 20:12:49 * nsh nods 20:13:01 There are many ways to get from state A to B. An anonymous system doesn't care which one you take, an non-anonymous system does. 20:13:25 right 20:14:00 all we care about is certain rules about the traversal from the space of A to the space of B 20:14:13 not the exact paths 20:15:32 so the compression/succinctness is a product of symmetries defined by our agnosticism 20:15:37 probably easier to just compute the entropy of the deanonimizing information and say you save that. Though it's a little more complicated: if a coin used these states and proofs approach it would also compress away a bunch of non-anonymity related overhead. 20:15:51 And so you'd just get the anonymity savings as a side effect 20:15:57 oh, hmm 20:16:04 what other overhead is saved? 20:16:07 gmaxwell it seems to me that Peter todd's proposal for an inputs-only chain would be both more scalable (because miner's validations become simpler) and more private (because no miner gets full transactions) 20:16:29 at least more "spherically scalable" 20:16:41 jtimon: it's orthorgonal! ideally you combine these things. The proofs prevent linear complexity from signatures, the MMR stuff keeps the state space minal. 20:16:47 but the problem remains, why would miners mine in such a system 20:17:09 (thats also why I kept qualifying above as "if we were to do this as bitcoin is today") 20:17:17 yeah, I mean combining his proposal with full-block snark 20:17:30 I se 20:17:31 e 20:17:35 nsh: e.g. there are 2^big ways to satisfy a typical scriptpubkey. 20:17:46 nsh: which of those you used would be hidden. 20:17:53 oh, right 20:18:11 there are advantages to script transparency though 20:18:14 for contracts, etc. 20:18:30 nsh: sure, but you can make them transparent directly between the users. 20:18:36 right 20:19:23 No system that discloses the transactions can have better than linear scalablity in the size of new blocks for full nodes. ... 'cause you recieve data per transaction. 20:19:53 instead you use some snark and you end up with sublinear communications and validation complexity. The larger the system the bigger the advantage. 20:20:16 but there is some preprocessing cost, or something 20:20:34 there are constants. 20:20:41 yeah, that would be the scalability vs centralization tradeoff 20:20:48 jtimon: I don't think there is. 20:21:23 you say the bigger the system the bigger the advantage 20:22:20 wouldn't a system that processes 1 M tx per snark block imply more centralization than one that only processes up to 100 tx/block? 20:22:51 jtimon: I don't see why? 20:23:17 just talking about the miner's computational costs? 20:23:43 because there are less computers in the world capable of validating that number of transactions? 20:24:02 jtimon: okay, but then just don't produce a block with 1M transactions. 20:24:38 the snarks mean that the verifiers cost is not related the block size (or at least sublinear, perhaps constant) 20:25:10 ok, I could only process 100 tx, but then I won't be able to compete with miners that do produce 1M transactions 20:25:42 'compete'? in any case, to the extent thats true you can still cap blocks 20:26:17 that was my point 20:26:54 by compete I mean earning "equivalent fees" as the other miners for the "same" pow 20:27:32 oh, hmm 20:29:18 so the cap on transactions per block would be to defend p2p-ness against scalability 20:30:34 jtimon: not just that, in bitcoin we need some reason for the fee to be >1e-8 btc. :P 20:31:08 well, divisibility can be improved 20:31:09 jtimon: but at least such a change would make it so that someone _else_ producing enormous blocks didn't keep non-miners and smaller from validating... so the impact is reduced. 20:31:36 jtimon: that wasn't my point. for the system to be secure we need the pow to be many orders of magnitude more expensive that validation 20:31:59 otherwise the validation is most of the operating cost, and an attacker that just mines a few doublespending txn has an advantage. :) 20:32:11 oh, I see 20:33:11 an interesting point would be to have a cap only on fee paying txn, but sadly people would pay fees "out of band" :) 20:33:57 well, there's also demurrage, but now I get your point 20:34:10 hmm, so there's really no way to cap transactions 20:34:25 jtimon: hm? sure there is— it can just be part of the proof. 20:34:42 oh, sure 20:35:20 though "writes to the spent coin list" or something might be a better capacity metric in a system that has been MMR compressed. 20:36:40 I'm not sure I understand MMR but it's basically a tree structure for the utxo, like mmaaku's but with other properties, no? 20:36:48 maaku's 20:39:56 on the inputs-only proposal, I know petertodd wanted "pow fees" for anti-spam, but does anyone know if he had something in mind for miner's rewards? 21:01:23 it seems like i missed a very cool conversation about entropy of identifying information.. 21:01:35 if there are no complaints i'll set up a cronjob to publish logs for this channel 21:01:44 andytoshi-logbot has been recording for a few days now, seems to be working.. 21:02:25 +1 21:02:59 ok, lemme just finish catching up on the logs in secret :} 21:06:58 http://download.wpsoftware.net/bitcoin/wizards/ 21:07:13 how many 'official' places does dev discussion happen now 21:07:45 at least 2 irc hcans i know of, the sourceforge list, the github list 21:08:13 which one is the 'source of record' as it were, if the aim is transparency 21:10:26 is there a github mailing list? it seems like github links you to sourceforge.. 21:11:35 no there isn't 21:11:40 the mailing list is sourceforge 21:11:45 the issue tracker is github 21:12:00 the github threads system seems like you can email in and out of it 21:12:06 probably wrong to call it a list 22:15:35 zooko` is now known as zooko 23:34:51 Fistful_of_AFK is now known as Fistful_of_LTC