* [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
* 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
* 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-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-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-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-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-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-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 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 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
* 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 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 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: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
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