* [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
@ 2013-06-01 19:30 Peter Todd
[not found] ` <201306012034.31543.luke@dashjr.org>
` (3 more replies)
0 siblings, 4 replies; 22+ messages in thread
From: Peter Todd @ 2013-06-01 19:30 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]
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: <data> 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
00000000000000ce3427502ee6a254fed27e1cd21a656a335cd2ada79b7b5293
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread[parent not found: <201306012034.31543.luke@dashjr.org>]
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks [not found] ` <201306012034.31543.luke@dashjr.org> @ 2013-06-01 20:58 ` Peter Todd 0 siblings, 0 replies; 22+ messages in thread From: Peter Todd @ 2013-06-01 20:58 UTC (permalink / raw) To: Luke-Jr; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1528 bytes --] On Sat, Jun 01, 2013 at 08:34:29PM +0000, Luke-Jr wrote: > On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote: > > scriptPubKey: <data> OP_TRUE > > > > ... > > Along with that change anyone-can-spend outputs should be make IsStandard() > > so they will be relayed. > > Data does not belong in the blockchain. People running nodes have all > implicitly agreed to store the blocks for financial purposes, and storing data > is a violation of that social contract. Proof-of-stake may be arguably > financial, but I'm sure there must be a way to do it without spamming people > against their consent. We have no way of preventing this, so ensure it's done in a way that minimizes harm. For instance, my zookeyv key-value consensus system can be implemented using transactions with txout pairs of the following form: Let H(d) = RIPEMD160(SHA256(d)) txout_k*2 : OP_DUP H(key) OP_EQUALVERIFY txout_k*2+1: OP_DUP H(value) OP_EQUALVERIFY With an additional rule to allow for references to previous sacrifices with txouts of the form: txout_n: OP_DUP H(txid:vout) OP_EQUALVERIFY This is perfectly compatible with Gregory Maxwell's address pre-image fix to data-in-chain storage, and at the same time is completely unblockable by making such transactions more expensive - the whole point is to prove you've sacrificed funds. Yet another reason why increasing the blocksize is madness. -- 'peter'[:-1]@petertodd.org 0000000000000018235c41836eb88ea45343c746a3704c5a155bb90c7d2d9a48 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <38A06794-B6B4-45F3-99C1-24B08434536D@gmail.com>]
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks [not found] ` <38A06794-B6B4-45F3-99C1-24B08434536D@gmail.com> @ 2013-06-02 6:13 ` Peter Todd 2013-06-02 17:35 ` Jeff Garzik 2013-06-04 0:22 ` Mark Friedenbach 0 siblings, 2 replies; 22+ messages in thread From: Peter Todd @ 2013-06-02 6:13 UTC (permalink / raw) To: Gavin [-- Attachment #1: Type: text/plain, Size: 2428 bytes --] On Sat, Jun 01, 2013 at 10:32:07PM -0400, Gavin wrote: > Feels like a new opcode might be better. > > Eg <data> 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 <pete@petertodd•org> 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: <data> 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 0000000000000092f448c7630e47584650efa7e27604161c0b5984d603d944ea [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-02 6:13 ` Peter Todd @ 2013-06-02 17:35 ` Jeff Garzik 2013-06-02 18:41 ` Peter Todd 2013-06-04 0:22 ` Mark Friedenbach 1 sibling, 1 reply; 22+ messages in thread From: Jeff Garzik @ 2013-06-02 17:35 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev On Sun, Jun 2, 2013 at 2:13 AM, Peter Todd <pete@petertodd•org> 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-02 17:35 ` Jeff Garzik @ 2013-06-02 18:41 ` Peter Todd 0 siblings, 0 replies; 22+ messages in thread From: Peter Todd @ 2013-06-02 18:41 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3194 bytes --] 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 <aitahk2l@tormail•org> ----- Date: Sun, 02 Jun 2013 02:40:10 +0100 From: aitahk2l <aitahk2l@tormail•org> To: pete@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 0000000000000046da2c6f02bf57f3bdc48a08388e0030fc4490f5fc048516e6 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-02 6:13 ` Peter Todd 2013-06-02 17:35 ` Jeff Garzik @ 2013-06-04 0:22 ` Mark Friedenbach 1 sibling, 0 replies; 22+ messages in thread From: Mark Friedenbach @ 2013-06-04 0:22 UTC (permalink / raw) To: bitcoin-development -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Jun 01, 2013 at 10:32:07PM -0400, Gavin wrote: >> Feels like a new opcode might be better. >> >> Eg <data> 100 OP_NOP1 >> >> ... Where op_nop1 is redefined to be 'verify depth' ... I would suggest the more general 'push depth onto stack'. You can then use the usual math/relational operators which otherwise have seen little use. Assuming it's even a good idea to go down this route at all. Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRrTNTAAoJEAdzVfsmodw4mf0QAJAej83Pth0ZVfua3I5+RR58 7gHpt2rBHP8KuwDH6J3VbxZDKy0n+6/nC5+kjI+G0tYGt3yU4wARJA+afB+zxScT DPO1iMRxcwOz6KtPWpyCEEOW4ZlILQmbhGyA7XZ+Oy+hZZMBWvPCt4BQsyTjUJ4Y +gTDqdkNk9B2HZh5gskXRkOYWGB9517tTQ0zYWLtVm2sgeJvRkd73WLZGHm4nrLI 20OLaTP0RuW5+qfV4BSQp/Y3k/9OqrAFXiXo5NAs6PL81x3/IDGKpsfnZNLxPU0i QLg9RdHZ9769fTgACO8822pLaWQ4LtLB4FA/mVYBhr/ORWSIKfod7TPGF3AYiIpF db2IESX2HFAxMQ9xTi/2R9zYwCvVpQWwZNse+DEMhoQhykcNv/+sZBE93xHGSgsq XKBOXLJGCxnUwszz+CSmwrQVmwPqLAU/fFybnAI/6VHMMd8phgNV5oLluAaZyBTi DpImUul2fqKaJeRjQBB1Qya7az0Qvf4LSHFDQKYYWG/H03R5CxFkxiM/XsiyuzpK 7+MVh6gnWaoayB/eAh0KVgWXUrQQGUBwvVmSk6DU73yQ8Db0BHaxBaUihlsJrMTX Ybh8d8GSbXsaUjolvJ/dSclcAw7ovW91jqEhRoBq9AKQA23RjHChzT8M1UkXZclZ 8k6XWOJy+NaNmklEwMqF =iDLz -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-01 19:30 [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks Peter Todd [not found] ` <201306012034.31543.luke@dashjr.org> [not found] ` <38A06794-B6B4-45F3-99C1-24B08434536D@gmail.com> @ 2013-06-02 21:45 ` Adam Back 2013-06-04 14:12 ` Jeff Garzik 2013-06-03 23:43 ` Melvin Carvalho 3 siblings, 1 reply; 22+ messages in thread From: Adam Back @ 2013-06-02 21:45 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin-Dev 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: <data> 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 >00000000000000ce3427502ee6a254fed27e1cd21a656a335cd2ada79b7b5293 >------------------------------------------------------------------------------ >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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-02 21:45 ` Adam Back @ 2013-06-04 14:12 ` Jeff Garzik 2013-06-04 14:55 ` John Dillon 0 siblings, 1 reply; 22+ messages in thread From: Jeff Garzik @ 2013-06-04 14:12 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin-Dev On Sun, Jun 2, 2013 at 5:45 PM, Adam Back <adam@cypherspace•org> wrote: > d) some new standardized spend to fees (only miners can claim). > 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? I'm one of the people experimenting in this area. I've long argued that a zero-output transaction should be permitted -- 100% miner fee -- as an elegant proof of sacrifice. Unfortunately that requires a hard fork. Also, for most people, it seems likely that a change transaction would be generated. That, then, would generate an already-standard transaction, where inputs > outputs. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-04 14:12 ` Jeff Garzik @ 2013-06-04 14:55 ` John Dillon 2013-06-04 17:42 ` Jeff Garzik 0 siblings, 1 reply; 22+ messages in thread From: John Dillon @ 2013-06-04 14:55 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin-Dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > I'm one of the people experimenting in this area. I've long argued > that a zero-output transaction should be permitted -- 100% miner fee > -- as an elegant proof of sacrifice. Unfortunately that requires a > hard fork. Also, for most people, it seems likely that a change > transaction would be generated. That, then, would generate an > already-standard transaction, where inputs > outputs. 100% miner fee is not a proof of anything because the miner could have created that transaction for themselves. You must have proof that all miners had an equal opportunity at collecting the fee, and the only way to do that is by Peter's announce-commit protocol, or his unspendable until after n blocks proposal. Also the idea of a zero-output transaction is silly. In almost all cases you are making the sarifice to link that act to an identity, and linking that act to arbitrary data is far more flexible than any scheme relying on the pubkeys that paid for the transaction. With a arbitrary data you can slice up the sacrifice for instance with a merkle-sum-tree, as well as hide what the sacrifice was for to preserve anonymity. The extra cost in size of the provably unspendable OP_RETURN scriptPubKey is minimal for the rare time when it isn't required. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRrf/BAAoJEEWCsU4mNhiP7+MH/RGfo2k+Zd0VoGzv3KSTzBrM auK9Do2fYp2YvMnT/JFYbz2MgbTcCiKGyZfxjaH+zrqdTFgkgAE53midIv/Rd5/w kjjifJuqw5AyIN6ANA1TuLQ64elPOXXymsaMqWO8ou0angG6DBI/LZZEG7SXM7+I Jwk3MXLhFswvvuRif4G2C9v29WqSj4XRxxl3o63ziSYvZPPCHLYHAL9BJaMpDhaw LxebM088RofzJAoGL1QIeQhDS3aAK4jKSZtJ/6+fwYZQB2Qc3sa1v9IAcCQHE+M3 6oQY0tzEEFg9+xdnSM7J6pW7qW28nFS8Fdr6UkUUlwhI5c4KnIKCtQa3o1mYDFE= =SHWS -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-04 14:55 ` John Dillon @ 2013-06-04 17:42 ` Jeff Garzik 2013-06-04 18:36 ` Roy Badami 0 siblings, 1 reply; 22+ messages in thread From: Jeff Garzik @ 2013-06-04 17:42 UTC (permalink / raw) To: John Dillon; +Cc: Bitcoin-Dev On Tue, Jun 4, 2013 at 10:55 AM, John Dillon <john.dillon892@googlemail•com> wrote: >> I'm one of the people experimenting in this area. I've long argued >> that a zero-output transaction should be permitted -- 100% miner fee >> -- as an elegant proof of sacrifice. Unfortunately that requires a >> hard fork. Also, for most people, it seems likely that a change >> transaction would be generated. That, then, would generate an >> already-standard transaction, where inputs > outputs. > > 100% miner fee is not a proof of anything because the miner could have created > that transaction for themselves. You must have proof that all miners had an > equal opportunity at collecting the fee, and the only way to do that is by > Peter's announce-commit protocol, or his unspendable until after n blocks > proposal. Absolutely. It wholly depends on the security model, and economic-incentives model. Some use models simply don't care if the miner created a transaction that gave the fee to themselves. It might even be /encouraged/ to do this! Sure they are paying themselves, but given bitcoin network difficulty is so high, simply obtaining payments-go-myself-as-miner transactions is itself difficult. Producing an identity (my goal) or whatever is just fine, and in such case becomes simply an additional block reward -- an additional incentive to buy into this identity creation/management system. Or exchange "identity" with another token, for another data service of your choice. This is no longer a strict "proof of sacrifice" system, if such behavior is encouraged, but it is nonetheless valid. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-04 17:42 ` Jeff Garzik @ 2013-06-04 18:36 ` Roy Badami 2013-06-04 18:49 ` Jeff Garzik 0 siblings, 1 reply; 22+ messages in thread From: Roy Badami @ 2013-06-04 18:36 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin-Dev > Sure they are paying themselves, but given bitcoin network > difficulty is uso high, simply obtaining payments-go-myself-as-miner > transactions is itself difficult. Not for pool operators it isn't. Nor for people buying hashing power from a GPUMAX-type service, if such services still exist (or should they exist again in future). ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-04 18:36 ` Roy Badami @ 2013-06-04 18:49 ` Jeff Garzik 2013-06-04 20:25 ` Peter Todd 0 siblings, 1 reply; 22+ messages in thread From: Jeff Garzik @ 2013-06-04 18:49 UTC (permalink / raw) To: Roy Badami; +Cc: Bitcoin-Dev On Tue, Jun 4, 2013 at 2:36 PM, Roy Badami <roy@gnomon•org.uk> wrote: >> Sure they are paying themselves, but given bitcoin network >> difficulty is uso high, simply obtaining payments-go-myself-as-miner >> transactions is itself difficult. > > Not for pool operators it isn't. Nor for people buying hashing power > from a GPUMAX-type service, if such services still exist (or should > they exist again in future). Re-read what I wrote. That's perfectly OK. It is analogous to a pool operator receiving merged mined coins, each time they mine a bitcoin block. If you achieve the very high difficulty needed to create a valid bitcoin block, you have achieved a very high bar. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-04 18:49 ` Jeff Garzik @ 2013-06-04 20:25 ` Peter Todd 0 siblings, 0 replies; 22+ messages in thread From: Peter Todd @ 2013-06-04 20:25 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin-Dev [-- Attachment #1: Type: text/plain, Size: 1607 bytes --] On Tue, Jun 04, 2013 at 02:49:54PM -0400, Jeff Garzik wrote: > On Tue, Jun 4, 2013 at 2:36 PM, Roy Badami <roy@gnomon•org.uk> wrote: > >> Sure they are paying themselves, but given bitcoin network > >> difficulty is uso high, simply obtaining payments-go-myself-as-miner > >> transactions is itself difficult. > > > > Not for pool operators it isn't. Nor for people buying hashing power > > from a GPUMAX-type service, if such services still exist (or should > > they exist again in future). > > Re-read what I wrote. That's perfectly OK. It is analogous to a pool > operator receiving merged mined coins, each time they mine a bitcoin > block. > > If you achieve the very high difficulty needed to create a valid > bitcoin block, you have achieved a very high bar. "High" is relative. I could make a 100BTC apparently sacrifice via fees by just waiting a month or two for my mining hardware to find a block that had a pre-prepared fake sacrifice. It'd cost me roughly 1BTC when you take orphans into account. Similarly I could hack into a pool and have them do it on my behalf, or a pool could just offer the service for a fee. I already worry enough that announce-commit sacrifices to mining fees aren't secure enough given the potential of a few large pools teaming up to create them cheaply, let alone what you're talking about... Hey Luke: so what's the going rate to get Eligius to mine a fake mining fee sacrifice? Can I get a discount on repeat orders? :) -- 'peter'[:-1]@petertodd.org 000000000000014c5bfacfca559fd6a9519dcd338f9fca6590eda7d156120013 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-01 19:30 [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks Peter Todd ` (2 preceding siblings ...) 2013-06-02 21:45 ` Adam Back @ 2013-06-03 23:43 ` Melvin Carvalho 2013-06-04 2:26 ` Michael Hendricks 3 siblings, 1 reply; 22+ messages in thread From: Melvin Carvalho @ 2013-06-03 23:43 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2490 bytes --] On 1 June 2013 21:30, Peter Todd <pete@petertodd•org> 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: <data> 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. > Sorry if this is a stupid question, but why would someone want to sacrifice their bitcoins? > > 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 > 00000000000000ce3427502ee6a254fed27e1cd21a656a335cd2ada79b7b5293 > > > ------------------------------------------------------------------------------ > 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 > > [-- Attachment #2: Type: text/html, Size: 3450 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-03 23:43 ` Melvin Carvalho @ 2013-06-04 2:26 ` Michael Hendricks 0 siblings, 0 replies; 22+ messages in thread From: Michael Hendricks @ 2013-06-04 2:26 UTC (permalink / raw) To: Melvin Carvalho; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 270 bytes --] On Mon, Jun 3, 2013 at 5:43 PM, Melvin Carvalho <melvincarvalho@gmail•com>wrote: > Sorry if this is a stupid question, but why would someone want to > sacrifice their bitcoins? > Good question. One reason is https://en.bitcoin.it/wiki/Fidelity_bonds Cheers, Michael [-- Attachment #2: Type: text/html, Size: 764 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks @ 2013-06-06 19:14 Luke-Jr 2013-06-06 19:59 ` Andreas M. Antonopoulos 0 siblings, 1 reply; 22+ messages in thread From: Luke-Jr @ 2013-06-06 19:14 UTC (permalink / raw) To: bitcoin-development On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote: > scriptPubKey: <data> OP_TRUE > > ... > Along with that change anyone-can-spend outputs should be make IsStandard() > so they will be relayed. Data does not belong in the blockchain. People running nodes have all implicitly agreed to store the blocks for financial purposes, and storing data is a violation of that social contract. Proof-of-stake may be arguably financial, but I'm sure there must be a way to do it without spamming people against their consent. > 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. The alternative is to make other standard outputs unable to store data as well. Luke ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-06 19:14 Luke-Jr @ 2013-06-06 19:59 ` Andreas M. Antonopoulos 2013-06-06 20:07 ` Luke-Jr 2013-06-06 20:25 ` Melvin Carvalho 0 siblings, 2 replies; 22+ messages in thread From: Andreas M. Antonopoulos @ 2013-06-06 19:59 UTC (permalink / raw) To: Luke-Jr; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 2698 bytes --] Is there any consideration given to the fact that bitcoin can operate as a platform for many other services, if it is able to be neutral to payload, as long as the fee is paid for the transaction size? Unless I have misunderstood this discussion, it seems to me that this is a bit like saying in 1990 "IP Is only for email, the majority of users want email, we shouldn't allow video, voice or images". Ooops, there goes the web. Is it possible to solve this by solving the issue of provably un-spendable outputs without foreclosing on the possibility of other types of transaction payloads (ie, not money), that would open the possibility for a myriad of layered apps above? For example, hashes of content that is external to bitcoin, that people want to pay to have timestamped in the blockchain, as provably unspendable outputs. The social compact is to accept transaction for fee. I think it is a major mistake to make decisions that discriminate on the content of the transaction, saying that some uses are not appropriate. If the fee is paid and it covers the size of the transaction, why would it matter if it is not a payment? I could be totally misreading this thread, too, so please allow me some slack if I have! On Thu, Jun 6, 2013 at 12:14 PM, Luke-Jr <luke@dashjr•org> wrote: > On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote: > > scriptPubKey: <data> OP_TRUE > > > > ... > > Along with that change anyone-can-spend outputs should be make > IsStandard() > > so they will be relayed. > > Data does not belong in the blockchain. People running nodes have all > implicitly agreed to store the blocks for financial purposes, and storing > data > is a violation of that social contract. Proof-of-stake may be arguably > financial, but I'm sure there must be a way to do it without spamming > people > against their consent. > > > 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. > > The alternative is to make other standard outputs unable to store data as > well. > > Luke > > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 3740 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-06 19:59 ` Andreas M. Antonopoulos @ 2013-06-06 20:07 ` Luke-Jr 2013-06-06 20:16 ` Andreas M. Antonopoulos 2013-06-06 20:25 ` Melvin Carvalho 1 sibling, 1 reply; 22+ messages in thread From: Luke-Jr @ 2013-06-06 20:07 UTC (permalink / raw) To: Andreas M. Antonopoulos; +Cc: bitcoin-development On Thursday, June 06, 2013 7:59:16 PM Andreas M. Antonopoulos wrote: > Is there any consideration given to the fact that bitcoin can operate as a > platform for many other services, if it is able to be neutral to payload, > as long as the fee is paid for the transaction size? This doesn't work like you might think: first of all, the fees today are greatly subsidized - the actual cost to store data in the blockchain is much higher than most storage solutions. Secondly, only the miner receives the fees, not the majority of nodes which have to bear the burden of the data. That is, the fee system is setup as an antispam/deterrant, not as payment for storage. > Unless I have misunderstood this discussion, it seems to me that this is a > bit like saying in 1990 "IP Is only for email, the majority of users want > email, we shouldn't allow video, voice or images". Ooops, there goes the > web. Not the same thing at all; nobody is forced to store/relay video/voice/images without reimbursement. On the other hand, any full Bitcoin node is required to at least download the entire blockchain once. And the network as a whole suffers if nodes decide to start not-storing parts of the blockchain they don't want to deal with. > Is it possible to solve this by solving the issue of provably un-spendable > outputs without foreclosing on the possibility of other types of > transaction payloads (ie, not money), that would open the possibility for a > myriad of layered apps above? For example, hashes of content that is > external to bitcoin, that people want to pay to have timestamped in the > blockchain, as provably unspendable outputs. This is how merged mining solves the problem. A single extra hash in the coinbase can link the bitcoin blockchain up with unlimited other data. > The social compact is to accept transaction for fee. I think it is a major > mistake to make decisions that discriminate on the content of the > transaction, saying that some uses are not appropriate. If the fee is paid > and it covers the size of the transaction, why would it matter if it is not > a payment? See above. > I could be totally misreading this thread, too, so please allow me some > slack if I have! > > On Thu, Jun 6, 2013 at 12:14 PM, Luke-Jr <luke@dashjr•org> wrote: > > On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote: > > > scriptPubKey: <data> OP_TRUE > > > > > > ... > > > Along with that change anyone-can-spend outputs should be make > > > > IsStandard() > > > > > so they will be relayed. > > > > Data does not belong in the blockchain. People running nodes have all > > implicitly agreed to store the blocks for financial purposes, and storing > > data > > is a violation of that social contract. Proof-of-stake may be arguably > > financial, but I'm sure there must be a way to do it without spamming > > people > > against their consent. > > > > > 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. > > > > The alternative is to make other standard outputs unable to store data as > > well. > > > > Luke > > > > > > ------------------------------------------------------------------------- > > ----- How ServiceNow helps IT people transform IT departments: > > 1. A cloud service to automate IT design, transition and operations > > 2. Dashboards that offer high-level views of enterprise services > > 3. A single system of record for all IT processes > > http://p.sf.net/sfu/servicenow-d2d-j > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-06 20:07 ` Luke-Jr @ 2013-06-06 20:16 ` Andreas M. Antonopoulos 2013-06-06 21:48 ` Luke-Jr 0 siblings, 1 reply; 22+ messages in thread From: Andreas M. Antonopoulos @ 2013-06-06 20:16 UTC (permalink / raw) To: Luke-Jr; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 2353 bytes --] > This doesn't work like you might think: first of all, the fees today are > greatly subsidized - the actual cost to store data in the blockchain is > much > higher than most storage solutions. Secondly, only the miner receives the > fees, not the majority of nodes which have to bear the burden of the data. > That is, the fee system is setup as an antispam/deterrant, not as payment > for > storage. > There's a difference between storing the content itself, and storing just a hash to content (which however is not spendable payment). I undertand why content itself doesn't belong. But it goes too far to say that only payments should be allowed. If the fees are not enough, fix the fee structure, don't stop incredibly innovative and promising uses of the distributed timestamping database. That is definitely throwing the baby out with the bathwater. If the issue is size, then address that, rather than the content itself. Have I misunderstood this discussion or are some proposing than nothing except payments be allowed? Discriminating based on transaction content violates neutrality of the protocol and in my mind removes a very very large possibility of future innovation. If bitcoin is a *platform* and not just a payment system, then it needs to be neutral to content, like TCP/IP so that other protocols can be layered. Solve the size problem itself, without picking and chosing which uses of bitcoin are good and which are "bad" or "spam". I think it risks killing a tremendous amount of innovation just as it is starting. > > > > Not the same thing at all; nobody is forced to store/relay > video/voice/images > without reimbursement. On the other hand, any full Bitcoin node is > required to > at least download the entire blockchain once. And the network as a whole > suffers if nodes decide to start not-storing parts of the blockchain they > don't want to deal with. > > So don't store content, but allow hashes of content. Again, I think it is extreme and extremely restrictive to say that ONLY payments are allowed. > This is how merged mining solves the problem. A single extra hash in the > coinbase can link the bitcoin blockchain up with unlimited other data. > > > Can you explain this part or refer me to some docs? What do you mean by "coinbase", I assume not the company. Thanks for the reply and explanation! > [-- Attachment #2: Type: text/html, Size: 3418 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-06 20:16 ` Andreas M. Antonopoulos @ 2013-06-06 21:48 ` Luke-Jr 2013-06-06 22:10 ` Melvin Carvalho 0 siblings, 1 reply; 22+ messages in thread From: Luke-Jr @ 2013-06-06 21:48 UTC (permalink / raw) To: Andreas M. Antonopoulos; +Cc: bitcoin-development On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopoulos wrote: > > This doesn't work like you might think: first of all, the fees today are > > greatly subsidized - the actual cost to store data in the blockchain is > > much higher than most storage solutions. Secondly, only the miner receives > > the fees, not the majority of nodes which have to bear the burden of the > > data. That is, the fee system is setup as an antispam/deterrant, not as > > payment for > > storage. > > There's a difference between storing the content itself, and storing just a > hash to content (which however is not spendable payment). I undertand why > content itself doesn't belong. But it goes too far to say that only > payments should be allowed. Because payments are the only thing everyone using Bitcoin has agreed to use the blockchain for. Furthermore, there is no *reason* to store non-payments in the blockchain. If there was in fact such a use case, things might be arguable - but there isn't any I'm aware of. > If the fees are not enough, fix the fee structure, don't stop incredibly > innovative and promising uses of the distributed timestamping database. > That is definitely throwing the baby out with the bathwater. If the issue > is size, then address that, rather than the content itself. The issue is using other peoples' resources for something they did not agree to use it for. The fees aren't merely "not enough", they were never *intended* to be "cost of storage". They are "cost of security" and "prevent spamming". > Discriminating based on transaction content violates neutrality of the > protocol and in my mind removes a very very large possibility of future > innovation. If bitcoin is a *platform* and not just a payment system, then > it needs to be neutral to content, like TCP/IP so that other protocols can > be layered. Solve the size problem itself, without picking and chosing > which uses of bitcoin are good and which are "bad" or "spam". I think it > risks killing a tremendous amount of innovation just as it is starting. The concepts behind Bitcoin are applicable to future innovation, but this can all be accomplished without spamming Bitcoin itself. > > Not the same thing at all; nobody is forced to store/relay > > video/voice/images without reimbursement. On the other hand, any full > > Bitcoin node is required to at least download the entire blockchain once. > > And the network as a whole suffers if nodes decide to start not-storing > > parts of the blockchain they don't want to deal with. > > > > So don't store content, but allow hashes of content. > > Again, I think it is extreme and extremely restrictive to say that ONLY > payments are allowed. Non-payments are quite possible without the Bitcoin blockchain itself. If you're worried that not enough people will store the alternative-non-payment data, then you are essentially saying that voluntary participation is not enough and that forced storage is your solution. I don't think this is what you intend... > > This is how merged mining solves the problem. A single extra hash in the > > coinbase can link the bitcoin blockchain up with unlimited other data. > > Can you explain this part or refer me to some docs? What do you mean by > "coinbase", I assume not the company. The Bitcoin blockchain protocol has 95 bytes per block reserved for miners to put extra data. Currently, this is used for extranonces, political or other short messages (such as in the Genesis block), miner "signatures", and also, as I mentioned, merged mining. Merged mining works by tying a non- transactional merkle tree to the blockchain. The block coinbase stores the hash of the top of this merkle tree, so any data within the merkle tree can prove it is associated to the block. The merged mining merkle tree then stores hashes of multiple other data sets: for example, a Namecoin block can be referenced in a merged mining merkle tree, to use the Bitcoin block's proof- of-work for itself (so, miners can mine both Bitcoin and Namecoin using the same hashing effort). You could also add other non-transactional blocks to the merged mining merkle tree, for generic timestamping or really anything at all. Luke ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-06 21:48 ` Luke-Jr @ 2013-06-06 22:10 ` Melvin Carvalho 0 siblings, 0 replies; 22+ messages in thread From: Melvin Carvalho @ 2013-06-06 22:10 UTC (permalink / raw) To: Luke-Jr; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 5564 bytes --] On 6 June 2013 23:48, Luke-Jr <luke@dashjr•org> wrote: > On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopoulos wrote: > > > This doesn't work like you might think: first of all, the fees today > are > > > greatly subsidized - the actual cost to store data in the blockchain is > > > much higher than most storage solutions. Secondly, only the miner > receives > > > the fees, not the majority of nodes which have to bear the burden of > the > > > data. That is, the fee system is setup as an antispam/deterrant, not as > > > payment for > > > storage. > > > > There's a difference between storing the content itself, and storing > just a > > hash to content (which however is not spendable payment). I undertand why > > content itself doesn't belong. But it goes too far to say that only > > payments should be allowed. > > Because payments are the only thing everyone using Bitcoin has agreed to > use > the blockchain for. Furthermore, there is no *reason* to store > non-payments in > the blockchain. If there was in fact such a use case, things might be > arguable > - but there isn't any I'm aware of. > Two quotes satoshi: "Piling every proof-of-work quorum system in the world into one dataset doesn't scale." and "I like Hal Finney's idea for user-friendly timestamping. Convert the hash of a file to a bitcoin address and send 0.01 to it" This leads me to believe, that while bitcoin should not be over used as a time stamp server, there could be a balance reached for casual time stamp recording as part of satoshi's concept. What we call "spam" is to a degree subjective, and I think not always obvious, tho in some cases it clearly is. > > If the fees are not enough, fix the fee structure, don't stop incredibly > > innovative and promising uses of the distributed timestamping database. > > That is definitely throwing the baby out with the bathwater. If the issue > > is size, then address that, rather than the content itself. > > The issue is using other peoples' resources for something they did not > agree > to use it for. The fees aren't merely "not enough", they were never > *intended* > to be "cost of storage". They are "cost of security" and "prevent > spamming". > > > Discriminating based on transaction content violates neutrality of the > > protocol and in my mind removes a very very large possibility of future > > innovation. If bitcoin is a *platform* and not just a payment system, > then > > it needs to be neutral to content, like TCP/IP so that other protocols > can > > be layered. Solve the size problem itself, without picking and chosing > > which uses of bitcoin are good and which are "bad" or "spam". I think it > > risks killing a tremendous amount of innovation just as it is starting. > > The concepts behind Bitcoin are applicable to future innovation, but this > can > all be accomplished without spamming Bitcoin itself. > > > > Not the same thing at all; nobody is forced to store/relay > > > video/voice/images without reimbursement. On the other hand, any full > > > Bitcoin node is required to at least download the entire blockchain > once. > > > And the network as a whole suffers if nodes decide to start not-storing > > > parts of the blockchain they don't want to deal with. > > > > > > So don't store content, but allow hashes of content. > > > > Again, I think it is extreme and extremely restrictive to say that ONLY > > payments are allowed. > > Non-payments are quite possible without the Bitcoin blockchain itself. If > you're worried that not enough people will store the > alternative-non-payment > data, then you are essentially saying that voluntary participation is not > enough and that forced storage is your solution. I don't think this is what > you intend... > > > > This is how merged mining solves the problem. A single extra hash in > the > > > coinbase can link the bitcoin blockchain up with unlimited other data. > > > > Can you explain this part or refer me to some docs? What do you mean by > > "coinbase", I assume not the company. > > The Bitcoin blockchain protocol has 95 bytes per block reserved for miners > to > put extra data. Currently, this is used for extranonces, political or other > short messages (such as in the Genesis block), miner "signatures", and > also, > as I mentioned, merged mining. Merged mining works by tying a non- > transactional merkle tree to the blockchain. The block coinbase stores the > hash of the top of this merkle tree, so any data within the merkle tree can > prove it is associated to the block. The merged mining merkle tree then > stores > hashes of multiple other data sets: for example, a Namecoin block can be > referenced in a merged mining merkle tree, to use the Bitcoin block's > proof- > of-work for itself (so, miners can mine both Bitcoin and Namecoin using the > same hashing effort). You could also add other non-transactional blocks to > the > merged mining merkle tree, for generic timestamping or really anything at > all. > > Luke > > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 7150 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks 2013-06-06 19:59 ` Andreas M. Antonopoulos 2013-06-06 20:07 ` Luke-Jr @ 2013-06-06 20:25 ` Melvin Carvalho 1 sibling, 0 replies; 22+ messages in thread From: Melvin Carvalho @ 2013-06-06 20:25 UTC (permalink / raw) To: Andreas M. Antonopoulos; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3536 bytes --] On 6 June 2013 21:59, Andreas M. Antonopoulos <andreas@rooteleven•com>wrote: > Is there any consideration given to the fact that bitcoin can operate as a > platform for many other services, if it is able to be neutral to payload, > as long as the fee is paid for the transaction size? > > Unless I have misunderstood this discussion, it seems to me that this is a > bit like saying in 1990 "IP Is only for email, the majority of users want > email, we shouldn't allow video, voice or images". Ooops, there goes the > web. > > Is it possible to solve this by solving the issue of provably un-spendable > outputs without foreclosing on the possibility of other types of > transaction payloads (ie, not money), that would open the possibility for a > myriad of layered apps above? For example, hashes of content that is > external to bitcoin, that people want to pay to have timestamped in the > blockchain, as provably unspendable outputs. > > The social compact is to accept transaction for fee. I think it is a major > mistake to make decisions that discriminate on the content of the > transaction, saying that some uses are not appropriate. If the fee is paid > and it covers the size of the transaction, why would it matter if it is not > a payment? > > I could be totally misreading this thread, too, so please allow me some > slack if I have! > +1 we're still early into the bitcoin story ... unexpected reuse should not be ruled out ... > > > > > On Thu, Jun 6, 2013 at 12:14 PM, Luke-Jr <luke@dashjr•org> wrote: > >> On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote: >> > scriptPubKey: <data> OP_TRUE >> > >> > ... >> > Along with that change anyone-can-spend outputs should be make >> IsStandard() >> > so they will be relayed. >> >> Data does not belong in the blockchain. People running nodes have all >> implicitly agreed to store the blocks for financial purposes, and storing >> data >> is a violation of that social contract. Proof-of-stake may be arguably >> financial, but I'm sure there must be a way to do it without spamming >> people >> against their consent. >> >> > 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. >> >> The alternative is to make other standard outputs unable to store data as >> well. >> >> Luke >> >> >> ------------------------------------------------------------------------------ >> How ServiceNow helps IT people transform IT departments: >> 1. A cloud service to automate IT design, transition and operations >> 2. Dashboards that offer high-level views of enterprise services >> 3. A single system of record for all IT processes >> http://p.sf.net/sfu/servicenow-d2d-j >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 5166 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2013-06-06 22:10 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-01 19:30 [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks Peter Todd
[not found] ` <201306012034.31543.luke@dashjr.org>
2013-06-01 20:58 ` Peter Todd
[not found] ` <38A06794-B6B4-45F3-99C1-24B08434536D@gmail.com>
2013-06-02 6:13 ` Peter Todd
2013-06-02 17:35 ` Jeff Garzik
2013-06-02 18:41 ` Peter Todd
2013-06-04 0:22 ` Mark Friedenbach
2013-06-02 21:45 ` Adam Back
2013-06-04 14:12 ` Jeff Garzik
2013-06-04 14:55 ` John Dillon
2013-06-04 17:42 ` Jeff Garzik
2013-06-04 18:36 ` Roy Badami
2013-06-04 18:49 ` Jeff Garzik
2013-06-04 20:25 ` Peter Todd
2013-06-03 23:43 ` Melvin Carvalho
2013-06-04 2:26 ` Michael Hendricks
2013-06-06 19:14 Luke-Jr
2013-06-06 19:59 ` Andreas M. Antonopoulos
2013-06-06 20:07 ` Luke-Jr
2013-06-06 20:16 ` Andreas M. Antonopoulos
2013-06-06 21:48 ` Luke-Jr
2013-06-06 22:10 ` Melvin Carvalho
2013-06-06 20:25 ` Melvin Carvalho
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox