--- Log opened Thu Jul 04 00:00:10 2013
14:49 < adam3us> petertodd: not afk? about your proof of sacrifice somewhat resistant to miner inside attack, not sure if you saw my additional thought
14:50 < adam3us> petertodd: i think it averages out to pay to miners in proportion to their mining power, so you could more simply achieve the same effect by paying to miners in proportion to their rolling average proportion of nework power (with some signature annotation saying this is a proof of donation to miners)
15:22 < petertodd> But that's not a sacrifice without a solid way to pick the lucky miner randomly.
15:24 < petertodd> ...and that doesn't work because there is no way to commit the funds such that if a miner is picked that you do not want the funds to go to the funds will go to them anyway - Bitcoin just can't do that in the scripting system.
16:29 < adam3us> petertodd: but what is special about giving it to a random miner in (chances biased in proportion to their power) vs just giving it to the miners in proportion to their recent demonstration of power (eg last month).  if they keep running for another month the effect in terms of what they receive will be basically the same right?
16:30 < adam3us> petertodd: I dont know why you would not want the funds to go to a specific miner, but the approach you discussed recently doesnt prevent that either, because well a random miner will win, you have no control
16:54 < petertodd> We're talking about sacrifices; if the destination of the funds can be controlled it's probably not a true sacrifice.
16:57 < adam3us> petertodd: my point is the approach you proposed a few days ago, it has the property that funds are given to miners, with some randomness, but presuming lots of people make proofs of sacrifice over time that will average out anyway, so the net result is that miners (all of them) receive funds in proportion to their percentage of network power, agreed?
16:59 < adam3us> petertodd: and is so, you can simplify and achieve the same effect by just paying to miners in proportion to their wins over the last month (pay to all of them, a multiple output); you would need some special annotation to indicate this is not just a payment to miners, its a sacrifice to miners and that will be validated by other full nodes against the correct proportion being paid to the miners against the validated average network power
17:01 < petertodd> But doing that in Bitcoin is impossible if you want to ensure the person making the sacrifice can't direct it to themselves.
17:01 < petertodd> If you don't ensure that, it's not a true sacrifice.
17:02 < petertodd> What you are proposing would be at minimum a soft fork involving a lot of complex code with no advantage over a random model - it all evens out in the end.
17:04 < petertodd> Not to mention what you really want is anyone-can-spend outputs that remain locked for long enough that even if a pool has, say, 40% hashing power and is willing to play dirty and make sacrifices knowing that 40% of the time they'll mine the fees anyway it is unknown to them if they'll be in business by the time the output is spendable. IE sacrifices that only go back to miners after multiple months.
17:04 < adam3us> petertodd: i am not saying the sacrificer can spend to themselves, they can only spend to the miners during the last month, in proportion to the power (1GH = 100 satoshi sacrfice or whatever ratio), and if the sacrificer pays to the wrong proportion or to the wrong users, it will be rejected by all validators (full nodes)
17:05 < petertodd> In that circumstance you're wasting a lot of bytes paying multiple miners at once.
17:05 < petertodd> Besides, as I say what you really want is the fees to be collected far into the future.
17:07 < adam3us> well its true that you have multiple outputs, though I suppose you could compact that by having hte payment automatically go to the mining winners keys from the designated time period
17:07 < petertodd> Automatically is no good because it makes miner fraud proof protocols incredibly complex and bulky.
17:08 < adam3us> if you want it to apply in the future, make it a future time period
17:08 < petertodd> ?
17:09 < adam3us> so as I said compact payment by saying the sacrifice amount goes to the miners in proportion to their power measured in a historic time interval (last month)
17:10 < petertodd> Your compact payment assumes a lot of very non-compact code and extra state in the UTXO set.
17:10 < adam3us> if you want to delay that so they have to fight for power in the future say miners get their reward 3months in the future based on the average starting 30 days from 3months ahead, same basic idea
17:10 < petertodd> But again, there really isn't any compelling reason to do any of this stuff.
17:12 < adam3us> well the reason i suggested it is it seemed slightly simpler than the other proposal
17:13 < petertodd> How is it simpler?
17:14 < adam3us> so as i recall your proposal was something like to time-lock sacrifice payment and then reveal that later, this approach does not need two stage, nor commitments
17:15 < adam3us> this approach is mostly a calculation on existing information; though I dare say complicating validation is generally not a good thing
17:16 < petertodd> Yeah, we're not going to change validation for this. At best we might decide to make it possible to lock a txout for a given amount of time, but that can be done with a new opcode as a soft-fork.
17:17 < petertodd> Honestly, IMO all this talk about sacrifices via mining fees is probably the wrong approach, just sacrifice to unspendable outputs and be done with it until it's possible to lock an anyone-can-spend for n blocks.
17:18 < adam3us> i agree making coins unspendable is more reliable, an dactually is indirectly a gift to everyone I think.
17:18 < adam3us> it creates a little bit of deflation, I was thinking
17:18 < petertodd> Yup
17:19 < petertodd> If Bitcoin sacrifices become something a lot of people do it's then worth it to make those sacrifices into mining fees, but otherwise why bother?
17:19 < adam3us> so they are not actually destroyed (which feels bad to people somehow) it may not be bad
17:19 < adam3us> doesnt it just transfer money to everyone via deflation, in the presence of the same demand, after all
17:20 < adam3us> even at non-negligible scale
17:21 < petertodd> We need more ways to direct funds to miners sure, but if very few sacrifices are being made just destroying the coins isn't much of a loss.
17:22 < petertodd> Bit of a PR issue with some people who don't understand how divisible Bitcoins are...
17:25 < adam3us> (yes) i was thinking recently of another idea, that maybe there could be a bit of non-validated mining, the network could tolerate that
17:25 < petertodd> x% of non-validated mining turns a 51% attack into a 51-x% attack...
17:25 < petertodd> Nothing more to it than that.
17:26 < adam3us> say eg whenever you make a payment you can do a bit of mining on the transaction
17:26 < adam3us> this is true
17:26 < petertodd> Right, you're talking about my powpay thing...
17:26 < adam3us> the advantage is i can do that with my GPU in smaller amounts than a block
17:26 < adam3us>  without being a full node
17:27 < petertodd> The thing is Bitcoin doesn't really have much use for separate PoW schemes because we already have transferable PoW in the form of fees and coin age.
17:28 < adam3us> well my interest was direct mining, to create fees.  direct mined coins are more private, and they could be used for the committed coin idea i was talking about back some weeks ago
17:29 < adam3us> fees are quite small so it would not have to be a big %
17:29 < petertodd> You quickly run into the problem that the difference in profit between ASICs and anything else ishuge.
17:30 < petertodd> So huge even doing a bit of mining to earn some fees doesn't make all that much sense.
17:32 < adam3us> yep i expect presently asic will be so fast gpu wont recover electricity, however with small fees it might still be nice to direct mine fees for privacy
17:32 < petertodd> I think you'd be better off implementing trust-free mixing and/or fidelity bonded chaum banks frankly.
17:33 < petertodd> Solving the privacy problem more generally would be very good.
17:37 < adam3us> yes well zerocoin is supposedly coming out soon, however i think its quite inefficient
17:38 < petertodd> zerocoin is brute force rather than elegance
17:39 < adam3us> you could make a zerocoin only network - they only did the exchange with bc to zc and vice versa as an integration method, but that doesnt affect the efficiency
17:39 < petertodd> Yeah, and with zc->bc exchanges it creates a very profitable 51% attack target.
--- Log closed Fri Jul 05 00:00:13 2013