[Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks

[Peter Todd]

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 Todd]

Post by Peter Todd
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 Todd]

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.

Post by Peter Todd
Currently the most compact way (proof-size) to sacrifice Bitcoins that
does not involve making them unspendable is to create a anyone-can-spend
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.

[Jeff Garzik]

Post by Peter Todd
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.

[Peter Todd]

Post by Jeff Garzik
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.

Post by Jeff Garzik
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 <***@tormail.org> -----

Date: Sun, 02 Jun 2013 02:40:10 +0100
From: aitahk2l <***@tormail.org>
To: ***@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.

[Mark Friedenbach]

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

[Adam Back]

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

Post by Peter Todd
Currently the most compact way (proof-size) to sacrifice Bitcoins that
does not involve making them unspendable is to create a anyone-can-spend
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.
--
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
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Jeff Garzik]

Post by Adam Back
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.

[John Dillon]

Post by Jeff Garzik
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.

[Jeff Garzik]

On Tue, Jun 4, 2013 at 10:55 AM, John Dillon

Post by John Dillon

Post by Jeff Garzik
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]

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.

[Peter Todd]

Post by Jeff Garzik

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? :)

[Roy Badami]

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).

[Melvin Carvalho]

Post by Peter Todd
Currently the most compact way (proof-size) to sacrifice Bitcoins that
does not involve making them unspendable is to create a anyone-can-spend
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?

Post by Peter Todd
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.
--
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
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Michael Hendricks]

Post by Melvin Carvalho
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

[Luke-Jr]

Post by Peter Todd
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.

Post by Peter Todd
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

[Luke-Jr]

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!

Post by Peter Todd

Post by Peter Todd
scriptPubKey: <data> OP_TRUE
...
Along with that change anyone-can-spend outputs should be make

IsStandard()

Post by Peter Todd
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.

Post by Peter Todd
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
-------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Andreas M. Antonopoulos]

Post by Luke-Jr
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.

Post by Luke-Jr
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.

Post by Luke-Jr
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!

[Luke-Jr]

Post by Andreas M. Antonopoulos

Post by Luke-Jr
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.

Post by Andreas M. Antonopoulos
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".

Post by Andreas M. Antonopoulos
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.

Post by Andreas M. Antonopoulos

Post by Luke-Jr
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...

Post by Andreas M. Antonopoulos

Post by Luke-Jr
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

[Melvin Carvalho]

Post by Luke-Jr

Post by Andreas M. Antonopoulos

Post by Luke-Jr
This doesn't work like you might think: first of all, the fees today

are

Post by Andreas M. Antonopoulos

Post by Luke-Jr
greatly subsidized - the actual cost to store data in the blockchain is
much higher than most storage solutions. Secondly, only the miner

receives

Post by Andreas M. Antonopoulos

Post by Luke-Jr
the fees, not the majority of nodes which have to bear the burden of

the

Post by Andreas M. Antonopoulos

Post by Luke-Jr
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

Post by Andreas M. Antonopoulos
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.

Post by Luke-Jr

Post by Andreas M. Antonopoulos
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".

Post by Andreas M. Antonopoulos
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

Post by Andreas M. Antonopoulos
it needs to be neutral to content, like TCP/IP so that other protocols

can

Post by Andreas M. Antonopoulos
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.

Post by Andreas M. Antonopoulos

Post by Luke-Jr
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.

Post by Andreas M. Antonopoulos

Post by Luke-Jr
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...

Post by Andreas M. Antonopoulos

Post by Luke-Jr
This is how merged mining solves the problem. A single extra hash in

the

Post by Andreas M. Antonopoulos

Post by Luke-Jr
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
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Andreas M. Antonopoulos]

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!

Post by Peter Todd

Post by Peter Todd
scriptPubKey: <data> OP_TRUE
...
Along with that change anyone-can-spend outputs should be make

IsStandard()

Post by Peter Todd
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.

Post by Peter Todd
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
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Melvin Carvalho]

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 ...

Post by Peter Todd

Post by Peter Todd
scriptPubKey: <data> OP_TRUE
...
Along with that change anyone-can-spend outputs should be make

IsStandard()

Post by Peter Todd
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.

Post by Peter Todd
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
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/bitcoin-development