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

2017-05-03 Thread 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

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

2017-05-03 Thread 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, >

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

2017-05-03 Thread 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

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

2017-05-03 Thread 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

[bitcoin-dev] Full node "tip" function

2017-05-03 Thread 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

Re: [bitcoin-dev] Transaction signalling

2017-05-03 Thread 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

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

2017-05-03 Thread 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

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

2017-05-03 Thread 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