| 00:08:09 | phantomcircuit: | petertodd, do you know off the top of your head which of the merged coins has the cleanest codebase? |
| 00:11:17 | kdomanski_: | kdomanski_ is now known as kdomanski |
| 00:13:53 | kdomanski: | kdomanski is now known as kdomanski_ |
| 00:14:04 | kdomanski_: | kdomanski_ is now known as kdomanski |
| 00:37:20 | BitDigiNet: | Is this Room active? anyone else miss the CoinChat service |
| 00:44:16 | andytoshi: | BitDigiNet is PM spamming me, i don't have op in here |
| 00:46:23 | BitDigiNet: | All I had to say, a reply would of been nice before you pub. spam my name. Your "Andytoshi" SN appeared within the == Topic for #bitcoin-wizards was hoping you could help direct to an active member again I am trying to sell my website / research and name " |
| 00:47:12 | BitDigiNet: | "Bitcoin Digital Network" to a deserving #Bitcoin User there are many users out there that is all thank you for your time... |
| 00:50:53 | BitDigiNet: | Later Romanian134 No Exceptions right? |
| 01:09:57 | petertodd: | phantomcircuit: what do you mean by clean? namecoin hasn't changed since forever, so under some definitions, maybe it? |
| 01:28:45 | maaku: | does anyone understand what Sergio is trying to do? |
| 01:28:50 | maaku: | I'm not sure how to respond |
| 01:36:15 | amiller: | maaku, where? |
| 01:36:22 | maaku: | mailing list |
| 01:38:36 | amiller: | https://bitslog.wordpress.com/2014/04/25/smartspv-a-better-simplified-payment-verification-for-smartphones/ here's probably the condensed version, but no i haven't understood it yet either |
| 01:40:00 | maaku: | amiller: yes, and we told him about the compact spv proof concept which was posted to the list a month or so ago |
| 01:40:40 | maaku: | and about 30min ago he responded with some doubts that seem frankly non-sequitur to me, hence my confusion |
| 01:42:45 | amiller: | btw i'm still interested in figuring out if our compact spv proof schemes differ in any particular way, i haven't been able to convince anyone to show me sipa's simulator of yours |
| 01:43:56 | maaku: | amiller: you'd have to convince sipa as its on his laptop |
| 01:45:03 | maaku: | but its not just a schema difference. i don't think your protocol results in trustworthy non-interactive proofs |
| 01:47:05 | maaku: | you need to precommit to the back links, otherwise you are inviting fraud when the most recent block happens to be lucky |
| 01:47:25 | amiller: | the back links are precommitted |
| 01:47:33 | amiller: | for any reasonable definition of that |
| 01:47:59 | maaku: | the back links need to be precommited into the high-value block, i mean |
| 01:48:23 | amiller: | so lets say the most recent block is particularly lucky |
| 01:48:28 | amiller: | can you describe how this fraud might occur |
| 01:49:10 | amiller: | if i can figure out what you're getting at even on an intuitive level (i still don't) i can reconcile it with the game experiments i wrote down https://docs.google.com/document/d/12xl5eRtoE0uISUX188jnmGSb-bwG4yXByRBbdr2r97A/edit |
| 01:49:18 | maaku: | or actually it works for any lucky block in the history - you pull it out and build off it, with a false link |
| 01:49:46 | maaku: | did you look at gmaxwell's game from the last time we discussed this? |
| 01:49:57 | amiller: | no, is that in these chat logs |
| 01:50:33 | amiller: | i think i know the one you're talking about |
| 01:50:58 | amiller: | we got stuck i think on what it meant for "the real work content of a chain" when you aren't presenting the whole chain so that's confusing. |
| 01:51:17 | amiller: | but okay so in my game you want to convince someone that a certain amount of work has "buried" a transaction in some previous block |
| 01:52:00 | maaku: | here is the problem : "In order to determine the “up” link, we select the block *after* the most recent block whose value is *one larger* than the value of prev" |
| 01:52:17 | maaku: | you can't use the *previous* block's pow to assert the validity of the *current* block's back-link |
| 01:52:47 | maaku: | that is the point gmaxwell was trying to drive home |
| 01:53:31 | amiller: | but that's exaclty what i mean by back links are precommitted |
| 01:53:39 | amiller: | they don't depend on the current block's value |
| 01:54:23 | amiller: | in either case, "assert the validity of back-link" isn't a real thing... |
| 01:54:52 | maaku: | the fact that they don't depend on the current block's value is exactly the problem! |
| 01:54:54 | amiller: | is your objection either a) this notion of asserting that a certain amount of work "buries" a transaction isn't the right goal? or that b) having the back links arranged the way i describe makes it impossible to achieve that |
| 01:56:27 | maaku: | amiller: here is the question: does it take at least the same amount of work to create a fake proof as it does to mine the interveneing block headers |
| 01:58:03 | amiller: | that might not be the right question |
| 01:58:18 | amiller: | the reason is that i think you mean "in expectation" |
| 01:58:31 | maaku: | amiller: it's the only question that matters in the applications I'm considering |
| 01:58:52 | amiller: | wouldn't "almost as much, with high probability" be just as useful? |
| 01:58:59 | maaku: | no |
| 01:59:02 | amiller: | why not? |
| 02:00:04 | maaku: | the expected value of the work required (expected value because mining blocks or fake proofs is a stochastic process) would have to be exactly as much or greater, or else people's bitcoins get stolen |
| 02:00:52 | maaku: | the only thing securing the bitcoins in a peg pool is the fact that compact spv proofs require as much or greater work than the underlying headers |
| 02:01:24 | amiller: | right but that's just as secure the way i stated it |
| 02:02:34 | amiller: | if you think an attacker can only do 5 units of work, and with 99.99% probability (which you somehow think is tolerable) can only cheat by 1/5 portion, then wait for 6 blocks and you're done |
| 02:03:11 | maaku: | so my objection is (b), I don't see how having the back-links arranged the way you describe you are preventing someone from taking an easy route to fake proofs |
| 02:04:25 | amiller: | i think i can explain that then, based on what i think you mean by easy route to fake proofs |
| 02:05:26 | amiller: | suppose there's some amount of work w1 of honest blocks that bury a transaction |
| 02:05:57 | amiller: | and you want to do w2 work, and create a fake proof that somehow uses some of the honest work to make it look like w1+w2 is burying a conflicting transaction? |
| 02:07:02 | amiller: | the answer is this - one key aspect of my scheme is that for every *proof of work* that is included in the sample of evidence, you establish an unbroken chain of hashes from that block to the block you're proving is buried |
| 02:10:13 | maaku: | amiller: as far as I can tell I can halve the amount of work required to build any fake proof |
| 02:10:43 | amiller: | definitely not - how do you figure? |
| 02:11:06 | maaku: | I do so by starting a new chain with the transaction I want to bury, then keep finding a few more blocks |
| 02:11:41 | maaku: | at some point I choose the luckiest block found so far, and pick a historical block at the same level |
| 02:11:56 | maaku: | then build one block off the historical block, linking back to the most-luck fraud block |
| 02:13:41 | maaku: | i've effecitvely skipped having to do that much work, and I can repeat this cycle if I want more work or confirmations, effectively doubling the apparant work provided by lucky blocks |
| 02:14:42 | amiller: | a historical block at the same level? |
| 02:14:58 | amiller: | meaning a historical block that occured previous to the block containing the trnsaction/ |
| 02:16:42 | maaku: | amiller: sure, or in another chain, or whatever -- it really doesn't matter |
| 02:16:58 | amiller: | ok so that definitely does not help you |
| 02:17:15 | maaku: | why? |
| 02:17:16 | amiller: | because if that historical block is included in the sample |
| 02:17:31 | amiller: | then you will have to verify a connection between the historical block and the transaction you're trying to bury |
| 02:17:44 | maaku: | "verify a connection" -- what does that mean? |
| 02:18:03 | maaku: | i thought the point was that we were eliding the block headers? |
| 02:18:11 | maaku: | the spv proof is meant to be that connection |
| 02:19:21 | amiller: | you recursively follow up links and back links in order to find the connection |
| 02:19:42 | amiller: | it takes on average log n * log n blocks to do that |
| 02:19:56 | amiller: | you're eliding most block headers |
| 02:20:26 | maaku: | no, you follow the link in the following block |
| 02:20:36 | amiller: | what you are including though is a) a sample of lucky block headers, b) headers on the skip list route from the ones in your sample to the transaction you're burying |
| 02:20:38 | maaku: | you're just using the block header for its pow |
| 02:20:48 | maaku: | the back link is in the block which follows |
| 02:22:13 | amiller: | no the header contains the pow and the two backlinks (back and up) |
| 02:31:07 | maaku: | amiller: i'm not sure how that makes a difference? |
| 02:31:35 | maaku: | so we have two blocks , L (the lucky block) and S (the skip list block, which builds on L) |
| 02:31:48 | maaku: | both the up and back links are in L |
| 02:32:01 | maaku: | *are in S |
| 02:32:17 | maaku: | the back links to L, the up links to some other blocks |
| 02:32:26 | amiller: | okay so if L is included in your sample |
| 02:32:37 | amiller: | then you will need to verify a path of headers from L back to the transcation you're burying |
| 02:33:15 | amiller: | it's efficient to do so because of the skip list |
| 02:33:37 | amiller: | and doing so guarantees that no honest block can be part of the evidence used to make it look like a transaction is buried |
| 02:34:41 | maaku: | but you're able to make up the skip list links!! |
| 02:34:54 | maaku: | i'm sorry i don't know why this point is so hard to get through |
| 02:35:01 | maaku: | the skip list links have zero security on them |
| 02:35:15 | maaku: | because all it takes is 1 difficulty to invent them |
| 02:35:50 | amiller: | you're totally missing my point somehow... |
| 02:36:29 | amiller: | every block contains commitments/hashes of back links |
| 02:36:35 | amiller: | an honest block contains only back links to other honest blocks |
| 02:37:10 | amiller: | a compact SPV proof consists of a) a sample of lucky blocks, and b) for every lucky block in the sample, an unbroken chain of preimages that lead back to the transaction you are proving is buried |
| 02:37:29 | amiller: | if you create your own block and include it in a sample, yes you can make it link to whatever transaction you want |
| 02:37:58 | amiller: | but if you include any honest block in the sample, then the proof will not be valid |
| 02:38:22 | amiller: | because you cannot show that there's a chain from the transactino youre burying to the honest block |
| 02:40:02 | maaku: | ...that's not log(N) space |
| 02:40:16 | maaku: | if you need an unbroken chain, how is that any space savings? |
| 02:40:31 | amiller: | there are many unbroken chains |
| 02:40:36 | amiller: | because |
| 02:40:53 | amiller: | the back links and up links of the honest blocks form a nice graph |
| 02:41:10 | amiller: | you follow up and back links *from each honest lucky block in the sample* |
| 02:41:16 | amiller: | i'm making an illustration |
| 02:41:32 | maaku: | ok here's what i'm saying: if you follow the up links, it's not secure |
| 02:41:42 | maaku: | if you force following the back links all the way, that's no space savings |
| 02:44:16 | amiller: | i have no idea what you are trying to say by "if you follow the up links it's not secure" |
| 02:44:32 | amiller: | honest blocks only have up or back links to other honest blocks |
| 02:44:35 | amiller: | that's part of validation |
| 02:48:36 | amiller: | maaku, https://docs.google.com/drawings/d/1wVfHl5nnsAH2U6AnzJGj9csLvCa_fmLL-y5f09vxnMQ/edit illustration |
| 02:57:08 | amiller: | https://i.imgur.com/z78tQRE.png |
| 03:00:43 | Luke-Jr: | maaku: I thought we concluded that as long as the most recent N blocks were direct, we could skip the rest? |
| 03:03:58 | amiller: | it makes more of a difference if you think of these as tons of low value blocks like p2pool kinda in some side chain chain... |
| 03:04:16 | amiller: | but i probably don't know wht you're referring to luke |
| 03:05:20 | Luke-Jr: | [02:57:08] https://i.imgur.com/z78tQRE.png <-- this looks like the block skipping we discussed the last few days I was in SF |
| 03:06:54 | amiller: | yes |
| 03:07:30 | amiller: | it's the same concept as something i wrote about a year ago, but maaku came up with some different scheme, we're trying to hammer out whether there are actually any security differences... |
| 03:16:05 | Luke-Jr: | amiller: have you considered that option? use the regular block headers 100 blocks backward, then start using the skiplist? |
| 03:16:47 | amiller: | don't see how that could hurt, so sure? |
| 03:18:17 | Luke-Jr: | well, it avoids the security risk of someone finding one (or a few) lucky blocks that make it seem like they're tons of work ahead |
| 03:18:22 | Luke-Jr: | I think |
| 03:19:42 | amiller: | if you're doing a proof about 10k blocks then having to get that last 100 to be valid isn't that much of a deterrent, so i think it's still important for us to conclude that whatever skipply thing we have is also secure without that. |
| 04:05:14 | roconnor: | sipa: you around? |
| 04:10:04 | sipa: | accidentally |
| 04:10:20 | sipa: | roconnor: you? |
| 04:10:20 | roconnor: | oh, you busy? |
| 04:10:26 | sipa: | no, couldn't sleep :) |
| 04:13:12 | roconnor: | So, I was just pondering the possiblity of bitcoin poker where a bunch of people get together and move their money into a transaction whose script validates a game of poker was played. They the people play a game of cyptographic poker (a game which I sort of assume exists and I vague can imagine defining) and then the transaction is completed by attaching a trace of the game and the signature validates the trace and |
| 04:13:14 | roconnor: | distributes the money. |
| 04:13:31 | roconnor: | Then I figured this has probably all been worked out a long time ago on the forum somewhere |
| 04:13:35 | roconnor: | and maybe you know where. |
| 04:14:30 | roconnor: | This is clearly all an academic exercise, and I'm not suggesting such a monstrosity actually be implemented. |
| 04:16:18 | jgarzik: | roconnor, it's been covered on the forums |
| 04:17:49 | jgarzik: | roconnor, here's a post with links to older posts, RE DC poker: https://bitcointalk.org/index.php?topic=362901.0 |
| 04:18:07 | jgarzik: | roconnor, though perhaps a ZKP could also be employed |
| 04:19:56 | roconnor: | jgarzik: The one sticking point in my mind is that the value of the proposed transaction is not accessible in the script IIRC, so I'm not sure how to make the script validate the payouts are correct. |
| 04:20:11 | roconnor: | anyhow, it is so much easier when someone has already done all the hard thinking |
| 04:20:14 | roconnor: | (but less fun) |
| 04:21:38 | roconnor: | oh I see, |
| 04:21:52 | roconnor: | the proposal there is to put each poker transaction into the blockchain |
| 04:21:53 | roconnor: | yikes |
| 04:22:03 | roconnor: | well, this is all theoretical anyways. |
| 04:22:22 | jgarzik: | roconnor, yah, that's DC (decentralized) poker. |
| 04:22:33 | jgarzik: | roconnor, if you just need to prove a result after the fact, that's probably easier |
| 04:22:58 | roconnor: | yeah, I was contemplating putting a single game into the chain. |
| 04:23:47 | roconnor: | * roconnor double checks the script mechanism |
| 04:29:27 | amiller: | roconnor, you might also find this relevant: https://eprint.iacr.org/2013/784.pdf Secure Multiparty Computations on Bitcoin |
| 04:29:48 | amiller: | there's followup work by iddo and others |
| 04:30:20 | amiller: | basically you can put just the commitments to things in the blockchain, and do all the rest of the game with somewhat more standard crypto |
| 04:32:00 | roconnor: | actually maybe the bitcoin scripting mechanisms cannot be powerful enough to validate a game of poker since a poker game can take arbitarily long. Though techncially it is limited by the sum of all the stacks of all the players. |
| 04:32:01 | amiller: | i think that you still have to do something in the blockchain every time there's a "turn", but everyone could make a parallel move at once |
| 04:32:19 | roconnor: | But you'd have to have a script proportional to the size of the stacks to handle every possible case. |
| 04:32:36 | roconnor: | and that would be silly. |
| 04:33:06 | roconnor: | interesting |
| 04:34:21 | roconnor: | * roconnor considers altering his design of his imaginary alt-coin |
| 04:35:23 | sipa: | imaginary altcoin is best altcoin |
| 04:41:19 | roconnor: | sipa: validating poker would require at least some minimal form of primitive recursion to not be insane. |
| 04:41:43 | roconnor: | my imaginary altcoin doesn't have any recursion at all at the moment. |
| 04:42:46 | sipa: | with SNARK-like things it should be possible in constant space and time, no? |
| 04:42:57 | sipa: | (constant as in independent of the length of the game) |
| 04:43:06 | roconnor: | what is SNARK? |
| 04:44:01 | sipa: | (afaik) a zero-knowledge proof of a computation on unknown inputs |
| 04:44:42 | roconnor: | you can validate a zero-knowledge proof of a an aribitrary computation in constant time? |
| 04:45:33 | sipa: | i believe the proof size and validation time depend on the size of the program, and not on the number of execution steps |
| 04:46:16 | roconnor: | size of the program in a turing complete language? |
| 04:46:19 | sipa: | also, i don't think it's technically a proof, as it can (with exceedingly low probability) be true randomly |
| 04:46:22 | roconnor: | I don't beleive you. :) |
| 04:46:28 | roconnor: | even still |
| 04:46:36 | sipa: | to me, it's magic |
| 04:46:47 | sipa: | but iddo and gmaxwell understand it better |
| 04:48:19 | roconnor: | ... maybe I can somehow consolodate all the betting occuring in a round in the trace of the game, thus making the trace of poker a simple fixed step game. |
| 04:49:23 | amiller: | roconnor, not in a turing complete language, some prior bound is required |
| 04:49:41 | amiller: | but the proof size and validation time are constant |
| 04:50:02 | amiller: | independnet of the size of program or number of execution steps |
| 04:50:15 | sipa: | amiller: do the proof size and validation time depend on the choice of that bound? |
| 04:50:21 | amiller: | no they do not |
| 04:50:48 | roconnor: | amiller: validation time is indepenent of the size of the program? |
| 04:50:58 | amiller: | the time it takes to "setup" the system, and produce the proof, do depend on that bound though |
| 04:51:28 | roconnor: | that seems extrodinary. |
| 04:54:26 | roconnor: | validation time is linear in the size of the input. |
| 04:54:29 | amiller: | this is the GGPR paper that describes the math for it decribes https://usukitacs.com/sites/default/files/QSP.pdf |
| 04:55:10 | roconnor: | I found https://eprint.iacr.org/2013/507.pdf |
| 04:55:17 | amiller: | roconnor, you could always take a hash of the input, and make that the real input |
| 04:55:46 | roconnor: | well, the program cannot reconstruct the real input from the hash, |
| 04:56:46 | sipa: | validating the proof does not require knowing the input |
| 04:57:22 | amiller: | there can be auxiliary input that is chosen by whoever produces the proof, but that does not need to be included in what the verifier checks |
| 05:05:27 | roconnor: | amiller: wow |
| 05:07:47 | roconnor: | clearly way to late at night for me to be contemplating this |
| 05:07:57 | roconnor: | thanks. |
| 05:17:24 | stephenreed: | I posted a super-peer, round-robin single mint, proof-of-stake idea. Has this been discussed before? https://bitcointalk.org/index.php?topic=584719.msg6415632#msg6415632 |
| 05:23:46 | stephenreed: | Bitshares was in part an inspiration . . .http://107.170.30.182/security/delegated-proof-of-stake.php |
| 05:27:38 | sipa: | how do nodes agree on who is part of the set of 100? |
| 05:28:17 | sipa: | agreement in a distributed system requires consensus |
| 05:28:27 | sipa: | which is the problem you're trying to solve, but you're not |
| 05:28:49 | sipa: | of course, you could use a blockchain for that :) |
| 05:28:55 | sipa: | a PoW one |
| 05:58:23 | iddo: | there was this guy in 2011 who "proved" that bitcoin also needs consensus among small set of e.g. 100, because of checkpoints, http://www.links.org/files/decentralised-currencies.pdf |
| 05:59:00 | iddo: | he starts with the false assumption that checkpoints are essential, and then continues to pat himself on the back... |
| 05:59:39 | iddo: | i summarized high-level view regarding checkpoints when GHOST was discussed: https://bitcointalk.org/index.php?topic=359582.msg3867074#msg3867074 |
| 06:09:00 | stephenreed: | sipa: I suppose that any pool could join the ring, which is an attack I've not yet considered. Of the joined pools, each provides the sum of their respective client stakes. I will think more on this. |
| 06:11:21 | stephenreed: | I wonder how I would decide the 100 largest pools today? |
| 06:11:44 | Luke-Jr: | iddo: meh, to be fair, he doesn't merely assert checkpoints are essential, but (incorrectly) assumes they are a solution to an as-of-yet-unsolved(!) problem with Bitcoin |
| 06:11:53 | Luke-Jr: | (and then proves they aren't a real solution) |
| 06:12:01 | stephenreed: | Printed the paper |
| 06:12:48 | stephenreed: | Satoshi did not want a central mint. This is a way for the mint to move around - event if patent trolls were after it. |
| 07:17:36 | iddo: | Luke-Jr: he says "it is probably impossible to create a decentralised currency" when he proceeded to pat himself on the back... http://www.links.org/files/distributed-currency.pdf |
| 08:32:06 | gmaxwell: | iddo: I sent him a long rebuttal when that was published but he never responded to any of it. |
| 09:49:45 | cajg_: | cajg_ is now known as cajg |
| 11:56:17 | jaekwon: | so, i have a whitepaper almost complete. |
| 11:56:24 | jaekwon: | for a new consensus protocol. |
| 12:19:26 | zooko: | gmaxwell: you didn't publish your rebuttal to Ben Laurie's paper? |
| 13:19:30 | HM2: | Stepanovs lectures on abstract algebra are great for newbs like me |
| 13:19:53 | HM2: | plain english, lots of code, lots of stories and good humour to go along with |
| 13:24:43 | HM2: | things like you can use min() to form a subgroup where the identity element is INT_MAX |
| 15:23:05 | kdomanski_: | kdomanski_ is now known as kdomanski |
| 15:54:56 | [BNC]dansmith: | [BNC]dansmith is now known as dansmith_btc |
| 16:05:39 | gmaxwell: | zooko: No— I sort of felt that Ben wasted the reader's time with a number of weak arguments that could have been avoided if he'd privately asked for review from someone who knew the system better. Honestly, I didn't want to do the same thing myself— perhaps I misunderstood some of his positions. In the goal to enhance knoweldge I think its usually better to not turn everything into a public debate as fast as possible. :) |
| 16:18:58 | copumpkin: | gmaxwell: he went offlin |
| 20:46:16 | justanot1eruser: | I have two questions: Using scorched earth fees to prevent doublespending will supposedly stop most doublespending attempts because doublespenders lose their money. Miners won't be making money from doublespends then. |
| 20:46:50 | justanot1eruser: | So won't they instead advertise *not* having child pays for parent as a feature? |
| 20:47:42 | gmaxwell: | no, because it doesn't help unless everyone does it, and doing correct and complete fee calculations increases income from things entirely unrelated to doublespending. |
| 20:50:06 | justanot1eruser: | Hmm. So if a large number of mining pools or a few big ones decide to not do child pays for parent, won't they make money because they are bringing in all these new doublespend fees? |
| 20:51:35 | gmaxwell: | justanot1eruser: no because if they try other miners can make even more clearing them out. What you're describing isn't a nash equlibrium, whereas all miners doing CPP is. (and even more strongly because not doing it is antisocial and makes bitcoin less useful) |
| 20:53:55 | justanot1eruser: | I see |
| 20:58:17 | amiller: | * amiller grumbles |
| 20:58:25 | amiller: | mining pools are such a gross thing |
| 20:58:33 | amiller: | i think it's a shame everyone is tolerant of them |
| 20:58:43 | amiller: | there's no evidence mining pools were a part of "satoshi's vision" |
| 21:00:08 | sipa: | they weren't |
| 21:08:49 | Luke-Jr: | he had bad vision |
| 21:08:50 | Luke-Jr: | :P |
| 21:20:57 | justanot1eruser: | Oh, I forgot my other question. |
| 21:21:19 | justanot1eruser: | Currently the PoW is H(Block header). What is the PoW for querying the UTXO? |
| 21:21:55 | justanot1eruser: | I mean, what is the PoW when you need to query the UTXO? |
| 21:27:00 | sipa: | why would you need PoW to query the UTXO set? |
| 21:28:17 | mkarrer: | What is recommended for storing small amount of data in the blockchain? OP_RETURN + data is limited to 40 bytes, right? are all miners accepting that? will it be supported in future? I know many see that as abuse of the blockchain, but what are the realistic alternatives? use namecoin for that seems a good alternative, but then u need to download 1,7 gb of blockchain and deal with a 2. codebase, so the effort |
| 21:28:17 | mkarrer: | is pretty high. are there any other suggestions? |
| 21:29:24 | mkarrer: | ethereum might be a future candidate, but thats not available yet... |
| 21:29:37 | Luke-Jr: | mkarrer: it is NOT recommended to store data in the blockchain |
| 21:29:55 | Luke-Jr: | mkarrer: what do you *think* you need to do so for? |
| 21:33:39 | mkarrer: | there are use cases where u want to store data in a timestamped unchangeable way (like notary, proof of existence). that are valid use cases. I am just asking which alternatives are the core devs suggesting. If there is no realistic alternative, it will be always a race between people misusing btc for data storage and devs/miners to prevent that, that is a stupid situation... |
| 21:33:46 | sipa: | mkarrer: offtopic here |
| 21:34:24 | mkarrer: | sipa: can u point me to the latest info regarding that topic? |
| 21:34:37 | sipa: | i can tell you my opinion, but not here |
| 21:38:37 | Luke-Jr: | mkarrer: it's perfectly possible to make a notary service based on bitcoin's blockchain, but nobody has gone to the effort to do so yet |
| 21:38:48 | Luke-Jr: | mkarrer: basically you just need miners to merge-mine a merkle tree of data hashes |
| 21:40:05 | Luke-Jr: | sipa: seems on-topic to me (well, insofar as possible solutions that aren't implemented) |
| 21:40:38 | sipa: | how to solve timestamping in blockchain-based systems, yes |
| 21:40:44 | sipa: | how to store data in bitcoin's chain now, no |
| 21:41:22 | mkarrer: | ok, like sipa told me in the private room chronobit seems to be a solution for that. I dont know it yet, need to check it out... |
| 21:41:52 | sipa: | right, that would be ontopic here |
| 21:42:02 | Luke-Jr: | yes, Chronobit is one way to do it. I wasn't aware it was maintained.. still falls short of being a generic solution unfortunately |
| 21:42:15 | Luke-Jr: | (only works with p2pool) |
| 21:42:15 | sipa: | it's not |
| 21:42:22 | sipa: | it's just the best theoretical solution |
| 21:42:33 | sipa: | it even has better-than-1-block resolution |
| 21:44:26 | amiller: | also check commit coin, you can bury it in a public key |
| 21:45:40 | sipa: | it's a nice trick, but still *puke* |
| 21:45:59 | amiller: | who cares though, still just storing a hash of some data |
| 21:46:18 | sipa: | imho, storing any non-transactional data in the blockchain is abuse |
| 21:46:50 | sipa: | with better solutions |
| 21:47:26 | sipa: | there are cases where you need a transaction needs to commit to some external data, and that's what OP_RETURN is for |
| 21:47:49 | sipa: | unfortunately, everyone seems to interpret that as "storing data in the chain is ok!" |
| 21:48:02 | amiller: | do you think it is an abuse to send unnecessary transactions to yourself for fun |
| 21:48:13 | amiller: | like not true economic transfers of value, just noise |
| 21:48:38 | sipa: | that's a good question |
| 21:48:40 | amiller: | like spending a day at your bank branch repeatedly depositing money and then withdrawing it until the teller gets annoyed and bans you |
| 21:49:10 | amiller: | commitcoin doesn't use OP_RETURN or any data stored in the blockchain besides transactions |
| 21:49:19 | amiller: | it embeds the commitment in the keypair |
| 21:49:26 | sipa: | yes, i know how it works |
| 21:49:39 | amiller: | so, it's not really non-transactional data |
| 21:49:45 | sipa: | sure it is |
| 21:49:52 | amiller: | if you had normal transactions to make, you could make those at the same time too |
| 21:50:12 | sipa: | that's something else i guess |
| 21:50:34 | amiller: | so i think what you're talking about is an "intent" like intent to pay, intent to transfer control of a coin to a different principal |
| 21:50:36 | sipa: | it's a blurry line, and of course it's not enforceable |
| 21:51:28 | amiller: | it would be nice to make a commitcoin-integrated payment system that handles timestamping while in the course of performing other transactions. |
| 21:51:30 | mkarrer: | coin mixing would be a candidate as well... no real payment |
| 21:51:30 | sipa: | i guess the core problem is that there's economic incentive for some use cases to burden the blockchain |
| 21:52:02 | sipa: | which doesn't benefit those who pay the cost of it (blockchain storage, bandwidth, processing) without being rewarded for it (miners) |
| 22:18:58 | justanot1eruser: | sipa: you query it to prove you have the UTXO |
| 22:19:28 | sipa: | i have no idea what you're talking about |
| 22:19:39 | sipa: | a UTXO-based PoW algorithm? |
| 22:19:45 | justanot1eruser: | yes |
| 22:20:04 | justanot1eruser: | or prove you can access the UTXO quickly anyways |
| 22:20:54 | Luke-Jr: | sipa: the idea is forcing the miners to have the *ability* of validating transactions |
| 22:21:31 | sipa: | yes, i'm aware of that idea; just didn't know that was what he was talking about :) |
| 22:21:32 | justanot1eruser: | Anyways, would you have to do a new query every time you hashed the header? |
| 22:22:01 | Luke-Jr: | justanot1eruser: IMO yes, otherwise one could outsource the UTXO once |
| 22:22:03 | justanot1eruser: | like H(UTXO_Query(H(block_header)))? |
| 22:22:11 | sipa: | i believe the idea is to have some deterministic walk through the utxo set, with several iterations |
| 22:22:26 | sipa: | and use that to compute a hash value that must be low |
| 22:23:07 | Luke-Jr: | * Luke-Jr wonders if the last hash is necessary |
| 22:23:29 | sipa: | i should have said "hash" |
| 22:23:40 | justanot1eruser: | So this would make all ASICs useless? |
| 22:23:45 | sipa: | no |
| 22:23:51 | sipa: | well, all current ones, obviously |
| 22:23:57 | sipa: | but nobody is proposing this for bitcoin itsel |
| 22:24:06 | Luke-Jr: | no? |
| 22:24:36 | sipa: | unless there's a near-breaking preimage attack on SHA2, i don't believe changing bitcoin's hash function is viable |
| 22:24:44 | sipa: | s/hash/PoW/ |
| 22:25:22 | Luke-Jr: | sipa: even if bitfury has 75% of all hashing? |
| 22:25:46 | sipa: | maybe |
| 22:38:54 | justanot1eruser: | petertodd said it could be implemented in a way that would allow current ASICs to work. I was wondering how that could work while preventing the outsourcing of the UTXO query |
| 22:40:47 | justanot1eruser: | I don't really see the problem with implementing it. All ASICs are pretty much worthless after 3 months. Miners could start investing in really fast RAM when the PoW switch is about to happen |
| 22:41:07 | justanot1eruser: | s/implementing/including |
| 22:41:32 | maaku: | justanot1eruser: it is a very temporary phenomenon that asics have no lasting value |
| 22:43:34 | zzyzx: | zzyzx is now known as roidster |
| 22:45:02 | justanot1eruser: | maaku: yeah, and while that phenomenon is in effect, it wouldn't matter much if different ASICs began to be used |
| 22:46:00 | maaku: | justanot1eruser: it would matter a lot. you would invalidate overnight millions of dollars of capital investment |
| 22:46:09 | tromp_: | these proof-of-blockchain pows were also discussed on the ethereum blog in http://blog.ethereum.org/2014/02/18/ethereum-scalability-and-decentralization-updates/ |
| 22:46:48 | andytoshi: | is there a citation for PPC and/or FTC becoming centralized? |
| 22:57:59 | gmaxwell: | andytoshi: like https://bitcointalk.org/index.php?topic=282314.0 |
| 23:02:38 | andytoshi: | awesome, thx |
| 23:04:37 | gmaxwell: | andytoshi: ppc had the developer controlled block signing since the first day, and the transistion from being something that was a short term to something forever wasn't really announced as far as I know (though the updated whitepaper no longer describes it as a short term thing) |
| 23:10:32 | andytoshi: | interesting, presumably they had not heard of stake-grinding in the first interation |
| 23:11:56 | gmaxwell: | andytoshi: when it was created it had the checkpoints because there was no stake mining (and could be no stake mining, for obvious reasons) ... because of the maturing time there couldn't be any stake mining at all until some months until after it was created. |
| 23:12:29 | gmaxwell: | So the signatures were supposted to stop reorgs during that time and be taking out once the coin was mostly stake mined... but then it was attacked with the grinding as soon as it was stake minable. |
| 23:13:27 | andytoshi: | cool, it'd be nice to have a link for that because the reason i ask is that somebody PM'd me to say that if PoS is really as vulnerable as i claim, it should've been attacked |
| 23:19:50 | gmaxwell: | it was totally attacked, and they used the block signing to cut him off.... I'll see if I can find a citation; but that argument is flawed in general. Lots of things are vunlerable without being attacked. |
| 23:20:37 | andytoshi: | that's a good point, though in this case there is an obvious monetary incentive to attack |
| 23:21:04 | gmaxwell: | yep, and it was. and the current fixes are enough to reduce the subsidy gathering incentivies at least. |
| 23:21:17 | gmaxwell: | (they now use POW to pick the POS miners) |
| 23:37:06 | justanot1eruser: | maaku: it wouldn't invalidate their investment. They just wouldn't buy new ASICs if it was going to be unprofitable |
| 23:40:04 | jaekwon: | hi, i'm going to release a draft of the consensus protocol in 3 hours. |
| 23:40:34 | jaekwon: | would be great to get some feedback on it. |
| 23:52:21 | amiller: | jaekwon, i hope you explain what kind of assumptions/model you have and what exactly form of consensus is the goal you try to achieve! |
| 23:53:25 | jaekwon: | yup, i do that. |
| 23:53:49 | jaekwon: | i hope, sufficiently. but i might be wrong, which is why i need it reviewed :) |
| 23:56:04 | amiller: | sounds fun to me! good luck! |