00:00:01gmaxwell:andytoshi: trying to have an anti-double-spending bond?
00:00:28andytoshi:gmaxwell: yeah, but it's not working out :P
00:00:29gmaxwell:one problem with those is then how do you prevent the bond from being multiple subscribed?
00:00:54gmaxwell:e.g. I make one 1 btc bond. Then I make 1000 0.5 BTC spends secured against it…
00:00:54phantomcircuit:andytoshi, bond for what?
00:02:07justanotheruser:petertodd: Are there any posts or technical details on how sharding the blockchain would work? Would it involve removed anonymity?
00:02:19petertodd:gmaxwell: well, what if we had some kind of global consensus on who was making use of the bond?
00:02:22petertodd:* petertodd ducks
00:02:24andytoshi: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:52gmaxwell:petertodd: but then you have to wait for that consensus to settle, defeats the purpose.
00:03:28justanotheruser:* justanotheruser frowns
00:03:51petertodd:gmaxwell: that was the joke :)
00:04:22petertodd:justanotheruser: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html is the best writeup I have
00:04:33gmaxwell: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:39petertodd:justanotheruser: and it's not strictly about sharding, but you can easily see how it could be
00:04:52andytoshi:gmaxwell: that's the problem that just occured to me when i said "it's not working out :P"
00:04:55gmaxwell:(and he's not obligated to tell the broadcast network)
00:05:09petertodd:gmaxwell: hence it needs to be partial redeem, partial destroy
00:05:31justanotheruser:petertodd: thanks
00:05:44gmaxwell: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:50petertodd:justanotheruser: I had another post on bitcointalk somewhere from a few months back
00:06:21gmaxwell:but there needs to be a way to transfer ownership of such bonds.
00:07:33petertodd: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:56petertodd:gmaxwell: e.g. the proof is the txout bond hasn't been spent via fraud proof
00:09:37gmaxwell:right, but how do you allow transfer and not create a race between a transfer and a fraud?
00:10:06petertodd:gmaxwell: you create an intermediate "cooling off" period before a transfer can actually go through
00:10:23gmaxwell: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:38gmaxwell:yea, makes sense the resulting protocol has a number of steps though, which is unfortunate.
00:12:05petertodd:Yeah, or some multisig scheme with some kind of mutually agreed on cooling off tx - lots ofpossibilities.
00:12:38petertodd:Well, I think the cooling off thing is unavoidable to be fair to people potentially relying on the bond.
00:12:44gmaxwell:anyone honoring the bond needs to know the ... right
00:13:09petertodd:Which also means the bond txout really needs to be able to constrain the txout of the tx spending it. :(
00:13:19gmaxwell:esp if you want to allow the bond to be honored by 'offline' devices.
00:13:24petertodd:yup
00:13:52andytoshi: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:14gmaxwell:andytoshi: only if you expect people to get paid from the bond.
00:14:52gmaxwell: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:52petertodd: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:46gmaxwell:petertodd: you still can't promise the defrauded person get paid no matter how much the bond pays out
00:16:49andytoshi:sure, but how does this make it possible to use the bond without commiting to the output?
00:17:05andytoshi:ah, because 'overcommitting' is not a thing
00:17:06petertodd:gmaxwell: ah, right
00:17:08gmaxwell:andytoshi: because you're not promising that any particular victim can get paid.
00:17:11gmaxwell:right.
00:17:25gmaxwell:The payment the victim gets is just for the trouble of actually announcing to the world that they got ripped off.
00:17:40petertodd:gah, I should have written this up back when I was thinking about this stuff for fidelity bonded banks...
00:18:16petertodd:gmaxwell: yeah, they're not guaranteed to be made whole, and it's tricky to guarantee the fraudster has a net loss
00:21:22petertodd: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:28gmaxwell:haha one of my coworkers just asked me about his ntp daemon at home using lots of bandwidth
00:21:36petertodd:whut?
00:21:49gmaxwell:"Uh. maybe there is a NTP reflection DDOS attack" "oh look, one was recently found and is being exploited"
00:21:56petertodd:lol
00:23:12andytoshi: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:28andytoshi: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:57andytoshi:(and any more than a blocktime would require some sort of mining-based attack)
00:24:00petertodd: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:06phantomcircuit:andytoshi, or coordinate with lots of other scammers
00:24:12gmaxwell: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:24phantomcircuit:(organized russian crime groups do this fairly regularly with atm heists)
00:24:38gmaxwell:(and could also be secured by hardware remote attest)
00:24:53petertodd:gmaxwell: esp if the signing service provides some kind of proof of how many uncommitted btc they've signed for
00:25:12andytoshi:phantomcircuit: right, derp
00:25:34andytoshi:gmaxwell: neat, then you've got a traditional debit-card system but with a bit less trust
00:26:11gmaxwell:petertodd: if only someone recently described how to run a cryptographically private accumulator...
00:26:33petertodd:gmaxwell: I know 'eh?
00:26:49andytoshi:* andytoshi has one last exam tomorrow, better get off -wizards before somebody posts a link
00:26:49phantomcircuit:lol
00:27:13andytoshi:andytoshi is now known as andytoshi-away
00:39:31maaku: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:06petertodd:maaku: it's impossible to require them effectively
00:40:18maaku:well, setting that aside...
00:40:56maaku:spherical cow analysis, if you could get every node to upgrade, etc.
00:41:53petertodd: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:39maaku:i'm not sure that's a problem, except as it applies to decentralization
00:43:07petertodd:well if it's not a problem, then why did you want to require them?
00:43:08gmaxwell:perhaps I'm missing some context, as I don't see what maaku is talking about (maybe it was something too obvious?)
00:43:29petertodd:I assume for fairness, otherwise you might as well just only provide proofs when needed
00:44:08justanotheruser:justanotheruser is now known as justanotheruser1
00:44:11maaku: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:19gmaxwell: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:33justanotheruser1:justanotheruser1 is now known as justanotheruser
00:45:12gmaxwell:oh no, you wouldn't though you should note that scriptPubKey-indexing isn't naturally computationally balanced— so its a poor index.
00:45:14justanotheruser:petertodd: do you think blockchain sharding will be implemented some time soon?
00:45:25petertodd:justanotheruser: heck no
00:45:29gmaxwell:(also making address reuse cheaper is unfortunate)
00:45:33maaku: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:13justanotheruser:petertodd: what is the number of full nodes drops below 2k?
00:46:31gmaxwell: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:40maaku:" (also making address reuse cheaper is unfortunate)" <-- yes i'm onboard with that. this is more of a -wizards hypothetical
00:47:00gmaxwell:::nods::
00:47:04maaku:yeah ok i was stupid for not realizing that earlier
00:47:11petertodd:justanotheruser: sharding requires miner co-operation and a soft-fork
00:47:55justanotheruser:petertodd: yes, wouldn't it be necessary because the number of full nodes is dropping?
00:48:19sipa: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:58maaku:justanotheruser: re "blockchain sharding" sortof, that will come soon
00:49:11maaku:if, that is, you mean pruning where some nodes only store ranges of blocks
00:49:20maaku:not tomorrow though, but soon
00:49:49justanotheruser:maaku: I mean blockchain sharding as in https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html
00:50:03sipa:so you only need a single UTXO data structure for both validation lookups and lightweight node balance checking
00:50:38gmaxwell: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:48petertodd: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:26petertodd:justanotheruser: with so few pools the politics of the situation are unknown and may not be what we want...
00:52:26justanotheruser:gmaxwell: btcguru in #bitcoin is linking to a sketchy website. No results on google
00:53:16justanotheruser:petertodd: why would the number of pools effect that?
00:53:26petertodd:sipa: ugh, I really think we're best off avoiding that kind of single-scriptPubKey balance checking stuff
00:53:48petertodd:justanotheruser: because they're large enough that more centralization and fewer nodes out there may be in their interests
00:54:25maaku: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:42maaku:and, i guess, useful in that it doesn't encourage bad, bad things like dumping data on the block chain
00:55:13petertodd:maaku: or address re-use
00:55:23sipa:petertodd: maybe - i don't like the privacy implications of that either
00:56:23maaku:petertodd: yeah, although I don't know how to support looking up bip 32 or keypool addresses without also encouraging address reuse :(
00:57:07petertodd: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:13petertodd: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:03:06gmaxwell:Man, people are going to love anonymous coins where efficient lookups for payments to you is impossible.
01:04:09petertodd:gmaxwell: ?
01:06:24gmaxwell: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:33gmaxwell: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:40petertodd: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:08gmaxwell:yea, but interestingly the messaging layer could easily break the privacy.
01:08:10petertodd:gmaxwell: if bitmessage was reliable, you'd just use it, but it's not for non-interactive use
01:08:22gmaxwell:e.g. if the messages have a visible to it likely removes it completely.
01:08:42petertodd:gmaxwell: well, if you re-use something like bitmessage, at least your anonymity set also includes random messages unrelated to payments
01:09:02gmaxwell:an interesting point.
01:09:46justanotheruser:Are you referring to zerocoin?
01:09:55petertodd: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:28gmaxwell:petertodd: well in general seperating the accumulator operation from notice is interesting. Esp since there are different durability requirements.
01:10:46gmaxwell:e.g. losing old notices, ::meh::
01:11:30petertodd:gmaxwell: yup
01:11:34gmaxwell:justanotheruser: no.
01:20:38phantomcircuit:Morici v Hashfast Technologies
01:20:40phantomcircuit:and so it begins
01:20:42phantomcircuit:Case5:14-cv-00087
01:26:47gmaxwell:phantomcircuit: do you have some data feed of bitcoin relevant docket entries?
01:27:58phantomcircuit:gmaxwell, yes
01:28:22phantomcircuit:fun with lexus nexus
01:28:25gmaxwell: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:31gmaxwell:phantomcircuit: any details on it?
01:28:43phantomcircuit:gmaxwell, i'll upload the complaint in a minute
01:31:02phantomcircuit:gmaxwell, also it should be on RECAP now
01:34:03phantomcircuit:huh not working
01:36:40gmaxwell:and of course, pacer's password recovery takes like ... days
01:38:03warren:you folks manage to get it? I have westlaw and lexis access right now
01:40:40phantomcircuit:warren, i have it but scribd doesn't like me
01:43:02phantomcircuit:gmaxwell, http://198.27.67.106/hashfast.pdf
01:43:55gmaxwell:phantomcircuit: Can I post that URL on the forum?
01:44:25warren:from PACER?
01:44:34phantomcircuit:gmaxwell, sure
01:44:37gmaxwell:Thanks.
01:45:14phantomcircuit:warren, yes
01:45:55warren:well, good luck to them on getting their BTC back... USD value seems more likely
01:47:05phantomcircuit:warren, sure, but at what day?
01:47:19phantomcircuit:warren, did you notice the spike to 1000 on mtgox?
01:47:23phantomcircuit:i wonder if that's a coincidence
01:47:28phantomcircuit:or you know... not
01:49:49jgarzik:michagogo|cloud, yes, it is time to update bootstrap torrent. Past time, even.
01:50:46phantomcircuit:http://ia600407.us.archive.org/25/items/gov.uscourts.cand.273355/gov.uscourts.cand.273355.docket.html
01:52:24phantomcircuit:i wonder if pacer has broken recap on purpose
02:10:25phantomcircuit:http://www.archive.org/download/gov.uscourts.cand.273355/gov.uscourts.cand.273355.1.0.pdf
02:10:28phantomcircuit:there we go
02:10:41phantomcircuit:that cost me like $10
02:10:44phantomcircuit:stupid pacer
02:57:45fagmuffinz_:+1 on updating the bootstrap torrent
02:58:07fagmuffinz_:I'm currently catching up my laptop and it's > 10 weeks behind
02:58:25fagmuffinz_:Been several hours now and I'm just 7 weeks behind now
03:01:39gmaxwell:the torrent is just papering over the lack of the headers first patches.
03:06:18justanotheruser:justanotheruser has left #bitcoin-wizards
03:16:09maaku:fagmuffinz_: it will take just as long to verify via the bootstrap download
03:16:23maaku:unless you manually set a checkpoint or something
03:18:04phantomcircuit:maaku, actually it's much faster
03:18:29gmaxwell:maaku: fetch is seriously fuxored now..
03:19:11maaku:well i guess it depends on your internet speed :P
03:19:23maaku:i'm behind an ADSL.1 here :(
03:19:35maaku:rural speeds
03:24:28gmaxwell: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. :(
04:43:25jgarzik:jgarzik is now known as home_jg
05:21:34michagogo|cloud:jgarzik: do you know which block you'll extend it to?
05:22:47michagogo|cloud:(If so, I can generate the file myself, and be ready to seed when it goes live)
05:26:05maaku:maaku is now known as Guest58374
05:33:40gmaxwell:warren: http://peercoin.net/index.php < click Myth 2.
05:51:54michagogo|cloud:gmaxwell: o_O
05:52:35michagogo|cloud:They were the ones that allow the dev to add new checkpoints at any time without an update to the software, right?
05:52:45BlueMatt:gmaxwell: though that looks ridiculous, it does say they dont enforce checkpoints by default....
05:52:50BlueMatt:michagogo|cloud: yes
05:54:11gmaxwell:BlueMatt: it's not true.
05:54:20BlueMatt:ahh
05:54:22gmaxwell:BlueMatt: the text they're quoting there is about XPM not PPC.
05:54:29BlueMatt:well...thats just ridiculous
05:54:33gmaxwell:BlueMatt: it also says that Bitcoin and Litecoin has "checkpoints" too.
05:54:42BlueMatt:yea
05:54:44BlueMatt:I liked that bit
05:55:06michagogo|cloud:And even if it were true, if part of the network enforced them DNA another part didn't, that means a hardfork
05:55:14michagogo|cloud:and*
05:55:50gmaxwell: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:23gmaxwell:I also checked the PPC codebase, they're on, and there appears to be no way to turn them off.
05:57:04warren: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:01michagogo|cloud:Erm, maybe not hard
06:40:54gmaxwell: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:36home_jg:I wish reddit would not suck so much
06:43:09home_jg:Cardinal example of upvoting/downvoting systems producing herds of fast-moving idiots
06:43:51home_jg:I say this as a near-daily reddit user, of course
06:45:12home_jg:well-informed cautionary answers on brainwallets routinely get downvoted
06:53:25Guest58374:herding idiots
06:53:31Guest58374:i'm going to remember that :)
06:54:28Guest58374:Guest58374 is now known as maaku
06:58:07gmaxwell:the upvoted downvotey stuff overweighs superficial opinions. It's fine for cat pictures.
06:58:13gmaxwell:(which is mostly why I browse reddit)
06:58:28gmaxwell:I hardly read any bitcoin or technology things at all, mostly just funny pictures of animals.
07:00:18Taek42:I'm not sure that it's a symptom of upvotes and downvotes so much as Reddit being a general audience
07:01:04maaku:people are stupid
07:01:09gmaxwell:Taek42: nah, normally the general audience doesn't have their hands firmly placed on the steering wheel.
07:01:20maaku:it boggles my mind that when you have a crowd of them, wisdom is supposed to emerge
07:01:42gmaxwell:lol
07:01:55Taek42:democracy!
07:02:00gmaxwell:to be fair even the crappy "Wisdom of the crowds" book said that wasn't actually so.
07:04:38Taek42: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:39maaku:never actually read it. was the thesis that you need proper incentives?
07:07:46michagogo|cloud:Taek42: a monetary cost, you mean?
07:08:08Taek42:well, some sort of currency that could be swapped for real currency
07:08:11maaku:citizen cost a la starship troopers?
07:08:11Taek42:dogecoin, perhaps
07:08:18gmaxwell:voting already has a substantial cost in terms of time/trouble.
07:08:33Taek42:on reddit, the first vote is pretty costly
07:08:42Taek42:seeing as you have to log in, and maybe create an account
07:08:46Taek42:but the rest are painless
07:09:39michagogo|cloud:Or creddits
07:09:48Taek42: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:23Taek42:The problem being that the average person could have as much authority/power as the expert
07:10:27michagogo|cloud:I seem to recall there was some site like that
07:10:39michagogo|cloud:Where you spend reputation points to vote
07:11:22phantomcircuit:gmaxwell, is there still a penalty for p2pool?
07:11:32phantomcircuit:iirc there used to be a substantial orphan rate
07:11:57phantomcircuit:also @anybodyelse
07:12:20gmaxwell:phantomcircuit: it has the lowest orphan rate of any pool as far as I can tell.
07:12:38phantomcircuit:what's it's current orphan rate?
07:13:02gmaxwell:there has been two this year.
07:14:01gmaxwell:0.12% in my data. (eligius, by comparison, has been ~1%)
07:14:25phantomcircuit:that's interesting
07:14:52gmaxwell: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:38Taek42:theoretical problem: suppose every miner picks the maximum-payout pool. Wouldn't every miner end up picking the same pool?
07:15:43gmaxwell: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:48phantomcircuit:any idea why the orphan rate would be lower than eligius?
07:16:11gmaxwell:phantomcircuit: because it has an enormous network connectivity advantage.
07:16:49phantomcircuit:it might also have to do with what kind of hardware is connected to p2pool
07:16:54phantomcircuit:some of them have uh
07:17:00phantomcircuit:interesting ideas of what stale means
07:17:04gmaxwell:p2pool blocks end up being concurrently announced by a dozen peers in the first 30ms after finding a block... hundreds within 400ms.
07:18:21gmaxwell:phantomcircuit: maybe, p2pool direct miners to return "stale" shares.
07:18:42gmaxwell:in any case, if some miner is overly agressive in what its discarding, its not getting paid for that portion of its work.
08:18:52fagmuffinz:fagmuffinz has left #bitcoin-wizards
08:51:51gmaxwell:I think bitcoin is becoming the new DHT. :(
08:52:49wumpus:yo, slap a blockchain on it
08:53:32roidster:COULUD STAND FOR HEMROID
08:53:57roidster:could* pardon the caps
08:55:10BlueMatt:gmaxwell: I think we've known that was gonna happen for a while
08:55:33BlueMatt:/has been happening for a while
08:55:43wumpus: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:47wumpus:and you get nonsensical ideas, like in the internet boom.... just like your old pet shop, but online!
09:06:48gmaxwell:a miracle happened on reddit today
09:07:02gmaxwell:someone mentioned my name in a ppc thread, which is what brought my attention to those claims on that website.
09:07:09gmaxwell:I refuted them with citations to source code.
09:07:29warren:URL?
09:07:34warren:(reddit thread)
09:08:02gmaxwell:http://www.reddit.com/r/Bitcoin/comments/1uoq6e/what_do_you_guys_think_of_proof_of_stake_mining/cek7vbc
09:08:30gmaxwell:and someone argued with me... and then actually accepted my counter arguments. and I'm not being voted down!
09:14:23sipa:i've been explaining the problem with PoS a few times now at the zurich bitcoin meetups
09:14:35sipa:people do seem to understand it
09:18:11gmaxwell:it makes me sad, I really wish it worked.
09:19:37justanotheruser:What are the potential problems of associating namecoin registration price with transaction fee sum?
09:19:53gmaxwell:what is a "transaction fee sum"?
09:20:46gmaxwell: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:58justanotheruser: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:36justanotheruser:gmaxwell: yeah, that is a problem
09:22:18justanotheruser:There's not really a way to evaluate how many namecoin users there are...
09:22:39gmaxwell:you can look at the registrations however.
09:23:00gmaxwell:(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:02justanotheruser:gmaxwell: but you can't set the registration rate based on the number of registrations
09:23:31gmaxwell:yea oh sorry I thought you were back to suggesting that namecoin isn't currently a failure. :P
09:23:51justanotheruser:If there were only 500 domains offered per day, people would have to compete in price for registering.
09:24:17justanotheruser:Unfortunately namecoin isn't going to ever be stable, so you can't say "$10 for a registration"
09:24:27gmaxwell: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:18justanotheruser: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:25gmaxwell: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:44justanotheruser:but I guess for every domain they buy, they lose one domain sale that day
09:25:45gmaxwell:justanotheruser: unless the system just limits it via a protocol rule.
09:26:26justanotheruser:gmaxwell: is there a way to have a decentralized 2 way peg?
09:26:58gmaxwell:I guess you missed those discussions. I believe it's possible, there are some security limitations.
09:27:30justanotheruser: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:11gmaxwell: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:20gmaxwell:(slowly meaning like 100 blocks)
09:28:50justanotheruser:gmaxwell: would this allow for offchain transactions if the bitcoin chain was too big making transaction fees high?
09:29:20justanotheruser:well not "if", but for that reason would it be useful
09:29:31gmaxwell: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:17gmaxwell: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:29gmaxwell:(turing complete script, whoppie!)
09:30:38justanotheruser:gmaxwell: is the peg discussion in #bitcoin-dev logs?
09:30:43gmaxwell:it's in the logs here.
09:30:58justanotheruser:any public logs for this channel?
09:31:07gmaxwell:andytoshi-away: makes logs, dunno where they are.
09:31:14michagogo|cloud:(The logs should really be mentioned in the topic...)
09:32:03justanotheruser:I'll make a note to ask him for the logs
09:32:07gmaxwell: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:55justanotheruser:gmaxwell: so would this pretty much remove the need for Open Transactions?
09:33:42gmaxwell: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:21gmaxwell: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:38justanotheruser:gmaxwell: isn't the only way for that SPV proof to exist by embedding all those block headers in the bitcoin blockchain?
09:35:35justanotheruser: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:36gmaxwell: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:59gmaxwell:But the coinswaps alone cant get you a 2-way peg because they can't provide long term liquidity.
09:37:13gmaxwell: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:22gmaxwell:(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:05justanotheruser:gmaxwell: Seem expensive still. The blockchain could end up storing a dozen other blockchain headers in it
09:39:33gmaxwell: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:06gmaxwell: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:41justanotheruser: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:44gmaxwell:justanotheruser: and each of those dozens of other chains could have an infinity of transactions, seems like a good tradeoff to me.
09:41:08justanotheruser:gmaxwell: do you think that's more viable than sharding the blockchain?
09:41:47gmaxwell: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:30gmaxwell: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:02justanotheruser:hmm
09:44:48justanotheruser:gmaxwell: do you have some cryptography PhD or something?
09:45:14gmaxwell: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:31gmaxwell:justanotheruser: No. I'm just some guy who enjoys math.
09:45:41justanotheruser:I see
09:45:57justanotheruser:This idea seems to have a lot of potential
09:46:44justanotheruser:Would this not require disabled opcodes to determine whether the transactions belonged to someone else on this other chain?
09:47:05justanotheruser:I guess you said it was a softfork, so my real question is why wouldn't it
09:47:21gmaxwell: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:03gmaxwell: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:41gmaxwell:old nodes would just see a no-op transaction and permit it.
09:49:00gmaxwell: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:47Taek42:gmaxwell, what's your opinion of XRP?
09:50:39gmaxwell: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:54Taek42:thanks
09:53:08TD_:TD_ is now known as TD
09:53:51justanotheruser:Any known weaknesses to the pegging system?
09:53:55gmaxwell:ohh "Crony Consensus" I'll have to remember that.
09:54:51gmaxwell:justanotheruser: at least as I was describing above it only has SPV-like security. meaning that if you can outpace the second chain you can steal all the bitcoins assigned to it and leave it fractional reserve.
09:55:08gmaxwell:(which would be part of the reason it would need to be fairly slow)
09:55:21gmaxwell:(I mean the teleport operation would need to be slow)
09:56:15BlueMatt:gmaxwell: implementation detail: do you require the side-chain be merged-mined?
09:56:31justanotheruser:BlueMatt: seems like that would be ideal
09:56:39TD:good evening guys
09:56:50gmaxwell:BlueMatt: I don't think bitcoin should require that, though it would probably be pretty darn prudent.
09:57:02BlueMatt:hi TD
09:57:21gmaxwell:BlueMatt: at least my thought is really "just add enough so that bitcoin can verify a sutiable proof, and then you can build anything out of that which you can make fit"
09:57:24gmaxwell:HI
09:57:32sipa:TD: timezone deficiency?
09:57:58TD:evening for them. morning for us :)
09:58:08gmaxwell:BlueMatt: so while it might be _wise_ to merge mine it, and perhaps there are some optional strenghtening things that could be done, I don't think it would make sense to require it.
09:58:08sipa:ah, right
09:58:19BlueMatt:gmaxwell: makes sense
09:58:33TD:lol
09:58:34TD:"Since we're generating the points randomly, I'm going to ignore the first condition because it happens far less frequently than malfunctions in the CPU instructions that I might use to detect it."
09:58:43TD:i think i'm going to remember this excuse for ignoring edge cases, for the future :)
09:58:52sipa:link?
09:58:57TD:https://www.imperialviolet.org/
09:59:03TD:agl talking about implementing elligator for curve25519
09:59:23gmaxwell:e.g. ideally the pubkey could specify the proof geometry required with enough flexibility that you could merge in something rather throughly unlike bitcoin.
09:59:33justanotheruser:sipa: seem into producing acronyms...
10:00:21gmaxwell:BlueMatt: though annoyingly some of the already existing altcoins can't have compact spv-like proofs. :(
10:00:48justanotheruser:gmaxwell: scryptcoins?
10:00:50TD:how did they manage that?
10:01:22TD:justanotheruser: no, scrypt based coins still use sha256 for the merkle tree
10:01:36BlueMatt:gmaxwell: meh, I dont care about current altcoins that do dumb things, I want to enable actual innovation, not knob twiddling
10:01:49TD:says the guy behind coingen.io :)
10:01:53justanotheruser:TD: but how do you verify the PoW without including scrypt into bitcoin or implementing scrypt in a bitcoin script?
10:02:11BlueMatt:TD: yes, hopefully it will saturate the market with knob twiddling and people will get bored of it
10:02:31gmaxwell:TD: well PPC's proof of stake stuff appears to need a (mostly) unpruned blockchain history to validate. And a primecoin headers look like they're a couple kilobytes and need primality testing?!
10:03:35TD:gmaxwell: surely even in proof of stake, transactions are in blocks and arranged into a merkle tree though?
10:03:54TD:or you mean you can't just download headers at all
10:03:56gmaxwell:TD: you need to prove it hasn't been spent.
10:04:09gmaxwell:well they have no getheaders p2p messages either, but thats an aside. :P
10:05:22gmaxwell:basically at least as PPC is now, I don't think you can extract a compact proof that a header is valid. maybe you can get close enough by extracting the transactions and assuming they weren't subsiquently spent, but I dunno, since there is no POW on those blocks attacking is cheap. I honestly haven't thought about it much.
10:06:32gmaxwell:at a minimum it's complicated.
10:07:36sipa:maybe we should write a "if you're going to create an altcoin, think about:" document
10:08:10BlueMatt:sipa: yea, think about: "2-way pegged value"
10:08:34sipa:listing some of the easy-if-we-knew-it-at-the-start ideas like p2sh only, or simplifying script, or having amounts in the signature hash
10:08:50sipa:and concerns like compact proofs
10:09:08sipa:oh and maybe explain the reason for block times being slow
10:10:53gmaxwell:sipa: dunno that it would help, couldn't hurt. I say I don't know because of how they've responded when encountering problems.
10:11:48BlueMatt:for current-gen alts, its sure to make no difference
10:12:35gmaxwell:(e.g. the general response has been to do something even dumber)
10:12:43BlueMatt:for people making real alts (maybe, though I'm very unconfident) coingen will help
10:14:15gmaxwell:e.g. feathercoin had instability and attacks in due to some of their parameter choices, their response was to pay the ppcoin person to license "advanced checkpointing" from ppc (developer broadcast "checkpoints").
10:15:25Taek42:are people licensing cryptocurrency ideas now?
10:16:21_ingsoc_:BlueMatt: Lol.
10:16:29_ingsoc_:_ingsoc_ is now known as _ingsoc
10:16:46gmaxwell:thats the only incident of it that I'm aware of.
10:16:55TD:i never liked p2sh only as an idea.
10:16:58gmaxwell:unless you count coingen.io
10:17:38gmaxwell:It's certantly something I'd do when starting from scratch. Opinions may differ.
10:17:38TD:ethereum might evolve into an interesting alt
10:17:56TD:gmaxwell: well, it'd rule out things like OP_RETURN tagged outputs and the like, which people have found uses for.
10:18:15gmaxwell:TD: yea, the ethereum warez site agent is totally going to be popular. :P
10:18:58TD:is that actually on their website?
10:19:18gmaxwell:TD: no reason that it would preclude having a no index flag (or really just a seperate field in transactions for aux data).
10:19:34gmaxwell:TD: no, I was kidding, but it seemed to follow naturally from the description of it I read. :P
10:19:46TD:you saw payfile, right? :)
10:19:46sipa:what is ethereum?
10:19:47gmaxwell:TD: you couldn't tell for sure though…
10:20:13TD:gmaxwell: that's true. you could extend the tx format at the same time.
10:20:25gmaxwell:sipa: vitalik altcoin based on turing complete script.
10:20:35gmaxwell:doesn't exist yet as far as I know.
10:20:54sipa:ah
10:20:57gmaxwell:a bunch of the design decisions wouldn't be ones I would have made but. ::shrugs::
10:21:31gmaxwell:sipa: in particular it's supposted to support being able to upload code into the network which the network runs triggered by events e.g. independantly of transactions, which can do things like create transactions.
10:21:47sipa:ewww
10:21:56TD:hah
10:21:59gmaxwell:and a handwave at fees to pay for it, without any consideration of the incentives around that.
10:22:06gmaxwell:Yea, my response too. But at least its different.
10:22:20TD:right. hence me thinking it's the most interesting alt, even if i also think it's unlikely to work
10:22:23TD:but we'll see
10:22:24gmaxwell:be nice or I'll suggest they name one of their currency units after you.
10:22:46nsh:nobody talks about Dr Frankenstein advanced the field of medicine
10:22:48nsh:+how
10:23:30gmaxwell:http://demotivators.despair.com/demotivational/mistakesdemotivator.jpg
10:23:39TD:the guardian did a nice article on alt coins. i banged the drum about how they demonstrate the fundamentally democratic nature of crytocurrencies
10:24:03TD:so coingen and other joke alts are not entirely useless. they educate people about the tech and more importantly, make BlueMatt a lot of money
10:24:14nsh:* nsh smiles
10:24:32gmaxwell:Sadly alt's don't work too well as education on what not to do, just like invent your own blockcipher usually doesn't— because they usually don't reach the point where they justify a serious attack, but oh well.
10:24:57TD:well, that's education of developers. i'm thinking of education of users. showing how bitcoin developers are not simply the new central bankers
10:25:12TD:http://www.theguardian.com/technology/2014/jan/07/bitcoin-me-how-to-make-your-own-digital-currency
10:25:32gmaxwell:TD: hey, I strongly promoted that idea. I'm all for it. I also suggested it to people who wanted to "fight" altcoins as the fair and ethical way to do so... "we think these things are pointless, well it's not fair to stop them, but lets reduce the friction that makes making a pointless altcoin profitable."
10:26:19gmaxwell:TD: did you see the fallout from the launch of the 'conya' coin? (or however its spelled?)
10:26:38gmaxwell:coinye
10:27:35warren:gmaxwell: I'm guessing ICANN procedure to get the domain taken away will be tried next
10:27:49gmaxwell:yea probably.
10:27:55gmaxwell:did you see they were having zillion block reorgs?
10:28:08sipa:who?
10:29:16TD:i saw that kanye's lawyer was trademark-whacking them. lol.
10:29:28gmaxwell:coinye coin. another purpusfully dumb coin, but it started out with about 1/1000th of the initial difficulty it should have had.
10:29:35TD:and the anonymous authors response was basically to wave two fingers at them and say they'll bump up the release date
10:29:44gmaxwell:(they basically released a password to unlock the software at some time with enormous hype)
10:30:17sipa:eh?
10:31:10warren:if they were anonymous devs, with people unable to examine the software before the launch of mining, they could have included a trojan to steal
10:31:22warren:lots of idiots would rush in
10:31:28gmaxwell:and now pools that lost the reorg wars have shuttered and people are angry that they're not getting paid.
10:31:34warren:and they would cash out in an unexpected way
10:31:50Taek42:warren sounds like something worth trying
10:32:02BlueMatt:warren: I'm honestly surprised we haven't seen more of that
10:32:08gmaxwell:it was only released a couple hours ago and has like 5000 blocks.
10:32:24gmaxwell:BlueMatt: esp now that some of these exchanges will happly add brand new coins.
10:35:12gmaxwell:is it just me or is bc.i switching to USD every time other people follow a link to it?
10:36:46sipa:experienced that as well
10:40:38michagogo|cloud:gmaxwell: not just you
10:54:09warren:BlueMatt: to avoid that someone could release all the code except for the genesis
10:54:50gmaxwell:I believe thats how ltc was launched.
10:55:25gmaxwell:https://bitcointalk.org/index.php?topic=404888.0 < fwiw, I posted asking about bc.i's switching
11:06:47TD:sigh. we need to beat some rationality into the fees market
11:19:44warren:TD: the way we rolled out 20x lower fees might be feasible (albeit very dumb)
12:54:52adam3us:TD, gmaxwell: i admit some fault with coingen.io also (I was stting opposite mappum when he registered the domain), not a new idea apparently, but I yacked about how cool it would be a bunch with BlueMatt and put him up to it. maybe it'll back fire in interesting ways, but the intent is humorous clearly and genuine: to deflate param tweaks
12:56:15adam3us:TD, gmaxwell: and its actually serious. it seems to me that alts are stifling actual innovation. if u think about it inmany ways bitcoin innovation has virtually stalled since 2009. thats why i want to kill param-tweaks, and think pegged side-chains are the bet new idea since 2009 in bitcoin period.
13:02:51adam3us:about ethereum i talked to vitalik about it, not sure i mentioned this part or not, that while fees is a solution to the halting problem in a Turing Complete complete script language; however the history of java byte code interpreter sandbox escapes could give it a massive, repeating, binary failure, where each sandbox escape results in theft of all coins (and maybe bitcoins)
13:15:26adam3us:aka there is a reason bitcoin script is functional, no iterators/recursion, and most of even the stylized/simplified/cut-down script language is itself disabled. ripple dont seem to appreciate this risk and their draft script language looks turing complete. in open transactions, chris showed me he has pluggable script language interpreter hooks and jscript, lua etc but thats just code because he likes generalized clean code.
13:54:37andytoshi-away:justanotheruser: logs are at http://download.wpsoftware.net/bitcoin/wizards/ ... if you msg andytoshi-logbot with 'help' i think it'll tell you
13:55:06andytoshi-away:sipa: re 'someone should write a "what to think about before making an alt" document', i'm planning to write something like that this weekend
13:58:22TD:adam3us: you wouldn't try to steal all coins simultaneously, that'd be dumb
13:59:24TD:adam3us: it'd just be treated as an outage
13:59:47TD:you'd want to steal 1% or something like that ...
14:00:26adam3us:TD: if these coins are pegged bitcoins, you'd want to steal as many as possible. it depends on the reaction mode to stemming the loss. if its like the many exchange/processor thefts like say sheep market place (the largest?) because of the irrevocability maybe you may not even care if u empty the alt chain in one go on the way
14:01:21adam3us:TD: what re people going to do? issue and deploy an emergency bitcoin patch to reject this specific side chains re-conversion? that sounds centralized and fed policy like
14:01:43TD:we were talking about ethereum i thought?
14:01:51adam3us:TD: but you may well be right for detail reasons that the optimal exfiltration
14:02:11adam3us:TD: oh yeah sorry :D
14:03:14adam3us:TD: i guess that depends on the market cap and the liquidity and intent of the sabateur. why are they killing the alt. to make money or because they want to do a 'scorched earth' to borrow a petertodd'ism to prove a point
14:04:00adam3us:TD: lot of people might be quite upset and litigious about it if the market cap was like non-trivial at the time. dangerous thing to do possibly even via Tor.
14:04:30adam3us:(sorry i was still in pegged side-chain mode so misinterpreted your observation)
14:04:34TD:anyway, most of the java sandbox escapes especially these days are not issues with the bytecode verifier but rather with the huge libraries or native code that they call out to
14:04:51TD:presumably ethereum would not have anything in the way of libraries or big surface area APIs
14:07:05adam3us:TD: interesting point, yes i never went looking at the root cause of the repeated sandbox failures, but if thts accurate the risk might be a bit lower. but anyway i guess you can say its a brittle failure mode and more risky than bitcoin as a value store as a result. not only could a big bug collapse value like, but some worse things i think, like taking control simultaneously of all online nodes.
14:07:32TD:sure
14:07:38TD:code execution is always tricky
14:08:04TD:ironically, i suspect the JVM may end up being one of the safest sandboxes around. given how massively and repeatedly it's been attacked by hardened hackers compared to most sandboxes
14:08:14adam3us:(could happen to btc also, but higher risk as their code is basically an abstract interpreted asm with memory and iteration, pointers. very flexible. more like executing x86 interpreter)
14:08:24TD:if they keep plugging away at it for enough time, and if you restrict the API surface area, it could end up being kind of robust
14:10:14adam3us:TD: yes. but it seems in some ways that btc is surfacing whole new levels of code assurance. if there's a $1bil reward sitting on the table for entire system value exfiltration, more resources nd resourceful people get in, or lose their ethical behavior $ limit filter, seemingly empirically many otherwise trustworthy people have such limits)
14:11:14adam3us:just to say maybe its more interesting to sandbox escape ethereum (if btc was using that model right now) than sandbox vm escapes. it only takes one.
14:11:16TD:yeah. it makes me wonder if one day it'll simply become impossible to make any changes to the code at all because the legal/financial risk of making a mistake is so high
14:11:25TD:either that or every bitcoin developer will be anonymous and work from behind Tor
14:11:28adam3us:TD: yes i think so
14:11:38TD:neither outcome seems desirable
14:11:42TD:still i guess banks manage, sorta, somehow
14:12:53adam3us:TD: the Tor thing is interesting. i think people who get into exchanges and btc biz dont realize the risk they are putting themselves, their family etc at. if they get enough value inside a server, they have become like a bank. at the high end what do we need like thebunker.net or fortress with servers in it. seems like banks or physcal security need to be part of the picture with multsig eventually
14:14:14adam3us:TD: yes, that seems part of the genuine value of banks, they have structured governance (cross checks) physical security, personnel vetting, alarms, perhaps monitored security at managers houses. they had to think about it all and manage it. that is actual value.
14:14:15TD:probably. one reason why i'd never run an exchange or bitbank. however, exchanges are needed, so .... someone has to take that risk. w.r.t the rest of it, well, it's MIT licensed and disclaims all responsibility for everything
14:14:28TD:though i imagine some people will eventually ignore that and try their luck in courts anyway
14:14:51adam3us:TD: what u mean sue for losses due to code bugs?
14:15:09TD:well, or for any other kind of excuse. or patent lawsuits or whatever.
14:15:17TD:i mean as the amount of value goes up, anything could happen
14:16:38adam3us:TD: was vaguely wondering if one could retain unseizability property while protecting your self or your exchange or your processor (some server or equipment or paper under the service operators and employees control) from physical duress, by multisig the whole thing with a physical security provider of one part of the multisig. the RA aspect of the bank multisig is typically weak also. tho they do a lot of risk management
14:17:54WOODMAN:morning warriors
14:17:59TD:they're also insured
14:18:15adam3us:TD: like cheque sigs are not verified under £30k i hear. but if u wire £20k you can do that with some lame, malware attackable security. exactly insurance and risk management.
14:18:25WOODMAN:anybody been around on this technology since early days, i have a decent question if its ok?
14:18:37WOODMAN:brb
14:19:04andytoshi-away:WOODMAN: usually, try #bitcoin-dev first
14:19:23adam3us:TD: but i think what backs it all up is the revocability, usually when things go wrong they can undo the tx, they have ID, so they can recover even withdrawn funds, and insurance covers the rest
14:20:28adam3us:TD: btc lacks that. and if we introduce it (certainly can do revocable, easy using irrevocable + multisig escrow) then the disput resolution costs come back in and btc tx costs same as credit card. so we cant win. the remaining new avenue is to some smart contract magic
14:20:29WOODMAN:what is this site?
14:20:29TD:yep. it might turn out in the long run that irreversible transactions are simply something humanity can't handle, when the amounts of value being handled get too high
14:20:44WOODMAN:https://bitcointalk.org/index.php?topic=11606.0
14:20:46TD:(too hard to build secure software systems)
14:20:56adam3us:TD: was ever thus. ecash (irrevocable fast settlement) and slow cash just dont interface together well
14:21:02WOODMAN:i believe i bought bitcoin in 09
14:21:35adam3us:TD: yes. maybe that is an answer. large payments typically can tolerate being slow, and the parties having recourse enough to tolerate the revocability.
14:21:37WOODMAN:i never set up a client....bought from someone who put it on a USB and sent it to me....me never wanting to store on computer cause of hacking and never planned on selling, as there was no market at that time
14:21:54andytoshi-away:WOODMAN: #bitcoin please
14:21:56WOODMAN:i found this link and it discusses that you can put bitcoins on a USB
14:22:01WOODMAN:ah come on andy
14:22:05andytoshi-away:though i did enjoy the second post saying 'screw that, just use mybitcoin' :)
14:22:06WOODMAN:be a sport
14:22:11sipa:WOODMAN: #bitcoin, now
14:22:24WOODMAN:ahora!
14:22:38WOODMAN:im banned from there
14:22:48sipa:(you're very welcome to follow the discussion here, or contribute, but basic questions are completely off topic)
14:22:54TD:or post to bitcointalk
14:23:10WOODMAN:too many indians , not enough chiefs
14:23:36WOODMAN:this could be problem with open source
14:24:19WOODMAN:got another bitcoin IRC where they respect free speech?
14:24:30WOODMAN:or is this all funded by soros?
14:25:00adam3us:TD: "TD: (too hard to build secure software systems)" i worry about this. baseband hacking smart phones, targetted sophisticated malware, code base targetted tampering, human error over time.
14:25:05sipa:/ignore WOODMAN
14:25:29TD:adam3us: best "solution" such that it is, is to avoid large pileups of value in one place
14:25:48adam3us:TD: it doesnt seem like security has even warmed up yet. even the trezor & armory wallet are not safe from address substitution and payment protocol still leaves a gap in the merchant server
14:25:49TD:however, wealth inequality will not go away anytime soon. so .... not sure how far that takes you
14:26:45adam3us:TD: i think u could operate quite a bit of bitcoin ecosystem with airgap security protecting funds and airgap level of assurance of ownership of addresses
14:26:58adam3us:TD: even an exchange.
14:28:31adam3us:TD: (using color coin or better labelled /tagged coins on a pegged side chain and an offline issuer key issuing USD against a client funds issuer account. with a high reputation issuer)
14:31:32adam3us:TD: i think the airgap could save it as the exchange then has no btc funds or usdcoin funds at stake. all cash funds are held in offline airgapped wallets at all times. physical security for a merchant is like any supermarket... an armored truck deals with emptying. but even better than can sweep electronically to a vault with armed guards at company HQ.
14:31:40TD:* TD -> away
14:35:43adam3us:hmm so maybe a solution is a different property coins circulating though. optionally intentionally (time-limited) revocable coins for large tx by companies to derisk their storage from physical assault. and you can convert from revocable to irrevocable simply by waiting for the escrow smart-contract clause to expire
14:37:39adam3us:and similarly irrevocable become revocable by adding the escrow agent smart-contract. actually for storage the revocability needs to be permanent. the way you remove it is to spend it to an irrevocable address with the cooperation of the escrow agent.
14:46:48Graet:Graet is now known as Guest5939
15:40:39adam3us:TD: btw something else on the topic of software security and not daring to make changes to btc anymore, it seems to me there maybe scope to simplify high value storage & tx and perhaps layer the assurance. eg full node only model requires less validation, less code, less assumptions, and high value can afford full node reliance. not sure how to layer that upwards to SPV separately, but it seems like a desirable property
15:41:37CodeShark:adam3us: what about high values formed by aggregating lots of small ones?
15:41:39adam3us:TD: also apropos of the new discovery of a 23-year old remote root in all intervening? versions of X11. how would that look for btc as a world currency.
15:42:21adam3us:CodeShark: doesnt change the picture, we're talking systemic risk of value bug
15:47:10michagogo|cloud:;;later tell shesek Looks like the magic bytes appear 250,010 times in the first 250,000 blocks on disk (bootstrap.dat)
15:47:10gribble:The operation succeeded.
15:54:11sipa:michagogo|cloud: they could be occurring a few times just randomly as part of other data
15:54:20sipa:though 10 times is a lot
15:54:21michagogo|cloud:sipa: Yeah, I know that
15:54:43michagogo|cloud:(we had this discussion earlier (today or last night))
15:55:32jgarzik:adam3us, RE X11... url?
16:36:54adam3us:jgarzik: http://lists.x.org/archives/xorg-announce/2014-January/002389.html
16:38:26adam3us:jgarzik: "checked in on 1991/05/10, and is thus believed to be present in every X11 release starting with X11R5 up to the current libXfont 1.4.6"
16:38:47not-andytoshi:not-andytoshi is now known as andytoshi_
16:39:03andytoshi_:adam3us: that bug is older than i am!
16:39:13sipa:andytoshi_: wow :o
16:39:25sipa:* sipa suddenly feels old
16:39:37andytoshi_:well, only by 3 months :)
16:39:52sipa:well, I was in my first year at school in 1991...
16:42:21adam3us:* adam3us *is* old :) was starting CS PhD degree then
16:42:49sipa:haha
16:42:52sipa:* sipa feels young
17:00:34WOODMAN:sipa take it somewhere else
17:00:36WOODMAN:sipa now
17:00:45WOODMAN:take it to lethargic IRC chat
17:00:47WOODMAN:now
17:00:54WOODMAN:go
17:00:57WOODMAN:run
17:01:13helo::/
17:07:00WOODMAN:you kids are funny
17:07:05WOODMAN:B)
17:39:46justanotheruser:andytoshi_
17:40:27justanotheruser:do you have logs from the 2 way pegging discussion?
17:41:13nsh:justanotheruser, it's still in my buffer. can pastebin it
17:41:32nsh:(was meaning to give it another read later anyway)
17:43:42justanotheruser:nsh: please do
17:43:46nsh:moment
17:44:10justanotheruser:nsh: you mean the discussing I wasn't involved in right?
17:44:43nsh:oh, i meant from earlier today. i missed the discussion when gmaxwell mooted it
17:44:53andytoshi_:justanotheruser: one sec, i'm pretty sure i do..
17:45:00nsh:* nsh defers to andytoshi
17:45:34nsh:(here's today, in any case (unlisted on pastebin): http://pastebin.com/Aefaxfew )
17:47:30justanotheruser:thanks nsh
17:48:41nsh:np
17:54:52andytoshi_:justanotheruser: sorry, i can't find it on my server's logs, will check my laptop's logs when i get home
17:55:07andytoshi_:there are memories in my brain of it, so i'm pretty sure i was present
17:55:18justanotheruser:andytoshi_: ok please PM me them, thank
17:55:20justanotheruser:s
18:53:26gmaxwell:andytoshi_: I made a kind of boring comment about the vntinyram paper: https://groups.google.com/forum/#!topic/scipr-discuss/1psbALDMkAI (mostly I just wanted an excuse to post to the list and see if anyone was reading it, since there were no posts ever)
19:46:01nsh:gmaxwell, is that what you were referring to in this: "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" from earlier?
19:49:26gmaxwell:nsh: no.
19:49:32nsh:k
20:08:45jgarzik:adam3us, sounds like the root hole is in BDF font installation
20:09:01jgarzik:adam3us, thankfully, not really an actively used or triggered area
20:10:01adam3us:jgarzik: yes. i was well is the coe in the bdf or the code is in a malicious font no? the latter is bad as someone can send u a font file. did u know fedora 18 dvd wont install without network and downloads amongst other things fonts? (they are crazy)
20:10:45adam3us:jgarzik: or is bdf font an optional font system? so no risk if u havent installed that component?
20:11:02jgarzik:adam3us, well, (1) F18 installs fine without network and (2) any download exists inside a GPG-signed universe
20:12:36adam3us:jgarzik: hmm it depends which image u download, i tried 3 of them until i found one that installs without network cable. their new installer is a bit of a mess, but i was pretty determined to get an all offline install and trid 7 isos from ubunu an fedora over pretty much 2 ays
20:12:43spinza_:spinza_ is now known as spinza
20:13:41jgarzik:adam3us, at which step did you get stuck? I might have had to do some magic to get my F18 going in its network-free VM
20:14:02jgarzik:adam3us, I keep several network-free VMs as virtual condoms for various things
20:16:32adam3us:jgarzik: about the gpg-sig. the problem is 2-fold: one the WoT is sparse, secondly it doesnt define a merkle tree, so the content can be tailored to u and there is no rpm sig equivalent of certificate transparency
20:18:19adam3us:jgarzik: i finally gave up as i recall an used ethernet briefly i was very annoyed by that point, 2 days burnt on fedora & ubuntu i was astounded that it would fail for network on a DVD iso. 4GB and they want to fetch a font on the network or the install aborts. actually it was probably fc 19. i even tried ubuntu server install.
20:18:34jgarzik:adam3us, well each package comes from signed metadata package repo summary
20:18:44jgarzik:adam3us, I agree this does not solve 'tailored to u' problem
20:18:50adam3us:jgarzik: yes my point is say NSA has a copy ... ok right u get it
20:19:29adam3us:jgarzik: there is a solution.. merkle tree of snapshot of packages at iso release time, then your entire install is hardwired to the merkle root.
20:19:56jgarzik:adam3us, nobody wants packages of an era circa iso release time ;p
20:20:35jgarzik:adam3us, familiar problem as with routers: the moment you open the box and turn on the computer, it is out of date and missing security and other critical bug fixes
20:21:54adam3us:jgarzik: actually i would happily take an out of the box for this app, which is admittedly completely atypical (i was testing armory prebuilt stuff and source stuff.) that the DVD wouldnt install therefore was just the opposite.
20:24:42helo:hmmm... ubuntu without network has worked fine for me (via iso-on-usb)
20:27:15adam3us:jgarzik: also i guess we're going to need sooner or later the SSL / cert transparency, for rpm signatures, or something. its pretty much spelled out in like schneier and applebaum research in teh docs and articles from that that NSA has well placed TCP hi-jack infrastructure with selective payload delivery. u could imagine they might hve hacked some important signing keys via physical intrusion, black bag, NSL etc.
20:29:25adam3us:helo: i am not in a hurry to repeat that experiment it was the least fun i've had with a computer in quite a while. this was ubuntu 10 and ubuntu 12 (whatever armory claimed to be prebuilt for, or latest stable for source) and fedora 18. tried lots of isos. i dont think i was dreaming. been using linux since slackware 0.9 so i am not unusually fat fingered about linux installs
20:30:06helo:yeah, sounds pretty terrible
20:31:03gmaxwell:the fedora stuff kinda shuffles users torwards the crappy live image based installers, which I think do have to be online.
20:31:11_ingsoc:_ingsoc has left #bitcoin-wizards
20:50:06michagogo|cloud:adam3us: 10 and 12?
20:50:09michagogo|cloud:Which ones?
20:50:29michagogo|cloud:(.04 or .10?)
20:51:22adam3us:michagogo|cloud: it was a month ago, i tried 10, 12 as main advertised iso on ubuntu.co and i think 10 server at suggestion of a hacker friend of mine that server maybe less chatty
20:51:29adam3us:.04
21:50:39andytoshi-away:gmaxwell: cool, glad to see (a) that the list is active and (b) we're not crazy to think we can be throwing hash circuits everywhere
21:50:41andytoshi-away:andytoshi-away is now known as andytoshi
21:51:10andytoshi:i have another concern, which i haven't mentioned since i haven't read the whole paper, about verifying input..
21:51:35andytoshi:presumably to make a snark-based blockchain we would want VERIFY (old chain state, new chain state, transactions)
21:51:43gmaxwell:someone needs to find a bored grad student to go generate circuits for sha256 and all the sha3 finalists and see which results in the fastest proofs.
21:51:58andytoshi:and we'd want the old and new chainstate to be public, but the transactions to be zero knowledge
21:52:18andytoshi:the impression i get from the paper is that if we want inputs to be public and provably there, we'd need them to appear in the preprocessing stage
21:52:21andytoshi:is this right?
21:54:15gmaxwell:andytoshi: no, the preprocessing stage just takes in the description of vntinyram itself, the time limit bound, and the _number_ of public inputs.
21:54:41andytoshi:are the public inputs what they call 'auxilliary inputs'?
21:55:10gmaxwell:no, public inputs are "program inputs", while "auxilliary inputs" are the ZK inputs.
21:55:42andytoshi:ok, thanks, great
21:55:48gmaxwell:(also non-determinsim used to simplify the tinyram circuit, e.g. like magical answers that tinyram divide by only having a circuit to check the answer)
21:56:00andytoshi:yeah, i noticed that, that was really clever
21:57:49gmaxwell:andytoshi: also, in your description above there is an extra thing that needs to be provided.. full nodes would also demand a set of updates to change from the old state to the new state.
21:58:15andytoshi:the proof would not be enough for them?
21:58:17gmaxwell:E.g. the transactions are ZK but you do actually need to know the final state (not intermediate states) in order to make the next proof yourself.
21:58:40andytoshi:right, that's what i mean by 'new chain state', they can just use that as 'old chain state' in their next proof
21:58:59gmaxwell:oh okay, I read what you were saying as a commitment to the state.
22:00:33gmaxwell:A non-miner in that model doesn't actually need to pay attention to the state much of the time... so commitments are good enough.. then they could just get fragments of the state from filtering nodes to prove they were paid.
22:01:28andytoshi:right
22:02:32andytoshi:and full/filtering nodes would have to figure out some way to efficiently store the series of chainstates
22:03:10andytoshi:perhaps snark-proving chainstate diffs would be more efficient, i dunno, these are just details at this point :)
22:03:11gmaxwell:its useful to commit to the diff as well, since then you can get it from someplace else.
22:03:52andytoshi:oh, good point, doing both gives the best of both worlds
22:05:50andytoshi:full nodes would use the diffs, non-full user nodes would use the full state to verify what the full nodes are telling them
22:08:54gmaxwell:if you want to be really snazzy, you have a hiearachy of backpointers to old blocks, and at each backpointer level you keep a state snapshot and periodically commit big gap proofs.
22:09:25gmaxwell:then hotstarting a full node just involves evaluating log2(blocks)+ε proofs, and pulling down a full state.
22:09:42gmaxwell:but since the proofs are so fast, I goes O(N) proofs isn't so bad.
22:10:05andytoshi:we'll see what hardware looks like wherever this becomes feasible :P
22:10:30andytoshi:though my money's on "before 2020", and then things will look pretty-much the same
22:14:35andytoshi:justanotheruser: the 1-1 peg discussion starts (i think) at http://download.wpsoftware.net/bitcoin/wizards/2013-12-18.txt
22:14:56andytoshi:(for some reason my logs from 12-17 to 12-27 were not on the website, that's why i couldn't find them earlier)
22:16:38michagogo|cloud:2014-01-08 22:11:18 REORGANIZE: Disconnect 7880 blocks; 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f..
22:16:39michagogo|cloud:* michagogo|cloud 2014-01-08 22:11:18 REORGANIZE: Connect 31489 blocks; ..00000000ce13e2d877387db6a418974481fdcd946bcc72c3a52f1ed7ad34f2a5
22:17:03gmaxwell:michagogo|cloud: is that testnet?
22:17:12michagogo|cloud:It's Jesuscoin
22:17:17andytoshi:phew
22:17:20gmaxwell:... Jesus coin?!
22:17:31gmaxwell:(I did a reorg on testnet that big)
22:17:57michagogo|cloud:gmaxwell: coingen
22:18:11michagogo|cloud:second coin on http://coingen.io/status.html
22:18:19gmaxwell:ohhh you blew up a coingen coin?!
22:18:30gmaxwell:hah
22:18:34michagogo|cloud:Well, my script is breaking
22:18:55michagogo|cloud:since the reorg lags jesuscoin-qt
22:19:17gmaxwell:hah
22:19:29gmaxwell:* gmaxwell titters at "jesuscoin-qt"
22:19:43gmaxwell:does it have an icon where a coin outline forms a halo around jesus?
22:21:47helo:it proclaims to _be_ the second coming
22:21:55michagogo|cloud:gmaxwell: http://imgur.com/Wldyc7t
22:22:26gmaxwell:aww
22:23:35michagogo|cloud:Okay, added begin,rescue,retry,end lines
22:23:40phantomcircuit:opportunity missed
22:23:44michagogo|cloud:that should make it stop crashing
22:24:41michagogo|cloud:If you're interested, here's my script: http://0bin.net/paste/OFWqJ7Lj0k0GO0o4#Rd6uP8VFxwv3SEO4HQAwtF+Vy5M3ZtaUrrKC9m3qI+w=
22:25:31michagogo|cloud:Anyone happen to know when Bitcoin's first difficulty increase was?
22:25:46gmaxwell:block 80k?
22:26:00michagogo|cloud:thanks
22:26:42michagogo|cloud:Heh, looks like the real chain is fighting with my replay of the bitcoin chain
22:27:03michagogo|cloud:Reorging back and forth
22:27:39andytoshi:ah, this is from before BlueMatt fixed the 'same genesis' 'bug'
22:27:59shesek:oh, it was fixed eventually? when?
22:28:06shesek:we were talking about it just yesterday
22:28:24gmaxwell:michagogo|cloud: oh I'm wrong about the height
22:28:28BlueMatt:no, it was fixed a long time ago
22:28:40gmaxwell:michagogo|cloud: 32256
22:28:57michagogo|cloud:Hmm, what did it rise to?
22:29:04gmaxwell:1.18289953
22:29:06shesek:oh, I was under the impression it was still like that yesterday... someone said it was
22:30:12michagogo|cloud:If anyone feels like watching jesuscoin get killed, https://secure.join.me/671-648-265
22:30:34michagogo|cloud:(tailf of jesuscoin's debug.log)
22:32:31michagogo|cloud:Hey, I think I might have just pulled ahead
22:33:29michagogo|cloud:BlueMatt: How many coingen coins used Bitcoin's genesis block?
22:33:41gmaxwell:michagogo|cloud: too bad there aren't any huge tx fees until fairly late.
22:34:01michagogo|cloud:gmaxwell: Why?
22:34:22gmaxwell:otherwise I'd say it would be fun top play it up to right before the point where there was a block with huge tx fees. Then mine that txn yourself.
22:34:30BlueMatt:michagogo|cloud: no idea
22:34:33gmaxwell:Then continue on.. and you get the huge tx fees.
22:34:36michagogo|cloud:gmaxwell: heh
22:37:45helo:where's the boom?
22:37:56michagogo|cloud:helo: https://secure.join.me/671-648-265
22:39:04michagogo|cloud:shh, nobody tell Luke-Jr that I killed Jesus(coin)
22:39:14helo:interesting date
22:39:46michagogo|cloud:helo: hmm?
22:40:32helo:jesuscoin has blocks as far back as 2010?
22:40:42michagogo|cloud:helo: It's the Bitcoin blockchain
22:41:33michagogo|cloud:I'm just using http://0bin.net/paste/OFWqJ7Lj0k0GO0o4#Rd6uP8VFxwv3SEO4HQAwtF+Vy5M3ZtaUrrKC9m3qI+w= to replay the bitcoin blockchain onto Jesuscoin
22:42:20helo:wouldn't the hard coded genesis block make that not work?
22:42:38shesek:they share the same genesis block
22:42:54helo:bad move :/
22:42:56shesek:coingen used to give the altcoins it created the same genesis block as bitcoin's
23:20:51gmaxwell:andytoshi: the proving process for QAP snarks is ludicrously parallel, I wonder if it would make sense to have distributed generation of the proofs? ... I think the problem is that they need communcation similar to the prover key in size.
23:23:30maaku:adam3us: I've done multiple ubuntu installs without network connection ... i know it works for 12.04
23:26:23andytoshi:gmaxwell: hmm, a high communication requirement is going to incentivize centralization
23:26:38andytoshi:and in general, if you break the proof up it is hard to decide what part any individual miner should work on
23:27:01andytoshi:which i think also encourages centralization since it is easy to organize a single mining farm to not step on its own toes
23:30:00andytoshi:i think "ludicrously parallel" will just mean that we don't have a gpu-hard mining algorithm here
23:30:49maaku:* maaku downloads jesuscoin-qt and goes to make some popcorn
23:32:34michagogo|cloud:maaku: not much to see
23:32:52sipa:i expect jesuscoin to be able to fork, and keep both instances alive...
23:32:53michagogo|cloud:It'll just look like Bitcoin-Qt syncing
23:32:56maaku:is it off of git-head, or 0.8?
23:33:02michagogo|cloud:0.8.6
23:33:04sipa:0.8.6 iirc
23:33:08maaku:oh :\
23:33:18michagogo|cloud:Why?
23:33:33michagogo|cloud:Which git feature were you hoping to use?
23:33:38maaku:i was hoping for some fine grained timestamps on the log messages to get a good idea of how the reorg was spreading through the network
23:33:59maaku:vs. the "honest" miners
23:34:01michagogo|cloud:maaku: you can roll your own
23:34:24michagogo|cloud:Just built git head and change the pchMessageStart
23:34:27maaku:yeah true. i suppose I just need the port & msg bytes
23:34:36michagogo|cloud:port 9336
23:34:55michagogo|cloud:Don't know the magic, though
23:34:57michagogo|cloud:Sorry
23:35:08maaku:np. thanks
23:35:19maaku:i'll read the first 4 bytes of blk*.dat
23:35:38michagogo|cloud:(Not at my computer anymore, I'm writing this from my bedroom)
23:37:28shesek:so I guess Satoshi is now heavily invested in Jesuscoin? :)
23:37:33shesek:he should own a pretty large chunk of it
23:39:34shesek:given his large ownership in the early bitcoin blocks
23:39:58sipa:...?
23:40:08maaku:shesek: yes, but unfortunately he Ascended into heaven in 2010 without leaving any of his public keys to his disciples :\
23:40:13maaku:/public/private/
23:40:55sipa:someone should create a Nakamotocoin - dedicated to The Ascended One
23:41:01sipa:by mocking his Creation