00:00:01 andytoshi: trying to have an anti-double-spending bond? 00:00:28 gmaxwell: yeah, but it's not working out :P 00:00:29 one problem with those is then how do you prevent the bond from being multiple subscribed? 00:00:54 e.g. I make one 1 btc bond. Then I make 1000 0.5 BTC spends secured against it… 00:00:54 andytoshi, bond for what? 00:02:07 petertodd: Are there any posts or technical details on how sharding the blockchain would work? Would it involve removed anonymity? 00:02:19 gmaxwell: well, what if we had some kind of global consensus on who was making use of the bond? 00:02:22 * petertodd ducks 00:02:24 phantomcircuit: the idea is, i send you some money -- they rather than having you wait for a confirm, i construct an output (which i own) such that you can just take it if you can prove that i've double-spent you 00:02:52 petertodd: but then you have to wait for that consensus to settle, defeats the purpose. 00:03:28 * justanotheruser frowns 00:03:51 gmaxwell: that was the joke :) 00:04:22 justanotheruser: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html is the best writeup I have 00:04:33 I'd say you could trust a broadcast network to tell you about compeating bond usage, except the theif could redeem his own bond. 00:04:39 justanotheruser: and it's not strictly about sharding, but you can easily see how it could be 00:04:52 gmaxwell: that's the problem that just occured to me when i said "it's not working out :P" 00:04:55 (and he's not obligated to tell the broadcast network) 00:05:09 gmaxwell: hence it needs to be partial redeem, partial destroy 00:05:31 petertodd: thanks 00:05:44 andytoshi: this isn't to say that such bonds might not be useful. E.g. large ones which mostly destroy their funds. (they only pay at all as a reward for making the cheating public) 00:05:50 justanotheruser: I had another post on bitcointalk somewhere from a few months back 00:06:21 but there needs to be a way to transfer ownership of such bonds. 00:07:33 gmaxwell: which I solved, but soon realized then you also need a way to prove that proof-of-fraud isn't waiting to be released, which means you need consensus about all such fraud, which means proving fraud needs to be proof-of-publication-based. Fortunately this txout scheme I think works here. 00:07:56 gmaxwell: e.g. the proof is the txout bond hasn't been spent via fraud proof 00:09:00 justanotheruser1 has joined #bitcoin-wizards 00:09:37 right, but how do you allow transfer and not create a race between a transfer and a fraud? 00:10:06 gmaxwell: you create an intermediate "cooling off" period before a transfer can actually go through 00:10:23 I guess by having two outputs, one for transfer, one for fraud, and fraud can still be published for some time after the transfer before it settles? 00:10:38 yea, makes sense the resulting protocol has a number of steps though, which is unfortunate. 00:12:01 justanotheruser has quit 00:12:05 Yeah, or some multisig scheme with some kind of mutually agreed on cooling off tx - lots ofpossibilities. 00:12:38 Well, I think the cooling off thing is unavoidable to be fair to people potentially relying on the bond. 00:12:44 anyone honoring the bond needs to know the ... right 00:13:09 Which also means the bond txout really needs to be able to constrain the txout of the tx spending it. :( 00:13:19 esp if you want to allow the bond to be honored by 'offline' devices. 00:13:24 yup 00:13:52 petertodd: right, and that means that you have to precommit to your output and you lose the 'spend without waiting for confirmations' benefit :( 00:14:14 andytoshi: only if you expect people to get paid from the bond. 00:14:52 andytoshi: the alternative is you give up on that and just set it up so that misbehavior costs the misbehaving party their valuable bond... you don't get paid back but they don't get to keep using the bond. 00:15:52 gmaxwell: no, you just make some of the reward of proving fraud be paid out, and some destroyed, and make the destroyed amount larger than the payout amount 00:16:46 petertodd: you still can't promise the defrauded person get paid no matter how much the bond pays out 00:16:49 sure, but how does this make it possible to use the bond without commiting to the output? 00:17:05 ah, because 'overcommitting' is not a thing 00:17:06 gmaxwell: ah, right 00:17:08 andytoshi: because you're not promising that any particular victim can get paid. 00:17:11 right. 00:17:25 The payment the victim gets is just for the trouble of actually announcing to the world that they got ripped off. 00:17:40 gah, I should have written this up back when I was thinking about this stuff for fidelity bonded banks... 00:18:16 gmaxwell: yeah, they're not guaranteed to be made whole, and it's tricky to guarantee the fraudster has a net loss 00:21:19 justanotheruser1 has quit 00:21:22 unrelated: took a look at the twister twitter blockchain thing, and it's difficulty is 0.002... a single GPU scrypt miner could 51% attack the thing 00:21:28 haha one of my coworkers just asked me about his ntp daemon at home using lots of bandwidth 00:21:36 whut? 00:21:49 "Uh. maybe there is a NTP reflection DDOS attack" "oh look, one was recently found and is being exploited" 00:21:56 lol 00:23:12 petertodd: suppose that you've got like a 1btc bond, and it's only considered valid by fast food restaurants and groceries (who want the bond value to be some large multiple of the product value) 00:23:28 then to get a net win a scammer would have to get to a whole ton of physical stores within a blocktime or two 00:23:57 (and any more than a blocktime would require some sort of mining-based attack) 00:24:00 andytoshi: sure, but that just goes to say you have to take countermeasures against that kind of thing or it's easy to rip off 00:24:06 andytoshi, or coordinate with lots of other scammers 00:24:12 andytoshi: really these things make more sense in the context of an anti-doublespending signer service rather than personally, as the signer service could afford a bond a huge multiple of the typical transaction prices. 00:24:24 (organized russian crime groups do this fairly regularly with atm heists) 00:24:38 (and could also be secured by hardware remote attest) 00:24:53 gmaxwell: esp if the signing service provides some kind of proof of how many uncommitted btc they've signed for 00:25:12 phantomcircuit: right, derp 00:25:34 gmaxwell: neat, then you've got a traditional debit-card system but with a bit less trust 00:26:11 petertodd: if only someone recently described how to run a cryptographically private accumulator... 00:26:33 gmaxwell: I know 'eh? 00:26:49 * andytoshi has one last exam tomorrow, better get off -wizards before somebody posts a link 00:26:49 lol 00:27:03 justanotheruser has joined #bitcoin-wizards 00:27:03 justanotheruser has quit 00:27:03 justanotheruser has joined #bitcoin-wizards 00:27:13 andytoshi is now known as andytoshi-away 00:30:29 jtimon has quit 00:34:40 justanotheruser has quit 00:34:45 StormCC has joined #bitcoin-wizards 00:35:34 justanotheruser has joined #bitcoin-wizards 00:39:31 petertodd gmaxwell: I had a "duh" moment, but if prefixed proofs become *required* for transaction and block propagation, then it doesn't matter how the (U)TXO index is keyed, right? or the size of the UTXO set? 00:40:06 maaku: it's impossible to require them effectively 00:40:18 well, setting that aside... 00:40:56 spherical cow analysis, if you could get every node to upgrade, etc. 00:41:53 then you'd get collusion between miners who greatly reduce their bandwidth to each other by leaving out proofs they don't need because they have parts of the utxo set cached 00:42:39 i'm not sure that's a problem, except as it applies to decentralization 00:43:07 well if it's not a problem, then why did you want to require them? 00:43:08 perhaps I'm missing some context, as I don't see what maaku is talking about (maybe it was something too obvious?) 00:43:29 I assume for fairness, otherwise you might as well just only provide proofs when needed 00:43:55 justanotheruser has quit 00:43:55 justanotheruser has joined #bitcoin-wizards 00:44:08 justanotheruser is now known as justanotheruser1 00:44:11 well it's very obvious now that i think about it, but the trigger was that I as assuming you need to store the UTXO twice to support scriptPubKey-indexing 00:44:19 the whole idea of the MMR-structured data was that it let you make a storage/bandwidth tradeoff if you could always demand a peer give you proofs with their transactions. 00:44:33 justanotheruser1 is now known as justanotheruser 00:45:12 oh no, you wouldn't though you should note that scriptPubKey-indexing isn't naturally computationally balanced— so its a poor index. 00:45:14 petertodd: do you think blockchain sharding will be implemented some time soon? 00:45:25 justanotheruser: heck no 00:45:29 (also making address reuse cheaper is unfortunate) 00:45:33 but if a proof comes with a transaction, you could just mandate that proofs contain the paths to the inputs in the scriptPubKey index, and a mapping of txid:n -> scriptPubKey 00:46:13 petertodd: what is the number of full nodes drops below 2k? 00:46:31 yea, sure. Doesn't mean that indexing by scriptPubKey is actually desirable, but if you change how transactions look up their inputs, then indeed, you don't need two indexes. 00:46:40 " (also making address reuse cheaper is unfortunate)" <-- yes i'm onboard with that. this is more of a -wizards hypothetical 00:47:00 ::nods:: 00:47:04 yeah ok i was stupid for not realizing that earlier 00:47:11 justanotheruser: sharding requires miner co-operation and a soft-fork 00:47:55 petertodd: yes, wouldn't it be necessary because the number of full nodes is dropping? 00:48:19 well, if we can create a currency from scratch, with outputs being (value, merkle-ast-root) and inputs being (merkle-script, script inputs), you can easily (except for potential unbalancing) have your UTXO tree indexed by (merkle-ast-root, txid) 00:48:58 justanotheruser: re "blockchain sharding" sortof, that will come soon 00:49:11 if, that is, you mean pruning where some nodes only store ranges of blocks 00:49:20 not tomorrow though, but soon 00:49:49 maaku: I mean blockchain sharding as in https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html 00:50:03 so you only need a single UTXO data structure for both validation lookups and lightweight node balance checking 00:50:38 The unbalancing could be avoided by just prohibiting reuse. You end up with a design close to an anonymous coin then. E.g. where outputs do blinded inserts into a existing coin list, and where inputs unblind coins, prove the coins exist, and they are added to a spent coin list. 00:51:48 justanotheruser: necessary doesn't make stuff actually happen you know, more likely lack of full nodes just pushes people to use web-wallet stuff 00:52:26 justanotheruser: with so few pools the politics of the situation are unknown and may not be what we want... 00:52:26 gmaxwell: btcguru in #bitcoin is linking to a sketchy website. No results on google 00:53:16 petertodd: why would the number of pools effect that? 00:53:26 sipa: ugh, I really think we're best off avoiding that kind of single-scriptPubKey balance checking stuff 00:53:48 justanotheruser: because they're large enough that more centralization and fewer nodes out there may be in their interests 00:54:25 sipa: yeah that was more my line of thinking. indexing by txid or by insertion order isn't really useful, other than that's how bitcoin is structured (scriptPubKey isn't available in the input) 00:54:42 and, i guess, useful in that it doesn't encourage bad, bad things like dumping data on the block chain 00:55:13 maaku: or address re-use 00:55:23 petertodd: maybe - i don't like the privacy implications of that either 00:56:23 petertodd: yeah, although I don't know how to support looking up bip 32 or keypool addresses without also encouraging address reuse :( 00:57:07 maaku: use fixed prefixes so all you're reusing is the prefix, which still gets you a decent anonymity set (see my recent post on blockchain data) 00:58:13 maaku: for change I think we can get away with totally random change addresses as the set of *unspent* change txouts doesn't have to grow 01:02:15 Graet has quit 01:03:06 Man, people are going to love anonymous coins where efficient lookups for payments to you is impossible. 01:04:09 gmaxwell: ? 01:04:49 Graet has joined #bitcoin-wizards 01:06:24 petertodd: if you have an truly anonymous cryptocurrency, e.g. one that worked by committing to blinded coin values in an insertion ordered tree.. there is no way to tell someone paid you from just inspecting the currency. 01:07:33 They'd have to tell you out of band, or you'd have to have a seperate channel e.g. for storing ECDH keyed encrypted messages "hey, I paid you, the blinded coin has value X" 01:07:40 gmaxwell: oh sure - all this business about stealth addresses is just a way of relaxing that anonymity a bit so you can recover the payment. even a fully anon cryptocurrency can always bolt on a messaging layer to provide that channel 01:08:08 yea, but interestingly the messaging layer could easily break the privacy. 01:08:10 gmaxwell: if bitmessage was reliable, you'd just use it, but it's not for non-interactive use 01:08:22 e.g. if the messages have a visible to it likely removes it completely. 01:08:42 gmaxwell: well, if you re-use something like bitmessage, at least your anonymity set also includes random messages unrelated to payments 01:09:02 an interesting point. 01:09:46 Are you referring to zerocoin? 01:09:55 Anyway, figuring out how to make the user-experience of "must send this packet of data for foo to get their coin at all" to be acceptable might come in handy for other crypto-currency schemes like txin commitments where the network doesn't have the data at all. 01:10:28 petertodd: well in general seperating the accumulator operation from notice is interesting. Esp since there are different durability requirements. 01:10:46 e.g. losing old notices, ::meh:: 01:11:30 gmaxwell: yup 01:11:34 justanotheruser: no. 01:20:38 Morici v Hashfast Technologies 01:20:40 and so it begins 01:20:42 Case5:14-cv-00087 01:24:12 shesek has quit 01:26:47 phantomcircuit: do you have some data feed of bitcoin relevant docket entries? 01:27:58 gmaxwell, yes 01:28:22 fun with lexus nexus 01:28:25 Is anyone aware of any fully homorphic encryption schemes can have a plaintext output? e.g. the code inside the FHE decides to write to a plaintext output 01:28:31 phantomcircuit: any details on it? 01:28:43 gmaxwell, i'll upload the complaint in a minute 01:31:02 gmaxwell, also it should be on RECAP now 01:31:03 Graet has quit 01:33:23 Graet has joined #bitcoin-wizards 01:34:03 huh not working 01:36:40 and of course, pacer's password recovery takes like ... days 01:38:03 you folks manage to get it? I have westlaw and lexis access right now 01:38:07 eristisk has quit 01:40:40 warren, i have it but scribd doesn't like me 01:43:02 gmaxwell, http://198.27.67.106/hashfast.pdf 01:43:55 phantomcircuit: Can I post that URL on the forum? 01:44:25 from PACER? 01:44:34 gmaxwell, sure 01:44:37 Thanks. 01:45:14 warren, yes 01:45:55 well, good luck to them on getting their BTC back... USD value seems more likely 01:47:05 warren, sure, but at what day? 01:47:19 warren, did you notice the spike to 1000 on mtgox? 01:47:23 i wonder if that's a coincidence 01:47:28 or you know... not 01:49:49 michagogo|cloud, yes, it is time to update bootstrap torrent. Past time, even. 01:50:46 http://ia600407.us.archive.org/25/items/gov.uscourts.cand.273355/gov.uscourts.cand.273355.docket.html 01:51:37 eristisk has joined #bitcoin-wizards 01:52:24 i wonder if pacer has broken recap on purpose 02:10:25 http://www.archive.org/download/gov.uscourts.cand.273355/gov.uscourts.cand.273355.1.0.pdf 02:10:28 there we go 02:10:41 that cost me like $10 02:10:44 stupid pacer 02:12:32 shesek has joined #bitcoin-wizards 02:44:16 eristisk has quit 02:57:45 +1 on updating the bootstrap torrent 02:58:07 I'm currently catching up my laptop and it's > 10 weeks behind 02:58:25 Been several hours now and I'm just 7 weeks behind now 03:01:39 the torrent is just papering over the lack of the headers first patches. 03:06:18 justanotheruser has left #bitcoin-wizards 03:16:09 fagmuffinz_: it will take just as long to verify via the bootstrap download 03:16:23 unless you manually set a checkpoint or something 03:18:04 maaku, actually it's much faster 03:18:29 maaku: fetch is seriously fuxored now.. 03:19:11 well i guess it depends on your internet speed :P 03:19:23 i'm behind an ADSL.1 here :( 03:19:35 rural speeds 03:24:28 maaku: right you now you can expect to fetch the same blocks over and over again during sync, doesn't help when you're on adsl. :( 03:40:45 nessence has joined #bitcoin-wizards 03:46:58 StormCC has quit 03:49:42 shesek has quit 03:56:19 OneFixt has quit 03:56:43 OneFixt has joined #bitcoin-wizards 04:43:25 jgarzik is now known as home_jg 04:47:23 fagmuffinz has joined #bitcoin-wizards 04:49:12 fagmuffinz_ has quit 05:06:13 maaku has quit 05:06:42 mappum has quit 05:21:34 jgarzik: do you know which block you'll extend it to? 05:22:47 (If so, I can generate the file myself, and be ready to seed when it goes live) 05:25:34 maaku has joined #bitcoin-wizards 05:26:05 maaku is now known as Guest58374 05:27:19 eristisk has joined #bitcoin-wizards 05:31:02 nOg4nOo has joined #bitcoin-wizards 05:32:13 nOg4nOo has quit 05:33:40 warren: http://peercoin.net/index.php < click Myth 2. 05:51:54 gmaxwell: o_O 05:52:35 They were the ones that allow the dev to add new checkpoints at any time without an update to the software, right? 05:52:45 gmaxwell: though that looks ridiculous, it does say they dont enforce checkpoints by default.... 05:52:50 michagogo|cloud: yes 05:53:37 eristisk has quit 05:54:07 eristisk has joined #bitcoin-wizards 05:54:11 BlueMatt: it's not true. 05:54:20 ahh 05:54:22 BlueMatt: the text they're quoting there is about XPM not PPC. 05:54:29 well...thats just ridiculous 05:54:33 BlueMatt: it also says that Bitcoin and Litecoin has "checkpoints" too. 05:54:42 yea 05:54:44 I liked that bit 05:55:06 And even if it were true, if part of the network enforced them DNA another part didn't, that means a hardfork 05:55:14 and* 05:55:50 The PPC consensus model _requires_ them, not just for fuzzy security reasons, but because you cannot validate PoS without a transaction index containing the stake thats being used on the block... so they only allow coins which have been immobile for >30 days to be used for PoS and then use the checkpoints to make damn sure the network agrees about the state in the past. 05:56:23 I also checked the PPC codebase, they're on, and there appears to be no way to turn them off. 05:57:04 gmaxwell: and of course it doesn't matter if it isn't enabled by default, if pools do then the users don't have a choice. 05:58:01 Erm, maybe not hard 06:05:38 Luke-Jr has quit 06:06:00 Luke-Jr has joined #bitcoin-wizards 06:06:05 Luke-Jr has quit 06:06:05 Luke-Jr has joined #bitcoin-wizards 06:07:54 Taek42 has quit 06:09:33 warren has quit 06:14:39 Graet has quit 06:16:20 mappum has joined #bitcoin-wizards 06:17:15 Graet has joined #bitcoin-wizards 06:20:42 Taek42 has joined #bitcoin-wizards 06:40:54 I wish people would ask better questions: http://www.reddit.com/r/Bitcoin/comments/1uoq6e/what_do_you_guys_think_of_proof_of_stake_mining/cek9fhq 06:42:36 I wish reddit would not suck so much 06:43:09 Cardinal example of upvoting/downvoting systems producing herds of fast-moving idiots 06:43:51 I say this as a near-daily reddit user, of course 06:45:12 well-informed cautionary answers on brainwallets routinely get downvoted 06:51:43 eristisk has quit 06:53:25 herding idiots 06:53:31 i'm going to remember that :) 06:54:28 Guest58374 is now known as maaku 06:58:07 the upvoted downvotey stuff overweighs superficial opinions. It's fine for cat pictures. 06:58:13 (which is mostly why I browse reddit) 06:58:28 I hardly read any bitcoin or technology things at all, mostly just funny pictures of animals. 07:00:18 I'm not sure that it's a symptom of upvotes and downvotes so much as Reddit being a general audience 07:01:04 people are stupid 07:01:09 Taek42: nah, normally the general audience doesn't have their hands firmly placed on the steering wheel. 07:01:20 it boggles my mind that when you have a crowd of them, wisdom is supposed to emerge 07:01:42 lol 07:01:55 democracy! 07:02:00 to be fair even the crappy "Wisdom of the crowds" book said that wasn't actually so. 07:04:37 eristisk has joined #bitcoin-wizards 07:04:38 I've often wondered what would happen if voting had a cost to it, and you could pick the power of your vote by adjusting the cost 07:04:39 never actually read it. was the thesis that you need proper incentives? 07:07:46 Taek42: a monetary cost, you mean? 07:08:08 well, some sort of currency that could be swapped for real currency 07:08:11 citizen cost a la starship troopers? 07:08:11 dogecoin, perhaps 07:08:18 voting already has a substantial cost in terms of time/trouble. 07:08:33 on reddit, the first vote is pretty costly 07:08:42 seeing as you have to log in, and maybe create an account 07:08:46 but the rest are painless 07:09:39 Or creddits 07:09:48 I imagine though that it wouldn't actually be that different even if there were a monetary cost to each vote (or a karma cost) 07:10:23 The problem being that the average person could have as much authority/power as the expert 07:10:27 I seem to recall there was some site like that 07:10:39 Where you spend reputation points to vote 07:11:22 gmaxwell, is there still a penalty for p2pool? 07:11:32 iirc there used to be a substantial orphan rate 07:11:57 also @anybodyelse 07:12:20 phantomcircuit: it has the lowest orphan rate of any pool as far as I can tell. 07:12:38 what's it's current orphan rate? 07:13:02 there has been two this year. 07:14:01 0.12% in my data. (eligius, by comparison, has been ~1%) 07:14:25 that's interesting 07:14:52 phantomcircuit: p2pool changed a couple years ago to a model where nodes pre-forwarded transaction data to their peers. So when one finds a block it just has to send the list of transactions that were actually in it. 07:15:38 theoretical problem: suppose every miner picks the maximum-payout pool. Wouldn't every miner end up picking the same pool? 07:15:43 it will also mine a transactionless block in brief windows when the local bitcoind is lagging but p2pool peers have produced shares against a further along chain. 07:15:48 any idea why the orphan rate would be lower than eligius? 07:16:11 phantomcircuit: because it has an enormous network connectivity advantage. 07:16:49 it might also have to do with what kind of hardware is connected to p2pool 07:16:54 some of them have uh 07:17:00 interesting ideas of what stale means 07:17:04 p2pool blocks end up being concurrently announced by a dozen peers in the first 30ms after finding a block... hundreds within 400ms. 07:18:00 warren has joined #bitcoin-wizards 07:18:21 phantomcircuit: maybe, p2pool direct miners to return "stale" shares. 07:18:42 in any case, if some miner is overly agressive in what its discarding, its not getting paid for that portion of its work. 07:26:22 eristisk has quit 07:30:28 Luke-Jr has quit 07:31:17 Luke-Jr has joined #bitcoin-wizards 07:40:15 eristisk has joined #bitcoin-wizards 07:45:51 Graet has quit 07:48:50 Graet has joined #bitcoin-wizards 07:52:58 mappum has quit 08:13:00 nessence has quit 08:18:52 fagmuffinz has left #bitcoin-wizards 08:18:57 fagmuffinz has joined #bitcoin-wizards 08:32:47 <_ingsoc> _ingsoc has joined #bitcoin-wizards 08:45:23 roidster has joined #bitcoin-wizards 08:51:51 I think bitcoin is becoming the new DHT. :( 08:52:49 yo, slap a blockchain on it 08:53:26 Graet has quit 08:53:32 COULUD STAND FOR HEMROID 08:53:57 could* pardon the caps 08:55:10 gmaxwell: I think we've known that was gonna happen for a while 08:55:33 /has been happening for a while 08:55:43 well yes bitcoin is the new idea of the day, so now we're in the [try_with_new_idea(x) for x in old ideas] phase 08:56:47 and you get nonsensical ideas, like in the internet boom.... just like your old pet shop, but online! 09:02:26 Graet has joined #bitcoin-wizards 09:06:48 a miracle happened on reddit today 09:07:02 someone mentioned my name in a ppc thread, which is what brought my attention to those claims on that website. 09:07:09 I refuted them with citations to source code. 09:07:29 URL? 09:07:34 (reddit thread) 09:08:02 http://www.reddit.com/r/Bitcoin/comments/1uoq6e/what_do_you_guys_think_of_proof_of_stake_mining/cek7vbc 09:08:30 and someone argued with me... and then actually accepted my counter arguments. and I'm not being voted down! 09:14:23 i've been explaining the problem with PoS a few times now at the zurich bitcoin meetups 09:14:35 people do seem to understand it 09:18:11 it makes me sad, I really wish it worked. 09:19:11 justanotheruser has joined #bitcoin-wizards 09:19:37 What are the potential problems of associating namecoin registration price with transaction fee sum? 09:19:53 what is a "transaction fee sum"? 09:20:15 Graet has quit 09:20:46 if you mean some function of recent transaction fees … the problem is miners padding up transaction fees with payments to themselves to manipulate prices (might as well just let miners set them) 09:20:58 gmaxwell: you could look at how much was paid in tx fee since the last difficulty adjustment (or some other arbitrary period of time) 09:21:36 gmaxwell: yeah, that is a problem 09:22:18 There's not really a way to evaluate how many namecoin users there are... 09:22:39 you can look at the registrations however. 09:23:00 Graet has joined #bitcoin-wizards 09:23:00 (and also, it's easy to see it not being used anywhere, and even easy to see the lack of people asking how to use it) 09:23:02 gmaxwell: but you can't set the registration rate based on the number of registrations 09:23:31 yea oh sorry I thought you were back to suggesting that namecoin isn't currently a failure. :P 09:23:51 If there were only 500 domains offered per day, people would have to compete in price for registering. 09:24:17 Unfortunately namecoin isn't going to ever be stable, so you can't say "$10 for a registration" 09:24:27 yea, I've got no freeking idea. yes, one possible way would be to make the database fixed in size or something like that. 09:25:18 if people compete in price it would have to be in mining fees, so the miners would be able to register however many domains they wanted... 09:25:25 well with 2 way-peg you could transfer bitcoins into the namecoin chain to pay for names, thus giving them to miners, who can remove them from the namecoin chain. (I mean, if we're talking about things which decidely aren't namecoin as it is today) so then the instability of namecoin as a tradable asset can be removed. 09:25:44 but I guess for every domain they buy, they lose one domain sale that day 09:25:45 justanotheruser: unless the system just limits it via a protocol rule. 09:26:26 gmaxwell: is there a way to have a decentralized 2 way peg? 09:26:58 I guess you missed those discussions. I believe it's possible, there are some security limitations. 09:27:30 also I don't think pegging something to bitcoin makes it stable. It makes it more stable relative to all other cryptocurrencies, but relative to almost every other asset/commodity bitcoin is incredibly unstable 09:28:11 basically I suggested a relatively minor softforking addition that would allow you to assign coins to another chain, and then carry a proof back from the other chain to bitcoin to allow you to very slowly teleport coins back and forth. 09:28:20 (slowly meaning like 100 blocks) 09:28:50 gmaxwell: would this allow for offchain transactions if the bitcoin chain was too big making transaction fees high? 09:29:20 well not "if", but for that reason would it be useful 09:29:31 it would. or more interesting it would allow altcoins to expirement with new ideas without also creating new currencies. (at least when the idea is just new payment network ideas) 09:30:14 Graet has quit 09:30:17 e.g. you could have namecoin but without having a seperate namecoin currency. or you could have some 10 second blockchain thing (0_o) or something with more powerful script. 09:30:29 (turing complete script, whoppie!) 09:30:38 gmaxwell: is the peg discussion in #bitcoin-dev logs? 09:30:43 it's in the logs here. 09:30:58 any public logs for this channel? 09:31:07 andytoshi-away: makes logs, dunno where they are. 09:31:14 (The logs should really be mentioned in the topic...) 09:32:03 I'll make a note to ask him for the logs 09:32:07 it's not a serious proposal at this time... but perhaps it will become one. The belief that it could work two ways is relatively new. (it's not that complicated an idea though, I'm sure I would have said it was obvious in 2011 if it had been suggested to me then) 09:32:55 gmaxwell: so would this pretty much remove the need for Open Transactions? 09:32:58 Graet has joined #bitcoin-wizards 09:33:42 but in any case the idea is that you make a payment to a special scriptpubkey which basically says "these coins are now controlled by foocoin" and then it's possible to spend from txouts to that scriptpubkey by showing up with an SPV proof "foocoin says you should give me X of those coins to scriptpubkeys Y and Z", plus some extra details. 09:34:21 justanotheruser: well it would allow the same kind of "binding" that open transactions could do already using multisig ... but allow it for other blockchain cryptocurrencies. 09:34:38 gmaxwell: isn't the only way for that SPV proof to exist by embedding all those block headers in the bitcoin blockchain? 09:35:35 Or is there some way that the miner can be proved that their blockchain says something without actually looking at anything other than the transaction 09:35:36 justanotheruser: sure, but 100 blocks is 8kb. whopptie do. These transfers would generally be infrequent because they'd be used for bulk liquidity, normally if you want coins on the other chain you find someone who wants bitcoin and you do an atomic coinswap. 09:35:59 But the coinswaps alone cant get you a 2-way peg because they can't provide long term liquidity. 09:37:13 justanotheruser: the proofs could also be structured so that they can be pruned. e.g. perhaps the only thing that gets stored in the blockchain directly is a summary of the proof. After all the proof only has SPV security, once it's thousands of blocks deep in bitcoin why keep it? (and if that were done the proof wouldn't need to count against the block size limit, or wouldn't need to count against it fully) 09:38:22 (also a single proof could actually be batching dozens of transfers, e.g. foocoin tells bitcoin a whole list of scriptpubkeys to pay, at least you can get batching in the foo->bitcoin direction) 09:39:05 gmaxwell: Seem expensive still. The blockchain could end up storing a dozen other blockchain headers in it 09:39:33 e.g. the foo->bitcoin instructions are generated by foocoin miners, summarizing actions commanded by transactions and validated according to the foocoin rules. 09:40:06 justanotheruser: well snarks can compress that kind of thing down to 384 bytes for 128 bit security, but I'd prefer to show it viable without any cutting edge cryptography. 09:40:41 I wonder if there's some crypto that could be used to do that proof in a size significantly smaller than the actual altchain 09:40:44 justanotheruser: and each of those dozens of other chains could have an infinity of transactions, seems like a good tradeoff to me. 09:41:08 gmaxwell: do you think that's more viable than sharding the blockchain? 09:41:47 justanotheruser: zk-SNARKs can have size only proportional to the security level. The size of the rule being proven or the data it accesses is irrelevant to them. 09:43:30 but the really small ones have some uncomfortable security tradeoffs (CRS assumption) the ROM ones are somewhat larger (eg 20kb, though I did invent a novel compression scheme which may help, so they may not be good for compressing header proofs, but then again they'd allow full security not just spv, potentially.. but this is all really cutting edge and not yet totally pratical stuff.) 09:44:02 hmm 09:44:48 gmaxwell: do you have some cryptography PhD or something? 09:45:14 in any case, I don't think an 8kb signature intermittently per bound chain is a bad tradeoff. Especially knowing that application of sufficient magic could make it smaller in the future. 09:45:31 justanotheruser: No. I'm just some guy who enjoys math. 09:45:41 I see 09:45:57 This idea seems to have a lot of potential 09:46:44 Would this not require disabled opcodes to determine whether the transactions belonged to someone else on this other chain? 09:47:05 I guess you said it was a softfork, so my real question is why wouldn't it 09:47:21 I think it does too. well, and it also may solve a problem thats been bothering me— which is that its hard to do novel cryptocoin expirementation. We can't mess around with it in bitcoin because its too important. Alt systems generally get little love because they're worthless, unless you make a big thing about pumping their value and then that speculation becomes all encompassing. 09:48:03 justanotheruser: we'd add a new opcode in place of a no-op today "the thing on the stack is a chain binding proof, this transaction is only valid if the proof is valid" 09:48:41 old nodes would just see a no-op transaction and permit it. 09:49:00 It would be safe to use once a super majority of hashpower agreed to enforce it as a rule in the chain— same way p2sh was deployed. 09:49:47 gmaxwell, what's your opinion of XRP? 09:50:39 Taek42: https://bitcointalk.org/index.php?topic=144471.0 the whole thread is informative, I answer my own question and then get into a discussion with one of the ripple developers. 09:50:54 thanks 09:53:08