Discussion:
[bitcoin-dev] Full node "tip" function
Erik Aronesty via bitcoin-dev
2017-05-03 21:08:35 UTC
Permalink
IDEA:

- Full nodes advertise a bitcoin address. Users that need to download the
block chain from that node can be encouraged to send a tip to the peers
that served them (by % served). Recommended tip of 10mbit should be fine.

- A full nodes can *require* a tip to download the blockchain. If they do,
users that don't specify a tip cannot use them.

CONS:

For some people, this may represent a barrier to hosting their own full
node. After all, if you have to pay $15 just to get a copy of the
blockchain, that just adds to the already expensive prospect of hosting a
full node.

PROS:

As long as you manage to stay online, you should get your money back and
more. This is the an incentive for quality, long term hosting.

In the long term, this should cause stable nodes to stick around longer.
It also discourages "installation spam" attacks on the network.

Fees for other node operations can be considered if this is successful.
Ben Thompson via bitcoin-dev
2017-05-03 21:43:16 UTC
Permalink
I feel like this would be pointless as the vast majority of users would
likely download the blockchain from a node that was not enforcing a tip
requirement as it would seem like unnecessary cost as in protocol​s such as
BitTorrent there is no such tips in sharing files and the blockchain
distribution is in eccense the same thing. However perhaps I am
underestimating the generosity of node operators but I feel that adding a
cost to the blockchain (assuming that all users add a tip requirement)
would lead to centralisation.

