path: root/54/dfcb2a43ac0ec57b390c5518d81846ed3987af

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 <melvincarvalho@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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>
	<CAFmyj8zDCjGR6cLUXQnWP4G0k6A85vdNW03k5NPAVyoJj0eEnQ@mail.gmail.com>
	<201306062148.16611.luke@dashjr.org>
Date: Fri, 7 Jun 2013 00:10:11 +0200
Message-ID: <CAKaEYhKVmhrvYLVR7s-WkT+kC-DWm=faXj6fJ0rp1yhytoQ15Q@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Luke-Jr <luke@dashjr.org>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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
>

--001a11c32ed8fa75f404de8393d0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 6 June 2013 23:48, Luke-Jr <span dir=3D"ltr">&lt;<a href=3D"mail=
to:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=3D"im">On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopo=
ulos wrote:<br>
&gt; &gt; This doesn&#39;t work like you might think: first of all, the fee=
s today are<br>
&gt; &gt; greatly subsidized - the actual cost to store data in the blockch=
ain is<br>
&gt; &gt; much higher than most storage solutions. Secondly, only the miner=
 receives<br>
&gt; &gt; the fees, not the majority of nodes which have to bear the burden=
 of the<br>
&gt; &gt; data. That is, the fee system is setup as an antispam/deterrant, =
not as<br>
&gt; &gt; payment for<br>
&gt; &gt; storage.<br>
&gt;<br>
&gt; There&#39;s a difference between storing the content itself, and stori=
ng just a<br>
&gt; hash to content (which however is not spendable payment). I undertand =
why<br>
&gt; content itself doesn&#39;t belong. But it goes too far to say that onl=
y<br>
&gt; payments should be allowed.<br>
<br>
</div>Because payments are the only thing everyone using Bitcoin has agreed=
 to use<br>
the blockchain for. Furthermore, there is no *reason* to store non-payments=
 in<br>
the blockchain. If there was in fact such a use case, things might be argua=
ble<br>
- but there isn&#39;t any I&#39;m aware of.<br></blockquote><div><br></div>=
<div>Two quotes satoshi:<br><br>&quot;Piling every proof-of-work quorum sys=
tem in the world into one dataset doesn&#39;t scale.&quot;<br><br></div>
<div>and<br></div><div><br>&quot;I like Hal Finney&#39;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&quot;<br><br></div><div>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&#39;s con=
cept.<br>
<br></div><div>What we call &quot;spam&quot; is to a degree subjective, and=
 I think not always obvious, tho in some cases it clearly is.<br></div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class=3D"im"><br>
&gt; If the fees are not enough, fix the fee structure, don&#39;t stop incr=
edibly<br>
&gt; innovative and promising uses of the distributed timestamping database=
.<br>
&gt; That is definitely throwing the baby out with the bathwater. If the is=
sue<br>
&gt; is size, then address that, rather than the content itself.<br>
<br>
</div>The issue is using other peoples&#39; resources for something they di=
d not agree<br>
to use it for. The fees aren&#39;t merely &quot;not enough&quot;, they were=
 never *intended*<br>
to be &quot;cost of storage&quot;. They are &quot;cost of security&quot; an=
d &quot;prevent spamming&quot;.<br>
<div class=3D"im"><br>
&gt; Discriminating based on transaction content violates neutrality of the=
<br>
&gt; protocol and in my mind removes a very very large possibility of futur=
e<br>
</div>&gt; innovation. If bitcoin is a *platform* and not just a payment sy=
stem, then<br>
<div class=3D"im">&gt; it needs to be neutral to content, like TCP/IP so th=
at other protocols can<br>
&gt; be layered. Solve the size problem itself, without picking and chosing=
<br>
&gt; which uses of bitcoin are good and which are &quot;bad&quot; or &quot;=
spam&quot;. I think it<br>
&gt; risks killing a tremendous amount of innovation just as it is starting=
.<br>
<br>
</div>The concepts behind Bitcoin are applicable to future innovation, but =
this can<br>
all be accomplished without spamming Bitcoin itself.<br>
<div class=3D"im"><br>
&gt; &gt; Not the same thing at all; nobody is forced to store/relay<br>
&gt; &gt; video/voice/images without reimbursement. On the other hand, any =
full<br>
&gt; &gt; Bitcoin node is required to at least download the entire blockcha=
in once.<br>
&gt; &gt; And the network as a whole suffers if nodes decide to start not-s=
toring<br>
&gt; &gt; parts of the blockchain they don&#39;t want to deal with.<br>
&gt; &gt;<br>
&gt; &gt; So don&#39;t store content, but allow hashes of content.<br>
&gt;<br>
&gt; Again, I think it is extreme and extremely restrictive to say that ONL=
Y<br>
&gt; payments are allowed.<br>
<br>
</div>Non-payments are quite possible without the Bitcoin blockchain itself=
. If<br>
you&#39;re worried that not enough people will store the alternative-non-pa=
yment<br>
data, then you are essentially saying that voluntary participation is not<b=
r>
enough and that forced storage is your solution. I don&#39;t think this is =
what<br>
you intend...<br>
<div class=3D"im"><br>
&gt; &gt; This is how merged mining solves the problem. A single extra hash=
 in the<br>
&gt; &gt; coinbase can link the bitcoin blockchain up with unlimited other =
data.<br>
&gt;<br>
&gt; Can you explain this part or refer me to some docs? What do you mean b=
y<br>
&gt; &quot;coinbase&quot;, I assume not the company.<br>
<br>
</div>The Bitcoin blockchain protocol has 95 bytes per block reserved for m=
iners to<br>
put extra data. Currently, this is used for extranonces, political or other=
<br>
short messages (such as in the Genesis block), miner &quot;signatures&quot;=
, and also,<br>
as I mentioned, merged mining. Merged mining works by tying a non-<br>
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=
<br>
prove it is associated to the block. The merged mining merkle tree then sto=
res<br>
hashes of multiple other data sets: for example, a Namecoin block can be<br=
>
referenced in a merged mining merkle tree, to use the Bitcoin block&#39;s p=
roof-<br>
of-work for itself (so, miners can mine both Bitcoin and Namecoin using the=
<br>
same hashing effort). You could also add other non-transactional blocks to =
the<br>
merged mining merkle tree, for generic timestamping or really anything at a=
ll.<br>
<span class=3D""><font color=3D"#888888"><br>
Luke<br>
</font></span><div class=3D""><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
How ServiceNow helps IT people transform IT departments:<br>
1. A cloud service to automate IT design, transition and operations<br>
2. Dashboards that offer high-level views of enterprise services<br>
3. A single system of record for all IT processes<br>
<a href=3D"http://p.sf.net/sfu/servicenow-d2d-j" target=3D"_blank">http://p=
.sf.net/sfu/servicenow-d2d-j</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div></div>

--001a11c32ed8fa75f404de8393d0--