Bitcoin Wiki - User contributions [en]

CompuCoin

2011-11-12T04:38:59Z

Bshanks:

This is a proposal to modify the BitCoin protocol in such a way so as to put a large proportion of the computing power spent in the creation of the block chain to practical use, at the same time creating something similar to "backing" for BTC with computing power.

The proposal has two free parameters, K1 and K2, which would be fixed by the community during implementation.

1) Create a standardized way for computing power bids to be encoding in the block chain, alongside transactions. I suggest posing problems in some simple NP-complete problem representation such as 3-SAT, along with a bid. There also needs to be a standardized way to post solutions.

2) Allow computing power bids, written in the above standardized form, to be encoded alongside transaction in the block chain, with the restriction that the maximum worst-case time complexity that is allowed to be encoded into any block is proportional to the current hash difficulty (with some proportionality constant K1).

3) At all times, all nodes maintain in memory a list of the current largest valid computing power bid which has successfully been encoded in the block chain (call this the "current task").

4) A solution of the current task is taken as a form of proof-of-work and can be used as a discount on the hashing proof-of-work difficulty required to produce the next block in the block chain. So, nodes can choose to devote some of their computing power to searching for a solution to the current task in addition to hashing. However, a fixed proportion, K2, of each node's (worst-case) effort must always be devoted to hashing. That is to say, a block is considered valid as long as both (a) the sum of (worst case effort of solving the current task) + (worst case effort of hashing proof-of-work) exceeds some number, and (b) (worst case effort of hashing proof-of-work) >= ((worst case effort of solving the current task) + (worst case effort of hashing proof-of-work))*K2

I propose that the block chain be forked to implement this.

Notes:
* the motivation for selling computing power in the form of nondeterministic polynomial time problems is:
** to make use of the embarrassing parallelism of the BitCoin miner pool
** to only allow problems for which the space in bytes necessary to encode the answer to the problem is very small even for very difficult problems (since these answers must be encoded into the block chain)
** to make it simple to measure the worst-case time complexity of the problem posed
* 3-SAT is nice because the transformation of nondeterministic automata into a 3-SAT representation is relatively straightforward, conceptually, compared to e.g. TSP.
* the motivation for limiting the max time complexity of computing power bids is to prevent one miner from posing problems of large time complexity to which they already know the answer in order to be able to lock everyone else out from getting discounted blocks.
* the motivation for forcing the highest bid-to-date to be serviced is that, if each miner were able to choose which bid to service, then again each miner could submit their own bids for problems they already know the answer to, and in this way get to generate discounted blocks each time they generated a hash, without any additional effort. If the bid must be large and the time complexity limited, then miners who attempted to do this would periodically have their problems solved by other competing miners and would have to pay them large amounts of BTC.
* the motivation for requiring some amount of each proof-of-work to remain in the form of hashing is to prevent nodes from gaining control of the block chain by posing problems to which they already know the solution.
* this system means that people who want to buy computing power from the miner pool will first have to acquire BTC, driving up the price of BTC
* this is "backing" only in the same sense that U.S. income tax and petrodollars provide backing to the U.S. dollar -- it's not the case that your BTC can be redeemed for a fixed amount of computing power, but rather, it just guarantees there is at least one type of commodity which a lot of people will want to purchase from a set of suppliers who only accept BTC as payment (this assumes that the NP-complete solving power offered by the miner pool through this mechanism will end up being cheaper than other sellers of NP-complete computing power; which seems likely; and also that many people would want to purchase computing power in this form if it were cheaply available, which is debatable but which seems likely to me).
* Miners are incentivized to switch to a chain that implements this because this provides something like backing to BTC, which provides a floor to the price of 1 BTC.
* this proposal should be studied game-theoretically to make sure it that there is not some Nash equilibrium or similar in which the the current tasks almost always consist of problems posed by some node which already knows the solution. I have an intuition that the choice of K1 and K2 may be important.
-- BayleShanks

----

see also https://en.bitcoin.it/wiki/Intrinsic_worth_brainstorming

CompuCoin

2011-11-11T23:44:36Z

Bshanks: proposal to make use of the computing power of the miner pool while providing something like backing to BTC

This is a proposal to modify the BitCoin protocol in such a way so as to put a large proportion of the computing power spent in the creation of the block chain to practical use, at the same time creating something similar to "backing" for BTC with computing power.

The proposal has two free parameters, K1 and K2, which would be fixed by the community during implementation.

1) Create a standardized way for computing power bids to be encoding in the block chain, alongside transactions. I suggest posing problems in some simple NP-complete problem representation such as 3-SAT, along with a bid. There also needs to be a standardized way to post solutions.

2) Allow computing power bids, written in the above standardized form, to be encoded alongside transaction in the block chain, with the restriction that the maximum worst-case time complexity that is allowed to be encoded into any block is proportional to the current hash difficulty (with some proportionality constant K1).

3) At all times, all nodes maintain in memory a list of the current largest valid computing power bid which has successfully been encoded in the block chain (call this the "current task").

4) A solution of the current task is taken as a form of proof-of-work and can be used as a discount on the hashing proof-of-work difficulty required to produce the next block in the block chain. So, nodes can choose to devote some of their computing power to searching for a solution to the current task in addition to hashing. However, a fixed proportion, K2, of each node's (worst-case) effort must always be devoted to hashing. That is to say, a block is considered valid as long as both (a) the sum of (worst case effort of solving the current task) + (worst case effort of hashing proof-of-work) exceeds some number, and (b) (worst case effort of hashing proof-of-work) >= ((worst case effort of solving the current task) + (worst case effort of hashing proof-of-work))*K2

I propose that the block chain be forked to implement this.

Notes:
* the motivation for selling computing power in the form of nondeterministic polynomial time problems is:
** to make use of the embarrassing parallelism of the BitCoin miner pool
** to only allow problems for which the space in bytes necessary to encode the answer to the problem is very small even for very difficult problems (since these answers must be encoded into the block chain)
** to make it simple to measure the worst-case time complexity of the problem posed
* 3-SAT is nice because the transformations of nondeterministic automata into a 3-SAT representation is relatively straightforward, conceptually, compared to e.g. TSP.
* the motivation for limiting the max time complexity of computing power bids is to prevent one miner from posing problems of large time complexity to which they already know the answer in order to be able to lock everyone else out from getting discounted blocks.
* the motivation for forcing the highest bid-to-date to be serviced is that, if each miner were able to choose which bid to service, then again each miner could submit their own bids for problems they already know the answer to, and in this way get to generate discounted blocks each time they generated a hash, without any additional effort. If the bid must be large and the time complexity limited, then miners who attempted to do this would periodically have their problems solved by other competing miners and would have to pay them large amounts of BTC.
* the motivation for requiring some amount of each proof-of-work to remain in the form of hashing is to prevent nodes from gaining control of the block chain by posing problems to which they already know the solution.
* this system means that people who want to buy computing power from the miner pool will first have to acquire BTC, driving up the price of BTC
* this is "backing" only in the same sense that U.S. income tax and petrodollars provide backing to the U.S. dollar -- it's not the case that your BTC can be redeemed for a fixed amount of computing power, but rather, it just guarantees there is at least one type of commodity which a lot of people will want to purchase from a set of suppliers who only accept BTC as payment (this assumes that the NP-complete solving power offered by the miner pool through this mechanism will end up being cheaper than other sellers of NP-complete computing power; which seems likely; and also that many people would want to purchase computing power in this form if it were cheaply available, which is debatable but which seems likely to me).
* Miners are incentivized to switch to a chain that implements this because this provides something like backing to BTC, which provides a floor to the price of 1 BTC.
* this proposal should be studied game-theoretically to make sure it that there is not some Nash equilibrium or similar in which the the current tasks almost always consist of problems posed by some node which already knows the solution. I have an intuition that the choice of K1 and K2 may be important.
-- BayleShanks

----

see also https://en.bitcoin.it/wiki/Intrinsic_worth_brainstorming

Deflationary spiral

2011-10-17T09:33:27Z

Bshanks: /* See Also */

'''Deflationary spiral''' is an economic argument that proposes that runaway deflation can eventually lead to the collapse of the currency given certain conditions and constraints. It is a common criticism made against the viability of [[Bitcoin]].
The ‘deflationary spiral’ is a real condition that affects the fiat fractional reserve backing system. Bitcoin is not affected by this because it is fundamentally different from fiat currency. (See below for a dissenting argument on this topic.)

Deflation is a decline in the general price level. Deflation occurs when the price of goods and services, relative to a specific measure, decline. It is not necessarily that the value of the goods and services themselves declined, but can be because the value of the currency itself increased.

For example, let us consider an economy comprised entirely of beef and oranges where the medium of exchange is gold. Both beef and oranges can decay and are not consistent, and therefore cannot be used as a currency. In order to trade, people exchange gold for either beef or oranges. They see gold as a store of value that they can use to purchase beef or oranges in the future. What happens when the economy grows and we can produce more beef and more oranges? The price of both beef and oranges will decline. To the extent our productive capacity for both beef and oranges increased at the same pace, the exchange value between the two (the amount of beef for a given number of oranges) will likely stay the same; however, those who held gold as a store of value would now be able to purchase more beef and more oranges for a given amount of gold.

A deflationary spiral occurs when the value of a currency, relative to the goods in an economy, increases continually as a result of hoarding. As the value of the currency relative to the goods in the economy increase, people have the incentive to hoard the currency, because by merely holding it, they hope to be able to purchase more goods for less money in the future. A lack of currency available in the market causes the price of goods to further decrease, resulting in more hoarding.

In our economy of beef and oranges it is easy to see how this could occur. First, people see a significant gain in productivity on the horizon; we will be able to produce more beef and oranges for the same effort in the future. The supply of gold, however, is fixed. As a result, people desire to hold gold, because they will be able to purchase more beef and oranges with their gold in the future than they can now. This will lead to a decline in the price of beef and oranges as measured by gold (an increase in the value of gold). Limiting the amount of currency in the market available for exchange can also make transactions more difficult. In a complex system where we do not only have beef, oranges and gold, this can result in a deflationary spiral where no one wishes to spend their currency and the economy itself slows as a result of the limited number of transactions. Limited demand with fixed output results in a decline in prices, which further exacerbates the problem.

Alternative explanation:
A deflationary spiral occurs when the price of a traded article increases at some given rate, which causes people to hoard it. As people hoard the commodity, less and less of it is available thus causing the price to go up even more. In turn, even more people hoard the commodity. Thus a feedback loop or spiral of deflation occurs. 

