Bitcoin Forum

There have been a bunch of discussions on IRC lately with people who want to build non-financial distributed quorum schemes on top of BitCoin, but don't understand how to leverage BitCoins mining ecosystem. The design for this was laid out by Satoshi some time ago (http://bitcointalk.org/index.php?topic=1790.msg28715#msg28715) but not in sufficient detail for people to actually implement, so these people usually say they'll just stuff their unrelated data into the financial block chain regardless of what the community wants. It makes nobody happy.

In this post I'll try and lay out the rationale and specific work needed for multiple independent chains that share hash power. I'll also outline how to allow people to pay for things on alternative chains with BitCoins.

Rationale

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 schemes for distributed DNS, SSL certs, voting, secure timestamping and so on.

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.

One final reason is that 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.

Fortunately we can have our cake and eat it too.

Designing a new system

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 Google protocol buffers (http://code.google.com/p/protobuf/) syntax.


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 - we'll get to why in a moment. Here's a minimal example of what's needed:


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: unnecessary, we'll see why in a moment.

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:


You could just store the entire block. But that's inefficient. All you need to share work is the above three things.

Here's a quick note about the last field. A 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. Wikipedia has more detail if you need it (http://en.wikipedia.org/wiki/Hash_tree). 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.

The merkle branch links the coinbase_tx 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 the NameBlock structure. The coinbase scriptSig today is formatted like this:


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:

<NameBlock hash> <nBits> <nExtraNonce>

To get the NameBlock hash into BitCoin you'd add a new RPC command, "setextrahashes" or something similar. It'd just 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.

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" - like a hanging RPC or perhaps BitCoin could make an HTTP request by itself. The "getwork" protocol used by distributed workers might also need to be updated so miners can be given multiple difficulties to check ... or perhaps BitCoin can just do what Slushs pool already does and vend work of min(bitcoin difficulty, extra difficulty) then ignore found blocks that don't match BitCoins own difficulty.

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 the current NameBlock 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 block of the right difficulty for your network, it informs your software and passes the block header, coinbase tx and merkle branch to it. Your node combines them together into a BitCoinData message, which is then glued together with the NameBlock. This "superblock" is then broadcast via your independent P2P network.

When a namenode receives a new superblock it does the following things:

• Verifies the NameBlock contents are correct, ie, that the transactions follow the rules.
• Verifies that the NameBlocks prev hash makes it fit somewhere in the chain and that the difficulty is correct.
• Hashes the NameBlock 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 NameBlock structure.

You've now verified that a sufficiently hard proof of work was done over the contents of the NameBlock structure. Your node can now 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 NameBlock 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.

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 name 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.

The BlockChain class in BitCoinJ (http://code.google.com/p/bitcoinj/source/browse/trunk/src/com/google/bitcoin/core/BlockChain.java) shows how to implement these algorithms - it's not complicated. The code is largely independent of the BitCoin transaction format so it could maybe be reused for new networks.

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 alternative resources with BitCoins

Note: I rewrote this section later to remove talk of burning coins as it's not necessary

A commonly cited reason for putting DNS related data into BitCoin 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 implement this we extend our transaction message like this:


To buy a name that costs 10 BTC, the user presses the "buy name" button in their DnsCoin GUI. 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. I think sipa has patches that enable this functionality - it isn't possible with todays software though.
• Stores the key in a DnsCoin data file somewhere.
• Sets the purchase_pubkey field to the public form of the key (ecdsa pubkeys are derived from the private keys).
• Sets purchase_signature to zero, signs that copy of the NameTx, then puts the signature into the purchase_signature field.

The name purchase transaction is now linked to the BitCoin address with 10 BTC, in a crytographically provable way. Other DNS nodes verify that the BitCoin transaction exists and is confirmed before they agree you now own the name.

To release the name you re-import the key back into BitCoin and spend the coins. Because DNS nodes are linked to BitCoin nodes, they will quickly learn that the coins have been spent and will make the name available for purchasing once again.

Other schemes are possible, like pay to miner, if you want your network to interact with BitCoin in a different way.

Thank you, [mike]. That must have taken quite a while to put together.

I don't think the "Paying for alternative resources with BitCoins" explanation has been presented effectively in this forum before today.

All very good, thanks [mike] for the comprehensive clarification.

I agree with pretty much everything you've said, and I think I was the one who originally moaned on IRC, so that proves how great a job you've done at clarifying everything for me :-)

regarding Paying for alternative resources with BitCoins:

If I understand correctly, by "burning" bitcoins you mean a transaction in which you throw the bitcoins away to a non-existing bitcoin address (the address being the signature of your alternative resource), so they can be never recovered. This artificially inflates the value of bitcoin, but may be very undesirable (like you said), because it can lead to total depletion of bitcoin currency (in a very dark type of scenario).

What I'd love to see implemented in the mainstream client is accepting of a simple non-standard transaction which goes "Here is a positive transaction fee, please accept my bytes into the blockchain". A default fee to start with could be as large as 0.01 BTC per every 32 bytes (the size of a sha256 hash), and I'd still be very happy about it. When calculating the block size for the purpose of determining whether a standard bitcoin transaction requires a fee or will be free, such paid-for non-standard transactions should not be counted, because 1. there's already been a fee provided for them, 2. they should not make the fees higher for regular bitcoin users.

Such functionality would allow for reliable crypto-timestamping of arbitrary data, and could be used in many other networks, clients and scenarios. Such timestamping can already be implemented using the burning method you described, but like you said, I think it's not very nice.

Now, I've heard a number of arguments against my solution:

1. This pollutes the main blockchain with non-financial data.

Not more than regular bitcoin transactions do. Also, this IS a financial transaction, it is to pay an amount from sender's account to the account of the guy who's lucky enough to generate the next bitcoin block.

2. This increases the size of the bitcoin blockchain.

Yes, it does. Just like any bitcoin transaction does. But most current regular bitcoin transactions use up the free space of the blockchain and they're pretty much free. So a regular bitcoin transaction costs the network storage and bandwidth, yet does not pay for it. My new type of non-standard transaction would pay for itself and yet still shouldn't make it harder for any regular transactions, so I don't see what's the problem here, it's a win for everyone.

3. It's technically unrelated because it contains different type of data with different validations required.

No. I'm not proposing adding DNS type of validation into the mainstream bitcoin client, or anything of the sort. This should indeed be done outside the scope of bitcoin, perhaps in some kind of DHT. All the mainstream client should care about is "oh, a transaction of size X, with a fee for me! Thank you! The fee covers the size of your data! Accepted." (on a side note, I don't think a p2p DNS needs something like a blockchain at all. The data could be kept in a DHT. Bitcoin could be used simply to prove that someone paid for a domain, nothing else. More on that in another post, maybe)

And again, this kind of "pollution" (as much as I hate the word being used here) CAN ALREADY BE DONE by "burning" bitcoins. I just think it's not very nice to waste such a nice currency and that it's much better to pay it to the block finder instead.

I might be happy implementing a patch to do this, if time permits, and I if can see that it will have a reasonable chance of being accepted into mainstream.

I agree with the previous post.

Note that your proposed system does not help all the other people who have to store the data forever (it cannot be safely pruned because nothing spends the outputs). It gives a temporary benefit to the miner but everyone else gets no benefit at all.

There are a bunch of other reasons not to allow arbitrary data in the chain. For example the long discussed "child porn block" problem.

Yes, it's technically possible to subvert the various anti-abuse measures in place today. That doesn't mean it should be open season on participants storage and bandwidth.

If you want an alternative chain for timestamping of arbitrary events, you could follow the recipe I posted and set the block interval to something really low, like 5 seconds. There'd be a lot of "wasted" work as the chain splits and resolves but you'd get much better resolution than what BitCoin can provide.

Wow, excellent job [mike]!  Thanks for describing this so well--you need an address in your signature for tips.

@goblin I'm pretty sure Mike only offered the "burning bitcoins" option as a technical example.  The reasoning for implementing alternate blockchains is an incredibly sound economic and pragmatic one.  Consider, for example, that someone implements some random scheme within the standard blockchain that experiences a huge boom and bust.  It doesn't make any sense to have bitcoin transaction fees rise and fall with that scheme, yet they would unless miners specifically filtered out transactions related to it.  That's the other side of it too--you don't want to give miners an incentive to do that.  You want mining for alternative schemes to just be "free money" for them, which is what happens when you use your own blockchain paid for in bitcoins (rather than burned of course).

OK, because the miner is randomly chosen based on his computing power, the benefit (i.e. fee) actually gets split into all the miners by this criteria. There's also benefit to the guy who originally sent the transaction, because his stuff gets timestamped. So quite a lot of benefits.

Agreed, it doesn't solve the DNS problem for instance, but the DNS thing should really be kept outside of bitcoin blockchain, I think we can agree on that.

OK that's an interesting one I haven't heard before. Again, it's currently possible anyway. I think it's more of a moral problem / problem with current government rules, than a technical one.

It won't be an open season because they'll have to pay a lot for having their data timestamped. 3 US cents per 32 bytes is quite a lot, much more than amazon or anything else would cost.

Yes, that's possible, but in my opinion, that'd just create another bitcoin-like currency with arbitrary rules set differently. Together we stand, divided we fall, or something. You'd have to gain popularity and do it all over again. And more trade would emerge.

I don't see any reasons why a separate block chain is needed, a separate blockchain basically means a separate currency. It's nice that both could be mined at the same time, but in the end they'll both just be currencies. One is enough.

Oh and ~10 minutes per timestamp is well enough in most scenarios I can think of. I don't think 5-second accurancy of timestamping of DNS or Copyright data is required.

Burning coins wasn't very well thought out, I had to get back to doing real work by the end of writing that so it was rushed ;)

A simpler way that's compatible with the BitCoin of today is just to sign the NameTx with a private BitCoin key that has sufficient coins in it. If you spend those coins the name is automatically relinquished. The name network can simply ask BitCoin "what is the balance of this address" to find out if the name is still valid or should be released.

It'd be a bit annoying with todays software because there's no good way to stop BitCoin using some coins to make new spends. But there are patches floating around to let you extract keys out of BitCoin and re-import them, I think sipa was working on it. So to buy a name that costs 10 BTC you'd send that much to a new address owned by yourself, then export that keypair, then import into the NameCoin software which would use it to sign the NameTx. In practice this would be all automated by the NameCoin software that runs alongside BitCoin.

Agreed.

It wouldn't. Read what I wrote again. Non-standard timestamping transactions would not affect the price of standard transactions.

Also, imagine an online poker company like fivestars incorporated bitcoins into their business model. That would make bitcoin's popularity much higher than it is today, millions of transactions would be processed every day and the fees would get higher. That's one example of your "random scheme with the standard blockchain that experiences a huge boom" (not bust, actually), and it's EXACTLY what you want bitcoin for. It DOES make sense for transaction fees to rise then.

How exactly do you propose to have my own blockchain paid for in bitcoins? The only way I see this is via markets like mt.gox or OTC, which requires willing buyers and sellers.

My scheme gives the miners a very easy scheme to be "free money" for them. They'd earn more in transaction fees than they would if my scheme wouldn't be implemented.

OK, that's an interesting solution that also didn't cross my mind yet.

Regarding buying a name that costs 10 BTC... if you sent that much (10 BTC) to a new address owned by yourself, you wouldn't actually pay anything to anyone, would you?

Anyways, I'd also like to have a simple feature of "send X amount of BTC to the guy who next generates a block", as a form of donation to the "bitcoin network". Is it currently possible to have the outputs of a transaction be 0? That + using the private key to sign stuff would indeed solve my problem pretty well.

I updated the original post to have the pay-to-self solution instead of using coin burning.

Correct, you aren't paying anyone for anything. You're simply parking the coins. You have ownership of the name for as long as the coins remain parked.

Obviously there are other schemes that are possible. If you want to actually pay somebody specific, like somebody mining on the DNS chain, you'd do it another way - eg, use an escrow transaction to send coins to the DNS miner that you only release once they show you a newly found DNS block containing your transaction. It's up to you to define how BitCoin payments interact with the rules of your network.

You could just do a send to an address you own and include however large a fee you desire.

Well, then that's even more damaging to the blockchain... You're sending an arbitrary transaction without any fee, to yourself... Everyone has to pay for it with bandwidth + disk storage, the transaction is at least as large as a signature-signing one, yet there's no fee for it..?

I don't understand the concept of "parking" though, so I might be wrong... What's that?

This doesn't solve the incentive problem. A simple timestamping chain couldn't work, for example. For these cases, it makes more sense to put the hash of a message in a Bitcoin transaction and transfer the actual message through other means.

You could include a fee if that was needed for the tx to confirm - it's no different to any other financial transaction.

Today fees aren't really needed because security of the network is funded via inflation. In future it'll change.

Nodes don't have to store the transaction forever. Only for as long as you hold the name (or whatever thing you're paying for on the other chain). If one day you get bored of owning goblin.bit and spend the coins, that tx that spends the tx that held the name for you will get buried under more and more blocks. Eventually it becomes computationally intractable to reverse and the tx can be thrown away with only that part of the merkle tree remaining. BitCoin doesn't implement this today, but it's described in Satoshis paper and could be implemented with some work.


I just mean the coins aren't spent. They're sitting there, owned by you, but as far as BitCoin is concerned they might as well be your personal savings.

Yes, that is EXACTLY what I want. You don't want to store the whole message in the block because it would be too expensive. You store the hash only AND pay a fee for it.

But I don't think that's currently possible, so that's why I was suggesting adding processing of non-standard transactions to the mainstream client (with a fee of, say, 0.01 BTC for 32 bytes).

Perhaps re-using a private key to sign your message and sending a transaction using that same private key is equivalent in functionality and doesn't require a change though.

It's entirely possible right now. You can put the hash in a standard OP_CHECKSIG output with 0 value and bypass IsStandard, even.

Hang on, you're saying that sending arbitrary data in a transaction with a fee is possible and accepted by mainstream clients? That's not what I've heard on IRC...

Riight, OK, I get what you're saying now. Yes, it's a possible implementation of some P2P DNS, and quite an interesting one.

I just wanted a generic timestamping service out of bitcoin, which could theoretically be used in some P2P DNS implementation as well as other stuff, but yeah, what you're saying makes sense.

It's impossible to distinguish between a valid public key and arbitrary data. Pretend that the data is a public key you're sending BTC to.

The size is pretty limited when you do this, but it's more than enough for a hash.

Sorry, still unsure... Does this "burn" bitcoins?

I'm not proficient with low-level bitcoin stuff yet, but... is such a transaction possible then?

in: 0.01 from a valid bitcoin address
out: 0.00 to arbitrary data / public key
(induced fee: 0.01 to the miner)

Yes -- that's how it would be done. 0-value outputs are valid.

Great, then there's no problem at all! We do have a reliable p2p timestamping service using the bitcoin's blockchain and everyone is happy! Yay! :-)

OK, some people might hate me for this:...

If it's OK to store a hash that way... It should also be OK to store a small simple NS record, right? :->

I think so. Take a look at the DNS proposal that nanotube an I made, which stores records in that area:
http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal

Awesome.

I agree with [mike] in that what satoshi says has more weight than what we say.  I like the concept of shared work with bitcoin miners.  It will only make the bitcoin more valuable and I'm all for that.  Shared work is also what satoshi recommended.

I would also say that what [mike] says carries more weight than some others on this board, simply because he works for Google and also for implementing the BitcoinJ project.  Google only hires the best of the best of the best.

Mike, I'm a little confused what exactly miners would be hashing that can be shared between Bitcoin and BitDNS. Is there some value they can hash that represents both Bitcoin and BitDNS?

Miners hash the BitCoin block header. Miner workers like UfaSoft/poclbm wouldn't need to change at all. That header has a merkle root which is dependent on the contents of every transaction in the current block.

Imagine the BitCoin network is quiet and nothing is happening. Miners hash over a block header that changes only by the "nonce" field each time. Every so often the nonce field overflows and the "extraNonce" part of the coinbase scriptSig is incremented. Because this changes the contents of a transaction, it also changes the merkle root in the header (essentially randomizing it).

Now if a new alternative chain block comes in, your node tells BitCoin "update the extra hash", which is sitting next to the extraNonce. That also triggers re-calculation of the merkle root in the current BitCoin block. If a moment later you find a nonce that makes the current BitCoin block header fit the difficulty of the alternative chain, you have all the data you need to prove on the alternate chain that you did the proof of work.

So to answer your question the value they're hashing that represents both BitCoin and DNS is the current bitcoin block header - same as today.

Sorry [mike], it's time to rip your post apart:


The only people I've seen unhappy about doing domain name registration or other things with bitcoin are those that seem to have some sort of purist mentality in regards to which arbitrary uses of bitcoin are acceptable (according to their own subjective preferences, of course).  Regardless, please don't make assumptions about how random people you don't know will feel if someone does X or Y, and then use your assumption as an argument against some use of bitcoin.


So merchants will be ok with supporting bitcoin transactions for drugs, porn, alpaca socks, and their competitors, but not for domain names?  What's the difference?  If a domain name transaction can be done using practically the same amount of space and computational power as a normal transaction for any other good, then why does it matter?  If the merchant is ok with processing bitcoin transactions that go to their competitors (and the blocks holding those transactions), then why would they care about processing transactions with a few bytes of extra data for domain name registrations?  Either way from their perspective it's just bandwidth, processing power, and storage being used up for things that do not pertain to their business...  Why would they single out domain name transactions as being unacceptable, but tolerate all the other millions of bitcoin transactions that provide no income to them but cost them resources?


How can you decide who it does and does not hurt or if it will increase or reduce the number of merchants?  Like I said, they're willing to tolerate transactions and blocks containing transactions to their competitors or businesses/people that aren't directly competing, so why would they single out domain name transactions?  Perhaps registering domain names through bitcoin increases the security (more miners due to higher fees for domain name transactions) and value (by adding decentralized domain name registration as another use) of bitcoin...is it impossible, or even unlikely that some merchants won't find that increased value more than enough to offset the increase in transactions of similar size to any other transaction?


And this will have to be done for every bitcoin transaction that's buying a domain, whether or not the actual domain information is in the transaction or not. 10000 bitcoin transactions buying domains from some centralized domain name registrar, or 10000 bitcoin transactions containing perhaps a couple more opcodes and a 32-byte hash referencing the domain name the registering has no practical difference in computational cost (and I think some have presented ways to do it without increasing the size at all).


I care about his technical opinions, but I don't recall him presenting any technical reasons for not putting non-bitcoin related data into the main chain.  I think it's purely an economic issue (one I believe most people will view as a net gain), not a technical one.  This means it is merely a matter of personal preference.  Just because Satoshi's preference was to keep non-bitcoin related data out of the block chain does not mean that putting that data in there is not a good idea...it just means he doesn't want it in there.  It's no different than you wanting or not wanting pineapple on your pizza.


It's not because people want to pay for domain names (I think most people, including myself, would much rather get them for free than pay for them).  It's because there needs to be an incentive for people to work on the block chain.


So you leave out the one that actually gives people incentive to work on the DNS block chain...  Obviously you're under no obligation to provide such a solution to us, but it's the most important part!  You went through all of this trouble making this post, but left out the most important piece.  Without it, a decentralized domain name registration project will not become widely used.

If two different block chains were to be used while sharing work and providing an incentive for the miner to support the secondary block chain, the domain name block generated has to be synchronized with the bitcoin block that holds the transaction paying the miner.  If they are not synchronized, the miner is not necessarily guaranteed to be paid for registering the domain name (requiring that registration to be considered invalid, and wasting work on the miner's part for including it, not to mention the block chain being wide open to spam due to not needing to pay to get transactions put into it).  The person buying the domain name can't pay before the block is mined, because they don't know who will mine the block until after it happens.  The simplest way to solve this is for the domain name registrations and fees paid to the miners be in the same transactions on the same block chain.  This means either doing it in the bitcoin block chain, or creating a (probably more valuable) competitor to bitcoin that will provide a greater incentive for miners to stop mining bitcoin and start mining in the new system...not good for bitcoin.


I have to question whether or not you really understand the issue with domain name registrations and bitcoin.  You're using personal preferences as reasons to not do domain name registration in bitcoin, while providing unnecessary technical alternatives (that do not provide the necessary incentives for it to work) just to meet your personal preferences.  For you to even think that people "want to pay for domain names" and then going through the trouble of providing a technical way to do this proves your lack of understanding on this matter.  You're willing to make modifications to bitcoin to accommodate alternative block chains, but are not willing to allow a few extra bytes in a fraction of the transactions, requiring no change to bitcoin and likely providing an economic benefit for most/all people using bitcoin through more mining incentive, thereby increasing network security, and also through more demand for bitcoins due to it's use for domain name registration.

The issue of using the bitcoin block chain for domain name registration is not technical.  It's purely an economic matter, meaning it's entirely subject to personal preferences.  Please don't hide behind Satoshi's opinions or use unnecessary (and unsatisfactory) technical alternatives as a way to suggest to us that your anti-DNS-in-bitcoin post is anything more than an expression of your personal preference.  Also, please don't state your assumptions as to how it would affect others economically or emotionally as though it's some sort of provable fact.

When you track the transaction history, you aren't doing it pointlessly. You need to know the history of all coins so when one of those coins comes to you as payment, you can verify it's legitimate and not an attempted double spend. This is fundamental to BitCoin and accepted by everyone who runs a node. The only way to prove the absence of transactions is to be aware of all transactions.

If you are already happy with the existing domain name system (or whatever), you don't care about those transactions. You aren't planning on taking part in that system so those domain names will never "come around" to you. You also don't care if somebody else owns any particular name. It's additional expense that gains you nothing.

I think you're overfocussing on the DNS case. There are several possible use cases for alternative chains. Nobody will care about all of them. Some of them may involve significant amounts of data, far beyond a DNS system.


Then you need to re-read his posts. The technical reason is that trying to combine every possible proof of work based quorum into a single chain does not scale. This is not a matter of personal preference, it's about solid engineering.


If the names are free then somebody will just do a dictionary attack on the network and claim all useful names.

But regardless, if for your 0x6763 chain you don't want to charge any coins you don't have to. Miners don't need much incentive to work on alternative chains as long as the CPU cost of receiving and verifying your transactions isn't too high. They just connect your software to BitCoin and their mining hardware works on both simultaneously. Beyond an hour or twos setup time nothing more is required.


I left it out because the post was already too long and the overhead of joining a second chain once you do mining on the first is so trivial. Believing in "the cause" is probably enough. It got BitCoin bootstrapped quite fine after all, BTC was not always worth $3.

Regardless, if you believe your idea is so uncompelling nobody will join you unless they get paid, there are designs possible which allow for it. I'm about to head out for the night. I'm sure somebody can propose one here.

Agree with [mike].  It is pretty obvious that allowing domain name registration info in the block chain does not scale.  If you open the doorway to domains, other potential applications using P2P could also do the same causing the chain to bloat.  It truly is about solid engineering.




This is pretty obvious.  Registering a domain must cost something so all the names will not be taken.  One cannot just get it for 'free'.

Also agree with Mike. Anyone who hasn't gotten this point yet, keep in mind that you can look for a solution for any and all block chains (set up as Mike specified) with one round of hashing. If this becomes popular, all miners could be computing for all parallel block chains simultaneously.

I guess you should sell your BTC, then, because arbitrary transactions are allowed right now, and they are very likely to always be allowed. If using Bitcoin's chain for DNS is the best way to do DNS (which I'm not totally convinced about), that's how it will be done. There's no way to stop people from sending information via Bitcoin.

Look who came up with that OP_CHECKSIG trick for inserting arbitrary data:

Gains you nothing...oh, except for maybe a more robust and secure network and a more valuable and more widely used currency.  What each person loses and gains is for each individual person to decide for themselves and only themselves.  Again, please don't state your assumptions of what other people gain or lose as though it's some provable objective fact.


And the miners can and most likely will charge the fees that gets them the most profit for those types of transactions, causing the number of them to be lower than if they were free.  To reduce costs in fees, the people designing the system could provide a more cost effective system by limiting the amount of data put into the transactions/block chain to a minimum that merely references where to find the data in some other system (which is exactly how I would do DNS).  The incentives to prevent it from blowing up out of control already exist (except for perhaps the lack of flexibility for setting fees in the bitcoin client and mining software).


Scaling is generally an economic issue, not a technical one.  With enough resources you can scale anything up in an incredibly inefficient way if you wanted to (just look at most governments).  The nice thing about bitcoin is that the miners can charge transaction fees, reducing the externalization of costs to others from people putting non-bitcoin related data into the block chain, because the fees will make it cost prohibitive to just throw whatever or however much data they want into the block chain.  The miners could pick and choose which types of transactions they will put into a block according to their own economic goals, and the people making the transactions will pick and choose what transactions they will make and pay fees for based on their own economic goals.  The network will adjust and scale according to the values of its users.


All engineering is intended to meet some arbitrary subjective goal, to provide some subjective value to one or more people.  From what you have stated thus far, it seems that among your goals (preferences, values, or whatever you wish to call them) you want the bitcoin block chain to hold only data related to bitcoins, and nothing else, with the exception of making some changes to include some non-bitcoin related data in coinbase transactions.  You've chosen an arbitrary trade-off to meet your goals...some people like it, and some people don't.  Others are willing to make the arbitrary exception of just simplifying things to the point that you can include data in a transaction that references something in some other datastore.  And others are willing to go as far as putting a lot of data into the block chain (entire DNS records and other data).  Every single one of these is completely arbitrary, and the network can technically handle every single one.

The problem is not a technical one, but an economical one.  Storing large amounts of data in the block chain is likely not very economical, but the amount stored would be prevented from growing beyond a certain point due to transaction fees.  Creating an alternative block chain and making exceptions to allow a reference to this alternate chain in a coinbase transaction is certainly less burdensome on the bitcoin network, but I'm not confident that anyone's fully solved all the issues of miner incentive and asynchronous difficulty between the two chains.  Unless those issues are definitely solved, an alternative chain sharing work with bitcoin is likely to suffer and not have a chance of having widespread use.  I personally think that allowing people to put arbitrary references to outside data in bitcoin transactions makes the most sense technically (it's simple) and can be well accommodated by the bitcoin network economically (the market rate chosen by miners and those sending special transactions will regulate how much of this data goes into the block chain).



Yes, that's another reason (in addition to the one where I said the miners need an incentive to even bother creating the blocks), for there to be a fee.


It seems you misunderstood what I was saying.  I was not saying that I want to create a system where the domain names would be free, because I am already well aware that won't work.


That's awfully short-sighted of you.  For bootstrapping, sure, 'believing in "the cause"' may be enough just like it was for bitcoin.  But "this doesn't scale" to wide use of the system.  The vast increase in bitcoin difficulty is due to the fact that the price of bitcoins increased, resulting in more opportunity to make a profit from mining, leading to more people investing in mining.  In the future, I doubt most people are going to be investing in multi-million dollar data centers for bitcoin mining just because they 'believe in "the cause"', and I believe the same will be true for a decentralized DNS.  What significant reason does any other miner have to spend even just a couple hours to get setup for working on the alternative block chain if they don't already 'believe in "the cause"' and don't earn extra money from it?

0x6763, why are you so hostile? Your tone is not contributing to this discussion.

I apologize for the tone, and I'll try to keep it a little nicer in any further posts.

I don't find the arguments against using bitcoin for DNS to be compelling as they all seem to be personal preferences disguised as technical reasons against it.  I'm just trying to point out that all the arguments that have been made against using bitcoin for DNS are economic arguments, which means they are based on perceived gains and loses, personal preferences, etc, and are not technical in nature.


And I should qualify this:
with: "if I were to choose bitcoin for DNS over the option of creating a competing currency."

What technical issues are solved by storing DNS data in the main block chain, as opposed to an alternate yet connected block chain, as Mike has proposed?

I find the idea of one block chain per application, but connected in such a way that they can all be mined against simultaneously, much more appealing than one monolithic block chain. Similar to those that want to change Bitcoin to have constant inflation, or distribute payouts more fairly, or anything else... rather than trying to impose a change on all Bitcoin users, why not start a new chain instead?

I now return you to your regularly scheduled argument.

Incentives. If I want to make an alternative chain for timestamping documents, then no one will ever generate blocks on that chain, since there would be no profit.

If you can easily work incentives into your project, a side chain is better. Then you can do simple payment verification for your chain, too.

First, not every bitcoin miner is going to be a domain name block chain miner, or timestamping miner, etc.  This means that to generate a block in that system that is also tied to a block in the bitcoin block chain could take significantly longer.  If you have 1/1000th of the bitcoin network's hashing power also working on the domain name block chain, then approximately 1 out of every 1000 blocks will generate a block for the domain name block chain.  Not a problem for bitcoin, but it is a problem for the alternative block chain.  If that ratio were to ever reverse to where bitcoin has the minority in hashing power, then bitcoin will suffer from blocks being few and far between.  I'm not sure that anyone has sufficiently solved this problem.

Another problem that comes from this asynchronous block generation rate is paying the miners fees for generating blocks in the alternative block chain.  Currently with bitcoin, when you send a transaction with a fee, you know the miner does not get the fee unless the transaction is accept, and the miner knows your transaction will not be accept without him getting the fee.  But with two block chains where blocks are generated at different rates, you don't know ahead of time who to send the fee to (say for registering a domain name)...the next person that generates a block may not be mining for the domain name block chain, so they shouldn't get the fee.  Someone might just assume pay the domain name miner afterwards, but this is not enforceable, and due to this lack of enforceability it opens up the system to spam attacks where someone sends a bunch of domain name registrations because they don't have to pay for them, yet, and can't be forced to pay for them in the future, but the miner's won't be able to know this, and have know way to know whether or not to put them into a block.  If they don't, they risk losing fees they could have gained...if they do, they risk filling up the block chain with useless data for nothing.

These issues do not exist when the currency and secondary application are both on the same block chain.  If someone has solved this asynchronous block generation rate issue, please point me to the post.  Perhaps I've overlooked it.  Otherwise, I believe the solution that is most likely to work for alternative applications of a block chain is for both the alternative application and the currency to be on the same block chain, which leads me to either using bitcoin, due to it already existing and thriving, or to compete against it.

I think you're missing an important point of Mike's: separate chains will have different difficulties.

If you set up Bittimestamp to generate a block on average once per minute, one will be generated once per minute, regardless of Bitcoin's difficulty. This is because for every hash that wins a Bitcoin block, millions are thrown away as "not sufficiently difficult". However, any one of those hashes (or many of them) are sufficiently difficult for the Bittimestamp chain, since there are potentially fewer miners computing for that chain.

So you can put BitDNS (and whatever other alternate non monetary block chains emerge) in the main Bitcoin block chain, but that forces everyone to process and store DNS data. Or you can come up with a robust and extendable way for any and all chains to be mined simultaneously.

How do the Bittimestamp miners get transaction fees for generating Bittimestamp blocks?

Paying miners for including your NameTx can be done in a straightforward manner. Nothing fancy is required.

Introduce a couple of new fields into the NameTx message, call them:


When the buyer broadcasts his NameTx to claim a new name, he leaves the miner_payment_address field blank and sets the fee field to be however much he is willing to pay for inclusion into a block.

Miners that receive the transaction and begin working on it create a new BitCoin address for themselves and set miner_payment_address to it. When they solve a block, it is broadcast and the name enters a pending state. It isn't available for purchase anymore but it doesn't resolve to IP addresses either. To complete the purchase the buyer sends the fee to the miners address. Once they do so, each DNS node observes that the BitCoin address in the miner_payment_address field has received 'fee' coins and start serving the name. If insufficient payment is sent within a few days the name becomes available once again. The miner loses but the buyer doesn't get anything either. The pending state ensures that people cannot watch transactions and immediately outbid somebody then try to sell the name back to them at inflated prices.

I'm explaining this as an example of how to link chains together financially whilst keeping them separate. I don't actually think a BitDNS style system makes any sense. The interest seems to come primarily from wanting to prevent your name being seized by governments. If your website is illegal in a particular jurisdiction (like the USA) then there's a simple solution - use a domain name under a different countries TLD, pick a country where your operation is legal. If your operation is illegal everywhere then you have to use Tor which already provides a secure P2P DNS system, but also anonymity for both service provider and clients.

A BitDNS system only makes sense if you're very concerned about your domain name being seized, but not concerned at all about seizure of your servers, your clients identities or yourself. Maybe I missed something, but I can't think of any operations which actually operate under such a threat model.

Well, recent history has shown that it's a lot easier for governments (namely the United States) to seize domain names than physical objects. There is also the worry that ICANN will give in to political pressure and play censorship whackamole at the behest of powerful governments.

And this still leaves open the attack for flood the system with domain name registrations with no intention of buying them or using them...just to fill up space or even DDoS the network, due to the payments not being required at the time of registration.  I think I might see how the shared work can function, but it still leaves your proposal open to a very simple and easy attack unless the alternative block chain also has it's own currency and registrations come with a payment.


Some of us don't believe permission from some random person or government is necessary to register a domain name, nor do we believe anyone has a right to take domain names away from us.  I've never (at least knowingly) done anything illegal with a domain name or website, and I don't intend to.  I think the real question is why should anyone else be able to stop me from registering a domain name or be able to take it away from me?  Why should anyone even be in such a position to do that, even if they never do interfere with me?  ICANN is nothing more than government waste, like the central banks.

No it doesn't. There's a separation between coins you park in order to keep the domain - if those coins are spent the domain automatically releases. Then there's the coins you pay to the miner as an incentive to take part in the system. Those you spend when the block is found.

You can't DoS the network because miners wouldn't let you double spend parked coins on multiple domains. If I say output 1 of tx ABCD is the collateral for name mike.bit then I won't be allowed to reuse it to register mike2.bit.


I don't agree with your position because governments and laws do exist regardless of what you might like, and they will happily just seize your servers or throw you in jail if a court gives them permission.

But if you aren't going to do anything illegal, the current DNS works fine. The "D" in it stands for distributed, right? The only reason WikiLeaks had to move to .ch was a DDoS that could have come from anyone. It had nothing to do with governments, who left its infrastructure alone. In fact the parts of DNS controlled by the US Government are remarkably freeform. You don't actually have to be a network to register a .net domain, or a non-profit to register a .org, or a commercial enterprise to register .com even if that's what they're technically meant for. You don't have to be a US citizen or have any US presence, unlike some country TLDs.

If there were examples of DNS actually failing to work well today, BitDNS might be a more compelling proposal.

There are some situations where the server and admin are out of the country.
Also many situations where the country aren't a truly freedom places.
Laws are subject of the usual human's failure.
It's better to build a system that isn't based on human's rules, as Bitcoin is itself.

Wow, a lot has happened since my last post.

Thanks everyone for insightful comments.

Let me just make something clear:

From [mike]'s standpoint, there's nothing to lose in terms of block storage space if we were to follow theymos's/satoshi's idea of 0-value output transactions with some data embedded before OP_DROP/OP_CHECKSIG. These transactions are already accepted by the stock client (and if anyone argues changing this, well, I think that'd be disastrous as it'd encourage coin burning as the only other alternative). These transactions could be pruned by the clients who are not interested in them! They have 0 output + a fee, so they can be considered spent and pruned (well as long as the miner spends her reward from the fee). Only nodes interested in BitStamp/BitDNS/BitX would keep and verify these transactions. So again, there's no problem to the mainstream clients at all in terms of storage; and in bandwidth, it's pretty much identical to the [mike]'s proposed send-to-self with later release.

Are you referring to the actual Namecoin project that I started, or to another system?

I intend to implement cross-mining between chains but I don't see the value of sharing keys between the chains.  There will be exchange markets converting btc to nmc.  There were actually already some transactions along these lines.

I was using BitDNS/DnsCoin/NameCoin interchangably to refer to "people who would like to do DNS on top of block chain technology", sorry for any confusion. I haven't looked deeply at how you implemented it, but it's essentially a separate network with a couple more transaction types right?

Creating an alternative currency just for names then having exchange markets is indeed another way to do it. It's a bit less direct than tying the chains together, but I understand why you did that as I guess it's simpler to implement.

Looking forward to seeing your patches for chain work sharing. It'd be good to get this resolved so there's one less reason to try and abuse the main chain.

theymos, for your consideration:
i think incentives can easily be worked into [mike]'s scheme, if you just change the protocol to require the 'parking' transaction to have X fees. et voila, we have incentives. what do you think?

Well I think we discussed a different approach to yours, vinced. One where the bitcoin blockchain could be used in a simple non-intrusive way.

I have to say I personally don't like the idea of your approach with a separate chain. What you're effectively creating is a currency alternative to bitcoin, with an alternative blockchain. That'll cause competition and basically leave us with two weaker currencies, rather than 1 stronger one. I would prefer to have 1 stronger (mostly for technical reasons - less code duplication, less loss from converting from one to the other), but some people might prefer to have many weaker ones and trade between them -- matter of opinion I guess.

So to summarize (and anyone correct me if I'm wrong) there's three possibilities:

1) Have the registrations in the bitcoin chain and pay for them with bitcoins
2) Have a parallel chain for name registration and pay with bitcoins for it (parking them as collateral)
3) Have a parallel chain for name registration, with its own currency and pay for registrations with that currency.

2 and 3 can share computing power with the bitcoin network.
I don't see 1 as a bad thing, but as has been said, its not suitable for all uses of the block chain.
The technology to share computing power is a necessary thing then. If a bitcoin-like competing currency emerges, it should share computing power with bitcoin (for bitcoin's and its own benefit). It would be also necessary for other services that work as 2. Although 3 could be the only solution for some cases (like other currencies), is it a good enough reason to start a new currency (allow it to pay for names registration instantly) while 2 can be done?
More questions about about namecoin:

Is it already functioning?
Does it have any other difference with bitcoin?
The monetary base will issued in the same way?

https://github.com/vinced/namecoin/blob/master/FAQ.md

http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal

Forget this part:

I've written up the results of this discussion and put it into a (very large) wiki page here:

  https://en.bitcoin.it/wiki/Alternative_Chains

The new page is similar to my original post with the following changes:

• A rewritten section on paying for things in alternative chains that consolidates discussion of paying to no-one (collateral) and paying to miners for both resource-owning chains like DNS, and pure-inclusion chains like timestamping services
• A new section on mining independent of Bitcoin
• A new section on scaling up to millions of alt-chains using merkle trees
• Slightly adjusted to keep mentions of DNS in the payment section and as an example of designing a tx at the start

Hope it helps.

What stops an attacker who intends to fork your non-bitcoin block chain from sending their incorrect hashes "to Bitcoin"?
What exactly does "make an RPC to BitCoin" mean? What is "BitCoin" in this context? I presume you mean a particular bitcoin miner who has implemented the "support non-bitcoin chains" option.
How does the bitcoin node you're talking to know that it's getting a legitimate extra hash rather than let's say a portion of some illegal kiddie porn?
Who on the non-bitcoin chain has the responsibility for and authority to talk to the bitcoin node?
Everyone? - a lot of spam for the bitcoin node
One node? - single point of failure

The way your explanation is drafted makes it look like the non-bitcoin chain is limited to one transaction per bitcoin block. I presume you mean to expand the scheme to support rolling non-bitcoin transactions into non-bitcoin blocks and then getting hashes of those into the bitcoin block chain somehow. Could you expand on exactly how this would work?

ByteCoin

Just read through the whole thing. Brilliant design, being able to share work without bogging down Bitcoin is awesome and the use of the coinbase is very elegant, it's practically begging to be used for this. :)

I believe the section "Scaling up" should be a normal part of the standard. It just makes sense to include that from the start rather than having two methods (list of hashes vs merkle) floating around later.


What do you mean by "incorrect"? The custom network would have its own rules on what constitutes a valid block or transaction. For example a DNS system would only allow registration of previously unregistered domains. This can be enforced by the clients of the custom network. The block chain's job is only to solve conflicts between two blocks that are both independently valid. The older block takes precedence over the younger block.

So your attacker could indeed include a hash of an invalid block for the custom network, but it would be rejected by the custom client if it is invalid or conflicts with a block that is referenced in an older Bitcoin block.



A miner would run both the normal Bitcoin client as well as the client for the custom network. They would ask the custom client to construct a block, get its hash and send that to the mining Bitcoin client for inclusion in the coinbase using a new RPC command "setextrahashes".



Miners would opt in to a specific custom network and run the software for that network themselves. In other words they know the blocks are trusted, because they have generated them themselves. As for the "transactions" in the blocks, such as name registrations/transfers for a DNS system, they'd have to be validated just like Bitcoin transactions are validated before miners include them.



The custom network could have whatever architecture you want. Most likely it would be a P2P architecture in order to avoid a SPOF. As for spam - the custom network would have similar antispam measures as Bitcoin does, [mike] included a concept to pay for resources used on the custom network with Bitcoins. The miners that are connected to the custom network would have to bear the burden of receiving messages from it, they would likely require some sort of compensation for that service. Otherwise you could not motivate miners to run your custom network.

Non-mining nodes in the custom network would likely impose limits and restrictions on what it relays, again just like any P2P network.

The beauty of [mike]'s proposal is that he doesn't make any assumptions about the custom network. As long as it produces a hash it can interface with Bitcoin.


Not at all:


The blocks in [mike]'s example contain an arbitrary number of transactions.



That's up to the designer of the custom chain. They could either include all their data in their blocks (as in the example) or - more likely - include a merkle root like Bitcoin does.


Now I have a question for [mike]: The custom network would only get a block whenever a sympathetic miner makes a block for Bitcoin. So the average time for a confirmation would be 10 minutes divided by the percentage of miners supporting the custom network, correct?

Here is an idea: Could the custom network accept blocks of a lower difficulty? So basically you have the current Bitcoin difficulty target and then a lower difficulty target for the custom network. The Bitcoin miner would sometimes generate Bitcoin blocks that are completely valid as Bitcoin blocks, except they don't meet the full difficulty target required for Bitcoin. But they do meet the lower target for the custom network, so the miner would publish them there. That would allow the custom network to have any difficulty it wants and any rate of confirmations it wants while still sharing work with Bitcoin.

Hmm, it seems I need to make things clearer. Or maybe just shorter, it's a lot to digest all at once.


I put it in a separate section because it's already complex enough and quite a few people have struggled to understand it. Merging it into the first part would result in several independent merkle trees being discussed which is a recipe for confusion. I know that's one of the aspects of Satoshis explanation that foxed me for a long time.

Custom chain difficulties are mentioned already - alt chains will always have their own difficulty. Some other people weren't sure about this so I called it out in bold.


... and ....


Each alt chain has its own difficulty and can make a new block every 10 minutes regardless of how many people mine on it, if that's what you want. The getwork protocol is already used to vend blocks of incorrect difficulty, it's how pools work. You'd use the same technique so the mining modules like ufasoft or poclbm report back whenever they find a block of sufficient difficulty for either chain.

The software that you download and run from bitcoin.org, ie, a regular (full) node in the Bitcoin P2P network.

Bitcoin already does the work of building bitcoin-format blocks, filling them with transactions and then vending the header to independent mining modules like poclbm. It allows you to talk to it via JSON-RPC, that's how mining modules get work to hash.


Bitcoin doesn't care what the hash is. It just accepts some arbitrary 32 byte value and stuffs it into the current bitcoin blocks coinbase transaction scriptSig.

The only reason we need to get Bitcoin involved is to support simultaneous mining on both Bitcoin and other chains, which basically means finding an overlap point in those data structures. The overlap point is the scriptSig - essentially a scratchpad space where anyone who mines can put arbitrary data that Bitcoin will ignore. For instance the genesis block has a quote from the Financial Times in it.


Everyone who runs an alt-chain node and who wants to mine also runs a Bitcoin node along side it. They talk over the localhost connection. There are no shared nodes.


Justmoon already mentioned this but to be totally clear, your alt-chain blocks can contain whatever you want, however many transactions you want, etc. To mine on your new DnsBlock you:

• Add a bunch of DNS transactions into your current DnsBlock data structure
• Hash that block (or do what Satoshi does and arrange transactions into a merkle tree, but it's optional)
• Now send that hash via a localhost RPC "setextrahashes" to Bitcoin, which has a bunch of GPU miners attached to it just like you normally would.

The "setextrahashes" RPC doesn't exist today but it's probably only an afternoons work to add.

The miners are now working on Bitcoin and your alt-chain simultaneously.

isn't this discussion like the developers of a bittorrent client saying 'how should we design the client so that it lets people share only action movies, rather than comedies'? as theymos and others have implied, you can't stop it, and the principle upon which you'd favour 'finance' isn't clear anyhow.

what is 'nonfinancial' about a dns transaction but 'financial' about a generic multi-party contract? even if you solve the design problem to your satisfaction, it resurfaces as a security problem, for what could ever restrict the block chain to 'financial' information anyway? designing the 'action-movie only' bittorrent client would be a fool's errand.

No, it's absolutely nothing like that at all. I suggest you read up some more on the function of the block chain, and the proposed alternate block chains, so you can get a sense of how much data might have to be stored by all Bitcoin nodes if people were to start storing arbitrary data in the main block chain.

i have never seen a project that so readily assumes ignorance in newbies! (maybe the typical newbies are more ignorant here than elsewhere?)

you appear to have misunderstood my message. my analogy was not meant to compare the stakes, only the futility and arbitrariness of the exercise.

you cannot prevent people from 'storing arbitrary data in the main block chain', so at best the present attempt is to get a few people to coordinate their efforts to reduce the size of the block chain by not including things that the group of people doesn't want to include. as i already noted, 'even if you solve the design problem to your satisfaction, it resurfaces as a security problem'. at best you're seeking a gentleman's agreement, analogous to advisory locking in a filesystem.

I think that certain people have conclusions they like to jump to and they do so without properly reading the post they are replying to. It's also easy to infer criticism or an attack where none is meant.

Nobody is seriously suggesting anymore that one can prevent using the bitcoin chain to store data. People want to store data in the block chain to implement certain functionality and if we can facilitate the functionality by some other more convenient method then they will use that instead. Alt-chains attempts to do that.

[mike]'s proposal boils down to having miners who support alternative block chains incorporating a hash for one or more block chains in the coinbase transaction for the bitcoin blocks they're mining.

One drawback is that the people distributing the generic bitcoin client could pull the plug on all the alternative block chains by having their client reject blocks which have a non-standard coinbase. As alt-chain-compatible blocks would not be accepted and relayed by clients, the alt-chain supporting miners would essentially drop off the network. The bitcoin network would experience a drop in hashing power as these clients left but would otherwise continue unaffected.

I don't know whether the possibility of this kill-switch would be acceptable for the alt-chain users.

ByteCoin

Hmm... I'm not sure this would be an issue as long as large or lots of miners adopted this method. I imagine a pool that offered mining of all complementary block chains would be quite popular, and it would be in the best interest of everyone who wants to receive confirmations that they accept these types of blocks.

Why would anyone want to kill off alternative chains so badly?

And yeah I agree with ByteCoin. "Preventing" abuse is really hard, often impossible. Making it senseless or pointless is quite easy and how nearly all abuse control works. Bitcoin will never be a good way to store arbitrary data just because it wasn't meant for that. There's almost always a better tool for your problem.

If you try to stuff data through the existing system, it's like TCP-over-DNS:  possible, but so not designed for that purpose that it is slow, inefficient, limited and problematic.

It also impacts existing currency users, who probably don't want their currency use to be slowed or impacted by DNS data.  That will potentially slow or damage bitcoin-the-currency, which is what most people here are interested in.

Sorry, I'm not a very technical person. Are you saying that a DNS system can be implemented on top of Bitcoin without needing to make any changes to the protocol or ask for permission from anyone? If so then doesn't that make Namecoin worthless or is a new block chain with new transaction types still technically superior than this method?

Yes.


Some people think that a separate system is better. I think combining DNS into Bitcoin's block chain (not into the Bitcoin software) is better because the incentive problem is already solved, it's easier to do, and it would give some intrinsic value to bitcoins.

Yeah, I know the opposing views on the subject. I'm asking purely from a technical standpoint if your system has any limitation that Namecoin doesn't have, thus making the existence of Namecoin still worthwhile even if bitDNS is implemented. I ask because I was planning on investing in Namecoin but I'm afraid that if it becomes a threat to Bitcoin (which I think it will if Bitcoin remains purely for financial transactions forever) then your system will be widely supported and implement, thus crashing the value of namecoins.

How would Namecoin become a threat to Bitcoin?

BitDNS can't use Bitcoin's lightweight client mode, so in the future it will always be rare for people to run their own BitDNS resolvers. I don't know if Namecoin is set up to use client mode, either, though. BitDNS probably requires more resources, too, since servers need to scan all non-DNS transactions.

I think Namecoin is broken for other reasons, though:
https://forum.bitcoin.org/index.php?topic=7244.msg106438#msg106438

As most miners will forget old transactions, you would have to renew the transactions from time to time with BitDNS.
Am I right, theymos?
Maybe BitDNS clients could act like archivers.

Yes. Our spec handles this by requiring DNS renewals. There are ways to handle it more elegantly, though (using multiple 0-value outputs, for example). The spec was written a while ago.

Can you explain (or give a link on) the "multiple 0-value output" solution?

An output with 0 value is valid, and these outputs can't be forgotten by the network until they are spent (which is also valid). So you can stuff all of the DNS data into several of those outputs.

When the bitDNS spec was written, having more than two outputs was not considered standard; therefore, it was difficult to get those transactions into blocks. Now they are standard.

So people would put the DNS info in one output and would send bitcoins to the other to lock the transaction.
But in the demurrage fees thread has been said that miners can forget transactions even if they're not spent.

That's only if >50% of the mining power agrees to do that. I doubt it will ever happen.

No.
The demurrage fee will be charged only if the network agrees, but miners can forget transactions without asking permission. This was an argument against the need of demurrage fees. Most miners will forget old transactions, and only "archivers" (specialized miners) will get the fees for transactions that contain an "old account" as input.

I argued against that notion in the thread:

So you don't think miners will forget DNS transactions.
I think bitDNS could be good for bitcoin if there's a way to prevent DNS transactions to last forever. If bitDNS prevents miners from forgeting the DNS data by parking (or worse, burning) bitcoins in one of the two outputs (the other contains the DNS map), bitDNS service is taking a service from the bitcoin chain for "free" (everlasting storing). I don't think that's fair for the bitcoin network.
With demurrage, bitDNS would need to renew DNS transactions from time to time and would pay miners for the service (through demurrage or transaction fees).
Although I see the problems Namecoin can have, I think it would be interesting to develop the work sharing software for it, since it's the only other block chain in place right now.

(watching)

They can't be forgotten when you're limited to standard scripts, but if non-standard scripts were usable, you could spend the 0-value outputs to make the network forget about them. Yet another reason why IsStandard should be removed.

I'm not talking about the current bitcoin code but about what miners could do within the network protocol.
Anyway, I've not read the bitcoin code yet, So I'm not sure I've understand what you're saying.
You want 0 value outputs to be remembered until the receiver sends them out?

I thought bitDNS would use one transaction output (with 0 value) for storing the the DNS data (the IP, the URL and whatever else is needed) and other output for "parking" some coins and "lock" the transaction, preventing it to be forgotten.

What is the incentive for miners to remember 0 value outputs?
When they receive a transaction with an input that they don't know but that input doesn't add value to the transaction, they can just accept it as good.

That is assuming that miners will never forget outputs with values greater than zero. Maybe they could take the risk of accepting blocks they cannot completely verify if that increases their hash rate.

No. The 0-value output is used to store data. The other output is used to show ownership: you send this coin to transfer the domain. You also need to send the valued output for every new BitDNS command.

The valued output isn't necessary for "locking". A transaction can have just a 0-value output and still be "locked".

Our BitDNS spec wastes a lot of space because the 0-value transactions will exist forever. They can't ever be redeemed. But this is only necessary because our spec -- designed to work with current code -- writes the outputs in such a way that they are irredeemable. If script could be used freely, the 0-value outputs could both contain data and be redeemable. This was the original design, in fact, but IsStandard was created while we were writing it.


Miners must know all unspent transactions, or else they risk ending up in a situation where they need to verify a transaction but are unable to do so. If this ever happens, they will have to stop mining until they get the needed transaction, which might be difficult.


Inputs don't state what its value is, so the miner can't know that it's a 0-value input if it can't see the associated output. It would be clear that no value is taken by the outputs, but you can't determine the fee, which is necessary for verifying blocks. (Rejecting transactions like this is also impossible for other reasons.)


Forgetting transactions will usually slow down mining somewhat, and sometimes it could cause very unprofitable things to happen.

Example:

You are using a client that forgets unspent 0-value transactions after a while. 10% of the network is also running that code. I create a block with a transaction that redeems a 0-value transaction, and most of the network builds on my block. If you reject my block, you are isolated from the network. If you reject my block initially, but start working on it later on, you've just wasted a ton of hashing work. If you accept my block blindly, and it turns out that the transaction is actually invalid later on, you've just wasted a ton of hashing work. Your best option is to immediately find the transaction being redeemed so you can verify it. First, you'll contact your peers to see if they have it. If they don't, you'll have to connect to more peers. Maybe you'll use an archiver service. This is a second or two of wasted hashing time per transaction you need to look up. An attacker might create lots of these transactions just to mess with you.

You actually end up giving up quite a bit of mining power for some disk space.

If your side has more than 50% of the network's computational power, your side can reject transactions with impunity for as long as it is in control.

This sharing of work... are you saying that a % of hashing would be pushed off to the other chain.. or, that useless hashes (ie that don't satisfy bitcoin difficulty) would somehow satisfy a smaller difficulty in another chain?

Imagine a transaction like this:

input 0: tx A output 0 [unknown by the miner]
input 1: tx B output 1 [known by the miner] 10 btc
input 2: tx C output 0 [known by the miner] 5 btc
output 0: address X, 14 btc
fee: 1 btc

The miner could just ignore tx A since it doesn't add value to this tx.
Can he accept this transaction as good even if he doesn't have tx A?


I would accept your block and if it turns out that the transaction is actually invalid later on, I've wasted hashing work.
I would balance the risk of wasting hash power by accepting invalid blocks with the gain in hashing power for not bothering about old transactions.
This can be done not only with 0-value outputs, but with any old transactions.
If I receive a transaction that I cannot verify, I ignore it (don't include it in my block), because otherwise my block could be rejected as invalid.
I just accept transactions that I cannot verify when it's in another block.

The question that remains is...
Is the gain in hashing power for not bothering about old transactions powerful enough to allow miners to forget old transactions?

The fee is not specified directly by the transaction. It is calculated by looking at the difference between input value (which is also not specified) and output value.

Ignoring the other problems with doing this, you could accept the transaction into your own blocks without knowing the exact fee, but you could not correctly verify other blocks that include the transaction. For all you know, the transaction you've forgotten permits a fee of 1000 BTC.


You don't gain any hashing power. Only disk space, which is cheap.

Didn't know that.


Then I don't understand why people said in the demurrage fee thread that miners will forget transactions.

Thank you for all the clarifications.

If storage ends up being really expensive (which I doubt), miners might use demurrage. I think it's a good solution for that (unlikely) case, in fact.

More than 50% of the miners need to agree before actually forgetting transactions, though. Otherwise you'll get the problems that I've described.

The problems you outline presuppose that the miner is trying to include as many transactions as possible. The miner can just shun transactions that use inputs it has forgotten. Unless these transactions contain substantial fees then the miner is not losing out significantly. The underlying problem is that the incentives for miners to include transactions are currently weak.

Taking the "miners forgetting transactions" to its logical conclusion, you could probably run a miner in the current bitcoin environment that neither verifies signature nor stores the block chain. It would assume that all incoming transactions are correct as they have probably been verified by someone else. To prevent an obvious poisoning attack, it could maintain more than one separate anonymous connection to the network and only accept transactions that appear on both.

ByteCoin

No. In my posts in this topic, I have always assumed that the miner will never include the transaction in his own blocks. I am only concerned here with what the miner will do with other blocks with transactions he can't verify.

Wouldn't the net effect of this sharing work proposal be to synchronise the difficulties of the two block chains?

Is that the desired outcome?

I don't think so.


The only thing that I know I don't understand is how you are able to compute only one hash but have the solution be valid for either block chain.

"You don't think so" to part a) or part b)?

Neither part a nor b.

I think the desired outcome is that with just a single hash computation, a miner could potentially generate a valid block on any chain connected in this way.

Okay. So my reasoning goes;
- there needs to be some incentive for individual miner to submit lesser difficulty shares to alternate blockchain
- given the incentive, the individual miner will submit as many lesser difficulty shares as possible to the alternate blockchain
- given the incentive most, if not all, miners on BTC network, will submit as many lower difficulty shares as possible to alternate blockchain
- net effect, the hashpower being pointed at alternate block chain will be nearly same as that pointed at BTC, hence difficulty will rise on alternate block chain until they are synchronised

Ok, yeah, that clicked. I think you're right. The goal is to maximally secure the most block chains with the least effort.

This reasoning is correct, but you're assuming that the block rate in the alternate network is the same as in btc (10 min per block).
That's not necessarily true.

(Added to watchlist)

Good point, thanks for that.

So, choosing the block rate of an alternate chain utilising the same hashing network, is tantamount to choosing it's difficulty ratio with the main BTC chain.

And I propose that this maybe "fix" its relative security, desirability and thus price relative to BTC. E.g. The alternate block chain could have a block rate of 1 per minute (faster confirms) but it's network difficulty would be 1/6th that of BTC and thus it would trade at approx. 1:6 ratio with BTC.

No. The price of bitcoin does not depend on difficulty but on demand and supply. Although security increases demand, demand is not directly proportional to security. If otherCoin were just like like bitcoin but with a monetary base of 300 M instead of 21 M (and a block per minute instead of each 10 minutes), they wouldn't trade at a 1:10. If otherCoin had different properties (rules) than bitcoin, the demand would be different too.

Is it feasible for the hash power of the bitcoin network to be hijacked for code cracking?

If the code cracking problem solution was a mapping to the block solution space it could be as simple as inserting a 'magic' transaction into the block that maps the two solutions together.

Probably easier performed by a large pool operator that distributes work and controls the included transactions in the sought after block solution, for example ... or if all diff. 1 solutions are collected then other auxiliary problems that lie in the same mapping space can be solved simultaneously also.

No.

Even if an attacker really did want to find a bunch of double hashes of specific 680 bit blocks, each result he got back would have a 1 in 4 billion chance of being the one he wanted.

Your reply was prompt and quite emphatic so I'll take that you must have done all the math to back that "no" up previously somewhere. Care to share?

Particularly be interested to see how you discounted mappings into other problem spaces so easily.

32 bits are supplied by the final miner.  2^32 =~ 4 billion.

Besides, no one but us cares that their hashes start with a bunch of zeros.

vinced, the namecoin developer, has added merged mining capability, allowing shared work for the bitcoin and namecoin chains (http://dot-bit.org/forum/viewtopic.php?p=1242#p1242). The design notes are here (https://github.com/vinced/namecoin/blob/mergedmine/doc/README_merged-mining.md).

I'm happy to see Vince came through on his promise, and that the document I wrote proved helpful.

I think this is very important for cryptocurrencies.
Maybe I develop freicoin one day, after all.
I've read a target block to start using it. To what ordinary date does it correspond?
Does it require changes in the bitcoin client?