* [bitcoin-dev] Full node "tip" function
@ 2017-05-03 21:08 Erik Aronesty
2017-05-03 21:43 ` Ben Thompson
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Erik Aronesty @ 2017-05-03 21:08 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 946 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1160 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [bitcoin-dev] Full node "tip" function 2017-05-03 21:08 [bitcoin-dev] Full node "tip" function Erik Aronesty @ 2017-05-03 21:43 ` Ben Thompson 2017-05-04 10:38 ` Tomas 2017-05-03 21:53 ` Gregory Maxwell 2017-05-03 23:21 ` Luke Dashjr 2 siblings, 1 reply; 15+ messages in thread From: Ben Thompson @ 2017-05-03 21:43 UTC (permalink / raw) To: Erik Aronesty, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1857 bytes --] 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-dev@lists•linuxfoundation.org> wrote: > 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. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 2465 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Full node "tip" function 2017-05-03 21:43 ` Ben Thompson @ 2017-05-04 10:38 ` Tomas 2017-05-04 13:37 ` Aymeric Vitte 0 siblings, 1 reply; 15+ messages in thread From: Tomas @ 2017-05-04 10:38 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2711 bytes --] 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 On Wed, May 3, 2017, at 23:43, Ben Thompson via bitcoin-dev wrote: > 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- > dev@lists•linuxfoundation.org> wrote:>> 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.>> [-- Attachment #2: Type: text/html, Size: 3749 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Full node "tip" function 2017-05-04 10:38 ` Tomas @ 2017-05-04 13:37 ` Aymeric Vitte 2017-05-04 13:47 ` Erik Aronesty 0 siblings, 1 reply; 15+ messages in thread From: Aymeric Vitte @ 2017-05-04 13:37 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 3959 bytes --] 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) Le 04/05/2017 à 12:38, Tomas via bitcoin-dev a écrit : > 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 > > On Wed, May 3, 2017, at 23:43, Ben Thompson via bitcoin-dev wrote: >> 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-dev@lists•linuxfoundation.org >> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: >> >> 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. >> > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > 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 [-- Attachment #2: Type: text/html, Size: 7690 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Full node "tip" function 2017-05-04 13:37 ` Aymeric Vitte @ 2017-05-04 13:47 ` Erik Aronesty 2017-05-04 14:31 ` Aymeric Vitte 0 siblings, 1 reply; 15+ messages in thread From: Erik Aronesty @ 2017-05-04 13:47 UTC (permalink / raw) To: Aymeric Vitte; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4718 bytes --] - 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 < bitcoin-dev@lists•linuxfoundation.org> wrote: > 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) > > Le 04/05/2017 à 12:38, Tomas via bitcoin-dev a écrit : > > 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 > > On Wed, May 3, 2017, at 23:43, Ben Thompson via bitcoin-dev wrote: > > 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-dev@lists•linuxfoundation.org> wrote: > > 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. > > > > > _______________________________________________ > bitcoin-dev mailing listbitcoin-dev@lists•linuxfoundation.orghttps://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 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 9662 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Full node "tip" function 2017-05-04 13:47 ` Erik Aronesty @ 2017-05-04 14:31 ` Aymeric Vitte 0 siblings, 0 replies; 15+ messages in thread From: Aymeric Vitte @ 2017-05-04 14:31 UTC (permalink / raw) To: Erik Aronesty, Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 7417 bytes --] 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 Le 04/05/2017 à 15:47, Erik Aronesty a écrit : > - 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 > <bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: > > 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) > > > Le 04/05/2017 à 12:38, Tomas via bitcoin-dev a écrit : >> 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 >> >> On Wed, May 3, 2017, at 23:43, Ben Thompson via bitcoin-dev wrote: >>> 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-dev@lists•linuxfoundation.org >>> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: >>> >>> 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. >>> >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> <mailto:bitcoin-dev@lists•linuxfoundation.org> >> 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 > mailing list bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org> > 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 [-- Attachment #2: Type: text/html, Size: 15614 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Full node "tip" function 2017-05-03 21:08 [bitcoin-dev] Full node "tip" function Erik Aronesty 2017-05-03 21:43 ` Ben Thompson @ 2017-05-03 21:53 ` Gregory Maxwell 2017-05-03 22:03 ` Matt Corallo 2017-05-04 13:15 ` Erik Aronesty 2017-05-03 23:21 ` Luke Dashjr 2 siblings, 2 replies; 15+ messages in thread From: Gregory Maxwell @ 2017-05-03 21:53 UTC (permalink / raw) To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion On Wed, May 3, 2017 at 9:08 PM, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > CONS: 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Full node "tip" function 2017-05-03 21:53 ` Gregory Maxwell @ 2017-05-03 22:03 ` Matt Corallo 2017-05-04 13:15 ` Erik Aronesty 1 sibling, 0 replies; 15+ messages in thread From: Matt Corallo @ 2017-05-03 22:03 UTC (permalink / raw) To: Gregory Maxwell, Gregory Maxwell via bitcoin-dev, Erik Aronesty Cc: Bitcoin Protocol Discussion 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. On May 3, 2017 5:53:07 PM EDT, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >On Wed, May 3, 2017 at 9:08 PM, Erik Aronesty via bitcoin-dev ><bitcoin-dev@lists•linuxfoundation.org> wrote: >> CONS: > >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 >bitcoin-dev@lists•linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Full node "tip" function 2017-05-03 21:53 ` Gregory Maxwell 2017-05-03 22:03 ` Matt Corallo @ 2017-05-04 13:15 ` Erik Aronesty 2017-05-04 14:57 ` Tom Zander 1 sibling, 1 reply; 15+ messages in thread From: Erik Aronesty @ 2017-05-04 13:15 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1604 bytes --] > 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. > Luke: > 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. On Wed, May 3, 2017 at 5:53 PM, Gregory Maxwell <greg@xiph•org> wrote: > On Wed, May 3, 2017 at 9:08 PM, Erik Aronesty via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > CONS: > > 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. > [-- Attachment #2: Type: text/html, Size: 2190 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Full node "tip" function 2017-05-04 13:15 ` Erik Aronesty @ 2017-05-04 14:57 ` Tom Zander 0 siblings, 0 replies; 15+ messages in thread From: Tom Zander @ 2017-05-04 14:57 UTC (permalink / raw) To: bitcoin-dev, Erik Aronesty via bitcoin-dev 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. On Thursday, 4 May 2017 15:15:02 CEST Erik Aronesty via bitcoin-dev wrote: > > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Full node "tip" function 2017-05-03 21:08 [bitcoin-dev] Full node "tip" function Erik Aronesty 2017-05-03 21:43 ` Ben Thompson 2017-05-03 21:53 ` Gregory Maxwell @ 2017-05-03 23:21 ` Luke Dashjr [not found] ` <9335E0E0-F9D6-41AD-9FF9-5CDF2B1AF1F7@gmail.com> 2 siblings, 1 reply; 15+ messages in thread From: Luke Dashjr @ 2017-05-03 23:21 UTC (permalink / raw) To: bitcoin-dev, Erik Aronesty 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). On Wednesday 03 May 2017 9:08:35 PM Erik Aronesty via bitcoin-dev wrote: > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <9335E0E0-F9D6-41AD-9FF9-5CDF2B1AF1F7@gmail.com>]
* Re: [bitcoin-dev] Full node "tip" function [not found] ` <9335E0E0-F9D6-41AD-9FF9-5CDF2B1AF1F7@gmail.com> @ 2017-05-04 19:28 ` Erik Aronesty 2017-05-08 21:00 ` Sergio Demian Lerner 0 siblings, 1 reply; 15+ messages in thread From: Erik Aronesty @ 2017-05-04 19:28 UTC (permalink / raw) To: Eric Lombrozo; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 542 bytes --] > > 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. [-- Attachment #2: Type: text/html, Size: 783 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Full node "tip" function 2017-05-04 19:28 ` Erik Aronesty @ 2017-05-08 21:00 ` Sergio Demian Lerner 2017-05-08 21:44 ` Natanael 0 siblings, 1 reply; 15+ messages in thread From: Sergio Demian Lerner @ 2017-05-08 21:00 UTC (permalink / raw) To: Erik Aronesty; +Cc: Eric Lombrozo, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1827 bytes --] 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 < bitcoin-dev@lists•linuxfoundation.org> wrote: > 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 > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 2794 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Full node "tip" function 2017-05-08 21:00 ` Sergio Demian Lerner @ 2017-05-08 21:44 ` Natanael 2017-05-08 22:15 ` Sergio Demian Lerner 0 siblings, 1 reply; 15+ messages in thread From: Natanael @ 2017-05-08 21:44 UTC (permalink / raw) To: Sergio Demian Lerner; +Cc: Bitcoin Dev, Eric Lombrozo [-- Attachment #1: Type: text/plain, Size: 1509 bytes --] Den 8 maj 2017 23:01 skrev "Sergio Demian Lerner via bitcoin-dev" < bitcoin-dev@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. [-- Attachment #2: Type: text/html, Size: 2162 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Full node "tip" function 2017-05-08 21:44 ` Natanael @ 2017-05-08 22:15 ` Sergio Demian Lerner 0 siblings, 0 replies; 15+ messages in thread From: Sergio Demian Lerner @ 2017-05-08 22:15 UTC (permalink / raw) To: Natanael; +Cc: Bitcoin Dev, Eric Lombrozo [-- Attachment #1: Type: text/plain, Size: 1946 bytes --] 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. On Mon, May 8, 2017 at 6:44 PM, Natanael <natanael.l@gmail•com> wrote: > > Den 8 maj 2017 23:01 skrev "Sergio Demian Lerner via bitcoin-dev" < > bitcoin-dev@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. > [-- Attachment #2: Type: text/html, Size: 2984 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2017-05-08 22:16 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-03 21:08 [bitcoin-dev] Full node "tip" function Erik Aronesty
2017-05-03 21:43 ` Ben Thompson
2017-05-04 10:38 ` Tomas
2017-05-04 13:37 ` Aymeric Vitte
2017-05-04 13:47 ` Erik Aronesty
2017-05-04 14:31 ` Aymeric Vitte
2017-05-03 21:53 ` Gregory Maxwell
2017-05-03 22:03 ` Matt Corallo
2017-05-04 13:15 ` Erik Aronesty
2017-05-04 14:57 ` Tom Zander
2017-05-03 23:21 ` Luke Dashjr
[not found] ` <9335E0E0-F9D6-41AD-9FF9-5CDF2B1AF1F7@gmail.com>
2017-05-04 19:28 ` Erik Aronesty
2017-05-08 21:00 ` Sergio Demian Lerner
2017-05-08 21:44 ` Natanael
2017-05-08 22:15 ` Sergio Demian Lerner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox