Luke-Jr [ARCHIVE] on Nostr: 📅 Original date posted:2013-06-06 📝 Original message:On Thursday, June 06, 2013 ...
📅 Original date posted:2013-06-06
📝 Original message: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.
> 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
Published at
2023-06-07 15:02:45Event JSON
{
"id": "e9d5948c2f3617fbfd9464450eb156bf041940c92540cbe713abc71a956e2c61",
"pubkey": "6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1",
"created_at": 1686150165,
"kind": 1,
"tags": [
[
"e",
"6bd9512be4afa2a81b307b24d258a963f9abe4599b255899b627408b516854f9",
"",
"root"
],
[
"e",
"7b5c7ecc391c5ea0ec0f70db0ef90637929d5fb6e74024f05e36c5ad52e22b4b",
"",
"reply"
],
[
"p",
"4562b0c58f363ac63193251c989c88c6386ca7e991c5c8e6e4d498e899db7883"
]
],
"content": "📅 Original date posted:2013-06-06\n📝 Original message:On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopoulos wrote:\n\u003e \u003e This doesn't work like you might think: first of all, the fees today are\n\u003e \u003e greatly subsidized - the actual cost to store data in the blockchain is\n\u003e \u003e much higher than most storage solutions. Secondly, only the miner receives\n\u003e \u003e the fees, not the majority of nodes which have to bear the burden of the\n\u003e \u003e data. That is, the fee system is setup as an antispam/deterrant, not as\n\u003e \u003e payment for\n\u003e \u003e storage.\n\u003e \n\u003e There's a difference between storing the content itself, and storing just a\n\u003e hash to content (which however is not spendable payment). I undertand why\n\u003e content itself doesn't belong. But it goes too far to say that only\n\u003e payments should be allowed.\n\nBecause payments are the only thing everyone using Bitcoin has agreed to use \nthe blockchain for. Furthermore, there is no *reason* to store non-payments in \nthe blockchain. If there was in fact such a use case, things might be arguable \n- but there isn't any I'm aware of.\n\n\u003e If the fees are not enough, fix the fee structure, don't stop incredibly\n\u003e innovative and promising uses of the distributed timestamping database.\n\u003e That is definitely throwing the baby out with the bathwater. If the issue\n\u003e is size, then address that, rather than the content itself.\n\nThe issue is using other peoples' resources for something they did not agree \nto use it for. The fees aren't merely \"not enough\", they were never *intended* \nto be \"cost of storage\". They are \"cost of security\" and \"prevent spamming\".\n\n\u003e Discriminating based on transaction content violates neutrality of the\n\u003e protocol and in my mind removes a very very large possibility of future\n\u003e innovation. If bitcoin is a *platform* and not just a payment system, then\n\u003e it needs to be neutral to content, like TCP/IP so that other protocols can\n\u003e be layered. Solve the size problem itself, without picking and chosing\n\u003e which uses of bitcoin are good and which are \"bad\" or \"spam\". I think it\n\u003e risks killing a tremendous amount of innovation just as it is starting.\n\nThe concepts behind Bitcoin are applicable to future innovation, but this can \nall be accomplished without spamming Bitcoin itself.\n\n\u003e \u003e Not the same thing at all; nobody is forced to store/relay\n\u003e \u003e video/voice/images without reimbursement. On the other hand, any full\n\u003e \u003e Bitcoin node is required to at least download the entire blockchain once.\n\u003e \u003e And the network as a whole suffers if nodes decide to start not-storing\n\u003e \u003e parts of the blockchain they don't want to deal with.\n\u003e \u003e \n\u003e \u003e So don't store content, but allow hashes of content.\n\u003e \n\u003e Again, I think it is extreme and extremely restrictive to say that ONLY\n\u003e payments are allowed.\n\nNon-payments are quite possible without the Bitcoin blockchain itself. If \nyou're worried that not enough people will store the alternative-non-payment \ndata, then you are essentially saying that voluntary participation is not \nenough and that forced storage is your solution. I don't think this is what \nyou intend...\n\n\u003e \u003e This is how merged mining solves the problem. A single extra hash in the\n\u003e \u003e coinbase can link the bitcoin blockchain up with unlimited other data.\n\u003e \n\u003e Can you explain this part or refer me to some docs? What do you mean by\n\u003e \"coinbase\", I assume not the company.\n\nThe Bitcoin blockchain protocol has 95 bytes per block reserved for miners to \nput extra data. Currently, this is used for extranonces, political or other \nshort messages (such as in the Genesis block), miner \"signatures\", and also, \nas I mentioned, merged mining. Merged mining works by tying a non-\ntransactional merkle tree to the blockchain. The block coinbase stores the \nhash of the top of this merkle tree, so any data within the merkle tree can \nprove it is associated to the block. The merged mining merkle tree then stores \nhashes of multiple other data sets: for example, a Namecoin block can be \nreferenced in a merged mining merkle tree, to use the Bitcoin block's proof-\nof-work for itself (so, miners can mine both Bitcoin and Namecoin using the \nsame hashing effort). You could also add other non-transactional blocks to the \nmerged mining merkle tree, for generic timestamping or really anything at all.\n\nLuke",
"sig": "ff11e49d1f74307b0d6463fcb4a0a009515a21bf9b5c9cd07ea8f537251226e57e866b366dfac565eddbdbca3b1fbe20445c8480c76e0351624fa73f98cf4fd5"
}