Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timestamps without destroying bitcoin #1

Open
ghost opened this issue Nov 24, 2013 · 4 comments
Open

Timestamps without destroying bitcoin #1

ghost opened this issue Nov 24, 2013 · 4 comments

Comments

@ghost
Copy link

ghost commented Nov 24, 2013

The general principal of stamping a hash of some data into the blockchain is fine, except it causes bitcoins to be sent to unredeemable addresses.

One could achieve the same result by using the hash of the data to create a private key (just like a brain wallet). You can then send coins to the bitcoin address of the private key, and be able to redeem the coins afterwards.

privateKey = brainwallet(hash(data))
address = get_address_from(privateKey)

Remember now have a minimum dust level which could rise later, bitcoin price is skyrocketing so this becomes expensive, and now we reduce the fee to 2 x miners fee which is more likely to go down over time.

@vog
Copy link
Owner

vog commented Nov 25, 2013

Thanks for bringing up this old idea again. Back then, when I implemented Bitcoinproof, the "dust level" just didn't exist, so having just exactly one transaction was a great win. In the meantime, things changed, so generating the private key instead of the public key is becoming an interesting option.

I'd be glad to receive patches / pull requests on that matter, as I won't be able to implement this on my own in the near future.

However, I'm not sure how the dust level and transaction fees will develop. I agree that the dust level will almost certainly rise, but I don't agree with the transaction fees falling down. I think these will also rise! Over time, the miners will receive fewer and fewer bitcoins by the mining itself, so the transaction fees will become a greater and greater share of their income, which they need to pay for their hardware and electricity.

@ghost
Copy link
Author

ghost commented Nov 25, 2013

My speculation about fees is that I always see fees being around the few cents level, but bitcoin's value is going to rise more and more, thus the fee level has to drop. It's already really expensive at 0.0001 @ ~$800 and there are efforts to make the fee dynamic so we will see how that pans out. Certainly for small transaction you can always just try to pay no fee and hope it get's included in the block anyhow - usually it does eventually.

I am sadly not a python programmer but I have been trying to "get the idea out there" to help spread adoption.

Saying that, maybe someone will see this ticket and submit a patch.

@vog
Copy link
Owner

vog commented Nov 25, 2013

Just for clarification: The Python part is obsolete. I just moved it to a separate location to make it more clear. Bitcoinproof, as you see it on the website, is pure JavaScript.

I think that implementing this is worthwhile independently from the development of transactions fees. With that approach, you still have the option to perform just one transaction (and not to care if others "steal" this money, in case that taking this back is more expensive than leaving it there).

A more important question is how long this transaction will exist in the chain, as there are plans to improve the "pruning" of such transactions in the chain. So maybe it is a good idea to keep the bitcoins there, at least until you actually have to prove something. On the other hand, you'll have essentially a "random" private key, so you could have got a weak one by chance. In that case, it might be better to make the second transaction as quickly as possible before anybody else does.

Either way, it will be up to the user to decide this. The only job of Bitcoinproof would be to generate this private (and possibly also the public) Bitcoin address.

Let's hope somebody picks up this idea. I would love to see this implemented!

vog added a commit that referenced this issue Nov 25, 2013
The old CLI version is written in Python.
The new web version is written in JavaScript.
@ghost
Copy link
Author

ghost commented Nov 25, 2013

You are not vulnerable to a spending attack because you do not share the original data at the time of embedding the data in the blockchain. It's just a payment like any other until you need to prove the timestamp at which point you would have to either spend the funds.

I dont think pruning will lead to the loss of payment records because blockchain explorers will keep the full history and it will be provable because it still has to match and meet the blockchain.

So I hunted around and it seems for Python, the code is already done:

https://github.com/willwharton/pybrainwallet/blob/master/brainwallet.py
or
https://github.com/jgilmour/brainwallet-check/blob/master/brainwallet-check.py

and for JS:

https://github.com/brainwallet/brainwallet.github.com/blob/master/js/brainwallet.js
or
https://github.com/pointbiz/bitaddress.org/blob/master/src/ninja.brainwallet.js

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant