Re: [bitcoin-dev] Full node "tip" function

[Luke Dashjr via bitcoin-dev]

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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

[Aymeric Vitte via bitcoin-dev]

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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Full node "tip" function

[Matt Corallo via bitcoin-dev]

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 
 wrote:
>On Wed, May 3, 2017 at 9:08 PM, Erik Aronesty via bitcoin-dev
> 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Full node "tip" function

[Ben Thompson via bitcoin-dev]

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 protocol​s 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Full node "tip" function

[Erik Aronesty via bitcoin-dev]

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

Re: [bitcoin-dev] Transaction signalling

[Erik Aronesty via bitcoin-dev]

BIP  : User activated features (ROUGH OVERVIEW)

A proposed change to a usage of the 'OP_RETURN' script opcode in Bitcoin
transactions, allowing multiple changes (features) to be deployed in
parallel. It relies on interpreting the output field as a bit vector, where
each bit can be used to track an independent change. Like BIP9, once a
consensus change succeeds or times out, there is a "fallow" pause after
which the bit can be reused for later changes.

==Motivation==

BIP 9 introduced a mechanism for doing soft-forking changes, relying on
measuring miner support indicated by version bits in block headers. As it
relies on miner support, any change which may conflict with miners but is
acceptable to users may be difficult to deploy.   The alternative, a
flag-day deployment can cause issues for users of a feature that has failed
to achieve adequate miner support.

BIP , if used for deployment, can be used in conjunction with BIP 9, in
order to more safely deploy soft-forking changes that do not require a
supermajority of miners, but do require a large percentage of active
users.

Alternatively, BIP  signalling can be used to gauge user support for
"features" - independent of its use as a direct deployment mechanism.   In
this document a "feature" can be considered synonymous with "soft fork",
but since this mechanism is "user activated", it is not necessarily
restricted to soft-forks.

==Specification==

Each "feature" is specified by the sames set of per-chain parameters as in
BIP9, with the same usage and meaning (name, bit, starttime and timeout).

===Bit flags===

If the outputs contain a zero valued OP_RETURN, and the length of the key
is 2 bytes, and if the first byte (prefix) of that OP_RETURN's key
parameter is 0x012, then the remaining byte is to be interpreted as an
8-bit little-endian integer, and bits are selected within this integer as
values (1 << N) where N is the bit number.  This allows up to 8 features to
be in the STARTED state at a time.

===Array determination===

In order for this to successfully be used for deployment, a lightweight
UTXO must be maintained in memory.   For each bit in STARTED state, a
corresponding bit is set in a map entry for each input address.   Each
input address is hashed to a 24 bit value using SHA3-256(input)[0:24].  An
array with 16777216 2-byte entries (~32MB RAM) is used to record the
current activation state.   The first byte contains the bit flags most
recently associated with an entry.

The second byte contains the log base 2 of the number of "1/100th" bitcoins
most recently associated with this entry.   This is computed by taking the
value, multiplying by 100, converting to an unsigned 32 bit integer, and
using the log2_32 function below ( log2_32 func defined below ).

This array is initialized to zero.   The array must be stored and
maintained for each block.  When a block is in the STARTED state for any
bit, the array is updated for each transaction in the block according to
the rules above: a[i][0]=bits, a[i][1]=log2_32()

===State transitions===

State transitions work the same as BIP9, however, the determination of the
LOCKED_IN tally is as follows:

For each bit in STARTED state, using the array above, the values are
totaled (unsigned int)(2 << a[i][1]) for each entry where this bit is set
in a[i][0].  In addition the total of all the entries in a, irrespective of
bit, are computed.   This can be done in a single pass, resulting in a
vector of up to 8 32 bit entries containing the "feature totals" for the
array, and one extra 32 bit entry for the sum total of observations since
the start time.

The percentage of observations is computed for each bit.   Up to 8 features
can be computed at a time, with reuse similar to BIP9.

If 2016 sequential blocks have a value of 95% or greater, a feature is
"LOCKED_IN", (75% on testnet)
bit.

Similar to BIP9, a block's state never depends on its own transactions set;
only on that of its ancestors.  ACTIVE and FAILED are terminal states, etc.


On Thu, Apr 20, 2017 at 12:14 PM, Erik Aronesty  wrote:

> I agree, addresses create vulnerability, an OP_RETURN signal seems the
> safest way to go for UA signalling.   I can model a BIP after BIP9, with
> some discussion of how to properly collect statistics, and the ability for
> nodes to activate features based on an "economic majority" defined in this
> way.
>
> On Tue, Apr 18, 2017 at 6:29 PM, Tim Ruffing via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I don't have an opinion on whether signaling is a good idea in general.
>>
>> However I don't think that using addresses is a good idea, because this
>> has privacy implications. For example, it makes it much easier to link
>> the addresses, e.g., inputs with change address. (The change address
>> votes for the same proposal as the input address.)
>>
>> Tim
>>
>> On Tue, 2017-04-18 at 18:07 +, Christian Decker via bitcoin-dev
>> wrote:
>> > I really 

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

[Natanael via bitcoin-dev]

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, which
is essentially impossible, as well as a way of determining which nodes are
run by the same people (all the AWS nodes should essentially count as one).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

[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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev