From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UkiNv-0007n6-Vt for bitcoin-development@lists.sourceforge.net; Thu, 06 Jun 2013 22:10:20 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.48 as permitted sender) client-ip=209.85.215.48; envelope-from=melvincarvalho@gmail.com; helo=mail-la0-f48.google.com; Received: from mail-la0-f48.google.com ([209.85.215.48]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UkiNu-0002FQ-CH for bitcoin-development@lists.sourceforge.net; Thu, 06 Jun 2013 22:10:19 +0000 Received: by mail-la0-f48.google.com with SMTP id lx15so2059126lab.7 for ; Thu, 06 Jun 2013 15:10:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.219.133 with SMTP id po5mr792111lbc.80.1370556611587; Thu, 06 Jun 2013 15:10:11 -0700 (PDT) Received: by 10.112.2.8 with HTTP; Thu, 6 Jun 2013 15:10:11 -0700 (PDT) In-Reply-To: <201306062148.16611.luke@dashjr.org> References: <201306061914.20006.luke@dashjr.org> <201306062007.41398.luke@dashjr.org> <201306062148.16611.luke@dashjr.org> Date: Fri, 7 Jun 2013 00:10:11 +0200 Message-ID: From: Melvin Carvalho To: Luke-Jr Content-Type: multipart/alternative; boundary=001a11c32ed8fa75f404de8393d0 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (melvincarvalho[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UkiNu-0002FQ-CH Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 22:10:20 -0000 --001a11c32ed8fa75f404de8393d0 Content-Type: text/plain; charset=ISO-8859-1 On 6 June 2013 23:48, Luke-Jr 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 > --001a11c32ed8fa75f404de8393d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 6 June 2013 23:48, Luke-Jr <luke@dashjr.org> wrote:=
On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopo= ulos wrote:
> > This doesn't work like you might think: first of all, the fee= s today are
> > greatly subsidized - the actual cost to store data in the blockch= ain 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 stori= ng 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 onl= y
> 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 argua= ble
- but there isn't any I'm aware of.

=
Two quotes satoshi:

"Piling every proof-of-work quorum sys= tem in the world into one dataset doesn't scale."

and

"I like Hal Finney's idea for user-frie= ndly timestamping.=A0 Convert the hash of a file to a bitcoin address and s= end 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 b= alance reached for casual time stamp recording as part of satoshi's con= cept.

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 incr= edibly
> innovative and promising uses of the distributed timestamping database= .
> That is definitely throwing the baby out with the bathwater. If the is= sue
> is size, then address that, rather than the content itself.

The issue is using other peoples' resources for something they di= d 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" an= d "prevent spamming".

> Discriminating based on transaction content violates neutrality of the=
> protocol and in my mind removes a very very large possibility of futur= e
> innovation. If bitcoin is a *platform* and not just a payment sy= stem, then
> it needs to be neutral to content, like TCP/IP so th= at 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 blockcha= in once.
> > And the network as a whole suffers if nodes decide to start not-s= toring
> > 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 ONL= Y
> 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-pa= yment
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 b= y
> "coinbase", I assume not the company.

The Bitcoin blockchain protocol has 95 bytes per block reserved for m= iners 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<= br> 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 sto= res
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 p= roof-
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 a= ll.

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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a11c32ed8fa75f404de8393d0--