Bitcoind can already report UserAgent via a RPC call. Let's add another option so node operator can set up a donation address for running this node. This can be an extra option in the config and if set it will be reported via a separate RPC command.
This would make activities like https://getaddr.bitnodes.io/nodes/incentive/ much more easier to setup (adding one line to config vs setting up an extra http server).
I don't think this makes much sense. a) This would encourage address reuse (https://en.bitcoin.it/wiki/Address_reuse) b) RPC should not be open to the public INet (https://bitcoin.org/en/developer-reference#remote-procedure-calls-rpcs)
a) Address reuse is perfectly fine for donations.
b) For some strange reason nodes already advertise their version/useragent via a RPC call. I am not proposing basically the same mechanism for advertising donation address.
Posting Reddit thread to show there is really a demand for this feature: https://www.reddit.com/r/Bitcoin/comments/2vf6ed/bitnodes_incentive_program/
for b) you probably mean the "version" p2p message (https://en.bitcoin.it/wiki/Protocol_documentation#version)?
IMO a such feature should/can be implemented outside of bitcoin core. The bitnodes.io approche https://getaddr.bitnodes.io/api/#node-bitcoin-address makes much more sense to me (in case of flexibility and security).
Setting up a secure web server to add the possibility to response some static infos sounds more easy then changing things in the core of bitcoin.
Proposed change should be max 10 lines of code addition to Bitcoin Core. Forcing all node operators to setup two servers instead of one is audacious.
Why not put it directly in the User agent in some form? E.g. /Satoshi:0.9.3:1CXPSdTv1spC68p42wFp52vMj947nbBhML/
Let's propose a patch to change user agent reported (it would be nice to have the ability to hide the real user agent from public without changing the source) and publish the method to include the address there instead...
Why not put it directly in the User agent in some form?
That was my original idea, but then I saw a lot of hardcoded checks for user agents in the codebase. Maybe if we reworked these checks ...
But I don't think that possibility to change user agent to some completely random string is really worth it and can bring more damage than gains.
Changing the user_agent within the version message should be save.
See also: https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki
Bitcoin core will limit the string to 256 chars (https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L3507).
I don't see any further check agains this "user agent" string. Don't mix it up with the 4 byte protocol version.
But i still have concerns if it should be possible to link nodes to addresses.
Maybe a patch that adds the possibility to change the "user agent" text to whatever the user likes could make it into the master. Search after const std::string CLIENT_NAME.
So it seems the things that needs to be changed/fixed are:
donation=address to the bitcoin.conf file/Satoshi:0.9.3/address/ instead of /Satoshi:0.9.3/$) from this check: https://github.com/bitcoin/bitcoin/blob/d48ce48093faf1a0778b424397a2879a93e5fb5e/contrib/seeds/makeseeds.py#L27Are we in agreement here?
Maybe a patch that adds the possibility to change the "user agent" text to whatever the user likes could make it into the master.
I agree with this.
I do not like Pavol’s proposal about donation option (although I agree that it would make this particular use-case elegant).
And I hope web authors sanitize User-agent strings before using it in their web pages as we do before printing it in the debug.log ;-)
NACK
This sets up for risky network behavior like people attempting to make donations to the whole network, which incentivizes malicious actors with botnets and abnormally large IP allocations to farm with sybil nodes. It's trivial to make a "node" which functions enough to present a donation address and relay it's own addr rumors but does absolutely nothing else.
I do not like Pavol’s proposal about donation option
Well, we can call it something like user-agent-extension, I don't really care about the option name.
Do you have any usecase for modifying the whole user-agent as opposed to just appending some info without changing the first part of the user-agent? To me it does not make sense like in the case of browser user-agent, but maybe I am missing something.
A large portion of the network lies about it's string subver anyway.
FWIW there already is a function FormatSubVersion which handles extra data (vector comments) and adds them to the version string:
Comments are just not used (except for the unit tests).
A large portion of the network lies about it's string subver anyway.
What is the motivation to do this? Can you support your claim with some evidence?
What is the motivation to do this?
To hide that they're not /Satoshi/.
Can you support your claim with some evidence?
Not beyond digging around the behavior of nodes connected to mine and determining they are most certainly not Bitcoin Core. Take a look at one of your own listening nodes and you'll see that some portion (10-20% in my case) of them never relay any inventory to you. Some have odd behavior like aggressively reconnecting after a ban (Bitcoin Core does not do this), relaying malformed addr rumors, or presenting slightly non-standard subversion strings.
No need to use addresses for this, could just do a payment request over the p2p interface. I think the MITM risk is a concern though...
Do you have any usecase for modifying the whole user-agent as opposed to just appending some info without changing the first part of the user-agent? To me it does not make sense like in the case of browser user-agent, but maybe I am missing something.
Look at it also from “server”/full node side. The node is announcing its full version details to the network/its peers. It would be nice to be able to turn this version announcement off (something like ProductOnly to Apache httpd’s ServerTokens - and proudly announcing using of Bitcoin Core/Satoshi) or change the “User Agent” completely. People do so anyway and we should allow this for users of our builds as well.
And the name of such option can be user-agent (as used in UI) or subversion.
Back to the “donation address” for full node. As full node has a static IP address, what about using some form of IN TXT or other entry (we should propose IN BTC anyway ;-) in the reverse DNS zone?
As full node has a static IP address, what about using some form of IN TXT or other entry (we should propose IN BTC anyway ;-) in the reverse DNS zone?
I would bet most listening nodes can not control their DNS records at all.
I think a method to add optional contact information to a node could make sense, in the same way as Tor, e.g. to make it possible to contact admins of malfunctioning or misconfigured nodes.
Adding a donation address seems unwise though; due to stated address reuse issue, but also because of MItM reasons. This was the main the reason pay-to-IP was removed in the first place, which was a superior way of doing this: https://en.bitcoin.it/wiki/IP_Transactions
This seems really ill advised for the reasons mentioned. Also associating static reused addresses with IP addresses will more or less completely deanonymize the vast majority of the users who are not very well informed with how the system works enough to take the burdensome additional steps to protect their privacy. It will also incentivize spidering to collect this identifying information, in addition to the the above concerns about incentivizing additional sibyl nodes.
What if the node operator can set up a stealth address, as a donation address, for running his/hers node?
https://wiki.unsystem.net/en/index.php/DarkWallet/Alpha#Stealth
That might make sense, if Bitcoin Core supported stealth addresses at all, or if there was at least a BIP standard for them.
It would address the privacy part at least, though not the incentivizing sibyl / MITM attacks against the network part. A stealth address isn't the right tool in this case either: they have a considerable amount of overhead, and you have interaction with the source so, you would really just want a one use BIP32 public chain address (e.g. an ordinary address which is 'generated' on demand
Edit: Oh actually I was being blond: even that only partially addresses the privacy issue.. it still makes it easy to build IP -> address maps, it just costs a bit (you have to pay some bit dust to the address you fetched / negotiated).
I think you completely forgot about the fact that the user who sets up the address using this method is OK with deanonymizing transactions on this address.
Deanonymization doesn't affect just him, but everyone in the Bitcoin ecosystem.
@prusnak He may be perfectly fine with "deanonymizing transactions" on that particular address, but much to his surprise without measures which are costly, unusual, and not available in popular wallets doing so will actually deanonymize all his transactions with high probability. It also hurts the privacy of everyone he has transacted with in the past or future-- who get no say in this, and his loss of privacy potentially increases systemic risk for the ecosystem (e.g. nodes being ordered to not process transactions identified as being connected to a particular user or geography).
If privacy were the only issue here it might be arguably that it wasn't the worst privacy problem in Bitcoin... but it is an additional argument against it that adds to the other ones enumerated above.
So basically you are saying that everyone who mines and sends his payouts to the same Bitcoin addresses (60% of the miners and thus mined bitcoins) is hurting the privacy of everyone? I'm having big trouble understanding what is the issue here ...
In the case of miners, it is much better, because of the coinbase transactions (no previous outputs used as inputs).
What about putting (your/some) e-mail in the user-agent? What about encoding some one-time code in the user-agent (like google verification) and removing it after verification?
Since Bitcoin Core does not support stealth addresses, another wallet would have to be used for collecting and handling the coins. This was some of the reason I had for suggesting stealth addresses.
@paveljanik In the case of miners, it is much better, because of the coinbase transactions (no previous outputs used as inputs)
That's not true for most of the pools. They use internal payout wallets and are not paying out via coinbase transactions directly.
Just wondering. It could be a deterministic wallet "root public key", and the client would return a new address each time it was requested. Makes any sense?
Just wondering. It could be a deterministic wallet "root public key", and the client would return a new address each time it was requested. Makes any sense?
That would create a lot of gaps in the chains rendering this method quite unusable.
At the very least, solving the MitM problem would require host keys and an authenticated P2P protocol, and the ability to -addnode peers with a known host key. If you do that, you could just as well share a tipping address along with the host identity...
Here is an off the cuff proposal, not thought through at all, go knock it down.
We could use Lighthouse combined with group signatures for this sort of thing, the scheme I'm thinking about is:
Thus, there is no correlation between the Bitcoin address used to raise the money and the IP address of the new node, but it's still proven that the node was funded by the contract.
Obviously bitcoind would need some fairly complex new code for this, and responding to the challenges would have to be CPU prioritised lower than actually handling network traffic etc. There are DoS issues to think through. But I think it would satisfy the constraints and avoid a centralised third party who holds the bitcoins for distribution because the contract would pay the node operators directly. The central authority just checks for sybils and admits people into the scheme.
The main downside is of course complexity. I think realistically such a scheme would have to be a feature of Lighthouse itself. The project file format could be extended to indicate that this is a node-support contract, and then the app could just perform some IP group signature challenges from time to time when it's started and inform the user if a node is unable to respond to the challenge i.e. someone is in violation of the (legal/social) contract.
We can imagine several extensions of the scheme. For instance instead of paying node operators up front, the contract pays to multisig outputs that are controlled by a dispute mediator who measures uptime, performance and protocol compliance of the nodes.
Please see, for what I think is previous related discussion of this sort of issue, Issue [#4079](/bitcoin-bitcoin/4079/).
It sounds as though these ideas have been discussed before and were not well accepted by the developer community. With the exception of Lighthouse and similar concepts which I think will gain broader acceptance as time goes on. I hope that perhaps this new discussion might find a way to get giving, or microdonation ideas better integrated into bitcoin.
Central to this discussion is the question, should a bitcoin address be tied directly to a node? I think that development effort should move more away from doing that. Which is to say, development efforts should protect people from having their node associated with any particular address (loosely expressed, the deanonymization concern).
Edit: See also Pull Request [#253](/bitcoin-bitcoin/253/).
@sandakersmann @gmaxwell Regarding the comment above on stealth, I am curious as to why the situation has run on so long with respect to the matter of why BIP63 is not done and why op_return issues appear to be unresolved.
@ABISprotocol OP_RETURN was bumped back to 80 bytes.