| 00:40:08 | lnovy: | lnovy is now known as zz_lnovy |
| 00:47:07 | zz_lnovy: | zz_lnovy is now known as lnovy |
| 00:52:47 | _Iriez: | _Iriez is now known as Iriez |
| 01:21:30 | wallet42: | wallet42 is now known as Guest69807 |
| 01:21:30 | wallet421: | wallet421 is now known as wallet42 |
| 03:58:39 | amiller_: | petertodd, you're implementing *colored coins* for some reason? |
| 03:59:45 | petertodd: | amiller_: yup, basic idea has a huge amount of simularities to schemes that treechains would use you know |
| 04:00:28 | amiller_: | idont see that similarity yet but it's interesting |
| 04:00:59 | sipa: | the similarity is that both needs the sender to provide proofs of the input coin's history? |
| 04:01:07 | petertodd: | sipa: exactly |
| 04:01:24 | amiller_: | ok that part is pretty clear enough |
| 04:01:26 | petertodd: | getting $$$ to write that code and explore the ideas is something I'm all for |
| 04:02:56 | amiller_: | tokay |
| 04:03:17 | petertodd: | 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:43 | amiller_: | centralized but with accounting on the blockchain? that's interesting but i dont get it yet |
| 04:03:57 | amiller_: | colored coins has really poor spv but maybe that doesn't matter |
| 04:04:14 | petertodd: | 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:23 | petertodd: | also, I've got a few reasonable approaches re: spv |
| 04:06:05 | amiller_: | go on? |
| 04:07:12 | petertodd: | 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:11 | amiller_: | ok for a new comer to check that all those merkleed trees are accurate seems expensive |
| 04:08:20 | petertodd: | amiller_: it's a trusted issuer :) |
| 04:08:24 | amiller_: | uhg |
| 04:08:36 | amiller_: | trusted issuer should just store his own ledger and publish it maybe every so often |
| 04:08:51 | petertodd: | amiller_: by definition the merkle tree is accurate! equally, checking ledgers is expensive |
| 04:10:25 | petertodd: | 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:35 | amiller_: | 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:44 | petertodd: | 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:45 | amiller_: | so trusted issuer, why bother with blockchain |
| 04:12:21 | petertodd: | amiller_: you can ask the question why public companies don't keep track of stock issuances/ownership themselves... |
| 04:12:54 | amiller_: | 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:26 | petertodd: | 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:02 | amiller_: | 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:18 | petertodd: | amiller_: |
| 04:17:31 | petertodd: | amiller_: "expensive and vulnerable to dos" <- no more than bitcoin... |
| 04:17:47 | petertodd: | also, you don't need colored coins nodes in how we've architected it |
| 04:18:11 | amiller_: | ok im curious what |
| 04:19:19 | petertodd: | 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:05 | amiller_: | is the issuer punsihed if it fails to prune periodically |
| 04:20:18 | amiller_: | it seems like if it's doing periodic stuff, it can just run its own ledger |
| 04:20:21 | petertodd: | sure, they're customers complain, not a big deal |
| 04:20:33 | amiller_: | right so it ignores its customers because that's not something it's really promsid to do |
| 04:20:46 | petertodd: | periodically running some script on an *offline* machine is *way* easier than having a 24/7 available online ledger |
| 04:21:48 | petertodd: | 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:12 | petertodd: | sorry, but business needs trump purity anyday... |
| 04:22:47 | amiller_: | ok so |
| 04:23:12 | amiller_: | the (semitrusted) issuer reissues in batches to avoid the growing proof complexity |
| 04:23:30 | petertodd: | yup |
| 04:24:00 | petertodd: | in the future this may become "SCIP MAGIC IS MAGIC" |
| 04:25:29 | amiller_: | so frustrated at scip being misused that way, snarks is a crypto term scip is a project name that implemented snarks second |
| 04:25:46 | petertodd: | amiller_: don't get snarky at me |
| 04:26:23 | amiller_: | ok with cheap snarks yeah colored coins no problem anyway |
| 04:27:13 | petertodd: | 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:37 | petertodd: | not pretty and pure... but issuers think it's a total non-issue |
| 04:29:18 | amiller_: | issuers gonna ish |
| 04:29:34 | amiller_: | okay that all makes sense just wanted to check what you were aiming for |
| 04:29:44 | kanzure: | couldn't there be some non-distributed-blockchain software for issuers to run? |
| 04:30:00 | sipa: | kanzure: yes, it's called accounting software |
| 04:30:04 | kanzure: | they seem willing to run spv nodes, apparently, so why not something else? |
| 04:30:29 | petertodd: | kanzure: issuers aren't willing to do *anything* that requires any particular uptime |
| 04:30:43 | petertodd: | kanzure: it's the users who are running the spv nodes - that is, wallet software |
| 04:30:55 | kanzure: | but they are an issuer! they should have 100% uptime for the windows during which they are offering redemption etc. |
| 04:31:22 | petertodd: | kanzure: uptime for when you offer redemption != uptime for when people trade assets around |
| 04:31:26 | gmaxwell: | redemption? ... is that something that happens during the mysterous step 2? |
| 04:31:50 | kanzure: | 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:04 | petertodd: | 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:31 | gmaxwell: | So what phase does that happen in? (1) Issue underpants, (2) ???, (3) Profit! |
| 04:33:11 | petertodd: | gmaxwell: if you're wikileaks, and want to hold USD rather than BTC, outsourcing redemption is a lovely thing |
| 04:34:49 | gmaxwell: | I'm skeptical, but happy to see people trying things in any case. |
| 04:34:56 | kanzure: | i wonder what sort of downtime for transaction ledgering is acceptable to the majority of would-be issuers |
| 04:35:35 | petertodd: | 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:42 | petertodd: | kanzure: ~0% |
| 04:36:33 | petertodd: | 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:10 | moa: | sounds a lot like philosophy around Open transactions or earlier Truledger |
| 04:38:21 | kanzure: | i don't think it sounds like open transactions |
| 04:39:20 | kanzure: | "hey signing is involved therefore it must be like open transactions" |
| 04:39:43 | moa: | with some bolt on bitcoinesque baubles |
| 04:43:00 | kanzure: | 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:25 | amiller_: | ot forgot to do any crypto |
| 04:47:08 | petertodd: | ot forgot to ship an actual useful application |
| 04:47:43 | gmaxwell: | To be fair, this is a time tested approach in the field of cryptocurrency. |
| 04:48:14 | kanzure: | "welcome to the wonderful business of lemons"? |
| 04:48:25 | petertodd: | ...and by tested, you mean "every time we did this, the test results said we failed" |
| 04:48:39 | petertodd: | "maybe this time we'll get lucky?" |
| 04:49:25 | kanzure: | there should be a general merkle proof tree library thing for slinging proof trees together. hrm. |
| 04:49:35 | Taek42: | * Taek42 feels confused by all the cynicism |
| 04:49:48 | petertodd: | kanzure: https://github.com/petertodd/python-merbinnertree |
| 04:49:58 | gmaxwell: | http://xkcd.com/242/ |
| 04:50:00 | kanzure: | next i would like petertodd to deliver me a burrito |
| 04:50:01 | petertodd: | kanzure: note how it even has a made-up name that is googlable! |
| 04:50:18 | petertodd: | kanzure: http://idlewords.com/2007/04/the_alameda-weehawken_burrito_tunnel.htm |
| 04:50:50 | gmaxwell: | <3 the burrito tunnel |
| 04:50:52 | kanzure: | my last wish is 3 more wishes |
| 04:51:01 | petertodd: | kanzure: granted |
| 04:51:36 | gmaxwell: | ^ good news |
| 04:52:33 | gmaxwell: | 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:59 | kanzure: | this place is rough |
| 04:53:09 | kanzure: | provably rough |
| 04:53:22 | amiller_: | kanzure, https://github.com/amiller/lambda-auth |
| 04:53:37 | petertodd: | kanzure: unfortunately the proof isn't transferable to third parties, and must be experienced in person |
| 04:54:08 | gmaxwell: | hm. should invent an asymetric cryptosystem that is provably secure so long as there is no efficient algorithim for sorting integers. |
| 04:54:13 | kanzure: | so merbinnertree only proves the presence of a key in the original data struct? |
| 04:54:32 | petertodd: | kanzure: or not presence (a merkle tree only proves presence) |
| 04:55:04 | kanzure: | what about key-mapped values? |
| 04:55:19 | kanzure: | i see that values are accepted in the functions here, but i don't know what happens to them =) |
| 04:55:22 | petertodd: | kanzure: merbinner tree is a key:value map |
| 04:56:09 | petertodd: | kanzure: proves the statements "key -> value" and "key -> ⊥" |
| 04:56:50 | amiller_: | 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:30 | petertodd: | 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:56 | amiller_: | simplicity is relative and i like my name :) |
| 04:58:21 | petertodd: | 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:28 | amiller_: | yeesh |
| 04:58:41 | kanzure: | and instead? |
| 04:59:01 | petertodd: | kanzure: the features that depend on it are just going to get delayed, nothing fancy |
| 04:59:29 | petertodd: | 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:04 | petertodd: | ∫ |
| 05:01:34 | petertodd: | * petertodd should use a console other than IRC chat to see what unicode symbols look like on his terminal... |
| 05:34:44 | phantomcircuit: | petertodd, lol that's short sighted |
| 05:34:52 | phantomcircuit: | i had someone implement it in c |
| 06:32:16 | Ded: | Ded is now known as Aquent |
| 06:33:35 | petertodd: | phantomcircuit: ? |
| 06:33:56 | petertodd: | phantomcircuit: oh, you mean leaving our the merbinner tree stuff? yeah, that's just a delay of a few weeks or so |
| 06:34:05 | petertodd: | phantomcircuit: repo for the C version? |
| 06:35:45 | phantomcircuit: | petertodd, isn't one |
| 06:35:54 | phantomcircuit: | currently a "email me that" project |
| 06:36:17 | petertodd: | phantomcircuit: lol, well "email me that" :) |
| 06:36:32 | petertodd: | phantomcircuit: I should do up some data-driven test-cases ASAP |
| 08:05:17 | holmes.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:17 | holmes.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:17 | holmes.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:18 | holmes.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:18 | holmes.freenode.net: | Users on #bitcoin-wizards: phantomcircuit nsh- sipa asoltys |
| 16:06:13 | nessence_: | nessence_ is now known as nessence |
| 16:30:21 | Guyver2: | Guyver2 has left #bitcoin-wizards |
| 17:27:19 | Drefenor: | Drefenor has left #bitcoin-wizards |
| 18:03:41 | amiller_: | petertodd, you should look into VerSum |
| 18:04:00 | amiller_: | it's actually a really good way of doing more complicated proofs based on data in bitcoin blockcain |
| 18:04:18 | amiller_: | it's really efficient, more so than checking acolored coin proof or whatever |
| 18:04:25 | amiller_: | the catch is that it relies on an "any trust" server model |
| 18:04:26 | kanzure: | this? http://people.csail.mit.edu/nickolai/papers/vandenhooff-versum.pdf |
| 18:04:31 | amiller_: | kanzure, yep |
| 18:04:49 | amiller_: | it will be presented at CCS (swanky academic security conference) later this year |
| 18:05:23 | amiller_: | youhave to query some number of N servers |
| 18:05:23 | amiller_: | if *even one of them* is giving you honest results, you can figure out which one it is |
| 18:05:54 | amiller_: | 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:45 | amiller_: | its a really great use of authenticated data structures i wish i thuoght of |
| 18:24:00 | jgarzik: | amiller_, andytoshi, gmaxwell: Does anyone have any Nicholas Courtois refutations lying around? |
| 18:24:29 | jgarzik: | Journos are emailing, and giving him tons of credibility (5800 Google Scholar citations!!!) |
| 18:25:21 | amiller_: | about what? |
| 18:25:24 | amiller_: | refuting him generally? |
| 18:25:43 | amiller_: | oh eprint The Unreasonable Fundamental Incertitudes Behind Bitcoin Mining http://arxiv.org/abs/1310.7935 |
| 18:26:54 | kanzure: | "More importantly, the specification is likely to change" ? |
| 18:27:05 | amiller_: | omfg this is an arxiv paper that cites the dakami bet? |
| 18:27:16 | kanzure: | hahah |
| 18:27:27 | kanzure: | this is just random strings of words put together |
| 18:27:36 | sipa: | i don't understand the abstract |
| 18:27:43 | kanzure: | gish gallop |
| 18:27:45 | sipa: | it says conflicting things |
| 18:29:36 | jgarzik: | amiller_, Yep that's the one, http://arxiv.org/abs/1310.7935 |
| 18:29:38 | amiller_: | 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:14 | amiller_: | so they're proposing a modified reward formula and a different pow i guess |
| 18:30:59 | amiller_: | " 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:11 | amiller_: | tons of altcoins *have* used different PoW and altered reward schemes |
| 18:31:25 | amiller_: | Dogecoin changed their reward schedule mid stream due to implementation bugs |
| 18:31:52 | gmaxwell: | jgarzik: there is a thread on bitcoin talk that tares into it some. I can't believe anyone would cite it. |
| 18:32:45 | gmaxwell: | Regardless of the merits of the arguments the writing seems generally unhinged. (e.g. switching at random into bold allcaps) |
| 18:34:40 | jgarzik: | gmaxwell, This CoinDesk journo is using total citations of the person as a metric for credibility :/ |
| 18:34:54 | jgarzik: | "Courtois (not his paper) has 5800 Google Scholar citations!" |
| 18:35:12 | amiller_: | 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:21 | jgarzik: | and then "why are bitcoin core devs being assholes and ignoring an obvious scholar?" |
| 18:35:22 | jgarzik: | etc. |
| 18:35:24 | fluffypony: | wasn't he the idiot that wrote that paper "on the longest chain rule" ? |
| 18:35:30 | kanzure: | 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:30 | jgarzik: | fluffypony, yep, that's the one |
| 18:35:42 | fluffypony: | oh lord... |
| 18:35:56 | sipa: | he gives the reason why such a change won't happen in the abstract: the community would reject it |
| 18:36:11 | amiller_: | is there any evidence that their SHA2 mining optimizations are any better than actual bitcoin mining asics? |
| 18:36:16 | amiller_: | or is it just vs naive sha2 circuit? |
| 18:36:16 | gmaxwell: | 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:34 | gmaxwell: | fluffypony: yes |
| 18:36:50 | amiller_: | "Remark 3. We ignore if recent mining devices already use Fact 12.1 which developers could have discovered independently" |
| 18:36:50 | fluffypony: | gmaxwell: maybe AnonyMint == Curtois, wouldn't that be a twist :-P |
| 18:36:59 | gmaxwell: | Weird! |
| 18:37:02 | amiller_: | they are almost certainly reinventing obvious optimizations that the industry of mining asics is taking advantage of |
| 18:37:11 | amiller_: | " We have noticed that the Swedish |
| 18:37:11 | amiller_: | company KNCminer have explained in some Internet forums that they do indeed |
| 18:37:11 | amiller_: | use some optimizations [39] which allow them to" |
| 18:37:51 | sipa: | "Hi! We're publishing a paper on technology well-known in the industry, but hey, nobody published them yet, so why not!" |
| 18:38:10 | gmaxwell: | 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:25 | amiller_: | they are explicitly showing a small constant factor |
| 18:38:43 | gmaxwell: | yea, so who cares? differential power price is likewise. |
| 18:39:13 | gmaxwell: | 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:21 | kanzure: | jgarzik: unfortunately i don't know of a good defense against this |
| 18:39:52 | kanzure: | jgarzik: do the journos want some other papers to read? are they even going to read any of them? |
| 18:40:33 | jgarzik: | kanzure, probably not |
| 18:40:44 | fluffypony: | 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:57 | jgarzik: | kanzure, they want a quote from Courtois, quote from bitcoin dev, etc. probably cannot even parse the abstract. |
| 18:41:05 | jgarzik: | typical journo pattern |
| 18:41:29 | kanzure: | 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:24 | kanzure: | sentences switch topic and don't justify each other :/ |
| 18:49:25 | justanotheruser: | can you link me to this paper? Is it just an altcoin "whitepaper" |
| 18:49:30 | jgarzik: | scroll up |
| 18:49:45 | justanotheruser: | jgarzik: I don't think I was in here. |
| 18:49:49 | justanotheruser: | * justanotheruser goes to online logs |
| 18:50:00 | kanzure: | you were in here |
| 18:50:05 | jgarzik: | * justanotheruser (~Justan@unaffiliated/justanotheruser) has joined #bitcoin-wizards |
| 18:50:06 | jgarzik: | amiller_, Yep that's the one, http://arxiv.org/abs/1310.7935 |
| 18:50:55 | justanotheruser: | my bad |
| 18:51:11 | kanzure: | 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:43 | jgarzik: | Yeah, my usual reaction of "goddamn this work sucks" isn't very productive |
| 18:52:05 | fluffypony: | 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:13 | amiller_: | point out this hasn't been peer reviewed at all jgarzik |
| 18:52:28 | kanzure: | peer review is overrated, just don't be an idiot and you can get away without peer review in some cases |
| 18:52:41 | amiller_: | that's true too tbh |
| 18:53:08 | sipa: | the right peer review is very valuable :) |
| 18:53:16 | kanzure: | sure, i shouldn't have made such a strong statement |
| 18:53:18 | tacotime: | yeah, it depends on the journal |
| 18:53:21 | kanzure: | it does have value |
| 18:54:16 | kanzure: | fluffypony: unfortuately "we encourage academic study into x" can be interpreted as an endorsement |
| 18:54:39 | tacotime: | 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:55 | fluffypony: | 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:02 | tacotime: | like when andytoshi destroyed a proposed improvement to our ring sig algorithm. :) |
| 18:55:02 | jgarzik: | amiller_, yeah, That's where I'm currently at, in fact: |
| 18:55:09 | kanzure: | "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:12 | justanotheruser: | Their abstract says so much but says so little |
| 18:55:14 | jgarzik: | "You [coindesk journo] completely avoided the issues raised in my message. |
| 18:55:14 | jgarzik: | Who, specifically, peer-reviewed Courtois' latest paper, and reached |
| 18:55:14 | jgarzik: | the same conclusions as Courtois? |
| 18:55:14 | jgarzik: | I'm not talking about other unrelated papers that Google Scholar links." |
| 18:55:27 | jgarzik: | Previous email lectured journo on the scientific method & process. |
| 18:55:28 | jgarzik: | ;p |
| 18:55:34 | justanotheruser: | they have a giant abstract only to finally cover the fact that they don't like the 4 year halving |
| 18:55:42 | kanzure: | it is important to emphasize that reading a paper and properly reviewing it takes a long time |
| 18:56:04 | kanzure: | and by definition nobody on the planet has picked apart this paper yet |
| 18:56:17 | kanzure: | 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:21 | jgarzik: | kanzure, definitely good responses |
| 18:56:33 | jgarzik: | though I think some of the hand-waving and ALL CAPS EMOTION should be highlighted |
| 18:57:08 | justanotheruser: | "There |
| 18:57:08 | justanotheruser: | were also major cyber attacks with concrete exploits against bitcoin software |
| 18:57:11 | justanotheruser: | and systems, see [10]. In just once such incident 17000 BTC were lost |
| 18:57:16 | justanotheruser: | what is this referring to? |
| 18:57:30 | justanotheruser: | an actual reference client bug? |
| 18:59:18 | justanotheruser: | I see bitomat losing their coins, but thats not an exploit... |
| 19:27:59 | Dizzle__: | Dizzle__ is now known as Dizzle |
| 19:43:05 | phantomcircuit: | jgarzik, that guy is such a dick |
| 20:03:13 | Taek42: | 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:44 | dpk: | .privacy |
| 20:15:44 | yoleaux: | 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:15 | dpk: | kanzure: let me know if the channel message privacy stuff changes |
| 20:16:25 | kanzure: | yep |
| 20:17:07 | dpk: | dpk has left #bitcoin-wizards |
| 20:18:13 | CoinMuncher: | 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:48 | CoinMuncher: | It's too bad half of the audience took him seriously. |
| 20:20:11 | fluffypony: | could be worse - at least he didn't say "when I release *my* coin..." |
| 20:21:19 | CoinMuncher: | CourtoisCoin |
| 20:21:35 | justanotheruser: | CoinMuncher: he said do away with the blockchain? |
| 20:21:39 | justanotheruser: | what did he suggest? |
| 20:21:41 | kanzure: | CoinMuncher: you may be experiencing irc message length cutoff due to misconfigured client stuff |
| 20:22:03 | CoinMuncher: | hmm... I'll cut it up |
| 20:22:12 | CoinMuncher: | 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:34 | fluffypony: | well now he's gone to CoinDesk |
| 20:22:40 | fluffypony: | because they're completely unbiased. |
| 20:22:41 | CoinMuncher: | (using pidgin, I'll try to do some research on max length) |
| 20:23:29 | justanotheruser: | CoinMuncher: sounds like an uninformed person too confident for their own good |
| 20:23:50 | kanzure: | you shouldn't judge his confidence at all |
| 20:24:24 | Taek42: | CoinMuncher looks like 448 chars is your limit |
| 20:24:36 | justanotheruser: | kanzure: he was confident enough to deny reason in favor of his own idea |
| 20:27:52 | CoinMuncher: | 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:41 | helo: | that is pretty silly |
| 20:35:05 | helo: | (courtois) |
| 20:35:15 | helo: | how would coindesk take him seriously? |
| 20:36:25 | helo: | he has done some awesome crypto work, but i guess just completely missed the point |
| 20:36:53 | helo: | (of blockchain) |
| 20:39:42 | CoinMuncher: | 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:11 | Luke-Jr: | well, there might be better curves we could use, but that's kinda beside the point |
| 21:15:01 | tromp: | Vitalik has another blog entry on PoS; https://blog.ethereum.org/2014/10/03/slasher-ghost-developments-proof-stake/ |
| 21:16:46 | tromp: | he seems to think that any problem can be overcome with additional complexity |
| 21:31:43 | tacotime: | "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:47 | tacotime: | That about sums it up |
| 21:31:59 | andytoshi: | 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:29 | helo: | from an outsider's perspective, i'm afraid their arguments make just as much sense as ours |
| 21:36:26 | amiller_: | even to an insider i think all the arguments on both sides are fragile |
| 21:36:52 | tacotime: | the nice thing about most of our arguments is that bitcoin has succeeded from virtually nothing and already works. |
| 21:37:14 | andytoshi: | i think if you start with an unstated assumption that relativity of simultaneity is wrong, your argument is garbage |
| 21:37:24 | andytoshi: | not fragile |
| 21:37:34 | helo: | yep |
| 21:37:58 | helo: | but an outsider won't even invest that much work into comprehending either argument |
| 21:38:06 | andytoshi: | (ofc, agree that the arguments in favour of hashpower sigs providing a consensus are fragile!) |
| 21:38:14 | helo: | and just say "that sounds weird *shrug*" |
| 22:13:06 | petertodd: | 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:00 | petertodd: | 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:26 | petertodd: | 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:00 | Eliel: | petertodd: blown in what sense? :) |
| 22:18:24 | petertodd: | Eliel: "blown"? |
| 22:18:44 | Eliel: | "academics minds are going to be blown" |
| 22:19:09 | petertodd: | Eliel: oh, in reference to academics complaining about the inflation schedule |
| 22:19:31 | petertodd: | Eliel: point is, we have way less coercion ability with regard to this stuff than people like to assume |
| 22:20:11 | Eliel: | ah, yes, you mean the market decides the monetary policy, not someone in a high chair. |
| 22:20:33 | petertodd: | Eliel: exactly! |
| 22:21:31 | Taek42: | 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:15 | petertodd: | 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:00 | Taek42: | I suppose it's more of a problem when your tree is N layers deep |
| 22:24:12 | Taek42: | makes sense then |
| 22:24:38 | petertodd: | exactly, the tree can be many, many layers deep :) |
| 22:25:33 | Taek42: | 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:52 | Taek42: | how does b2 - b5 get mined, and what are the incentives for publishing them as you find them? |
| 22:26:41 | petertodd: | 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:01 | petertodd: | (<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:57 | Taek42: | (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:18 | Taek42: | 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:31 | petertodd: | 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:37 | Taek42: | 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:24 | petertodd: | 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:42 | Taek42: | 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:02 | Taek42: | IE it's easier for me to 50% attack 'b' if I ignore the rewards from a |
| 22:32:08 | Taek42: | *** c not a |
| 22:32:49 | petertodd: | 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:19 | Taek42: | cool. Out of personal interest I'm going to do the math on that, let you know what I find |
| 22:33:33 | petertodd: | cool! I'd love to see how some people approach this formally |
| 22:43:33 | Taek42: | 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:40 | petertodd: | Taek42: I've got ideas, but no formal system yet - feel free to think of one! |
| 22:50:58 | petertodd: | Taek42: I highly suspect more than one system is a good idea for diversities sake |
| 22:51:43 | Taek42: | what do you mean by that? diversity at a theoretical level or also at an implementational one? |
| 22:52:23 | petertodd: | 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:13 | petertodd: | 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:47 | Taek42: | 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:15 | petertodd: | oh, there are no rules! it's just a proof-of-publication mechanism - all the rules happen on the clients |
| 22:55:31 | petertodd: | 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:47 | petertodd: | after all, from "no-rules" you can always soft-fork in rules later when you figure out how to :) |
| 22:57:14 | Taek42: | ok. Can each parent have an arbitrary number of children? |
| 22:57:35 | petertodd: | no, one child, either left or right, forming a binary prefix tree |
| 22:58:22 | Taek42: | ok. So I have this new protocol, and I want to add it to the tree-chain. How do I do that? |
| 22:58:36 | Taek42: | we'll call it 'bitcoin' |
| 22:59:01 | petertodd: | 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:26 | petertodd: | 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:58 | petertodd: | 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:20 | petertodd: | Taek42: you ever read my paper on disentangling crypto-coin minigng? |
| 23:00:29 | Taek42: | I don't think that I have |
| 23:00:51 | petertodd: | https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg03307.html |
| 23:02:26 | amiller_: | petertodd, do you have to actually seen the data underlying a hash in order to mine on it in treechains |
| 23:02:40 | amiller_: | (like you're assumed to have donein bitcoin) |
| 23:03:08 | petertodd: | amiller_: yeah, we'll have to force that in some way - bitcoin itself is broken in that respect |
| 23:03:13 | amiller_: | okay |
| 23:07:52 | amiller_: | maybe you want to combine treechains with a permacoin-style puzzle |
| 23:08:05 | petertodd: | absolutely! |
| 23:09:03 | Taek42: | permacoin puzzles to prove you're storing the block history? |
| 23:09:06 | amiller_: | 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:15 | amiller_: | not hte block history in this case, but the data in the current/new block |
| 23:09:28 | sipa: | petertodd: speach? :p |
| 23:09:35 | sipa: | that's talk about peaches? |
| 23:10:25 | amiller_: | "freeze peach" might be a good cocktail |
| 23:10:30 | petertodd: | 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:57 | petertodd: | sipa: lololo, hooked on phonics didn't work for me... |
| 23:11:05 | amiller_: | petertodd, okay well im pretty confident permacoin is good for that |
| 23:11:17 | sipa: | petertodd: hey, *you're* the arts major |
| 23:11:33 | sipa: | sorry for offtopicness! |
| 23:11:59 | petertodd: | sipa: fine arts is a pre-requisit to fully understanding crypto-currencies |
| 23:12:05 | sipa: | petertodd: to prevent bitcoin mining without having the block data we just need UTXO commitments, of course *ducks* |
| 23:12:26 | petertodd: | sipa: I'm worried that UTXO commitments will make that problem worse, not better, actually |
| 23:12:54 | sipa: | that i don't understand |
| 23:13:47 | amiller_: | 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:47 | petertodd: | 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:21 | amiller_: | i dunno, then what, i dont see what to reason about what comes next in treechains |
| 23:14:40 | Taek42: | 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:25 | petertodd: | amiller_: what do you mean about "what comes next"? |
| 23:15:47 | petertodd: | Taek42: well it's merge-mining basically, but constrained |
| 23:16:09 | amiller_: | petertodd, help me understand treechain in the form of assumptions and achieved invariant |
| 23:16:46 | Taek42: | so basically A gets a child whenever a miner decides to mine a child? |
| 23:17:11 | petertodd: | amiller_: ah, did you see my #Bitmessage suggestion for a 'v0.0' use-case? |
| 23:17:35 | amiller_: | yeah i think so but that didn't help me get it much better |
| 23:18:43 | petertodd: | 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:09 | petertodd: | Taek42: each level refers to the previous block that you consider valid at that depth |
| 23:21:03 | amiller_: | lets say we just make a storage blockchain coin where you can add as much "data" in a block as you want |
| 23:21:10 | amiller_: | transacions are just there for fees if necessary i guess |
| 23:21:16 | amiller_: | what do you get with trees that you don't get otherwise? |
| 23:22:14 | petertodd: | amiller_: scaling - if it's just one blockchain there is a one-size-fits-all scalability situation |
| 23:22:34 | petertodd: | amiller_: now if it weren't for centralization concerns, yeah, a single infinite max size blockchain would be best |
| 23:23:21 | amiller_: | ok let me try to work centralization back into the assumptions + invariant frameowrk |
| 23:23:49 | amiller_: | 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:11 | amiller_: | 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:38 | amiller_: | i'm not really sure yet what you have in mind whats your centralization/decentralization modell |
| 23:25:55 | petertodd: | well, basically I want the overhead cost of solo mining to be as close to zero as possible; certainly not high |
| 23:26:56 | amiller_: | there's not much overhead if you don't include any transactions |
| 23:27:06 | amiller_: | like that kind of overhead e.g. checking |
| 23:27:14 | amiller_: | i think you're also talking about upstream + downstream bandwidth though too |
| 23:27:20 | petertodd: | amiller_: yes, but I'm talking about overhead of mining profitably - w/o transactions you're not profitable |
| 23:28:32 | Taek42: | is there anything stopping a miner from intentionally bloating the root chain? |
| 23:28:58 | petertodd: | Taek42: yes, blocks should have a max blocksize and fixed block interval |
| 23:29:48 | amiller_: | okay i dont really undersatnd the transaction + profitability model |
| 23:30:03 | amiller_: | are you assuming optional fees and that's all basically the way bitcoin is |
| 23:30:30 | petertodd: | amiller_: I'm assuming that including data in the blockchain somehow earns you money, exactly how is hard to say |
| 23:30:41 | petertodd: | (probably will be more than one way!) |
| 23:30:59 | amiller_: | okay so including data earns you more money |
| 23:31:07 | petertodd: | yup |
| 23:31:21 | petertodd: | but it also costs everyone else money |
| 23:31:53 | amiller_: | okay so given that what's the difference between treechain world and blockchain world |
| 23:32:12 | petertodd: | to a first approximation, no difference at all: data gets provably published and that's that |
| 23:32:36 | petertodd: | but if demand for publishing >> supply (blocksize limit!) we need a way to meet that demand |
| 23:33:42 | amiller_: | okay so lets see vs removed blocksize limit |
| 23:33:45 | amiller_: | but still chain |
| 23:34:12 | Taek42: | do treechains have coins? Or is the reward for publishing coming from an external source? |
| 23:34:12 | amiller_: | 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:33 | petertodd: | Taek42: assume reward from external source for now |
| 23:35:13 | petertodd: | 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:35:26 | amiller_: | ok |
| 23:36:44 | amiller_: | alright im familiar with that argument assuming the overhead is based on transmission basically |
| 23:36:53 | petertodd: | that creates a centralization spiral and leads to Bad Things |
| 23:37:22 | amiller_: | okay i think the stage is set now what is different in tree chain world |
| 23:37:25 | petertodd: | yeah, overhead ~= blocksize is a perfectly reasonable assumption, and covers transmission, storage, etc. etc. |
| 23:37:39 | amiller_: | storage goes away when you have pow-puzzle |
| 23:37:43 | amiller_: | por-puzzle |
| 23:38:10 | amiller_: | but transmission sure |
| 23:38:22 | petertodd: | 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:51 | petertodd: | the tradeoff being that you may have less security at a deeper part of the tree |
| 23:38:56 | amiller_: | the overhead is proportional to the number of transactions in my block isn't it |
| 23:39:01 | petertodd: | amiller_: yes |
| 23:39:02 | amiller_: | i think i diverged from you earlier |
| 23:39:12 | amiller_: | you were talking about overhead including receiving all the blocks from someone else even ones you haven't mined |
| 23:39:18 | amiller_: | i was only thinking about the choice of include more tx vs include no more x |
| 23:39:35 | petertodd: | yeah, overhead has to include everything related to keeping up with the chain |
| 23:39:36 | amiller_: | my overhead is zero if i disregard the history and include no tx |
| 23:39:50 | petertodd: | yes, and such a system has no security and no profit for you :) |
| 23:40:04 | amiller_: | with por-puzzle over the whole history + the newest block that gets better i guess |
| 23:41:00 | amiller_: | okay i dont get it |
| 23:41:02 | petertodd: | yes, but por-puzzle means that minimum reqs to mine keep increasing - eventually people are shut out of the mining game |
| 23:41:29 | amiller_: | petertodd, okay so in tree chain do you have to receive all the blocks |
| 23:41:38 | amiller_: | all the data in all the blocks |
| 23:41:47 | amiller_: | if someone doesn't have to receive all the data in all the blocks, in what sense is it proof of publication |
| 23:42:04 | petertodd: | 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:31 | petertodd: | 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:11 | amiller_: | okay half of everyone... |
| 23:43:12 | amiller_: | hm |
| 23:43:18 | amiller_: | how do i decide which blocks i'm supposed to receive? |
| 23:43:22 | amiller_: | or who to send which blocks to? |
| 23:43:35 | amiller_: | bits of public key? |
| 23:43:41 | amiller_: | ip addr? |
| 23:43:46 | amiller_: | or choice |
| 23:43:57 | petertodd: | amiller_: read my disentangling crypto-coin mining paper? |
| 23:44:57 | amiller_: | several times, will try again, haven't grokked it yet |
| 23:45:14 | petertodd: | heh! |
| 23:45:43 | petertodd: | 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:08 | petertodd: | 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:46:47 | amiller_: | okay |
| 23:47:04 | amiller_: | so you don't "publish" to everyone, you publish to people who care for external reaosn? |
| 23:47:27 | petertodd: | right... but since we can't figure out how to do *that*, instead we just arbitrarily split up the tree |
| 23:47:52 | amiller_: | and all the tx i care about are in the same part of the tree? |
| 23:48:10 | petertodd: | 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:35 | amiller_: | that answers whree the tx goes in the tree, but not which miners have to validate which part of the tree |
| 23:48:57 | amiller_: | 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:08 | petertodd: | ah, well basically mining == validation == proving you were in posession of some data, and *nothing else* |
| 23:49:13 | amiller_: | yeah i got that |
| 23:49:20 | amiller_: | but which of the data |
| 23:49:26 | amiller_: | you said half the people look at half the data |
| 23:49:39 | amiller_: | so what prevent 100% of the people from looking at the same half of the data in the second layer |
| 23:49:46 | petertodd: | so as a miner, pick some part of the tree, and merge-mine blocks up to some depth along that path |
| 23:49:54 | amiller_: | so its miners choice |
| 23:50:11 | petertodd: | well, I'm thinking you could make a consensus rule be that blocks can only be created on alternating sides |
| 23:50:36 | amiller_: | ick |
| 23:50:43 | amiller_: | all the way down the tree? |
| 23:50:55 | amiller_: | so if i'm storing something at the last layer, it only helps me once in a year? |
| 23:51:33 | petertodd: | 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:36 | amiller_: | so miners can choose whichever leaves they want to store |
| 23:52:43 | amiller_: | and um |
| 23:53:07 | petertodd: | well they need to store leaves such that they can meet the proof-of-storage requirement |
| 23:53:50 | amiller_: | yeah but you said they can't be required to store more leaves or the minimum cost increases |
| 23:54:34 | amiller_: | 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:53 | petertodd: | 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:15 | petertodd: | storing more than a single path has rapidly diminishing returns in terms of extra profitability |
| 23:55:20 | amiller_: | okay so one path |
| 23:55:36 | petertodd: | yup, because each attempt at a pow is only valid for a single path |
| 23:56:45 | amiller_: | okay so then what prevents everyone from all choosing the same path |
| 23:57:12 | amiller_: | i think you are going to say that alternating thing |
| 23:57:21 | amiller_: | but that just means the small guy here has to turn off his miner every other block interval |
| 23:57:39 | amiller_: | (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:55 | petertodd: | 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:59 | Taek42: | 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:10 | petertodd: | you can incentivise that by the fact that you get faster confirms on average due to the even/odd rule |
| 23:59:30 | amiller_: | i'm not asking about what incentivizes people to put their transactions in which place in the tree, but which miners choose |
| 23:59:31 | amiller_: | also |
| 23:59:33 | amiller_: | miners who can store the hwole thing |
| 23:59:46 | amiller_: | can more easily switch position to take advantage of changing profitability if some partsof tree are more profitable than others |