|
Title: How to do document timestamping with the block chain? Post by: cjp on March 21, 2012, 08:23:47 PM I want to create something like the "Bitcoin message service" (https://bitcointalk.org/index.php?topic=47283.0), but I think I need non-standard transactions for that. I know some of you would disapprove, but what would be the easiest way to do this?
And do I need to forward these transactions to certain specific pool operators, who are known to accept non-standard transactions? Who would that be, and how would I forward my transactions to them? My own version of a "messaging service" would put a very low load on Bitcoin: maybe only a single, small transaction once every 24 hours. To prove that load won't be too high, I am willing to use unusually high transaction fees. Think of something like a 0.1 .. 1 BTC transaction fee. (Edit: changed subject) Title: Re: What is the easiest way to make nonstandard transactions? Post by: cjp on March 22, 2012, 09:27:58 PM Sorry for replying to myself, but I have some more info:
I've found the protocol that is used by that "Bitcoin message service": http://btcmsg.staticloud.com/btcmsg_protocol_v1.txt Quote BTCmsg Protocol v1 (2011-09-18) =============================== Each message is represented by multiple payment which is calculated by the following algorithm: 1. Two first chars for message type ('01' for md5, '02' for ascii). 2. Then the message in hex (python binascii.hexlify). 3. Split the long string to groups of 4 hex digits. 4. Each group of 4 hex (e.g. 2 ascii letters from the message) is represented by a payment in satoshi (maximum 0xffff=65535). 5. The service fee (composed of a fixed part and a variable part times the amount of small payments required, minus the transaction fee), can be seen within the first transaction. Enjoy! Actually that's pretty smart, and I feel a bit stupid for not having thought of that! I can do the same of course, and nobody will be able to stop me from doing it (except by convincing me it's a bad idea of course), since this scheme only uses "standard transactions". This does indeed look like the easiest way to achieve my goal, although I need to put a sha256sum into the transaction, so I'll use a new message type ID. As I said before, I'll use a very low number of transactions (max once every 12 hours in the current design), so my load on the block chain shouldn't be too big. Still, the scheme as used by the "Bitcoin message service" is far from optimal. I think the transaction containing the message could be much smaller if a special transaction type was used, that just pushes some unused data on the stack. The policy of only accepting "standard transaction" and not "messages" really works counterproductive here. Since nobody can stop people from using the block chain for messaging anyway, wouldn't it be better to have a standard transaction that allows for efficient insertion of small messages? A sha256sum would be the minimum that should be supported IMO. That would allow people like me to insert secure hashes of documents of arbitrary size. BTW, this reminds me of some people I used to know who played a game of chess by making small bank transfers to each other and putting the chess moves in the transaction comments :D. Title: Re: What is the easiest way to make nonstandard transactions? Post by: Sukrim on March 22, 2012, 10:00:42 PM Well, noone can stop you from doing this, however in the end, all you're doing is burning bitcoins (and giving a few to miners) for the "benefit" of having something (most likely) unprunable embedded on every machine that will process bitcoins in the future.
Maybe you can think of something else how to reach your goal(s) - whatever they are - in a less obtrusive way? Something like sending specific amounts of coins to a special address + giving proof that oyu own this address by signing a message with it's key? Title: Re: What is the easiest way to make nonstandard transactions? Post by: grue on March 22, 2012, 11:03:53 PM or use OP_DROP
Title: Re: What is the easiest way to make nonstandard transactions? Post by: cjp on March 23, 2012, 07:49:25 AM Well, noone can stop you from doing this, however in the end, all you're doing is burning bitcoins (and giving a few to miners) for the "benefit" of having something (most likely) unprunable embedded on every machine that will process bitcoins in the future. I'm not burning bitcoins: I'm just sending them to myself, in very specific amounts. Yes, I will be giving a few to miners, but I think it will be worth it. Maybe you can think of something else how to reach your goal(s) - whatever they are - in a less obtrusive way? Something like sending specific amounts of coins to a special address + giving proof that oyu own this address by signing a message with it's key? What I want to do is a little bit different from what the "Bitcoin message service" does. My goal is to make is a trust-free timestamp service. I want to create evidence that a certain document (or a document with attached name, signature etc.) existed at a certain time. Just "signing with my key" is not sufficient, since it can still be done at a later moment. The block chain acts as a "timestamp server", and I want to use it as such. I don't believe in creating alternative block chains for alternative purposes, because I believe a trust-free, Bitcoin-style timestamp server needs the monetary incentive to function. What I want to do instead, to reduce load on the block chain to an absolute minimum, is to create my own Merkle trees, which have their root in a Bitcoin transaction. or use OP_DROP Please tell me more about this. I already know a couple of things about Bitcoin scripting, but is there a standard transaction type for this? Otherwise, it brings me back to my original question. Title: Re: What is the easiest way to make nonstandard transactions? Post by: CIYAM on March 23, 2012, 08:55:36 AM Another possible approach that had been mentioned before is to make a "fake" bitcoin address that is appears to be valid but instead of being a real address it is actually a user provided hash (after the 1) and then a suffix (to ensure it is parsed as being valid).
You then burn a small amount of BTC by sending to this address (this amount will never be able to be claimed and so cannot be pruned) and then you would have for example the hash of a document permanently recorded in the blockchain. I guess perhaps even better would be to include a URL in the tx (as a message) so that the tx indicates the original document location (or perhaps just its name or something else). Title: Re: What is the easiest way to make nonstandard transactions? Post by: Sukrim on March 23, 2012, 05:11:52 PM Maybe use the hash of the document/message/whatever as private key and make a transaction to and from the resulting address? This would even have the benefit that the hash doesn't get public but it's trivial to check if the resulting address was used at a specific time. Also this might be pruneable (as you leave an empty address) and you can do as many transactions as you like as soon as you want. As long as you pay transfer fees I guess that could be considered part of normal bitcoin operations.
Should someone want to know if the document with the hash "abc123" existed prior to today, he would simply use "abc123" as private key and check if the corresponding address received any money already (maybe even send the filesize in Satoshis to be extra sure?). Title: Re: What is the easiest way to make nonstandard transactions? Post by: bitlotto on March 23, 2012, 10:14:55 PM Code: #!/bin/bash Just creates a hash in Bitcoin address format. Sent a small amount to this address. The likelihood of an address existing that matches the hash of your file are pretty darn small!!! Great to prove that something has existed since at least the time of the tx. Title: Re: What is the easiest way to make nonstandard transactions? Post by: cjp on March 26, 2012, 04:48:55 PM Thanks. That script looks promising.
Is there a way to reclaim the spent bitcoins? If I understand it correctly, the hash is actually used as private key, so it shouldn't be too difficult to format the hash in such a way that I can import it into a Bitcoin wallet, right? I already have pyWallet, and I believe it allows me to import private keys... Title: Re: What is the easiest way to make nonstandard transactions? Post by: bitlotto on March 27, 2012, 02:27:01 AM Thanks. That script looks promising. The script creates a Bitcoin address only and that address is the hash of the file. There is no private key go along with it. So any BTC you send to that address is gone. It would be pretty much impossible to create a private key to go along with it. BUT, it does create a visible hash that's permanently set in the block chain. Is there a way to reclaim the spent bitcoins? If I understand it correctly, the hash is actually used as private key, so it shouldn't be too difficult to format the hash in such a way that I can import it into a Bitcoin wallet, right? I already have pyWallet, and I believe it allows me to import private keys... Title: Re: What is the easiest way to make nonstandard transactions? Post by: CIYAM on March 27, 2012, 02:55:20 AM Is there a way to reclaim the spent bitcoins? If I understand it correctly, the hash is actually used as private key, so it shouldn't be too difficult to format the hash in such a way that I can import it into a Bitcoin wallet, right? I already have pyWallet, and I believe it allows me to import private keys... I think if you want to be sure that the tx is permanently stored then the funds cannot be reclaimed (otherwise it could be pruned in the future), however, another approach you could perhaps consider is the following: 1) Use the file hash as a private key then generate a pubic key and send BTC to an empty wallet (that has had this address imported into it). 2) After getting the BTC immediately forward it to another address in the same wallet (if a tx fee is required you will have to lose this amount). 3) Publish the private key of the original tx (after enough confirmations have passed with the last step). Assuming you don't spend the money you forwarded to yourself then I think that would keep a permanent record with the money eventually being able to be reclaimed (perhaps after a time when you no longer care about the proof). Title: How to do document timestamping with the block chain? Post by: cjp on March 27, 2012, 08:50:25 PM I think if you want to be sure that the tx is permanently stored then the funds cannot be reclaimed (otherwise it could be pruned in the future), however, another approach you could perhaps consider is the following: 1) Use the file hash as a private key then generate a pubic key and send BTC to an empty wallet (that has had this address imported into it). 2) After getting the BTC immediately forward it to another address in the same wallet (if a tx fee is required you will have to lose this amount). 3) Publish the private key of the original tx (after enough confirmations have passed with the last step). Assuming you don't spend the money you forwarded to yourself then I think that would keep a permanent record with the money eventually being able to be reclaimed (perhaps after a time when you no longer care about the proof). My intended way of dealing with pruning of spent transactions is simple: keep a local copy of the relevant part of the Merkle tree of the block. If I am correct, the root of the Merkle tree is part of the block header, which will be kept forever. And actually spending the coins is not just good for me: it also allows for the pruning to take place, which will help save disk space in the future. I already feel a bit like a socially responsible blockchain-environmentalist ;D . If it is possible to use a SHA256 hash as private key and generate a public key and Bitcoin address from that, it seems like an efficient method (less block chain pollution than the "Bitcoin message service" approach). Of course I'll need to transfer the coins to another address with a second transaction, before publishing the SHA256 hash of the document, or otherwise the coins are free to be grabbed by anybody who knows my method and the published hash. I think I can make an implementation of this, but I'd appreciate some help on the following:
Title: Re: How to do document timestamping with the block chain? Post by: Pieter Wuille on March 28, 2012, 12:16:48 AM
In 0.6.0 this is possible via the "importprivkey" RPC call. Title: Re: How to do document timestamping with the block chain? Post by: FreeMoney on March 28, 2012, 12:26:53 AM Someone correct me if I'm wrong, but pruning is just the act of a miner forgetting something they don't need to know anymore. The tx will still have happened and still be in the chain and any service doing lookups of hashes of documents for the purpose of time stamping will be smart enough to not prune. Or maybe you can mark it in some way that lets timestamp checking services forget everything else and remember only the non-financial tx.
If people are worried about the size of the chain, maybe a way to do it is for a company to accumulate documents to be stamped, hash them all together and just include 1 hash per block/hour/day. Title: Re: How to do document timestamping with the block chain? Post by: cjp on March 29, 2012, 06:30:17 AM Someone correct me if I'm wrong, but pruning is just the act of a miner forgetting something they don't need to know anymore. The tx will still have happened and still be in the chain and any service doing lookups of hashes of documents for the purpose of time stamping will be smart enough to not prune. Or maybe you can mark it in some way that lets timestamp checking services forget everything else and remember only the non-financial tx. If people are worried about the size of the chain, maybe a way to do it is for a company to accumulate documents to be stamped, hash them all together and just include 1 hash per block/hour/day. I think you are correct, and that is exactly what I am planning to do: I will create "timestamp certificates" that contain:
I am planning to create max. 2 timestamp transactions per 24 hour, so that every document will be timestamped within 24 hours. And pruning is not a problem, since the certificate contains a local copy of the relevant parts of the block. On the methods of encoding a hash value into a transaction: for simplicity, I'll first use the "Bitcoin messaging service" method, and later, as soon as I switch to Bitcoin 0.6, I'll use the more efficient method of using the hash as a private key. Title: Re: How to do document timestamping with the block chain? Post by: Red Emerald on March 29, 2012, 06:46:04 AM In order for this to work, the timestamp has to be easy to verify by a third party. Keep that in mind when designing your system. It can't be 100% trusted if it relies on any more than the document and the blockchain IMO. If you hash a whole bunch of documents together, than all of those documents will need to be available to the third party. This seems like it would be a problem.
Title: Re: How to do document timestamping with the block chain? Post by: FreeMoney on March 29, 2012, 07:32:03 AM In order for this to work, the timestamp has to be easy to verify by a third party. Keep that in mind when designing your system. It can't be 100% trusted if it relies on any more than the document and the blockchain IMO. If you hash a whole bunch of documents together, than all of those documents will need to be available to the third party. This seems like it would be a problem. Right, I was thinking it would be fine because he'd have a 'master document' with the days stamped docs, but people won't want to pass around the master so they'll go to his site I suppose, but that sucks because now you need him. You don't have to trust him, but you need him, or at least that doc. Still it could be useful, you could push torrents up every day with the day's stamped docs. Doesn't seem like it would scale well at all though. Title: Re: How to do document timestamping with the block chain? Post by: fergalish on March 29, 2012, 09:41:43 AM In order for this to work, ... If you hash a whole bunch of documents together, than all of those documents will need to be available to the third party. This seems like it would be a problem. The "master document" need not actually be all the day's collected documents - just a list of their hashes. i.e. on day X at time Y in block B, a transaction occurred to a private key equal to the hash of master document Z, which therefore existed at that time. In document Z, presented here Your Honours, we can see that there is the hash of "bob's_contract_of_employment.doc" exactly as shown here.Title: Re: How to do document timestamping with the block chain? Post by: Red Emerald on March 31, 2012, 06:02:46 PM In order for this to work, ... If you hash a whole bunch of documents together, than all of those documents will need to be available to the third party. This seems like it would be a problem. The "master document" need not actually be all the day's collected documents - just a list of their hashes. i.e. on day X at time Y in block B, a transaction occurred to a private key equal to the hash of master document Z, which therefore existed at that time. In document Z, presented here Your Honours, we can see that there is the hash of "bob's_contract_of_employment.doc" exactly as shown here.Title: Re: How to do document timestamping with the block chain? Post by: mila on March 31, 2012, 06:27:15 PM In order for this to work, ... If you hash a whole bunch of documents together, than all of those documents will need to be available to the third party. This seems like it would be a problem. The "master document" need not actually be all the day's collected documents - just a list of their hashes. i.e. on day X at time Y in block B, a transaction occurred to a private key equal to the hash of master document Z, which therefore existed at that time. In document Z, presented here Your Honours, we can see that there is the hash of "bob's_contract_of_employment.doc" exactly as shown here.the master document will have to be published. period everybody will be able to see the content of it (should be anyway only the list of document IDs and their hashes) and the hash of the document itself would be in the blockchain. this way anyone could verify if the document of his interest is in any of the master documents, if yes, which one and then test/compare the hashes and verify in blockchain. edit: this approach will be used for official eu publications. they will sign 1 document containing list of hashes of all files published that day and anybody can verify that a pdf comes from the publication office by checking the hash of pdf, checking if the hash matches the info in the list which was signed and then verify signature (certificate used, if it was not revoked, etc). the bitcoin/blockchain timestamping is kind of different, has no certicate issuer nor not known yet how the master document (daily list) would be published. but it should be public and tamper proof Title: Re: How to do document timestamping with the block chain? Post by: cjp on April 01, 2012, 10:44:57 AM I don't understand what you mean with a "master document". For me, the only "master document" is the chain of Bitcoin block headers, and these are verified in a quite unique, decentralized way, which I'm sure you're all familiar with.
Each block header contains (IIRC) a timestamp, which is verified by future miners, and a hash value, which forms the root of a Merkle tree. For normal Bitcoin usage, the "leaves" of the Merkle tree are Bitcoin transactions, but for my timestamping concept I will create a special type of transaction which contains a hash value, and this way, I am able to extend the Merkle tree with my own Merkle sub-tree. The "leaves" of my own sub-tree are the documents that need to be timestamped. The block headers, together with the part of the Merkle tree that leads to a leave, are a timestamp proof for that leave. The block headers are distributed among all Bitcoin users. For Bitcoin transactions, the Merkle tree and the transactions themselves are also distributed among all Bitcoin users, since they are part of the block data, but they may be "pruned" in the future as soon as the transaction outputs are spent. The "Merkle sub-tree" of my timestamping concept is not distributed among all Bitcoin users, and the same is true for the timestamped documents themselves. The person who has an interest in timestamping a document needs to take care of keeping a copy of the document and a timestamp certificate that contains the missing information. Or he can choose to publish both of them in any way he likes. In my timestamping concept, you can provide timestamping proof if you have the following:
The certificate will be machine-readable, and you can use an open source and publicly reviewed script to see whether the certificate is valid. The script needs the above items as input. Title: Re: How to do document timestamping with the block chain? Post by: mila on April 01, 2012, 10:55:41 AM well you mention somewhere that you'll be timestamping twice a day. that means either you'll timestamp two documents or two collective documents with a list of timestamped documents. if the later is the case, the list of timestamped docs is the master document. did my clarification help?
Title: Re: How to do document timestamping with the block chain? Post by: cjp on April 01, 2012, 01:09:00 PM well you mention somewhere that you'll be timestamping twice a day. that means either you'll timestamp two documents or two collective documents with a list of timestamped documents. if the later is the case, the list of timestamped docs is the master document. did my clarification help? I'll timestamp twice per day, and each timestamp can apply to multiple documents. So, in that sense, my concept follows your second option. However, there is no "list of timestamped documents": instead of a list, I use a Merkle tree structure. I don't know whether this makes a big difference for you. The similarity with your second option is that, yes, you need that Merkle tree structure to do the verification. That's why it(*) will be included in the certificate document. The difference is that you don't need the entire Merkle tree to verify a single document: you only need the branch that leads to the document you're interested in. Are you familiar with Merkle trees? (*) actually, only the relevant branch of the Merkle tree will be included in the certificate. Each timestamped document will have its own certificate, even if there are multiple documents to be timestamped at the same moment. Title: Re: How to do document timestamping with the block chain? Post by: phelix on April 06, 2012, 08:06:44 PM have you considered namecoin for your purposes? it actually is a generic name/value pair accounting system.
you can register a fixed name of ~255 bytes and a value of 1023 bytes. not sure if the value is locked in the chain forever but I think at least the name is. Title: Re: How to do document timestamping with the block chain? Post by: cjp on April 09, 2012, 10:00:35 AM have you considered namecoin for your purposes? it actually is a generic name/value pair accounting system. you can register a fixed name of ~255 bytes and a value of 1023 bytes. not sure if the value is locked in the chain forever but I think at least the name is. Yes, but I don't believe in the concept of using separate block chains for separate purposes:
Title: Re: How to do document timestamping with the block chain? Post by: phelix on April 09, 2012, 10:35:43 AM have you considered namecoin for your purposes? it actually is a generic name/value pair accounting system. you can register a fixed name of ~255 bytes and a value of 1023 bytes. not sure if the value is locked in the chain forever but I think at least the name is. Yes, but I don't believe in the concept of using separate block chains for separate purposes:
Title: Re: How to do document timestamping with the block chain? Post by: cjp on April 09, 2012, 12:07:52 PM I sure agree to your first point but imho merged mining resolves the second. gold miners also make use of secondary ores. I want to understand how that "merged mining" works. Can you please explain it, or provide a good link? To my understanding, mining for block chain X works as follows: Code: nonce = 0 BTW, I created a certificate: http://timestamp.ultimatestunts.nl/certificateExample.pdf (http://timestamp.ultimatestunts.nl/certificateExample.pdf) Are there any errors in this? I am particularly interested in:
Title: Re: How to do document timestamping with the block chain? Post by: phelix on April 09, 2012, 04:27:12 PM I sure agree to your first point but imho merged mining resolves the second. gold miners also make use of secondary ores. I want to understand how that "merged mining" works. Can you please explain it, or provide a good link? To my understanding, mining for block chain X works as follows: Code: nonce = 0 [...] the namecoin block hash is included in the bitcoin block. namecoin accepts a bitcoin block hash at namecoin difficulty level. http://bitcoin.stackexchange.com/questions/273/how-does-merged-mining-work http://dot-bit.org/Merged_Mining Title: Re: How to do document timestamping with the block chain? Post by: cjp on April 10, 2012, 06:38:11 PM http://bitcoin.stackexchange.com/questions/273/how-does-merged-mining-work Thanks, that is a good explanation. An interesting thing to see is that merged mining (as described on that page) also works by inserting a hash value into a Bitcoin block. Someone suggests this is done with a 0 BTC transaction (to an address that encodes the hash??). Since this is done by the miners themselves, I can imagine they have more freedom to use non-standard transactions for this. The comments on that page make me a bit worried about the future of Bitcoin, since competing crypto-currencies that do merged mining with Bitcoin can get the same block chain security, while offering much lower transaction fees than Bitcoin. Effectively, they don't pay for what they're using, which will destroy the system for all of us. I hope somebody knows a solution. In the mean time, my Bitcoin-based implementation is already 90% finished, so from this point, it seems simpler to just continue using Bitcoin directly, instead of indirectly through Namecoin. Title: Re: How to do document timestamping with the block chain? Post by: DeathAndTaxes on April 10, 2012, 06:40:39 PM http://bitcoin.stackexchange.com/questions/273/how-does-merged-mining-work Thanks, that is a good explanation. An interesting thing to see is that merged mining (as described on that page) also works by inserting a hash value into a Bitcoin block. Someone suggests this is done with a 0 BTC transaction (to an address that encodes the hash??). Since this is done by the miners themselves, I can imagine they have more freedom to use non-standard transactions for this. The comments on that page make me a bit worried about the future of Bitcoin, since competing crypto-currencies that do merged mining with Bitcoin can get the same block chain security, while offering much lower transaction fees than Bitcoin. Effectively, they don't pay for what they're using, which will destroy the system for all of us. I hope somebody knows a solution. In the mean time, my Bitcoin-based implementation is already 90% finished, so from this point, it seems simpler to just continue using Bitcoin directly, instead of indirectly through Namecoin. Merged mining is done by putting the child chain in the coinbase field. Merged chains can't get something for nothing. If there fees are low they why will miners mine them? Ultimately each miner will decide which chains to mine. No current chain with the exception of namecoin has any significant merge mining. Title: Re: How to do document timestamping with the block chain? Post by: cjp on April 10, 2012, 08:19:46 PM Merged mining is done by putting the child chain in the coinbase field. Ah, thanks. I can't find much documentation about the coinbase field, but the Wiki (https://en.bitcoin.it/wiki/Transactions) mentions "The data in "coinbase" can be anything; it isn't used.", which explains enough for me.Merged chains can't get something for nothing. If there fees are low they why will miners mine them? Ultimately each miner will decide which chains to mine. No current chain with the exception of namecoin has any significant merge mining. I've been thinking about this, and I haven't figured out yet how this is going to work. In fact, I don't think I understand the mining economics of a future Bitcoin-system that is dominated by transaction fees instead of coin generation. What would prevent a "race to the bottom", where miners ask lower and lower fees, to out-compete competitors? The few miners who happen to have the most efficient computers and the lowest electricity prices will be able to out-compete all others. Once others leave the game, the difficulty decreases, but the ratio between the remaining miners doesn't change. The few successful ones can continue lowering the transaction fee, so that the game remains unprofitable for the other ones. In the end, there is a real danger of a 51% attack. I think that, currently, the only thing that keeps difficulty high is the high value of the generated bitcoins per block. With the generated coin value dropping to zero, I think difficulty will also drop to zero, and the system will fail. Luckily, it will take several decades before this happens, and most in-between lowerings of the amount of generated bitcoins will probably be over-compensated by the increase in value due to increased usage. Title: Re: How to do document timestamping with the block chain? Post by: kjj on April 11, 2012, 05:25:42 AM Merged mining is done by putting the child chain in the coinbase field. Ah, thanks. I can't find much documentation about the coinbase field, but the Wiki (https://en.bitcoin.it/wiki/Transactions) mentions "The data in "coinbase" can be anything; it isn't used.", which explains enough for me.Merged chains can't get something for nothing. If there fees are low they why will miners mine them? Ultimately each miner will decide which chains to mine. No current chain with the exception of namecoin has any significant merge mining. I've been thinking about this, and I haven't figured out yet how this is going to work. In fact, I don't think I understand the mining economics of a future Bitcoin-system that is dominated by transaction fees instead of coin generation. What would prevent a "race to the bottom", where miners ask lower and lower fees, to out-compete competitors? The few miners who happen to have the most efficient computers and the lowest electricity prices will be able to out-compete all others. Once others leave the game, the difficulty decreases, but the ratio between the remaining miners doesn't change. The few successful ones can continue lowering the transaction fee, so that the game remains unprofitable for the other ones. In the end, there is a real danger of a 51% attack. I think that, currently, the only thing that keeps difficulty high is the high value of the generated bitcoins per block. With the generated coin value dropping to zero, I think difficulty will also drop to zero, and the system will fail. Luckily, it will take several decades before this happens, and most in-between lowerings of the amount of generated bitcoins will probably be over-compensated by the increase in value due to increased usage. That's an awful lot of assumptions between now and the system failing in a few decades. Title: Re: How to do document timestamping with the block chain? Post by: phelix on April 11, 2012, 04:44:21 PM Merged mining is done by putting the child chain in the coinbase field. Ah, thanks. I can't find much documentation about the coinbase field, but the Wiki (https://en.bitcoin.it/wiki/Transactions) mentions "The data in "coinbase" can be anything; it isn't used.", which explains enough for me.Merged chains can't get something for nothing. If there fees are low they why will miners mine them? Ultimately each miner will decide which chains to mine. No current chain with the exception of namecoin has any significant merge mining. I've been thinking about this, and I haven't figured out yet how this is going to work. In fact, I don't think I understand the mining economics of a future Bitcoin-system that is dominated by transaction fees instead of coin generation. What would prevent a "race to the bottom", where miners ask lower and lower fees, to out-compete competitors? The few miners who happen to have the most efficient computers and the lowest electricity prices will be able to out-compete all others. Once others leave the game, the difficulty decreases, but the ratio between the remaining miners doesn't change. The few successful ones can continue lowering the transaction fee, so that the game remains unprofitable for the other ones. In the end, there is a real danger of a 51% attack. I think that, currently, the only thing that keeps difficulty high is the high value of the generated bitcoins per block. With the generated coin value dropping to zero, I think difficulty will also drop to zero, and the system will fail. Luckily, it will take several decades before this happens, and most in-between lowerings of the amount of generated bitcoins will probably be over-compensated by the increase in value due to increased usage. That's an awful lot of assumptions between now and the system failing in a few decades. but sharp assumptions. the effect you are talking about is discussed as "tragedy of the commons" for example here: https://bitcointalk.org/index.php?topic=67900 and here: http://bitcoin.stackexchange.com/questions/3111/will-bitcoin-suffer-from-a-mining-tragedy-of-the-commons-when-mining-fees-drop-t/3129#3129 Quote In the mean time, my Bitcoin-based implementation is already 90% finished, so from this point, it seems simpler to just continue using Bitcoin directly, instead of indirectly through Namecoin. oh noesbut with namecoin there is not much to be done about this anyway - it works just like that. name_new / name_firstupdate stamp/myhashh789dhh7 ;D |