In practice, there is only a limited amount of 'value' that can be placed upon a good before it becomes too attractive to trade for other goods (thus ending the spiral). The only time that the 'Deflationary Spiral' can happen (to it's conclusion) is when people can foresee a time where they are forced to use that particular traded article. See below for a dissenting argument on this topic.

==In The Fiat Fractional Reserve Banking System==
The fiat money that we trade consists of the principal of the loans of other people. All this money must be someday 'repaid.' When people save (pay back their loans), the total monetary supply contracts. When people spend (take out loans), the total monetary supply is increasing.

If you have people who are hoarding money, the principal still needs to be repaid. Hoarding will make it harder for other people in the economy to pay back their loans.

Because people foresee a time where they need to pay back their loans (a future fixed expense), when the value of the money starts to increase (deflation), those with loans will endeavour to pay back the loans quicker. This causes the monetary supply to reduce, reducing the total amount of money available for repayment of loans, again making it harder for people to pay back what they owe.

This Deflationary spiral diverts funds away from the legitimate economy, to the repayment of debt. Causing the economy to stagnate and stop.

==Bitcoin==
The key difference is that people don't foresee a fixed cost (unit amount) that they must pay with Bitcoin. If the value of the Bitcoins that they own increases, then any future cost will take a proportionally smaller amount of Bitcoins. There isn't any fixed incentive to holding Bitcoin other than speculation.

If the economy that uses Bitcoin grows, the per-unit value of Bitcoin proportionally increases also.

Everything is the opposite to the fiat fractional reserve banking system (because Bitcoin isn't a debt but an asset). Bitcoins '''only''' deflate in value when the Bitcoin Economy is '''growing'''.

Because the Deflationary spiral is a real problem in the traditional monetary system, doesn't necessarily mean that it will also be a problem in the Bitcoin economy.

<blockquote>
"Elaborate controls to make sure that currency is not produced in greater numbers is not something any other currency, like the dollar or the euro, has," says Russ Roberts, professor of economics at George Mason University. The consequence will likely be slow and steady deflation, as the growth in circulating bitcoins declines and their value rises.

"That is considered very destructive in today's economies, mostly because when it occurs, it is unexpected," says Roberts. But he thinks that won't apply in an economy where deflation is expected. "In a Bitcoin world, everyone would anticipate that, and they know what they got paid would buy more then than it would now."
</blockquote>
--MIT Technology Review: [http://www.technologyreview.com/computing/37619/page2/ What Bitcoin Is, and Why It Matters], May 25, 2011

==Alternative Viewpoint==
A deflationary spiral occurs when there is an incentive to hoard because of declining prices, which results in even less available currency on the market, further perpetuating declining prices.

How could this occur in the Bitcoin market? First, we see massive deflation occurring in the market right now, as the value of a Bitcoin relative to other currencies, and as a result goods and services as well, increases. To the extent there is value in a Bitcoin because there will be a limited number of them in the future and they are one of the few untraceable mediums of exchange that cannot be subjected to expropriation (at the moment), it is easy to see why their value is currently increasing. Already, however, this is creating the incentive for hoarding. Given there is a known limit on the future amount of Bitcoins in existence, the market expects that the "price" of Bitcoins as measured in other currencies will increase.

While this will not necessarily lead to a deflationary spiral, it will likely cause serious problems for Bitcoin which could ultimately trigger Bitcoin's demise, as outlined below.

1. Currently, with knowledge that there will be a limited number of Bitcoins in the future, the price of Bitcoins is increasing rapidly. The result is limited price stability. Limited price stability has a negative impact on the acceptance of a currency. Vendors do not wish to speculate on the price of currency when selling goods or services.

2. Once prices do stabilize in the future, there will always be the knowledge that the number of Bitcoins in the market is limited. As a result, to the extent the GDP of the Bitcoin economy increases (the total value of all Bitcoin transactions completed increases in "real" terms), there will continue to be price deflation. Price deflation rewards the holders of the existing currency and provides an incentive to hoard the currency. The value held by the existing holders of the currency, and the resulting reward that they receive for future deflation, can be eliminated by a competing system. As a result, to the extent there is an expectation for inflation because demand for the currency itself is greater than the supply of Bitcoins, a competing system will emerge.

Fundamentally, the growth of Bitcoin will be limited because of the knowledge that there is a limited supply of coins. The fact that there is a limited supply of coins means that there is an expectation of deflation if the economy grows. The "cost" of that deflation, borne by new users, can be avoided if an alternative system is used.

While this is not a traditional deflationary spiral, the constraint on the actual money supply can produce the same result, which is a limit on the value of goods and services transacted using Bitcoins.

What can be done to deal with this issue?

An alternative is technically possible through revised software. The supply of Bitcoins could grow in proportion to the total value of transactions undertaken using the system. This would lead to price stability and will eliminate the benefit that accrues to existing holders of the currency. Because those holding Bitcoins would likekly not choose to use the revised software as it devalues their holdings, it is doubtful this alternative would be adopted without causing a fork.

==See Also==

* [[Controlled inflation]]
* [[Bitcoin Days Destroyed]]
* [http://bitcoin.stackexchange.com/questions/408/does-hoarding-really-hurt-bitcoin Does hoarding really hurt bitcoin?] on stackexchange.com

[[Category:Economics]]

Deflationary spiral

2011-10-17T09:31:53Z

Bshanks: See also Intrinsic worth brainstorming

Alternative chain

2011-10-17T09:29:44Z

Bshanks: See also Intrinsic worth brainstorming.

An '''alternative chain''' is a system using the block chain algorithm to achieve distributed consensus on a particular topic. Alternative chains may share miners with a '''parent''' network such as Bitcoin's; this is called '''merged mining'''. Alternative chains have been suggested as ways to implement DNS, SSL certificate authorities, timestamping, file storage and voting systems.

== Objective ==

Bitcoin uses the [[block chain]] algorithm to achieve distributed consensus on who owns what coins. Block chains were invented specifically for the Bitcoin project but they can be applied anywhere a distributed consensus needs to be established in the presence of malicious or untrustworthy actors.

Whilst it's possible to abuse the Bitcoin financial block chain for other purposes, it's better to set up an alternative network and chain which share the same miners. There are several reasons to do this.

* The block chain is a large, complex data structure shared between many people. Verifying its integrity requires many slow (and thus expensive) operations like ECDSA verifications and disk seeks. Everyone who takes part in Bitcoin today runs a node and thus maintains the whole thing. Whilst in future end-users will probably use more efficient but slightly less secure modes (SPV), merchants and miners will probably always pay the full costs for the upkeep of this shared data structure. All these people today are united by a common interest in a new form of payments. They may or may not also be interested in other schemes. So one reason to keep the Bitcoin chain for finance is it's unfair to externalize the costs of unrelated schemes onto people who are interested only in payments - the canonical example being merchants. Increasing the cost of accepting Bitcoins for goods and services hurts everyone who uses the system by reducing the number of merchants or increasing their costs.

* Another reason is that it's just bad engineering to cram every possible distributed quorum into the design constraints of Bitcoin. The transaction format Bitcoin uses is flexible but ultimately designed for finance. You cannot leave out the "value" field. It's always there, even if it'd make no sense for your particular application. Building non-financial applications on top of a financial system results in bizarre protocols and code that are difficult to understand, leading to maintainability problems.

* One final reason is that [[Satoshi Nakamoto|Satoshi]] was opposed to putting non-Bitcoin related data into the main chain. As creator of the system, his opinion should carry a lot of weight with anyone serious about extending it.

=== Designing a new network ===

To create a new network that uses Nakamoto block chains, you need to start by defining what a transaction in your new network means. Bitcoin transactions split and combine value using scripts, but yours don't have to do that. They could be anything. Here's an example of a simple DNS style "transaction" described using [http://code.google.com/p/protobuf/ Google protocol buffers] syntax.

message NameTx {
required string name = 1;
repeated bytes ip_addresses = 2;
required bytes pubkey = 3;
enum ClaimType {
NEW_NAME,
TRANSFER
}
required ClaimType type = 4;

// Only used if type == TRANSFER. The new owner of the name and signature proving current ownership.
optional bytes dest_pubkey = 5;
optional bytes signature = 6;
}

This is very different to a Bitcoin style transaction. There's no concept of inputs, outputs, addresses, values or scripts. It's got what you need for a very simple DNS style scheme (that lacks abuse controls etc) and nothing more. There's also no concept of a "coinbase" transaction.

The block definition is also up to you. It does not have to be formatted in the same way as Satoshi chose, but you need most of the same conceptual parts. You also need to store something else, some data from Bitcoin. Here's a minimal example of what's needed:

message MyBlock {
required bytes prev_block_hash = 1;
required uint32 difficulty = 2;
required uint32 time = 3;

repeated MyTx transactions = 4;
}

message SuperBlock {
required MyBlock my_data = 1;
required BitcoinData bitcoin_data = 2;
}

It's important to observe what we don't have as well as what we do. We don't have the following fields from Satoshis format:

# version: protobufs handles the versioning of binary data formats for us
# merkle root: you can choose to arrange your transactions into a merkle root if you like, so you can use the same disk space reclamation trick Satoshi did. But it's strictly optional. If you want to simplify things down you can skip it.
# nonce

== Sharing work ==

The bitcoin_data field is how you share work with miners today (assuming they opt in by installing your software alongside their bitcoin node). It's defined like this:

message BitcoinData {
// A Bitcoin format block header. Because it's in Satoshis custom format we represent this as a byte array.
required bytes header = 1;

// The first transaction from the block.
required bytes coinbase_tx = 2;

// The merkle branch linking the coinbase transaction to the header.
required bytes coinbase_merkle_branch = 3;

// The coinbase scriptSig contains bits of data in order. Which one is our hash?
required int coinbase_tx_index = 4;
}

All you need to share work is the above four things.

A [[wikipedia:Merkle tree]] is a data structure in which each node in the tree is a hash. The leaf nodes are hashes of the things you want to include in the tree. The interior nodes are hashes of the concatenations of the child nodes. A merkle branch is a part of a merkle tree which allows you to cryptographically prove that something you're given was in the tree, without needing everything that was in the tree. They are calculated by the CBlock::GetMerkleBranch() function in the Bitcoin code.

We store a merkle branch here for efficiency. It means no matter how large the current Bitcoin block is, your alternative network only needs to handle a small amount of data. You could just store the entire Bitcoin block - that would be simpler but inefficient.

The merkle branch links the coinbase transaction to the block header, so you can prove it was in that block. The coinbase TX is a regular Bitcoin coinbase (that makes new coins and claims fees), except the scriptSig on its input contains an extra entry that todays scriptSigs don't. That extra entry is a hash of your block structure. The coinbase scriptSig today is formatted like this:

void IncrementExtraNonce(CBlock* pblock, CBlockIndex* pindexPrev, unsigned int& nExtraNonce, int64& nPrevTime)
{
.....
pblock->vtx[0].vin[0].scriptSig = CScript() << pblock->nBits << CBigNum(nExtraNonce);
.....
}

Just the difficulty bits and the "extra nonce". But it's actually allowed to contain anything, as long as it's not too big. So in your new blocks it'd be:

<MyBlock hash> <nBits> <nExtraNonce>

To get the MyBlock hash into Bitcoin requires a presently unimplemented RPC command, "setextrahashes". It'd update a global list and the IncrementExtraNonce function would include the extra hashes when the scriptSig is built. This is a very simple change to Bitcoin.

In the scriptSig above the coinbase_tx_index would be zero. It's possible to work on an arbitrary number of alternative chains simultaneously:

<MyBlock hash> <SomeOtherChainBlock hash> <nBits> <nExtraNonce>

in which case the BitcoinData message for SomeOtherChain would be 1 rather than zero.

A more complex change is the other new RPC. Because you have your own chain, it has its own difficulty. Most likely it'll be different to Bitcoins own. So you need a way to tell Bitcoin "when you find a block that matches an extradifficulty, please let me know". To mine on multiple difficulties at once, the node vends work (via getwork) matching the easiest difficulty. When a miner reports finding a solution the difficulty is checked to see which chains it is sufficiently difficult for.

Important note: Your chain has its own difficulty and as such the block creation rate is independent of how much mining takes place.

== Independent node software ==

Your new network has its own codebase. It can be written in whatever language you like, use whatever P2P protocol you like, store its data however you like and so on.

When a node on your network receives a message informing it about a new transaction, it verifies that transaction follows the rules of your network. To use our simple DNS example it would verify that if you're claiming a new name, it doesn't already exist and if you're transferring a name that the signatures are correct.

If the transaction is valid, it's added to your current MyBlock message. That message is serialized to binary (protobufs does this for you), hashed and then your node makes an RPC to Bitcoin telling it what the current extra hash is. When Bitcoin finds a Bitcoin-format block of the right difficulty for your network, it informs your software and passes the block header, coinbase transaction and merkle branch to it. Your node combines them together into a BitcoinData message, which is then glued together with your alternative chains block. This "superblock" is then broadcast via your independent P2P network.

When a node on your new network receives a superblock it does the following things:

# Verifies the MyBlock contents are correct, ie, that the transactions follow the rules.
# Verifies that the MyBlock prev hash makes it fit somewhere in the chain and that the difficulty is correct.
# Hashes the MyBlock structure and then verifies that this hash appears in the BitcoinData coinbase scriptSig, in the right place.
# Extracts the merkle root of the Bitcoin format block from the header and then verifies that the coinbase tx provided did, in fact, exist in that block (using the branch, root, tx and header together).
# Verifies that the hash of the Bitcoin format block header is below the difficulty found in the MyBlock structure.

You've now verified that a sufficiently hard proof of work was done over the contents of the MyBlock structure, so your node can relay the newly found block (or if you don't use a P2P network make it available on your server, etc).

On the other side when Bitcoin finds a block that is correct for the Bitcoin network and chain, it broadcasts it and obviously the hash of your MyBlock is included. Fortunately this is only an additional 33 bytes overhead so nobody cares about it - the pollution of the financial chain is both trivial and constant. Note that regular Bitcoin nodes just ignore this extra hash, it doesn't mean anything to them.

== Handling your new block chain ==

You have to handle re-organizations. This is a standard part of the block chain algorithm. When a re-org occurs you have to verify that the state of your world still makes sense. For example in the new chain maybe somebody else now owns a resource you thought you owned. It's up to you how to inform your users of these events and what app specific logic is appropriate here.

You can choose your own parameters for the new chain. As an example, Satoshi chose to target one new block every ten minutes as a tradeoff between latency and wasted work. You could choose something much larger (hours, days) or much faster if you're willing to tolerate more splits due to blocks being found simultaneously. Bitcoin retargets the difficulty roughly every two weeks. You could choose some other length of time.

To store the block chain, Satoshi chose to use Berkeley DB as a way to index from transactions to the blocks they appeared in (amongst other things). You could use any database you liked.

== Paying for resources on alternative chains with Bitcoins ==

A commonly cited reason for putting DNS related data into the financial chain is the desire to pay for names with Bitcoins. You can do this with an independent chain too, because you make the rules and can link the two chains together as you see fit.

To start, decide on the purpose of your payments and who will receive the coins - if anyone. In the case of a DNS system, there are two reasons you might want to pay for names:

# To prevent abuse by people claiming all interesting names via a dictionary attack.
# To incentivise people to run your software and mine on your alternative chain.

In the first case really nobody should receive the payment. The money is being put up as a collateral and has no other use, so as long as it's sitting around unspent that is good enough. In the second case the payment should go to the miner working on the DNS chain.

To implement this we extend our hypothetical DNS transaction message like this:

message NameTx {
required string name = 1;
repeated bytes ip_addresses = 2;
required bytes pubkey = 3;
enum ClaimType {
NEW_NAME,
TRANSFER
}
required ClaimType type = 4;

// Only used if type == TRANSFER. The new owner of the name and signature proving current ownership.
optional bytes dest_pubkey = 5;
optional bytes signature = 6;

// Only used if type == NEW_NAME.
optional bytes collateral_signature = 7;
optional string miner_address = 8;
optional uint64 miner_fee = 9;
}

The collateral_signature field contains an ECDSA signature generated from a public key that holds some Bitcoins. The miner address is blank when the name purchaser creates the transaction and is filled out after a miner receives it, but before they begin working on it.

To buy a name that costs 10 BTC with a miner fee of 2 BTC, a user presses the "buy name" button in their DNS software. It talks to their local Bitcoin node via RPC and does the following:

# Creates a new Bitcoin address (key).
# Sends 10 BTC to the new address (a send-to-self transaction).
# Extracts the key from Bitcoin, meaning it's no longer available to spend in your wallet.
# Stores the key in a local DNS data file ("wallet") somewhere.
# Sets the miner_fee field to the pre-agreed value of 2 BTC.
# Takes the public key part and uses it to sign a version of the NameTx that lacks collateral_signature (a signature can't sign itself) and miner_address.
# The signature is placed in collateral_signature field.
# The transaction is sent to a miner who charges 2 BTC.

When the miner receives the transaction, it verifies that the 10 BTC is not spent:

# The ECDSA public key recovery algorithm is run on the collateral_signature. It can yield several possible keys.
# The public keys recovered are used to verify the signature is correct. This step also figures out which of the possible keys is the right one.
# The correct public key is turned into a Bitcoin address (by hashing it)
# The DNS node software queries Bitcoin to discover whether that address has 10 BTC associated with it, or whether the balance of that address is lower. Note that todays software does not index the balance of every address in the system, but it can be added (the Block Explorer does this).
# If the address does indeed have 10 unspent Bitcoins then the collateral is present and it's OK to serve the name

The miner then creates a new Bitcoin address for themselves and sets miner_address to contain it, then includes it into the current block being worked on. After a block matching the DNS chains difficulty is found, it is broadcast. Other nodes do the following:

# For each transaction, repeat the verification steps to ensure the collateral is not spent.
# Check the balance of the miners own address.
# If the balance is not yet equal to miner_fee, the name is put into a "pending" state in which it is owned but not served in response to DNS queries.

The user observes the broadcast and sees that their name is now pending payment, so they send 2 BTC to the address they find in their transaction. As nodes notice the payment becoming confirmed they start responding to DNS queries for that name (ie, the ownership process is complete).

When the user gets tired of owning the name, he can simply re-import the collateral key into his wallet and spend the coins. The DNS network will soon observe that the coins are spent and make the name available for purchasing by somebody else.

== Incentivising non-resource based chains ==

It's possible to incentivise mining on an alt-chain even if that chain does not have any concept of ownership, ie, if the act of finding a block itself is what is being paid for. An example of this is a timestamping chain in which presence in a block alone is sufficient to satisfy the user.

To implement this, set up a new chain as normal. Blocks in this new chain arrange transactions into a merkle tree in the same manner as Bitcoin does. A client that wants something incorporated into a block connects directly to some miners and submits their transaction. The miners add their address to the transaction as normal. Once a miner finds a block, it immediately sends the block to connected clients whose transactions made it in, but does not broadcast the new block to other miners. The clients respond with a valid Bitcoin transaction which pays for block inclusion. Once all clients have paid up the transaction is broadcast.

If a client has disconnected or does not pay quickly enough, their transaction can be replaced inside the block with its hash. In this way the blocks validity is preserved because the merkle tree is still valid. The newly found alt-block is broadcast, minus the transaction of the delinquent customer. As long as clients are still connected the payment process for all found transactions can be completed quickly: it would only take a few seconds to gather the payments and broadcast those on the Bitcoin network, minimizing the chance of a race that would require you to trust the miner to reinclude your transactions in the next block despite having already been paid.

== Mining on the alt-chain but not Bitcoin ==

So far we've considered a scheme in which all alt-chain miners simultaneously mine on Bitcoin. It's possible some people may wish to mine on your chain but not Bitcoin, perhaps because the cost of keeping up with the Bitcoin transaction rate has become too high for them to bother.

To mine without an attached Bitcoin node, your software can simply implement the same getwork protocol Bitcoin itself does. When a mining tool requests work your program would generate a correctly formatted but ultimately bogus Bitcoin block. The contents of this block don't need to be correct because it will never be broadcast on the Bitcoin network, for example, the prevBlockHash field can be all zeros. It exists purely for backwards compatibility. Whilst the block needs a valid merkle root and a coinbase transaction, no other transactions are required and the only part of the coinbase tx that matters is the part holding the hash.

== Scaling up ==

In the simple scheme each alt-chain being worked on needs 33 bytes in the Bitcoin coinbase transaction (1 for the length and 32 for the hash). Note that if there are two independent miners working on two different alt-chains, you still only need 1 hash in the coinbase scriptSig because the hash isn't meaningful to anyone else on the Bitcoin network. If miners only want to work a handful of chains this overhead is trivially dwarfed by the rest of the data in a Bitcoin block.

But if a miner wishes to work on hundreds, thousands or millions of alternative chains the size of the coinbase scriptSig would balloon and become unworkable. To solve this, the hash stored in the scriptSig can be the root of yet another merkle tree, this time a tree over the hashes of all blocks being worked on. The BitcoinData message is extended like this:

message MyBlock {
required bytes prev_block_hash = 1;
required uint32 difficulty = 2;
required uint32 time = 3;

repeated MyTx transactions = 4;
}

message SuperBlock {
required MyBlock my_data = 1;
required BitcoinData bitcoin_data = 2;
}

message BitcoinData {
// A Bitcoin format block header. Because it's in Satoshis custom format we represent this as a byte array.
required bytes header = 1;

// The first transaction from the block.
required bytes coinbase_tx = 2;

// The merkle branch linking the coinbase transaction to the header.
required bytes coinbase_merkle_branch = 3;

// The merkle branch linking MyBlock to the merkle root in the coinbase_tx.
required bytes altblock_merkle_branch = 4;
}

The verification step becomes a bit more complex:

# Verify the header is of sufficient difficulty for the alt-chain
# Verify coinbase_tx was a part of that block by checking the coinbase_merkle_branch is linked to the merkle root in the header.
# Extract the root of the second merkle tree from the coinbase_tx (call it 2MR).
# Hash the alt-chain block (my_data), verify that altblock_merkle_branch links the my_data hash to 2MR.

You have now proven that the MyBlock instance was worked on, along with perhaps thousands of other chains you don't have to know anything about.

This is an advanced technique which is probably not worth implementing unless the additional scalability is required. It can be introduced in a backwards compatible manner for new chains without impacting older networks.

=== Protecting against double proof ===

The merkle tree approach to scalability comes with a caveat. If naïvely implemented, a miner could cheat the proof-of-work system by putting more than one alt-chain block header into one Bitcoin block. This "cheating" would not cause a problem if the alt-chain blocks all had the same previous-block hash: one or another would win the race, as happens when competing blocks enter the network. The problem would arise if a linked series of alt-chain blocks all existed in one Bitcoin block's auxiliary merkle trees. The miner could work on them all at once, getting more from his hashes than difficulty warrants.

Namecoin's [http://dot-bit.org/forum/viewtopic.php?f=5&t=269&start=11 solution] is to constrain the paths by which alt-chain blocks may be embedded in Bitcoin blocks. This works, but it complicates the picture for miners and chain designers in a future with many alternative chains.

A better solution for new chains is to forbid multiple blocks from having the same proof of work hash - the hash measured against the difficulty target would need to be unique over all blocks. This means you can't embed a series of blocks into the same merkle tree and win them all simultaneously as the network would accept only one.

== Generalized proof of work ==

Hashes embedded in transactions and headers, merkle branches, and [[Nonce|nonces]] all contribute to the goal of [[Proof of work|proving work]] on a block header. One can express all as sequences of these basic operations:

* prepend a byte string to the current data
* append a byte string to the current data
* hash the current data

For maximum flexibility, a work-sharing chain's block acceptance algorithm might accept proof in the form of a script using just these operations. The script would receive as input an alternative chain block header, and the hash of its output would have to satisfy the chain's difficulty.

This design would even support plain Bitcoin proof of work, where the "header" consists of all [[Protocol Specification#block|Bitcoin block header fields]] except the nonce, and the proof-of-work script simply appends the nonce. Thus, one can think of the work-sharing rules as an extension of the original Bitcoin rules.

==External Links==

* [https://bitcointalk.org/index.php?topic=6197.0 BitDNS in the words of Satoshi]
* [http://dot-bit.org/Merged_Mining Merged Mining] in Namecoin
* [http://dot-bit.org/forum/viewtopic.php?f=5&t=269 Namecoin forum discussion]
* [https://bitcointalk.org/index.php?topic=46927.msg572981#msg572981 Forum thread about double proof]

----

See also [[Intrinsic worth brainstorming]].

[[Category:Technical]]

Intrinsic worth brainstorming

2011-09-20T08:07:16Z

Bshanks: more ruminations on paying for computation

This page is for brainstorming ways to endow Bitcoin with "backing", that is, some sort of near-fundamental or near-intrinsic worth to BTC (that does NOT derive merely from their scarcity or their use as a medium of exchange). This would provide a price floor independent of speculators or BTC's use as a medium of exchange.

This page is not the place to discuss [[DoesBtcNeedBacking]], or to argue if speculation or usage of medium of exchange should be included in the definition of "backing". This page is for brainstorming other kinds of backing.

==Topics==
=== BitX ===
See https://bitcointalk.org/index.php?topic=1790.0 . The worth of bitcoins would be the maximum of the worth of any of the services built on top of bitcoin.

Many of the following ideas are a specialization of the BitX idea.

=== Publishing ===
Bitcoin is fundamentally a global censorship-resistant memory system, similar to FreeNet. It just happens that what it is remembering is the log of Bitcoin transactions.

Information can be encoded in the transaction log, and the speed with which it can be encoded is limited by the ability to encode information into the blockchain. Encoding information into the blockchain requires BTC (or, while BTC are mineable, computing power, which has a price floor).

Publishing services could be setup which encode information into the blockchain (that is, to perpetually, globally publish, in a censorship-resistant way), and read out encoded information, for a price. Like FreeNet, for pay. This sort of service is more valuable if it is done on top of something like Bitcoin (because the network effects of Bitcoin provide stronger incorruptibility). This inherent value provides backing.

=== Marked coins ===
Because BTC is traceable, other alternative currency systems could be built on top of BTC. For example, if I had a lot of gold, and assuming that 1 BTC was worth less than an ounce of gold, then I could buy 1000 BTC and then say, "My BTC address is XYZ. Any BTC which was has passed thru this address is equivalent to a transferrable IOU for one ounce of gold from me.". Then I sell those BTC for whatever an ounce of gold is worth. This provides a standardized way to electronically transfer gold IOUs.

This would mean that those bitcoins would be backed by gold. It wouldn't mean that ALL bitcoins would be backed by gold. But, the fact that all alternative currency issuers utilizing this "marked coins" scheme on top of bitcoin first need to acquire bitcoins provides a backing for all bitcoins (the value of this backing would be much less than the value of the alternative currencies themselves, of course). In other words, bitcoin's inherent usefulness as a layer underlying other alternative currencies would be the backing.

===Triple Entry Accounting===
Bitcoin functions as a triple-entry accounting system that provides a [[Block Explorer|transaction register that can be publicly audited]]. Ian Grigg has published on this topic<ref>[http://iang.org/papers/triple_entry.html Triple Entry Accounting]</ref> and on Bitcoin being the first wide-scale application of it<ref>[http://financialcryptography.com/mt/archives/001325.html http://financialcryptography.com/mt/archives/001325.html]</ref>.

This property has already been used in differing ways -- for instance, to verify how much in donations have been collected<ref>[http://bitcointalk.org/?topic=6752.msg101417#msg101417 ALABAMA DISASTER RELIEF FUND]</ref> and the full list of tickets sold for each weekly and monthly [[BitLotto]] draw.

=== Namecoin ===
https://bitcointalk.org/index.php?topic=6017.0 , https://bitcointalk.org/index.php?topic=30294.0

=== Voting ===
BTC could provide the substrate for an anonymous transitive proxy voting system. Simply give tiny amounts of BTC to the voters, then create a deposit address for each ballot alternative and tell the voters to send their votes thru a mixer before depositing.

The need for the authority holding the vote to buy the BTC initially endows BTC with intrinsic worth.

=== Goods and services which are ONLY buyable with BTC, for set prices ===
Mere usage of BTC as a medium of exchange isn't backing. But if some merchants sell something which (a) may ONLY be purchased with BTC (similar to "petrodollars"; a lot of oil can only be purchased with dollars), (b) are made available to sell at a set BTC price, INDEPENDENT OF THE EXCHANGE RATE OF BTC VS ANY OTHER CURRENCY, then this provides backing.

An example would be an MMORPG in which the in-game currency were Bitcoin, and in which the prices of some in-game things were set by the creator of the game without reference to BTC's current price on currency exchanges (specifically, if the price of BTC in dollars fell, the game maker would NOT drop the in-game price of items).

Something which satisfied (a) but not (b) wouldn't quite be backing, but it would be better than nothing.

=== A club which demands dues in BTC ===
Consider how the U.S. dollar is the only currency that is accepted for payment of U.S. taxes. This creates a demand for dollars to pay taxes with.

The U.S. gov allows you to transact business in some other currency, but you still have to pay a percentage of the net income generated by those transactions in dollars.

This isn't quite backing but it would be better than nothing.

----

== Alternatives to BTC which would have intrinsic worth ==
This section is for discussing things that can't be done ON TOP of BTC, but which could be done by creating something very similar to BTC.

=== pseudo-BTC that uses computational power in service of some problem ===
If there were a way for someone to purchase a large amount of pseudo-BTC and then use them to "buy" computing power, in the form of specifying an NP-complete problem, such that solving that problem then becomes a way to encode additional transactions into the blockchain (instead of meaningless hashes), then the price of computing power would be the intrinsic worth of pseudo-BTC.

Obviously, the issue that must be solved is: whoever poses the question (the purchaser of the computing power) may already know the answer. Therefore, we cannot assume that there is a lower bound on the computational difficulty of the problem posed.

If the problem is NP-complete and is posed in a standard NP-complete format, however, we can assume an upper bound on the computational difficulty.

One idea: combine this with the current "meaningless hash" system as follows: in order to mine BTC (or, later, to insert transactions into the block chain), nodes must do both of (a) do some hashing, (b) solve an NP-complete problem whose difficulty is upper bounded at 1000 times the amount of hashing that needs to be done. The system would include a way for computing buyers to bid BTC for the right to pose the problem in (b). Bids are encoded into the blockchain, and the highest already-encoded bid is chosen. The money from the bid is transferred partially to the node that solves the problem (b), but partially to a different node(s) that also solved the hash (a); the money is divided up in proportion with the 1000 constant (this is so that a rich miner can't just make up problems with known answers and bid huge amounts on them, allowing them to always win the bid for computing power and pose the problem, allowing them to undercut everyone else because, knowing the answer to the problem they posed, they only have to solve (a), whereas everyone else would have to solve (a) and (b); this ensures that if they do that, the money they bid doesn't all go back to them, but in fact is bled off to give to other miners too).

Now (a) provides a floor for the difficulty, which is needed to keep the blockchain un-pwnable, and and (b) provides a floor for the value of BTC.

I dunno is 1000 is the right value for the proportionality constant.

Are there any flaws in this? Seems to me that the current BTC ecology could be transitioned to this pretty easily if more than 50% of the miners (weighted by computing power) agreed.

I'm not sure if this would actually cause computing power auctions or not. It may cause:

Miner Q bids unreasonably highly for computing power, then poses a problem for which only they already know the solution; but then eventually, miner R outbids them, then does the same. The prices are too high for others to actually buy computing power. But Q and R themselves generate an enormous demand for bitcoins, because they need to outbid the other in order to monopolize mining.

Hmmm... we don't want mining monopolized.. needs a bit more work..

oh, i got it. choose the bid winner stochastically.

==== more ruminations on paying for computation ====
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1773169 brings up the idea of "programming" a market to solve an NP-complete problem for you by placing a series of orders. This inspires a better idea than holding an auction to see whose NP-complete problem will be solved next; instead, the system should allow everyone's NP-complete problem to be put out there, and other participants solve the ones they can, being paid for it by the person issuing the question.

Also, the low transaction costs of BTC make one wonder if this is already the case; are there ways that one could make offers to the market such that, by their nature, the market is incentivized to solve NP-complete problems for you? Maymin describes one way (which he terms OCO-3) which is a rather direct encoding of 3-SAT, but it's rather unnatural -- but surely there are others.

One difference is that, in Maymin's scenario, the market can silently yield the "wrong answer" simply by being inefficient, whereas in BTC, nodes either claim to have reversed a given hash, or they don't.

-- BayleShanks

==See Also==
* [[Ideal Properties of Digital Commodities]]

==References==
<references />

Intrinsic worth brainstorming

2011-08-08T22:55:32Z

Bshanks: /* pseudo-BTC that uses computational power in service of some problem */

This page is for brainstorming ways to endow Bitcoin with "backing", that is, some sort of near-fundamental or near-intrinsic worth to BTC (that does NOT derive merely from their scarcity or their use as a medium of exchange). This would provide a price floor independent of speculators or BTC's use as a medium of exchange.

This page is not the place to discuss [[DoesBtcNeedBacking]], or to argue if speculation or usage of medium of exchange should be included in the definition of "backing". This page is for brainstorming other kinds of backing.

=== BitX ===
See https://bitcointalk.org/index.php?topic=1790.0 . The worth of bitcoins would be the maximum of the worth of any of the services built on top of bitcoin.

Many of the following ideas are a specialization of the BitX idea.

=== Publishing ===
Bitcoin is fundamentally a global censorship-resistant memory system, similar to FreeNet. It just happens that what it is remembering is the log of Bitcoin transactions.

Information can be encoded in the transaction log, and the speed with which it can be encoded is limited by the ability to encode information into the blockchain. Encoding information into the blockchain requires BTC (or, while BTC are mineable, computing power, which has a price floor).

Publishing services could be setup which encode information into the blockchain (that is, to perpetually, globally publish, in a censorship-resistant way), and read out encoded information, for a price. Like FreeNet, for pay. This sort of service is more valuable if it is done on top of something like Bitcoin (because the network effects of Bitcoin provide stronger incorruptibility). This inherent value provides backing.

=== Marked coins ===
Because BTC is traceable, other alternative currency systems could be built on top of BTC. For example, if I had a lot of gold, and assuming that 1 BTC was worth less than an ounce of gold, then I could buy 1000 BTC and then say, "My BTC address is XYZ. Any BTC which was has passed thru this address is equivalent to a transferrable IOU for one ounce of gold from me.". Then I sell those BTC for whatever an ounce of gold is worth. This provides a standardized way to electronically transfer gold IOUs.

This would mean that those bitcoins would be backed by gold. It wouldn't mean that ALL bitcoins would be backed by gold. But, the fact that all alternative currency issuers utilizing this "marked coins" scheme on top of bitcoin first need to acquire bitcoins provides a backing for all bitcoins (the value of this backing would be much less than the value of the alternative currencies themselves, of course). In other words, bitcoin's inherent usefulness as a layer underlying other alternative currencies would be the backing.

=== Namecoin ===
https://bitcointalk.org/index.php?topic=6017.0 , https://bitcointalk.org/index.php?topic=30294.0

=== Voting ===
BTC could provide the substrate for an anonymous transitive proxy voting system. Simply give tiny amounts of BTC to the voters, then create a deposit address for each ballot alternative and tell the voters to send their votes thru a mixer before depositing.

The need for the authority holding the vote to buy the BTC initially endows BTC with intrinsic worth.

=== Goods and services which are ONLY buyable with BTC, for set prices ===
Mere usage of BTC as a medium of exchange isn't backing. But if some merchants sell something which (a) may ONLY be purchased with BTC (similar to "petrodollars"; a lot of oil can only be purchased with dollars), (b) are made available to sell at a set BTC price, INDEPENDENT OF THE EXCHANGE RATE OF BTC VS ANY OTHER CURRENCY, then this provides backing.

An example would be an MMORPG in which the in-game currency were Bitcoin, and in which the prices of some in-game things were set by the creator of the game without reference to BTC's current price on currency exchanges (specifically, if the price of BTC in dollars fell, the game maker would NOT drop the in-game price of items).

Something which satisfied (a) but not (b) wouldn't quite be backing, but it would be better than nothing.

=== A club which demands dues in BTC ===
Consider how the U.S. dollar is the only currency that is accepted for payment of U.S. taxes. This creates a demand for dollars to pay taxes with.

The U.S. gov allows you to transact business in some other currency, but you still have to pay a percentage of the net income generated by those transactions in dollars.

This isn't quite backing but it would be better than nothing.

----

== Alternatives to BTC which would have intrinsic worth ==
This section is for discussing things that can't be done ON TOP of BTC, but which could be done by creating something very similar to BTC.

=== pseudo-BTC that uses computational power in service of some problem ===
If there were a way for someone to purchase a large amount of pseudo-BTC and then use them to "buy" computing power, in the form of specifying an NP-complete problem, such that solving that problem then becomes a way to encode additional transactions into the blockchain (instead of meaningless hashes), then the price of computing power would be the intrinsic worth of pseudo-BTC.

Obviously, the issue that must be solved is: whoever poses the question (the purchaser of the computing power) may already know the answer. Therefore, we cannot assume that there is a lower bound on the computational difficulty of the problem posed.

If the problem is NP-complete and is posed in a standard NP-complete format, however, we can assume an upper bound on the computational difficulty.

One idea: combine this with the current "meaningless hash" system as follows: in order to mine BTC (or, later, to insert transactions into the block chain), nodes must do both of (a) do some hashing, (b) solve an NP-complete problem whose difficulty is upper bounded at 1000 times the amount of hashing that needs to be done. The system would include a way for computing buyers to bid BTC for the right to pose the problem in (b). Bids are encoded into the blockchain, and the highest already-encoded bid is chosen. The money from the bid is transferred partially to the node that solves the problem (b), but partially to a different node(s) that also solved the hash (a); the money is divided up in proportion with the 1000 constant (this is so that a rich miner can't just make up problems with known answers and bid huge amounts on them, allowing them to always win the bid for computing power and pose the problem, allowing them to undercut everyone else because, knowing the answer to the problem they posed, they only have to solve (a), whereas everyone else would have to solve (a) and (b); this ensures that if they do that, the money they bid doesn't all go back to them, but in fact is bled off to give to other miners too).

Now (a) provides a floor for the difficulty, which is needed to keep the blockchain un-pwnable, and and (b) provides a floor for the value of BTC.

I dunno is 1000 is the right value for the proportionality constant.

Are there any flaws in this? Seems to me that the current BTC ecology could be transitioned to this pretty easily if more than 50% of the miners (weighted by computing power) agreed.

I'm not sure if this would actually cause computing power auctions or not. It may cause:

Miner Q bids unreasonably highly for computing power, then poses a problem for which only they already know the solution; but then eventually, miner R outbids them, then does the same. The prices are too high for others to actually buy computing power. But Q and R themselves generate an enormous demand for bitcoins, because they need to outbid the other in order to monopolize mining.

Hmmm... we don't want mining monopolized.. needs a bit more work..

oh, i got it. choose the bid winner stochastically.

Intrinsic worth brainstorming

2011-08-08T22:54:38Z

Bshanks: /* pseudo-BTC that uses computational power in service of some problem */

This page is for brainstorming ways to endow Bitcoin with "backing", that is, some sort of near-fundamental or near-intrinsic worth to BTC (that does NOT derive merely from their scarcity or their use as a medium of exchange). This would provide a price floor independent of speculators or BTC's use as a medium of exchange.

This page is not the place to discuss [[DoesBtcNeedBacking]], or to argue if speculation or usage of medium of exchange should be included in the definition of "backing". This page is for brainstorming other kinds of backing.

=== BitX ===
See https://bitcointalk.org/index.php?topic=1790.0 . The worth of bitcoins would be the maximum of the worth of any of the services built on top of bitcoin.

Many of the following ideas are a specialization of the BitX idea.

=== Publishing ===
Bitcoin is fundamentally a global censorship-resistant memory system, similar to FreeNet. It just happens that what it is remembering is the log of Bitcoin transactions.

Information can be encoded in the transaction log, and the speed with which it can be encoded is limited by the ability to encode information into the blockchain. Encoding information into the blockchain requires BTC (or, while BTC are mineable, computing power, which has a price floor).

Publishing services could be setup which encode information into the blockchain (that is, to perpetually, globally publish, in a censorship-resistant way), and read out encoded information, for a price. Like FreeNet, for pay. This sort of service is more valuable if it is done on top of something like Bitcoin (because the network effects of Bitcoin provide stronger incorruptibility). This inherent value provides backing.

=== Marked coins ===
Because BTC is traceable, other alternative currency systems could be built on top of BTC. For example, if I had a lot of gold, and assuming that 1 BTC was worth less than an ounce of gold, then I could buy 1000 BTC and then say, "My BTC address is XYZ. Any BTC which was has passed thru this address is equivalent to a transferrable IOU for one ounce of gold from me.". Then I sell those BTC for whatever an ounce of gold is worth. This provides a standardized way to electronically transfer gold IOUs.

This would mean that those bitcoins would be backed by gold. It wouldn't mean that ALL bitcoins would be backed by gold. But, the fact that all alternative currency issuers utilizing this "marked coins" scheme on top of bitcoin first need to acquire bitcoins provides a backing for all bitcoins (the value of this backing would be much less than the value of the alternative currencies themselves, of course). In other words, bitcoin's inherent usefulness as a layer underlying other alternative currencies would be the backing.

=== Namecoin ===
https://bitcointalk.org/index.php?topic=6017.0 , https://bitcointalk.org/index.php?topic=30294.0

=== Voting ===
BTC could provide the substrate for an anonymous transitive proxy voting system. Simply give tiny amounts of BTC to the voters, then create a deposit address for each ballot alternative and tell the voters to send their votes thru a mixer before depositing.

The need for the authority holding the vote to buy the BTC initially endows BTC with intrinsic worth.

=== Goods and services which are ONLY buyable with BTC, for set prices ===
Mere usage of BTC as a medium of exchange isn't backing. But if some merchants sell something which (a) may ONLY be purchased with BTC (similar to "petrodollars"; a lot of oil can only be purchased with dollars), (b) are made available to sell at a set BTC price, INDEPENDENT OF THE EXCHANGE RATE OF BTC VS ANY OTHER CURRENCY, then this provides backing.

An example would be an MMORPG in which the in-game currency were Bitcoin, and in which the prices of some in-game things were set by the creator of the game without reference to BTC's current price on currency exchanges (specifically, if the price of BTC in dollars fell, the game maker would NOT drop the in-game price of items).

Something which satisfied (a) but not (b) wouldn't quite be backing, but it would be better than nothing.

=== A club which demands dues in BTC ===
Consider how the U.S. dollar is the only currency that is accepted for payment of U.S. taxes. This creates a demand for dollars to pay taxes with.

The U.S. gov allows you to transact business in some other currency, but you still have to pay a percentage of the net income generated by those transactions in dollars.

This isn't quite backing but it would be better than nothing.

----

== Alternatives to BTC which would have intrinsic worth ==
This section is for discussing things that can't be done ON TOP of BTC, but which could be done by creating something very similar to BTC.

=== pseudo-BTC that uses computational power in service of some problem ===
If there were a way for someone to purchase a large amount of pseudo-BTC and then use them to "buy" computing power, in the form of specifying an NP-complete problem, such that solving that problem then becomes a way to encode additional transactions into the blockchain (instead of meaningless hashes), then the price of computing power would be the intrinsic worth of pseudo-BTC.

Obviously, the issue that must be solved is: whoever poses the question (the purchaser of the computing power) may already know the answer. Therefore, we cannot assume that there is a lower bound on the computational difficulty of the problem posed.

If the problem is NP-complete and is posed in a standard NP-complete format, however, we can assume an upper bound on the computational difficulty.

One idea: combine this with the current "meaningless hash" system as follows: in order to mine BTC (or, later, to insert transactions into the block chain), nodes must do both of (a) do some hashing, (b) solve an NP-complete problem whose difficulty is upper bounded at 1000 times the amount of hashing that needs to be done. The system would include a way for computing buyers to bid BTC for the right to pose the problem in (b). Bids are encoded into the blockchain, and the highest already-encoded bid is chosen. The money from the bid is transferred partially to the node that solves the problem (b), but partially to a different node(s) that also solved the hash (a); the money is divided up in proportion with the 1000 constant (this is so that a rich miner can't just make up problems with known answers and bid huge amounts on them, allowing them to always win the bid for computing power and pose the problem, allowing them to undercut everyone else because, knowing the answer to the problem they posed, they only have to solve (a), whereas everyone else would have to solve (a) and (b); this ensures that if they do that, the money they bid doesn't all go back to them, but in fact is bled off to give to other miners too).

Now (a) provides a floor for the difficulty, which is needed to keep the blockchain un-pwnable, and and (b) provides a floor for the value of BTC.

I dunno is 1000 is the right value for the proportionality constant.

Are there any flaws in this? Seems to me that the current BTC ecology could be transitioned to this pretty easily if more than 50% of the miners (weighted by computing power) agreed.

I'm not sure if this would actually cause computing power auctions or not. It may cause:

Miner Q bids unreasonably highly for computing power, then poses a problem for which only they already know the solution; but then eventually, miner R outbids them, then does the same. The prices are too high for others to actually buy computing power. But Q and R themselves generate an enormous demand for bitcoins, because they need to outbid the other in order to monopolize mining.

Hmmm... we don't want mining monopolized.. needs a bit more work..

Intrinsic worth brainstorming

2011-08-08T22:34:43Z

Bshanks: /* pseudo-BTC that uses computational power in service of some problem */

Intrinsic worth brainstorming

2011-08-08T22:26:38Z

Bshanks: /* pseudo-BTC that uses computational power in service of some problem */

Intrinsic worth brainstorming

2011-08-08T22:22:17Z

Bshanks: more details on the computational power auction idea

Intrinsic worth brainstorming

2011-08-08T21:50:16Z

Bshanks: /* Voting */

Intrinsic worth brainstorming

2011-08-08T21:49:19Z

Bshanks: voting

Intrinsic worth brainstorming

2011-08-08T21:36:14Z

Bshanks: pseudo-BTC backed by computing power

Backing brainstorming

2011-08-08T21:25:39Z

Bshanks: moved Backing brainstorming to Intrinsic worth brainstorming

#REDIRECT [[Intrinsic worth brainstorming]]

Intrinsic worth brainstorming

2011-08-08T21:25:39Z

Bshanks: moved Backing brainstorming to Intrinsic worth brainstorming

Intrinsic worth brainstorming

2011-08-08T21:09:08Z

Bshanks: /* Publishing */

Intrinsic worth brainstorming

2011-08-08T21:07:52Z

Bshanks:

Intrinsic worth brainstorming

2011-08-08T21:07:05Z

Bshanks: /* = Marked coins */

Intrinsic worth brainstorming

2011-08-08T21:06:47Z

Bshanks: ideas for endowing BTC with a price floor