From: "Andreas M. Antonopoulos" <andreas@rooteleven•com>
To: Luke-Jr <luke@dashjr•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
Date: Thu, 6 Jun 2013 13:16:40 -0700 [thread overview]
Message-ID: <CAFmyj8zDCjGR6cLUXQnWP4G0k6A85vdNW03k5NPAVyoJj0eEnQ@mail.gmail.com> (raw)
In-Reply-To: <201306062007.41398.luke@dashjr.org>
[-- 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 --]
next prev parent reply other threads:[~2013-06-06 20:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2013-06-06 21:48 ` Luke-Jr
2013-06-06 22:10 ` Melvin Carvalho
2013-06-06 20:25 ` Melvin Carvalho
-- strict thread matches above, loose matches on Subject: below --
2013-06-01 19:30 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFmyj8zDCjGR6cLUXQnWP4G0k6A85vdNW03k5NPAVyoJj0eEnQ@mail.gmail.com \
--to=andreas@rooteleven$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox