This is proposal in reaction to current Bitfinex hack. It has similar pattern as previous BitStamp hack. The most damages are made by other parties sending their bitcoins to the compromised addresses after hack has been discovered and confirmed. This proposal introduces new message being broadcast through the network with list of addresses to put on a blacklist

Blacklist means:

• any client refuses to public transaction containing blacklisted address
• miners reject a transaction containing blacklisted address

To put address on the blacklist requires to have the private key. Every address on the list must contain correct signature and expiration of the blocking.

(sorry for english)

This won't work. This is in effect sending cash to someone, then taking it back and throwing it into a fire.

sorry I don't understand, maybe i did not write it right. It is about blocking my address because it has been compromised and I want to prevenent other parties to send bitcoins to that compromised address. Blocking is one way action, so neither me nor hacker can remove blocking before expiration.

---------- Původní zpráva ----------

Od: Jeff Garzik

Datum: 22. 5. 2015 v 16:40:41

Předmět: Re: [bitcoin] Blacklisting addresses (#6175)

This won't work. This is in effect sending cash to someone, then taking it back and throwing it into a fire.

—

Reply to this email directly or view it on GitHub (https://github.com/bitcoin/bitcoin/issues/6175#issuecomment-104676764).

"Blacklist" is the wrong word to use. "Retire compromised addresses" is the idea here, and I agree that could be a useful feature.

There are a lot of potential problems with such a feature, though. Two immediately come to mind:

Attacker sends payment to merchant, with change going to change address. Attacker then reports the change address as compromised, to try to prevent the payment from going through.

Attacker generates an endless stream of addresses, reports them as compromised to try to flood the network.

You could try to use RBF to double-spend the entire UTXO to fees. This doesn't solve the ripoff-merchants-accepting-unconfirmed-payments issue, but it should solve the network flood issue.

The core problem is that "compromised" and "I regret sending that" are sufficiently, dangerously close enough to create some DoS situations.

sugestion: request to block can be mined. User will need to spend an output (it don't need to be from the same address). Blocking request can be put after OP_RETURN as separate signed request. Miners fees can be used to prioritize transactions. Or the blocking will not take a effect before transaction is mined.

My point is that we already have a way to block a UTXO from being spent: spend it.

this proposal is not about blocking output. It is about blocking target address. You want to avoid to receive not spend

---------- Původní zpráva ----------

Od: Luke-Jr

Datum: 22. 5. 2015 v 21:25:34

Předmět: Re: [bitcoin] Blacklisting addresses (#6175)

My point is that we already have a way to block a UTXO from being spent: spend it.

—

Reply to this email directly or view it on GitHub (https://github.com/bitcoin/bitcoin/issues/6175#issuecomment-104748247).

So... just directly tell the sender not to use the address? You presumably need to give him a new one anyway.

problem is that this can be impossible or hard to achieve. First hack to BitStamp continued after the BitStamp published alert, because a lot of senders reused the address and did not received the alert yet. The same situation with BitFinex. Hack has been discovered when there were 600 BTC sweeped our from the hotwallet. After 3 hours, hack address collected 1500 BTC. with blocking mechanism.bitfinex could to block all remaining hotwallet addresses to prevent additional loss.

---------- Původní zpráva ----------

Od: Luke-Jr

Datum: 22. 5. 2015 v 21:34:25

Předmět: Re: [bitcoin] Blacklisting addresses (#6175)

So... just directly tell the sender not to use the address? You presumably need to give him a new one anyway.

—

Reply to this email directly or view it on GitHub (https://github.com/bitcoin/bitcoin/issues/6175#issuecomment-104749566).

Easy solution: never recognise address reuse as a valid payment.

@luke-jr It seems that u don't want to understand. Address reuse is not only issue for this case. This address https://blockchain.info/address/1Ks4usdNXE4Un97pYG5Aqrjx3tm88GVj9n was not reused and still the sender lost 1 Bitcoin. My idea is mitigate the damage made by the attack. Yes, Bitfinex can state, that any transfers made after announcement will not refunded. But Bitfinex cannot do this, because many transfers was made to addresses generated by the Bitfinex and user is not obliged to be always online. Bitfinex will have to refund this loss, so this still increases the damage.

The idea doesn't require any special change in the Bitcoin protocol. We can use OP_RETURN and put the blocking request after it. This idea will work only if majority of bitcoin users will accept it.

I know, that there are some possible ways, how to abuse this feature - as someone pointed out that it can be used to block unconfirmed transactions. But there is already way to block unconfirmed transaction. Someone can try to double-spend the transaction with the same effect. It still doesn't render the idea invalid. We can just put this feature at the same level as double-spending and problem is solved.

I just drew the idea. You should to improve the idea, not finding the difficulties to throw it away. Bitcoin needs lot of user-protecting features and this is one of them. Otherwise, it will not widely accepted by the public.

Transaction sent by the facebook friend: https://blockchain.info/address/1KY1pqABaNmbA59RKmis4juHVc7NRnigwN Damage 10BTC No address reuse.

It was after the Bitfinex did already know that hotwallet was compromised. Unfortunately, this was not known by the friend.

Oh well, your idea isn't viable. OP_RETURN just makes a commitment, it doesn't do anything useful for this. You simply can't expect every bitcoin user to track a list of compromised keys for you...

@luke-jr Bitcoin nodes now must track a list of all_transactions and all_unspend_outputs! This is not an argument. Anyway, if this could be a problem, there can be some implicit or explicit expiration.

Think about it, don't try to find arguments against it.

Feel free to patch your own node to implement blacklisting behavior. However this project will remain neutral as to maximize overall fungibility of bitcoin, and not merge such functionality.

I'm sorry about what incompetence appears here. You have rejected the proposal without any analysis or any argument. I'm afraid that we have a long way to accepting Bitcoin general public. It'll be difficult without instruments to protect its users.

I cannot see how the fungibility of bitcoin is interfered with an option for the owner of a bitcoin address to retire it, so it cannot accept futher funding.

Please explain.

Ondra, Petr: lets imagine, it is done in the bitcoin somehow. It must be stored somewhere (where?). And now imagine someone else being an attacker and wanting to DoS the network. So they will start at private key 1 and start network flooding... This particular problem can be partially solved by the fee on these lock translations (if the lock is being done as a transaction of some special kind). And there are other problems I can think of - do you see them? Do you have a solution for them?

But anyway, this is not a solution for offline signing, SPV clients etc.

It is not about incompetence, but about the visionary - people here see a bit more than you. In this case much more than you. People here are not obliged to finish your ideas. If you want something to happen, just work on it, create proposal, send it to the development list for discussion etc.

In this particular case, the whole principle of "deposit to some address" needs to be reworked from the exchanges side IMO.

What you're trying to do is use the p2p protocol to broadcast information to senders, so they do not send coins to those addresses anymore.

There are several problems with this:

• You will rarely reach all senders, as the p2p protocol mostly reaches full nodes, while wallets are increasingly on more lightweight systems, which are often only connected intermittently to the network.
• You're also suggesting to make miners not accept such transactions. This is potentially ineconomical for them (they may lose fees), and it is hard to expect this to be deployed 100% (it can't be enforced by full nodes without risking a hard fork), and as such, may, if a sender still sends to a retired address, just result in a slower-confirming transaction, but still in lost coins. Asking miners to not accept blacklisted addresses in outputs also doesn't help really, you really just need to get your information to a sender, so they don't create such a transaction in the first place. I would just drop that part of the proposal.
• DoS potential: who stores these blacklists? If full nodes need to maintain them so that lightweight clients can request the blacklist list, you're looking at unbounded memory and bandwidth usage. At the very least there must be some cost or other finite resource one has to spend to create a blacklist, to limit the number of blacklist entries active at any given time.
• This is a network protocol change, which requires coordination between more software than just Bitcoin Core. If you want a solution of this nature, please discuss on the mailing list first, and if a good mechanism is found, propose a BIP and an implementation.
• A better solution to this fundamental problem already exists: if you worry that you might need to revoke a private key, use the BIP70 payment protocol, where senders ask for the address to use on the fly, rather than a static piece of data referring to a private key. This is also cleaner in term of network architecture: it sends the information directly and solely to the sender (who is the only one who cares), rather than flooding the full node network (which mostly doesn't care).

ok, let me see

1. it is my mistage, this feature requires that blocking (actually revoking) must be mined. It solves all issues. It also requires to spend an ouput (not connected with the address)

2. this argument is invalid when 1) . Fees for such transaction can be higher.

3. this argument is invalid when 1). Fees will solve this issue, as it solves potential transaction DoS, Lightweight clients uses gateway to broadcast transaction so that gateway can hold blacklist (it still must reject double spends and duplicated transactions). SPV clients can ask nearest node whether addresses are revoked

4. It can be implemented as extension inside ordinary transaction after OP_ RETURN. It also need to be accepted by majority, however bitcoin core is reference client, it has very easy position for accepting new standardts.

5. No way. It requires that receiving party must be online. This is againts bitcoin philosophy.

I cannot write BIPS. Of course anyone that likes this idea can write it. I am just sharing the idea.

---------- Původní zpráva ----------

Od: Pieter Wuille

Datum: 25. 5. 2015 v 17:55:43

Předmět: Re: [bitcoin] Blacklisting addresses (#6175)

What you're trying to do is use the p2p protocol to broadcast information

to senders, so they do not send coins to those addresses anymore.

There are several problems with this:

• You will rarely reach all senders, as the p2p protocol mostly reaches

full nodes, while wallets are increasingly on more lightweight systems,

which are often only connected intermittently to the network.

• You're also suggesting to make miners not accept such transactions. This

is potentially ineconomical for them (they may lose fees), and it is hard

to expect this to be deployed 100% (it can't be enforced by full nodes

without risking a hard fork), and as such, may, if a sender still sends to

a retired address, just result in a slower-confirming transaction, but

still in lost coins. Asking miners to not accept blacklisted addresses in

outputs also doesn't help really, you really just need to get your

information to a sender, so they don't create such a transaction in the

first place. I would just drop that part of the proposal.

• DoS potential: who stores these blacklists? If full nodes need to

maintain them so that lightweight clients can request the blacklist list,

you're looking at unbounded memory and bandwidth usage. At the very least

there must be some cost or other finite resource one has to spend to create

a blacklist, to limit the number of blacklist entries active at any given

time.

• This is a network protocol change, which requires coordination between

more software than just Bitcoin Core. If you want a solution of this

nature, please discuss on the mailing list first, and if a good mechanism

is found, propose a BIP and an implementation.

• A better solution to this fundamental problem already exists: if you

worry that you might need to revoke a private key, use the BIP70 payment

protocol, where senders ask for the address to use on the fly, rather than

a static piece of data referring to a private key. This is also cleaner in

term of network architecture: it sends the information directly and solely

to the sender (who is the only one who cares), rather than flooding the

full node network (which mostly doesn't care).

—

Reply to this email directly or view it on GitHub (https://github.com/bitcoin/bitcoin/issues/6175#issuecomment-105255853).

1. Indeed, if you make it a consensus rule, that problem is solved. However, doing such a softfork requires a majority of hashpower to agree with your change, which is potentially uneconomical for them. It still requires wallets to deal with non-confirming transactions to such addresses, and it's much more fundamentally solved by informing the sender not to create such a transaction in the first place.

2. Ok.

3. As per 1), you're now making it a consensus rule, requiring it to be stored by all full nodes in a fast lookup table using potentially unbounded fast memory as well, in addition to the UTXO set.

4. That's one way to implement the soft fork, but now you're not only changing the P2P protocol, but also the network consensus rules, so you will absolutely need to take this discussion to a larger audience than one client. I understand you're just trying to convince people that a problem exists and must be solved (by others), but for this kind of problem, this is really not the place.

5. I'm not suggesting to outlaw send to address entirely, those have their uses, but for the vast majority of your use cases, you already have the receiver online anyway. And ultimately, this is just about informing senders to not send somewhere (either by broadcast messages, by asking a full node through P2P, or by seeing their transactions not confirm in time). It is vastly more efficient to just tell them, than imposing the cost of distributing and maintaining a blacklist by every full node in the network. Furthermore, negotiating transactions as done by BIP70 also has other advantages (such as being able to identify receivers, communicating refund addresses, sending memo messages, and better privacy through reducing address reuse).

If you don't want to write a BIP or at least start discussing the perceived problem on the mailing list, that's fine, but don't expect the contributors to one client to start advocating your proposed solutions to others.

Sorry for closing so brusquely, it seems I misunderstood. I read this as Yet Another Proposal to limit spending from outputs that are marked as stolen. There are, indeed, no fungibility issues with disallowing spends to an address.

Your proposal is would be best implemented as a recipient address blacklist coordinated between wallets. This could have some use, whether the coordination happens over the P2P protocol or not. But take the discussion to the mailing list, this is not the right place for high-level proposals. (also - my suggestion would be to use another term than 'blacklist', as you've noticed it can cause almost aggressive reflex reactions)