Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 837784A5 for ; Wed, 3 May 2017 22:45:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f172.google.com (mail-wr0-f172.google.com [209.85.128.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6C25E138 for ; Wed, 3 May 2017 22:45:37 +0000 (UTC) Received: by mail-wr0-f172.google.com with SMTP id l9so1704474wre.1 for ; Wed, 03 May 2017 15:45:37 -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=2IS2IDXwyaGZgqIyUcfpVSLLIxeIl7T7QGVjvMswA9w=; b=bP+FGEA5a73Z4TGTOKQwZ8dR903uNDaELC8sb3ZIHZ4Lkm3giF0DeHTuLV9N97j1nY HL7K8svKIncx/ItMOR7JxWAvJKtahA8E/uKPWH/XYUilzQQXilpst60MYd19MuVYE23P 91VawPGzWgqpZBTct+Y7/FRddFWWq/dNIrNqRzd5gUvmcpr9Q6kmnHwHSw9C+DVUsQDS hiVVaPEkNL6g3vrqwqzg4CyYd2BwG0ggU/jjbbYlJ94OsGJODZCS1RJGypca5MBi2eDz XVFzIyy1zWNzkp5aDzdKEcUxy2H/m8WnxX12rnvDhex55hx2u9Q9oTEW6aKoyWB8ESi9 036A== 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=2IS2IDXwyaGZgqIyUcfpVSLLIxeIl7T7QGVjvMswA9w=; b=lqvAuhUEzWHGL0Hc+tWbLIrnWo2g1PIpPO+OHAGJUPmYSLG7dG6WFzSUXqt1jIENnJ 6YOQu5soioieQJdzdkgbY407eoQlh6SfPR4B6cpJjqx8kjdcfynGm+N9ZXYnbMNuqFg0 XKctISfozlAc9FILJq7lodqhPbRD6Ju1LutFzIOkj8+HpIBNbMSDF5gklq8MNTKP9vbS Wz2f8DUrBXG7EslYPQJRmxWBjh/WsD7Dqn1k2cpj4FVj+XCSYi6GkYq7pbPsX4pn6rWm xUF68EKoXnydKX/FPZnojMjF/HDALs3fb/zI1g+j2Mytkf5Tl1/tTbc+BIA4ZjDVbT+J I0jQ== X-Gm-Message-State: AN3rC/7mMHMES3W5VuK9aHmBY4TZUvQI6Db0FO4w56oCrThlw32DoPnZ ROYB6QrM2XrZip1A X-Received: by 10.223.147.225 with SMTP id 88mr18095538wrp.74.1493851535804; Wed, 03 May 2017 15:45:35 -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 t85sm75759wmt.23.2017.05.03.15.45.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 15:45:35 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: From: Aymeric Vitte Message-ID: Date: Thu, 4 May 2017 00:45:40 +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: Content-Type: multipart/alternative; boundary="------------94524430C44E8A4615A6B492" 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] Small Nodes: A Better Alternative to Pruned Nodes 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: Wed, 03 May 2017 22:45:38 -0000 This is a multi-part message in MIME format. --------------94524430C44E8A4615A6B492 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Le 03/05/2017 à 21:10, Natanael via bitcoin-dev a écrit : > > Den 3 maj 2017 16:05 skrev "Erik Aronesty via bitcoin-dev" > >: > > > But as you've observed, the failure probabilities are rather high, > > especially if an active attacker targets nodes carrying less > commonly > > available blocks. > > Wouldn't the solution be for nodes to use whatever mechanism an > attacker uses to determine less commonly available blocks and > choose to store a random percentage of them as well as their > deterministic random set? > > IE X blocks end of chain (spv bootstrap), Y% deterministic random > set, Z% patch/fill set to deter attacks > > > Then he uses Sybil attacks to obscure what's actually rare and not. > Even proof of storage isn't enough,you need proof of INDEPENDENT storage Yes > , which is essentially impossible No, the bittorrent network is a good example > , as well as a way of determining which nodes are run by the same > people (all the AWS nodes should essentially count as one). No, this one is impossible and you don't care in fact, as long as the system forbids the nodes to position themselves where they like and can check that the nodes are behaving correctly, same people's nodes/IPs would then just do the job And if you add to this a rewarding system that is not necessarily profitable then you eliminate the incentive for sybil attacking the network (like the "tip" proposal today) while motivating those that have the resources to run full nodes, then increasing independence > > > _______________________________________________ > 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 --------------94524430C44E8A4615A6B492 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



Le 03/05/2017 à 21:10, Natanael via bitcoin-dev a écrit :

Den 3 maj 2017 16:05 skrev "Erik Aronesty via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>:
> But as you've observed, the failure probabilities are rather high,
> especially if an active attacker targets nodes carrying less commonly
> available blocks. 

Wouldn't the solution be for nodes to use whatever mechanism an attacker uses to determine less commonly available blocks and choose to store a random percentage of them as well as their deterministic random set? 

IE X blocks end of chain (spv bootstrap), Y% deterministic random set,  Z% patch/fill set to deter attacks

Then he uses Sybil attacks to obscure what's actually rare and not.

Even proof of storage isn't enough,you need proof of INDEPENDENT storage

Yes

, which is essentially impossible

No, the bittorrent network is a good example

, as well as a way of determining which nodes are run by the same people (all the AWS nodes should essentially count as one).

No, this one is impossible and you don't care in fact, as long as the system forbids the nodes to position themselves where they like and can check that the nodes are behaving correctly, same people's nodes/IPs would then just do the job

And if you add to this a rewarding system that is not necessarily profitable then you eliminate the incentive for sybil attacking the network (like the "tip" proposal today) while motivating those that have the resources to run full nodes, then increasing independence




_______________________________________________
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
--------------94524430C44E8A4615A6B492--