On Wed, 3 May 2017, 22:21 Erik Aronesty via bitcoin-dev, <
Post by Erik Aronesty via bitcoin-dev
- Full nodes advertise a bitcoin address. Users that need to download
the block chain from that node can be encouraged to send a tip to the peers
that served them (by % served). Recommended tip of 10mbit should be fine.
- A full nodes can *require* a tip to download the blockchain. If they
do, users that don't specify a tip cannot use them.
For some people, this may represent a barrier to hosting their own full
node. After all, if you have to pay $15 just to get a copy of the
blockchain, that just adds to the already expensive prospect of hosting a
full node.
As long as you manage to stay online, you should get your money back and
more. This is the an incentive for quality, long term hosting.
In the long term, this should cause stable nodes to stick around longer.
It also discourages "installation spam" attacks on the network.
Fees for other node operations can be considered if this is successful.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Tomas via bitcoin-dev
2017-05-04 10:38:29 UTC
Permalink
The ones that *could* pay non-mining full nodes are miners/pools, by
outsourcing transaction selection using a different PoW. By doing so
they could buy proof-of-uncensored-selection and proof-of-goodwill for a
small fee.
We would allow full nodes to generate and broadcast a template
block which:
* Does not contain a valid header yet
* Contains the transaction selection
* Contains a coinbase output with a predetermined part of the block
reward (say 0.5%) to themselves* Contains a nonce for PoW of a predetermined currently ASIC resistant
hash function behind a OP_RETURN.
The template with the highest PoW since the last block would be leading.
A miner/pool can then choose to use this instead of their own, adding
the rest of the reward and the SHA nonce themselves. That way they would
set up a competition among full nodes.
This would of course be voluntary but provable, so maybe in a pool's
interest to do this via naming and shaming.
Tomas
bitcrust
Post by Ben Thompson via bitcoin-dev
I feel like this would be pointless as the vast majority of users
would likely download the blockchain from a node that was not
enforcing a tip requirement as it would seem like unnecessary cost as
in protocols such as BitTorrent there is no such tips in sharing files
and the blockchain distribution is in eccense the same thing. However
perhaps I am underestimating the generosity of node operators but I
feel that adding a cost to the blockchain (assuming that all users add
a tip requirement) would lead to centralisation.>
On Wed, 3 May 2017, 22:21 Erik Aronesty via bitcoin-dev, <bitcoin-
Post by Erik Aronesty via bitcoin-dev
- Full nodes advertise a bitcoin address. Users that need to
download the block chain from that node can be encouraged to send a
tip to the peers that served them (by % served). Recommended tip
of 10mbit should be fine.>>
- A full nodes can *require* a tip to download the blockchain. If
they do, users that don't specify a tip cannot use them.>>
For some people, this may represent a barrier to hosting their own
full node. After all, if you have to pay $15 just to get a copy of
the blockchain, that just adds to the already expensive prospect of
As long as you manage to stay online, you should get your money back
and more. This is the an incentive for quality, long term hosting.>> In the long term, this should cause stable nodes to stick around
longer. It also discourages "installation spam" attacks on the
network.>> Fees for other node operations can be considered if this is
successful.>>
Aymeric Vitte via bitcoin-dev
2017-05-04 13:37:43 UTC
Permalink
Strange idea, incentiving people to run full nodes should certainly not
depend on miners, should certainly not involve another wasteful pow and
should certainly not encourage any collusion between participants like
miners are doing (ie full nodes pools for example or miners creating
full nodes pools)
Post by Tomas via bitcoin-dev
The ones that *could* pay non-mining full nodes are miners/pools, by
outsourcing transaction selection using a different PoW. By doing so
they could buy proof-of-uncensored-selection and proof-of-goodwill for
a small fee.
We would allow full nodes to generate and broadcast a template block
* Does not contain a valid header yet
* Contains the transaction selection
* Contains a coinbase output with a predetermined part of the block
reward (say 0.5%) to themselves
* Contains a nonce for PoW of a predetermined currently ASIC resistant
hash function behind a OP_RETURN.
The template with the highest PoW since the last block would be
leading. A miner/pool can then choose to use this instead of their
own, adding the rest of the reward and the SHA nonce themselves. That
way they would set up a competition among full nodes.
This would of course be voluntary but provable, so maybe in a pool's
interest to do this via naming and shaming.
Tomas
bitcrust
Post by Ben Thompson via bitcoin-dev
I feel like this would be pointless as the vast majority of users
would likely download the blockchain from a node that was not
enforcing a tip requirement as it would seem like unnecessary cost as
in protocols such as BitTorrent there is no such tips in sharing
files and the blockchain distribution is in eccense the same thing.
However perhaps I am underestimating the generosity of node operators
but I feel that adding a cost to the blockchain (assuming that all
users add a tip requirement) would lead to centralisation.
On Wed, 3 May 2017, 22:21 Erik Aronesty via bitcoin-dev,
- Full nodes advertise a bitcoin address. Users that need to
download the block chain from that node can be encouraged to send
a tip to the peers that served them (by % served). Recommended
tip of 10mbit should be fine.
- A full nodes can *require* a tip to download the blockchain.
If they do, users that don't specify a tip cannot use them.
For some people, this may represent a barrier to hosting their
own full node. After all, if you have to pay $15 just to get a
copy of the blockchain, that just adds to the already expensive
prospect of hosting a full node.
As long as you manage to stay online, you should get your money
back and more. This is the an incentive for quality, long term
hosting.
In the long term, this should cause stable nodes to stick around
longer. It also discourages "installation spam" attacks on the
network.
Fees for other node operations can be considered if this is successful.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Aymeric Vitte via bitcoin-dev
2017-05-04 14:31:11 UTC
Permalink
Yes, as a whole, but I am sorry, your "tip" proposal is very very very
bad as it is, think a little bit more about your latest answer and you
will understand why

I am a bit perplexed sometimes about what is proposed on this list

Adding services paid by the miners is not a bad idea, like some
proposals that were posted here proposing some system to validate/format
the blocks for the miners

But, first, the highest priority is to scale the full nodes and this
cannot depend on miners, then once this is done we can imagine other
services on top of it paid by the miners or others (+lightning & co)

I have already explained many times my thoughts on the subject, I don't
pretend that they represent the perfect solution but at least it's
different from what we can read , so I think that the core dev team
should setup a task force/group to solve this quickly now, the
accumulation of strange proposals/workarounds here does not help

