Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 39BE0949 for ; Thu, 4 May 2017 13:37:41 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 12873E5 for ; Thu, 4 May 2017 13:37:39 +0000 (UTC) Received: by mail-wm0-f44.google.com with SMTP id m123so16058959wma.0 for ; Thu, 04 May 2017 06:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=pRkCXhrH7bddRPgGO6jQ4axAV9fOBAe/K3aqc+Q2wUw=; b=jb98dvDvqUIqrZ3PoafRqextLqyUoPTozXBkWyhlb+WWWoQd/MqMQ31zZb4qiDUyMc ojRoPBDtCFHSkP7VaYXgzO/lOu2jrfH94zSk198B6fVNVmWNED0CeIToN/7j6B268PV+ WqpsGtDJQlo57AR/L/g38yeaMOQ3GQwIhLkYKfldESNZQLFzn002nOkGNd2c+Us56Jp6 Rwmbopq17aZ1gxSgHyyjxx7PzRFGbDigPXKVHPBAqiOE0Kece/oON63ayTS5N89u24tE ue8ZvwmFK9bY+mlWfBIzYojOHWJsg0AhiDjjWuG1PaiW7ILQggQILJAmiLRAwTFpQ+GU Z9DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=pRkCXhrH7bddRPgGO6jQ4axAV9fOBAe/K3aqc+Q2wUw=; b=tE+1AyyBIcQUmxN5d919Fzry94OStan4zqOVhDdkIH72VmW0bshKlXcOf39zDBF78Y BEazhhcuStcKsxoDdHVBPlFsKRUg0y6psUYxM/KMXMewn4K+EefbgnwuVs4g/ZJB1+j0 bC7IfuxEWjRHWWkRc+3ESaoO/5nnWM9DQg2yY3qq4bHIFpyy7JVOSz+yxI5zdceAKF0X xk3Xr7ZsobNhlDciWpAoCwGpRlDaMDGHjPcFPnNsTIqnSjjg6DwpXDLZUUwMEiiFOqv4 cN5q1v1bGYy9NU4ahP9MuwG0fS5Mz3cBmRtpA4kf5tM/zLbgrNkvRT8PiUIhX0UckHzk z29w== X-Gm-Message-State: AN3rC/7OrsnubcPhKV/V+hrMuHUj+8/Q5tBVcAmbGxM0+b+2FxHffad9 yzi36y2kujuUkgyn X-Received: by 10.28.197.11 with SMTP id v11mr2043218wmf.84.1493905058439; Thu, 04 May 2017 06:37:38 -0700 (PDT) Received: from [192.168.1.10] (ANice-654-1-42-58.w83-201.abo.wanadoo.fr. [83.201.101.58]) by smtp.googlemail.com with ESMTPSA id k7sm3212522wrk.45.2017.05.04.06.37.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 May 2017 06:37:37 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: <1493894309.1179269.965498864.6244705A@webmail.messagingengine.com> From: Aymeric Vitte Message-ID: <02b56878-c4e5-d1b9-07f4-317663f543b5@gmail.com> Date: Thu, 4 May 2017 15:37:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1493894309.1179269.965498864.6244705A@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------812ABCBB7415E348EBCE50D8" X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Full node "tip" function X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 13:37:41 -0000 This is a multi-part message in MIME format. --------------812ABCBB7415E348EBCE50D8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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, >> > > 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 --------------812ABCBB7415E348EBCE50D8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

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 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
--------------812ABCBB7415E348EBCE50D8--