- Full nodes advertise a bitcoin address. Users that need to download theblock chain from that node can be encouraged to send a tip to the peersthat 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 fullnode. After all, if you have to pay $15 just to get a copy of theblockchain, that just adds to the already expensive prospect of hosting afull node.

PROS:

As long as you manage to stay online, you should get your money back andmore. 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.

I feel like this would be pointless as the vast majority of users wouldlikely download the blockchain from a node that was not enforcing a tiprequirement as it would seem like unnecessary cost as in protocolâs such asBitTorrent there is no such tips in sharing files and the blockchaindistribution is in eccense the same thing. However perhaps I amunderestimating the generosity of node operators but I feel that adding acost 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 downloadthe block chain from that node can be encouraged to send a tip to the peersthat served them (by % served). Recommended tip of 10mbit should be fine.- A full nodes can *require* a tip to download the blockchain. If theydo, users that don't specify a tip cannot use them.For some people, this may represent a barrier to hosting their own fullnode. After all, if you have to pay $15 just to get a copy of theblockchain, that just adds to the already expensive prospect of hosting afull node.As long as you manage to stay online, you should get your money back andmore. 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 listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

The ones that *could* pay non-mining full nodes are miners/pools, byoutsourcing transaction selection using a different PoW. By doing sothey could buy proof-of-uncensored-selection and proof-of-goodwill for asmall fee.We would allow full nodes to generate and broadcast a templateblock which:* Does not contain a valid header yet* Contains the transaction selection* Contains a coinbase output with a predetermined part of the blockreward (say 0.5%) to themselves* Contains a nonce for PoW of a predetermined currently ASIC resistanthash 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, addingthe rest of the reward and the SHA nonce themselves. That way they wouldset up a competition among full nodes.This would of course be voluntary but provable, so maybe in a pool'sinterest to do this via naming and shaming.Tomasbitcrust

