Is it time to give Bitcoin a Use Value?

BreathOfZen

full member

Activity: 140

Merit: 100

Quote from: bakedrice on January 09, 2015, 09:31:30 AM

Quote from: BreathOfZen on January 07, 2015, 11:37:04 AM

The truth however is that Bitcoin has one giant Use Value lurking in the background, but one that the developers don't like - One can use Bitcoin to inject information into the blockchain, and that information will last for all of time (or at least so long as the blockchain exists). In a word, it would mean you can use Bitcoin to save your files to the blockchain, in an uncensorable and inerasable form.

Blockchain as file storage - it will cause Bitcoin to go back up in value, and it will give us a solid reason to give for why Bitcoin has value in the first place.

Is it time?

Wouldn't this cause the problem of bloat in the blockchain? As it already is, takes forever to download the entire 6 years worth of blockchain.

Success and growing adoption are the single largest factors that cause the "bloat" of the blockchain. How long will it take you to download the blockchain if Bitcoin actually catches on and 1% of online sales are made through it?

bakedrice

sr. member

Activity: 338

Merit: 250

Quote from: BreathOfZen on January 07, 2015, 11:37:04 AM

The truth however is that Bitcoin has one giant Use Value lurking in the background, but one that the developers don't like - One can use Bitcoin to inject information into the blockchain, and that information will last for all of time (or at least so long as the blockchain exists). In a word, it would mean you can use Bitcoin to save your files to the blockchain, in an uncensorable and inerasable form.

Blockchain as file storage - it will cause Bitcoin to go back up in value, and it will give us a solid reason to give for why Bitcoin has value in the first place.

Is it time?

Wouldn't this cause the problem of bloat in the blockchain? As it already is, takes forever to download the entire 6 years worth of blockchain.

username18333

sr. member

Activity: 378

Merit: 250

Knowledge could but approximate existence.

Quote from: DeathAndTaxes on January 09, 2015, 12:24:34 AM

That wouldn't prevent the encoding of non-txn data in blockchain. Those who want to would simply place the encoded data instead of a valid script hash. One can't verify a hash is a hash of a valid script with only the hash becauses hashes are indistinguishable from random data. The script hash can't be verified at the time the output is created. It is only verified at the time the input is spent. This would actually be a step backwards because there would be no valid script to redeem the output but unlike OP_RETURN the network wouldn't know the output is unspendable (it just would never be spent). This means it would bloat not only the blockchain but the UTXO set as well.

Also while I like the "script hash only" concept (although not for the incorrect reasons you give) it doesn't make blocks any smaller. The script will not be in the output however it will not mean the script is in the input so outputs become smaller but inputs become larger.

1. I will concede your foremost assertion.

2. Actually, since Writcoin™ doesn’t require its transactions to have inputs (each client is, essentially, a branch of the GE’s central bank), its “script hash only” design could ensure its blocks remain comparatively small.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

That wouldn't prevent the encoding of non-txn data in blockchain. Those who want to would simply place the encoded data in place of a valid script hash in the output. One can't verify the 256 bits provides represents a hash of a valid script and not some other arbitrary data. The script hash isn't verified until the output is spent by hashing the input script hashing it and comparing it to the recorded output ScriptHash. Compared to the existing network this would actually be a step backwards because unlike OP_RETURN the network wouldn't know the output is unspendable (it just would never be spent). This means it would bloat not only the blockchain but the UTXO set as well.

Also while I like the "script hash only" concept (although not for the incorrect reasons you give) it doesn't make blocks any smaller. The script will not be in the output however it will not mean the script is in the input so outputs become smaller but inputs become larger.

username18333

sr. member

Activity: 378

Merit: 250

Knowledge could but approximate existence.

Quote from: BreathOfZen on January 09, 2015, 12:05:50 AM

Quote from: username18333 on January 08, 2015, 11:58:38 PM

Quote from: BreathOfZen on January 08, 2015, 11:56:57 PM

So long as one can look at the inputs and outputs of every single transaction going back to the very first transaction, which one can currenly do in Bitcoin, then the data will be available.

All that would be available are message digests. That's what you're not understanding.

I am very much doubting your claim to the implementation of transaction destruction, as that is not how Bitcoin currently works, is mentioned by no one other then yourself, and it would make a mockery of the Proof of Work model.

Here's how it works:
[sender]
1. Get hash of recipients "regular" script.
2. Create transaction addressed to hash of recipients regular script.
3. Broadcast the transaction.

[recipient]
4. Receive the transaction.
5. Sign my regular script whose message digest (hash) I gave out.
6. Create transaction with that signature.
7. Broadcast transaction.

It works because someone can still check the signed script for whether or not it actually corresponds to the given message digest or not. As well, since the full script would have been in the signature anyway?, it actually reduces the size of a given block since transaction outputs would always contain scripts of a certain, relatively small size.

BreathOfZen

full member

Activity: 140

Merit: 100

Quote from: username18333 on January 08, 2015, 11:58:38 PM

Quote from: BreathOfZen on January 08, 2015, 11:56:57 PM

So long as one can look at the inputs and outputs of every single transaction going back to the very first transaction, which one can currenly do in Bitcoin, then the data will be available.

All that would be available are message digests. That's what you're not understanding.

I am very much doubting your claim to the implementation of transaction destruction, as that is not how Bitcoin currently works, is mentioned by no one other then yourself, and it would make a mockery of the Proof of Work model.

username18333

sr. member

Activity: 378

Merit: 250

Knowledge could but approximate existence.

Quote from: BreathOfZen on January 08, 2015, 11:56:57 PM

So long as one can look at the inputs and outputs of every single transaction going back to the very first transaction, which one can currenly do in Bitcoin, then the data will be available.

Those base58 message digest of "public keys" will have been replaced with base58 message digests of cryptographically secure message digests. That's what you're not understanding: all the output scripts would contain would be cryptographically secure message digests and their required data, and inputs would still be required to be able to sign the outputs they spend.

BreathOfZen

full member

Activity: 140

Merit: 100

So long as one can look at the inputs and outputs of every single transaction going back to the very first transaction, which one can currenly do in Bitcoin, then the data will be available.

username18333

sr. member

Activity: 378

Merit: 250

Knowledge could but approximate existence.

Quote from: BreathOfZen on January 08, 2015, 11:44:21 PM

Quote from: username18333 on January 08, 2015, 11:39:57 PM

1. A message digest produced by a cryptographically secure hash function cannot be run through the algorithm in such a way as it reproduces the data that was used to generate it. Therefore, the data hashed by one or more of these functions for the sake of fulfilling an X-coin network's requirement for transactions' addressing their outputs to, ultimately, message digests will not be useful for storing information but, merely, the message digests derived therefrom by practically "irreversible" means.

2. a) Bitcoin Core for Writcoin™ is a Bitcoin Core derivative specificaly designed to transact digital GE coins over Writcoin™, a network.
2. b) Great Empire of Earth is an empire whose imperium is an Earth-centered celestial sphere of a radius of about eight hundred seventy thousand kilometers.

I see, I apologize for encouraging your trolling.

How, then, do you intend to recover data from its cryptographically secure message digest?

BreathOfZen

full member

Activity: 140

Merit: 100

Quote from: username18333 on January 08, 2015, 11:39:57 PM

1. A message digest produced by a cryptographically secure hash function cannot be run through the algorithm in such a way as it reproduces the data that used to generate it. Therefore, the data hashed by one or more of these functions for the sake of fulfilling an X-coin network's requirement for transactions' addressing their outputs to, ultimately, message digests will not be useful for storing information but, merely, the message digests derived therefrom by practically "irreversible" means.

2. Bitcoin Core for Writcoin™ is a Bitcoin Core derivative specificaly designed to transact digital GE coins over Writcoin™, a network.

I see, I apologize for encouraging your trolling.

username18333

sr. member

Activity: 378

Merit: 250

