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

Show "Public Key" with bitcoin address #3

Open
felipelalli opened this issue Sep 4, 2017 · 10 comments
Open

Show "Public Key" with bitcoin address #3

felipelalli opened this issue Sep 4, 2017 · 10 comments

Comments

@felipelalli
Copy link

I don't know if it is possible, but now to get the "Public Key" you have to unlock. It can be useful if you'll use timelock in a multi-sign address.

@petertodd
Copy link
Owner

Oh, you actually tried to use it?!

I'm not gonna lie - this was basically a one-off proof-of-concept; to use it in production it really should get a rewrite.

@felipelalli
Copy link
Author

@petertodd I use it. :) Thank you. In my tests everything always worked nice. The only thing is missing to me is the public key.

@petertodd
Copy link
Owner

Interesting! What do you use it for?

@felipelalli
Copy link
Author

Decrease the liquidity of funds that I will keep in the long term.

@petertodd
Copy link
Owner

Oh, via timelock encryption of private keys? Why not use CHECKLOCKTIMEVERIFY for that instead?

@petertodd
Copy link
Owner

And actually, you can use nLockTime in your case too.

@felipelalli
Copy link
Author

Actually the only reason I do not use this is because I do not trust future versions of bitcoin (in very long term) will be fully compatible with the generated tx. Forks, forks, forks. I think is safer to keep the real private key instead a tx. See the case of BCash, for example: I guess if I kept the tx with nLockTime instead the original private key I'd lost that free lunch. Am I wrong?

@petertodd
Copy link
Owner

Nope, you're not wrong at all when you take forks into account.

Also, for your use-case we can make timelock a bit simpler: you really just need to dedicate as little as a single core to it to keep it generating a timelock chain some amount of time into the future, and you don't even really need the BTC part of it, strictly speaking.

I should do a rewrite of timelock at some point! :)

@felipelalli
Copy link
Author

Thank you for your answer. If you do, please tell me! :) Now I have to spend the same amount of unlock time to lock. Or there is another way?

@InnovativeInventor
Copy link

@felipelalli If my understanding of the the timelock algo is correct, we could truncate the first few bits off the IV, which would force the third-party unlocker to search through ~50% of the possible IVs before being able to claim the bounty (giving the creator an advantage).

The downside with this approach is that this extra difficulty can be easily parallelized. Please let me know if I'm misunderstanding the timelock algo.

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

3 participants