Because it's a real question for everybody in the current context
whether we can trust bitcoin or not, unfortunately the answer currently
tends toward the later, or please explain me why this statement could be
wrong
- Full nodes already perform many valuable services, and simply
allowing people to pay for better service is something operators can
do now - even without it being baked into bitcoind. Paying for
access to a higher-speed relay network, for example, is something that
many operators would do.
- Baking in the ability to add service fees could make more people
*want* to run more high quality, highly available full nodes... which
is really one of the most important things developers can be doing.
On Thu, May 4, 2017 at 9:37 AM, Aymeric Vitte via bitcoin-dev
Strange idea, incentiving people to run full nodes should
certainly not depend on miners, should certainly not involve
another wasteful pow and should certainly not encourage any
collusion between participants like miners are doing (ie full
nodes pools for example or miners creating full nodes pools)
Post by Tomas via bitcoin-dev
The ones that *could* pay non-mining full nodes are miners/pools,
by outsourcing transaction selection using a different PoW. By
doing so they could buy proof-of-uncensored-selection and
proof-of-goodwill for a small fee.
We would allow full nodes to generate and broadcast a template
* Does not contain a valid header yet
* Contains the transaction selection
* Contains a coinbase output with a predetermined part of the
block reward (say 0.5%) to themselves
* Contains a nonce for PoW of a predetermined currently ASIC
resistant hash function behind a OP_RETURN.
The template with the highest PoW since the last block would be
leading. A miner/pool can then choose to use this instead of
their own, adding the rest of the reward and the SHA nonce
themselves. That way they would set up a competition among full
nodes.
This would of course be voluntary but provable, so maybe in a
pool's interest to do this via naming and shaming.
Tomas
bitcrust
Post by Ben Thompson via bitcoin-dev
I feel like this would be pointless as the vast majority of
users would likely download the blockchain from a node that was
not enforcing a tip requirement as it would seem like
unnecessary cost as in protocols such as BitTorrent there is no
such tips in sharing files and the blockchain distribution is in
eccense the same thing. However perhaps I am underestimating the
generosity of node operators but I feel that adding a cost to
the blockchain (assuming that all users add a tip requirement)
would lead to centralisation.
On Wed, 3 May 2017, 22:21 Erik Aronesty via bitcoin-dev,
- Full nodes advertise a bitcoin address. Users that need
to download the block chain from that node can be encouraged
to send a tip to the peers that served them (by % served).
Recommended tip of 10mbit should be fine.
- A full nodes can *require* a tip to download the
blockchain. If they do, users that don't specify a tip
cannot use them.
For some people, this may represent a barrier to hosting
their own full node. After all, if you have to pay $15
just to get a copy of the blockchain, that just adds to the
already expensive prospect of hosting a full node.
As long as you manage to stay online, you should get your
money back and more. This is the an incentive for quality,
long term hosting.
In the long term, this should cause stable nodes to stick
around longer. It also discourages "installation spam"
attacks on the network.
Fees for other node operations can be considered if this is successful.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
<https://github.com/Ayms/zcash-wallets>
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
<https://github.com/Ayms/bitcoin-wallets>
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
<https://github.com/Ayms/torrent-live>
node-Tor : https://www.github.com/Ayms/node-Tor
<https://www.github.com/Ayms/node-Tor>
GitHub : https://www.github.com/Ayms
_______________________________________________ bitcoin-dev
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Gregory Maxwell via bitcoin-dev
2017-05-03 21:53:07 UTC
Permalink
On Wed, May 3, 2017 at 9:08 PM, Erik Aronesty via bitcoin-dev
The primary result would be paying people to sybil attack the network.
It's far cheaper to run one node behind thousands of IPs than it is to
run many nodes.

Suggestions like this have come up many times before.
Matt Corallo via bitcoin-dev
2017-05-03 22:03:43 UTC
Permalink
If we ever have a problem getting blocks, we could consider adding something to pay to receive historical blocks but luckily that isn't a problem we have today - the available connection slots and bandwidth on the network today appears to be more than sufficient to saturate nearly any fully-validating node.
Post by Gregory Maxwell via bitcoin-dev
On Wed, May 3, 2017 at 9:08 PM, Erik Aronesty via bitcoin-dev
The primary result would be paying people to sybil attack the network.
It's far cheaper to run one node behind thousands of IPs than it is to
run many nodes.
Suggestions like this have come up many times before.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Erik Aronesty via bitcoin-dev
2017-05-04 13:15:02 UTC
Permalink
Post by Gregory Maxwell via bitcoin-dev
Greg
The primary result would be paying people to sybil attack the network.
I cannot imagine the benefit to replicating an ip address in this case,
except maybe you think that you would be more likely to be selected as a
peer? But there would be no actual advantage since download peers are
selected based on throughput and actual blocks served.

