00:01:49 <[\\\]> [\\\] has joined #bitcoin-wizards 00:03:09 DougieBot5000 has quit 00:07:08 roidster has joined #bitcoin-wizards 00:07:32 jtimon has joined #bitcoin-wizards 00:08:38 situation has quit 00:09:47 zzyzx has quit 00:10:32 adam3us has joined #bitcoin-wizards 00:13:07 Ursium_ has quit 00:14:12 rdymac has joined #bitcoin-wizards 00:15:07 situation has joined #bitcoin-wizards 00:19:25 crowex has quit 00:21:04 rs2 has joined #bitcoin-wizards 00:22:50 AndChat-522641 has joined #bitcoin-wizards 00:24:18 AndChat|522641 has quit 00:26:14 rs2 has quit 00:30:13 rs2 has joined #bitcoin-wizards 00:31:04 crowex has joined #bitcoin-wizards 00:32:31 AndChat-522641 has quit 00:34:49 tromp has quit 00:35:24 tromp has joined #bitcoin-wizards 00:38:46 tromp has quit 00:39:01 tromp has joined #bitcoin-wizards 00:43:49 ghtdak has joined #bitcoin-wizards 00:54:03 crowex has quit 00:54:24 mr_burdell has joined #bitcoin-wizards 01:01:00 roconnor has quit 01:03:26 crowex has joined #bitcoin-wizards 01:05:28 crowex has quit 01:14:27 AndChat|522641 has joined #bitcoin-wizards 01:15:39 rs2 has quit 01:16:16 wallet42 has joined #bitcoin-wizards 01:18:55 AndChat|522641 has quit 01:27:00 TheSeven has quit 01:40:29 tromp has quit 01:41:02 tromp has joined #bitcoin-wizards 01:44:58 Man. Someone needs to redo The Producers for modern times. It should be about developer and a trader duo that due to some crazy futures contract have to make their altcoin become worthless. 01:44:59 tromp has quit 01:45:03 And they make it scammier and scammer but the price keeps going up. 01:50:02 gavinandresen has joined #bitcoin-wizards 01:57:14 haha 02:00:17 fanquake has joined #bitcoin-wizards 02:00:54 tromp has joined #bitcoin-wizards 02:01:12 Ursium has joined #bitcoin-wizards 02:05:41 bizzle has quit 02:06:24 bizzle has joined #bitcoin-wizards 02:07:39 crowex has joined #bitcoin-wizards 02:08:31 (wikipedia and imdb disagree on 'the' year of that film -- '67 and '68, respectively -- i wonder if they define it differently or just errorism...) 02:10:40 bizzle has quit 02:18:35 gavinandresen has quit 02:19:23 Krellan_ has quit 02:22:31 crowex has quit 02:25:05 wallet42 has quit 02:26:05 austinhill has joined #bitcoin-wizards 02:30:03 wallet42 has joined #bitcoin-wizards 02:31:14 gmaxwell: LOL! 02:32:05 tetra has quit 02:32:51 nsh_ has joined #bitcoin-wizards 02:32:52 nsh has quit 02:38:21 wallet42 has quit 02:41:56 wallet42 has joined #bitcoin-wizards 02:48:57 c0rw1n has joined #bitcoin-wizards 02:50:16 austinhill has quit 02:50:44 tt_texas is now known as tacotime_ 02:52:05 TheSeven has joined #bitcoin-wizards 02:53:22 ssj4mo has joined #bitcoin-wizards 02:53:53 ssj4mo_e has joined #bitcoin-wizards 02:54:11 ssj4mo has quit 02:54:15 ssj4mo_e has quit 02:54:34 ssj4mo has joined #bitcoin-wizards 03:11:59 HM has quit 03:21:18 HM has joined #bitcoin-wizards 03:23:15 spin123456 has quit 03:23:40 spinza has joined #bitcoin-wizards 03:23:45 Guest42545 is now known as weex 03:23:57 weex has quit 03:23:57 weex has joined #bitcoin-wizards 03:35:32 ssj4mo has quit 03:36:43 ssj4mo has joined #bitcoin-wizards 03:54:17 gmaxwell: ROFL 04:01:48 wallet42 has quit 04:03:13 c0rw1n has quit 04:09:48 c0rw1n has joined #bitcoin-wizards 04:42:15 ghtdak has quit 04:46:54 TheSeven has quit 04:47:02 <[7]> [7] has joined #bitcoin-wizards 04:48:38 kanzure has quit 04:48:42 jrmithdobbs has quit 04:49:44 kanzure has joined #bitcoin-wizards 04:52:34 jrmithdobbs has joined #bitcoin-wizards 05:29:31 artifexd has quit 05:37:11 super3 has quit 05:38:28 artifexd has joined #bitcoin-wizards 05:41:03 tromp has quit 05:41:35 tromp has joined #bitcoin-wizards 05:46:20 tromp has quit 05:46:58 LarsLarsen has quit 05:47:59 CodeShark has quit 05:52:40 gmaxwell: classic! 05:55:50 roidster has quit 05:59:38 CodeShark has joined #bitcoin-wizards 06:02:23 CodeShark has quit 06:02:44 CodeShark has joined #bitcoin-wizards 06:03:33 roasbeef_ is now known as roasbeef 06:23:44 wallet42 has joined #bitcoin-wizards 06:28:24 bizzle has joined #bitcoin-wizards 06:33:06 bizzle has quit 06:38:30 antephialtic has quit 06:59:36 rdymac has quit 07:00:42 rdymac has joined #bitcoin-wizards 07:00:43 gmaxwell: brilliant 07:02:05 Ksipax has joined #bitcoin-wizards 07:03:40 for someone who knows SNARKs better than I do, it is possible to have a generic, circuit-independent verificaiton routine which takes a verification key and a proof and validates it for any input program, correct? 07:28:31 tetra has joined #bitcoin-wizards 07:30:03 c0rw1n has quit 07:32:48 ielo has joined #bitcoin-wizards 07:44:52 ssj4mo has quit 07:45:17 <_ingsoc> _ingsoc has joined #bitcoin-wizards 07:45:23 ssj4mo has joined #bitcoin-wizards 07:48:57 n/m, reading the pinocchio paper... 08:03:41 sure, a universal circut. thats what the tinyram stuff is about. they define a circuit for a load/store processor that runs N steps (e.g. verifies any program that completes in at least N step) 08:05:05 gmaxwell: but you could write a generic function that takes vk,input,output,proof as returns true/false, and works for any circuit, right? 08:05:46 i mean, using tinyram is not necessary, right? 08:07:05 i'm trying to see if I can get two-way pegging down to one SNARK verfication opcode and a single protocol rule 08:07:11 yes. assuming that vk is different for different circuits OR vk is a vk for a universal circut (like tinyram) which you've used and input includes the config. 08:07:47 ok cool, that means i'm starting to get an intuitive grasp for this :) 08:07:50 maaku: yes. well not quite one opcode, you'll need extra opcodes to push the right data onto the stack for the input. 08:08:32 yes of course, i meant just one new opcode extension, as a soft-fork 08:08:42 but thats exactly what I imagined in the coinwitness post. That there would just be an OP_SNARK. 08:10:53 plus either one more opcode or a pattern matching rule to make sure the quieting output is of a specific form, also a soft fork change 08:11:02 wallet42 has quit 08:11:06 i'm much more confident about this now that I'm reasonably certain it can be done as a soft-fork 08:11:48 actually you don't necessarily need an op code that does anything about the outputs! 08:12:20 you make either the snark opcode act like a checksig and gets a hash of the transaction or you add an opcode to push a hash of the transaction onto the stack 08:12:28 and thats all you need. 08:12:52 because you make the hash of the transaction a public input to the snark, and then as a private input to the snark you give it the whole transaction. 08:13:08 and the snark checks the outputs and runs the hash and checks agreement! 08:13:44 (this is the coin covenants post where I'm mostly pointing out that if a snark signs the transaction at all, you can have output restrictions even if you never intended to enable them. 08:13:47 sneaky 08:13:48 ) 08:14:32 that is suitably evil 08:15:53 ok given that this enables covenants, how confident are you that it could get adopted? 08:16:53 imho an evil-covenanted coin is no worse than a lost coin, but i realize that isn't the popular opinion when the topic comes up... 08:17:32 I think covenants are too useful (as PT pointed out they can give you compactly verifyable colored coins) 08:17:45 you can always choose to refuse to accept them. 08:18:00 yeah that's my argument 08:18:06 since you choose what scriptpubkeys you reconize as yours. 08:18:08 MoALTz has joined #bitcoin-wizards 08:18:09 besides, I don't know how you'd recognize them in the first place 08:18:14 -yeah 08:19:03 right, they're not something that would surprise you. I think in general they are bad and can be misused and people should be cautioned against them.. but I don't think thats enough reason to deny a very powerful feature esp removing them is quite difficult. 08:19:57 you can even have them today, if you have n/m signing oracles .. e.g. that can insist you provide the tx they're signing for inspection for agreement with rules. 08:24:29 crowex has joined #bitcoin-wizards 08:25:06 I do in any case think we should have an opcode that takes a masking setting and pushes tag,h(mask_setting,mask(mask_setting,transaction)) onto a special signing stack or the like so that you can control what you're signing from within the script. 08:28:59 crowex has quit 08:30:44 what is tag in this context? 08:32:35 you mean a generalization of the sighash flags? 08:32:42 a description of which opcode was used to push the data. it must be tagged so that you can't use a data push instead of a mask_transaction push 08:33:35 otherwise you can take a transaction save its masked hash and replace the OP_MASKTX_TO_SIGSTACK with a OP_PUSHTOSIGSTACK 08:33:50 and thereby steal coins. 08:36:39 ok. it's nothing special though, just the byte/opcode index perhaps? 08:37:20 yea, just the opcode you're using I think is fine, just to prevent emulation of a transaction push with a data push. 08:37:37 in any case you could construct complicated masking schemes just by making multiple OP_MASKTX_TO_SIGSTACK pushes. 08:38:32 e.g. if one of the settings for OP_MASKTX_TO_SIGSTACK is a lets you pick txouts one at a time. 08:39:56 Ksipax has quit 08:40:02 OP_MASKTX & SIGSTACK is something I need to contemplate. is this written up anywhere? 08:42:26 I might discussed it in passing but I'm not sure which post. I'm not entirely sure if it's worth it of if some point it just becomes 'screw it' use a snark. though if you want malleability you can't really do snark masking, since the snark would need to be recomputed. 08:43:16 mostly all this stemming from the in ability to do a SIGHASH SINGLE that obligates two txouts, or even just a different tx out than your current index. 08:44:24 tromp has joined #bitcoin-wizards 08:46:14 wait, if the snark accepts as input the full (unsigned) transaction, then ignores some parts of it, if those ignored parts are changed the snark proof becomes invalid? 08:46:21 even though the output doesn't change? 08:47:04 yes, because the hash input to the snark proof changes. 08:47:12 i see 08:47:17 so someone needs to rerun the proof to make sure it still likes it 08:47:38 this is one reason why flexible masking is still useful even though in theory you can do all masking inside the snark 08:48:17 gribble has quit 08:48:23 another reason is because doing any masking inside the snark requires proving that the transaction and the hash agree, and that means running the hash in the snark.. and thats a bunch of extra work for the prover. 08:48:55 tromp has quit 08:49:17 edulix_ has joined #bitcoin-wizards 08:49:26 have you thought about the format for the configuration of this masker? are bitfields specifying inputs & outputs to include sufficient? 08:50:05 mike4 has joined #bitcoin-wizards 08:50:17 I have, and I think something like that is acceptable, figuring out what the most efficient way to encode the masks seems like an interesting problem. 08:50:41 Sangheil- has joined #bitcoin-wizards 08:51:17 basically I think you want some cases to be efficient: for each data type (inputs, outputs): all, none, a few at random, some range contigiously to all be reasonably efficient to encode. 08:51:43 gribble has joined #bitcoin-wizards 08:51:43 yeah last time I thought about this I got hung up on figuring out how to make these masking modes composable 08:51:52 sipa_ has joined #bitcoin-wizards 08:51:53 without requring equal numbers of inputs & outputs 08:52:06 mikalv_ has joined #bitcoin-wizards 08:52:15 nsh__ has joined #bitcoin-wizards 08:52:23 hence the freimarkets sub-transactions which punts the problem to a hard fork 08:52:31 there is also a question of wanting to do masking like outputx, clamping the bitcoin amount it pays to min(actual,2 btc). but maybe you just say if you want masking that complicated, get a snark. 08:52:42 though it's actually a very useful thing to do. 08:53:50 e.g. say you're going to do a kickstarter thing, output 0 pays to the project, you put in 2 btc using a 3 btc coin. You want to sign output 0 clamped to min(actual,2), and sign output N (completely) 08:54:14 I sign any txn spending my coin, such that at least 2 btc go here, and 1 btc go to me. 08:55:00 I waver on the use: the problem is that you can eliminate the need by using a multiple round protocol where the users agree on the values first. 08:55:12 Aesthetic has joined #bitcoin-wizards 08:55:29 nsh_ has quit 08:55:31 the problem with that solution, however, is that multiple round protocols are actually really hard to implement and create a bunch of obnoxious failure modes, including accidental ones. 08:56:03 keus has quit 08:56:04 d34th has quit 08:56:04 copumpkin has quit 08:56:05 mikalv has quit 08:56:05 edulix has quit 08:56:05 Sangheili has quit 08:56:05 c--O-O has quit 08:56:07 Logicwax has quit 08:56:07 sipa has quit 08:56:12 "oh, bob went offline, we need to start over. oh bob came back. oh bob is gone again. oh bob is back. oh crap we werent smart enough to write code to deal with bob flapping" 08:56:23 darnit freenode 08:56:24 hrm, the mask specification could be relative to an encoded offset to the other side, which is intentionally malleable 08:56:31 i think i may have just eliminated the need for sub-transactions 08:57:16 yeah 08:57:34 yea I had assumed at one point basically leaving the mask specifier out of the hash (though I see I fucked that up above) for that reason. 08:58:06 basically if you haven't covered the whole tx someone should be able to add/reorder outputs and fixup your masks. 08:58:43 well, yes, but is there a way for them to exploit that? 08:58:58 and I figured with a sigstack if you just had optcodes for PUSH1, PUSHall, PUSHrange you could cover the cases I thought need to be efficient. 08:59:17 it's malleability but if you leave in a way to sign all I think its a non issue. 08:59:38 also malleability can be a non-issue if you leave a way out of including the f@#$@# vin:index out of the signature. 09:00:04 (and use a refusal to reuse pubkeys as a way to make sure the right coin gets spent) 09:00:31 which is really how I think you should handle protocols that need precomputed refunds. 09:08:18 well this has been an enlightening discussion. thank you, gregory 09:08:31 i need to get some sleep so my SO doesn't kill me in the morning :) 09:13:57 goood night! 09:15:44 koshii has joined #bitcoin-wizards 09:16:09 koshii has quit 09:18:25 c0rw1n has joined #bitcoin-wizards 09:23:06 c0rw1n has quit 09:28:00 jtimon has quit 10:00:23 super3 has joined #bitcoin-wizards 10:38:12 I think it would a good idea to make introduce a proof-of-stake blockchain in bitcoin, so that there would be 2 blockchains simultaneously running - pow and pos. Neither blockchain will allow the inputs spend on the other blockchain. Putting aside the complexity of implementation, is this a sound idea? 10:39:55 nsh__ has quit 10:39:56 nsh__ has joined #bitcoin-wizards 10:39:57 nsh__ is now known as nsh 10:40:41 how would that be different from bitcoin + a PoS altcoin? 10:41:35 ielo has quit 10:41:38 nsh, it will allow bitcoin to peacefully make a transision to pos without cause a revolt from the pow miners. 10:44:37 also the diff with an altcoin is that the pos coins are already distributed and there is no need to start from scratch 10:45:07 I mean, when bitcoin makes a transision to pos, the coins are already distributed fairly 10:45:16 okay, it's not a good idea. 10:54:04 go1111111 has quit 11:19:21 wallet42 has joined #bitcoin-wizards 11:21:18 wallet42 has quit 11:26:37 wallet42 has joined #bitcoin-wizards 11:27:19 ielo has joined #bitcoin-wizards 11:28:30 wallet42 has quit 11:34:16 crowex has joined #bitcoin-wizards 11:36:59 antephialtic has joined #bitcoin-wizards 11:37:51 c0rw1n has joined #bitcoin-wizards 11:42:12 irclouis has quit 11:46:40 dansmith_btc: yeah, uhh... I'm with nsh here. since there are two separate blockchains, you've essentially just created an altcoin 12:01:23 wallet42 has joined #bitcoin-wizards 12:08:58 wallet42 has quit 12:15:43 crowex has left #bitcoin-wizards 12:16:27 crowex has joined #bitcoin-wizards 12:24:01 wallet42 has joined #bitcoin-wizards 12:26:08 nsh_ has joined #bitcoin-wizards 12:26:58 samson_ has quit 12:27:40 samson_ has joined #bitcoin-wizards 12:27:52 nsh has quit 12:34:41 wallet42 has quit 12:35:45 crowex has quit 12:35:59 crowex has joined #bitcoin-wizards 12:36:31 crowex has quit 13:19:08 antephialtic has quit 13:48:54 dansmith_btc: you mix "Neither blockchain will allow the inputs spend on the other blockchain." with "when bitcoin makes a transision to pos, the coins are already distributed fairly" 13:48:58 this does not make sense 13:49:02 please xplain 13:49:27 also keep in mind that nobody has demonstrated the viability of any proof-of-stake system yet 13:49:48 cpacia has joined #bitcoin-wizards 13:53:59 cpacia has quit 14:04:49 <_ingsoc> _ingsoc has quit 14:09:43 cpacia has joined #bitcoin-wizards 14:10:35 MrUtuber has joined #bitcoin-wizards 14:10:40 MrUtuber has left #bitcoin-wizards 14:13:59 nOgAnOo has quit 14:21:29 Luke-Jr, what I meant is if you introduce a new PoS altcoin right now, people will see it as "not fair" if the early adopters get all the coins (like what nextcoin did). But since the current distribution of bitcoins is perceived to be fair as it is, then it is much easier to make a gradual transition to PoS. 14:23:00 Of course I wasn't going to discuss the merits of PoS vs PoW, I just assumed for the sake of simplicity that PoS is more secure than PoW. 14:25:27 I'm not gonna reiterate the theoretical benefits of Pos, they are covered in the wiki, I was just exploring whether it is a technologically feasible idea of having 2 blockchains Pow and PoS. 14:26:04 The PoW blockchain can still be used by miners until we get the 21 mil promise, but the PoS will be there for the transactions. 14:27:41 dansmith_btc: ..."the theoretical benefits of PoS" are not covered anywhere because it is not known whether PoS consensus is possible 14:28:06 nOgAnOo has joined #bitcoin-wizards 14:30:44 also the suggestion that you can just snapshot the bitcoin utxo set at some random height to get a 'fair' distribution of coins doesn't really make sense, that's a very arbitrary distribution 14:35:32 andytoshi, what I have in mind is PoS which randomly chooses the next miner based on their btc balance. So, starting at some agreed-upon point there will have to be a utxo snapshot. What exactly "doesn't make sense"? 14:39:21 what doesn't make sense is that it's completely unfair, you are assigning coins to people who are probably not even aware of it in a random fashion. then i don't get what "randomly" means, how does everyone agree on the random selection of miner, and why would they agree? what if the chosen miner does not respond? 14:40:56 andytoshi: the follow the satoshi scheme like that usually uses an exponentially rolling difficulty for the chosen miner. 14:41:24 so that for the chosen miner, the difficulty is n, for the next miner, n*2, then n*4, etc 14:41:57 in this way it's difficult to get "stuck", but you can also miss your turn i guess. 14:42:03 and if you don't agree, you're overruled out by the broadcast checkpoint ;) 14:42:11 tacotime_: if the miner is chosen anyway, what does the difficulty accomplish? 14:42:33 and what does it mean to 'miss your turn', you'd need some sort of distributed timestamp mechanism to detect that 14:42:41 as for the random number picked by finding a block... you can pick most of the non-leading bits (a little past the zeros) iirc 14:42:57 andytoshi: preventing burn-through (rapid consumption of blocks) and the problem of a non-responsive miner. 14:43:01 of the hash i mean 14:43:21 andytoshi, what I was suggestng is that new coins continue to be mined by PoW miners, it is only new transactions that will be accepted into a block by the PoS miner. You are right, I shouldnt have used the word "randomly chosen", because the PoS miner gets chosen based on their btc stake - the larger their stake, the more frequently the miner gets chosen. 14:43:25 andytoshi: yeah, that's an issue too. 14:44:01 dansmith: that's what my fork and iddo's fork does, although they're both not totally functional yet. 14:44:10 dansmith_btc: i'm not worried about the specific distribution, i'm worried about consensus. as MoALTz says you can just use bitcoin blockhashes (and i guess tie your blocktimes to bitcoin's) 14:44:43 tacotime_: unless your difficulty scales like bitcoin's, you're going to have rapid blocks, and if you are choosing the next miner based on PoS blocks then that can obviously be gamed by a fast miner 14:44:57 tacotime_: otoh if you are choosing the next miner based on bitcoin blocks, you have a natural throttle already 14:45:09 andytoshi, right 14:45:44 wallet42 has joined #bitcoin-wizards 14:46:35 all the pos mechanisms that make the most sense to me require pow too. but, yeah, these are in the works and will probably be released in the near future. 14:47:24 bitcoin kind of already has a built in pos mechanism through the nodes though, and if someone forks the network the major players are going to see it and select a single fork to work on anyway. :P 14:48:13 I feel like it's less of a problem than people make it out to be. 14:48:59 I just want to do my PoS mechanism because it seems interesting, and I'm curious what security/consensus it affords (or doesn't). 14:49:01 istm that if you have pow anyway then you have accomplished nothing environmentally, but you've made your consensus code way more complicated and introduced a ton of incentive hacks, esp. if the txes you choose to mine affect your future chances of being a voter 14:50:49 tacotime_: cool, sounds like a fun experiment. but i don't think it'll work out for a currency 14:51:19 if you can tie it to the bitcoin PoW for consensus/throttling maybe there are other applications which are compatible with the screwy incentives, def something to think about 14:53:14 jtimon has joined #bitcoin-wizards 14:53:59 nsh_ has quit 14:54:33 eg there have been political ideas to the effect of replacing voting with simply conscripting congressmen at random from the population. if you made the choice based on bitcoin blockhashes every 100000 blocks (and included 100000 hashes in the calc) or whatever that's globally visible and impossible to game 14:54:39 Yeah, one theoretical application was voting consensus among stakeholders and PoW miners for what they think the rewards should be, and see how they interact. You would think PoW would always vote PoW reward up and PoS down, and then vice versa. 14:55:03 andytoshi: that's sorta how it works 14:55:18 http://mc2.xwebnetwork.com/storage/mc2_0.05.pdf 14:55:39 also note that what is said about the hash only applies if you're doing competitive PoW (where you want to post your solution as soon as you find one). it doesn't work if the miner gets to find multiple solutions to pick the one that favors him (where PoS mostly replaces PoW that might be the case) 14:55:51 Forgive any lame/nontechnical ideas in the paper, I don't have a heavy math bg. 14:56:11 you said at the conference you used to be a grad student? what in? 14:56:20 Biochemistry 14:57:00 ohhh it's so long 14:57:04 cool, i'll check it out :) 14:57:35 A lot in there is "technical specifications", there's a bug in the chain selection method too in that version. 14:58:54 I try to keep the "how this works in a nutshell" stuff in the beginning. 15:12:35 wallet42 has quit 15:14:41 jtimon has quit 15:21:05 tromp has joined #bitcoin-wizards 15:22:22 <_ingsoc> _ingsoc has joined #bitcoin-wizards 15:26:13 Fistful_of_LTC is now known as Fistful_of_Coins 15:33:59 cpacia has quit 15:37:57 dansmith_btc: my point is that if PoS and PoW blockchains don't mix, they can't provide any benefit to each other. also, like 10% of bitcoins are *stolen* - I doubt many would consider it "fair" distribution 15:39:37 wallet42 has joined #bitcoin-wizards 15:41:29 Luke-Jr, I agree they don't mix. I am proposing to use the two so that the current pow miners would not feel cheated when the transision is made. As I mentioned earlier, why not let the existing miners mine their 25 reward blocks and at the same time use PoS blockchain to confirm transactions. 15:42:39 IMO the PoW distribution is *only* fair because of the value miners provide the network.. 15:42:48 My initial supposition was that PoS blobkchain is superior, i.e. lesser fees, higher attack cost, so people would naturally gravitate towards PoS if given an option. 15:42:55 if not for that, it would be retarded 15:44:23 if PoW mining is non-existent, I would think the obvious initial distribution would be to simply put a tiny amount at every possible scriptPubKey :p 15:46:15 (eg, allow outputs to be +.000000000001 BTC more than inputs) 15:46:46 Luke-Jr, sorry but I have a hard time understanding your responses. It seems like we are not on the same page or maybe I'm not following. 15:47:16 dansmith_btc: perhaps the problem is you are working with a fixed set of assumptions that I find almost entirely wrong ;) 15:50:03 wallet421 has joined #bitcoin-wizards 15:50:03 wallet42 is now known as Guest31878 15:50:03 Guest31878 has quit 15:50:03 wallet421 is now known as wallet42 15:50:17 Luke-Jr, do you think if a point in the future is chosen and from that point on users will choose whether to send their txs to PoW miners or to PoS miners (while PoW miners continue to mint btc until 21 mil is reached), do you think there is some unfairness in that? 15:51:26 dansmith_btc: yes. but perhaps tolerable unfairness. 15:52:17 Luke-Jr, I would love to hear your opinion on what exactly the unfairness is? Is it the breaking of the initial promise that PoW miners get all the tx fees? 15:54:22 dansmith_btc: miners are rewarded for providing a value to the network. if they no longer provide that value, it makes no sense for them to get the subsidy even 15:54:23 copumpkin has joined #bitcoin-wizards 15:54:59 note miners were never guaranteed the PoW algo would remain fixed either (although they have a voice in that as community members of course 15:57:52 Luke-Jr, are you trying to say that if the switch to PoS is made, there is no point in continuing to give block rewards to PoW miners because they dont provide any value anymore? 16:07:12 If yes, then I agree, but I suggest that they continue to get their block reward in order to avoid PoW miners' revolt. Because if we set a date in the future when the transision to PoS will be made, the PoW miners sensing their impending demise can collude and attack the system. So, unless the exixting PoW miners are guaranteed their continuing block rewards even after transitioning to PoS, they won't cooperate. 16:14:41 mike4 is now known as c--O-O 16:14:53 c--O-O has quit 16:14:53 c--O-O has joined #bitcoin-wizards 16:14:53 c--O-O has quit 16:14:53 c--O-O has joined #bitcoin-wizards 16:15:42 jtimon has joined #bitcoin-wizards 16:20:00 Hunger-- has quit 16:27:25 tromp has quit 16:27:57 tromp has joined #bitcoin-wizards 16:28:36 Hunger- has joined #bitcoin-wizards 16:32:27 tromp has quit 16:34:14 rdymac has quit 16:36:07 this is why peercoin uses a hybrid model 16:36:42 PoW is simply a better model for fair distribution of the coins, while PoS is a better model for securing the chain 16:37:25 hypocrite! I was witness to you failing proof-of-steak! 16:38:16 :p 16:38:57 Luke-Jr, I was tricked. I used the wrong algo because I didn't read the menu. 16:39:27 awww what proof of steak actually happened and i missed it!? 16:39:38 tacotime_: nah, not really 16:39:46 tacotime_: super3 had the option the night before we met 16:39:54 ah okay haha 16:40:06 he ordered ssomething else 16:40:08 lol 16:40:11 super3: uhhh wtf. 16:40:28 super3: It doesn't even appear that PoS is actually viable at all for securing the chain. :( 16:42:09 if I was to implement this on Bitcoin I would do a hybrid system. you would gradually increase the PoS until the day when the block reward runs out. that way you have a secure chain and the miners are happy. 16:42:22 gmaxwell, explain 16:42:34 super3, that's exactly what I had in mind 16:42:40 i 16:42:58 What do you mean ... explain? this isn't some remarkable new position. 16:43:21 i'm not convinced that he fees can sustain the miners after the block reward runs out 16:43:24 I'm basically blown away to see you expressing a view that it was better when I think the overall view is that it's not clear that its workable _at all_ 16:43:42 yea, perhaps PoW is not workable a long time in the future for bitcoin either. 16:44:08 But PoS doesn't work immediately due to the nothing at stake problem. 16:44:47 I wonder if it would work to just accept a pubkeyhash signature to do blocks, with the accepted range of hashes doubling every 0x1000th of a day 16:44:54 (which is why peercoin had mandatory developer signed blocks, and mandatory POW to select the randomness for PoS) 16:44:55 let me read your bitcointalk post about this 16:45:01 (so after ~5 mins, any key works) 16:45:10 or maybe 0x100th (90 mins) 16:46:41 well, I guess it'd need to adjust for difficulty perhaps 16:47:03 which is probaably non-linear already 16:49:58 gmaxwell, did a little reading and i agree with your position 16:50:31 super3, what thread is that? 16:50:38 super3: wow! what does that mean for Peercoin? XD 16:50:44 dansmith_btc, found it via google here https://bitcointalk.org/index.php?topic=430683.0 16:51:16 super3: it's been discussed in a bunch of places... it's really irritating I can't tell you how many hours I've spent trying to think up solutions. 16:51:27 gmaxwell: it's a hard problem. 16:51:45 my solution was simply "use PoW as tiebreaker". but it's not very elegant. 16:52:05 that just reduces to PoW I think, with some constant factors shuffled around. 16:52:23 Well, yeah, PoW with random stakeholder verification. 16:52:38 I've carefully considered several specific variations of that, at least and convinced myself that they were really just PoW with some constant factors. 16:52:55 gmaxwell, i think PoS + another algoritm to get you that last mile might work 16:53:06 i like that people are playing around with other algoritms though 16:53:06 (re my idea on a gradual acceptance of a keyhash: obvious flaw is that it allows a "miner" to build up a database of keyhashes and keep using it over and over :/) 16:53:53 someone might come up with something we could have never thought of 16:53:57