Knowledge could but approximate existence.

1. A message digest produced by a cryptographically secure hash function cannot be run through the algorithm in such a way as it reproduces the data that was used to generate it. Therefore, the data hashed by one or more of these functions for the sake of fulfilling an X-coin network's requirement for transactions' addressing their outputs to, ultimately, message digests will not be useful for storing information but, merely, the message digests derived therefrom by practically "irreversible" means.

2. a) Bitcoin Core for Writcoin™ is a Bitcoin Core derivative specificaly designed to transact digital GE coins over Writcoin™, a network.
2. b) Great Empire of Earth is an empire whose imperium is an Earth-centered celestial sphere of a radius of about eight hundred seventy thousand kilometers.

BreathOfZen

full member

Activity: 140

Merit: 100

1. You need to explain to me why I care about the scripts - are you saying that transactions can been erased, that the network will start rejecting ones it doesn't like, or what?

2. I feel like I know less then before, but I'm pretty sure that "Great Empire of Earth" is not something that should show up in technical documentation for Bitcoin, or any other ostensibly serious endeavor.

username18333

sr. member

Activity: 378

Merit: 250

Knowledge could but approximate existence.

Quote from: BreathOfZen on January 08, 2015, 11:04:59 PM

Quote from: username18333 on January 08, 2015, 09:24:49 PM

. . .

It means what it sounds like: coins are addressed to hashes (double SHA-256 hashes?) of X-coin scripts instead of X-coin addresses.

A miner could also regulate the number of outputs he or she permits a transaction to have.

The latter point is of course true, and I fully expect that data transactions will pay their fair portion in miners fees to be seen as worthwhile from a miner's perspective. It is after all only fair.

As to the former point though, I still don't really know what you are saying. Also, I really do want to know what a Great Empire Coin is.

1. An X-coin transaction that is addressed to an X-coin address contains an X-coin "script" which includes the actual address and some related commands. An X-coin transaction that is addressed to an X-coin "script hash" contains an X-coin "script" which includes the message digest of the aforementioned kind of script and some related commands.

2. Great Empire Coin (GEC) is the official currency of Great Empire of Earth in much the same way the United States dollar (USD) is the official currency of the United States of America.

BreathOfZen

full member

Activity: 140

Merit: 100

Quote from: username18333 on January 08, 2015, 09:24:49 PM

Quote from: BreathOfZen on January 08, 2015, 09:14:51 PM

Quote from: username18333 on January 08, 2015, 08:56:28 PM

. . .

"[E]xclusive use of . . . pay-to-script-hash [P2SH] within all . . . transaction outputs" should do it.

Not being a core Bitcoin developer, I don't know what that actually means. Questions that arise from it though:
1. What is a Great Empire Coin, Writcoin, and what do they have to do with Bitcoin?
2. Is the gist of your contention that the core Dev team wants to in some way take control of what we can and cannot spend our Bitcoins on, and vigilantly control our Bitcoin spending based on some "father knows best" algorithm?

It means what it sounds like: coins are addressed to hashes (double SHA-256 hashes?) of X-coin scripts instead of X-coin addresses.

A miner could also regulate the number of outputs he or she permits a transaction to have.

The latter point is of course true, and I fully expect that data transactions will pay their fair portion in miners fees to be seen as worthwhile from a miner's perspective. It is after all only fair.

As to the former point though, I still don't really know what you are saying. Also, I really do want to know what a Great Empire Coin is.

username18333

sr. member

Activity: 378

Merit: 250

Knowledge could but approximate existence.

Quote from: BreathOfZen on January 08, 2015, 09:14:51 PM

Quote from: username18333 on January 08, 2015, 08:56:28 PM

. . .

"[E]xclusive use of . . . pay-to-script-hash [P2SH] within all . . . transaction outputs" should do it.

Not being a core Bitcoin developer, I don't know what that actually means. Questions that arise from it though:
1. What is a Great Empire Coin, Writcoin, and what do they have to do with Bitcoin?
2. Is the gist of your contention that the core Dev team wants to in some way take control of what we can and cannot spend our Bitcoins on, and vigilantly control our Bitcoin spending based on some "father knows best" algorithm?