Post by Ben Thompson via bitcoin-devI feel like this would be pointless as the vast majority of userswould likely download the blockchain from a node that was notenforcing a tip requirement as it would seem like unnecessary cost asin protocols such as BitTorrent there is no such tips in sharing filesand the blockchain distribution is in eccense the same thing. Howeverperhaps I am underestimating the generosity of node operators but Ifeel that adding a cost to the blockchain (assuming that all users adda 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 todownload the block chain from that node can be encouraged to send atip to the peers that served them (by % served). Recommended tipof 10mbit should be fine.>>- A full nodes can *require* a tip to download the blockchain. Ifthey do, users that don't specify a tip cannot use them.>>For some people, this may represent a barrier to hosting their ownfull node. After all, if you have to pay $15 just to get a copy ofthe blockchain, that just adds to the already expensive prospect ofAs long as you manage to stay online, you should get your money backand more. This is the an incentive for quality, long term hosting.>> In the long term, this should cause stable nodes to stick aroundlonger. It also discourages "installation spam" attacks on thenetwork.>> Fees for other node operations can be considered if this issuccessful.>>

Strange idea, incentiving people to run full nodes should certainly notdepend on miners, should certainly not involve another wasteful pow andshould certainly not encourage any collusion between participants likeminers are doing (ie full nodes pools for example or miners creatingfull nodes pools)

Post by Tomas via bitcoin-devThe ones that *could* pay non-mining full nodes are miners/pools, byoutsourcing transaction selection using a different PoW. By doing sothey could buy proof-of-uncensored-selection and proof-of-goodwill fora 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 blockreward (say 0.5%) to themselves* Contains a nonce for PoW of a predetermined currently ASIC resistanthash function behind a OP_RETURN.The template with the highest PoW since the last block would beleading. A miner/pool can then choose to use this instead of theirown, adding the rest of the reward and the SHA nonce themselves. Thatway they would set up a competition among full nodes.This would of course be voluntary but provable, so maybe in a pool'sinterest to do this via naming and shaming.Tomasbitcrust

Post by Ben Thompson via bitcoin-devI feel like this would be pointless as the vast majority of userswould likely download the blockchain from a node that was notenforcing a tip requirement as it would seem like unnecessary cost asin protocols such as BitTorrent there is no such tips in sharingfiles and the blockchain distribution is in eccense the same thing.However perhaps I am underestimating the generosity of node operatorsbut I feel that adding a cost to the blockchain (assuming that allusers 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 todownload the block chain from that node can be encouraged to senda tip to the peers that served them (by % served). Recommendedtip 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 theirown full node. After all, if you have to pay $15 just to get acopy of the blockchain, that just adds to the already expensiveprospect of hosting a full node.As long as you manage to stay online, you should get your moneyback and more. This is the an incentive for quality, long termhosting.In the long term, this should cause stable nodes to stick aroundlonger. It also discourages "installation spam" attacks on thenetwork.Fees for other node operations can be considered if this is successful.

Yes, as a whole, but I am sorry, your "tip" proposal is very very verybad as it is, think a little bit more about your latest answer and youwill 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 someproposals that were posted here proposing some system to validate/formatthe blocks for the miners

But, first, the highest priority is to scale the full nodes and thiscannot depend on miners, then once this is done we can imagine otherservices 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'tpretend that they represent the perfect solution but at least it'sdifferent from what we can read , so I think that the core dev teamshould setup a task force/group to solve this quickly now, theaccumulation of strange proposals/workarounds here does not help

Because it's a real question for everybody in the current contextwhether we can trust bitcoin or not, unfortunately the answer currentlytends toward the later, or please explain me why this statement could bewrong

- Full nodes already perform many valuable services, and simplyallowing people to pay for better service is something operators cando now - even without it being baked into bitcoind. Paying foraccess to a higher-speed relay network, for example, is something thatmany 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... whichis really one of the most important things developers can be doing.On Thu, May 4, 2017 at 9:37 AM, Aymeric Vitte via bitcoin-devStrange idea, incentiving people to run full nodes shouldcertainly not depend on miners, should certainly not involveanother wasteful pow and should certainly not encourage anycollusion between participants like miners are doing (ie fullnodes pools for example or miners creating full nodes pools)

Post by Tomas via bitcoin-devThe ones that *could* pay non-mining full nodes are miners/pools,by outsourcing transaction selection using a different PoW. Bydoing so they could buy proof-of-uncensored-selection andproof-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 theblock reward (say 0.5%) to themselves* Contains a nonce for PoW of a predetermined currently ASICresistant hash function behind a OP_RETURN.The template with the highest PoW since the last block would beleading. A miner/pool can then choose to use this instead oftheir own, adding the rest of the reward and the SHA noncethemselves. That way they would set up a competition among fullnodes.This would of course be voluntary but provable, so maybe in apool's interest to do this via naming and shaming.Tomasbitcrust

Post by Ben Thompson via bitcoin-devI feel like this would be pointless as the vast majority ofusers would likely download the blockchain from a node that wasnot enforcing a tip requirement as it would seem likeunnecessary cost as in protocols such as BitTorrent there is nosuch tips in sharing files and the blockchain distribution is ineccense the same thing. However perhaps I am underestimating thegenerosity of node operators but I feel that adding a cost tothe 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 needto download the block chain from that node can be encouragedto 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 theblockchain. If they do, users that don't specify a tipcannot use them.For some people, this may represent a barrier to hostingtheir own full node. After all, if you have to pay $15just to get a copy of the blockchain, that just adds to thealready expensive prospect of hosting a full node.As long as you manage to stay online, you should get yourmoney back and more. This is the an incentive for quality,long term hosting.In the long term, this should cause stable nodes to stickaround longer. It also discourages "installation spam"attacks on the network.Fees for other node operations can be considered if this is successful.

On Wed, May 3, 2017 at 9:08 PM, Erik Aronesty via bitcoin-devThe 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 torun many nodes.

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-devOn Wed, May 3, 2017 at 9:08 PM, Erik Aronesty via bitcoin-devThe 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 torun many nodes.Suggestions like this have come up many times before._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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 apeer? But there would be no actual advantage since download peers areselected based on throughput and actual blocks served.

Also, since this makes the network far more resistant to DDOS attacks, ithas added benefits.

I agree, if lightning networks were baked in, then the tips could be asgranular as "per block downloaded", or even (outlandish seeming now, butmaybe 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" wouldprobably take more time, for example.

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

Sybil attacks seem irrelevant as long as reasonable QOS metrics are storedper peer.

Post by Gregory Maxwell via bitcoin-devOn Wed, May 3, 2017 at 9:08 PM, Erik Aronesty via bitcoin-devThe 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 torun many nodes.Suggestions like this have come up many times before.

I agree with you here, Erik. Greg's standard answer doesn’t apply to yoursuggestion.I think he was a bit too trigger happy because we have seen a lot of similarsuggestions that have the Sybill issue he mentioned.

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 apeer? But there would be no actual advantage since download peers areselected based on throughput and actual blocks served.

I think paying for services is in general a great idea, but one that Bitcoincan much better serve once Lightning is in production. Not only does it enablecost-effective micro-transactions, it also should allow nodes to initiatepayments before they have a synced node (which is something impractical atpresent).

Post by Erik Aronesty via bitcoin-dev- Full nodes advertise a bitcoin address. Users that need to download theblock chain from that node can be encouraged to send a tip to the peersthat 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 fullnode. After all, if you have to pay $15 just to get a copy of theblockchain, that just adds to the already expensive prospect of hosting afull node.As long as you manage to stay online, you should get your money back andmore. 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.

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

It would be great if this protocol was in-place and ready to go in oraround the same time LN is ready. It would incentivize full nodes evenfurther than LN does, and allow the network to be strongly DDOS resistant.

With your tip idea you only encourages 6, and by increasing the number ofnodes, 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 theblockchain based on Proof-of-Unique-Blockchain-Storage (PoUBS), a featurethat RSK will add to incentivize Bitcoin and RSK full nodes. This solutionencourages 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 isbest at.Establishing a channel with each peer is too expensive. But using LN tomicro-pay for high-quality peer services seems like it would aggregate verywell.It would be great if this protocol was in-place and ready to go in oraround the same time LN is ready. It would incentivize full nodes evenfurther than LN does, and allow the network to be strongly DDOS resistant._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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

All you can do with a challenge-response protocol is to prevent honestnodes 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 singlecopy of the blockchain.

I believe best you can do is to force somebody to hold multiple copieslocally on multiple hardware units to not run out of memory I/O whencreating proofs for multiple remote nodes, through using memory heavyfunctions for the proof of storage, forcing quick random access. Howeversomebody willing to put enough RAM in a server rack to hold the fullblockchain could still easily pretend to be multiple regular nodes withindependent copies.

Any kind of attempt at forcing the full copy of the blockchain to be inmemory close to the CPU will either rule out most nodes from passing orwill be cheatable.

Yes you practically can. No proxy can defeat the protocol investing lessmoney than buying storage space to store the blockchain.

Even with challenge-response delays of minutes. That's why it will befully controlled by a RSK smart-contract, with no user intervention.I'm will post about this soon.

Post by Natanael via bitcoin-devDen 8 maj 2017 23:01 skrev "Sergio Demian Lerner via bitcoin-dev" <I'll soon present a solution to encourage full nodes to store theblockchain based on Proof-of-Unique-Blockchain-Storage (PoUBS)Proving that you're holding your own copy of the blockchain, not sharedwith other nodes? I don't think that's possible to do securely. It falls onthat the whole blockchain is both public and static, while any such proofof independence needs to rely on unique capabilities per node.All you can do with a challenge-response protocol is to prevent honestnodes 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 singlecopy of the blockchain.I believe best you can do is to force somebody to hold multiple copieslocally on multiple hardware units to not run out of memory I/O whencreating proofs for multiple remote nodes, through using memory heavyfunctions for the proof of storage, forcing quick random access. Howeversomebody willing to put enough RAM in a server rack to hold the fullblockchain could still easily pretend to be multiple regular nodes withindependent copies.Any kind of attempt at forcing the full copy of the blockchain to be inmemory close to the CPU will either rule out most nodes from passing orwill be cheatable.