00:08:09phantomcircuit:petertodd, do you know off the top of your head which of the merged coins has the cleanest codebase?
00:11:17kdomanski_:kdomanski_ is now known as kdomanski
00:13:53kdomanski:kdomanski is now known as kdomanski_
00:14:04kdomanski_:kdomanski_ is now known as kdomanski
00:37:20BitDigiNet:Is this Room active? anyone else miss the CoinChat service
00:44:16andytoshi:BitDigiNet is PM spamming me, i don't have op in here
00:46:23BitDigiNet: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:12BitDigiNet:"Bitcoin Digital Network" to a deserving #Bitcoin User there are many users out there that is all thank you for your time...
00:50:53BitDigiNet:Later Romanian134 No Exceptions right?
01:09:57petertodd:phantomcircuit: what do you mean by clean? namecoin hasn't changed since forever, so under some definitions, maybe it?
01:28:45maaku:does anyone understand what Sergio is trying to do?
01:28:50maaku:I'm not sure how to respond
01:36:15amiller:maaku, where?
01:36:22maaku:mailing list
01:38:36amiller: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:00maaku: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:40maaku:and about 30min ago he responded with some doubts that seem frankly non-sequitur to me, hence my confusion
01:42:45amiller: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:56maaku:amiller: you'd have to convince sipa as its on his laptop
01:45:03maaku:but its not just a schema difference. i don't think your protocol results in trustworthy non-interactive proofs
01:47:05maaku:you need to precommit to the back links, otherwise you are inviting fraud when the most recent block happens to be lucky
01:47:25amiller:the back links are precommitted
01:47:33amiller:for any reasonable definition of that
01:47:59maaku:the back links need to be precommited into the high-value block, i mean
01:48:23amiller:so lets say the most recent block is particularly lucky
01:48:28amiller:can you describe how this fraud might occur
01:49:10amiller: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:18maaku: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:46maaku:did you look at gmaxwell's game from the last time we discussed this?
01:49:57amiller:no, is that in these chat logs
01:50:33amiller:i think i know the one you're talking about
01:50:58amiller: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:17amiller: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:00maaku: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:17maaku:you can't use the *previous* block's pow to assert the validity of the *current* block's back-link
01:52:47maaku:that is the point gmaxwell was trying to drive home
01:53:31amiller:but that's exaclty what i mean by back links are precommitted
01:53:39amiller:they don't depend on the current block's value
01:54:23amiller:in either case, "assert the validity of back-link" isn't a real thing...
01:54:52maaku:the fact that they don't depend on the current block's value is exactly the problem!
01:54:54amiller: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:27maaku: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:03amiller:that might not be the right question
01:58:18amiller:the reason is that i think you mean "in expectation"
01:58:31maaku:amiller: it's the only question that matters in the applications I'm considering
01:58:52amiller:wouldn't "almost as much, with high probability" be just as useful?
01:59:02amiller:why not?
02:00:04maaku: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:52maaku: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:24amiller:right but that's just as secure the way i stated it
02:02:34amiller: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:11maaku: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:25amiller:i think i can explain that then, based on what i think you mean by easy route to fake proofs
02:05:26amiller:suppose there's some amount of work w1 of honest blocks that bury a transaction
02:05:57amiller: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:02amiller: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:13maaku:amiller: as far as I can tell I can halve the amount of work required to build any fake proof
02:10:43amiller:definitely not - how do you figure?
02:11:06maaku:I do so by starting a new chain with the transaction I want to bury, then keep finding a few more blocks
02:11:41maaku:at some point I choose the luckiest block found so far, and pick a historical block at the same level
02:11:56maaku:then build one block off the historical block, linking back to the most-luck fraud block
02:13:41maaku: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:42amiller:a historical block at the same level?
02:14:58amiller:meaning a historical block that occured previous to the block containing the trnsaction/
02:16:42maaku:amiller: sure, or in another chain, or whatever -- it really doesn't matter
02:16:58amiller:ok so that definitely does not help you
02:17:16amiller:because if that historical block is included in the sample
02:17:31amiller:then you will have to verify a connection between the historical block and the transaction you're trying to bury
02:17:44maaku:"verify a connection" -- what does that mean?
02:18:03maaku:i thought the point was that we were eliding the block headers?
02:18:11maaku:the spv proof is meant to be that connection
02:19:21amiller:you recursively follow up links and back links in order to find the connection
02:19:42amiller:it takes on average log n * log n blocks to do that
02:19:56amiller:you're eliding most block headers
02:20:26maaku:no, you follow the link in the following block
02:20:36amiller: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:38maaku:you're just using the block header for its pow
02:20:48maaku:the back link is in the block which follows
02:22:13amiller:no the header contains the pow and the two backlinks (back and up)
02:31:07maaku:amiller: i'm not sure how that makes a difference?
02:31:35maaku:so we have two blocks , L (the lucky block) and S (the skip list block, which builds on L)
02:31:48maaku:both the up and back links are in L
02:32:01maaku:*are in S
02:32:17maaku:the back links to L, the up links to some other blocks
02:32:26amiller:okay so if L is included in your sample
02:32:37amiller:then you will need to verify a path of headers from L back to the transcation you're burying
02:33:15amiller:it's efficient to do so because of the skip list
02:33:37amiller: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:41maaku:but you're able to make up the skip list links!!
02:34:54maaku:i'm sorry i don't know why this point is so hard to get through
02:35:01maaku:the skip list links have zero security on them
02:35:15maaku:because all it takes is 1 difficulty to invent them
02:35:50amiller:you're totally missing my point somehow...
02:36:29amiller:every block contains commitments/hashes of back links
02:36:35amiller:an honest block contains only back links to other honest blocks
02:37:10amiller: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:29amiller: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:58amiller:but if you include any honest block in the sample, then the proof will not be valid
02:38:22amiller:because you cannot show that there's a chain from the transactino youre burying to the honest block
02:40:02maaku:...that's not log(N) space
02:40:16maaku:if you need an unbroken chain, how is that any space savings?
02:40:31amiller:there are many unbroken chains
02:40:53amiller:the back links and up links of the honest blocks form a nice graph
02:41:10amiller:you follow up and back links *from each honest lucky block in the sample*
02:41:16amiller:i'm making an illustration
02:41:32maaku:ok here's what i'm saying: if you follow the up links, it's not secure
02:41:42maaku:if you force following the back links all the way, that's no space savings
02:44:16amiller:i have no idea what you are trying to say by "if you follow the up links it's not secure"
02:44:32amiller:honest blocks only have up or back links to other honest blocks
02:44:35amiller:that's part of validation
02:48:36amiller:maaku, https://docs.google.com/drawings/d/1wVfHl5nnsAH2U6AnzJGj9csLvCa_fmLL-y5f09vxnMQ/edit illustration
03:00:43Luke-Jr:maaku: I thought we concluded that as long as the most recent N blocks were direct, we could skip the rest?
03:03:58amiller: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:16amiller:but i probably don't know wht you're referring to luke
03:05:20Luke-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:07:30amiller: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:05Luke-Jr:amiller: have you considered that option? use the regular block headers 100 blocks backward, then start using the skiplist?
03:16:47amiller:don't see how that could hurt, so sure?
03:18:17Luke-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:22Luke-Jr:I think
03:19:42amiller: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:14roconnor:sipa: you around?
04:10:20sipa:roconnor: you?
04:10:20roconnor:oh, you busy?
04:10:26sipa:no, couldn't sleep :)
04:13:12roconnor: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:14roconnor:distributes the money.
04:13:31roconnor:Then I figured this has probably all been worked out a long time ago on the forum somewhere
04:13:35roconnor:and maybe you know where.
04:14:30roconnor:This is clearly all an academic exercise, and I'm not suggesting such a monstrosity actually be implemented.
04:16:18jgarzik:roconnor, it's been covered on the forums
04:17:49jgarzik:roconnor, here's a post with links to older posts, RE DC poker: https://bitcointalk.org/index.php?topic=362901.0
04:18:07jgarzik:roconnor, though perhaps a ZKP could also be employed
04:19:56roconnor: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:11roconnor:anyhow, it is so much easier when someone has already done all the hard thinking
04:20:14roconnor:(but less fun)
04:21:38roconnor:oh I see,
04:21:52roconnor:the proposal there is to put each poker transaction into the blockchain
04:22:03roconnor:well, this is all theoretical anyways.
04:22:22jgarzik:roconnor, yah, that's DC (decentralized) poker.
04:22:33jgarzik:roconnor, if you just need to prove a result after the fact, that's probably easier
04:22:58roconnor:yeah, I was contemplating putting a single game into the chain.
04:23:47roconnor:* roconnor double checks the script mechanism
04:29:27amiller:roconnor, you might also find this relevant: https://eprint.iacr.org/2013/784.pdf Secure Multiparty Computations on Bitcoin
04:29:48amiller:there's followup work by iddo and others
04:30:20amiller: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:00roconnor: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:01amiller: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:19roconnor:But you'd have to have a script proportional to the size of the stacks to handle every possible case.
04:32:36roconnor:and that would be silly.
04:34:21roconnor:* roconnor considers altering his design of his imaginary alt-coin
04:35:23sipa:imaginary altcoin is best altcoin
04:41:19roconnor:sipa: validating poker would require at least some minimal form of primitive recursion to not be insane.
04:41:43roconnor:my imaginary altcoin doesn't have any recursion at all at the moment.
04:42:46sipa:with SNARK-like things it should be possible in constant space and time, no?
04:42:57sipa:(constant as in independent of the length of the game)
04:43:06roconnor:what is SNARK?
04:44:01sipa:(afaik) a zero-knowledge proof of a computation on unknown inputs
04:44:42roconnor:you can validate a zero-knowledge proof of a an aribitrary computation in constant time?
04:45:33sipa: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:16roconnor:size of the program in a turing complete language?
04:46:19sipa:also, i don't think it's technically a proof, as it can (with exceedingly low probability) be true randomly
04:46:22roconnor:I don't beleive you. :)
04:46:28roconnor:even still
04:46:36sipa:to me, it's magic
04:46:47sipa:but iddo and gmaxwell understand it better
04:48:19roconnor:... 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:23amiller:roconnor, not in a turing complete language, some prior bound is required
04:49:41amiller:but the proof size and validation time are constant
04:50:02amiller:independnet of the size of program or number of execution steps
04:50:15sipa:amiller: do the proof size and validation time depend on the choice of that bound?
04:50:21amiller:no they do not
04:50:48roconnor:amiller: validation time is indepenent of the size of the program?
04:50:58amiller:the time it takes to "setup" the system, and produce the proof, do depend on that bound though
04:51:28roconnor:that seems extrodinary.
04:54:26roconnor:validation time is linear in the size of the input.
04:54:29amiller:this is the GGPR paper that describes the math for it decribes https://usukitacs.com/sites/default/files/QSP.pdf
04:55:10roconnor:I found https://eprint.iacr.org/2013/507.pdf
04:55:17amiller:roconnor, you could always take a hash of the input, and make that the real input
04:55:46roconnor:well, the program cannot reconstruct the real input from the hash,
04:56:46sipa:validating the proof does not require knowing the input
04:57:22amiller: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:27roconnor:amiller: wow
05:07:47roconnor:clearly way to late at night for me to be contemplating this
05:17:24stephenreed: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:46stephenreed:Bitshares was in part an inspiration . . .
05:27:38sipa:how do nodes agree on who is part of the set of 100?
05:28:17sipa:agreement in a distributed system requires consensus
05:28:27sipa:which is the problem you're trying to solve, but you're not
05:28:49sipa:of course, you could use a blockchain for that :)
05:28:55sipa:a PoW one
05:58:23iddo: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:00iddo:he starts with the false assumption that checkpoints are essential, and then continues to pat himself on the back...
05:59:39iddo:i summarized high-level view regarding checkpoints when GHOST was discussed: https://bitcointalk.org/index.php?topic=359582.msg3867074#msg3867074
06:09:00stephenreed: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:21stephenreed:I wonder how I would decide the 100 largest pools today?
06:11:44Luke-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:53Luke-Jr:(and then proves they aren't a real solution)
06:12:01stephenreed:Printed the paper
06:12:48stephenreed: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:36iddo: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:06gmaxwell:iddo: I sent him a long rebuttal when that was published but he never responded to any of it.
09:49:45cajg_:cajg_ is now known as cajg
11:56:17jaekwon:so, i have a whitepaper almost complete.
11:56:24jaekwon:for a new consensus protocol.
12:19:26zooko:gmaxwell: you didn't publish your rebuttal to Ben Laurie's paper?
13:19:30HM2:Stepanovs lectures on abstract algebra are great for newbs like me
13:19:53HM2:plain english, lots of code, lots of stories and good humour to go along with
13:24:43HM2:things like you can use min() to form a subgroup where the identity element is INT_MAX
15:23:05kdomanski_:kdomanski_ is now known as kdomanski
15:54:56[BNC]dansmith:[BNC]dansmith is now known as dansmith_btc
16:05:39gmaxwell: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:58copumpkin:gmaxwell: he went offlin
20:46:16justanot1eruser: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:50justanot1eruser:So won't they instead advertise *not* having child pays for parent as a feature?
20:47:42gmaxwell: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:06justanot1eruser: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:35gmaxwell: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:55justanot1eruser:I see
20:58:17amiller:* amiller grumbles
20:58:25amiller:mining pools are such a gross thing
20:58:33amiller:i think it's a shame everyone is tolerant of them
20:58:43amiller:there's no evidence mining pools were a part of "satoshi's vision"
21:00:08sipa:they weren't
21:08:49Luke-Jr:he had bad vision
21:20:57justanot1eruser:Oh, I forgot my other question.
21:21:19justanot1eruser:Currently the PoW is H(Block header). What is the PoW for querying the UTXO?
21:21:55justanot1eruser:I mean, what is the PoW when you need to query the UTXO?
21:27:00sipa:why would you need PoW to query the UTXO set?
21:28:17mkarrer: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:17mkarrer:is pretty high. are there any other suggestions?
21:29:24mkarrer:ethereum might be a future candidate, but thats not available yet...
21:29:37Luke-Jr:mkarrer: it is NOT recommended to store data in the blockchain
21:29:55Luke-Jr:mkarrer: what do you *think* you need to do so for?
21:33:39mkarrer: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:46sipa:mkarrer: offtopic here
21:34:24mkarrer:sipa: can u point me to the latest info regarding that topic?
21:34:37sipa:i can tell you my opinion, but not here
21:38:37Luke-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:48Luke-Jr:mkarrer: basically you just need miners to merge-mine a merkle tree of data hashes
21:40:05Luke-Jr:sipa: seems on-topic to me (well, insofar as possible solutions that aren't implemented)
21:40:38sipa:how to solve timestamping in blockchain-based systems, yes
21:40:44sipa:how to store data in bitcoin's chain now, no
21:41:22mkarrer: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:52sipa:right, that would be ontopic here
21:42:02Luke-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:15Luke-Jr:(only works with p2pool)
21:42:15sipa:it's not
21:42:22sipa:it's just the best theoretical solution
21:42:33sipa:it even has better-than-1-block resolution
21:44:26amiller:also check commit coin, you can bury it in a public key
21:45:40sipa:it's a nice trick, but still *puke*
21:45:59amiller:who cares though, still just storing a hash of some data
21:46:18sipa:imho, storing any non-transactional data in the blockchain is abuse
21:46:50sipa:with better solutions
21:47:26sipa: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:49sipa:unfortunately, everyone seems to interpret that as "storing data in the chain is ok!"
21:48:02amiller:do you think it is an abuse to send unnecessary transactions to yourself for fun
21:48:13amiller:like not true economic transfers of value, just noise
21:48:38sipa:that's a good question
21:48:40amiller: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:10amiller:commitcoin doesn't use OP_RETURN or any data stored in the blockchain besides transactions
21:49:19amiller:it embeds the commitment in the keypair
21:49:26sipa:yes, i know how it works
21:49:39amiller:so, it's not really non-transactional data
21:49:45sipa:sure it is
21:49:52amiller:if you had normal transactions to make, you could make those at the same time too
21:50:12sipa:that's something else i guess
21:50:34amiller: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:36sipa:it's a blurry line, and of course it's not enforceable
21:51:28amiller:it would be nice to make a commitcoin-integrated payment system that handles timestamping while in the course of performing other transactions.
21:51:30mkarrer:coin mixing would be a candidate as well... no real payment
21:51:30sipa:i guess the core problem is that there's economic incentive for some use cases to burden the blockchain
21:52:02sipa:which doesn't benefit those who pay the cost of it (blockchain storage, bandwidth, processing) without being rewarded for it (miners)
22:18:58justanot1eruser:sipa: you query it to prove you have the UTXO
22:19:28sipa:i have no idea what you're talking about
22:19:39sipa:a UTXO-based PoW algorithm?
22:20:04justanot1eruser:or prove you can access the UTXO quickly anyways
22:20:54Luke-Jr:sipa: the idea is forcing the miners to have the *ability* of validating transactions
22:21:31sipa:yes, i'm aware of that idea; just didn't know that was what he was talking about :)
22:21:32justanot1eruser:Anyways, would you have to do a new query every time you hashed the header?
22:22:01Luke-Jr:justanot1eruser: IMO yes, otherwise one could outsource the UTXO once
22:22:03justanot1eruser:like H(UTXO_Query(H(block_header)))?
22:22:11sipa:i believe the idea is to have some deterministic walk through the utxo set, with several iterations
22:22:26sipa:and use that to compute a hash value that must be low
22:23:07Luke-Jr:* Luke-Jr wonders if the last hash is necessary
22:23:29sipa:i should have said "hash"
22:23:40justanot1eruser:So this would make all ASICs useless?
22:23:51sipa:well, all current ones, obviously
22:23:57sipa:but nobody is proposing this for bitcoin itsel
22:24:36sipa:unless there's a near-breaking preimage attack on SHA2, i don't believe changing bitcoin's hash function is viable
22:25:22Luke-Jr:sipa: even if bitfury has 75% of all hashing?
22:38:54justanot1eruser: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:47justanot1eruser: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:32maaku:justanot1eruser: it is a very temporary phenomenon that asics have no lasting value
22:43:34zzyzx:zzyzx is now known as roidster
22:45:02justanot1eruser:maaku: yeah, and while that phenomenon is in effect, it wouldn't matter much if different ASICs began to be used
22:46:00maaku:justanot1eruser: it would matter a lot. you would invalidate overnight millions of dollars of capital investment
22:46:09tromp_: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:48andytoshi:is there a citation for PPC and/or FTC becoming centralized?
22:57:59gmaxwell:andytoshi: like https://bitcointalk.org/index.php?topic=282314.0
23:02:38andytoshi:awesome, thx
23:04:37gmaxwell: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:32andytoshi:interesting, presumably they had not heard of stake-grinding in the first interation
23:11:56gmaxwell: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:29gmaxwell: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:27andytoshi: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:50gmaxwell: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:37andytoshi:that's a good point, though in this case there is an obvious monetary incentive to attack
23:21:04gmaxwell:yep, and it was. and the current fixes are enough to reduce the subsidy gathering incentivies at least.
23:21:17gmaxwell:(they now use POW to pick the POS miners)
23:37:06justanot1eruser:maaku: it wouldn't invalidate their investment. They just wouldn't buy new ASICs if it was going to be unprofitable
23:40:04jaekwon:hi, i'm going to release a draft of the consensus protocol in 3 hours.
23:40:34jaekwon:would be great to get some feedback on it.
23:52:21amiller: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:25jaekwon:yup, i do that.
23:53:49jaekwon:i hope, sufficiently. but i might be wrong, which is why i need it reviewed :)
23:56:04amiller:sounds fun to me! good luck!