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

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] Small Nodes: A Better Alternative to Pruned Nodes

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

> 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

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

"Absolutely, I assume if Vorick's proposal were implemented that nodes would have the follow options: Pruned [UTXO + recent two weeks of blocks], 20%, 40%, 60%, 80%, 100% (archive)." Yes, and I think that they can have this in "disorder" (only 20% of blocks in the middle of the blockchain for

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

On Mon, Apr 17, 2017 at 6:54 AM, David Vorick via bitcoin-dev wrote: > Rationale: > > A node that stores the full blockchain (I will use the term archival node) > requires over 100GB of disk space, which I believe is one of the most > significant barriers to

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

Maybe it already exists ... #9484 812714f Introduce assumevalid setting to skip validation presumed valid scripts (gmaxwell) https://github.com/bitcoin/bitcoin/pull/9484 ..., but ... It would be

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

??? what do you mean? (https://www.soyoustart.com/fr/serveurs-essential/) Le 20/04/2017 à 17:50, Erik Aronesty via bitcoin-dev a écrit : > Try to find 1TB dedicated server hosting ... > > If you want to set up an ecommerce site somewhere besides your living > room, storage costs are still a

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

On Thu, Apr 20, 2017 at 11:46:33AM +0200, Tom Zander via bitcoin-dev wrote: > On Wednesday, 19 April 2017 19:30:30 CEST David Vorick via bitcoin-dev > wrote: > > > I suggested something similar which is a much simpler version; > > > https://zander.github.io/scaling/Pruning/ > > > Your proposal

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

Try to find 1TB dedicated server hosting ... If you want to set up an ecommerce site somewhere besides your living room, storage costs are still a concern. On Mon, Apr 17, 2017 at 3:11 AM, Danny Thorpe via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 1TB HDD is now available

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

On Wednesday, 19 April 2017 19:30:30 CEST David Vorick via bitcoin-dev wrote: > > I suggested something similar which is a much simpler version; > > https://zander.github.io/scaling/Pruning/ > Your proposal has a significant disadvantage: If every peer is dropping > 75% of all blocks randomly,

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

Thanks but you did not answer all the points and some of your statements look wrong, like the global ideas behind this proposal from my standpoint, which basically is inventing strange things not reusing what is already proven to be working well and could provide the same result, which at the end

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

On Tue, Apr 18, 2017 at 3:43 AM, Jonas Schnelli wrote: > > Hi Dave > > *1. I agree that we need to have a way for pruned nodes to partially serve > historical blocks.* > My personal measurements told me that around ~80% of historical block > serving are between tip and

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

>Financially incentivising nodes is a really weird area because it would allow someone to essentially automate the deployment of nodes. i.e. if a node can pay for itself 100% (even at a lesser value, it just becomes cheaper overall), you could write an application that uses an AWS API or a digital

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

I'd like to add to this. There is definitely a barrier of entry with regards to setting up a full node. Unless you're living in a first world country, the bandwidth requirements alone, will outright prevent you from even setting up a full node (sync since genesis). To maintain that also

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

>From the initial post " The situation would likely become problematic quickly if bitcoin-core were to ship with the defaults set to a pruned node." Sorry to be straight, I read the (painful) thread below, and most of what is in there is inept, wrong, obsolete... or biased, cf the first sentence

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

This has been discussed before. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008101.html including a list of nice to have features by Maxwell https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008110.html You meet most of these rules, though you do have to

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

On Monday, 17 April 2017 08:54:49 CEST David Vorick via bitcoin-dev wrote: > The best alternative today to storing the full blockchain is to run a > pruned node The idea looks a little overly complex to me. I suggested something similar which is a much simpler version;

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

Hi Dave > A node that stores the full blockchain (I will use the term archival node) > requires over 100GB of disk space, which I believe is one of the most > significant barriers to more people running full nodes. And I believe the > ecosystem would benefit substantially if more users were

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

While I fully agree with the intent (increasing full nodes so a big miner waking up in a bad mood can't threaten the world any longer every day as it is now) I am not sure to get the interest of this proposal, because: - it's probably not a good idea to encourage the home users to run full nodes,

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

Most people do not want to go out and buy new hardware to run a Bitcoin node. The want to use the hardware that they already own, and usually that hardware is going to have a non-generous amount of disk space. 500GB SSD with no HDD is common in computers today. But really, the best test is to go

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

1TB HDD is now available for under $40 USD. How is the 100GB storage requirement preventing anyone from setting up full nodes? On Apr 16, 2017 11:55 PM, "David Vorick via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > *Rationale:* > > A node that stores the full blockchain (I