What is Nostr?
Erik Aronesty [ARCHIVE] /
npub1y22…taj0
2023-06-07 18:00:45
in reply to nevent1q…df8s

Erik Aronesty [ARCHIVE] on Nostr: 📅 Original date posted:2017-05-04 📝 Original message:- Full nodes already ...

📅 Original date posted:2017-05-04
📝 Original message:- 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 at 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 at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170504/3858fae9/attachment-0001.html>;
Author Public Key
npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0