05:43:06kornbluth.freenode.net:topic is: This channel is not about Bitcoin today | "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi."
05:43:06kornbluth.freenode.net:Users on #bitcoin-wizards: andytoshi-logbot wallet42 justanot1eruser Vitalik__ grau TheSeven rdponticelli jaekwon quickcoin c0rw1n_ Dizzle adam3us tjopper MoALTz_ The_Turbo_Pump postpre mike4 samson_ dexX7 go1111111 sunshynez EasyAt roconnor rdymac Ursium Burrito dansmith_btc copumpkin tacotime jcorgan tromp_ mmozeiko mr_burdell Anduck Sorcier_FXK quackgyver stqism CodeShark Graet OneFixt d34th stonecoldpat Luke-Jr cluckj artifexd vcorem jgarzik jchp_ [-krypto-]
05:43:06kornbluth.freenode.net:Users on #bitcoin-wizards: LarsLarsen1 HM2 Emcy_ spinza mappum so ageis mhanne [\\\] aynstein airbreather maaku comboy K1773R amiller crescendo waxwing Sangheili bobke LaptopZZ_ Alanius justusranvier cajg johntramp Muis weex perrier UukGoblin kanzure kinlo Mikalv sploush lechuga_ forrestv petertodd Apocalyptic asoltys rs0 poggy azariah4 nanotube warren BlueMatt sl01 @ChanServ harrow edulix imjonathan Elriel otoburb keus num1 sipa hno coryfields michagogo|cloud
05:43:06kornbluth.freenode.net:Users on #bitcoin-wizards: zenojis paperbot pigeons a5m0 Dyaheon gmaxwell midnightmagic Fistful_of_Coins helo espes__ [Tristan] ryan-c Hunger- optimator gribble justanotheruser ewust iddo kaptah zacm pajarillo realz jhj1 phantomcircuit Logicwax Krellan flammit nikitab roasbeef wumpus epscy lianj heakins
13:52:28The_Turbo_Pump:The_Turbo_Pump is now known as shinybro_
13:57:59[BNC]dansmith:[BNC]dansmith is now known as dansmith_btc
14:36:25mr_burde_:mr_burde_ is now known as mr_burdell
17:15:47gmaxwell:The "encrypted bip32 seeds" draft had had some pretty extensive revision lately: https://bitcointalk.org/index.php?topic=258678.0
17:17:02gmaxwell:They've added a novel plausible denyability construction to it where you can basically pick two passwords which will decrypt one seed, a 'normal' and a 'durress', without blowing out their error checking.
17:34:53petertodd:gmaxwell: your link doesn't go to the revision
17:35:29petertodd:gmaxwell: did they adopt my idea of just bruteforcing the error checking to get two valid seeds?
17:50:58gmaxwell:petertodd: It does because they've been editing the posts for revisions (thus no diff! boo)
17:51:14gmaxwell:No they didn't they've implemented a 32 bit bloom filter. 0_o
17:55:34justanotheruser:Am I allowed to talk about dark market here?
17:56:56gmaxwell:justanotheruser: is it about cryptographic protocols and/or future bitcoin technology? :)
17:57:33gmaxwell:I don't think anyone wants to talk about any specific dark markets but technology in the abstract is interesting.
17:57:34petertodd:gmaxwell: lol, well I guess that works
17:58:32gmaxwell:petertodd: I have no idea what its rate it, have a bit of a hard time believing that it's better than "must match one of two 16 bit check values"
17:58:51justanotheruser:Yeah. http://www.coindesk.com/airbitz-wins-toronto-bitcoin-expo-hackathon-darkmarket/
17:59:04petertodd:gmaxwell: sounds overly complex too - bloom filters are the new dhts :P
17:59:31petertodd:justanotheruser: amir is crazy driven
18:00:23petertodd:justanotheruser: I also have to respect him for creating tech that is actually plausible - the other teams were doing stuff where I was less than convinced - to put it nicely - that the underlying ideas could work at all
18:00:35justanotheruser:petertodd: like he has crazy drive or he's driven by crazy
18:00:46petertodd:justanotheruser: why not both?
18:01:27sipa:i think both
18:01:30justanotheruser:petertodd: because the first means he is going to succeed, the 2nd means he is crazy
18:02:16gmaxwell:petertodd: I guess it could give a better false decode rate when there is no second key (compared to the two 16 bit check values)
18:02:43justanotheruser:Anyways, what do you think of their (future) product? One problem might be not having an incentive to run a node
18:03:39justanotheruser:Another is a malicious node that just makes a bunch of listings that are from themselves and trick the user
18:03:39petertodd:justanotheruser: heh, you know, after the toronto expo I was telling a guy that everyone in the bitcoin world is batshit crazy - the ethereum crew puts all their crazy into tech, and has reasonable politics. Guys like Amir have crazy politics, but produce tech that is actually pretty reasonable. Myself? Well I just got back from exploring caves in WV this weekend...
18:04:53petertodd:justanotheruser: Yeah, I was talking to them about that stuff - basically it's just an open question as to how far you can go with rating systems. amiller calls this the "package post problem", and argues that it may be insolvable in principle.
18:04:54justanotheruser:Are WV caves crazy?
18:05:20amiller:petertodd, parcel post, and i think i can solve it, it just requires a very unusual approach.
18:05:21sipa:WV caves?
18:05:43justanotheruser:I assumed west virginia
18:06:37petertodd:justanotheruser: All caves have small passages in them, so you can pretty much always find something crazy to be in if you push hard enough. The one I was in on saturday was mainly crazy for the gigantic boulder piles you were climbing over - a 100ft thick layer of up to house sized boulders.
18:06:46petertodd:sipa: yeah, west virginia
18:06:52petertodd:amiller: oh yeah/
18:06:53petertodd:?
18:07:13justanotheruser:amiller: can't you only place trust in the user, the post office or the seller?
18:07:34amiller:justanotheruser, petertodd, the basic idea is related to Ripple but differs in some key ways
18:07:34justanotheruser:... Or a tracking device
18:07:47amiller:there are a ton of related ideas, like PGP web of trust, ripple, trust davis
18:08:12amiller:all involve having a graph where the edges represent "some form of trust" and the idea is you can transact with people where there is some kind of flow through this graph
18:08:28amiller:the thing is, no one has been able to figure out a really satisfying explanation for what the edges are supposed to mean
18:08:41amiller:like in Bitcoin OTC or PGP Wot, it's a "number 1 through 10" which makes no sense really
18:09:16amiller:in Ripple it's basically "line of borrowing credit", but it's totally unspecified when you're supposed to pay it back or if your line of credit can be revoked right when you want to use it
18:09:56amiller:in TrustDavis, an edge means you're insuring someone like you'd pay off their debt if they end up lying, but still if one person claims the other lied, it's impossible to tell which one is which
18:10:19amiller:i think that this basic structure is the right solution, it's just a matter of finding a better explanation for what the edge means.
18:10:30amiller:here's the one that i have in mind right now:
18:10:55justanotheruser:amiller: Does that remove the incentive to say you sent a package when you didn't?
18:11:20amiller:justanotheruser, no it doesn't remove that incentive, but it allocates it properly
18:11:32amiller:you always have an incentive to steal from someone who'll let you get away with it or believe you when you like
18:11:34amiller:lie*
18:12:19amiller:when you "trust" someone, it means you're willing to accept that vulnerability even if they'd get away with it because you believe they wouldn't take it
18:13:03amiller:this is one of the beefs i have with ripple, encouraging people to "trust" companies - no one "trusts" a company, they trust the regulatory enforcement and PR fiasco response if they piss enough people off
18:13:08petertodd:amiller: makes a lot of sense - this is what you were talking about at princeton right?
18:13:15petertodd:amiller: +1 on companies...
18:13:27amiller:petertodd, uh right yeah i talked about this with gun at princeton
18:13:51petertodd:amiller: seemed reasonable enough to me, if uncertain how it'd work in the real world
18:14:02amiller:well it doesn't even work in theory yet but i'm almost there
18:14:06amiller:i didn't give the punchline yet thouhg
18:14:10petertodd:go on
18:14:31amiller:here's the one i have in mind right now: a $10 edge from A to B means "I'll take whatever bet B is willing to take"
18:14:35amiller:"i'll have what he's having"
18:15:11amiller:it's a bit like saying you'd let someone act as an agent for a stock broker for you, except it avoids the agency problem because the agent doesn't know he's acting that way, in other words it's only suppose to apply to bets that B is *actually* taking for himself as well
18:15:14amiller:also it's inherently recursive
18:15:33amiller:since B might also be willing to "take whatever bet A would take" as well
18:16:16amiller:so if you have something like A ---> B <---> C <--- D
18:16:46amiller:it's okay to let A and D trade, and if either of them cheat (you have no hope of learning which) it's okay to payout the insurance from either B or C with 50/50 either one of htem
18:17:10amiller:because one of B or C trusted the wrong person A or D, and B and C had indicated that they'd accept each other's position, so it works out
18:18:11petertodd:ha, clever
18:18:39amiller:that's as far as i've got, i think they key idea is that an "edge" is interpreted by definition as some recursive thing, so you have to solve it all simultaneously or something
18:19:10justanotheruser:That's smart, but will C have enough trust in B to take the bet usually?
18:19:11amiller:it's much different than any of the existing approaches for that reason, maybe it works out
18:19:18petertodd:god help us when it comes time to make a UI for this :P
18:19:59amiller:petertodd, lol gpg --settrust A*->B<--C<--><>EEF
18:20:29petertodd:amiller: indeed, and imagine how convoluted reading the man page will be for the average person...
18:20:30amiller:justanotheruser, i suspect that there is actually enough trust to go around, and it just isn't being properly utilized this way
18:21:08justanotheruser:amiller: are you planning on making a post about this?
18:21:40justanotheruser:Also, why doesn't it even theoretically work yet?
18:22:00amiller:justanotheruser, i'm planning on making a post and writing a real serious math paper about it
18:22:20justanotheruser:Awesome
18:22:25amiller:it's not clear to me yet what it means to theoretically work.
18:23:07amiller:i think it's something like incentive compatibility, given belief functions about trustworthiness and/or savviness of the others
18:23:13petertodd:amiller: I'm not going to claim I'm totally clear on how it works either :)
18:23:47amiller:every time i pick a new "interpretation" of the edges, that basically defines the model
18:23:56amiller:so like there is a real belief function
18:24:00amiller:then there is an expressed belief function
18:24:35amiller:then there has to be some mechanism that actually decides who to take money from, given the *expressed* belief functions, and the uncertain outcome (like you know one of A or D cheated but can't know which)
18:24:55amiller:and given that mechanism, there should be no reason to express anything other than your correct belief function
18:27:30petertodd:amiller: reminds me of a much simplier idea I had: have OpenPGP WoT edges be based on what you believed the cost would be for an adversary to fool you into signing the wrong key
18:27:49petertodd:amiller: obviously extremely rough in the real world, but it's actually a plausibly useful metric
18:27:57amiller:that's pretty close to what nanotube wanted for them too
18:28:06petertodd:nice!
18:28:28amiller:not exactly the same, but like, for otc, the score should be the amount of money % of GDP you'd trust them with
18:28:52amiller:%of global gdp is hilarious metric but technically just as good as any other :p
18:29:01amiller:anyway it's clearly not incentive compatible
18:29:13amiller:you don't actually lose anything by lying about how much it is
18:29:32amiller:if the reputations are public, you can easily be bullied into giving a good reputation
18:29:37petertodd:amiller: right, for OpenPGP in general lying about edges is hard to prevent
18:29:56amiller:in ripple a good strategy would be to give everyone lines of credit
18:30:13amiller:and then any time someone tries to borrow, frontrun them with a "close line of credit" transaction
18:31:18amiller:or for that matter just draw as much as possible on any line of credit you get
18:31:32amiller:or if people are likely to use your amount drawn, get a bunch of fake people to give you fake lines of credit etc etc
18:33:24petertodd:an nice, makes a lot of sense, some time of timestamping might help there, but that gets you quickly into ugly consensus issues at best
18:34:11amiller:i think the theory would work better in my system was actually completely zero knowledge
18:34:34amiller:like you shouldn't even be able to learn who got involved in a bad transaction, or who is offering what kind of collateral to you etc
18:34:47petertodd:oh, so you wouldn't have the knowledge needed to do those frauds?
18:35:25amiller:you should just get messages like "one of your investments broke down, you lost $50" and like "There is someone available to trade with you. There is $50 available in escrow for you to claim if the tx goes bad"
18:35:54petertodd:obvious user acceptance issues there :)
18:35:56amiller:the idea is that this mechanism shouldn't *help* you form your trust portfolio or give you any feedback, which is important since you can't learn who cheated among the people who got involved
18:36:14amiller:well a useful implementation of this doesn't have to match the theory so closely :)
18:36:45amiller:basically id want to make it absolutely as easy on myself as possible to say something formal, if that works at all, then it's natural to back off from that with tractable cryptography and acceptable leakage
18:36:45petertodd:right, which keeps the user experience closer to the theory that makes it actually work - in essense preventing users from circumventing it
18:36:49justanotheruser:amiller: can you explain who would pay what if A was shipping a $100 product to be with WoT A<-C<-D<->E->B
18:37:13amiller:justanotheruser, sure, i can make the scenario really concrete
18:37:35amiller:let me stick to the A-->B<--->C<---D case though
18:37:39justanotheruser:And in the case A says the didn't get paid, B says they didn't receive their product and in the case where they both say they didn't get paid nor receive their product
18:37:45justanotheruser:Ok
18:37:53amiller:A will ship a $100 product to B, assume that B has already paid A $100 worth of bitcoins
18:38:12amiller:this is the bobcat in a box (or parcel post) game https://xkcd.com/325/
18:38:32amiller:either A actually ships the item, or A does not shit the item. however D is the only person that learns this
18:38:51amiller:as far as the rest of the network is concerned, D either says everything went okay, or D says "there was a problem"
18:39:15amiller:if D says there was a problem, it's certain that either A is cheating or D is cheating (or both), but it's impossible for anyone except D to know which
18:39:39amiller:so basically, I think, either B or C (chosen by coinflip) should pay D.
18:39:48amiller:or maybe B and C should split it and pay D.
18:40:35justanotheruser:amiller: so what is their incentive to join? A fee?
18:40:41waxwing:has D already paid for the product? you said B paid for it earlier.
18:40:53amiller:A was already paid for the product, A is the seller and D is the buyer
18:41:30amiller:also in one of the lines above i said B instead of D but i meant D.... A is the seller, D is the buyer, D pays first, and B C are intermediaries who trust each other, and B trusts A and, C trusts D
18:42:54amiller:it would be appropriate for B and C to receive a commission in case the transaction goes well - presumably A and D are making profit on the trade, and they should share that profit with B and C who are tying up their collateral to facilitate the transaction --- however i also don't think this essential for the model to work
18:42:56justanotheruser:how is this different from ripples trust lines?
18:43:52amiller:there are several differences but it will be a little bit tricky to pare them down.
18:43:57waxwing:the bobcat problem is solved in many real world cases by use of physical delivery men requiring signatures (e.g. Taobao). Things like ebay are a bit of a weird aberration.
18:44:33amiller:waxwing, if you can trust a third party who's actually willing to receive the package (as "escrow" is supposed to mean, not like bitcoin "escrow" which isn't) then yes that solves the problem
18:44:44waxwing:with wire transfer, you can try to use ssl verification methods. with crypto, we know, there's no problem - but if you're not using verification, you have to fall back on incentives which is always going to be weak.
18:45:15amiller:i'm assuming that the digital currency side of the transaction (i.e., Bitcoin) is trivial to get right
18:45:39waxwing:in your exact case, one could argue it's better for the money to be thrown away than given to either A or D.
18:45:53waxwing:(or B or C)
18:46:54justanotheruser:I assume each of these trust connections will require very high levels of trust?
18:46:56amiller:waxwing, yes you're talking about the ripped coins idea, or like nashx.com
18:47:31amiller:where if the buyer isn't happy, then neither the buyer nor the seller get the money
18:48:10amiller:the incentives there don't work out well either, because once the buyer's put the money in, regardless of whether he gets the package or not, he can't make himself any better off by not finalizing the tx
18:48:26amiller:you can say that he's motivated by punishment but that's somewhat outside the rationality assumptions
18:48:30waxwing:yes, sort of .. interesting to compare a game theory approach with a WoT approach, but ultimately I don't think either of them are going to work out so well.
18:48:39amiller:also, you could imagine the seller saying "finalize the tranasction and i'll give you 10% of your money back"
18:48:51amiller:this is the same as the ultimatum game in behavioral economics
18:49:21amiller:waxwing, well you're saying they won't work out, but i'm really hopeful that my particular approach here is an actual solution to this
18:50:00amiller:the key of my approach is that an edge says "i'm willing to have the fate of my $10 collateral be the same as the fate of your $10", and that's different
18:50:19amiller:justanotheruser, very high level of trust? i don't know i don't think it has to be that much
18:50:29waxwing:i wish you the very best of luck, as I think this is at least as important as issues within cryptocurrency itself.
18:50:45petertodd:amiller: yeah, I expect nashx would work in practice in many real world situations, but best to have something with solid theoretical backing too
18:51:23amiller:justanotheruser, so.... ways in which this is different than ripple
18:51:29amiller:ripple tries to solve payments, which is the wrong problem
18:51:36amiller:it isn't clear how to use the semantics of ripple edges to solve this
18:51:36justanotheruser:amiller: well its free money for D from B who might loosely trust C who loosely trusts D. It seems like there is little reason for D to not take Bs money
18:52:02amiller:if C loosely trusts D for $10, then yes that implies free $10 to D.
18:53:46amiller:so the way it would work with ripple is
18:53:57amiller:i started by saying that D has already paid A the $100
18:53:59justanotheruser:What if D legitimately doesn't get the product? Shouldn't B pay since they trust A?
18:54:19amiller:justanotheruser, the money comes from either B or C.
18:54:36justanotheruser:Ok
18:54:40amiller:if D is lying to steal the money, then C trusted D, and B was willing to be vulnerable to whatever C does
18:54:44amiller:so it's acceptable in that case
18:55:10amiller:also if A actually didn't ship the product, then B trusted A, but C was also willing to endure whatever outcome happens to B
18:55:28amiller:so the idea is hopefully it's an acceptable outcome this way regardless of which of A or D was bad
18:55:35waxwing:if there is a failure in trust somewhere in the chain, but we don't know where, then the only fair thing to do is to penalize all parties equally
18:55:56amiller:waxwing, right so basically i'm saying you penalize one party the full amount, but all with equal probability
18:56:04gmaxwell:amiller: but all outcomes aren't equal.. the product really was shipped. I'm willing to trust A ... but not willing to take losses because someone who was not A was a theif.
18:56:34amiller:gmaxwell, the premise A-->B<--->C<---D says that you're B, you're willing to trust A, you're also willing to have your $10 invested by C however C sees fit
18:57:14amiller:someone who was not A was the thief, but you and B were in the same boat with the same prospect, and you indicated you were okay with that
18:57:24amiller:er, you are B - i meant to say, you and C were in the same boat
19:01:20justanotheruser:amiller: how big of a fee would you need to join as B?
19:01:44justanotheruser:Given that you have a certain amount of trust for A and C
19:02:57amiller:justanotheruser, i don't know, i'm not convinced that matters initially... if you trust A, maybe you're also charitable towards A? Or you say you'd trust A, but only for a percentage cut if the trade is successful, or a tip or something. If you are trusted your $10 to have the same outcome prospet as C's $10, then maybe you get whatever profit C is okay with?
19:03:15gmaxwell:amiller: Ah, I see what you're saying.
19:03:36gmaxwell:In general I do think that 'insurance' is vastly better than 'trust'.
19:04:04amiller:so let me finish explaining why this is so different than ripple
19:04:12amiller:with ripple you would have D send money to A via ripple payment
19:04:14gmaxwell:When people I know have shown up in OTC wanting to trade, I don't go give them a +3 and tell them to hope for the best, I go tell the channel that I will back their trades up to some value.
19:04:18justanotheruser:amiller: is this a way for two parties without direct trust to trade?
19:04:30justanotheruser:Or would they have trust in each other as well?
19:04:34amiller:this means B now "owes" A, C now "owes" B, and D now "owes" C
19:04:44justanotheruser:s/would/could
19:04:47amiller:justanotheruser, yes this is precisely a way for two parties to trade who have no direct trust between them
19:05:11amiller:so with ripple, once the payment is done, you still have that weird outcome where A might not ship the item
19:05:21amiller:if A doesn't ship the item, D knows this, but he's already paid and therefore he already owes C
19:05:30amiller:so it's totally unclear what happens at this point!
19:05:53amiller:because D hasn't *actually* paid anything, he only "owes" C, and he was ripped off by someone C trusted indirectly, maybe the idea is that D is supposed to "righteously default" or something like that
19:06:07amiller:D nominally owes C, but screw it
19:06:37amiller:there's no "i'd like to settle up now" button in ripple
19:07:08amiller:i think the idea is that somehow, someone along the path would just eat the loss
19:07:15amiller:but it's not clear who
19:07:45justanotheruser:amiller: well it would depend on how much each user investing in the person they trust wouldn't it?
19:08:03justanotheruser:User is investing
19:09:49amiller:i don't see how that notion of investing helps clear this up
19:09:59amiller:if D actually gets ripped off, shouldn't D default?
19:10:45amiller:i don't think the ripple model actually includes anyone defaulting, or at least not defaulting in a public way
19:11:15justanotheruser:Oh. I thought we were talking about your model
19:11:22Luke-Jr:IMO, if D defaults on C, he is stealing from C
19:11:28Luke-Jr:it isn't C's fault that A didn't deliver
19:12:46justanotheruser:Luke-Jr: but he agreed to take that risk
19:13:31Luke-Jr:justanotheruser: he didn't agree to forgive D
19:14:00Luke-Jr:point is, C should be free to take D to court over it and win, regardless of A's actions
19:14:36Luke-Jr:even if C hasn't settled with B yet
19:15:49amiller:Luke-Jr, then that's an example of why ripple isn't usable for insurane
19:16:31amiller:Luke-Jr, in the past dozen lines or so i've been trying to explain the difference between Ripple and the system I'm proposing which is useful for insuring transactions where it's one person's word against the other and no one can tell for sure who's cheating (but at least one of them is)
19:25:49nsh:(i'm always cheating)
19:28:17maaku:amiller: it would be A that ate the loss
19:28:20maaku:everyone else is accounted for
19:34:49hearn:lately i was thinking about how to tackle bitundo. trying to “discourage” blocks containing double spends by not building on blocks that you saw finney attack txns out of your mempool seems like a non-starter: it’d allow a DoS on the network
19:35:40hearn:but what about if miners voted in the coinbase data on whether to erase/reallocate the coinbase of particular blocks? if a quorum was established within the maturity period, the coinbase of the errant block would simply be deleted from the UTXO set, or allowed to be reallocated into the next one.
19:36:26hearn:instead of trying to auto identify bad blocks, which is open to attack, good miners would exploit the fact that bad miners must coordinate with fraudulent users. the good miners can run a separate program that submits double spends to the service and when it seems them appear in a block and successfully do a finney attack, that block starts being voted on for coinbase erasure
19:36:27petertodd:lol, that was going to be my april fools joke, but I ran out of time
19:36:59hearn:this solves the problem of miners having an incentive to vote “no” on a fork attempt because they don’t know if they’ll be on the losing side or not.
19:39:08gmaxwell:* gmaxwell votes to erase all mike's bitcoins, all in favor?
19:39:21hearn:luckily for me, i don’t mine, so it wouldn’t work :)
19:39:46gmaxwell:Well if we can do it for that, why not erase any bitcoins some random majority of miners choose? :P
19:39:47petertodd:fwiw I did some successful (and profitable!) double-spends against a gambling site by taking advantage of how eligius doesn't accept some txs to their mempool due to blacklisted addresses; in discussion with them their not particularly worried, and thought replace-by-fee scorched earth looked good enough w/ some monitoring. Interestingly the way the numbers work even if just, say, eligius implemented replace-by-fee w/ scorched earth the ...
19:39:53petertodd:... margins get too low to be profitable
19:39:55petertodd:gmaxwell: +1
19:40:02hearn:gmaxwell: a majority of miners can already do that, right?
19:40:05hearn:s/miners/hash power
19:40:19petertodd:they can also distroy bitcoin...
19:40:25petertodd:*destroy
19:40:36maaku:hearn: no, they can only temporarily censor transactions
19:40:42maaku:that's not the same as destroying
19:41:01hearn:no, they can permanently censor by just re-orging away any block that contains the transactions they don’t like.
19:41:02gmaxwell:hearn: They can at least temporarily block, but they do not. I mean what you're talking about is already a complant about things they can do but you prefer they choose not to. I prefer they choost not to effectively revoke anyone's bitcoins. :)
19:41:34gmaxwell:hearn: wrt temporary in my comment: the transaction can be reinserted later (e.g. when they are no longer a majority)
19:42:07hearn:coinbases cannot, which is what i’m talking about
19:42:12gmaxwell:(and if their majority is slim their ability to reorg away an existing block is somewhat costly, as they'll lose sometimes)
19:42:13hearn:not arbitrary transactions
19:42:21maaku:hearn: if you remove from the utxo, a temporary miner majority could permanently destroy coins willy nilly. just censorship goes away when they are no longer the majority
19:42:44hearn:the value could be added to a “pot” that can be claimed by subsequent blocks, if need be
19:42:53petertodd:maaku: yeah, and if there are, say, utxo commitments involved, then this censorship mechanism is violating the utxo commitment protocol
19:42:57hearn:so the value is merely pushed forward rather than deleted for good
19:44:00petertodd:maaku: in fact, that's a good evaluation criteria: can you make compact proofs of theft where miners don't add utxo's to the utxo set? coinbases must be included in that fraud proof tech
19:44:44hearn:obviously to implement this would be a hard forking rule change, so by definition it would not be fraud, it’d just be a new network rule
19:45:20petertodd:would help prevent theft by hackers in the case where, say, someone hacks into a majority of big pools temporarily and manages to delete some utxo's/not add some utxo's to the utxo commitments when they should have been - ugly way to destroy someone's money there, and easy to miss too if appropriate fraud proofs aren't involved
19:46:33hearn:that wouldn’t destroy people’s money, right. if such a hack happened then when someone tried to spend their money and it didn’t work, the hack would be revealed and miners would have to replay their chain to get their utxo db correct again
19:46:39hearn:it’d be a temporary DoS
19:47:17maaku:petertodd: you mean the last 99 coinbases that aren't in the utxo yet?
19:47:18petertodd:by the time such a hack is detected it may be a week later and without appropriate *automatic* tech to detect and replay, it's easy to see people not replaying
19:47:24petertodd:maaku: exactly
19:47:42maaku:yeah i've wondered whether we need commitments for that
19:47:59maaku:i haven't thought through the structure yet
19:48:03maaku:some sort of Merkle deque
19:48:35maaku:or maybe a MMR, and you just forget the older entries
19:48:43petertodd:maaku: well, proving fraud is easy enough: prove coinbase txout existance, and prove that it's 99 blocks back, and then that the new utxo didn't have that txout
19:49:01petertodd:but it is a special case, which is ugly
19:49:17sipa:do utxo commitments need the height?
19:49:18petertodd:(we should commit to a MMR of all block hashes)
19:49:29maaku:yeah it's not strictly speaking necessary, which is why I haven't focused on it - the block chain is the merkle structure
19:49:31petertodd:sipa: good point, would be useful
19:49:32sipa:do you want to be able to prove the number of confirmations?
19:49:34maaku:sipa: yes-ish
19:49:46sipa:the current utxo database does
19:49:57petertodd:sipa: OTOH proving the number of confs arguably can only be done with n individual confs to a header (or some type of NI proof doing the same)
19:50:27sipa:if so... why bother with avoiding the coinbase outputs in the utxo set?
19:50:43petertodd:sipa: sure would be simpler!
19:50:56sipa:you make the validation rules simpler, but the authentication structure harder
19:51:15petertodd:right, although an extra few bytes isn't that much harder
19:51:25sipa:by harder i don't mean larger
19:51:45sipa:hmm
19:51:49maaku:strictly speaking the height is not necesary although there are enough use cases to warrent having it included
19:51:50sipa:well, maybe not
19:52:01sipa:maaku: indeed, strictly for validation it isn't necessary
19:52:03maaku:some extensions I've considered would depend on height being present
19:52:19sipa:but an scriptPubKey-based index isn't needed for validation either
19:52:43petertodd:maaku: if you do include height, then that makes using the UTXO set database for timestamping even more attractive
19:52:44maaku:no, and I'm leaning against that anyway
19:53:08maaku:probably better to index blocks by scriptPubKey, and maybe a superblock every 144 blocks with an index of the last day
19:53:14petertodd:sipa: I think per-block committed indexes are much more useful
19:53:38maaku:that would solve all of the wallet-related scriptPubKey index uses, without enabling arbitrary data storage queries
19:54:12petertodd:maaku: be careful with that statement - bruteforcing txid hashes for your queries is a very viable approach
19:54:15maaku:petertodd: does it if you can't query by scriptPubKey?
19:54:28sipa:petertodd: less useful, but perhaps more viable on the scalability-vs-usefulness compromise
19:54:30maaku:petertodd: what? no it is not
19:54:38maaku:how do you brute force a txid?
19:55:02petertodd:maaku: sure it is: brute-forcing 32-bits is easy with a nonce in the txid, and makes the data retrieval to get your actual txout cheap
19:55:30petertodd:and at the same time, retrieval by partial prefix has huge privacy advantages
19:57:26maaku:sipa: there is a particular elegance to making the committed utxo only contain txouts that are known spendable, but yes with nHeight included it's probably simpler to just contain everything
19:58:14sipa:you need a bit for coinbaseness too
19:58:27petertodd:sipa: why?
19:58:28sipa:or, maybe even more useful: just include the height at which it becomes spendable
19:58:30maaku:wait if you have a txid hash collision -- impossible, I know -- with a prior coinbase that isn't matured yet, is that invalid in the current code?
19:58:34gmaxwell:keeping it out also has an advantage that simple verifiers are harder to trick.
19:59:02sipa:maaku: BIP30; yes
19:59:23sipa:maaku: overwriting a txid which isn't entirely spent is invalid
19:59:33maaku:sipa: no, I mean block 101 contains a regular tx that hashes to the same value as block 100's coinbase
19:59:46sipa:maaku: that would be overwriting that txid entry
19:59:46maaku:and yes, I know this means breaking sha256^2
19:59:54sipa:so that is invalid per bip30
20:00:41maaku:ok, then it would be a change in validator rules to keep immature coinbases out of the utxo set
20:01:00maaku:assuming that's an edge case worth thinking about
20:01:03gmaxwell:interesting point, since it would change the overwrite semantics.
20:01:27gmaxwell:I mean you could always check both lists.
20:01:31sipa:maaku: i generally don't care about things that require sha256 collisions or preimages
20:01:48sipa:maaku: but you're right; BIP30 implies that immature coins are part of the utxo set
20:02:07sipa:(which doesn't mean it can't change)
20:03:33maaku:if nothing else, so long as age factors into priority calculations, it is worth having nHeight in the utxo entry
20:03:38sipa:if you exclude sha256 collisions however, bip34 means this is impossible
20:03:55sipa:(and makes bip30 obsolete)
20:04:55gmaxwell:I do like that BIP30 makes things 'well defined' even with a collisions.
20:28:43wallet421:wallet421 is now known as wallet42
20:34:11phantomcircuit:gmaxwell, bwahah i finally conquered ledd
20:34:17phantomcircuit:>.>
20:43:57gmaxwell:Fun example of why byzantine robust security matters: Apparently people have problems with GPS jamming due to semitrucks driving around with jammers running (e.g. http://www.insidegnss.com/node/3676 ) because the trucks have ubiquitious gps tracking and the drivers don't want their bosses knowing they've visiting stripclubs and the like.
20:45:57maaku:* maaku reminds himself to get a pocket-sized gps jammer
20:46:47maaku:probably wont work if my car is being tracked though
20:47:46phantomcircuit:maaku, sure it would those things are insanely powerful
20:50:02gmaxwell:I'm just amused by the sort of attack being completely rational; but from the point of view of someone designing a telecom timing infrastructure no rational attack exists; byzantine robust can mean being secure against the rational attackers whos motivations are just inscrutable to you. :)
20:53:15phantomcircuit:gmaxwell, fortunately those types of jammers tend to be mobile
20:53:27phantomcircuit:so gps with a reasonably accurate clock should be fine
20:55:14maaku:phantomcircuit: oh i meant as soon as i get out of the case and walk a bit people tracking my car know where i went
20:55:17phantomcircuit:gmaxwell, this... this network the MTU is 18k across the open internet
20:55:18phantomcircuit:o.o
20:55:22maaku:* out of the car
20:55:25gmaxwell:phantomcircuit: sure, proper telecom equipment can keep spec time for several days of holdover.
20:55:28phantomcircuit:maaku, ah
20:55:37phantomcircuit:maaku, so leave one in your car and carry one on your person
21:00:37Emcy_:how illegal are gps jammers
21:01:44gmaxwell:Emcy_: see the article I linked to, the guy in it was fined 30k.
21:02:47phantomcircuit:gmaxwell, that's a pretty special case though since he was jamming AT AN AIRPORT
21:03:07Emcy_:oh he disrupted an airport
21:03:21Emcy_:surprised he got away without terrism charges
21:04:50sipa:terrism... discrimination based on upbringing on planet earth?
21:05:45gmaxwell:US policy now suddenly makes more sense to me: it's all predicated on a bad interpertation of a GWB mispronunciation!
21:05:46Emcy_:hurr
21:06:51Emcy_:that almost makes sense, no one really knew what that man was saying half the time
21:31:55nsh_:nsh_ is now known as nsh
22:34:35maaku:sipa: I didn't see the typo because because that's just one way of interpreting it