From: Erik Aronesty <erik@q32.com>
To: Aymeric Vitte <vitteaymeric@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Full node "tip" function
Date: Thu, 4 May 2017 09:47:45 -0400 [thread overview]
Message-ID: <CAJowKgJiW4wZ_FnVPLLTYbA1B6xgswMD19-Tf1HmowpWqZEnPQ@mail.gmail.com> (raw)
In-Reply-To: <02b56878-c4e5-d1b9-07f4-317663f543b5@gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2017-05-04 13:47 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJowKgJiW4wZ_FnVPLLTYbA1B6xgswMD19-Tf1HmowpWqZEnPQ@mail.gmail.com \
--to=erik@q32.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=vitteaymeric@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox