- Is it possible to import such a key pair into Bitcoin while bitcoind is running? I have no experience with the JSON API, but from what I read, it doesn't seem to support this.
In 0.6.0 this is possible via the "importprivkey" RPC call.
Topic: How to do document timestamping with the block chain? - page 2. (Read 4452 times)
In 0.6.0 this is possible via the "importprivkey" RPC call.
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).
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
.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:
- How can I generate a private and public key from a SHA256 hash, e.g. using bash and openssl?
- Is it possible to import such a key pair into Bitcoin while bitcoind is running? I have no experience with the JSON API, but from what I read, it doesn't seem to support this.
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).
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...
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...
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...
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...
Code:
#!/bin/bash
#
# Timestamping program
# Returns a valid bitcoin address made from stdin
# To timestamp, just send 0.01 BTC to this address
#
# Requires bc, openssl, xxd
#
base58=({1..9} {A..H} {J..N} {P..Z} {a..k} {m..z})
EncodeBase58() {
# 58 =0x3A
bc <<<"ibase=16; n=${1^^}; while(n>0) { n%3A ; n/=3A }" |
tac |
while read n
do echo -n ${base58[n]}
done
}
checksum() {
xxd -p -r <<<"$1" |
openssl dgst -sha256 -binary |
openssl dgst -sha256 -hex |
cut -d\ -f2 |
sed -r "s/^((..){4}).*/\1/"
}
Hash160() {
openssl dgst -sha256 -binary |
openssl dgst -rmd160 -hex |
cut -d\ -f2
}
Hash160ToAddress() {
printf %34s "$(EncodeBase58 "00$1$(checksum "00$1")")" |
sed "s/ /1/g"
}
Hash160ToAddress $(Hash160)
From https://bitcointalksearch.org/topic/timestamping-a-file-into-bitcoins-block-chain-2358 made by grondilu#
# Timestamping program
# Returns a valid bitcoin address made from stdin
# To timestamp, just send 0.01 BTC to this address
#
# Requires bc, openssl, xxd
#
base58=({1..9} {A..H} {J..N} {P..Z} {a..k} {m..z})
EncodeBase58() {
# 58 =0x3A
bc <<<"ibase=16; n=${1^^}; while(n>0) { n%3A ; n/=3A }" |
tac |
while read n
do echo -n ${base58[n]}
done
}
checksum() {
xxd -p -r <<<"$1" |
openssl dgst -sha256 -binary |
openssl dgst -sha256 -hex |
cut -d\ -f2 |
sed -r "s/^((..){4}).*/\1/"
}
Hash160() {
openssl dgst -sha256 -binary |
openssl dgst -rmd160 -hex |
cut -d\ -f2
}
Hash160ToAddress() {
printf %34s "$(EncodeBase58 "00$1$(checksum "00$1")")" |
sed "s/ /1/g"
}
Hash160ToAddress $(Hash160)
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.
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?).
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?).
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).
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).
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.
or use OP_DROP
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?
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?
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
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
.
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!
===============================
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
.
I want to create something like the "Bitcoin message service", 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)
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)
Jump to: