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

2017-05-08 Thread Sergio Demian Lerner via bitcoin-dev
Yes you practically can. No proxy can defeat the protocol investing less money than buying storage space to store the blockchain. Even with challenge-response delays of minutes. That's why it will be fully controlled by a RSK smart-contract, with no user intervention. I'm will post about this

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

2017-05-08 Thread Natanael via bitcoin-dev
Den 8 maj 2017 23:01 skrev "Sergio Demian Lerner via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: I'll soon present a solution to encourage full nodes to store the blockchain based on Proof-of-Unique-Blockchain-Storage (PoUBS) Proving that you're holding your own copy of the

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

2017-05-08 Thread Sergio Demian Lerner via bitcoin-dev
A full node provides several services to the network: 1•Broadcasts blocks (public service) 2•Broadcasts transactions (public/private service) 3•Increases privacy by hiding other node’s IPs 4•Increases network security by protecting it from global DoS. 5•Provides information filtering services to

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

2017-05-05 Thread Erik Aronesty via bitcoin-dev
> > This is actually LN’s killer use case - not buying coffees ;) > Yes, micro-payments for online network services is precisely what LN is best at. Establishing a channel with each peer is too expensive. But using LN to micro-pay for high-quality peer services seems like it would aggregate

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

2017-05-04 Thread Tom Zander via bitcoin-dev
I agree with you here, Erik. Greg's standard answer doesn’t apply to your suggestion. I think he was a bit too trigger happy because we have seen a lot of similar suggestions that have the Sybill issue he mentioned. On Thursday, 4 May 2017 15:15:02 CEST Erik Aronesty via bitcoin-dev wrote: > >

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

2017-05-04 Thread Erik Aronesty via bitcoin-dev
- 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. -

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

2017-05-04 Thread Aymeric Vitte via bitcoin-dev
Yes, as a whole, but I am sorry, your "tip" proposal is very very very bad as it is, think a little bit more about your latest answer and you will understand why I am a bit perplexed sometimes about what is proposed on this list Adding services paid by the miners is not a bad idea, like some

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

2017-05-04 Thread Aymeric Vitte via bitcoin-dev
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

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

2017-05-04 Thread Erik Aronesty via bitcoin-dev
> Greg > The primary result would be paying people to sybil attack the network. I cannot imagine the benefit to replicating an ip address in this case, except maybe you think that you would be more likely to be selected as a peer? But there would be no actual advantage since download peers are

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

2017-05-04 Thread Tomas via bitcoin-dev
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:

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] 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