It means what it sounds like: coins are addressed to hashes (double SHA-256 hashes?) of X-coin scripts instead of X-coin addresses.

A miner could also regulate the number of outputs he or she permits a transaction to have.

BreathOfZen

full member

Activity: 140

Merit: 100

Quote from: username18333 on January 08, 2015, 08:56:28 PM

Quote from: BreathOfZen on January 08, 2015, 08:53:58 PM

Quote from: username18333 on January 08, 2015, 08:44:21 PM

Quote from: BreathOfZen on January 08, 2015, 08:35:52 PM

Quote from: username18333 on January 08, 2015, 08:30:42 PM

. . .

A miner of bitcoins, or any derivative thereof that has not been made to do otherwise, can willfully exclude the "null data" type of transaction from the blocks he or she mines and still have the blocks accepted.

I personally don't use null codes when encoding data into the blockchain. They may be the right way to go eventually with enough development support, but as you bring up for now it is actually best if one doesn't depend on any unusual transaction behaviors like null codes to encode data.

Code:

OP_RETURN OP_[bytes of data] [data]

It doesn't matter how you do it, if it's unique enough, it can be filtered out.

Note that the transaction below contains the entire Bill of Rights encoded into the blockchain using only the normal methods of transaction formation. How would you filter it out?

http://bit-comm.appspot.com/packet/d71e39e493a1eaa4eb7c39e5a34ceb002649315321b3cc6e9ea25fcc765de1c3?expanded=true

Quote from: username18333 on September 09, 2014, 04:37:04 PM

. . .

This software features Bitcoin hard-fork requests such as the exclusive use of both pay-to-script-hash within all (non-data) transaction outputs and the exclusive use of fixed-width, 64-bit unsigned integers in storing block times. Writcoin™, the protocol wherefor this software is a client, utilizes a Proof-of-Work based on transaction tree Merkle roots and short (here, ten second) block times called Proof-of-Wait™, requires coinbase transactions to not have any inputs and to only have one, unspendable output, permits coinbase transactions to originate outside blocks, and permits deficit spending (that is to say, it permits transactions’ total output value to exceed its total input value). Great Empire Coin™ (GEC™) is the state money that is exchanged through Writcoin. G.E. coins are the state money of Great Empire of Earth, are divisible into cents and mills, and have denominations of mega-, terra-, and exacoins.

. . .

(Red colorization added.)

"[E]xclusive use of . . . pay-to-script-hash [P2SH] within all . . . transaction outputs" should do it.

Not being a core Bitcoin developer, I don't know what that actually means. Questions that arise from it though:
1. What is a Great Empire Coin, Writcoin, and what do they have to do with Bitcoin?
2. Is the gist of your contention that the core Dev team wants to in some way take control of what we can and cannot spend our Bitcoins on, and vigilantly control our Bitcoin spending based on some "father knows best" algorithm?

username18333

sr. member

Activity: 378

Merit: 250

Knowledge could but approximate existence.

Quote from: BreathOfZen on January 08, 2015, 08:53:58 PM

Quote from: username18333 on January 08, 2015, 08:44:21 PM

Quote from: BreathOfZen on January 08, 2015, 08:35:52 PM

Quote from: username18333 on January 08, 2015, 08:30:42 PM

. . .

A miner of bitcoins, or any derivative thereof that has not been made to do otherwise, can willfully exclude the "null data" type of transaction from the blocks he or she mines and still have the blocks accepted.

I personally don't use null codes when encoding data into the blockchain. They may be the right way to go eventually with enough development support, but as you bring up for now it is actually best if one doesn't depend on any unusual transaction behaviors like null codes to encode data.

Code:

OP_RETURN OP_[bytes of data] [data]

It doesn't matter how you do it, if it's unique enough, it can be filtered out.