Also, since this makes the network far more resistant to DDOS attacks, it
has added benefits.
Post by Gregory Maxwell via bitcoin-dev
paying for services is in general a great idea, but one that Bitcoin
can much better serve once Lightning is in production.
I agree, if lightning networks were baked in, then the tips could be as
granular as "per block downloaded", or even (outlandish seeming now, but
maybe not in a future where there is a "public rpc api") "per rpc call".
Miners and business users would certainly pay for high quality services.
Spinning up new nodes without a tip and relying on the "free network" would
probably take more time, for example.

I suspect that if income were even a small possibility the number of full
nodes would vastly increase.

Sybil attacks seem irrelevant as long as reasonable QOS metrics are stored
per peer.
Post by Gregory Maxwell via bitcoin-dev
On Wed, May 3, 2017 at 9:08 PM, Erik Aronesty via bitcoin-dev
The primary result would be paying people to sybil attack the network.
It's far cheaper to run one node behind thousands of IPs than it is to
run many nodes.
Suggestions like this have come up many times before.
Tom Zander via bitcoin-dev
2017-05-04 14:57:59 UTC
Permalink
I agree with you here, Erik. Greg's standard answer doesn’t apply to your
suggestion.
I think he was a bit too trigger happy because we have seen a lot of similar
suggestions that have the Sybill issue he mentioned.
Post by Erik Aronesty via bitcoin-dev
Post by Gregory Maxwell via bitcoin-dev
Greg
The primary result would be paying people to sybil attack the network.
I cannot imagine the benefit to replicating an ip address in this case,
except maybe you think that you would be more likely to be selected as a
peer? But there would be no actual advantage since download peers are
selected based on throughput and actual blocks served.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
Luke Dashjr via bitcoin-dev
2017-05-03 23:21:13 UTC
Permalink
I think paying for services is in general a great idea, but one that Bitcoin
can much better serve once Lightning is in production. Not only does it enable
cost-effective micro-transactions, it also should allow nodes to initiate
payments before they have a synced node (which is something impractical at
present).
Post by Erik Aronesty via bitcoin-dev
- Full nodes advertise a bitcoin address. Users that need to download the
block chain from that node can be encouraged to send a tip to the peers
that served them (by % served). Recommended tip of 10mbit should be fine.
- A full nodes can *require* a tip to download the blockchain. If they do,
users that don't specify a tip cannot use them.
For some people, this may represent a barrier to hosting their own full
node. After all, if you have to pay $15 just to get a copy of the
blockchain, that just adds to the already expensive prospect of hosting a
full node.
As long as you manage to stay online, you should get your money back and
more. This is the an incentive for quality, long term hosting.
In the long term, this should cause stable nodes to stick around longer.
It also discourages "installation spam" attacks on the network.
Fees for other node operations can be considered if this is successful.
Erik Aronesty via bitcoin-dev
2017-05-04 19:28:10 UTC
Permalink
This is actually LN’s killer use case - not buying coffees ;)
Yes, micro-payments for online network services is precisely what LN is
best at.

Establishing a channel with each peer is too expensive. But using LN to
micro-pay for high-quality peer services seems like it would aggregate very
well.

It would be great if this protocol was in-place and ready to go in or
around the same time LN is ready. It would incentivize full nodes even
further than LN does, and allow the network to be strongly DDOS resistant.
Sergio Demian Lerner via bitcoin-dev
2017-05-08 21:00:10 UTC
Permalink
A full node provides several services to the network:

1•Broadcasts blocks (public service)
2•Broadcasts transactions (public/private service)
3•Increases privacy by hiding other node’s IPs
4•Increases network security by protecting it from global DoS.
5•Provides information filtering services to SPV nodes.
6•Provides historic blockchain and state information to new nodes.

