<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 6 June 2013 23:48, Luke-Jr <span dir="ltr"><<a href="mailto:luke@dashjr.org" target="_blank">luke@dashjr.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopoulos wrote:<br>
> > This doesn't work like you might think: first of all, the fees today are<br>
> > greatly subsidized - the actual cost to store data in the blockchain is<br>
> > much higher than most storage solutions. Secondly, only the miner receives<br>
> > the fees, not the majority of nodes which have to bear the burden of the<br>
> > data. That is, the fee system is setup as an antispam/deterrant, not as<br>
> > payment for<br>
> > storage.<br>
><br>
> There's a difference between storing the content itself, and storing just a<br>
> hash to content (which however is not spendable payment). I undertand why<br>
> content itself doesn't belong. But it goes too far to say that only<br>
> 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 arguable<br>
- but there isn't any I'm aware of.<br></blockquote><div><br></div><div>Two quotes satoshi:<br><br>"Piling every proof-of-work quorum system in the world into one dataset doesn't scale."<br><br></div>
<div>and<br></div><div><br>"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"<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 balance reached for casual time stamp recording as part of satoshi's concept.<br>
<br></div><div>What we call "spam" 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="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> If the fees are not enough, fix the fee structure, don't stop incredibly<br>
> innovative and promising uses of the distributed timestamping database.<br>
> That is definitely throwing the baby out with the bathwater. If the issue<br>
> is size, then address that, rather than the content itself.<br>
<br>
</div>The issue is using other peoples' resources for something they did not agree<br>
to use it for. The fees aren't merely "not enough", they were never *intended*<br>
to be "cost of storage". They are "cost of security" and "prevent spamming".<br>
<div class="im"><br>
> Discriminating based on transaction content violates neutrality of the<br>
> protocol and in my mind removes a very very large possibility of future<br>
</div>> innovation. If bitcoin is a *platform* and not just a payment system, then<br>
<div class="im">> it needs to be neutral to content, like TCP/IP so that other protocols can<br>
> be layered. Solve the size problem itself, without picking and chosing<br>
> which uses of bitcoin are good and which are "bad" or "spam". I think it<br>
> 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="im"><br>
> > Not the same thing at all; nobody is forced to store/relay<br>
> > video/voice/images without reimbursement. On the other hand, any full<br>
> > Bitcoin node is required to at least download the entire blockchain once.<br>
> > And the network as a whole suffers if nodes decide to start not-storing<br>
> > parts of the blockchain they don't want to deal with.<br>
> ><br>
> > So don't store content, but allow hashes of content.<br>
><br>
> Again, I think it is extreme and extremely restrictive to say that ONLY<br>
> payments are allowed.<br>
<br>
</div>Non-payments are quite possible without the Bitcoin blockchain itself. If<br>
you're worried that not enough people will store the alternative-non-payment<br>
data, then you are essentially saying that voluntary participation is not<br>
enough and that forced storage is your solution. I don't think this is what<br>
you intend...<br>
<div class="im"><br>
> > This is how merged mining solves the problem. A single extra hash in the<br>
> > coinbase can link the bitcoin blockchain up with unlimited other data.<br>
><br>
> Can you explain this part or refer me to some docs? What do you mean by<br>
> "coinbase", I assume not the company.<br>
<br>
</div>The Bitcoin blockchain protocol has 95 bytes per block reserved for miners to<br>
put extra data. Currently, this is used for extranonces, political or other<br>
short messages (such as in the Genesis block), miner "signatures", 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 stores<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's proof-<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 all.<br>
<span class=""><font color="#888888"><br>
Luke<br>
</font></span><div class=""><div class="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="http://p.sf.net/sfu/servicenow-d2d-j" target="_blank">http://p.sf.net/sfu/servicenow-d2d-j</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</div></div></blockquote></div><br></div></div>