Note that the transaction below contains the entire Bill of Rights encoded into the blockchain using only the normal methods of transaction formation. How would you filter it out?

http://bit-comm.appspot.com/packet/d71e39e493a1eaa4eb7c39e5a34ceb002649315321b3cc6e9ea25fcc765de1c3?expanded=true

Quote from: username18333 on September 09, 2014, 04:37:04 PM

. . .

This software features Bitcoin hard-fork requests such as the exclusive use of both pay-to-script-hash within all (non-data) transaction outputs and the exclusive use of fixed-width, 64-bit unsigned integers in storing block times. Writcoin™, the protocol wherefor this software is a client, utilizes a Proof-of-Work based on transaction tree Merkle roots and short (here, ten second) block times called Proof-of-Wait™, requires coinbase transactions to not have any inputs and to only have one, unspendable output, permits coinbase transactions to originate outside blocks, and permits deficit spending (that is to say, it permits transactions’ total output value to exceed its total input value). Great Empire Coin™ (GEC™) is the state money that is exchanged through Writcoin. G.E. coins are the state money of Great Empire of Earth, are divisible into cents and mills, and have denominations of mega-, terra-, and exacoins.

. . .

(Red colorization added.)

"[E]xclusive use of . . . pay-to-script-hash [P2SH] within all . . . transaction outputs" should do it.

BreathOfZen

full member

Activity: 140

Merit: 100

Quote from: username18333 on January 08, 2015, 08:44:21 PM

Quote from: BreathOfZen on January 08, 2015, 08:35:52 PM

Quote from: username18333 on January 08, 2015, 08:30:42 PM

Quote from: BreathOfZen on January 08, 2015, 07:42:21 PM

Quote from: DeathAndTaxes on January 08, 2015, 07:08:26 PM

Blockchain as file storage is a fundamentally bad concept because it is incredibly expensive and the ledger provides a poor compromise between redundancy and cost. When you store or backup some data how many copies do you need. The correct answer is one. The only reason we use redundancy in some form is because failure is a possibility. 0 surviving copies is worthless and 1 copy is maximum value. Since we can't know how, when, or why a copy will be destroyed the cheapest form of insurance is to maintain more copies. The problem is that each additional copy provides a smaller incremental gain however the cost of that additional copy increasingly linearly. The blockchain isn't partially redundant it is perfectly redundant for security reasons. If there are 100,000 nodes you don't gain incrementally much more by having 100,000 copies of your data than you do by having say 100 copies but the true cost is 1000x more. That is a bad tradeoff for bulk storage.

The advantage is that due to the incentive structure, if you want to mine Bitcoins you will have to store all data in the blockchain. This means that while any other web service or data storage company may go belly up and shut down servers when they stop getting an inflow of customers, for Bitcoin as long as mining is profitable your data will always be stored on a large number of nodes which have good economic self interest in preserving it. It is really the only service that can offer that sort of economic guarantee.

The number of nodes (100, 100,000, etc) isn't what matters, but rather that Bitcoin nodes are actually getting paid to store data.

A miner of bitcoins, or any derivative thereof that has not been made to do otherwise, can willfully exclude the "null data" type of transaction from the blocks he or she mines and still have the blocks accepted.

I personally don't use null codes when encoding data into the blockchain. They may be the right way to go eventually with enough development support, but as you bring up for now it is actually best if one doesn't depend on any unusual transaction behaviors like null codes to encode data.

Code:

OP_RETURN OP_[bytes of data] [data]

It doesn't matter how you do it, if it's unique enough, it can be filtered out.

Note that the transaction below contains the entire Bill of Rights encoded into the blockchain using only the normal methods of transaction formation. How would you filter it out?

http://bit-comm.appspot.com/packet/d71e39e493a1eaa4eb7c39e5a34ceb002649315321b3cc6e9ea25fcc765de1c3?expanded=true

username18333

sr. member

Activity: 378

Merit: 250

Knowledge could but approximate existence.

Quote from: BreathOfZen on January 08, 2015, 08:35:52 PM

