Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
So the idea is that people may want to use proof-of-work unrelated to bitcoin, and abuse bitcoin to obtain that proof, in a way denominated in BTC (and with a published USD exchange rate). And the ways they can do that are to: a) create unspendable addresses (which maybe you cant compact in the UTXO set if the unspendable address choices are not standardized) b) spend to anyone which I take it goes to a random person who happens to see the address first and race the "spend to me" out on to the network, and hope miners dnt replace it with "spend to miner", which is insecure c) doesnt delay by 100 blocks just delay the "spend to me" race? Also most likely to be one by a big miner once they adapt and join the race. d) some new standardized spend to fees (only miners can claim). e) spend to charity/non-profit of choice could be useful also f) I guess we see something related in zerocoin - locked but unlockable via another type of transaction later. g) why not instead make the beneficiary the address of the service the user is consuming that is being DoS protected by the proof-of-sacrifice? Seems more useful than burning virtual money, then it helps the bitcoin network AND it helps the service provide better service! so if I understand what you proposed d) seems like a useful concept if that is not currently possible. eg alternatively could we not just propose a standard recognized address that clearly no-one knows the EC discrete log of? Adam On Sat, Jun 01, 2013 at 03:30:36PM -0400, Peter Todd wrote: >Currently the most compact way (proof-size) to sacrifice Bitcoins that >does not involve making them unspendable is to create a anyone-can-spend >output as the last txout in the coinbase of a block: > >scriptPubKey: OP_TRUE > >The proof is then the SHA256 midstate, the txout, and the merkle path to >the block header. However this mechanism needs miner support, and it is >not possible to pay for such a sacrifice securely, or create an >assurance contract to create one. > >A anyone-can-spend in a regular txout is another option, but there is no >way to prevent a miner from including a transaction spending that txout >in the same block. Once that happens, there is no way to prove the miner >didn't create both, thus invalidating the sacrifice. The announce-commit >protocol solves that problem, but at the cost of a much larger proof, >especially if multiple parties want to get together to pay the cost of >the sacrifice. (the proof must include the entire tx used to make the >sacrifice) > >However if we add a rule where txouts ending in OP_TRUE are unspendable >for 100 blocks, similar to coinbases, we fix these problems. The rule >can be done as a soft-fork with 95% support in the same way the >blockheight rule was implemented. Along with that change >anyone-can-spend outputs should be make IsStandard() so they will be >relayed. > >The alternative is sacrifices to unspendable outputs, which is very >undesirable compared to sending the money to miners to further >strengthen the security of the network. > >We should always make it easy for people to write code that does what is >best for Bitcoin. > >-- >'peter'[:-1]@petertodd.org >00ce3427502ee6a254fed27e1cd21a656a335cd2ada79b7b5293 >-- >Get 100% visibility into Java/.NET code with AppDynamics Lite >It's a free troubleshooting tool designed for production >Get down to code-level detail for bottlenecks, with <2% overhead. >Download for free and get started troubleshooting in minutes. >http://p.sf.net/sfu/appdyn_d2d_ap2 >___ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
On Sun, Jun 02, 2013 at 01:35:10PM -0400, Jeff Garzik wrote: > It is a fair criticism that this inches the incentives, a bit, towards > timestamping and other non-currency uses. But those uses (a) cannot > be prevented and (b) have already been automated anyway (e.g. the > python upload/download tools stored in-chain). Yeah, and Bitcoin sacrifices are kind of an odd middle ground there. It's been suggested to make provably unspendable OP_RETURN IsStandard() only if the txout value is zero, but considering the sacrifice use-case I'm thinking we should allow people to throw away coins in a non-UTXO-bloating way if they choose too. > I do think the overwhelming majority of users are invested in > bitcoin-the-currency (or bitcoin-the-commodity, take your pick), i.e. > the value proposition. That's our 98% use case. Given the relative > volumes of traffic, timestamping/data storage/messaging is essentially > getting a free ride. So IMO it is worth continuing to explore > /disincentives/ for use of the blockchain for data storage and > messaging, for the rare times where a clear currency-or-data-storage > incentive is available. Indeed, just recognize that those disincentives must be implemented in a way that makes doing the less-harmful thing is to your advantage. For instance people keep arguing for OP_RETURN to only be allowed as one txout in a tx, which puts it at a disadvantage relative to just using unspendable outputs. Similarly because people can play OP_CHECKMULTISIG games, allow as much data as can be included in that form, 195 bytes. Of course, you can't block everything: - Forwarded message from aitahk2l - Date: Sun, 02 Jun 2013 02:40:10 +0100 From: aitahk2l To: p...@petertodd.org Subject: Your timestamper We spoke a few months back and I sent you some funds to run your timestamper. I'm letting you know we're going back to unspendable txout timestamps for our needs. Your service is great, but I think you have written it prematurely. Like you said in your recent bitcoin-development post on sacrifices if the technology enables a use, people will use it. Inefficient timestamping is one such use and threatens the blockchain with unlimited bloat, but from what I hear from Gavin he doesn't see decentralization as particularly important. You really should turn off your OpenTimestamps servers. They mislead people into a sense of scalability that just isn't there. You'll see some of our efforts at 1MBGavinWuiJCF6thGfEriB2WhDD5nhB2a soon; frankly I think he is the biggest threat Bitcoin faces in the long term and will back us all into a scalability corner with no good solutions. Feel free to forward this message to others. - End forwarded message - Seems legit - traffic on my timestamper is significantly reduced from what it was before. Incidentally, I've left the opentimestamps client deliberately broken for months now to see if anyone used it, and other than this guy I've had zero bug reports. -- 'peter'[:-1]@petertodd.org 0046da2c6f02bf57f3bdc48a08388e0030fc4490f5fc048516e6 signature.asc Description: Digital signature -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
On Sun, Jun 2, 2013 at 2:13 AM, Peter Todd wrote: > I'd say we tell people to sacrifice to (provably) unspendable for now > and do a soft-fork later if there is real demand for this stuff in the > future. That seems fair. In general, people are actively bloating the UTXO set with unspendable outputs (that cannot be 100% proven unspendable). Provably unspendable seems like an improvement on long term UTXO health. It is a fair criticism that this inches the incentives, a bit, towards timestamping and other non-currency uses. But those uses (a) cannot be prevented and (b) have already been automated anyway (e.g. the python upload/download tools stored in-chain). I do think the overwhelming majority of users are invested in bitcoin-the-currency (or bitcoin-the-commodity, take your pick), i.e. the value proposition. That's our 98% use case. Given the relative volumes of traffic, timestamping/data storage/messaging is essentially getting a free ride. So IMO it is worth continuing to explore /disincentives/ for use of the blockchain for data storage and messaging, for the rare times where a clear currency-or-data-storage incentive is available. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
On Sat, Jun 01, 2013 at 10:32:07PM -0400, Gavin wrote: > Feels like a new opcode might be better. > > Eg 100 OP_NOP1 > > ... Where op_nop1 is redefined to be 'verify depth' ... Good idea. Either way, looks like complex announce-commit logic isn't needed and a simple txout with one of a few possible forms will work. I'd say we tell people to sacrifice to (provably) unspendable for now and do a soft-fork later if there is real demand for this stuff in the future. > On Jun 1, 2013, at 3:30 PM, Peter Todd wrote: > > > Currently the most compact way (proof-size) to sacrifice Bitcoins that > > does not involve making them unspendable is to create a anyone-can-spend > > output as the last txout in the coinbase of a block: > > > > scriptPubKey: OP_TRUE > > > > The proof is then the SHA256 midstate, the txout, and the merkle path to > > the block header. However this mechanism needs miner support, and it is > > not possible to pay for such a sacrifice securely, or create an > > assurance contract to create one. > > > > A anyone-can-spend in a regular txout is another option, but there is no > > way to prevent a miner from including a transaction spending that txout > > in the same block. Once that happens, there is no way to prove the miner > > didn't create both, thus invalidating the sacrifice. The announce-commit > > protocol solves that problem, but at the cost of a much larger proof, > > especially if multiple parties want to get together to pay the cost of > > the sacrifice. (the proof must include the entire tx used to make the > > sacrifice) > > > > However if we add a rule where txouts ending in OP_TRUE are unspendable > > for 100 blocks, similar to coinbases, we fix these problems. The rule > > can be done as a soft-fork with 95% support in the same way the > > blockheight rule was implemented. Along with that change > > anyone-can-spend outputs should be make IsStandard() so they will be > > relayed. > > > > The alternative is sacrifices to unspendable outputs, which is very > > undesirable compared to sending the money to miners to further > > strengthen the security of the network. > > > > We should always make it easy for people to write code that does what is > > best for Bitcoin. -- 'peter'[:-1]@petertodd.org 0092f448c7630e47584650efa7e27604161c0b5984d603d944ea signature.asc Description: Digital signature -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
