Topic: Proposal: Lock my address (Read 822 times)

I have a link that may be helpful.

seems dynamic QR codes are already here.

 https://www.google.com/#q=dynamic+QR+code

You do understand you are proposing a protocol wide change on the most niche of applications.  As proposed it doesn't even guarantee to improve security as once the release is sent it just becomes a race with the attacker.  The attacker may know malicious pools willing to disregard transaction timing in exchange for a huge cut in the form of fees.    Given that it can't guarantee security any store which loses their wallet would simply cover up the fixed bitcoin address signs with a sheet of paper which says "Sorry Bitcoin payments unavailable".  The reality is even that is never going to happen, as fixed addresses don't work beyond the most trivial applications.   We are talking about a single fixed location, with single authorized user, and single fixed address sign/display possibly no more complex than an addres and QR code printed on the on location printer. There is no evidence that anyone in your protected niche even exists.  

So it is a protocol wide solution, which needs a hard fork, does nothing for the vast majority of users, and (only debatably) improves security by the slimmest margins in the most unlikely scenario of the tiniest (possibly 0%) portion of the user base? Sound about right?

If you want to help this very niche application build a reliable low cost dynamic address display for BIP 32.

I don't keep these links as these discussions are usually not very fruitful.

It is a really bad idea to use a fixed address at retail locations because you can't distinguish payments from different clients. Let say in a bar with a high turnover, many clients are paying as they are drinking, at the same time. With a fixed address it is impossible to determine whether a client has paid or not.

Having a fixed address is also extremely bad for financial privacy. Now everyone knows the turnover of your bar.

Reusing an address may also compromise security. https://bitcoin.org/en/alert/2013-08-11-android

So the answer is no. There is no way in hell we are going to make bitcoin more complex to facilitate bad practice.


This function is available for at least 2 years (search P2SH). It's just not very commonly used but I believe it will become much more common in 2 years.

If you could direct us to those proposals, we may become more helpful and less repetitive.  Do you have any links?

You must have missed this part:
That's a great idea!  It's extra work for those who want to accept bitcoin, and I assume that the vast majority of people already accepting bitcoin payments haven't done it.  Making bitcoin more secure for them seems like something that might help adoption, no?

Qft.

 And if you are concerned about 300 bitcoins being a target, move them to 300 different addresses making it 300 times as hard to steal the bunch. Or 3000 at 0.1 each etc.

Such kind of scheme has been repeatedly proposed. This does not improve security at all.

If you could keep the private key of 1UnlockingAddr safe (and you are not confident in the security of 1AddrToLock), why don't you just simply send your bitcoin to 1UnlockingAddr directly?

If you want to require the private keys of both 1AddrToLock and 1UnlockingAddr to spend the bitcoin, why don't you simply use 2-of-2 multisignature?

But if you locked it, that would simply render the QR code inoperable.
It would be better to use some kind of redirectable/dynamic QR code,
if that is possible.  Kind of off topic...sorry I don't know enough
about bitcoin core to say anything better.

ou must have missed this later post from me:

Why would you want to rescind a private key to begin with, when you could simple use a new address?

Actually, to preserve the integrity of telepatheic's reply, I'll revise my proposal here:

I propose that a further imposition (and opportunity for earnings) be made on miners.  In the same way that a transaction can be broadcast and propagated to all miners, I propose that a replacement-address also be capable of such propagation.  The replacement-address would contain the following values:
Once a block in the main chain contains such a replacement-address, miners must exclude all transactions that spend any outputs from 1AddrToLock unless they have a single output equal to 1ReplacementAddr, at least until a revert-address appears in a block.  A revert-address would be similar to the replacement-address:
In this way, a private key could be temporarily rescinded.

Problems: The transactions in a block are not always simple enough to fall into the paradigm assumed by this idea.  They're really scripts that take input and have to return a 1 in order to be valid.  One of the inputs is usually a signature generated by a private key (if I remember correctly).  So a more accurate description of the function of the replacement-address would be to invalidate a private key (the one matching 1AddrToLock) except when it simply defers to an alternate private key (the one matching 1ReplacementAddr).