Quote from: username18333 on January 08, 2015, 08:30:42 PM

Quote from: BreathOfZen on January 08, 2015, 07:42:21 PM

Quote from: DeathAndTaxes on January 08, 2015, 07:08:26 PM

Blockchain as file storage is a fundamentally bad concept because it is incredibly expensive and the ledger provides a poor compromise between redundancy and cost. When you store or backup some data how many copies do you need. The correct answer is one. The only reason we use redundancy in some form is because failure is a possibility. 0 surviving copies is worthless and 1 copy is maximum value. Since we can't know how, when, or why a copy will be destroyed the cheapest form of insurance is to maintain more copies. The problem is that each additional copy provides a smaller incremental gain however the cost of that additional copy increasingly linearly. The blockchain isn't partially redundant it is perfectly redundant for security reasons. If there are 100,000 nodes you don't gain incrementally much more by having 100,000 copies of your data than you do by having say 100 copies but the true cost is 1000x more. That is a bad tradeoff for bulk storage.

The advantage is that due to the incentive structure, if you want to mine Bitcoins you will have to store all data in the blockchain. This means that while any other web service or data storage company may go belly up and shut down servers when they stop getting an inflow of customers, for Bitcoin as long as mining is profitable your data will always be stored on a large number of nodes which have good economic self interest in preserving it. It is really the only service that can offer that sort of economic guarantee.

The number of nodes (100, 100,000, etc) isn't what matters, but rather that Bitcoin nodes are actually getting paid to store data.

A miner of bitcoins, or any derivative thereof that has not been made to do otherwise, can willfully exclude the "null data" type of transaction from the blocks he or she mines and still have the blocks accepted.

I personally don't use null codes when encoding data into the blockchain. They may be the right way to go eventually with enough development support, but as you bring up for now it is actually best if one doesn't depend on any unusual transaction behaviors like null codes to encode data.

Code:

OP_RETURN OP_[bytes of data] [data]

It doesn't matter how you do it, if it's unique enough, it can be filtered out.

BreathOfZen

full member

Activity: 140

Merit: 100

Quote from: username18333 on January 08, 2015, 08:30:42 PM

Quote from: BreathOfZen on January 08, 2015, 07:42:21 PM

Quote from: DeathAndTaxes on January 08, 2015, 07:08:26 PM

Blockchain as file storage is a fundamentally bad concept because it is incredibly expensive and the ledger provides a poor compromise between redundancy and cost. When you store or backup some data how many copies do you need. The correct answer is one. The only reason we use redundancy in some form is because failure is a possibility. 0 surviving copies is worthless and 1 copy is maximum value. Since we can't know how, when, or why a copy will be destroyed the cheapest form of insurance is to maintain more copies. The problem is that each additional copy provides a smaller incremental gain however the cost of that additional copy increasingly linearly. The blockchain isn't partially redundant it is perfectly redundant for security reasons. If there are 100,000 nodes you don't gain incrementally much more by having 100,000 copies of your data than you do by having say 100 copies but the true cost is 1000x more. That is a bad tradeoff for bulk storage.

The advantage is that due to the incentive structure, if you want to mine Bitcoins you will have to store all data in the blockchain. This means that while any other web service or data storage company may go belly up and shut down servers when they stop getting an inflow of customers, for Bitcoin as long as mining is profitable your data will always be stored on a large number of nodes which have good economic self interest in preserving it. It is really the only service that can offer that sort of economic guarantee.

The number of nodes (100, 100,000, etc) isn't what matters, but rather that Bitcoin nodes are actually getting paid to store data.

A miner of bitcoins, or any derivative thereof that has been made to do otherwise, can willfully exclude the "null data" type of transaction from the blocks he or she mines and still have the blocks accepted.

I personally don't use null codes when encoding data into the blockchain. They may be the right way to go eventually with enough development support, but as you bring up for now it is actually best if one doesn't depend on any unusual transaction behaviors like null codes to encode data.

Topic: Is it time to give Bitcoin a Use Value? (Read 1927 times)