00:40:08lnovy:lnovy is now known as zz_lnovy
00:47:07zz_lnovy:zz_lnovy is now known as lnovy
00:52:47_Iriez:_Iriez is now known as Iriez
01:21:30wallet42:wallet42 is now known as Guest69807
01:21:30wallet421:wallet421 is now known as wallet42
03:58:39amiller_:petertodd, you're implementing *colored coins* for some reason?
03:59:45petertodd:amiller_: yup, basic idea has a huge amount of simularities to schemes that treechains would use you know
04:00:28amiller_:idont see that similarity yet but it's interesting
04:00:59sipa:the similarity is that both needs the sender to provide proofs of the input coin's history?
04:01:07petertodd:sipa: exactly
04:01:24amiller_:ok that part is pretty clear enough
04:01:26petertodd:getting $$$ to write that code and explore the ideas is something I'm all for
04:03:17petertodd:equally, I genuinely think colored coins gets a bad rap - my clients in this case understand damn well that they're always centralized in a way, as well as having specific legal/social reasons for doing the accounting on the blockchain
04:03:43amiller_:centralized but with accounting on the blockchain? that's interesting but i dont get it yet
04:03:57amiller_:colored coins has really poor spv but maybe that doesn't matter
04:04:14petertodd:a centralized issuer may not want to have the ability to easily turn down a transfer of assets from one owner to another
04:04:23petertodd:also, I've got a few reasonable approaches re: spv
04:06:05amiller_:go on?
04:07:12petertodd:amiller_: easiest is to just have the issuer periodically hash all colored txouts into a new merklized prefix tree and update the color definition
04:08:11amiller_:ok for a new comer to check that all those merkleed trees are accurate seems expensive
04:08:20petertodd:amiller_: it's a trusted issuer :)
04:08:36amiller_:trusted issuer should just store his own ledger and publish it maybe every so often
04:08:51petertodd:amiller_: by definition the merkle tree is accurate! equally, checking ledgers is expensive
04:10:25petertodd:equally, in the use-cases they have, every asset transfer will end up bein for bitcoins or another asset, so you're already involving bitcoin transactions anyway
04:10:35amiller_:so my general line of thought here is.... super public consensus is really expensive, but really narrow... in the sense that almost everything is either *not posssible even with the blockchain* or *possible in the same trust model without the blockchain*
04:11:44petertodd:and my model is "meh, a 2x increase in costs is meaningless" - remember all this colored coin stuff works fine with offchain techniques, micropayment channels, etc.
04:11:45amiller_:so trusted issuer, why bother with blockchain
04:12:21petertodd:amiller_: you can ask the question why public companies don't keep track of stock issuances/ownership themselves...
04:12:54amiller_:they're also not "trusted" but maybe that's splitting hairs, i guess you mean "partially trusted" in some specific onctext and not others
04:13:26petertodd:the notion of "partially trusted" is very important here - keeping track of assets being traded around isn't a core competecancy for most issuers
04:17:02amiller_:so either colored coins involves decentralized ledger keeping, in which case it's rpetty expensive and vulnerable to dos, or else it requires centralized ledger keeping because no one can afford to run a colored coins node
04:17:31petertodd:amiller_: "expensive and vulnerable to dos" <- no more than bitcoin...
04:17:47petertodd:also, you don't need colored coins nodes in how we've architected it
04:18:11amiller_:ok im curious what
04:19:19petertodd:simple, making history proofs showing some txout was colored according to the definition, pass them around when moving colored coins to the recipients, and prune those proofs periodically by new definitions, and/or re-issuing w/ scriptPubKey
04:20:05amiller_:is the issuer punsihed if it fails to prune periodically
04:20:18amiller_:it seems like if it's doing periodic stuff, it can just run its own ledger
04:20:21petertodd:sure, they're customers complain, not a big deal
04:20:33amiller_:right so it ignores its customers because that's not something it's really promsid to do
04:20:46petertodd:periodically running some script on an *offline* machine is *way* easier than having a 24/7 available online ledger
04:21:48petertodd:equally, you can punt the problem to semi-trusted third-parties authorized to prune proofs on your behalf, and if they commit fraud, easily construct proofs of that fraud
04:22:12petertodd:sorry, but business needs trump purity anyday...
04:22:47amiller_:ok so
04:23:12amiller_:the (semitrusted) issuer reissues in batches to avoid the growing proof complexity
04:24:00petertodd:in the future this may become "SCIP MAGIC IS MAGIC"
04:25:29amiller_:so frustrated at scip being misused that way, snarks is a crypto term scip is a project name that implemented snarks second
04:25:46petertodd:amiller_: don't get snarky at me
04:26:23amiller_:ok with cheap snarks yeah colored coins no problem anyway
04:27:13petertodd:heh, anyway, main thing is if you're already dong a bitcoin transaction because you want to buy some gold or whatever... at most increasing the cost of that transaction about 2x isn't a big deal
04:27:37petertodd:not pretty and pure... but issuers think it's a total non-issue
04:29:18amiller_:issuers gonna ish
04:29:34amiller_:okay that all makes sense just wanted to check what you were aiming for
04:29:44kanzure:couldn't there be some non-distributed-blockchain software for issuers to run?
04:30:00sipa:kanzure: yes, it's called accounting software
04:30:04kanzure:they seem willing to run spv nodes, apparently, so why not something else?
04:30:29petertodd:kanzure: issuers aren't willing to do *anything* that requires any particular uptime
04:30:43petertodd:kanzure: it's the users who are running the spv nodes - that is, wallet software
04:30:55kanzure:but they are an issuer! they should have 100% uptime for the windows during which they are offering redemption etc.
04:31:22petertodd:kanzure: uptime for when you offer redemption != uptime for when people trade assets around
04:31:26gmaxwell:redemption? ... is that something that happens during the mysterous step 2?
04:31:50kanzure:i was hand waving, i mean things like "there is stuff in our vaults that you presumably want to exchange for the ious"
04:32:04petertodd:kanzure: in fact, it's very, very likely that redemption ends up being semi-theoretical for many useful assets, as the ease of trading effectively means you've outsourced actual redemption to someone else
04:32:31gmaxwell:So what phase does that happen in? (1) Issue underpants, (2) ???, (3) Profit!
04:33:11petertodd:gmaxwell: if you're wikileaks, and want to hold USD rather than BTC, outsourcing redemption is a lovely thing
04:34:49gmaxwell:I'm skeptical, but happy to see people trying things in any case.
04:34:56kanzure:i wonder what sort of downtime for transaction ledgering is acceptable to the majority of would-be issuers
04:35:35petertodd:gmaxwell: I'm skeptical too :) but real-world issuers want to actually do this, and there's lots of subtle practical advantages to outsourcing accounting to a magic trusted third-party for those issuers
04:35:42petertodd:kanzure: ~0%
04:36:33petertodd:kanzure: note too, how having a "0%" downtime ledger available, makes the less reliable ledgers built on top of it more acceptable (IE off-chain layers)
04:38:10moa:sounds a lot like philosophy around Open transactions or earlier Truledger
04:38:21kanzure:i don't think it sounds like open transactions
04:39:20kanzure:"hey signing is involved therefore it must be like open transactions"
04:39:43moa:with some bolt on bitcoinesque baubles
04:43:00kanzure:heh an ot dev. well, i've read the source code, and i have poked at it, so i'm pretty sure i'm right.
04:43:25amiller_:ot forgot to do any crypto
04:47:08petertodd:ot forgot to ship an actual useful application
04:47:43gmaxwell:To be fair, this is a time tested approach in the field of cryptocurrency.
04:48:14kanzure:"welcome to the wonderful business of lemons"?
04:48:25petertodd:...and by tested, you mean "every time we did this, the test results said we failed"
04:48:39petertodd:"maybe this time we'll get lucky?"
04:49:25kanzure:there should be a general merkle proof tree library thing for slinging proof trees together. hrm.
04:49:35Taek42:* Taek42 feels confused by all the cynicism
04:49:48petertodd:kanzure: https://github.com/petertodd/python-merbinnertree
04:50:00kanzure:next i would like petertodd to deliver me a burrito
04:50:01petertodd:kanzure: note how it even has a made-up name that is googlable!
04:50:18petertodd:kanzure: http://idlewords.com/2007/04/the_alameda-weehawken_burrito_tunnel.htm
04:50:50gmaxwell:<3 the burrito tunnel
04:50:52kanzure:my last wish is 3 more wishes
04:51:01petertodd:kanzure: granted
04:51:36gmaxwell:^ good news
04:52:33gmaxwell:bad news: "wishes" are a new altcoin based on some quickbasic custom stream cipher predicated on the harness of sorting lists of integers.
04:52:59kanzure:this place is rough
04:53:09kanzure:provably rough
04:53:22amiller_:kanzure, https://github.com/amiller/lambda-auth
04:53:37petertodd:kanzure: unfortunately the proof isn't transferable to third parties, and must be experienced in person
04:54:08gmaxwell:hm. should invent an asymetric cryptosystem that is provably secure so long as there is no efficient algorithim for sorting integers.
04:54:13kanzure:so merbinnertree only proves the presence of a key in the original data struct?
04:54:32petertodd:kanzure: or not presence (a merkle tree only proves presence)
04:55:04kanzure:what about key-mapped values?
04:55:19kanzure:i see that values are accepted in the functions here, but i don't know what happens to them =)
04:55:22petertodd:kanzure: merbinner tree is a key:value map
04:56:09petertodd:kanzure: proves the statements "key -> value" and "key -> ⊥"
04:56:50amiller_:that's a special case in my system, you just give it a trie or balanced tree and you get the merkle version for free
04:57:30petertodd:amiller_: yeah, and I'm sure your system is better than mine in about a million ways... except simplicity and a good name :)
04:57:56amiller_:simplicity is relative and i like my name :)
04:58:21petertodd:amiller_: I wrote that merbinner tree library for this colored coin project, and my client decided to nix it for version 0 because it was "too complex"
04:58:41kanzure:and instead?
04:59:01petertodd:kanzure: the features that depend on it are just going to get delayed, nothing fancy
04:59:29petertodd:kanzure: improtant thing is I'm convinced those features *can* be implemented, so that'll just be a future upgrade (and probably a soon one!)
05:01:34petertodd:* petertodd should use a console other than IRC chat to see what unicode symbols look like on his terminal...
05:34:44phantomcircuit:petertodd, lol that's short sighted
05:34:52phantomcircuit:i had someone implement it in c
06:32:16Ded:Ded is now known as Aquent
06:33:35petertodd:phantomcircuit: ?
06:33:56petertodd:phantomcircuit: oh, you mean leaving our the merbinner tree stuff? yeah, that's just a delay of a few weeks or so
06:34:05petertodd:phantomcircuit: repo for the C version?
06:35:45phantomcircuit:petertodd, isn't one
06:35:54phantomcircuit:currently a "email me that" project
06:36:17petertodd:phantomcircuit: lol, well "email me that" :)
06:36:32petertodd:phantomcircuit: I should do up some data-driven test-cases ASAP
08:05:17holmes.freenode.net:topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
08:05:17holmes.freenode.net:Users on #bitcoin-wizards: andy-logbot adam3us x48_ hollandais RoboTedd_ cbeams ebfull pen p15 nuke1989 Aquent TheSeven Starduster fanquake tromp_ jchp Dr-G3 lnovy torsthaldo spinza gribble go1111111 koshii Tyrent Graftec hguux waxwing eristisk livegnik HaltingState mortale rfreeman_w wiretapped stonecoldpat Dyaheon Kretchfoop Fistful_of_coins Sangheili digitalmagus Transisto dansmith_btc2 jgarzik todaystomorrow dgenr8 EasyAt BigBitz altoz MRL-Relay artifexd _2539 mappum
08:05:17holmes.freenode.net:Users on #bitcoin-wizards: jbenet [Derek] shesek [d__d] berndj zibbo_ Iriez kanzure OneFixt SDCDev Luke-Jr petertodd optimator nsh [\\\] Grishnakh jaekwon1 warren puszl irc88___ tacotime pi07r Adohgg K1773R xmj Hunger- mkarrer Eliel HM gmaxwell amiller_ crescendo LarsLarsen cfields btc_ kgk bobke iddo samson_ arowser comboy Happzz copumpkin wumpus NikolaiToryzin coryfields michagogo zenojis LaptopZZ Meeh poggy_ Emcy_ UukGoblin danneu catcow TD-Linux [Tristan] helo smooth
08:05:18holmes.freenode.net:Users on #bitcoin-wizards: otoburb gwillen ryan-c nickler_ mmozeiko roasbeef pajarillo sl01 Keefe rs0_ Gnosis ahmed_ Muis Logicwax nanotube espes__ andytoshi so epscy BlueMatt tromp wizkid057 a5m0 starsoccer midnightmagic Graet kinlo pigeons BrainOverfl0w lianj Apocalyptic mr_burdell fluffypony bbrittain SomeoneWeird forrestv Anduck Nightwolf Krellan Taek42 @ChanServ phedny burcin lechuga_ abc56889 Alanius Guest47516 throughnothing CodeShark harrow DoctorBTC
08:05:18holmes.freenode.net:Users on #bitcoin-wizards: phantomcircuit nsh- sipa asoltys
16:06:13nessence_:nessence_ is now known as nessence
16:30:21Guyver2:Guyver2 has left #bitcoin-wizards
17:27:19Drefenor:Drefenor has left #bitcoin-wizards
18:03:41amiller_:petertodd, you should look into VerSum
18:04:00amiller_:it's actually a really good way of doing more complicated proofs based on data in bitcoin blockcain
18:04:18amiller_:it's really efficient, more so than checking acolored coin proof or whatever
18:04:25amiller_:the catch is that it relies on an "any trust" server model
18:04:26kanzure:this? http://people.csail.mit.edu/nickolai/papers/vandenhooff-versum.pdf
18:04:31amiller_:kanzure, yep
18:04:49amiller_:it will be presented at CCS (swanky academic security conference) later this year
18:05:23amiller_:youhave to query some number of N servers
18:05:23amiller_:if *even one of them* is giving you honest results, you can figure out which one it is
18:05:54amiller_:the way it works is that if two people give you different answers about some query, you can interact with them doing a sort of bisection thing to figure out the first place they differ at some step, and you can identify that one of them was wrong
18:06:45amiller_:its a really great use of authenticated data structures i wish i thuoght of
18:24:00jgarzik:amiller_, andytoshi, gmaxwell: Does anyone have any Nicholas Courtois refutations lying around?
18:24:29jgarzik:Journos are emailing, and giving him tons of credibility (5800 Google Scholar citations!!!)
18:25:21amiller_:about what?
18:25:24amiller_:refuting him generally?
18:25:43amiller_:oh eprint The Unreasonable Fundamental Incertitudes Behind Bitcoin Mining http://arxiv.org/abs/1310.7935
18:26:54kanzure:"More importantly, the specification is likely to change" ?
18:27:05amiller_:omfg this is an arxiv paper that cites the dakami bet?
18:27:27kanzure:this is just random strings of words put together
18:27:36sipa:i don't understand the abstract
18:27:43kanzure:gish gallop
18:27:45sipa:it says conflicting things
18:29:36jgarzik:amiller_, Yep that's the one, http://arxiv.org/abs/1310.7935
18:29:38amiller_:i think their frustrating abstract says two things: "These [novel] optimizations enable bitcoin miners to save tens of millions of dollars" and regarding the 4 year inflation bumps, they "find this property totally unreasonable and harmful"
18:30:14amiller_:so they're proposing a modified reward formula and a different pow i guess
18:30:59amiller_:" We see absolutely no reason and no benefit of any kind to have this sort of mechanism built in a crypto currency. On the contrary, we claim that this mechanism is unnecessary and harmful." that is pretty embarrassing writing
18:31:11amiller_:tons of altcoins *have* used different PoW and altered reward schemes
18:31:25amiller_:Dogecoin changed their reward schedule mid stream due to implementation bugs
18:31:52gmaxwell:jgarzik: there is a thread on bitcoin talk that tares into it some. I can't believe anyone would cite it.
18:32:45gmaxwell:Regardless of the merits of the arguments the writing seems generally unhinged. (e.g. switching at random into bold allcaps)
18:34:40jgarzik:gmaxwell, This CoinDesk journo is using total citations of the person as a metric for credibility :/
18:34:54jgarzik:"Courtois (not his paper) has 5800 Google Scholar citations!"
18:35:12amiller_:i like that they propose a new reward scheme based on some principles, such as gradually becoming more continuous.... but they don't really have any validation for why those principles are desirable and the intuition is kind of fuzzy
18:35:21jgarzik:and then "why are bitcoin core devs being assholes and ignoring an obvious scholar?"
18:35:24fluffypony:wasn't he the idiot that wrote that paper "on the longest chain rule" ?
18:35:30kanzure:it's interesting that the author is trying to backdate the terminology and claim that his term is what everyone else should be using, rather than the bitcoin lexicon
18:35:30jgarzik:fluffypony, yep, that's the one
18:35:42fluffypony:oh lord...
18:35:56sipa:he gives the reason why such a change won't happen in the abstract: the community would reject it
18:36:11amiller_:is there any evidence that their SHA2 mining optimizations are any better than actual bitcoin mining asics?
18:36:16amiller_:or is it just vs naive sha2 circuit?
18:36:16gmaxwell:oh well I think courtois is credible in general (like shamir is, though obviously not as much) but his commentary on bitcoin is mostly uninteresting.
18:36:34gmaxwell:fluffypony: yes
18:36:50amiller_:"Remark 3. We ignore if recent mining devices already use Fact 12.1 which developers could have discovered independently"
18:36:50fluffypony:gmaxwell: maybe AnonyMint == Curtois, wouldn't that be a twist :-P
18:37:02amiller_:they are almost certainly reinventing obvious optimizations that the industry of mining asics is taking advantage of
18:37:11amiller_:" We have noticed that the Swedish
18:37:11amiller_:company KNCminer have explained in some Internet forums that they do indeed
18:37:11amiller_:use some optimizations [39] which allow them to"
18:37:51sipa:"Hi! We're publishing a paper on technology well-known in the industry, but hey, nobody published them yet, so why not!"
18:38:10gmaxwell:amiller_: there are some moderate circuit optimizations.. but of course any amount of circuit optimizations are (1) independantly discoverable to anyone, (2) at most some constant factor (usually small), (3) many kind are widely known.
18:38:25amiller_:they are explicitly showing a small constant factor
18:38:43gmaxwell:yea, so who cares? differential power price is likewise.
18:39:13gmaxwell:E.g. you can drop the last three rounds of the double sha256 has been known and used since 2010. There are a grab bag of small optimizations which are widely known.
18:39:21kanzure:jgarzik: unfortunately i don't know of a good defense against this
18:39:52kanzure:jgarzik: do the journos want some other papers to read? are they even going to read any of them?
18:40:33jgarzik:kanzure, probably not
18:40:44fluffypony:kanzure: they will read the abstract and the first two paragraphs and then jump to the end "where all the good stuff is"
18:40:57jgarzik:kanzure, they want a quote from Courtois, quote from bitcoin dev, etc. probably cannot even parse the abstract.
18:41:05jgarzik:typical journo pattern
18:41:29kanzure:okay, well, so far this has been a waste of my time to read, so i can't imagine anyone else would get value out of this pdf
18:48:24kanzure:sentences switch topic and don't justify each other :/
18:49:25justanotheruser:can you link me to this paper? Is it just an altcoin "whitepaper"
18:49:30jgarzik:scroll up
18:49:45justanotheruser:jgarzik: I don't think I was in here.
18:49:49justanotheruser:* justanotheruser goes to online logs
18:50:00kanzure:you were in here
18:50:05jgarzik:* justanotheruser (~Justan@unaffiliated/justanotheruser) has joined #bitcoin-wizards
18:50:06jgarzik: amiller_, Yep that's the one, http://arxiv.org/abs/1310.7935
18:50:55justanotheruser:my bad
18:51:11kanzure:i suppose you can just give them the standard "academic study of bitcoin is highly encouraged, and we look forward to them refining their ideas" haha
18:51:43jgarzik:Yeah, my usual reaction of "goddamn this work sucks" isn't very productive
18:52:05fluffypony:kanzure: we've been pondering similar phrasing to shut down all the armchair mathematicians that "think they found a flaw" in the ring signature maths
18:52:13amiller_:point out this hasn't been peer reviewed at all jgarzik
18:52:28kanzure:peer review is overrated, just don't be an idiot and you can get away without peer review in some cases
18:52:41amiller_:that's true too tbh
18:53:08sipa:the right peer review is very valuable :)
18:53:16kanzure:sure, i shouldn't have made such a strong statement
18:53:18tacotime:yeah, it depends on the journal
18:53:21kanzure:it does have value
18:54:16kanzure:fluffypony: unfortuately "we encourage academic study into x" can be interpreted as an endorsement
18:54:39tacotime:and also the reviewer. i've seen totally useful and reasonable requests for more data on papers and ones that are off the wall and don't really make sense. you never know what you're going to get, but it's always good for someone to have a second look.
18:54:55fluffypony:kanzure: maybe we need to universally define a format, like "if you think you have something, please publish it in this format" to discourage this sort of thing
18:55:02tacotime:like when andytoshi destroyed a proposed improvement to our ring sig algorithm. :)
18:55:02jgarzik:amiller_, yeah, That's where I'm currently at, in fact:
18:55:09kanzure:"My review process takes many months for a work of this magnitude, and I just want to say that academic investigation into Bitcoin is extremely important, even though my time can't be dedicated to picking through their work."
18:55:12justanotheruser:Their abstract says so much but says so little
18:55:14jgarzik:"You [coindesk journo] completely avoided the issues raised in my message.
18:55:14jgarzik:Who, specifically, peer-reviewed Courtois' latest paper, and reached
18:55:14jgarzik:the same conclusions as Courtois?
18:55:14jgarzik:I'm not talking about other unrelated papers that Google Scholar links."
18:55:27jgarzik:Previous email lectured journo on the scientific method & process.
18:55:34justanotheruser:they have a giant abstract only to finally cover the fact that they don't like the 4 year halving
18:55:42kanzure:it is important to emphasize that reading a paper and properly reviewing it takes a long time
18:56:04kanzure:and by definition nobody on the planet has picked apart this paper yet
18:56:17kanzure:so there's no way anyone can have a positive opinion on it (and if they do, they should be held under suspicion of bullshit)
18:56:21jgarzik:kanzure, definitely good responses
18:56:33jgarzik:though I think some of the hand-waving and ALL CAPS EMOTION should be highlighted
18:57:08justanotheruser:were also major cyber attacks with concrete exploits against bitcoin software
18:57:11justanotheruser:and systems, see [10]. In just once such incident 17000 BTC were lost
18:57:16justanotheruser:what is this referring to?
18:57:30justanotheruser:an actual reference client bug?
18:59:18justanotheruser:I see bitomat losing their coins, but thats not an exploit...
19:27:59Dizzle__:Dizzle__ is now known as Dizzle
19:43:05phantomcircuit:jgarzik, that guy is such a dick
20:03:13Taek42:petertodd: in your treechains overview, you say miners can mine the root, the root and the left side, the root and the right side, but not the root and both sides. Why is this a necessary constraint?
20:15:44yoleaux:dpk: This channel is public. When I am asked when I last saw you, I may repeat things you say and what time it was when you said them.
20:16:15dpk:kanzure: let me know if the channel message privacy stuff changes
20:17:07dpk:dpk has left #bitcoin-wizards
20:18:13CoinMuncher:I'm enjoying this... Nicholas Courtois recently gave a talk at Bitcoinference.com in Amsterdam. His emotional and unhinged writing style is also present in his presentations. It was a horrible mismatch of "Satoshi forgot this." "Satoshi did that wrong." "Core devs overlooked this." without any sign of any suggestion of a better way to do it. I think in the end the suggestion was just to do away with the entire blockchain and the "horrible" 10 m
20:18:48CoinMuncher:It's too bad half of the audience took him seriously.
20:20:11fluffypony:could be worse - at least he didn't say "when I release *my* coin..."
20:21:35justanotheruser:CoinMuncher: he said do away with the blockchain?
20:21:39justanotheruser:what did he suggest?
20:21:41kanzure:CoinMuncher: you may be experiencing irc message length cutoff due to misconfigured client stuff
20:22:03CoinMuncher:hmm... I'll cut it up
20:22:12CoinMuncher:I think in the end the suggestion was just to do away with the entire blockchain and the "horrible" 10 minutes delays by simply using synchronised clocks and picking the first transaction in case of double spends. And at some point he was almost in tears "I went to the bitcoin devs with my super-awesome findings and they didn't take me seriously".
20:22:34fluffypony:well now he's gone to CoinDesk
20:22:40fluffypony:because they're completely unbiased.
20:22:41CoinMuncher:(using pidgin, I'll try to do some research on max length)
20:23:29justanotheruser:CoinMuncher: sounds like an uninformed person too confident for their own good
20:23:50kanzure:you shouldn't judge his confidence at all
20:24:24Taek42:CoinMuncher looks like 448 chars is your limit
20:24:36justanotheruser:kanzure: he was confident enough to deny reason in favor of his own idea
20:27:52CoinMuncher:If any of you guys are ever in Amsterdam, please come by on the meetups btw. That would be awesome! There's two different meetups, you're bound to hit at least one. Maybe you can set some Courtois-confused souls back on the right path.
20:34:41helo:that is pretty silly
20:35:15helo:how would coindesk take him seriously?
20:36:25helo:he has done some awesome crypto work, but i guess just completely missed the point
20:36:53helo:(of blockchain)
20:39:42CoinMuncher:Oh yeah, now I remember. He called Bitcoin the laughing stock of the elecptic curve crowd because it uses constants that noone else uses and are not NSA endorsed.
20:57:11Luke-Jr:well, there might be better curves we could use, but that's kinda beside the point
21:15:01tromp:Vitalik has another blog entry on PoS; https://blog.ethereum.org/2014/10/03/slasher-ghost-developments-proof-stake/
21:16:46tromp:he seems to think that any problem can be overcome with additional complexity
21:31:43tacotime:"For Ethereum 1.0, we consider it highly desirable to both not excessively delay the release and not try too many untested features at once; hence, we will likely stick with ASIC-resistant proof of work, perhaps with non-Slasher proof of activity as an addon, and look at moving to a more comprehensive proof of stake model over time."
21:31:47tacotime:That about sums it up
21:31:59andytoshi:calling 51% a "flaw" of proof-of-work is astoundingly confused, maybe he should describe a distinguisher between an honest and dishonest history creator?
21:35:29helo:from an outsider's perspective, i'm afraid their arguments make just as much sense as ours
21:36:26amiller_:even to an insider i think all the arguments on both sides are fragile
21:36:52tacotime:the nice thing about most of our arguments is that bitcoin has succeeded from virtually nothing and already works.
21:37:14andytoshi:i think if you start with an unstated assumption that relativity of simultaneity is wrong, your argument is garbage
21:37:24andytoshi:not fragile
21:37:58helo:but an outsider won't even invest that much work into comprehending either argument
21:38:06andytoshi:(ofc, agree that the arguments in favour of hashpower sigs providing a consensus are fragile!)
21:38:14helo:and just say "that sounds weird *shrug*"
22:13:06petertodd:amiller_: oh, yeah, VerSum sounds really similar to stuff I was arguing that Mastercoin/Counterparty should do just on the basis of making testing easier, let alone the obvious outsourcing applcations
22:15:00petertodd:amiller_: academics minds are going to be blown when they realise that treechains-like proof-of-publication layers are monetary policy agnostic, and inevitably invite people to use whatever currency makes them the most money... (or thye think will make them the most money)
22:16:26petertodd:Taek42: I want to avoid giving advantages to miners with large concentrations of hashing power; profit should be a linear function of hashing power
22:17:00Eliel:petertodd: blown in what sense? :)
22:18:24petertodd:Eliel: "blown"?
22:18:44Eliel:"academics minds are going to be blown"
22:19:09petertodd:Eliel: oh, in reference to academics complaining about the inflation schedule
22:19:31petertodd:Eliel: point is, we have way less coercion ability with regard to this stuff than people like to assume
22:20:11Eliel:ah, yes, you mean the market decides the monetary policy, not someone in a high chair.
22:20:33petertodd:Eliel: exactly!
22:21:31Taek42:petertodd: I only sort of understand. If everybody has the ability to mine a+b+c, then every hash should be equally valuable regardless of how big your operation is?
22:23:15petertodd:Taek42: basically, if you can mind left and right children simultaneously, than miners with more hashing power have a lower overhead cost per unit hash, thus a non-linear profit advantage
22:24:00Taek42:I suppose it's more of a problem when your tree is N layers deep
22:24:12Taek42:makes sense then
22:24:38petertodd:exactly, the tree can be many, many layers deep :)
22:25:33Taek42:The next question is about 'untethered' blocks. So b1 is in a1, and then b2... b5 is untethered, and then b6 is in a_X
22:25:52Taek42:how does b2 - b5 get mined, and what are the incentives for publishing them as you find them?
22:26:41petertodd:basically incentives to publish only happen if you have <50% of hashing power, and the incentive is that others will mine on top of your blocks - same as bitcoin
22:27:01petertodd:(<50% hashing power locally I believe - need to go through the math a bit more to see if that can be improved upon)
22:28:57Taek42:(thinking outloud, sorry for dumb errors) so, presumably, A has 100% of the hashes on the network, because nobody would mine b and not a. And b is protected by some lesser amount of hashes, say 50%.
22:29:18Taek42:And I mine on b when it's probabilistically more valuable for me to do a+b than it is to do a+c
22:30:31petertodd:right, and I think - thought haven't rigorously analysed it - that forcing "left/right/left/right" ordering for children can help with that, though we'll see
22:30:37Taek42:If I find a block in 'b', I can either publish it or hide it. If I hide it until I find find 'a+b', I can potentially orphan a competing miners blocks
22:31:24petertodd:ah, yes, although if you have a minority of hashing power it's more likely that someone else will find the next block at a level up
22:31:42Taek42:So it's potentially valuable for me to solo-focus 'b', even if 'a' appears to be more valuable, because I can get a higher percentage of b blocks by only mining b
22:32:02Taek42:IE it's easier for me to 50% attack 'b' if I ignore the rewards from a
22:32:08Taek42:*** c not a
22:32:49petertodd:could be true! like I say, this isn't set in stone and I suspect we're going to find a number of incentives edge cases that weaken security in cases from wht we'd really like
22:33:19Taek42:cool. Out of personal interest I'm going to do the math on that, let you know what I find
22:33:33petertodd:cool! I'd love to see how some people approach this formally
22:43:33Taek42:petertodd I don't think you've explained how rewards work on the child chains (looking at the bitcoin-dev mailing list from March). Do you have a system, or am I at liberty to construct one?
22:50:40petertodd:Taek42: I've got ideas, but no formal system yet - feel free to think of one!
22:50:58petertodd:Taek42: I highly suspect more than one system is a good idea for diversities sake
22:51:43Taek42:what do you mean by that? diversity at a theoretical level or also at an implementational one?
22:52:23petertodd:I mean, if hashing power is being paid for by multiple uses of the system it becomes harder for an attacker to profit by 51% attacking the entire system
22:53:13petertodd:the hope is an attacker can only profit by disrupting a small number of users, while a large number of users are paying into the security of the system
22:54:47Taek42:ah. so child chains don't necessarily follow the same rules? Can a parent have more than two children? (was looking at this from the perspective of a uniform set of rules)
22:55:15petertodd:oh, there are no rules! it's just a proof-of-publication mechanism - all the rules happen on the clients
22:55:31petertodd:I would like there to be enforcable rules - liek bitcoin - but I can't figure out any really robust way of doing that
22:55:47petertodd:after all, from "no-rules" you can always soft-fork in rules later when you figure out how to :)
22:57:14Taek42:ok. Can each parent have an arbitrary number of children?
22:57:35petertodd:no, one child, either left or right, forming a binary prefix tree
22:58:22Taek42:ok. So I have this new protocol, and I want to add it to the tree-chain. How do I do that?
22:58:36Taek42:we'll call it 'bitcoin'
22:59:01petertodd:write clients that publish/interpret data similar, dumbest possible way would be similar to mastercoin where you scan the whole chain for the consensus-related data
22:59:26petertodd:smarter is you do things such that certain actions - spending a txout - are restricted in their consensus domain to a certain part of the overall tree
22:59:58petertodd:that allows users to pass around (ever growin) proofs that some asset is valid that show that the actions required were published correctly in the right parts of the tree
23:00:20petertodd:Taek42: you ever read my paper on disentangling crypto-coin minigng?
23:00:29Taek42:I don't think that I have
23:02:26amiller_:petertodd, do you have to actually seen the data underlying a hash in order to mine on it in treechains
23:02:40amiller_:(like you're assumed to have donein bitcoin)
23:03:08petertodd:amiller_: yeah, we'll have to force that in some way - bitcoin itself is broken in that respect
23:07:52amiller_:maybe you want to combine treechains with a permacoin-style puzzle
23:09:03Taek42:permacoin puzzles to prove you're storing the block history?
23:09:06amiller_:okay so suppose your proof of work does require that you've seen all the underlying data, that's a good way of institutinoalizing it
23:09:15amiller_:not hte block history in this case, but the data in the current/new block
23:09:28sipa:petertodd: speach? :p
23:09:35sipa:that's talk about peaches?
23:10:25amiller_:"freeze peach" might be a good cocktail
23:10:30petertodd:amiller_: yup, and one subtlety is that you really want verifying the PoW to verify for sure that the PoW creator really did have that data - lots of schemes to do that actually fail on that point
23:10:57petertodd:sipa: lololo, hooked on phonics didn't work for me...
23:11:05amiller_:petertodd, okay well im pretty confident permacoin is good for that
23:11:17sipa:petertodd: hey, *you're* the arts major
23:11:33sipa:sorry for offtopicness!
23:11:59petertodd:sipa: fine arts is a pre-requisit to fully understanding crypto-currencies
23:12:05sipa:petertodd: to prevent bitcoin mining without having the block data we just need UTXO commitments, of course *ducks*
23:12:26petertodd:sipa: I'm worried that UTXO commitments will make that problem worse, not better, actually
23:12:54sipa:that i don't understand
23:13:47amiller_:okay so storage-pow over current block incentivizes having that block, storage-pow over previous blocks also incentivizes publishin those blocks to whoever comes next, excpet for selifsh mining style attacks
23:13:47petertodd:sipa: because you can so easily provide proof that the delta to the UTXO set from the previous block is correct, allowing people to skip further back
23:14:21amiller_:i dunno, then what, i dont see what to reason about what comes next in treechains
23:14:40Taek42:I'm still confused about when a child chain comes into existence. First it's just 'A', with no children and all the data... then ???, then A has 2 children b and c.
23:15:25petertodd:amiller_: what do you mean about "what comes next"?
23:15:47petertodd:Taek42: well it's merge-mining basically, but constrained
23:16:09amiller_:petertodd, help me understand treechain in the form of assumptions and achieved invariant
23:16:46Taek42:so basically A gets a child whenever a miner decides to mine a child?
23:17:11petertodd:amiller_: ah, did you see my #Bitmessage suggestion for a 'v0.0' use-case?
23:17:35amiller_:yeah i think so but that didn't help me get it much better
23:18:43petertodd:Taek42: so, to mine a child, you attempt to mine the top block, a child of that, a child of that, etc. depending on what PoW you find, some level down from the top is valid (or the top itself!)
23:19:09petertodd:Taek42: each level refers to the previous block that you consider valid at that depth
23:21:03amiller_:lets say we just make a storage blockchain coin where you can add as much "data" in a block as you want
23:21:10amiller_:transacions are just there for fees if necessary i guess
23:21:16amiller_:what do you get with trees that you don't get otherwise?
23:22:14petertodd:amiller_: scaling - if it's just one blockchain there is a one-size-fits-all scalability situation
23:22:34petertodd:amiller_: now if it weren't for centralization concerns, yeah, a single infinite max size blockchain would be best
23:23:21amiller_:ok let me try to work centralization back into the assumptions + invariant frameowrk
23:23:49amiller_:one way is to assume that someone has some maximum capacity of some resource and they can't just get more than that
23:24:11amiller_:another one i like is to basically say people have some number of lottery tickets they're willing to buy with their week's paycheck
23:25:38amiller_:i'm not really sure yet what you have in mind whats your centralization/decentralization modell
23:25:55petertodd:well, basically I want the overhead cost of solo mining to be as close to zero as possible; certainly not high
23:26:56amiller_:there's not much overhead if you don't include any transactions
23:27:06amiller_:like that kind of overhead e.g. checking
23:27:14amiller_:i think you're also talking about upstream + downstream bandwidth though too
23:27:20petertodd:amiller_: yes, but I'm talking about overhead of mining profitably - w/o transactions you're not profitable
23:28:32Taek42:is there anything stopping a miner from intentionally bloating the root chain?
23:28:58petertodd:Taek42: yes, blocks should have a max blocksize and fixed block interval
23:29:48amiller_:okay i dont really undersatnd the transaction + profitability model
23:30:03amiller_:are you assuming optional fees and that's all basically the way bitcoin is
23:30:30petertodd:amiller_: I'm assuming that including data in the blockchain somehow earns you money, exactly how is hard to say
23:30:41petertodd:(probably will be more than one way!)
23:30:59amiller_:okay so including data earns you more money
23:31:21petertodd:but it also costs everyone else money
23:31:53amiller_:okay so given that what's the difference between treechain world and blockchain world
23:32:12petertodd:to a first approximation, no difference at all: data gets provably published and that's that
23:32:36petertodd:but if demand for publishing >> supply (blocksize limit!) we need a way to meet that demand
23:33:42amiller_:okay so lets see vs removed blocksize limit
23:33:45amiller_:but still chain
23:34:12Taek42:do treechains have coins? Or is the reward for publishing coming from an external source?
23:34:12amiller_:with tree chain as i miner i have an option of including transaction data in my block and you want to see if its overhead vs not including it
23:34:33petertodd:Taek42: assume reward from external source for now
23:35:13petertodd:so without a blocksize limit, the cost to mine is hashing power and overhead, and overhead/hash is reduced when you are a larger miner than smaller
23:36:44amiller_:alright im familiar with that argument assuming the overhead is based on transmission basically
23:36:53petertodd:that creates a centralization spiral and leads to Bad Things
23:37:22amiller_:okay i think the stage is set now what is different in tree chain world
23:37:25petertodd:yeah, overhead ~= blocksize is a perfectly reasonable assumption, and covers transmission, storage, etc. etc.
23:37:39amiller_:storage goes away when you have pow-puzzle
23:38:10amiller_:but transmission sure
23:38:22petertodd:in the treechain world because the blockchain is split up into a binary tree, overhead is approx fixed (grows logorithmetically w/ entire blockchain size)
23:38:51petertodd:the tradeoff being that you may have less security at a deeper part of the tree
23:38:56amiller_:the overhead is proportional to the number of transactions in my block isn't it
23:39:01petertodd:amiller_: yes
23:39:02amiller_:i think i diverged from you earlier
23:39:12amiller_:you were talking about overhead including receiving all the blocks from someone else even ones you haven't mined
23:39:18amiller_:i was only thinking about the choice of include more tx vs include no more x
23:39:35petertodd:yeah, overhead has to include everything related to keeping up with the chain
23:39:36amiller_:my overhead is zero if i disregard the history and include no tx
23:39:50petertodd:yes, and such a system has no security and no profit for you :)
23:40:04amiller_:with por-puzzle over the whole history + the newest block that gets better i guess
23:41:00amiller_:okay i dont get it
23:41:02petertodd:yes, but por-puzzle means that minimum reqs to mine keep increasing - eventually people are shut out of the mining game
23:41:29amiller_:petertodd, okay so in tree chain do you have to receive all the blocks
23:41:38amiller_:all the data in all the blocks
23:41:47amiller_:if someone doesn't have to receive all the data in all the blocks, in what sense is it proof of publication
23:42:04petertodd:amiller_: no, you only have to receive blocks in a specific part of the tree, all the top blocks, all the blocks in *one* child under that, again under that and so on
23:42:31petertodd:amiller_: so data in the top block is proven published to everyone, in the child under that proven published to half of everyone, a quarter of everyone etc.
23:43:11amiller_:okay half of everyone...
23:43:18amiller_:how do i decide which blocks i'm supposed to receive?
23:43:22amiller_:or who to send which blocks to?
23:43:35amiller_:bits of public key?
23:43:41amiller_:ip addr?
23:43:46amiller_:or choice
23:43:57petertodd:amiller_: read my disentangling crypto-coin mining paper?
23:44:57amiller_:several times, will try again, haven't grokked it yet
23:45:43petertodd:anyway, a key concept there is the idea of a consensus domain: if I have a txout, the only people who care whether or not I spend that txout are the people who might want to accept a payment based on it
23:46:08petertodd:whereas in bitcoin every single person in the system finds out about that spend, or to be exact, my proven-published-data about that spend
23:47:04amiller_:so you don't "publish" to everyone, you publish to people who care for external reaosn?
23:47:27petertodd:right... but since we can't figure out how to do *that*, instead we just arbitrarily split up the tree
23:47:52amiller_:and all the tx i care about are in the same part of the tree?
23:48:10petertodd:e.g., for the consensus domain, we could use the hash of the txid as a prefix, and then figure out some max depth in which to publish, so any block in the tree up to that depth and with that prefix (binary remember!) may contain the spend
23:48:35amiller_:that answers whree the tx goes in the tree, but not which miners have to validate which part of the tree
23:48:57amiller_:i.e. if you are using por-puzzle to make sure people are checking what they're suppsoed to check, then the por-puzzle has to refer to only the particular subtre
23:49:08petertodd:ah, well basically mining == validation == proving you were in posession of some data, and *nothing else*
23:49:13amiller_:yeah i got that
23:49:20amiller_:but which of the data
23:49:26amiller_:you said half the people look at half the data
23:49:39amiller_:so what prevent 100% of the people from looking at the same half of the data in the second layer
23:49:46petertodd:so as a miner, pick some part of the tree, and merge-mine blocks up to some depth along that path
23:49:54amiller_:so its miners choice
23:50:11petertodd:well, I'm thinking you could make a consensus rule be that blocks can only be created on alternating sides
23:50:43amiller_:all the way down the tree?
23:50:55amiller_:so if i'm storing something at the last layer, it only helps me once in a year?
23:51:33petertodd:amiller_: ah, but that only needs to apply for *valid* blocks, invalid ones (because they don't meet the difficulty) don't have to follow that rule
23:52:36amiller_:so miners can choose whichever leaves they want to store
23:52:43amiller_:and um
23:53:07petertodd:well they need to store leaves such that they can meet the proof-of-storage requirement
23:53:50amiller_:yeah but you said they can't be required to store more leaves or the minimum cost increases
23:54:34amiller_:i guess i will imagine one little guy who has enough capacity to keep up with the main blockhcain and a single path
23:54:53petertodd:ah, but see, for effective hashing, you only need to store a log-sized set of leaves down some path in th etree
23:55:15petertodd:storing more than a single path has rapidly diminishing returns in terms of extra profitability
23:55:20amiller_:okay so one path
23:55:36petertodd:yup, because each attempt at a pow is only valid for a single path
23:56:45amiller_:okay so then what prevents everyone from all choosing the same path
23:57:12amiller_:i think you are going to say that alternating thing
23:57:21amiller_:but that just means the small guy here has to turn off his miner every other block interval
23:57:39amiller_:(or mine at lower effectiveness due to his attempts only being valid for "consolation prizes" but not the grand prize at hte top layer)
23:58:55petertodd:the "choosing the same path" thing is a function of what's profitable, and the *users* of the system should use it in such a way that data that needs to be published is distributed randomly in the tree
23:58:59Taek42:it seems like you'd want the child blocks to have their own difficulty, so that child chains can have the same blockrate as their parents, even though only ~ every other block is going to be included in the parent
23:59:10petertodd:you can incentivise that by the fact that you get faster confirms on average due to the even/odd rule
23:59:30amiller_:i'm not asking about what incentivizes people to put their transactions in which place in the tree, but which miners choose
23:59:33amiller_:miners who can store the hwole thing
23:59:46amiller_:can more easily switch position to take advantage of changing profitability if some partsof tree are more profitable than others