This idea came to me when I heard that a hacker had gained root access to LocalBitcoins' webserver for about 40 minutes.  I don't think they would have used it, but there are occasions when one might want to use it.

And maybe miners could publish "replacement rates" that must be provided through 1ReplacementAddr in orer to include a replacement-address in the block they're working on.  If the block also contains a transaction from 1ReplacementAddr that has a high enough fee, the miner would include the replacement-address.  So if a miner doesn't want to respect (new) replacement-addresses, they can just publish a really high replacement fee and ignore (exclude from their block) replacement-addresses that aren't accompanied by expensive enough transactions from 1ReplacementAddr.  But once ANY miner accepts the replacement-address, ALL miners are obligated to honor it.

Am I still missing something?

I will edit OP with your fix when I'm done replying - thanks!

Detailed situation:
I have a USB key with a backup of my private keys on it.  It's encrypted with a 15-character password, but one of my addresses has 300 BTC (over $120,000), which is enough motivation for a hacker to dedicate a lot of computing power to cracking it.  If I can make the coins unspendable before he cracks it, then I have prevented the attacker from getting access to the bitcoins.

Of course, it would be smarter to transfer the 300 BTC to a new secure address instead of locking it, so let's complicate the situation further:  Several hardcopies of the bitcoin address QR Code are displayed to collect payments from customers at retail locations.  Replacing all of them with a new address will take some time.

Perhaps a better idea than a "lock-request" would be a "replacement-address".  So the 1UnlockingAddr would instead be 1ReplacementAddr.  Once a replacement-address is in a block, transactions that spend inputs to 1AddrToLock would be invalid unless their only output was 1ReplacementAddr.

Yes you are missing something


Anyone on the network can get this message and do this:


Now you have to go begging to the malicious party to unlock your bitcoins.

This can be fixed by doing:


However I can't really see the usefulness of this. Can you detail any situation where this would prevent an attacker from getting access to bitcoins?

I propose that a further imposition (and opportunity for earnings) be made on miners.  In the same way that a transaction can be broadcast and propagated to all miners, I propose that a lock-request also be capable of such propagation.  The lock-request would contain the following values:

{
LR:[A bitcoin address to lock, let's call it 1AddrToLock]
LRSig:[the signature resulting from the first item when signed with 1AddrToLock]
ULSig:[the signature resulting from the first two items when signed with an address we'll call 1UnlockingAddr]
}

Once a block in the main chain contains such a lock-request, miners must exclude all transactions that spend any outputs from 1AddrToLock until an unlock-request appears in a block.  An unlock-request would be similar to the lock request:

{
ULR:[1AddrToLock from lock-request]
ULRSig:[the signature resulting from the first two items (and colon) when signed with 1UnlockingAddr]
}

In this way, a private key could be temporarily rescinded.

Problems: The transactions in a block are not always simple enough to fall into the paradigm assumed by this idea.  They're really scripts that take input and have to return a 1 in order to be valid.  One of the inputs is usually a signature generated by a private key (if I remember correctly).  So a more accurate description of the function of the lock-request would be to invalidate a private key (the one matching 1AddrToLock) until an alternate private key (the one matching 1UnlockingAddr) signs an unlock request.

This idea came to me when I heard that a hacker had gained root access to LocalBitcoins' webserver for about 40 minutes.  I don't think they would have used it, but there are occasions when one might want to use it.

And maybe miners could publish "locking rates" that must be provided through 1UnlockingAddr in orer to include a lock-request in the block they're working on.  If the block also contains a transaction from 1UnlockingAddr that has a high enough fee, the miner would include the lock request.  So if a miner doesn't want to respect (new) lock-requests, they can just publish a really high locking fee and ignore (exclude from their block) lock-requests that aren't accompanied by expensive enough transactions from 1UlockingAddr.  But once ANY miner accepts the request, ALL miners are obligated to honor it.

While one can simply move all the coins from 1AddrToLock to a new address, this leaves vulnerable all new transactions to 1AddrToLock.  It may take some time for a victim to instruct all payers to use a new address, and it would be nice to have a mechanism in place to thwart the thieves during that time.

Am I missing something?