With your tip idea you only encourages 6, and by increasing the number of
nodes, also 3 and 4.
The services 1 and 2 cannot be encouraged by tips.

However, it's a good way to start.

There was a way to encourage 2 I described in 2013. (
https://bitcointalk.org/index.php?topic=385528.msg4155300#msg4155300)

I'll soon present a solution to encourage full nodes to store the
blockchain based on Proof-of-Unique-Blockchain-Storage (PoUBS), a feature
that RSK will add to incentivize Bitcoin and RSK full nodes. This solution
encourages 6.



On Thu, May 4, 2017 at 4:28 PM, Erik Aronesty via bitcoin-dev <
This is actually LN’s killer use case - not buying coffees ;)
Yes, micro-payments for online network services is precisely what LN is
best at.
Establishing a channel with each peer is too expensive. But using LN to
micro-pay for high-quality peer services seems like it would aggregate very
well.
It would be great if this protocol was in-place and ready to go in or
around the same time LN is ready. It would incentivize full nodes even
further than LN does, and allow the network to be strongly DDOS resistant.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Natanael via bitcoin-dev
2017-05-08 21:44:41 UTC
Permalink
Den 8 maj 2017 23:01 skrev "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-***@lists.linuxfoundation.org>:

I'll soon present a solution to encourage full nodes to store the
blockchain based on Proof-of-Unique-Blockchain-Storage (PoUBS)


Proving that you're holding your own copy of the blockchain, not shared
with other nodes? I don't think that's possible to do securely. It falls on
that the whole blockchain is both public and static, while any such proof
of independence needs to rely on unique capabilities per node.

All you can do with a challenge-response protocol is to prevent honest
nodes from being unwitting backends to dishonest transparent proxy nodes
(by binding the challenge to cryptographic node identities).

Even latency bounding protocols can't stop you from putting multiple
*seemingly independent* nodes in front of the same backend with one single
copy of the blockchain.

I believe best you can do is to force somebody to hold multiple copies
locally on multiple hardware units to not run out of memory I/O when
creating proofs for multiple remote nodes, through using memory heavy
functions for the proof of storage, forcing quick random access. However
somebody willing to put enough RAM in a server rack to hold the full
blockchain could still easily pretend to be multiple regular nodes with
independent copies.

Any kind of attempt at forcing the full copy of the blockchain to be in
memory close to the CPU will either rule out most nodes from passing or
will be cheatable.
Sergio Demian Lerner via bitcoin-dev
2017-05-08 22:15:48 UTC
Permalink
Yes you practically can. No proxy can defeat the protocol investing less
money than buying storage space to store the blockchain.

Even with challenge-response delays of minutes. That's why it will be
fully controlled by a RSK smart-contract, with no user intervention.
I'm will post about this soon.
Post by Natanael via bitcoin-dev
Den 8 maj 2017 23:01 skrev "Sergio Demian Lerner via bitcoin-dev" <
I'll soon present a solution to encourage full nodes to store the
blockchain based on Proof-of-Unique-Blockchain-Storage (PoUBS)
Proving that you're holding your own copy of the blockchain, not shared
with other nodes? I don't think that's possible to do securely. It falls on
that the whole blockchain is both public and static, while any such proof
of independence needs to rely on unique capabilities per node.
All you can do with a challenge-response protocol is to prevent honest
nodes from being unwitting backends to dishonest transparent proxy nodes
(by binding the challenge to cryptographic node identities).
Even latency bounding protocols can't stop you from putting multiple
*seemingly independent* nodes in front of the same backend with one single
copy of the blockchain.
I believe best you can do is to force somebody to hold multiple copies
locally on multiple hardware units to not run out of memory I/O when
creating proofs for multiple remote nodes, through using memory heavy
functions for the proof of storage, forcing quick random access. However
somebody willing to put enough RAM in a server rack to hold the full
blockchain could still easily pretend to be multiple regular nodes with
independent copies.
Any kind of attempt at forcing the full copy of the blockchain to be in
memory close to the CPU will either rule out most nodes from passing or
will be cheatable.
Loading...