--- Log opened Mon Nov 11 00:00:04 2013
03:36 < gmaxwell> amiller: you may find interesting: https://bitcointalk.org/index.php?topic=327767.0  looks like somewhat strong evidence of a 25% hashpower miner using it to exploit a gambling site.
03:36 < gmaxwell> (I'd say conclusive, but I think it's at least slightly plausable that someone else is framing them)
03:41 < michagogo|cloud> gmaxwell: could you give an example of a way they could be framed?
03:42 < michagogo|cloud> Finding their mining node or something?
03:42 < gmaxwell> e.g.
03:42 < gmaxwell> 3. Going further, I found the address the earnings from attack were sent to: 12e8322A9YqPbGBzFU6zXqn7KuBEHrpAAv
03:42 < gmaxwell> https://blockchain.info/tx/292e7354fbca1847f0cbdc87a7d62bc37e58e8b6fa773ef4846b959f28c42910
03:42 < gmaxwell> And then part of these funds (125 BTC) was sent to ghash.io's mining address:
03:42 < gmaxwell> https://blockchain.info/tx/48168cf655d0ac0c7c2733288ca72e69ecd515a9a0ab2821087eb33deb7c6962
03:42 < gmaxwell> ...
03:42 < gmaxwell> The attacker could have just paid some of their loot to ghash.io to make it look like they were in on it.
03:44 < phantomcircuit> gmaxwell, that's a lot of coin to frame them
03:44 < gmaxwell> To be clear: I think it's more likely that the simpler explination is correct. I'm just trying to behave responsibly by making it clear that I haven't seen enough to eliminate all doubt.
03:45 < gmaxwell> phantomcircuit: if you're a competing pool... and the funds were the procedes of an attack.. I don't see why losing half of them to frame someone wouldn't be a great plan.
03:46 < phantomcircuit> there isn't really anybody competing with them
03:46 < phantomcircuit> iirc most of their hashing power is from cex.io
03:46 < phantomcircuit> who aren't going to care about this at all
03:47 < gmaxwell> also, I expect that if there are attacks going on whats actually happening is that GHash.io is doing hashpower for hire instead of attacking themselves.
03:48 < gmaxwell> which would also explain all the evidence and changes the surface of culpability somewhat. (and more importantly, teaches us a slightly different lesson)
03:49 < phantomcircuit> gmaxwell, 45k transaction fee
03:49 < phantomcircuit> heh
03:49 < gmaxwell> e.g. the payments aren't to frame, they're payments for the hashpower they bought.
03:49 < gmaxwell> step 1) buy hashpower for a small markup over its worth, step 2) double spend the crap out of some shitty gambling site, step 3) profit.
03:51 < gmaxwell> just requires someone with a bunch of hashpower which is greedy or stupid enough to go along with people buying their hashpower. Sadly, lots of people sold hashpower on pirate40's service (confirmed by the SEC).
03:53 < gmaxwell> another interesting point is that they could have profitably (well, positive EV) performed this attack even if the gambling site had been required 6 confirms, if they really did have 25% hashpower behind the attack.
03:54 < gmaxwell> (25% reverses 6 confirms 5% of the time)
03:55 < michagogo|cloud> gmaxwell: so I'm guessing house edge is <5%?
03:55 < phantomcircuit> gmaxwell, except that screwing with unconfirmed transactions isn't likely to freak anybody out
03:55 < phantomcircuit> screwing with 6 confirm transactions is
03:56 < michagogo|cloud> Also you have the coinbases that you lose if you fail
03:56 < gmaxwell> michagogo|cloud: yea, these betting sites always have really small edges, enough that they almost certantly fail the https://en.wikipedia.org/wiki/Kelly_criterion for the largest bets they allow
03:58 < gmaxwell> michagogo|cloud: yea, you just need the attack to be profitable enough that you offset the coinbase loss expected. Which you can do because the absolute return on the attack is infinite (well, bounded by the casino's bank account, maximum bet size, and number of txn you can put in a block) even though the relative return is only some percentage.
03:59 < gmaxwell> this isn't to say that attacking 0 confirmed stuff isn't much better for the attacker, it is... but just 6 confirms doesn't stop such an attack from being postive EV if you can buy the hashpower to do it at a small markup.
04:01 < gmaxwell> Because the site does 0 confirm you can double spend them with no hashpower at all. I don't really understand why the attacker bothered with the hashpower.
04:01 < gmaxwell> Your success rate is lower, sure, but your costs are lower.
04:01 < warren> Despite this, people don't seem concerned about the real problem, massive centralization.
04:02 < warren> And I'm thrilled by the huge positive response to the p2pool grant yesterday.
04:02 < warren> <crickets>
04:02 < phantomcircuit> gmaxwell, the obvious answer is because they already had it
04:04 < gmaxwell> warren: dude, no one gives a shit about technology except us. :(  This is why I think paying people to mine on p2pool is important.  Or rather, it's not that people don't care, it's that it's really mentally expensive to sort this stuff out so people don't think about it.  If you tell them upfront that they'll make more by switching to p2pool, then they don't have to think through the other stuff.
04:05 < phantomcircuit> lol it's funny cause really nobody cares
04:05 < warren> gmaxwell: make p2pool more scalable and easy enough for a caveman, maybe with no apparent share orphans/DOA with share merging, and tell them the pool's fees are lower than anything else, and then entice people to join with random donation subsidies.
04:06 < warren> currently I'm not confident that donating is well spent to attract miners who will stay
04:06 < phantomcircuit> warren, people are hella lazy
04:06 < phantomcircuit> once it's setup nobody is changing shit
04:07 < warren> it's rather scary that things are moving beyond mere centralized pools ... huge hashrate for hire
04:07 < gmaxwell> warren: perhaps but it will be months at best before its not a huge pita. and most of that isn't fixing p2pool. The fact that people are trying to run their mining on hardware that can't run bitcoind is at least as big of a barrier as anything inside p2pool.
04:07 < gmaxwell> warren: most people using bitcoin have no idea what role mining fills in the system.
04:07 < warren> gmaxwell: indeed
04:08 < gmaxwell> I reported here week before last of my expirence at the SV bitcoin users group. Lots of exicted people— even generally technically competent ones (uh with technical CVs that include a lot of php and ruby...), almost none with any real clue how bitcoin works.
04:08 < gmaxwell> Even miners often have no clue what role mining serves.
04:09 < warren> past assumptions always assumed that large quantities of greedy miners will secure the network
04:09 < warren> centralized pools broke that
04:09 < warren> and greed can lead to even worse things
04:10 < gmaxwell> well, someone made the mistake of assuming miners were rational and well informed.
04:10 < michagogo|cloud> 11:05:45 <warren> gmaxwell: make p2pool more scalable and easy enough for a caveman, maybe with no apparent share orphans/DOA with share merging, and tell them the pool's fees are lower than anything else, and then entice people to join with random donation subsidies.
04:10 < michagogo|cloud> AIUI, p2pool's model inherently has many stales
04:10 < gmaxwell> the fucking stales are irrelevant. gah. stop @#$#@$ derailing things with that warren.
04:10 < warren> michagogo|cloud: please don't get into this right now, you're demonstrating the most common misunderstanding of p2pool
04:11 < gmaxwell> warren: and you encouraged him to accidentally! see how that works?
04:11 < michagogo|cloud> But the payout mechanism means that all that matters is your stales aren't proportionally more than others'
04:11 < michagogo|cloud> Okay, sorry
04:12 < gmaxwell> michagogo|cloud: :) if nothing else there is a major UI problem there though. Because it's hard to get people to as sophicated an understanding as that.
04:12 < michagogo|cloud> Lol, #$#@$ got detected as a channel
04:13 < warren> one of the proposed counter-measures against the selfish miner thing was the honest pools forming a cartel.  If p2pool were to grow huge, that would become impossible.  Now that being possible at all is scary.
04:20 < warren> gmaxwell: I don't see any fix for the greedy miners seeking profit by selling their hashes issue.
05:52 < adam3us> so is there any reason not everyone is mining on p2pool?
05:53 < sipa> compexity & variance
05:54 < gmaxwell> Yep, plus ignorance and lazy.
05:54 < gmaxwell> People think pool fees of 3% aren't much...
05:55 < warren> adam3us: https://bitcointalk.org/index.php?topic=329860.0
05:55 < sipa> when they're less than your monthly variance, you won't notice it anway :)
05:55 < gmaxwell> (but really, it's a lot more work to use: you have to run bitcoind.. which is like a day plus of install time and 15 gb of disk space and means you can't run on a rasberry pi)
05:55 < gmaxwell> (then you have to run p2pool, which is at least pretty easy)
05:55 < adam3us> to me 3% is phenomenally high, maybe i should start a pool with lower fees that refuses no GBT miners
05:56 < gmaxwell> vs: plug in miner, type in url. Recieve bitcoins.
05:56 < gmaxwell> adam3us: then you're suspect because you charge too little, obviously the majority of people paying 3% or more are getting something of value!
05:56 < gmaxwell> plus for non-PPS pools, being a small pool means you have enormous variance, you're objectively less good.
05:57 < gmaxwell> (or at least, very small pool)
05:57 < gmaxwell> (once you're finding a block a day the variance is probably not so bad)
05:57 < adam3us> gmaxwell: yeah the reality of decisions people make is sooo stupid that moderately smart people cant even comprehend or predict the market outcomes
05:57 < warren> sigh, I really thought at least one person would have donated there.
05:59 < gmaxwell> I mean, I think I now have a mental model to predict miner behavior somewhat... which mostly seems to work. But it basically starts with the premise that miners are uninformed and somewhat lazy. When they try to get informed they get overloaded quickly.
05:59 < warren> I haven't been paying attention to the Bitcoin pools.  The first and only bitcoin pool I ever used was p2pool.  The issue preventing Litecoin pools from spreading hashrate out more is there is a tiny quantity of competent pool operators capable of keeping their software secure against exploits and robust against DDoS attacks.
06:00 < warren> There existed a few massive pools in the past who killed themselves with a payout bug
06:01 < warren> and a few just don't recover from a DDoS attack
06:01 < gmaxwell> The algorithim for selecting a pool looks like: look at the pie chart on bc.i. Compare a couple of the biggest pools. Find nothing really distinguishing between them, pick the largest.
06:01 < warren> The survivors could be behind killing their competition.  We have no way of knowing.
06:02 < adam3us> its puzzling indeed that there appears no model to get financing for core dev work that must happen for bitcoin to progress, despite there being $3b resting on it
06:02 < gmaxwell> p2pool almost doubled in size in the weeks following convincing bc.i to stop hiding p2pool on their chart.
06:02 < warren> percentage wise of global hashrate, how much did it peak at before?
06:02 < adam3us> gmaxwell: cant people run multiple independent instances of p2pool to scale it?
06:03 < gmaxwell> adam3us: sure, actually in the past some people have run it privately.  But there shouldn't /need/ to be multiple ones to scale it.
06:03 < warren> adam3us: Litecoin Dev raised $xxk in donations, we're spending a portion of that on various things, mostly security related development that could benefit Bitcoin too.
06:03 < adam3us> (you guys should be sleeping btw:)
06:03 < warren> I know =(
06:04 < adam3us> warren: esp you if youre in hawaii
06:04 < adam3us> but yeah about dev its really rubbish and disappointing the rate of progress and funding ..
06:05 < adam3us> eg colored coin i though has a lot of potential and yet the progress has been really slow; there are some people trying to get professional funding now (company, biz plan etc) so maybe that'll create something open
06:06 < gmaxwell> the people getting funding are doing mostly terrible things, see also: mastercoin
06:06 < warren> https://bitcointalk.org/index.php?topic=320695.0  <---- Bitcoin 0.8.5 + Litecoin 0.8 patches (minus the litecoin protocol)
06:06 < adam3us> (though coloring in a way that creates bitcoin dust is something i am not keen on; must be a better way to do it with side-chains if they just thought about it)
06:06 < gmaxwell> adam3us: thinking gets in the way of spending time on posts and fundraising. :)
06:06 < adam3us> warren: that is bitcoin omg link? yes i was hyped when i saw that
06:06 < warren> gmaxwell: omg, and quite a lot of funding with zero code
06:07 < gmaxwell> warren: I liked it when I asked them to use OP_RETURN instead of their garbage addresses and got told that they couldn't because they were currently creating all their mastercoin transactions by hand in a bc.i web wallet.
06:07 < adam3us> mastercoin, yes that was terrible, and it surely will fail because of the negative regard people will hold the premine in
06:08 < gmaxwell> (I stopped complaining in public about it at that point... "okay, this is going to fail on its own")
06:08 < TD> i concluded that ages ago
06:08 < TD> the whitepaper was nonsensical
06:08 < warren> gmaxwell: they tried to hire me to work on client software.  I told them to do the majority of their crap off-chain...
06:08 < adam3us> but they actually got money in a way which is disreputable
06:08 < adam3us> an yet the people doing reputable things seemingly do not
06:08 < gmaxwell> yea I ignored it initially because the whitepaper was nonsensical, then I suddenly started seeing lots of dust transactions on the network, and went searching for the cause.
06:09 < adam3us> so this is going to drive more disreputable things unless msc crashes and burns
06:09 < TD> it seems to hit the sweet spot where it seems technically credible enough to pull in a lot of suckers, but not quite credible enough to actually work
06:09 < warren> TD: pets.com
06:10 < TD> lol
06:10 < gmaxwell> adam3us: yea, look at all the altcoins (not even talking about ltc here, the zillions of other ones)... some of them have managed to monitize pretty well on the exchanges with patches that did little more than change the name of the software... its really depressing.
06:10 < adam3us> TD: to my reading the msc paper was a list of noble aspirations with no indication of how or even if they could be achieved technically, plus the disreputable invest now for big discount, limited time offer like say timeshare sales
06:11 < adam3us> the protoshares by bitshare is barely better
06:11 < gmaxwell> Or _usefully_ achieved technically.  E.g. "p2p replacement for mtgox!"  uhhhh..
06:11 < TD> i try to stay positive. what this shows is there's tremendous demand for cryptocurrency technology that works
06:12 < gmaxwell> s/ that works//
06:12 < TD> yes. but there's even more demand for stuff that works!
06:12 < gmaxwell> There is a tremendous demand for promises of future riches.
06:12 < adam3us> pts are not even anything, just a bitcoin alt-coin as a place holder until / if they finish coding their bitshare system, iwth a promise that you own 10% of bitshares, but they screwed up their params almost as badly as terracoin and mined 1/4 of issue in 1 week that was designed to take 3months
06:12 < gmaxwell> Something which works but due to honesty and understanding can't promise future riches... not clear there is much demand.
06:12 < TD> yeah. well. that's certainly one possibility.
06:13 < adam3us> TD: i am not sure, i had a look at the pts irc channel an it seems most of the miners had no clue why or what it is, they just wanted in early in case it went somewhere
06:13 < TD> i think people get hyped due to second order effects though. "i want this cool tech because it will make bitcoin more useful and thus more valuable:
06:13 < TD> but it's MUCH harder to build it than just promise the moon
06:13 < adam3us> the guy bytemaster? bitshares cto - was slapping out unsigned binaries on non SSL - very scary
06:13 < gmaxwell> TD: both bitshares and mastercoin have directly traded on that thinking even where it made no sense.
06:14 < gmaxwell> (claiming that they were enhancements to bitcoin, where in the case of esp bitshares I am unable to find any relationship with bitcoin at all except them exploiting the name in their marketing)
06:14 < adam3us> gmaxwell, TD: oh yes and when pts params failed, they put out misleading info saying you HAD to upgrade under somethreat to a massively revised param set; if the users had cludes they'd have forked the code and said no
06:15 < gmaxwell> adam3us: well realsolid already proved that what you can get away with is nearly boundless. An amazing history there that you missed.
06:15 < TD> yes these schemes are just ridiculous
06:15 < TD> what i mean is that whenever i go to a conference, i get mobbed by people asking "where's the contracts apps"
06:15 < adam3us> seems to me it'd be nice to get i dunno some salary equiv to what y'all can pull in industry to sit i a bitcoin lab not-for-profi
06:16 < gmaxwell> (guy created an altcoin and kept revising the rules over and over again, ... making me pretty much convinced it was an expirement in how disreputable you could make a cryptocurrency and still have users)
06:16 < TD> so i mean there's definitely a population of people that isn't just bandwagon jumping but _really_ want to see all the cool exotic features that were discussed come true
06:16 < adam3us> which'd take say $5mil/year or something to hoover up the top brains and make somewhere nice for them to work
06:16 < warren> adam3us: "slapping out unsigned binaries on non SSL - very scary" ... like cgminer!
06:16 < TD> a big part of mastercoin's marketing is claiming that the reason bitcoin doesn't have $FEATURE is that the core developers are too conservative, scared, not well funded enough, whatever
06:16 < TD> and that mastercoin resolves this problem thus bringing such features faster
06:17 < TD> warren: cgminer is AFAIK detected as a virus by now, by most AV systems :(
06:17 < gmaxwell> TD: except, you know, $FEATURE, seldom needs anything in core software.
06:17 < adam3us> TD: yes this is why i keep harping on about bitcoin staging
06:17 < TD> yes, all this stuff is obvious to us, but much less so to other people
06:17 < adam3us> and why i was psyched to see warren made a step towars it with bitcoin omg release :)
06:17 < warren> toward what?
06:17 < adam3us> bitcoin staging could keep the rapid dev within the bitcoin brand
06:17 < TD> luke used to maintain a "bitcoin next". dunno if he still does
06:17 < adam3us> bitcoin staging
06:17 < gmaxwell> And even if it did need it, you can test it without deploying it.... of course that requires writing something, or even figuring out in detail how it might work.
06:17 < adam3us> hmm link?
06:18 < gmaxwell> Luke still does.
06:18 < warren> adam3us: it isn't really staging, it was "I put all this work into litecoin, might as well make a bitcoin client"
06:18 < TD> gmaxwell: the good news is, someone stepped up to take over PayFile from me last week, and he seems to be credible - is already produced pull reqs. so I am hoping that quite soon we will have perhaps the first easy to use gui micropayments (contracts) based app
06:18 < TD> that people can actually download real binaries of, run, and use for something useful
06:18 < adam3us> i know but apart from the peg mechanism you did the work that i thought would need to be done
06:18 < TD> gmaxwell: it just needs a few bug fixes and packaging work basically, and then it's ready to go. the first step towards StorJ!
06:19  * TD is quite excited to see if it really happens
06:19 < TD> adam3us saw it at the amsterdam conference
06:20 < adam3us> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02944.html
06:21 < adam3us> err who is TD? (mike demoed me payfile at ams) is TD mike?
06:21 < TD> yes
06:21 < adam3us> doh ok , hello
06:21 < TD> hi :)
06:21 < TD> one day i should really abandon this nick. but i had it so long ...
06:22 < gmaxwell> TD is secretly TD bank.
06:22 < adam3us> TD: no prob, still catching up on associating bitcointtalk, real name & irc nicks
06:22 < gmaxwell> adam3us: looks like luke hasn't updated the next stuff since july.
06:23 < gmaxwell> adam3us: I decided to make that easy (nick / name matching) a decade ago.
06:23 < warren> hm, I wonder if that guy who wanted to buy my IRC nick for 100 BTC still wants it.
06:24 < adam3us> gmaxwell, warren: yes but my point with staging is to do a bitcoin next/bitcoin omg but with a one-way peg to insulate bitcoin core from bitcoin next and have real value in it AND associate it with bitcoin itself, foundation etc, not with an altcoin
06:24 < gmaxwell> Every once in a while I still run into someone who goes "holy crap! you're nullc!" (which was my irc nick since ~1993)
06:24 < adam3us> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02944.html
06:24 < TD> the nick "mike" was only registered in 2011 and has only been used once. goddamnit.
06:24 < adam3us> gmaxwell: yes i figured out nullc was you from reddit or something
06:25 < gmaxwell> adam3us: I'm not sure you can do live developement in something with value. initial testnet was a disaster even as a testnet, not something for rules expirementation.
06:25 < adam3us> warren: staging, staging, staging
06:25 < warren> adam3us: I found it much easier to fix a critically broken altcoin than to win any political battle here.
06:26 < adam3us> gmaxwell: staging is not testnet, it wouldbe like litecoin level of care
06:26 < adam3us> gmaxwell: but one-way pegged to bitcoin
06:26 < gmaxwell> And anything with value is a competition with bitcoin. I really can't express how demoralizing it is to be compeating with your own work. Even if you try to set it up so it won't be that way, e.g. premine out the altcoin thing, some altcoin will just copy the code and exploit it.
06:26 < adam3us> gmaxwell: so for mindshare and other purposes the coins are bitcoin, its partly an anti-mindshare dilution argument
06:27 < gmaxwell> adam3us: ah, with some cross chain transfer?
06:27 < adam3us> gmaxwell: i think y'all didnt read it, or follow
06:27 < adam3us> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02944.html
06:27 < gmaxwell> adam3us: I stopped reading those threads because the initial ideas proposed were not very interesting to me, sorry. If you're telling me again its interesting I'll read it.
06:27 < adam3us> gmaxwell: the staging idea is bitcoin staging (need better name) has no native mining, the only way to get coins in is to move them from bitcoin
06:27 < gmaxwell> adam3us: yea great, and when an altcoin copies the code and removes that limitation?
06:28 < adam3us> gmaxwell: and then there is 2-way trade in the reverse direction
06:28 < gmaxwell> Certantly I like the idea that the market can decide to support the new thing by chosing to use it rather than having a speculative feature forced on it via hardforks.
06:28 < adam3us> gmaxwell: altcoins can float or not on their own, you cant prevent it with opensource; but bitcoin staging can capture the early adopter and feature hungry people like mastercoin, colorcoin, warrren (bitcoin omg), lukejr (bitcoin next)
06:29 < warren> how does the staging coin confirm things?
06:29 < adam3us> gmaxwell: which undermines most of the altcoin impetus and mastercoin arguments about faster dev
06:29 < adam3us> warren: side-chain
06:29 < warren> so you mean no subsidy, not no native mining
06:30 < adam3us> warren: right
06:30 < gmaxwell> adam3us: altcoin people hey aren't asking for new features and almost never have any, except for highly trivial changes. They're asking for a get rich scheme.
06:31 < gmaxwell> I don't think you can offer that while making the currency bitcoin. :)
06:31 < adam3us> warren: i wanted to see a way to overcome the must be careful not to damage core value, and see still conservative but faster feature dev, without that being under an altcoin with its own floating value
06:31 < adam3us> gmaxwell: yes; but mastercoin was able to use it as one argument to justify their existence
06:32 < warren> adam3us: there are more complicated issues preventing that aside from the lack of funding
06:32 < gmaxwell> True, fair enough. At least it could prevent that, which might have redirected some of the funding.
06:32 < warren> adam3us: for example, political will is a limited commodity too.  It's demoralizing to work on things that you know will be shot down by <whoever>.
06:32 < adam3us> gmaxwell: i mostly mean like the argument warren gives that litecoin can provide ne wfeatures faster
06:33 < TD> like what things?
06:33 < gmaxwell> I really wish I had some way to estimate how many people actually understand the concept of decenteralized cryptocurrency, e.g. where a hypothetical paypal-bucks and bitcoin are distinct in their minds.
06:33 < adam3us> gmaxwell, warren: so i think its more interesting to capture the new features under the bitcoin foundation umbrella as bitcoin staging than have those features motivate or drive adoption of an altcoin
06:34 < adam3us> TD: features? eg like armory's request to have the signature include the value, so he oesnt have to transfer 1MB to validate a tx
06:35 < warren> adam3us: you're missing the fractured camps of different groups out there upset with the bitcoin foundation for different reasons, ranging from the anarcho-capitalist crazies to sane technical people.
06:35 < gmaxwell> It might actually turn out that there really are only a few thousand people that are really very of the underlying ideas, which would explain some of the lack of progress.
06:35 < warren> adam3us: Bitcoin Foundation does not control Bitcoin
06:35 < gmaxwell> It's going to control Bitcoin. The general public already believes it does.
06:36 < TD> adam3us: i meant what stuff was warren seeing being shot down
06:36 < gmaxwell> And most of them believe it always did, because the idea of something not being produced by an instution is too foreign to contemplate in any case, so they're not upset about it as a landgrab.
06:36 < adam3us> warren:  my point was the mind share for new features should stay with bitcoin (less worried about foundation arguments)
06:36 < warren> TD: I sometimes rather give up on pushing things that would protect Bitcoin, it's easier to prove it elsewhere first.
06:37 < warren> adam3us: that's a reasonable goal, lacking funding
06:37 < adam3us> warren: well a great example is the sig includes input value i gave, armory badly needs that to make more secure offline wallet
06:37 < TD> warren: like what?
06:37 < adam3us> warren: as is they have to send the full tx details just to be able to validate
06:37 < warren> TD: really too late to get into this right now.
06:37 < TD> warren: i mean you assert that we shoot down all your great ideas, but i don't remember this happening
06:38 < TD> well, alright.
06:38 < gmaxwell> Well I certantly shoot down ideas. :P
06:38 < TD> but just be aware that maybe some ideas get shot down for valid reasons :)
06:38 < gmaxwell> some of them are even good sounding ones. :P
06:39 < adam3us> TD: 'm guessing he would more mean good ideas, that are delayed for risk arguments, like armory's request i saw that iscussed and most seemed to think it a good fix, but i am not sure when its going to happen as any kind of fork is a scary scary thing to navigate for good reason
06:39 < gmaxwell> Like I think we should have UTXO expire in bitcoin, because it will increase supply certanty, reduce validation costs, and protect the network from cracking attacks bringing back long lost coins.. but I also think that doing so would be economically incompatible with bitcoin— a violation of our promises.
06:40 < TD> adam3us: i don't think that's delayed for "risk reasons". nobody has written the code, have they? so the question of when to do such a hard fork has never even come up yet.
06:40 < gmaxwell> adam3us: I haven't yet seen a softforking value-in-txn design that wasn't ugly as sin. Certantly no one has even drafted a bip for one.
06:41 < adam3us> TD, gmaxwell: fair enough i guess i should get off my butt and write one... but i am not blowing smoke i think to say the core has to be rightly extremely cautious about changes
06:42 < gmaxwell> sure, and indeed it is— but thats not the cause for changes not existing.
06:43 < adam3us> gmaxwell: hmm i suspect warren thinks different, and i saw sipa said the only way to make faster change was a rewrite i dont know as i havent tried it first hand
06:44 < adam3us> gmaxwell: ah maybe the issue is the softfork - the actual (probably hardfork) design and idea seemed extremely simple and clean I thought
06:44 < warren> TD: it isn't my great ideas, and it isn't about quantity
06:44 < TD> yeah. doing it with a hard fork isn't that hard. i'd like to see this happen too.
06:45 < gmaxwell> adam3us: changing transaction syntax in a hardfork would be trivial (but god, I hope that input values wouldn't be all that we'd change)
06:45 < gmaxwell> but now what are you going to do with the fact that parties like mtgox and coinbase use their own node software and are already not able to keep it working right.  How will they adopt this hardfork?
06:47 < gmaxwell> P2SH has failed to be adopted by most alt implementations, even just for send-to, making it almost useless for everyone. ... and its a very simple change.
06:48 < adam3us> TD, gmaxwell: another use case eg the visual wallet (forgot the name & link) like an armory wallet but using animated qr code interface on an android tablet wallet with a physically disabled wifi; its hard to do that because of the bandwidth or its safer than usb that armory uses
06:48 < TD> animated qrcodes? ye gods. bluetooth exists, people!
06:48 < adam3us> gmaxwell: well... with bitcoin staging you do your advanced stuff, then you trade it back to btc to deal with likes of gox
06:49 < gmaxwell> "and bluetooth is still airgapped! see, no wires!"
06:49 < adam3us> TD: the idea is to have optical interface only - isolation from remote network/bluetooth stack compromise
06:49 < gmaxwell> and then they overflow your transaction parser. :P
06:49 < adam3us> armory tries but then you have a usb going back and forth, and there is risk of "bad bios" usb compromise of the bios firmware
06:50 < adam3us> gmaxwell: indeed thats the new attack surface however its software so at least you can look at it unlike bios firmware
06:51 < warren> Snowcrash bitmap to brain infection...
06:51 < adam3us> gmaxwell: yes about tx parser, but thats in the realm of magic pgp message that compromises the targets machine when he processes it
06:51 < gmaxwell> adam3us: if you're going to buy into that badbios stuff you might as well hypotize that the table is already compromised and the high frequency sound modem in your computer is already bridging the airgap (something else dragos claimed... )
06:51 < gmaxwell> in any case, no one is arguing that making the data smaller is important.
06:52 < adam3us> gmaxwell: half the bad bios was space alien paranoia unsubstantiated, but my hacker buddy says the firmware compromise part is plausible
06:52 < warren> computers already infect humans with psychological diseases
06:52 < gmaxwell> yea, it's unsubstantiated but plausable.
06:52 < gmaxwell> (if you look, alans' original signer stuff... it didn't send the inputs, I pointed out to him that it had to... so I'm not unaware of what a pain that is)
06:53 < gmaxwell> though I don't really know if including the value is the best solution, or just restructuring the transactions so that the inputs are always super compact.
06:53 < adam3us> gmaxwell: yes i saw you on the bitcoin thread talking about it (didnt know/recal that you first observed the issue, ok)
06:53  * warren sleep
06:53 < adam3us> 'night
06:54 < warren> adam3us: "core has to be rightly extremely cautious about changes"  core really needs to be a lot smaller
06:54 < warren> ok, really going
06:55 < adam3us> gmaxwell: an explicit change amount might help, the saving from implicit change is the core problem
06:55 < adam3us> gmaxwell: sorry implicit fee i mean
06:55 < gmaxwell> adam3us: e.g. if the txid:vout in a transaction was really just a txout hash, and the transaction itself was a hashtree, then proof of the relevant inputs is always compact. (just provide the inputs)
06:56 < gmaxwell> In the general case for security— assuming scripts beyond regular pay-to-pubkey, its not adequate that the signer know the value, he actually needs to know the scriptpubkey he's signing for.
06:56 < adam3us> gmaxwell: implicit fee seems silly, then we have screw ups now and then
06:57 < adam3us> gmaxwell: yes
06:57 < gmaxwell> implicit fee is needed so that anyonecanpay can be used to add fees later.
06:57 < gmaxwell> if the fee is under the signatures you can't do that. :(
06:59 < adam3us> gmaxwell: i guess initial fee could be validated with =, anyonecanpay increased fee with >
07:00 < gmaxwell> > leaves you with the fee overpayment accident issue still. :)
07:01 < adam3us> gmaxwell: yes; i am going to refrain talking to you for a while os you go sleep - tomorrow:)
07:01 < gmaxwell> if instead you could extract inputs compactly the signing process could be  createraw / add-inputs / signraw (which _requires_ inputs and can tell you the fee in return)
07:01 < gmaxwell> goodnight
07:01 < adam3us> 'night
08:41 < michagogo|cloud> 13:24:49 <TD> the nick "mike" was only registered in 2011 and has only been used once. goddamnit.
08:41 < michagogo|cloud> Well, actually...
08:41 < michagogo|cloud> It's never been used at all
08:42 < michagogo|cloud> Also, the requirement that new accounts have email addresses has been in place for more than 2 years
08:42 < michagogo|cloud> The account mike has noemail [sic]
08:42 < michagogo|cloud> And also, it has the Hold flag, which means an account doesn't expire, and that flag can only be set by freenode staff
08:43 < michagogo|cloud> Conclusion: 1 year, 46 weeks, 5 days, 13:00:53 ago, freenode staff registered that as a dummy account to make it unusable
12:57 < maaku> <gmaxwell> Something which works but due to honesty and understanding can't promise future riches... not clear there is much demand.
12:57 < maaku> ain't that the truth
12:58 < maaku> you should see the negative reactions we got to freimarkets
12:58 < maaku> "what? there's no built in way to 'invest' in this? then why should I care when we've got mastercoin?"
12:58 < maaku> ...
13:00 < gmaxwell> I guess its no shock, there is a selection bias in the bitcoin community. A lot of the bitcoin users are bitcoin users because they heard they could make a quick buck. :)
13:01 < maaku> yeah
13:02 < maaku> i got 3btc for coinjoin so i'm going to update the code this week
13:02 < maaku> 3btc actually goes pretty far now :)
14:17 < adam3us> maaku, gmaxwell: i think if someone wants to take funds to do something it would be more normal to issue stock in a conventional company, in exchange for the investment; then the owner is a stakeholder in the company as with any other investment
14:19 < adam3us> maaku, gmaxwell: whereas mastercoin was like nuts: if this takes off you the investor will own a slice of global digital certificate fee currency for ever as it grows to $1triliion (or however it is that msc relates to the stock certificate concept on mastecoin)
14:20 < maaku> adam3us: the issue is how to monetize colored coins in the first place, how to make a business plan out of it
14:20 < adam3us> maaku, gmaxwell: even if it took off thats nuts, that  few gullible investors who feel for the join in the next x hours and get a 10% discount, time limited offer time-share like pitch, any rational person would abstain from participating on principle
14:21 < maaku> i could sell you shares in my company, but if my business plan is "develop open source software!" ... i'm not sure why you'd invest. a share of 0 is still 0
14:21 < adam3us> i am not sure how public this log is, but there are some folks giving it a go to attract conventional angel/investment into just that, with various monetization of the company but with open coloredcoin code & IP
14:22 < adam3us> maaku: personally i think why not - if coloredcoins (or preferably something side-chain that doesnt create nominal value bitcoin tx) does succeed, and in my view the blockchain innovation and smart contracts are so stark that it must sooner or later
14:23 < BlueMatt> the difference being mastercoin is selling shares in itself in some way that looks very clearly scammy, whereas there are better ways that dont look so ridiculous
14:23 < adam3us> maaku: there have to be multiple avenus for that company to collect on being the developers of it, having the expertise, enterprise versions, certification, hookups with auditors to certify issuers, etc etc
14:24 < adam3us> maaku, BlueMatt: exactly, to buy shares in a company and share in its success (or failure) in proportion to other investors and with a written prospectus and investment contract is actually largely uncontroversial
14:25 < maaku> Of course colored coin efforts will succeed. imho bitcoin is a toy and colored coins is where the real action is moving forward.
14:25 < maaku> (Otherwise I wouldn't have spent so much of my free time designing Freimarkets)
14:25 < maaku> the issue is, if you directly try to monetize it, you end up like Ripple.com or Mastercoin, both of which are paths to the dark side
14:25 < adam3us> maaku: yep, and i others were frustated by the progress of it being available in a user level sense; though actually i dont know much about friemarkets
14:26 < maaku> whereas if you simply ask the question "what's the best decentralized, distributed way to do colored coins?" the answer is not directly monetizable by the people who make it
14:26 < adam3us> maaku: (of colored coin not being availalble to user leve i mean).. its probably more than making a stable secure client, there is regultion to consider
14:26 < maaku> adam3us: https://bitcointalk.org/index.php?topic=280292.0
14:27 < adam3us> maaku: i dont think thats true re what i said above "there have to be multiple avenus for that company to collect on being the developers of it, having the expertise, enterprise versions, certification, hookups with auditors to certify issuers, etc etc"
14:27 < gmaxwell> I'm skeptical that colored coins are actually useful at all, but I'm happy to see people try.
14:27 < maaku> Yes, that's our path forward right now, but it hasn't been easy...
14:28 < maaku> Jorge and I have started a St. Vincent domiciled company to do a hosted colored coin solution  - "github for colored coins"
14:29 < adam3us> maaku: go maaku & jtimon, now thats what i'm talking about - action beyond code
14:29 < maaku> But most of our conversations with bitcoin investors have ended up along the lines of "Why don't you just do a new alt chain so we can invest in the idea directly like mastercoin?" etc.
14:29 < gmaxwell> Most of the examples I see are trivally exo-coin-able. The colored coin itself actually serves almost no purpose, there is some other system that assigns meaning to the coin, so you can usually do your transaction there.   There are arguments to be made that the other thing might try to censor transactions, but it could just as well refuse to honor transactions... and bitcoin itself is pretty censorable. Maybe it isn't a wash, but I ...
14:29 < gmaxwell> ... think it's far less obvious a gain than it looks at first blush.
14:31 < gmaxwell> worse, since bitcoin is colorblind, it doesn't usefully compute artifacts that help make looking up your colored coins computationally efficient. .. and if you try to make it, via things like inefficient tag addresses and address indexes, you make the colored coins much easier to censor. :(
14:31 < adam3us> gmaxwell: i think the irrevocability surprisingly transfers to even issuer backed items (eg colored usdcoins, goldcoins etc) as well as shares, in a way that ripple can not
14:32 < adam3us> gmaxwell: the issuer may not let you redeem, but you can trade for bitcoin or other exchange tradeable cryptocurrency, and get out
14:33 < adam3us> gmaxwell: though i have reservations about literally coloring bitcoins due to the tx volume of nominal value coins (eg mtgox has internal transaction per second peaks over bitcoins max tps with 1MB block)
14:33 < maaku> gmaxwell: that's why we developed freimarkets, because colored coins were too limited in functionality and huge scalability red flags
14:34 < maaku> it's our answer to the question "if you were to hard-fork, what changes would net you the most bang for the buck in the most general way possible"
14:35 < BlueMatt> gmaxwell: yea, thats a bit washy...in many cases that is true, but putting the colored coins directly in the bitcoin txn disconnects the exchanging from the issuer having to deal with it. and given that in some cases the exchange is a different part from the issuer, that may be a desirable property
14:35 < adam3us> gmaxwell: yes i thought of the definitional anti-mastercoin-dust (msc=literal coloring based) possiblity :) if they disrupt the bitcoin network to the point of seriously affecting normal bitcoin, the necessary openness and detection of coloring implies they can be blocked
14:35 < maaku> adam3us: well, anyone who thinks a decentralized exchange is going to surpass mtgox volume is fooling themselves
14:35 < BlueMatt> ofc there are plenty of cases where colored coins could easily just be handled directly by the issuer in a non-colored-coins way with the same security model (+/-)
14:36 < maaku> although you can take the idea rather far - if, like freimarkets you only ask for concensus on matched trades, not the order book, then you could probably reach mtgox circa-2012 levels
14:36 < adam3us> gmaxwell: actually let me retract that - the way msc does it most likely (and i didnt look at it beyond the initial paper) it could be blocked, but that may not be inherent, eg like my committed tx proposal  demonstrates yo can hide the nature of your tx even from all hostile miners
14:36 < gmaxwell> BlueMatt: a bit, but there are big advantages to not dealing with bitcoin. like... there is no promise that your colored coins will actually be transferable in bitcoin in the future. So even if the company is honest, the reality of bitcoin might make life hard for you.
14:37 < gmaxwell> adam3us: the schemes that hide though make the data even less public... and of course, if you can hide successfully, you could also use that with the trusted creator-of-value.
14:38 < adam3us> gmaxwell: i mean the committed tx feature that you can use bitcoin network validation for double-spend, without revealing addresses and tx details to the miners (or anyone not involved in the tx) due to commitments (hash tx detaisl including value, inputs, addresses) other than a one use recipient address to assure no double spending
14:38 < gmaxwell> Basically, whenever I've talked to people they've used examples where you can achieve it without bitcoin. maybe with some somewhat different tradeoffs. But since bitcoin is a _global_ broadcast medium, I generally default to "if you can achieve what you need without bitcoin transactions, you should"
14:39 < adam3us> gmaxwell: strongly agreed.  however i wanted to say that you can do irrevocable digital bearer certificates on a block chain, even if they are not mined, just issued; the issuer can refuse to redeem, but you dont need him to
14:40 < gmaxwell> adam3us: yea, now the annoying thing there is that all the users of those systems have to forever be personally trancking every coin in their system, because bitcoin can't do the work for them. And, of course, if the private data needed to do the tracking gets released people can censor the commitments.
14:41 < adam3us> adam3us: because you can trade them, atomically p2p for other cryptocurrency, and if necessary via other exchange if you want fiat
14:41 < adam3us> gmaxwell: actually bitcoin can do the storage for them, what the user has to store in committed tx in that variant is tiny, fixed size
14:41 < maaku> adam3us: if the issuer stops redeeming, I doubt there will be much liquidity to do that
14:42 < adam3us> maaku: no i mean about irrevocable DBC status, ecash like status; in my lexicon something i snot a DBC or not ecash if it has fungibility issues arising from selective non-tradeability
14:42 < gmaxwell> yea, if you imagine a money like asset whos value is pure scarcity ... there is an argument, but of course a money like asset is competative with bitcoin and miners have all the more reason to .. uh not look kindly on it.
14:42 < maaku> but anyway i think it's rather rare that you need global concensus when there is a trusted issuer involved
14:43 < maaku> let an exchange or the isser themselves run an accounting server
14:43 < adam3us> maaku: i think you are over-estimating the issuers involvement
14:43 < gmaxwell> I think you're talking about different cases.
14:43 < adam3us> maaku:  the point is once there are usd colored coins on the network , people wont need to use fiat wire xfer to get into and out of gox etc
14:44 < gmaxwell> One of the things people talk about are shares in companies. (e.g. like bitcoin businesses) there have been a lot of bitcoin stock markets .. and everyone worries that the next one will vanish and swallow up everything.. and so they ask for something p2p.
14:44 < adam3us> maaku: they can load exchanges with usdcoin, or type3 exchanges that just order match and green sign confirm a p2p atomic swap btc for usdcoin
14:44 < gmaxwell> adam3us: LOLOLOLOLOL
14:44 < adam3us> gmaxwell: ?? LOL ref?
14:45 < maaku> adam3us: what happens if the person acting as the gateway for usdcoin up and disappears?
14:45 < gmaxwell> adam3us: because everyone is totally going to be trusting that their adam3-usd is redeemable. That idea is a farse. Especially because creating notes for USD is generally believed to be regulatory unlawful... which is problematic if for nothing else than because you need the USD to actually be transferrable at some point.
14:46 < BlueMatt> adam3us: ehh, it still requires a similar level of trust on issuers...
14:46 < adam3us> maaku: sure, no diff to now what happens if gox goes under and you loe your goxusd (which btw are only worth 90c on the dollar)
14:47 < gmaxwell> adam3us: yea sure, but gox acts as a centeral clearing house. So goxusd is (in theory) liquid.
14:47 < adam3us> gmaxwell: "adam3-usd" tee hee pun.  in my way of thinking some innovator sticks their neck out forms a company in a digital currency conducive jurisdiction and issues them with auditors, banking reuglation and everything else that goes into it
14:48 < gmaxwell> We could call it DigiCash, if the name isn't already taken.
14:48 < adam3us> gmaxwell: its not liquid there are extreme backlogs getting the money out, daily limits, per tx limits, multiple month delays thats why its wort 90c on the dollar
14:48 < maaku> adam3us: hence our decision to domocile in St Vincent...
14:48 < gmaxwell> adam3us: that was the "in theory" part. Still, people consider it better than random-scammer-usd.
14:48 < adam3us> maaku: again, go maaku
14:49 < gmaxwell> adam3us: and in these cases you don't need colored coins for any of this. Have random-scammer run an open transactions server. The RSUSD is useless if RS goes kaput in any case.
14:49 < maaku> but the earlier point, that goxusd has any value is because you trust mtgox ltd. to redeem them (or you slightly trust them, and have 0.9 valuation)
14:49 < adam3us> gmaxwell: clearly its better if its a person people know, using their real name, with a real company in a credible, well regulated banking jurisdiction, with transparency, credible investors and backers
14:50 < maaku> you're trustin them to be honest anyway, so what is gained from public, global consensus of goxusd transactions?
14:50 < adam3us> gmaxwell: i dont think thats true; yes if it goes under you're in as much trouble as if gox goes under; but gox lived for some years so far, an presumably a few more yet
14:50 < gmaxwell> adam3us: sure, and if it is they can maintain their own ledger ... even using chaum tokens.
14:50 < adam3us> maaku, gmaxwell: again DBC have to be irrevocable or they are not DBC
14:50 < maaku> DBC?
14:50 < adam3us> digital bearer certificate
14:50 < maaku> ok
14:50 < gmaxwell> adam3us: if gox goes under all goxusd is worthless.. if RS goes under all RSUSD is wothless. Why not make RS run the ledger for them?
14:51 < adam3us> back in like 1995-2005 there were people running around ranting about DBCs, smart-contacts, chaum ecash etc
14:51 < adam3us> gmaxwell: there is a difference
14:51 < adam3us> gmaxwell: the ledger is central it can be hacked
14:52 < maaku> adam3us: Jorge and my poposal (in the Freimarkets PDF) is to have "private accounting servers" -- private servers that speak bitcoin p2p, but with the consensus algorithm sergically removed
14:52 < adam3us> gmaxwell: the leger is central there can be a court order to modify it
14:52 < adam3us> gmaxwell: if there is no mining there is no security against modification
14:52 < maaku> digitally sign blocks instead of proof-of-work
14:52 < maaku> but you could use open-transactions too
14:52 < gmaxwell> adam3us: the value behind the ledger is central regardless. Some court orders RS to pay cert 12345 to 23456 instead. "What now, bitches?"
14:52 < maaku> either way, you get the same security properties and don't force everyone to track your ledger
14:53 < adam3us> maaku: i dont think consensus like ripple cn actually make a DBC nor a smart-contact because the transaction layer does not finally and (fairly) instantly settle
14:53 < gmaxwell> as maaku says.. what OT supposidly does is let you distribute that stuff (but not decenteralize it) and it also produces recepts that can show when the ledger operators cheat.
14:53 < adam3us> gmaxwell: as i said the thing is the issuer for adam3-usd :0 is not online
14:53 < adam3us> gmaxwell: it doesnt get involved in exchange, just in changing the money supply, with an airgapped key
14:54 < gmaxwell> adam3us: there is no reason for the consensus and issuing to be the same keys... It's not like bitcoin instantly clears.
14:54 < adam3us> gmaxwell: yes sure but OT is still centralized just slightly redudant
14:54 < maaku> so if random OT server just disappears, the people using it have all the information necessary to reconstruct their accounts in their receipts, without trusting each other
14:54 < adam3us> gmaxwell: ok let me make a ripple example of why consensus fails
14:54 < maaku> adam3us: our point is that adam3-usd, goxusd, or any X-issued coin is centralized anyway, so why demand decentralization?
14:55 < adam3us> (finding email)
14:55 < adam3us> maaku: there is a reason... one sec find th eemail
14:55 < maaku> ok
14:55 < maaku> adam3us: are you talking about OpenCoin/Ripple.com concensus algorithm, or Ryan Fugger ripplepay accounting?
14:55 < gmaxwell> maaku: an argument is, for example— the centeral party could be online only rarely. But I think this is a pretty thin advantage vs the tradeoff e.g. losing instant transactions and running into the global scaling and possible censorship problems with bitcoin.
14:55 < adam3us> it distinguishes ripple from bitcoin-like and makes bitcoin (mining based) inherently superior in irrevocable final settlement which keeps dispute costs out of the transaction level
14:56 < adam3us> screw it my filing system is stupid, i'll explain
14:56 < adam3us> gmaxwell: thats not it either
14:57 < adam3us> gmaxwell, maaku: lets say we're talking about ripple when they implement the ripple script
14:57 < adam3us> (they also have aspirations to do smart contracts, you can consider their gateway ious as a kind of issue)
14:57 < adam3us> except its consensus based
14:57 < adam3us> ok now imagine someone gets scammed, eg malware causes them to sign something they did not intend (their computer lied to them and they bought shares for 10 the advertised price)
14:57 < maaku> gmaxwell: very true, which is why we want to deploy Freimarkets to Freicoin, not just private servers although we expect most traffic to be private...
14:58 < adam3us> they take the evidence to a court, the court decides in the favor, slaps > 50% of ripple gw with court orer to undo that
14:58 < maaku> also I imagine reconciliation at the highest level will happen on the public chain (e.g. gox and bitstamp paying each other)
14:58 < adam3us> unlike bitcoin mining-hardened block chain, there is no 50 day minng equiv param so they comply
14:59 < adam3us> with bitcoin like block chain, the court cant make that order, because its basically mathematically impossible at current compute rates, by the time a court has issued an expedited decision, the block chain will be months in at 5ph/s
15:00 < gmaxwell> adam3us: except they can just slap the stock issuer with the same order, and damn the consensus. Of course that doesn't reverse the bitcoins, but it still wouldn't reverse the bitcoins if bitcoins were transacted in bitcoins and the stock leger was run by the company.
15:00 < adam3us> so a ripple smart contract is actually a dumb contract, and a ripple xrp is not ecash, its a revocable IOU, and a ripple usd is not aecash, and a ripple share is not  DBC etc
15:00 < adam3us> gmaxwell: yes but it doesnt matter to you
15:00 < adam3us> gmaxwell: as long as the transactoin layer is fungible who cares if the court puts a random number somewhere
15:01 < gmaxwell> because it's not fungible, you just trace the colored coins and don't honor them.
15:01 < gmaxwell> "it's only fungible if you're not looking"
15:02 < adam3us> gmaxwell: yes well thats a bitcoin fungibility flaw too eh... thats why i proposed committed tx
15:02 < gmaxwell> Lets imagine that share ownership is run by the company, and people can exchange them for bitcoin by doing an atomic transaction.  court orders a reversal. You still can't make the bitcoin network reverse the bitcoins, and you still can make the company not honor them.
15:02 < adam3us> gmaxwell: bitcoin also not quite ecash until this fungibility issue is addressed somehow
15:02 < gmaxwell> adam3us: but committed tx doesn't help, because eventually the company needs to see the history to honor the shares, and in doing so they can distinguish ownership.
15:02 < BlueMatt> a court cant force the chain to change algorithms because they only have jurisdiction in some area, and they would literally fork the system if they tried to
15:03 < gmaxwell> and even if you make bitcoin fungable, you do so at the expensive of making colored coins impossible.
15:03 < gmaxwell> Colored coins are achieved by breaking fungibility!
15:03 < adam3us> gmaxwell: think of the DBC share as like a chaum signature, they cant selectively dishonor them
15:03 < BlueMatt> whereas they can force a given issuer to not honour certain coins
15:03 < gmaxwell> BlueMatt: yes, what are you disagreeing with?
15:03 < BlueMatt> nothing, i was agreeing and restating
15:03 < adam3us> gmaxwell: i dont think fungibility and prurpose / currency field are incompatible eg brands ecahs has attributes and blinding unlinkability
15:04 < BlueMatt> youd have to have decentralized issuance/redeeming, but that becomes an issue of trust...
15:04 < BlueMatt> how do you trust all the issuers if anyone can be an issuer?
15:04 < adam3us> gmaxwell: also when you have a share in IBM, you dont turn up at IBM and demand they have an emegency stock holder meeting to do a 10 share buyback, you atomically trade them
15:04 < gmaxwell> BlueMatt: well decenteralized redeeming doesn't generally make sense. :)
15:04 < BlueMatt> yep
15:05 < adam3us> gmaxwell: ye not decentralised redemption, decentralized trading
15:05 < gmaxwell> adam3us: because there is no way to distribute a classical stock market because we're not using ecash for usd. :P
15:05 < adam3us> gmaxwell: thats circular man
15:05 < adam3us> gmaxwell: so we need to issue usdcoins
15:06 < gmaxwell> adam3us: and I'm arguing that for most things decentralized trading has very little marginal value (but not zero) when issuing and redemption are centeralized.
15:06 < adam3us> gmaxwell: but also once you have shares, it doesnt actually matter what they are redeemed or listed in... could be bitcoin
15:06 < gmaxwell> adam3us: if we had USD coins then I'd expect every major corporation to just run its own stock servers (or at least contract to people to do it for them)
15:07 < adam3us> gmaxwell: irrevocability and the above story about ripple implications of court case
15:07 < adam3us> gmaxwell: if a server has a database (the double spend db) it can get shutdown
15:08 < adam3us> OT receipts help but i am not sure its as robust as a block chain, and also it can be undone
15:08 < gmaxwell> adam3us: consider colored coin vs external ledger and cross chain trades.   In either case you can order IBM to not honor certan shares, or to redeem for a different party than the keys imply.
15:08 < gmaxwell> In either case the bitcoin side is irreversable.
15:08 < adam3us> eg basically what makes OT secure is that the users have receipts so if a court made all OT servers do something unpopular they could form a p2p network filled with the receipts and resume
15:09 < gmaxwell> adam3us: but doing that is worthless for shares of IBM if IBM isn't going to honor or pay dividends to those share holders.
15:09 < gmaxwell> Empty victory.
15:09 < adam3us> gmaxwell: if they are properly fungible i do not think they can order IBM to do anything
15:09 < BlueMatt> adam3us: yes they can...
15:09 < gmaxwell> adam3us: so explain how colored coins can be properly fungable in a way that IBM can't cut through?
15:10 < adam3us> gmaxwell: because tehy do not know hwo the owner of the share is
15:10 < BlueMatt> you can jump up and down all day in front of a judge and say "but...but...thats not possible"
15:10 < BlueMatt> and they will just say, "ok, make it possible"
15:10 < adam3us> BlueMatt: yes thats why central severs are bad and block  chains are good
15:10 < gmaxwell> ...
15:10 < gmaxwell> again, please, tell me how its possible to do this with colored coins?
15:10 < adam3us> gmaxwell: say zerocoin
15:11 < maaku> adam3us: the problem isn't the chain/server, it's the issuer
15:11 < adam3us> gmaxwell: i'm not even saying coloring coins (literally) is a good idea, i'm just saying that a transaction layer anonymous (fully fungible) system can not discriminate at the issuer redemption point
15:11 < gmaxwell> adam3us: great and if zc were implemented as described the coin color wouldn't traverse the zc.
15:12 < gmaxwell> adam3us: okay, well I can't argue with a non-specific system. There may be some way to do it.. but the colored coin stuff people talk about does not accomplish it. As far as I can tell it's not a useful tradeoff over issuer ledger with cross chain trades.
15:12 < maaku> gmaxwell: you could have per-asset zc accumulators, no?
15:12 < adam3us> gmaxwell: dont attach to much to coloring as a process, if you had moderately efficient zc, you can extend it like brands so there are ibm coins and usd coins and bitcoin zcs
15:12 < maaku> ok that's not "as described"
15:12 < gmaxwell> maaku: it's not as described. :P
15:13 < adam3us> so my point is (about why fungibility and fairly immediate final settlement is important) that if you let courts get into canceling and undoing transactions it introduces dispute costs into the trasction layer and you ahve no improvemnt over the status quo
15:14 < adam3us> they can still do their dispute resolution, just their job is to identify the party who commited the theft and demand he reimburses the victim
15:14 < gmaxwell> adam3us: I agree with that advantage only where it actually exists. Eg.  yea the ledger has that weakness but so does _every_ colored coin system which I've ever seen described in detail.
15:14 < adam3us> you no more want the court undoing transactoins than you want the convenience store heist to result in usd paper in your wallet to be seized 10 tranactions later
15:14 < gmaxwell> And yea sure, if you postulate a system which doesn't have that problem then I revoke my complaint, there would actually be a reason to use that one vs issuer ledgers.
15:15 < gmaxwell> But where are the proposals for those systems? :P
15:15 < adam3us> gmaxwell: ok ok yes; i am eaning on idealized ecash system property which bitcoin does not currently robustly have
15:15 < BlueMatt> gmaxwell: except for the insane overhead of running your own ledger if you just want to issue some bond...contracting out the ledger without contracting out the issuance is actually quite nice
15:15 < BlueMatt> same with running your own chain
15:16 < gmaxwell> adam3us: fair enough, though it makes my other arguements stronger. e.g. ZC is hundreds of times less scalable than bitcoin * global blockchain = yuck.
15:16 < adam3us> gmaxwell: i think all agree that bitcoin should have that property as fast as we can figure out how to do it, viz coinjoin, coniswap, mixes, zc, committed tx, homomorphic encrypted value etc
15:16 < gmaxwell> yes, bitcoin should be ecash, ideally.
15:16 < adam3us> gmaxwell: alright lets do it then :)
15:17 < adam3us> gmaxwell: btw i saw you made the same argument i did in one bct thread that fungibility is orthogonal to identitytracebaliliy/etc
15:17 < maaku> you could do straight chaum or inefficient zc on a private server though (OT or Freimarkets)
15:17 < maaku> that's one advantage over doing IBM shares on the public chain
15:18 < adam3us> maaku:  this is true, and chris odom has chaum, and expressed an interest in homomorphic encrypted values (if i would get off my butt and implement the protocol) and brands also likewise
15:18 < gmaxwell> maaku: yea I almost argued that a moment ago, but I'm contemplating the court arguing IBM to rewind the entire state. Of course they could do that to bitcoin to... E.g. snapshot the ZC accumulators for IBM coins as of height=12345 and now all IBM shares are offnet.
15:19 < gmaxwell> If it's really blinded to ibm, then I think you get most of the advantage of non-revokablity (because it would create a disaster of doublespending) without requiring a global consensus network to create non-revokablity.
15:19 < gmaxwell> The non-revokablity comes from it being a suicide pact not the pow.
15:19 < adam3us> gmaxwell: i dont know that the court really need to go there, i think its better if the parties can be identified (eg by each other with proof) and the court can tell the guy who ripped the other guy to reimburse him
15:20 < adam3us> gmaxwell: after all there is currently not much bank note serial number blocking
15:20 < gmaxwell> I assumed we didn't exploit serial numbers more because we don't want to ruin fungiblity.
15:21 < gmaxwell> the obvious thing to do would be to catch counterfeit bills, by making serial numbers digital signatures and having banks announce ID's in their possession .. but as soon as we do, the USD would be unsafe to accept.
15:21 < adam3us> gmaxwell: (i mean in the paper usd analog, when they have rcrimes they go after criminals, not after tracking down the individual notes an seizing off the current innocent owners under "receiving stolen property" rules)
15:21 < gmaxwell> adam3us: right, I understand.
15:21 < maaku> gmaxwell: i always assumed banks did this behind the scenes...
15:22 < gmaxwell> maaku: no, you know they don't because you've never heard of someone getting @#$#@ due to accepting a superdollar.
15:22 < gmaxwell> If they are they're silent about it and not making the customers eat it.
15:23 < adam3us> gmaxwell, maaku: they dont want to dent confidence in fiat, its a fragile confidence bubble with no underlying value, apparently when the deflate, historically they are almost impossible to reinflate without going back to eg gold backing and then weaning off slowly)
15:23 < maaku> i mean, if I was DHS I would make every atm or teller counting machine scan the serial number and submit it with tx info
15:23 < maaku> i just assume, operationally, that is what they're doing
15:23 < adam3us> maaku: yes but whats the point.. no criminal is ever going to pay their note direct to a bank or atm deposit
15:24 < gmaxwell> yea, it's probably a safe "paranoid" assumption.
15:24 < gmaxwell> I don't know if its true but it could start at any time.
15:24 < maaku> adam3us: yeah, but if you had this info for every piece of paper that enters a bank, you can detect flow of money, deduce drug routes, etc.
15:24 < adam3us> maaku: they might track it and ask people, if there is something unique to try track down a forgery ring, but generally its hard, a shops cashdrawer is like a digital mix, they have no idea
15:25 < adam3us> maaku: oh sure they probably log and scan the crap out of it, but they're not breaking fungibility
15:25 < maaku> not with real bills, but they do reject counterfits
15:25 < gmaxwell> maaku: well, only bad ones.
15:26 < adam3us> gmaxwell: so back to your comment above that most of this can be done by IBM operating their own double-spend db, online, and be done with it (with chaum for fungibility)
15:26 < gmaxwell> maaku: rejecting counterfits that a careful shopkeeper could also reject doesn't break fungibility.
15:26 < gmaxwell> Rejecting ones that can only be detected with trusted online read/write access to a bank database would.
15:27 < adam3us> gmaxwell: one diff is ibm is central and could get their db hacked, the same way various bitcoin business had bitcoi thefts or ownership database modifiction
15:28 < adam3us> though they could append only write once log everything, if its fungible thats still a problem as you dont know which tx to accept after fixing the db
15:28 < gmaxwell> adam3us: imagine what IBM runs is a private fork of bitcoin with ZC, a seperate network.. and instead of POW they use IBM signed blocks and WORM media.
15:28 < adam3us> hmm maybe you could think of the block chain as a distributed secured append only double spend implementation
15:28 < maaku> adam3us: OT or OT-like private accounting servers would prevent this - every affected participant would know that the server reversed it's state
15:29 < adam3us> gmaxwell: its not bad, while they can undo things, they cant usefully udo them because of the blinding anonymity based fungibility
15:32 < adam3us> it does mean ibm has to be online and be involved in every trade of ibm for usd, or btc.
15:32 < adam3us> as you cant securely transfer without their confirmation of non-double spent status
15:33 < adam3us> maaku: they may know but what are they going to do about it? i presume the OT argument is to instantiate a new OT server, repopulate it with their combined logs and start with a new key
15:35 < adam3us> gmaxwell: i think another diff is the central server approach has full control and sets its own rules and can change them at any time
15:36 < adam3us> gmaxwell: eg with blockchain, there could be a smart-issueing-contract n a share, that says they cant issue more without 25% share holder approval, they cant do a share buy back without similar, and the approval is validating the amount; in this way the issuer is relatively powerless and has to behave within its contract
15:36 < gmaxwell> adam3us: yes, but I think thats true even using bitcoin since ultimately IBM controls the redeeming. e.g. "We're gonna go issue new shares over here, too bad for you guys that don't agree, since we're paying out the dividends"
15:37 < adam3us> gmaxwell: also redemption is a mini-buy back, so if those are allowed they would be required to prove posession and to prove destruction
15:38 < adam3us> gmaxwell: yes while the details are hazy at this point, i think where this is heading is like a scrupulously honest, uninfluenceable virtual bot enforcing as much of the companies stock rules and finances as can be coded
15:39 < adam3us> gmaxwell: except that as its block chai validated it is the down stream recipients that validate and reject if the terms were not followed, so th epotential to apply the smart-contract apriori enforcement can cover more and more of financial function
15:40 < adam3us> gmaxwell: ie the profits are mathematically defined, and the dividend voted on, and the company cant override the agreed rules for dividen issue
15:41 < adam3us> gmaxwell: and no one would pay an address for IBM not covered by its company contract, as they'd know there would be elevated risk the company execs would line their pockets iwthout shareholder and board approval
15:43 < gmaxwell> adam3us: but then you're demanding that every single fininacal transaction ibm engage in be globally visible. every hardware purchase, every paycheck, every invoice.
15:43 < gmaxwell> "uhh"
15:44 < adam3us> gmaxwell: dont forget about homomorphic encrypted value for commercial confidentiality
15:44 < gmaxwell> And of course they could just say that they're going to be issuing against this seperate account and please pay to it, because they won't ship you your hardware if you don't do as they say. Who's going to argue with that.
15:44 < gmaxwell> just seeing the volume of transactions in total is a big confidentality leak...
15:44 < adam3us> gmaxwell: i am not saying anyone can try to do all that now i am sayig i thnk that is the future for fiancial networks, putting mre and more of it under apriori rule enforcement to reduce systemic risk
15:45 < adam3us> gmaxwell: encryoted value, it has to happen, bitcoin is not suitable for commercial confidentiality (or even private confidentiality - a few people get paid in bitcoin it leaks far too much)
15:46 < gmaxwell> adam3us: okay sure. Every layer of this you add though you move it further away from something which even sounds remotely pratically achievable today. I'm happy to move in that direction, but one of the reasons I think cypherpunk vision failed almost completely in round one (save for keeping strong crypto from being outlawed) is because the bridge building failed. I'm happy to think one or two steps a head, but I think you're going ...
15:46 < gmaxwell> ... too far for me to care. :)  I just want fungible flexible highly trustworthy ecash. :)
15:47 < adam3us> gmaxwell: sure, step 1 fungibility
15:47 < adam3us> step 2 maybe distributed security for share issues
15:48 < adam3us> DBC (colored coins, though not necessarily using coloring nor bitcoin nominal value payments)
15:48 < gmaxwell> (and, as an aside, I'm worried about fungiblity measures in bitcoin being politically difficult if we don't get them in fast... e.g. if we get norms around blacklisting naughty coins and such, then any fungiblity measure will be a tool of evil.)
15:49 < adam3us> mostly explaining why i think it matters to have bearer and distributed enforcement for stocks, often the directoin things take is a side effect of interim decisions
15:50 < adam3us> gmaxwell: yes... i was starting to think maybe i am missing some aspect of committed tx, maybe committed tx plus more efficient homomorphic value, can do something interesting zc ike but without the overhead
15:50 < gmaxwell> well there are ways to do ZC with reduced overhead.
15:50 < adam3us> gmaxwell: ie dont check the inputs match the outputs, check all inputs add to all outputs
15:50 < gmaxwell> but uh  you might not like the security tradeoffs. :P
15:50 < adam3us> gmaxwell: ok that'll work too :
15:50 < adam3us> oh
15:51 < adam3us> gmaxwell: i had one more idea too but i didnt crack the crypto yet, to make a blind proof of work
15:52 < adam3us> gmaxwell: then you can prove your tx is confirmed, the depth of the confirmation, that it adds up (encypted value) basicall bitcoin in zero knowledge!
15:52 < amiller> the blind proof of work still has pretty unclear benefit even if you just assume abstractly you have free ZK
15:52 < maaku> the ZC bloat is in the scriptSig though, right?
15:52 < gmaxwell> for example, there is a pairing crypto way to do the accumulators which is much more space efficient. :P  There is also a fiat-shamir way where you can use the blockhash to do a cut-and-choose to compress your proof.
15:53 < adam3us> gmaxwell: zc uses fiat shamir transform in their cut-and-choose already right
15:53 < gmaxwell> maaku: not only, you need to have a growing anti-doublespend list.
15:53 < gmaxwell> adam3us: I know, but I'm pointing out that you can use the blockchain to compress it further. :P
15:53 < maaku> o_O !!
15:53 < adam3us> gmaxwell: ok, every bit helps
15:53  * maaku goes to read the paper, finally
15:53 < adam3us> gmaxwell: feel free to write that up sometime on bct
15:54 < gmaxwell> I did. uh, in some random thread.
15:55 < gmaxwell> The point is that you can do an interactive hashtree proof where you interact with the network. E.g. you give the miner a big proof, and the block hash tells it how to subset the proof. Because the block hash requires 2^lots work, creating a false proof is at least as expensive as mining many blocks and throwing them away.
15:55 < adam3us> amiller: point of blind pow is you could then prove in zero knowledge that your transaction is validated
15:56 < adam3us> amiller: its not enough by itself, lots of other detail level issues arise but its an interesting direction towards fungibility motivated anonymity
15:57 < adam3us> amiller: but its kind of moot so far as i cant seem to make an efficiently verifiable blind proof of work
15:57 < gmaxwell> the weird thing about my blockhash stuff is that in the common models of analyizing the security of fiat-shamir it adds nothing, because you normally assume that taking the proof commitment and turning it into random validation queries is O(1).
15:57 < maaku> "and check that S does not appear in any previous transaction" <-- I see.
15:58 < maaku> I somehow missed that before. So space wise this isn't actually an improvement over straight chaum ecash, is it?
15:58 < gmaxwell> maaku: yea, so if you don't want it to suck you have to have lifetime limits on ZC pools.
15:58 < gmaxwell> (so you could 'prune' off the anti-replay lists)
15:59 < gmaxwell> the network could also potentially outsource the anti-replay list storage by storing them in trees and having update proofs for them with the transactions.
15:59 < gmaxwell> which then makes the system more like PT's MMR-coin stuff, conceptually.
15:59 < adam3us> gmaxwell: interesting, seems to be somewhat related to the merkle pow for reduced variance
16:02 < gmaxwell> https://bitcointalk.org/index.php?topic=284194.0  < I mention it as a throwaway comment at the bottom here.
16:03 < gmaxwell> though I wrote it up on a long PM conversation with iddo. (I was suggesting it in the context of improving the scalablity of the SCIP stuff based on the locally checkable code stuff.)
16:08 < gmaxwell> (basically in that post I show how to make cut-and-choose random encrypted shuffles use log(security) bandwidth, and then point out that you can do the block hash thing because I thought I should put the idea out in public in case some shithead comes along and tried patenting it :P )
17:06 < jtimon> gmaxwell adam3us I still fail to see why traceability implies revocability
17:07 < jtimon> even with centralized redemption, I don't see how IBM shares are more revocable than bitcoins
17:08 < jtimon> basic colored coins do not provide support for KYC compliance
17:08 < gmaxwell> jtimon: because IBM can be ordered to ignore shares tracable from some point, and to credit some other shares instead.  You can trade these shares still, but without IBMs future support they only have novelty value. :P
17:09 < jtimon> but why would be IBM be ordered to break his contract?
17:09 < maaku> jtimon: legal pressure
17:09 < jtimon> I don't see the example
17:10 < maaku> maybe response to theft, trying to reverse a ponzi scheme, etc.
17:10 < jtimon> so Bob steals from Alice and sells to Carol, who sells to David...why should Z be punished for Bob's crime?
17:12 < jtimon> I'm assuming non-authorized assets where the the issuer doesn't knows the bearers identity
17:12 < Luke-Jr> gmaxwell: how about this argument: if IBM runs its own stock exchange, it needs to make sure only licensed investors buy in; with coloured coins, supposedly there is no way to require IBM to do this
17:13 < jtimon> Luke-Jr freimarkets supports KYC compliance, but it's of course optional
17:14 < Luke-Jr> KYC isn't related to this
17:15 < Luke-Jr> this is "if Joe isn't a licensed investor, he is not allowed to purchase shares"
17:15 < jtimon> well, by authorized assets I mean all those limitations
17:16 < jtimon> a closed list of licensed investors is the same as a closed list of authorized users (previously identified by the issuer)
17:16 < Luke-Jr> anyhow, it's silly to do this with a public blockchain
17:16 < jtimon> the way we do it is actually pretty stupid but very flexible
17:17 < Luke-Jr> as long as people are complying with the restrictions anyway, they should just host their own stock registry
17:17 < jtimon> require an "authorizer" to sign all transactions including that asset (but yes, it's stupid in almost all cases)
17:18 < jtimon> yes, if you're going to sign everything, the only reason not to run your own off-chain ledger is to provide more transparency
17:19 < jtimon> I know a local currency designer that needs this, although I don't think his "100% transpoarent currency" is a good idea
17:20 < maaku> Luke-Jr: I agree it's stupid, but it's something people ask for, to achieve regulatory compliance...
17:20 < Luke-Jr> maaku: using a blockchain instead of hosting it at the company, does not help regulatory compliance
17:20 < Luke-Jr> you can disclose your private "blockchain" if you want transparency
17:21 < maaku> ? no i meant the KYC/authorized accounts
17:21 < jtimon> would bitstamp be issuing in ripple if they didn't had a non-scalable version of this?
17:21 < maaku> doesn't matter if it's on public chain or private server
17:21 < maaku> as to using the public chain for asset issuance, i see very limited uses for that
17:22 < jtimon> the most obvious one are small issuers who can't run their own server and don't want to trust a server
17:22 < jtimon> but shares is also interesting
17:23 < jtimon> are
17:23 < jtimon> even if redeption is centralized, there's zero trust in accounting and exchange
17:24 < maaku> IBM, for example, would probably contract out to another company that handles hosting the gateway exchange and KYC compliance (making sure transactions only involve registered securities professionals, etc.)
17:24 < jtimon> of course we agree that most of the volume will be off-chain
17:24 < maaku> hopefully the law will change to be more bearer-instrument friendly, but until then...
17:25 < jtimon> until then maybe there's companies smaller than IBM and in other jurisdictions that can just issue shares without KYC
17:26 < maaku> yeah maybe we can start a movement for bitcoin startups in St Vincent and the Grenadines, as they have favorable laws towards bearer assets
17:26 < jtimon> but still IBM can be KYC compliant, I just don't think will be the most common case for in-chain assets
17:27 < maaku> but definately common for private servers, especially where convertible currencies are involved
17:28 < jtimon> what I still don't understand are adam3us and gmaxwell worries on "pseudonimously held" in-chain assets
17:29 < jtimon> I don't see the need for full anonimity in bitcoin itself, "user-defined anonymity" seems ideal to me
17:30 < maaku> jtimon: the issue is certain coins being marked as 'dirty' and black listed
17:31 < maaku> if you allow this to happen, it's a very slippary slope to full centralized, KYC control over bitcoin
17:32 < jtimon> but that doesn't makes much sense
17:32 < jtimon> who's going to maintain the centralized list of dirty coins?
17:32 < maaku> Financial regulators
17:33 < jtimon> and what happens to me if I spend those dirty coins?
17:33 < adam3us> jtimon: you need in my view the transaction layer to offer final settlement otherewise legal disputes increase costs and we're back to status quo
17:34 < adam3us> jtimon: but that doesnt mean anonymous, you can attach KYC info outside the fungible bearer certificate
17:34 < maaku> jtimon: good for you if you can actually get rid of them. but the point is that *everyone* will be checking this list of dirty coins to make sure they're not receving anything tainted
17:34 < jtimon> if the bearer contract says that a chain transfer is final after 3 blocks, then is final after 3 blocks
17:34 < adam3us> jtimon: only if its block chain hardened
17:35 < adam3us> jtimon: otherwise a judge can come in and say that malware share hack, all those have to be undone
17:35 < adam3us> jtimon: and any consensus system will have to obey the judges in their jurisdiction
17:35 < jtimon> that's impossible
17:35 < adam3us> jtimon: i view it as the analog of why credit cards have high fees and why banks have high wire fees etc
17:35 < maaku> adam3us: well, widely deployed coinjoin woudl be sufficient too, right?
17:36 < adam3us> maaku: sure, the main point is it is defacto impossible to undo because you cant tell you are punishing the right person
17:36 < jtimon> the judge can't just say, "hey, Bob, undo the last 1400 bitcoin blocks where you stole the IBM shares from alice"
17:37 < adam3us> maaku, jtimon: but it is orthogonal to identity, pseudonymity, privacy (say every knows everyone they interact with and can prove it btu the block chain doesnt see it) etc
17:37 < adam3us> jtimon: right thats good, the bad part is when they got to the OT server and undo the share
17:37 < jtimon> if privacy is possible, full traceability is not
17:38 < adam3us> jtimon: maybe not enogh assurance.. courts are very fuzzy, if there is a common sense argument as it being obvious who it was, they'll do it anywy
17:38 < adam3us> jtimon: i think privacy has to be near uniform ideally
17:38 < adam3us> jtimon: with identity added back on top as needed
17:39 < adam3us> jtimon: so you can prove who ripped you off, take them to court, and get a decision requiring them to reimburse you; but not get the court to find the actual share and give it back
17:39 < jtimon> but the thieft is the one responsible for the crime, not the person currently holding the coin
17:39 < jtimon> exactly
17:40 < jtimon> how that's not possible with the current input/output system?
17:40 < gmaxwell> Luke-Jr: I don't know that it matters, tracable = censorable. They can refuse to acknoweldge any share that hasn't had its whole history through KYC.
17:40 < adam3us> jtimon: yes, but we are not sure courts will care about that distinction, logical though it is, hence eg bitcoin fungibility worries from taint tracing, maybe a thief victim sues someone with deep pockets (gox) to get back their stolen "digital stamp collectible" from gox under handling stolen property rules
17:40 < adam3us> gmaxwell: yes and that could happen
17:40 < Luke-Jr> maaku: whenever it doesn't matter between public/shared or private, private is always the better option
17:41 < adam3us> gmaxwell: so i think give them the kyc, have opacity (privacy, but kyc inside provable by user), but have fungibility level anonymity of the bearer asset people are attaching the required KYC to
17:42 < jtimon> but with private the accountant (the server) has full control
17:42 < jtimon> with in-chain assets they only have control over issuance and redeption
17:43 < adam3us> jtimon: well one argument gmaxwell made above i that there were a few bitcoin related share issuing/trading compnies over the few years that were shutdown or disappeared leaving customers with claims on a nn-existant server
17:44 < adam3us> so it seems minimally necessary for the bearer asset/share to survive a transaction server shutdown
17:44 < jtimon> yes, scams will be possible under any system
17:44 < jtimon> I'm just talking about cheaper auditing
17:44 < adam3us> jtimon: i dont really mean scams, just that if the server shuts down for some reason
17:45 < adam3us> jtimon: you want your shares in the companies that were trading on it to persist and be tradeable and accountable afterwars
17:45 < maaku> jtimon: GLBSE being the example
17:46 < jtimon> that's a reason to better use colored coins for it, no?
17:46 < jtimon> there's no "accountant", the chain is the accountant
17:46 < gmaxwell> jtimon: dude, a chain is _far_ from free.
17:46 < adam3us> yes i guess thogh we should separate the term colored coins because its a mechanism (and maybe not the best one) to achieve bearer assets
17:46 < jtimon> with GLBSE you had to trust both issuer and accountant
17:46 < gmaxwell> It's basically the most expensive account system to ever be imagined, it actually sounds like a joke until you reason out that it can work at least at some scales.
17:47 < jtimon> ok, p2p bearer assets
17:47 < adam3us> i think you probably can use a side chain or something to spare bitcoin the volume of nominal value transactions which it badly does not need
17:47 < adam3us> jtimon: yes good name
17:47 < jtimon> or just in-chain assets
17:48 < adam3us> jtimon: so maaku was discussing above about using OT servers
17:48 < adam3us> jtimon: however while there are receipts and users can switch to another server, its still quite centralized
17:48 < maaku> adam3us: well really I advocate for Freimarkets' private accounting servers, but OT is better understood to this crowd
17:48 < jtimon> gmaxwell, in-chain assets can be far more scalable than current colored coins
17:48 < adam3us> jtimon: and the threat is basically if the system degrades the users migrate to a chain i suppose instatiated with the receipt history
17:49 < jtimon> I don't like OT much
17:49 < adam3us> maaku: (yes i hae some reading to catch up on, i dont mean to focus on OT, just i did not yet read the paper you published some time back)
17:50 < jtimon> OT assets are not atomically tradeable for in-chain assets, or even assets in other OT servers, for that matter
17:50 < adam3us> jtimon: in chain do u mean an altcoin with p2p assets on it? like a bitcoin extension that includes the asset issuer signature rather than mining evidence
17:50 < jtimon> yes, basically that
17:51 < jtimon> no
17:51 < jtimon> I mean, yes, the asset issuer signature is only required at issuance
17:51 < adam3us> jtimon: but that meets gmaxwell point that chains so far dont scale that far
17:51 < adam3us> jtimon: (yes)
17:52 < gmaxwell> jtimon: almost anything with script as powerful as bitcoin can be near atomically traded with bitcoin.
17:52 < jtimon> we could have bigger blocks
17:52 < adam3us> jtimon: at least while retaining their p2p nature (bandwidth too high if 1GB block eg)
17:52 < gmaxwell> jtimon: https://bitcointalk.org/index.php?topic=321228.0
17:52 < gmaxwell> (this works just as well when the endpoints are on different cryptocurrencies)
17:52 < adam3us> thats 23mbit symmetric i have nice internet in malta 100mbit/4mbit up but even i cant do that
17:52 < jtimon> yes, you cannot run NASDAQ on a p2p chain, I know
17:53 < maaku> adam3us: it's the consensus algorithm that doesn't scale, not the block chain datastructre itself
17:53 < adam3us> maaku: ok
17:54 < gmaxwell> jtimon: we could have bigger blocks  < this isn't a free choice. There is a direct tradeoff with decenteralization.  Since the chain has grown from 2GB to 14GB we've gone from around 40k reachable nodes to closer to 4000 reliable reachable nodes (actually there was an uptick in the last week, presumably due to the market activity, but we'll see how it settles)
17:54 < jtimon> we have problems to solve that we won't have in the future
17:54 < maaku> just pushing transactions through a beefy central server could easily handle 1000's of transactions per second, even with checkpoints and secondary replication, etc.
17:54 < adam3us> i think actually (in exploring what could change about bitcoin validation) some of the design decisions arise from supporting SPV
17:54 < gmaxwell> So yea sure, we could have bigger blocks but beyond some point it comes at a _direct_ expense of decenteralization. If the goal to not use something like OT was because of better decenteralization .. then thats counterproductive.
17:54 < jtimon> we don't need to download the whole chain
17:55 < adam3us> gmaxwell: agree, if that happens we have swift 2.0, and the miners will be public companies, they'd just as well sign paper contracts and stop mining
17:56 < gmaxwell> jtimon: if you don't download the whole chain then miners participants in the past before you joined could have cheated and freely written themselves blank checks. Its very nice today that when people ask about this (which they frequently do) I can give them a very strong answer: No, your software audits against that, and you can audit its code (or have someone else do so) to make sure that it does.
17:56 < adam3us> gmaxwell: committed tx would be your only remaining defense against policy, you can still do a few things, notice when they make changes etc, but with less power to do anything about it
17:56 < maaku> gmaxwell: our approach is to move more transactions off-chain onto private servers, and use the public concensus mechanism only when necessary (e.g. cross-server trade)
17:57 < gmaxwell> adam3us: sipa has a great argument that goes: At one extreme blocks are maximally small and no one can transact but everyone can validate and so the system is centeralized because so few can transact. At the other extreme the blocks are enormous and everyone can transact but no one can validate, so the system is again centeralized because we must trust the few validators.  The ideal behavior is somewhere in between.
17:57 < adam3us> maaku: in a way thats mirroring bitcoin activity, most mtgox,bitstamp trades are in server
17:58 < adam3us> gmaxwell: sounds like sipa's block chain triangle:)
17:58 < maaku> adam3us: yes, but we'd like to do it in a way where your 'off-chain wallet' contains similar security gurantees - server can't spend your coins without your sig, and any modification of the spend history is detectable, etc.
17:58 < jtimon> gmaxwell, with maaku's UTXO index hashed on every block, it's just a matter of how long in the past you want to go
17:58 < gmaxwell> Sipa Circumflex of Centeralization.
17:59 < jtimon> back to genesis? to the last checkpoint?
17:59 < maaku> similar to OT in that regard, but using bitcoin structures for interoperability
17:59 < gmaxwell> jtimon: allow me to be offended while you lecture one of the first people to suggest committed utxo on the subject of them...
17:59 < adam3us> maaku: i agree its the holy grail of off chain transactions " we'd like to do it in a way where your 'off-chain wallet' contains similar security gurantees - server can't spend your coins without your sig, and any modification of the spend history is detectable, etc."
18:00 < maaku> ok well read the paper and give us your feedback
18:00 < gmaxwell> jtimon: regardless not validating the rules is a break in the security model, and its one that may have weird interactions with incentives. Today a miner that does a bit reorg can only reorder transactions, in an enviroment where many nodes don't validate deeply, they can write themselves a blank check.
18:01 < maaku> we're implicitly assuming some form of tx commitment though (not mentioned in the paper), which is the source of some of the security protections
18:01 < adam3us> maaku: not saying i have a solution, though like presumably many others its occupied my thoughts for some time
18:01 < gmaxwell> This isn't to say that its not a good tradeoff, but its not clear that its a free one.
18:01 < jtimon> sorry, gmaxwell, and yes, I've heard that potential problem, I think from retep
18:02 < adam3us> maaku: on loose idea is to use the bitcoin block chain to timestamp the merkle root of the offchain servers transaction log
18:02 < gmaxwell> I suppose its a change which actually could be made in bitcoin because basically none of the users have a mental model of the security that makes any sense... though its kinda sad that it wouldn't be controversial to revise the security model in such a substantial way.
18:04 < adam3us> gmaxwell: i'm with you on this one, the assurances of immutability are the strongest feature of bitcoin
18:04 < jtimon> the way I see it, it's configurable security, you can still be a full node, miners should be prepeared for very big reorgs
18:04 < gmaxwell> jtimon: moral hazard.
18:04 < gmaxwell> If you're in a minority you're actually worse off setting security higher than other people.
18:05 < jtimon> I see
18:05 < gmaxwell> And if you can reduce your costs and let some other sucker take the work of making the security promises good? oh well.
18:05 < gmaxwell> (worse off because it's a consensus system: it's often more important to agree than to be right…)
18:05 < maaku> ... which is why i'm staunchly against probabalistic validation
18:06 < gmaxwell> maaku: if its over old history that you wouldn't have validated anyways? and your response it to just shut down and nag the user?  I don't worry about that. It's just a backstop that means that manual intervention would kill an attack that depended on a historical rule validation.
18:06 < adam3us> gmaxwell: agree vs right; I agree: it seems to me that other than SPV, miners could indirectly facilitate consistent distributed arbitration of a random decision, so long as its immutable
18:06 < gmaxwell> Likewise, the fraud notices stuff would make probablistic validation not a consensus risk. ... (though a software engineering risk... :( )
18:08 < adam3us> gmaxwell: just based on timestamping, no other validation; full node users could do committed tx fine with that assumption
18:09 < adam3us> if there is a way to shard activity within a timestamp tree, you might be able to scale that further than a miner validated blockchain (the miners in this model would just be timestamping merkle roots)
18:10 < jtimon> so you just timestamp things and the validation comes later, no?
18:10 < gmaxwell> maaku: the other question is: if your choice is "only google does the validation" vs "lots of parties do probabalistic validation with some risk of consensus failure" I don't think that it's a hard decision. There are lots of nice centeralized systems out there, I don't think bitcoin is really competition for them.  And I do think in the long run some compromises will be the matter of effectively centeralizing the whole ball of wax ...
18:10 < gmaxwell> ... or not.
18:10 < gmaxwell> adam3us: the incentive model is goofed up though if unfaithful validation doesn't make your 'work' wasted.
18:11 < gmaxwell> e.g. say it's constructed so you could timestamp multiple orthorgonal consensuses ... you might as well timestamp a zillion of them just in case one is preferred over another.
18:11 < gmaxwell> (this is the problem proof of stake has)
18:12 < adam3us> jtimon: yes committed tx are validated by users (including full tx history) and in this timestamping only use of it peers would need to be full nodes, but maybe it can be sharded to eg freimarket servers for the merkle root
18:14 < jtimon> it reminds me to a "crap serializer" idea I had, but mine was centralized
18:14 < adam3us> gmaxwell: so the hypothetical would be have lots of OT like servers as supernodes (but still peers) they participate in the timestamp consensus
18:14 < jtimon> how do you agree on the p2p serialization? do you have a thread?
18:15 < adam3us> gmaxwell: users transact on a given server with receipts, if anything goes wrong they switch servers; the server cant undo things because its transaction merkle root is timestamped
18:17 < gmaxwell> adam3us: how do you prevent supply doubling where users clone themselves and start transacting on two servers in parallel?
18:17 < adam3us> users, servers audit other servers ot be sure they never put conflicting statements in their tx tree
18:20 < adam3us> gmaxwell: possibly (or so i was loosely thinking) each asset has a home server that is the authority on ordering transactions involving it - the idea is distributed consensus is hard but individual consensus is trivial, and mining timestamping prevents revisionism, and audit detects problems, and then you need some migration property where you can move the asset to a new home using receipts (but only after timestamp validates the move)
18:21 < adam3us> gmaxwell: say it costs higher fees to move via the timestamp chain to another server, so there is a disincentive to move unless actual problem; and servers cant cheat as they are audited and the system reacts to cheating
18:22 < adam3us> gmaxwell: its basically OT + blockchain timestamping for merkle root timestamping, and reward (coin mining via blockchain timestamping) and to validate the movement of an asset to a new home
18:24 < adam3us> it becomes simpler to change mining details also when it is only doing timestamping eg as its low bandwidth, doesnt deal with 0-confirm ordering, nor validation of transaction details, nor fee collection
18:25 < gmaxwell> adam3us: this is starting to tread into the space I was talking about with the coinwitness stuff (using non-interactive zero knoweldge proofs to delegate coins to external transacript producing systems and eventually pull them back)
18:25 < gmaxwell> transcript*
18:27 < maaku> gmaxwell: I think if we move a lot of things off-chain (including day-to-day payments), and start using the chain mostly for global concensus over multi-server trades, we won't have to scale bitcoin much
18:27 < adam3us> gmaxwell: have to re-read that, while i thoght scip/snark interesting i mentally put it in the 'future crypto' bucket to keep an eye on
18:28 < adam3us> maaku: yes, but a bit of an open question how that can be done while preserving the bitcoin properties
18:28 < maaku> so fears about needing "google-scale" are not yet convincing, imho
18:29 < gmaxwell> maaku: personally I hope so, but that comes with another worry. Say we jack way up the block size, and the things move off to other systems (for things like instant confirmation) ... will bitcoin be able to support itself on fees with the enormous block sizes but most txn off chains? hell— would it be able to support adequate security with fees even with current blocksizes?   Petertodd gave a vision of the future where those ...
18:29 < gmaxwell> ... systems were bonded with mining donations, which might help, but its very murky to me.
18:31 < maaku> gmaxwell: well if most txns don't hit the chain, it's okay for those which do to pay the price
18:31 < maaku> it seems some people want 10,000 tps with <$0.01 txn fees
18:32 < maaku> i'm more in the camp of only slightly larger blocks, with much higher fees
18:32 < maaku> and moving most transactions off-chain (even day-to-day payments - heretical I know)
18:32 < gmaxwell> maaku: yea, indeed. And until we get magical pixie dust computers and networks we cannot do 10,000 tps without losing decenteralization.
18:32 < adam3us> maaku: as long as the properties you get off chain are matching the on chain properties (unseizable, relatively fungible, not relying on indivdual servers, p2p survivabiity and durability of asset ownership)
18:33 < maaku> gmaxwell: also, freicoin. (demurrage payments to miners)
18:33 < adam3us> maaku: it is another model for funding miner.. free tx for the cost of a small demurrage; however it doesnt prevent dust payment spam
18:33 < gmaxwell> maaku: mostly I worry that so long as bitcoin is maxmally decenteralized you can build more scalable systems on top of it. But if bitcoin loses some of its decentralization you cannot build a more decentralized system on top of it.
18:34 < gmaxwell> maaku: the inflation model implies a free parameter which there doesn't seem to be a way to make the system set which could be wildly wrong. ::sigh::
18:35 < gmaxwell> If we knew that processors would never become more powerful or energy more plentiful we could use potentially use hashrate to control inflation to pay for mining... but thats clearly wrong.
18:35 < gmaxwell> I hope at least bitcoin will advance the minimum difficulty over time.
18:37 < gmaxwell> maaku: also one of the biggest concerns is that we're _clearly_ losing decentralization already. I don't this can be debated, but I don't think the causes are as clear as the symptoms.
18:37 < maaku> adam3us: If there was a less expensive solution that had all of those properties, it would completely replace bitcoin. If you find that holy grail, let me know so I can short BTC.
18:37 < maaku> Otherwise, for a given application there are probably one or two of those requirements you can relax in return for some performance.
18:38 < maaku> It won't match all applications, but for yours it will work. And when you really need every single property of bitcoin, use bitcoin.
18:38 < maaku> And pay the cost
18:38 < gmaxwell> e.g. like the tamperresistant hardware that exchanges private keys... security is .. meh. but it works offline and is untracable!
18:38 < adam3us> maaku: well i'm interested in improving bitcoin
18:40 < adam3us> i think there is systemic danger even from the existence of altcoins, not just to bitcoin specifically but to digital scarcity coins in general
18:40 < adam3us> if litecoin overtook bitcoin then what - would bitcoin nosedive to 0?
18:40 < adam3us> and then people in litecoin would be look at feathercoin, novacoi etc and wondering if the same thing is going to happen
18:40 < gmaxwell> adam3us: I agree. Or I'll explain more concretely. I think there is a nontrivial risk that the first time an altcoin replaces bitcoin all decenteralized cryptocoins will substantially die.
18:41 < maaku> You can't extrapolate from an inconsistent assumption.
18:41 < jtimon> gmaxwell, you earier said: The point is that you can do an interactive hashtree proof where you interact with the network. E.g. you give the miner a big proof, and the block hash tells it how to subset the proof. Because the block hash requires 2^lots work, creating a false proof is at least as expensive as mining many blocks and throwing them away.
18:41 < gmaxwell> adam3us: oh you're saying exactly the same thing I am.
18:41 < adam3us> its fun for the people who get in selfishly, but it could be lethal if too succesful individually in a given altcoin
18:41 < maaku> Litecoin won't overtake bitcoin - neither will freicoin, either (I'm not biased!)
18:41 < jtimon> can't this be combined with adam3us's blind timestamping?
18:41 < adam3us> gmaxwell: ah i didnt read your bit, yes we coincidentaly said the same thing
18:42 < maaku> There's just no mechanism that could happen except rich people blindly throwing money away (unlikely)
18:42 < gmaxwell> maaku: Right, but assume Makku-ultimate-coin does. Doesn't matter which one does. Say it does.  Once it does the people holding it are going to wonder .. hey when will something else overtake ... this.
18:42 < gmaxwell> so if it ever happens it could unwind the whole thing.
18:43 < gmaxwell> Though I'm not expressing an opinion on how likely that is to happen, the network effect and first mover advantage are enormous.
18:43 < adam3us> yes sad though it is that no one can again become rich like satoshi
18:43 < gmaxwell> jtimon: perhaps.
18:43 < adam3us> if they try and succeed it maybe the end
18:43 < maaku> gmaxwell: my point is that won't magically happen overnight. if it did happen, it'd be for a specific reason, and that specific reason would determine the answer to the question about what people would do/think next
18:43 < jtimon> on the altcoin stuff, if one falls because a new one is better
18:44 < gmaxwell> maaku: there are lots of ways to improve on bitcoin, as everyone in here knows. :)
18:44 < sipa> i don't think bitcoin will be taken over by anything, until it actually fails
18:44 < jtimon> maybe people learn their lesson and start saving in real assets and credit instead of scarce-money
18:44 < adam3us> jtimon: the issue is the undermining of the concept of scarcity and longevity of the logscale graph heading to market saturation
18:45 < gmaxwell> sipa: I think the question of if something overtakes it at all even after depends on how it fails.
18:45 < jtimon> but that doesn't mean the new one won't have enough value to serve as medium of exchange
18:45 < adam3us> jtimon: it might create destabalization and fundamental loss of confidence in the concept that doesnt reinflate
18:45 < gmaxwell> or maybe not, ... I mean I'm shocked at how scammy things can be and people still participate. perhaps its unstoppable.
18:46 < jtimon> I disagree, maybe because I never considered bitcoin or  any other money to be a store of value
18:46 < adam3us> jtimon: the phenomena is seen historically with money that became fractional, suffered hyperinflation (collapse) and then could not be restarted without going back to gold backing
18:46 < gmaxwell> adam3us: or USD backing. :P
18:47 < adam3us> the bootstrap phase, expectation, and psychology matter;
18:47 < maaku> adam3us: just because something hasn't been done before, doesn't mean it's impossible
18:47 < adam3us> this is the road to the digital tulip story
18:47 < jtimon> I don't think that's true, I think fiat was restarted in germany just with another denomination
18:47 < maaku> but this is probably not an argument for -wizards
18:47 < jtimon> sure
18:47 < sipa> #bitcoin-psychology ?
18:47 < gmaxwell> Interestingly, bitcoin may be the only currency in "widespread" use which isn't at least indirectly tracable to being fixed to gold/silver at some point.
18:48 < adam3us> anyway i am more interested in improving bitcoin than altcoins and they maybe a danger to the concept of digital scarcity
18:48 < adam3us> gmaxwell: yes i think economically its writing history
18:49 < gmaxwell> (the closest I could find was ILS but it was fixed to the israel lira, which was fixed to the ukp, which was fixed to the usd (!), which was previously fixed to gold)
18:49 < adam3us> a new asset class etc, but the potential risk ith digital scarcity is new scarcity runs can be started on whim; thre needs to be a "gold tandard" of scarcity that people do not jump away fro
18:50 < adam3us> so i think altcoins should use the 1 way peg to bitcoin method i proposed for bitcoin-staging, and innovation should go into bitcoin staging
18:50 < jtimon> I don't think altcoins are a danger to digital scarcity and I couldn't disagree more with the need of a "gold standard"
18:50 < adam3us> we have enough dev resource shortage with out fragmenting
18:50 < gmaxwell> adam3us: thats partially why I wanted someone to create an altcoin generator.. basically keep the basin of low value stuff constantly flooded.
18:51 < gmaxwell> and remove the prospect of ever making big money with yet another worthless altcoin.
18:51 < jtimon> what bitcoin "backing" has to do with development fragmentation?
18:51 < adam3us> gmaxwell: well iw as thinking something related that these parm tweaks, surely they can be made to coexist on a meta chain
18:51 < maaku> <adam3us> we have enough dev resource shortage with out fragmenting
18:51 < adam3us> then the people who wnt to do them can just publish a paramset gensis msg
18:51 < gmaxwell> adam3us: the param tweaks are marketing not merit for the most part.
18:51 < maaku> <-- which is why we shouldn't bring currency politics into this
18:52 < adam3us> maaku: not getting t you guys - friecoin and friemarkets aimed for real innovation
18:52 < sipa> s/ie/ei/g
18:52 < adam3us> yes
18:52 < jtimon> I actually don't think freicoin is about innovation but about another monetary theory
18:52 < jtimon> freimarkets is about innovation, but it's not freicoin specific
18:53 < sipa> well, at least they are interesting experiments
18:53 < sipa> whether you agree or disagree with their theory
18:53 < gmaxwell> My comments whining about altcoins are always to the extent that they didn't do anything interesting. Something inflationary is pretty distinct (even if economically its less so than people guess at first).
18:53 < maaku> hrm maybe we shouldn't have named it "freimarkets"
18:53 < sipa> litecoin's scrypt was also an interesting experiment, but we're way past that point
18:53 < adam3us> btw it would be super embarasising if the thing which over took bitcoin if it happened was esentially a lame param tweak
18:53 < gmaxwell> PPC would be interesting to me if it weren't sullied with that stupid block signing.
18:53 < maaku> the pun on "free market" was just too good to pass up
18:54 < maaku> geistgeld, my favorite. 15 second blocks
18:54 < maaku> that actually was useful
18:54 < maaku> and appropriately, now dead
18:54 < gmaxwell> the scrypt expirement ran its coarse and failed as an expirement: It failed its stated goal, and it's had negative side effects (making initial (/spv) sync slow).  Double sad is that many people (myself included) predicted exactly this outcome.
18:54 < adam3us> sipa: yes litecoin main claim was giving gpu miners something to play with when asics came
18:55 < sipa> i wonder, with PPC, can you mine on both branches of a block chain fork at once, without loss?
18:55 < jtimon> wasn't geistgeld the first one with scrypt?
18:55 < gmaxwell> maaku: I liked "liquidcoin" the one with the difficulty set to a fixed level... it rapidly turned into a thousand seperate currencies as nodes could never manage to converge.
18:55 < adam3us> sipa: well even that was unintended if i caught up correctly it aimed for cpu preference and failed, luckily for it asics came along
18:56 < gmaxwell> sipa: with PoS you can indeed, thats why PoS is sad.  PPC arbritrates forks with a special altert message that adds a checkpoint, run by the developer.
18:56 < jtimon> I dream with a SCIP/spark-based pow
18:57 < sipa> gmaxwell: i keep reading "PoS" as "piece of shit"
18:57 < adam3us> he he
18:57 < petertodd> gmaxwell, maaku: working on a paper analyzing profitability of tx fees - results are looking pretty ugly w/ centralizing mining having at best linear improvements in profitability.
18:58 < sipa> gmaxwell: oh, so that is actually why the checkpoints are needed
18:58 < adam3us> gmaxwell: scrypt spv problem being higher hash validation cost?
18:58 < petertodd> gmaxwell, maaku: you can very quickly construct a proof that in any circumstance mining is something where increased hashing power gives you more profits per unit work
18:58 < sipa> gmaxwell: i thought it was to prevent tons of SHA256 power working against it
18:58 < petertodd> gmaxwell, maaku: which we knew... but it looks like under certain circumstances the implications of that are really ugly.
18:58 < gmaxwell> adam3us: no it wasn't, LTC's claim was that it was cpu only (gpu resistant) :P
18:58 < adam3us> gmaxwell: yes i read that
18:59 < sipa> < adam3us> sipa: yes litecoin main claim was giving gpu miners something to play with when asics came    <-- unsure what you mean here
18:59 < gmaxwell> sipa: most of PPC blocks is PoS mining now, the SHA256 difficulty is quite high.
18:59 < adam3us> gmaxwell: "and it's had negative side effects (making initial (/spv) sync slow)." was referring to that ... scrypt spv problem being higher hash validation cost?
18:59 < petertodd> bbl
19:00 < jtimon> the theory now is that ASICs = centralization = less security: I think bitshares offers an "even-harder-to-asic" pow
19:00 < gmaxwell> sipa: the first version of PPC PoS was super vulnerable, by throwing CPU at the POS you could find a path of solutions where your coins were the lucky POS cons for every block.
19:00 < adam3us> sipa: never mind, i just meant that it would've probably died if asic mining hadnt freed up lots of gpus, when its failed attempt to be better on cpu failed
19:00 < sipa> adam3us: ic
19:00 < sipa> adam3us: ironic :)
19:01 < gmaxwell> sipa: they stopped the majority attack by the alert lockins and then did a hardfork to change the PoS so that the stake is selected using POW blocks to prevet that kind of fork and search to favor your own stake.
19:01 < adam3us> sipa: litecoin investors made money from a failure that succeed for random reasons outside of its authors control or expectation
19:02 < gmaxwell> but you can still mine all possible forks, and its rational to do so... you just can't use doing that to make yourself mine all the blocks. :P
19:02 < jtimon> I guess atlantis had a lot to do with ltc success too
19:02 < gmaxwell> (unless you also have a lot of hashpower)
19:02 < adam3us> sipa: but it is kind of interesting that the value of a coin is partly fom the fun that can be had in the act of mining it... if you take away peoples toys by removing gpu mining and asics being hard to get, then thats what happens
19:03 < adam3us> jtimon: atlantis?
19:03 < jtimon> was another silk road that accepted both btc and ltc
19:03 < gmaxwell> adam3us: litecoin mining was really weird for a long time, e.g. it was net unproftable over power for a very long time until GPU mining took off.
19:04 < adam3us> btw i had a look at bitshares protocoin mining run and they very badly screwed their params, but the psychology of the miners on the #protoshares channel was interesting... they mostly didnt understand what it was or why they were mining it, just it was fun, and they were early and getting  discount/jump on a timelimited offer
19:05 < gmaxwell> adam3us: yea, mining all the new things blindly has been at times very profitable.
19:05 < adam3us> (they hard forked their params with no warning to the alarm of users who prepaid for like hosting services on a month basis that bitshares was taking referral commission on)
19:05 < adam3us> i was too late to encourage their users to reject and not upgrade!
19:06 < gmaxwell> adam3us: nothing can compete with with all the crazy stuff solid coin did.
19:06 < adam3us> (they put a message n their site to say you have to upgrde or else, but the threat w incorrect - if the miners revolted that wouldve been the end of th param change plan)
19:06 < gmaxwell> I'm pretty sure you could do a hardfork of a moderately successful altcoin where you just moved half the users balances to yourself, and they'd take it.
19:06 < midnightmagic> gmaxwell: I wonder if that's the anonymous developer who wants to add in all that new stuff to an altcoin fork.
19:06 < jtimon> gmaxwell, do you have more on your interactive hashtree proof besides this thread? https://bitcointalk.org/index.php?topic=284194.0
19:07 < gmaxwell> jtimon: the block cut and choose idea at the bottom is applicable to any fiat shamir style non-interactive proof, it just potentially makes them smaller for a given security level.
19:08 < gmaxwell> midnightmagic: hm?
19:08 < adam3us> gmaxwell: btw about your aside about patent trolls, i did send a mail to the foundation lawyer guy and matonis, and they replied to say yes they were working on a defensive shared patent pool
19:09 < gmaxwell> midnightmagic: realsolid hardly did anything original
19:09 < sipa> he was perhaps the first to use floating point in consensus-critical code :)
19:09 < gmaxwell> adam3us: uhh. that the foundation would own? danger danger. 501(c)(6) assets can be taken in bankrupcy to creditors, and bankrupcy transfers can sever otherwise perpetual licenses.
19:10 < midnightmagic> gmaxwell: The ideas lists were collected from others' hardfork wishlists
19:10 < adam3us> gmaxwell: but yeah i dont know.. i suggested such risks to jgarzik who was on the thread here and he seemed less worried
19:10 < gmaxwell> midnightmagic: well ideas are a dime a dozen, sit down I'll pump out another gross of them for you.
19:10 < midnightmagic> :)
19:10 < adam3us> it seemed to me a risk that the foundation could be legally attacked and the patents seized
19:12 < adam3us> but the current alternative is not fantastic either that each new bitcoin startup probably patents half a dozen defensive things, that sooner or later will get bought by a troll, or sol to a big co that does nothing with it apart from park it in a 5000 patent defensive pool
19:12 < adam3us> it happened with chaums digicash patents, until they expired
19:14 < gmaxwell> adam3us: SFLC considers that kind of risk significant, for codec patents we've used a complicated interlocking scheme with multiple 501(c)(3) (which have special asset disposition rules which prevent them from being taken in a bankrupcy), e.g. mozilla filed patents and then assigned them to Xiph.Org under an agreement controlling the dispostion of the patents should Xiph.Org go away., and we still consider it generally risky as ...
19:14 < gmaxwell> ... opposed to pure defensive publication. (but the risk was necessary because we had to be able to force other potential patent holders to adopt licensing terms we specified and thus needed negotiating leverage)
19:15 < adam3us> i see - maybe you should fwd that to the lawyer guy & matonis
19:15 < gmaxwell> The biggest problem in true defensive patenting is that under current caselaw in the US a bankrupcy court can disolve _any_ licensing agreement, and they do.
19:16 < gmaxwell> (this is also why things like the twitter patent pledge thing are nice in spirit but may not work in practice)
19:16 < adam3us> i was thinking it would be nice to have some way to defnesively avoid patents becoming troll material
19:17 < gmaxwell> the next best idea was to embed trapdoor misconduct in the patent application process, so that our patents were trivally invalidatable but only to us.. uh.. I hope that expresses how hard we considered the process to be. :)
19:17 < adam3us> that bitcoin startups have; maybe they can own them but they revert to the foundation - far out of my depth other than hating patents with a vengence and seeing too many fo them through consulting on crypto for people and wanting to avoid seeing the digicash patent endgame
19:18 < adam3us> if there was a safe way to have  defensive pool, it would be good to have something to pressure bitcoin startups to assign their patents too so they can be forced to be sincere about their defensive plans
19:20 < gmaxwell> Really the best thing to do now is publish publish publish. You can't use defensive patents to negoiate with patent assertion entites in any case, since they only assert, not practice.  Defensive patents are only really useful for a licensing negotiation between parties with remotely equal standing. ... though I know VCs often pressure startups to build patent portfolios ... but I dunno how they'd feel about them being put into a ...
19:20 < gmaxwell> ... general disarming pool.
19:23 < adam3us> gmaxwell: well to my way of thinking they are benefiting from satoshi's work and lots of volunteer effort in developing and innovating bitcoin, which they use for free, and most of the bitcoin startups have no innovation, just deploying things (which is useful, necessary) but its an insult if they then grab biz process patents or patents on permutations of others work
19:24 < gmaxwell> Indeed, but that won't stop people. Most patents are very very incremental.
19:24 < adam3us> gmaxwell: so the community would be easily in its rights to have the foundation frown on tem etc
19:25 < midnightmagic> There are also groups of people who agree, collectively, that jointly-developed technologies or jointly-developed standards can be shared by all members, they disclose their patents, and then sign agreements that the disclosures are full and that they all agree that *if* any of the patents apply to the jointly-developed technology, they won't bring them to bear on any agreement-signers..
19:25 < adam3us> gmaxwell: yes been in enough startups to see the vc, ex-big-co patent hungry people at work, they either dont care, or just want to make money fast, long term consequences be damned
19:26 < gmaxwell> (I actually went as far as writing a provisional patent application for the use of the EC additive homorphism for publicly derivable wallets, but didn't go through with it because there were no other bitcoin relevant applications being filed and didn't consider it worth the risk that it would inspire more bitcoin patenting, etc.)
19:27 < adam3us> gmaxwell: yes.  i expect there are some patents in the dozens of bitcoin related companies already or pending now
19:28 < gmaxwell> At some point someone probably needs to get a patent application on something bitcoin related with a relatively complete description of the system just so it shows up in examiner prior art searches. (they sometimes search the internet ... but uh, it seems pretty rare!)
19:28 < midnightmagic> it would be amusing somehow if some company were awarded some patents on bitcoin core technologies and then they asserted them..
19:29 < gmaxwell> midnightmagic: it's possible, they wouldn't be valid of course... but examiner prior art searches are lame, and the applicant is required to disclose, but often don't (for obvious reasons...)
19:30 < midnightmagic> "clean room" defense.
19:30 < adam3us> midnightmagic: not in a good way though, courts and patents are largely hamfisted idiots, viz the apple/samsung to and fro and product freezes $1b awards, on xor-cursor level patent pool stuff; retardation^n
19:30 < gmaxwell> I suspect if they called it bitcoin in the patent they'd be likely caught. But if they didn't they'd likely get it through.
19:31 < gmaxwell> At least on the core stuff the age of it is unequivocal and digital cash was kind of a dead field in 200x.
19:31 < gmaxwell> There are some patents I'm aware of that probably read on _all_ DSA but are also new enough that they're necessarily invalid if they do.
19:31 < midnightmagic> adam3us: Maybe in a good (but absurd) way because patents have territories and people typically forget Canada exists.
19:32 < midnightmagic> "America's hat"
19:32 < adam3us> ok my turn to sleep
19:32 < midnightmagic> night adam
19:32 < gmaxwell> in any case, this is a much bigger risk for any better-than-bitcoins. .... as they might run afoul of new patents that bitcoin is old enough to be prior art for.
19:34 < midnightmagic> Say, did djb ever reveal the list of patents that NaCL was written to specifically avoid somewhere?
19:34 < midnightmagic> .. can't believe I even feel like I should know that. software patents. urg.
19:34 < gmaxwell> "We are now aware of this issue and we will perform an internal investigation to find out who is responsible for this.
19:34 < gmaxwell> Thank you for pointing out. "
19:35 < gmaxwell> https://bitcointalk.org/index.php?topic=327767.msg3552672#msg3552672
19:35 < gmaxwell> I guess I need to send these guys a christmas card for making me victor of the internet in all those arguments where people told me if a pool was evil miners would notice right away and switch.
19:37 < maaku> gmaxwell: 501c6 only goes bankrupt if its members let it
19:37 < midnightmagic> lazy/crazy?
19:37 < gmaxwell> maaku: it can become bankrupt as a result of litigation, e.g. if its found to have some neigh unbounded liability.
19:37 < midnightmagic> lol
19:38 < maaku> not that it isn't a risk - plaintiff could use the risk of bankruptcy as blackmail to raise settlements
19:39 < gmaxwell> maaku: at least thats less bad, a settlement can't free one from a perpetual patent grant.
19:40 < maaku> i guess my point is if the 506c3 is about to go bankrupt due to litigation, the members have option to make donate to cover the settlement & preserve the pool
19:41 < maaku> er, c6
19:41 < gmaxwell> midnightmagic: so it looks like a 25% hashpower pool doublespent the shit out of a service almost a month ago, even using the procedes of the activity to pay out miners. people only noticed about a week ago. It's known on the mining subforum now, but no one is leaving the pool.
19:41 < midnightmagic> gmaxwell: That's pretty funny.
19:41 < maaku> so if they let it go bankrupt, then presumably it's because the members made that cost-benefit analysis and decided  the patent pool wasn't worth it...
19:41 < gmaxwell> maaku: yea, but that could be very expensive. Either way the bitcoin community could have to pay a lot of funds due to patents stuffed there.
19:41 < maaku> yeah
19:41 < gmaxwell> (compared to the patents not existing or being handled some other way)
19:42 < maaku> better to publish and prevent a patent in the first place ;)
19:42 < midnightmagic> gmaxwell: This is one of those "people should insist on coinbase payouts" things that miners just automatically avoid getting entangled in.
19:42 < kill\switch> ^
19:42 < midnightmagic> still have no idea why I was never asked to return that 2x payouts on that mining pool a while back.
19:43 < gmaxwell> what pool did that?!
19:43 < Luke-Jr> midnightmagic: NaCL doesn't even avoid *copyright* problems, let alone patents
19:43 < gmaxwell> and why were you mining on it?
19:43 < gmaxwell> Luke-Jr: he means djb nacl not google nacl.
19:43 < midnightmagic> gmaxwell: I was invited after my Avalons came online but the database was for a while recording like 2x my hashrate than I was actually putting into it. And went through the payouts. And I notified the pool operator. And got paid out anyway.
19:44 < gmaxwell> midnightmagic: you see 50btc's letter?
19:44 < midnightmagic> Most of it was originally from coinbase, but a couple hops out but..
19:45 < midnightmagic> no, were they laundering for shadowy Tor people?
19:45 < gmaxwell> https://50btc.com/news/status_28_10_en
19:45 < gmaxwell> Conman thinks 50btc is mostly a cover for a botnet, they're certantly weird.
19:46 < midnightmagic> I hate it when people don't date their PR.
19:46 < gmaxwell> well the URL says 28_10 but I think its (or at least the en version) is newer than that.
19:49 < midnightmagic> What's the pool that keeps getting stolen from? Is that 50btc? Like over and over..
19:50 < gmaxwell> a few weeks back 50btc had all their user balances set to crazy amounts and people withdrew until their wallet ran out of coin.
19:50 < gmaxwell> ...and it sat like that for weeks. may even still be like that now.
19:50 < gmaxwell> and more coin was going in and people were pulling it out.
19:51 < gmaxwell> ozcoin got robbed a bunch of times. :(
20:02 < Luke-Jr> what is djb nacl? O.o
20:03 < Luke-Jr> hm
20:05 < maaku> Luke-Jr: super cool crypto
20:05 < maaku> http://nacl.cr.yp.to/
20:06 < gmaxwell> petertodd: can you please generate a new dust-b-gone txn? I'm sure you've had more submission since.. I want to take another pass at getting it mined.
21:05 < petertodd> gmaxwell: there's four txins for a few satoshi's, submitted it, but it's not likely to get mined
21:07 < gmaxwell> petertodd: hm? I don't think the first one got mined and didn't it have more than that?
21:07 < petertodd> gmaxwell: also: cbebc4da731e8995fe97f6fadcd731b36ad40e5ecb31e38e904f6e5982fa09f7 WTF!
21:07 < gmaxwell> I've gotta stop assuming you made all the weird txn.
21:08 < petertodd> gmaxwell: some of them eventually got mined - I'm talked about the total
21:08 < gmaxwell> I've seen it.
21:08 < gmaxwell> it forked some alt implementations
21:08 < petertodd> gmaxwell: might have been me - I am a crack addict
21:08 < petertodd> heh, figures...
21:08 < gmaxwell> and confused some of their implementors.
21:08 < petertodd> not good...
21:09 < gmaxwell> (confused because the 0 in the scriptsig position made them think it was like the checkmultisig behavior)
21:10 < midnightmagic> Luke-Jr: NaCL from dan bernstein, the NaCL paper he wrote on it sold me pretty good..
21:11 < gmaxwell> petertodd: care to give me the hex the submitted txn so when it doesn't get mined I can nag luke and wizkid about it?
21:11 < petertodd> gmaxwell: http://0bin.net/paste/qel7hbPIRFtSLRGc#Lwd7vxfMuyQPwhunBDq1SmWVvysX99wKozKgEYnkY24=
21:13 < gmaxwell> petertodd: weird, I know I sent you a388195b8c39caf20c7774045287ebc370b57db59909fe97668b7872b3396514:0 value         "amount" : 0.00040000,
21:14 < midnightmagic> Luke-Jr: http://cr.yp.to/highspeed/coolnacl-20120725.pdf
21:14 < gmaxwell> a while back, but its not been mined nor is it in that one.
21:14 < petertodd> gmaxwell: oh, maybe I did miss some older ones
21:15 < gmaxwell> (and 0.0004 should greatly improve the odds)
21:15 < petertodd> ah, yeah I think I did
21:15 < petertodd> well, it'd be a conflict now, so I just resent the old ones
21:16 < gmaxwell> 0bin?
21:16 < petertodd> http://0bin.net/paste/j5LLNLEDS7WFsf3S#XJaGGObQv3VZyuUFWSScsbMHFvyMStuXTGzzhrion7c=
21:16 < gmaxwell> nicely, if the second one fails I can merge these myself. :P
21:16 < petertodd> nice that OP_RETURN is now standard...
21:17 < petertodd> enough git head nodes that it's propagated across all my nodes at least
21:20 < gmaxwell> with them merged Total: 0.00227106
21:21 < gmaxwell> this is the merged one: http://0bin.net/paste/4kgGct5K+guuOdY8#7u9CCxfYaOz//nFCqfII5xS53sYx1V0oQSX7i2RjTuQ=
21:26 < petertodd> that GHash.IO is performing an investigation sets a very bad precedent IMO
21:30 < gmaxwell> phantomcircuit: how so?
21:30 < gmaxwell> er petertodd
21:30 < petertodd> lol
21:30 < petertodd> the idea that miners have any responsibility towards zero-conf users is dangerous
21:30 < petertodd> for instance it means you can't change your mempool acceptance rules
21:31 < petertodd> and raises ugly questions about what to do in the event of DoS attacks
21:31 < gmaxwell> well, changing your rules is a bit different from making a bunch of doublespends yourself and then paying the procedes to miners.
21:31 < gmaxwell> investigation doesn't mean conclusion either. like... uh .. if they don't _know_ how that was happening, thats .. bad.
21:32 < petertodd> so? it's a slippery slope. For instance is it ok that Eligius blocks some tx's from ever entering it's mempool, allowing a 10% double-spend attack?
21:32 < gmaxwell> I mean, if they don't know and can't just answer it suggests that they're not actually in control of their own stuff. 0_o
21:33 < gmaxwell> vs eligius filtering where wizkid or luke can step right up and say "yea, we block txn that look like X"
21:34 < petertodd> well such is renting out hashing power...
21:34 < gmaxwell> sure... which no one who cares about their investment in hardware should ever do...
21:34 < gmaxwell> Which I assume will be their answer, because it's an easy out regardless of the real cause.
21:35 < petertodd> ...except when they've already sold it all on an exchange, and the peopel on the exchange figure they can sell it to the other sucker before anything happens
21:35 < gmaxwell> well, there is still the value of the hardware itself.
21:36 < petertodd> what value? CEX doesn't own it anymore if I understand their business model correctly
21:36 < petertodd> just maintenance, and that could be negative value if they ever screw up
21:36 < petertodd> (negative to CEX)
21:36 < gmaxwell> moral hazard in any case you can rent out your hashpower fine, so long as few enough other people do it too.
21:37 < gmaxwell> I wasn't sure how much of the hardware cex had sold off as shares— it's never been priced attractively.
21:37 < gmaxwell> but fair point...
21:39 < gmaxwell> what a mess.. you hardware fractionalized and sold to people with no control over it.. who then mine at a single enormous pool which is full of these miners that can't vote with their feet.
21:39 < petertodd> well, assume they sold it all off, and then screwed up the contract such that they couldn't get out of supporting it for people at a price that wasn't profitable. They're incentive is to actually destroy Bitcoin.
21:40 < petertodd> More likely, they don't have any strong incentive *not* too...
21:43 < gmaxwell> The maintenance fee is estimated as $0.30 / kW x hour: $0.17/kW electricity cost + $0.09 data centre upkeep + $0.04 hardware repair/maintenance.
21:44 < petertodd> Sure, and screw up that contract in some way... You want an unconditional "out" clause, but eventually someone in the business is going to mess that up.
21:44 < gmaxwell> at the moment their hosting is 3.15% of the mining returns. looks like its structured so they can't get screwed.
21:46 < petertodd> Eventually someones going to mess that up. Also remember that their ROI is %3, so the amount of money sufficient to make it in thier interests to do something that damages Bitcoin is significantly less than for their customers.
21:47 < gmaxwell> right. Agreed. some stupid doublependy thing that doesn't return much could easily double their profit.
21:48 < gmaxwell> lol the users get dinged for another 3% pool fee.
21:51 < petertodd> well, a painless 3% is pretty attactive to a lot of people
21:51 < gmaxwell> there is a calculator on their site that shows 1 GH will net 0.08 BTC over its life.... and currently on their market 1GH/s sells for 0.09. :P
21:52 < petertodd> ha
21:52 < midnightmagic> *-/
21:52 < gmaxwell> their calculator assumes 50% hashrate growth per month. which is probably low for the near term, and in the longer term their operating fees eat the profits regardless of how you set it.
21:53 < gmaxwell> oh great, they are saying they'll have short selling by november 16th.
21:56 < petertodd> yeah we're fucked
21:57 < gmaxwell>  Is there anything I can do about the high stale counts on the GHash.IO pool?
21:57 < gmaxwell>     The stale and duplicate shares are kept to the minimum, however we do not guarantee low stale and duplicate shares on 3rd party hardware mining at out pool.
21:57 < gmaxwell> 0_o this is in the faq on the cex.io site.
21:58 < gmaxwell> We are conducting business as a legitimate UK based company. We will not be able to disappear, as we are governed by UK laws.
22:00 < gmaxwell>  When conducting Bitcoin Transfer Transactions with a Bitcoin user who is not a Member, CEX.io responsibility shall be further limited to ensuring the transfer of the necessary technical data to the Bitcoin peer-to-peer network.
22:01 < petertodd> "* At any point in time we may elect to turn into a Cayman Islands company, and such act will not constitute a disappearance"
22:03 < gmaxwell> CEX.io may by notice to Members discontinue or modify the Platform and/or revise or terminate these Terms at any time.
22:05 < gmaxwell>  Additionally, we may, in appropriate circumstances and at our discretion, suspend or terminate Accounts of Members for any reason, including without limitation: ... (6) unexpected operational difficulties,
22:06 < gmaxwell> sounds like: 'although you cannot see us, we are technically visible in that we are opaque to optical radiation and thus have not disappeared.'
22:06 < petertodd> heh
22:08 < gmaxwell> I can't find any terms related to the actual hardware.
22:12 < petertodd> the sad thing is how even with fancy ZI stuff to let hashers steal block rewards and stuff, it still doesn't solve the problem of hosted mining
22:12 < gmaxwell> petertodd: the older one (at least!) went through!
22:12 < petertodd> nifty
22:12 < gmaxwell> petertodd: the miners here can't even tell the hardware exists.
22:12 < petertodd> exactly
22:13 < gmaxwell> much less that they're not being robbed on it.
22:13 < petertodd> and if they keep getting their expected dividend, who'se to say they're really being robbed?
22:14 < gmaxwell> you could create a bitminter.io and pay a few weeks of dividends as people pile in to buy cheap "fasthash" gigahashes... and then just walk.
22:14 < petertodd> ha, for sure!
22:14 < petertodd> no hardware required
22:19 < gmaxwell> in any case you saw my initial response on that post "meh". I've never been one to think that just because your door is unlocked that its okay to rob you, but an unconfirmed gambling site is ... well I don't know what to think about that. but the fact that it looks like the pool or cex was earning a profit from it is interesting.
22:21 < petertodd> double-spend warnings are going to make this really interesting given that gavin's planning on implementing them by broadcasting the whole tx
22:23 < gmaxwell> if you don't broadcast the whole tx it's hard to verify they're correct... and just sending, e.g. pubkey,sig or whatever doesn't let you do things like ignore ones that still pay you.
22:23 < gmaxwell> so yea...
22:23 < gmaxwell> heh 2013-11-12 03:11:42 CWalletTx::GetAmounts: Unknown transaction type found, txid 499e80a173ee095d44b1c3503c5d00015222a2d7c17a2140fa16f28eeeda8b93
22:24 < petertodd> never mind that you can always rebroadcast a sig from an earlier tx if you do it with just hashes
22:24 < petertodd> (due to address re-use)
22:24 < gmaxwell> indeed.
22:24 < gmaxwell> "what ashame!"
22:24 < petertodd> it'll be a good time to push direct replace-by-fee, and incentivise it by making some double-spends with, say, 0.5BTC fees
22:25 < petertodd> won't surprise me if people try to push making miners ignore blocks that contain things they think are double-spends of course... but that has lots of ugly consequences
22:26 < gmaxwell> very bad for convergence.
22:26 < gmaxwell> esp if you flood the network with concurrently broadcasted doublespends.
22:26 < petertodd> yup, and makes any mempool difference practically a forking bug
22:26 < amiller> No one ever seems to bother doing a secure multiparty lottery
22:27 < amiller> in multiparty computation there are auctions and fair exchanges and stuff like that
22:27 < amiller> Adam Smith is quoted as saying "there can never be a fair lottery" but we should be able to do exactly that
22:27 < amiller> you would absolutely need a non-EU model or rationality to even analyze the lottery under terms like that
22:27 < petertodd> why would I want to do that? I'm a trustworthy guy.
22:28 < amiller> what does trustworthy have to do with participating in a lottery?
22:28 < petertodd> I'm running the lottery, you can trust me to do it fairly. Why trust all this crypto shit? It's probably designed by the NSA anyway.
22:29 < gmaxwell> amiller: most of this mpc stuff isn't even secure in an model where an attacker is active.
22:29 < gmaxwell> most of it is against a model where the attacker is curious but won't compromise the protocol.
22:29 < amiller> i learned today about the "covert security" model which actually matches exctly what we'd like in terms of auditability
22:29 < gmaxwell> (IOW: a fucking useless model, what is wrong with these people?!)
22:30 < amiller> an adversary might change the outcome, but it will do so in a publicly-detectable way
22:30 < amiller> active*
22:31 < amiller> anyway that's beside the point i'm talking about rational analysis mainly here
22:33 < petertodd> gmaxwell: ...so we're talking security against dumb five year olds?
23:32 < amiller> there's still no way of doing a fair 50-50 bet in bitcoin
23:32 < amiller> there would be if we had even the most basic bitwise arithmetic ops
23:51 < gmaxwell> amiller: hm? you don't like iddo's protocol?
23:53 < amiller> gmaxwell, https://bitcointalk.org/index.php?topic=277048.0 this one?
23:54 < amiller> how do you take the LSB of something you can hash?
23:54 < gmaxwell> ah I thought you said "even if we had [...] arithmetic ops" misread.
23:55 < amiller> so having a bet like that is one of the things you just can't analyze in EU
23:56 < amiller> i think that's one of the reasons why simple games like that have been skipped over by cryptofolk who assume that anything that isn't EU is just irrational and not worth modeling
23:57 < amiller> but it seems appealing to me, if enough people are each willing to pay a small amount of money for a marginally-negative EV but a high variance, then they should be able to get together and do a lottery like this
23:57 < amiller> incurring only transaction costs
--- Log closed Tue Nov 12 00:00:14 2013