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

[Melvin Carvalho <melvincarvalho@gmail.com>]

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