<unnamed>

Public Key

npub14h948ndawt32ps3y225sslch8344tmw8k5z0lxuxr6wq9tu6sl2qj9yjx0

Profile Code

nprofile1qqs2mj6nek7h9c4qcgj992gg0utnc664ahrm2p8lnwrpa8qz47dg04qpzpmhxue69uhkummnw3ezuamfdejs0c7nt6

Publishing to

nostr.wine

Last Notes

2023-06-07 18:00:21 UTC

- reply

📅 Original date posted:2017-04-19
📝 Original message:On Tue, Apr 18, 2017 at 3:43 AM, Jonas Schnelli <dev at jonasschnelli.ch>
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 -1’000 blocks.
> Currently, Core nodes have only two modes of operations, „server all
> historical blocks“ or „none“.
> This makes little sense especially if you prune to a target size of, lets
> say, 80GB (~80% of the chain).
> Ideally, there would be a mode where your full node can signal a third
> mode „I keep the last 1000 blocks“ (or make this more dynamic).
>
That probably makes sense with small nodes too. The past 1000 blocks are
such a small footprint compared to the rest of the chain.
>
> *2. Bootstrapping new peers*
> I’m not sure if full nodes must be the single point of historical data
> storage. Full nodes provide a valuable service (verification, relay,
> filtering, etc.). I’m not sure if serving historical blocks is one of them.
> Historical blocks could be made available on CDN’s or other file storage
> networks. You are going to verify them anyways,... the serving part is pure
> data storage.
> I’m also pretty sure that some users have stopping running full nodes
> because their upstream bandwidth consumption (because of serving historical
> blocks) was getting intolerable.
> Especially „consumer“ peers must have been hit by this (little experience
> in how to reduce traffic, upstream in general is bad for
> consumers-connections, little resources in general).
>
Perhaps it is not, but I would think that it would be pretty
straightforward to configure a global bandwidth limit within Bitcoin. I
know many torrent clients, and clients for protocols like Tor and i2p
include the ability to set both speed limits and monthly bandwidth limits.
Shipping core with sane default limits is probably sufficient to solve
bandwidth issues for most users. I don't know if default limits may result
in today's archive nodes pulling less weight though - changing the defaults
to have limits may slow the network down as a whole.
In my experience (living in a city where most people have uncapped
connections), disk usage is usually the bigger issue, but certainly
bandwidth is a known problem (especially for rural users) as well.
>
> Having a second option built into full nodes (or as an external bootstrap
> service/app) how to download historical blocks during bootstrapping could
> probably be a relieve for "small nodes“.
> It could be a little daemon that downloads historical blocks from CDN’s,
> etc. and feeds them into your full node over p2p/8333 and kickstarts your
> bootstrapping without bothering valuable peers.
> Or, the alternative download, could be built into the full nodes main
> logic.
> And, if it wasn’t obvious, this must not bypass the verification!
>
I worry about any type of CDN being a central point of failure. CDNs cost
money, which means someone is footing the bill. Torrenting typically relies
on a DHT, which is much easier to attack than Bitcoin's peer network. It's
possible that a decentralized CDN could be used, but I don't think any yet
exist (though I am building one for unrelated reasons) which are both
sufficiently secure and incentive-compatible to be considered as an
alternative to using full nodes to bootstrap.
I just don't want to end up in a situation where 90% of users are getting
their blockchain from the same 3 websites or centralized services. And I
also don't want to rely on any p2p solution which would not stand up to a
serious adversary. Right now, I think the bitcoin p2p network is by
significant margin the best we've got. The landscape for decentralized data
distribution is evolving rapidly though, perhaps in a few years there will
be a superior alternative.
> *To your proposal:*
> - Isn’t there a tiny finger-printing element if peers have to pick an
> segmentation index?
> - SPV bloom filter clients can’t use fragmented blocks to filter txns?
> Right? How could they avoid connecting to those peers?
>
> </jonas>
>
Yes, there is finger-print that happens if you have nodes pick an index.
And the fingerprint gets a lot worse if you have a node pick multiple
indexes. Though, isn't it already required that nodes have some sort of IP
address or hidden service domain? I want to say that the fingerprint
created by picking an index is not a big deal, because it can be separated
from activity like transaction relaying and mining. Though, I am not
certain and perhaps it is a problem.
To be honest, I hadn't really considered SPV nodes at the time of writing.
Small nodes would still be seeing all of the new blocks, and per your
suggestion may also be storing the 1000 or so most recent blocks, but SPV
nodes would still need some way to find all of their historical
transactions. The problem is not fetching blocks, it's figuring out which
blocks are worth fetching. It may be sufficient to have nodes store a bloom
filter for each block indicating which addresses had activity. The bloom
filter would probably only need to be about 1% of the size of the full
block. That's not too much overhead (now you are storing 21% of the block
instead of just 20%), and would retain SPV compatibility.
On Mon, Apr 17, 2017 at 12:17 PM, praxeology_guy <
praxeology_guy at protonmail.com> wrote:
>
> FYI With unspent coin snapshots, needing archive data becomes less
> important. People can synchronize from a later snapshot instead of the
> genesis block. See https://petertodd.org/2016/delayed-txo-commitments
> for my current favorite idea.
>
>
This is something that I think could help a lot too. If the build processes
included verifying the chain and then creating a utxo snapshot at say,
block 400,000, then nodes would no longer need to download, store, upload,
or share blocks prior to that height. It means that a reorg deeper than
that point would hardfork the network. But a reorg 60k blocks deep is going
to cause problems worse than a network split. Then, the only people who
would ever need to care about the early blocks are developers, and it's
more reasonable to expect developers to go through a longer process and
have more resources than everyday users.
On Mon, Apr 17, 2017 at 6:14 AM, Aymeric Vitte via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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, there are many people running servers far from their capacity that
> could easily run efficient full nodes
>
Running a full node is the only way to avoid needing to trust others. It's
also how you make your opinion worthwhile for events like hard forks and
UASFs. If decentralization is the primary motivation, it absolutely makes
sense to encourage people to run their own full nodes. Without a full node,
you are at the mercy of the governance decisions by those who do have full
nodes. But if you have a full node, you can chose to opt-out of any upgrade
(example: ethereum classic nodes).
> - if someone can't allocate 100 GB today to run a full node, then we can't
> expect him to allocate more in the future
>
That's why I'm proposing something to decrease the storage requirements.
> - this proposal is a kind of reinventing torrents, while limiting the
> number of connections to something not efficient at all, I don't see why
> something that is proven to be super efficient (torrents) would be needed
> to be reinvented, I am not saying that it should be used as the bittorrent
> network is doing but the concepts can be reused
>
It's different from torrents in that it uses specialized erasure coding to
make sure that every block is always available, even if an adversary is
running around targeting all the nodes with a particular piece.
> - I don't get at all the concept of "archival" nodes since it's another
> useless step toward centralization
>
"archival" nodes are simply nodes with the full blockchain. Nobody can
bootstrap on the network without them. Today, every bitcoin-core node is an
archival node by default.
> I think the only way to increase full nodes it to design an incentive for
> people to run them
>
The primary incentive is the sovereignty that it gives you. Running a
Bitcoin full node gives you security and protection against political
garbage that you can't get any other way. The network does currently depend
on altruism to allow people to download the blockchain, but as long as we
can keep the resource requirements of this altruism low, I think we can
expect it to continue. This proposal attempts to keep those requirements
low.
On Tue, Apr 18, 2017 at 6:50 AM, Tom Zander <tomz at freedommail.ch> wrote:
> 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;
> https://zander.github.io/scaling/Pruning/
>
> > # Random pruning mode
> >
> > There is a large gap between the two current modes of everything
> > (currently 75GB) and only what we need (2GB or so).
> >
> > This mode would have two areas, it would keep a days worth of blocks to
> > make sure that any reorgs etc would not cause a re-download, but it would
> > have additionally have an area that can be used to store historical data
> > to be shared on the network. Maybe 20 or 50GB.
> >
> > One main feature of Bitcoin is that we have massive replication. Each
> node
> > currently holds all the same data that every other node holds. But this
> > doesn't have to be the case with pruned nodes. A node itself has no need
> > for historic data at all.
> >
> > The suggestion is that a node stores a random set of blocks. Dropping
> > random blocks as the node runs out of disk-space. Additionally, we would
> > introduce a new way to download blocks from other nodes which allows the
> > node to say it doesn't actually have the block requested.
> >
> > The effect of this setup is that many different nodes together end up
> > having the total amount of blocks, even though each node only has a
> > fraction of the total amount.
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
>
Your proposal has a significant disadvantage: If every peer is dropping 75%
of all blocks randomly, then you need to connect to a large number of peers
to download the whole blockchain. Any given peer has a 25% chance of
holding a block, or rather, a 75% chance of not holding a block. If you
have n peers, your probability of not being able to download a given block
is 0.75^n. If you are downloading 450,000 blocks, you will need to connect
to an expected 46 peers to download the whole blockchain.
Your proposal is also a lot less able to handle active adversaries: if
nodes are randomly dropping blocks, the probability that one block in
particular is dropped by everyone goes up significantly. And the problem
gets a lot worse in the presence of an active adversary. If there are 8000
nodes each dropping 75% of the blocks, then each block on average will only
be held by 2000 nodes. Probabilistically, some unlucky blocks will be held
by fewer than 2000 nodes. An active adversary needs only to eliminate about
2000 nodes (a chosen 2000 nodes) to knock a block off of the network. But
missing even a single block is a significant problem.
Your proposal essentially requires that archive nodes still exist and be a
part of a typical blockchain download. Given that, I don't think it would
be a sound idea to ship as a default in bitcoin core.
On Tue, Apr 18, 2017 at 9:07 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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 download blocks from
> multiple peers.
>
> The suggestion in that thread were for a way to compactly indicate which
> blocks a node has. Each node would then store a sub-set of all the
> blocks. You just download the blocks you want from the node that has them.
>
> Each node would be recommended to store the last few days worth anyway.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
I believe that my proposal does meet all of the requirements listed by
Maxwell. Having a set of 8 random peers gives you a very high probability
of being able to recover every single block. You would need to connect to
at least 5 peers (and this is already >90% likely to be sufficient to
recover every block), but if you cannot connect to 5 random peers your node
is probably in trouble anyway. Highly parallel, high speed downloads are
just as possible with small nodes as with archive nodes. It only takes a
few bytes to indicate which part of the blockchain you have, and any 2
peers have a less than 1% chance of overlapping.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170419/88f15eb2/attachment-0001.html>

2023-06-07 18:00:18 UTC

- reply

📅 Original date posted:2017-04-17
📝 Original message: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 out and talk to people. Ask them if they
run a full node, and if they say no, ask them why not. In my experience,
the most common answer by a significant margin is that they don't want to
lose the disk space. That psychology is far more important than any example
of cheap hard drives. People don't want to go out and buy a hard drive so
that they can run Bitcoin. It's a non-starter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170417/11863db8/attachment.html>

2023-06-07 18:00:17 UTC

- reply

📅 Original date posted:2017-04-17
📝 Original message:*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 more people running full nodes. And I believe the
ecosystem would benefit substantially if more users were running full nodes.
The best alternative today to storing the full blockchain is to run a
pruned node, which keeps only the UTXO set and throws away already verified
blocks. The operator of the pruned node is able to enjoy the full security
benefits of a full node, but is essentially leeching the network, as they
performed a large download likely without contributing anything back.
This puts more pressure on the archival nodes, as the archival nodes need
to pick up the slack and help new nodes bootstrap to the network. As the
pressure on archival nodes grows, fewer people will be able to actually run
archival nodes, and the situation will degrade. The situation would likely
become problematic quickly if bitcoin-core were to ship with the defaults
set to a pruned node.
Even further, the people most likely to care about saving 100GB of disk
space are also the people least likely to care about some extra bandwidth
usage. For datacenter nodes, and for nodes doing lots of bandwidth, the
bandwidth is usually the biggest cost of running the node. For home users
however, as long as they stay under their bandwidth cap, the bandwidth is
actually free. Ideally, new nodes would be able to bootstrap from nodes
that do not have to pay for their bandwidth, instead of needing to rely on
a decreasing percentage of heavy-duty archival nodes.
I have (perhaps incorrectly) identified disk space consumption as the most
significant factor in your average user choosing to run a pruned node or a
lite client instead of a full node. The average user is not typically too
worried about bandwidth, and is also not typically too worried about
initial blockchain download time. But the 100GB hit to your disk space can
be a huge psychological factor, especially if your hard drive only has
500GB available in the first place, and 250+ GB is already consumed by
other files you have.
I believe that improving the disk usage situation would greatly benefit
decentralization, especially if it could be done without putting pressure
on archival nodes.
*Small Nodes Proposal:*
I propose an alternative to the pruned node that does not put undue
pressure on archival nodes, and would be acceptable and non-risky to ship
as a default in bitcoin-core. For lack of a better name, I'll call this new
type of node a 'small node'. The intention is that bitcoin-core would
eventually ship 'small nodes' by default, such that the expected amount of
disk consumption drops from today's 100+ GB to less than 30 GB.
My alternative proposal has the following properties:
+ Full nodes only need to store ~20% of the blockchain
+ With very high probability, a new node will be able to recover the entire
blockchain by connecting to 6 random small node peers.
+ An attacker that can eliminate a chosen+ 95% of the full nodes running
today will be unable to prevent new nodes from downloading the full
blockchain, even if the attacker is also able to eliminate all archival
nodes. (assuming all nodes today were small nodes instead of archival nodes)
Method:
A small node will pick an index [5, 256). This index is that node's
permanent index. When storing a block, instead of storing the full block,
the node will use Reed-Solomon coding to erasure code the block using a
5-of-256 scheme. The result will be 256 pieces that are 20% of the size of
the block each. The node picks the piece that corresponds to its index, and
stores that instead. (Indexes 0-4 are reserved for archival nodes -
explained later)
The node is now storing a fragment of every block. Alone, this fragment
cannot be used to recover any piece of the blockchain. However, when paired
with any 5 unique fragments (fragments of the same index will not be
unique), the full block can be recovered.
Nodes can optionally store more than 1 fragment each. At 5 fragments, the
node becomes a full archival node, and the chosen indexes should be 0-4.
This is advantageous for the archival node as the encoded data for the
first 5 indexes will actually be identical to the block itself - there is
no computational overhead for selecting the first indexes. There is also no
need to choose random indexes, because the full block can be recovered no
matter which indexes are chosen.
When connecting to new peers, the indexes of each peer needs to be known.
Once peers totaling 5 unique indexes are discovered, blockchain download
can begin. Connecting to just 5 small node peers provides a >95% chance of
getting 5 uniques, with exponentially improving odds of success as you
connect to more peers. Connecting to a single archive node guarantees that
any gaps can be filled.
A good encoder should be able to turn a block into a 5-of-256 piece set in
under 10 milliseconds using a single core on a standard consumer desktop.
This should not slow down initial blockchain download substantially, though
the overhead is more than a rounding error.
*DoS Prevention:*
A malicious node may provide garbage data instead of the actual piece.
Given just the garbage data and 4 other correct pieces, it is impossible
(best I know anyway) to tell which piece is the garbage piece.
One option in this case would be to seek out an archival node that could
verify the correctness of the pieces, and identify the malicious node.
Another option would be to have the small nodes store a cryptographic
checksum of each piece. Obtaining the cryptographic checksum for all 256
pieces would incur a nontrivial amount of hashing (post segwit, as much as
100MB of extra hashing per block), and would require an additional ~4kb of
storage per block. The hashing overhead here may be prohibitive.
Another solution would be to find additional pieces and brute-force
combinations of 5 until a working combination was discovered. Though this
sounds nasty, it should take less than five seconds of computation to find
the working combination given 5 correct pieces and 2 incorrect pieces. This
computation only needs to be performed once to identify the malicious peers.
I also believe that alternative erasure coding schemes exist which actually
are able to identify the bad pieces given sufficient good pieces, however I
don't know if they have the same computational performance as the best
Reed-Solomon coding implementations.
*Deployment:*
Small nodes are completely useless unless the critical mass of 5 pieces can
be obtained. The first version that supports small node block downloads
should default everyone to an archival node (meaning indexes 0-4 are used)
Once there are enough small-node-enabled archive nodes, the default can be
switched so that nodes only have a single index by default. In the first
few days, when there are only a few small nodes, the previously-deployed
archival nodes can help fill in the gaps, and the small nodes can be useful
for blockchain download right away.
----------------------------------
This represents a non-trivial amount of code, but I believe that the result
would be a non-trivial increase in the percentage of users running full
nodes, and a healthier overall network.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170417/513fc363/attachment.html>

2023-06-07 17:59:51 UTC

- reply

📅 Original date posted:2017-04-09
📝 Original message:On Apr 9, 2017 7:00 PM, "Jared Lee Richardson via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
I can speak from personal experience regarding another very prominent
altcoin that attempted to utilize an asic-resistant proof of work
algorithm, it is only a matter of time before the "asic resistant"
algorithm gets its own Asics. The more complicated the algorithm, the more
secretive the asic technology is developed. Even without it,
multi-megawatt gpu farms have already formed in the areas of the world with
low energy costs. I'd support the goal if I thought it possible, but I
really don't think centralization of mining can be prevented.
On Apr 9, 2017 1:16 PM, "Erik Aronesty via bitcoin-dev" <bitcoin-dev at lists.
linuxfoundation.org> wrote:
> Curious: I'm not sure why a serious discussion of POW change is not on the
> table as a part of a longer-term roadmap.
>
> Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of
> the proven, np-complete graph-theoretic or polygon manipulation POW would
> keep Bitcoin in commodity hardware and out of the hands of centralized
> manufacturing for many years.
>
> Clearly a level-playing field is critical to keeping centralization from
> being a "defining feature" of Bitcoin over the long term. I've heard the
> term "level playing field" bandied about quite a bit. And it seems to me
> that the risk of state actor control and botnet attacks is less than
> state-actor manipulation of specialized manufacturing of "SHA-256 forever"
> hardware. Indeed, the reliance on a fairly simple hash seems less and
> less likely a "feature" and more of a baggage.
>
> Perhaps regular, high-consensus POW changes might even be *necessary* as a
> part of good maintenance of cryptocurrency in general. Killing the
> existing POW, and using an as-yet undefined, but deployment-bit ready POW
> field to flip-flop between the current and the "next one" every 8 years or
> or so, with a ramp down beginning in the 7th year.... A stub function that
> is guaranteed to fail unless a new consensus POW is selected within 7
> years.
>
> Something like that?
>
> Haven't thought about it *that* much, but I think the network would
> respond well to a well known cutover date. This would enable
> rapid-response to quantum tech, or some other needed POW switch as well...
> because the mechanisms would be in-place and ready to switch as needed.
>
> Lots of people seem to panic over POW changes as "irresponsible", but it's
> only irresponsible if done irresponsibly.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
The real bottleneck today is the amount of capex required to achieve
optimal mining. I am strongly in favor of PoW research that investigates
better PoW, but I do not think that any obvious strategies are known yet to
improve substantially on computation heavy hashcash.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170409/76d8a516/attachment.html>

2023-06-07 17:59:19 UTC

- reply

📅 Original date posted:2017-04-06
📝 Original message:On Thu, Apr 6, 2017 at 2:24 AM, Jonathan Toomim via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Ethically, this situation has some similarities to the DAO fork. We have
> an entity who closely examined the code, found an unintended characteristic
> of that code, and made use of that characteristic in order to gain tens of
> millions of dollars. Now that developers are aware of it, they want to
> modify the code in order to negate as much of the gains as possible.
>
> There are differences, too, of course: the DAO attacker was explicitly
> malicious and stole Ether from others, whereas Bitmain is just optimizing
> their hardware better than anyone else and better than some of us think
> they should be allowed to.
>
> In both cases, developers are proposing that the developers and a majority
> of users collude to reduce the wealth of a single entity by altering the
> blockchain rules.
>
> In the case of the DAO fork, users were stealing back stolen funds, but
> that justification doesn't apply in this case. On the other hand, in this
> case we're talking about causing someone a loss by reducing the value of
> hardware investments rather than forcibly taking back their coins, which is
> less direct and maybe more justifiable.
>
> While I don't like patented mining algorithms, I also don't like the idea
> of playing Calvin Ball on the blockchain. Rule changes should not be
> employed as a means of disempowering and empoverishing particular entities
> without very good reason. Whether patenting a mining optimization qualifies
> as good reason is questionable.
>
Bitmain is blocking protocol upgrades to preserve their mining advantage.
This is quite distinct from someone taking advantage of a visibly broken
and highly toxic smart contract to net themselves tens of millions of
dollars. Further, Bitmain is performing a patented hardware optimization.
The patents mean that other miners are unable to capitalize on these
optimizations. These optimizations are to the tune of 30%. If you give one
player in the mining industry a permanent 30% cost advantage they will
eventually own everything. It's an industry where margins tend towards zero.
The asicboost patent is a direct threat to the health of the Bitcoin
ecosystem, and now we have visible proof. The war against segwit and the
strife with Bitcoin Unlimited was very damaging to the ecosystem, damaging
to the price, and holding back significant improvements and upgrades to the
Bitcoin protocol. I interpret this as a direct attack on the Bitcoin
ecosystem.
I don't know if changing the rules to nullify asicboost is the right move.
I'm sure this won't be the last patent that causes damage to the ecosystem.
But you need to recognize that the issue is not that Bitmain ran a hardware
optimization. It's that hardware optimizations exist which directly inhibit
upgrading the protocol. And it's that hardware optimizations exist
encumbered by patents enough to give one party a decisive advantage in
mining, decisive enough for them to build a single, centralized monopoly.
Each problem is separate, and each problem is significant, and each problem
is fundamental. The DAO attack was a one-time bout of stupidity that
threatened a fixed amount of money. asicboost is an ongoing status that
directly damages Bitcoin's ability to upgrade, and directly damage
Bitcoin's ability to retain any modicum of decentralization in the
hashrate. The DAO issue did neither of these things for ethereum.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/5ed69d3a/attachment.html>

2023-06-07 17:59:18 UTC

- reply

📅 Original date posted:2017-04-06
📝 Original message:I have a practical concern related to the amount of activation energy
required to get something like this through. We are talking about
implementing something that would remove tens to hundreds of millions of
dollars of mining revenue for miners who have already gambled that this
income would be available to them.
That's not something they are going to let go of without a fight, and we've
already seen this with the segwit resistance. Further, my understanding is
that this makes a UASF a lot more difficult. Mining hardware that has
unique optimizations on one chain only can resist a UASF beyond a simple
economic majority, because they can do more hashes on the same amount of
revenue. Threshold for success is no longer 51%, especially if you are
expecting the miners to struggle (and this is a case where they have a very
good reason to struggle). Any resistance from the hashrate during the early
days of a UASF will inevitably cause large reorgs for older nodes, and is
not much better than a hardfork.
I don't know what the right answer is. But I know that we are not going to
get segwit without a fight. We are not going to invalidate covert asicboost
without a fight. And we are working with a system that actively (and is
demonstrably very effective at doing it) resists changes which are
contentious. This is definitely a contentious change, because an important
part of the community (the miners) is going to be actively resisting it.
I urge everybody to realize how difficult something like this is going to
be to pull off. We are literally talking about invalidating hardware (or at
least the optimized bits). It's only going to succeed if everybody is
conclusively on board. As you consider proposals, realize that anything
which is not the simplest and least contentious is already dead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170405/e22feba7/attachment.html>

2023-06-07 17:58:33 UTC

- reply

📅 Original date posted:2017-03-30
📝 Original message:On Mar 30, 2017 12:04 PM, "Tom Harding via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Raystonn,
Your logic is very hard to dispute. An important special case is small
miners.
Small miners use pools exactly because they want smaller, more frequent
payments.
Rising fees force them to take payments less frequently, and will only tend
to make more of them give up.
With fees rising superlinearly, this centralizing effect is much stronger
than the oft-cited worry of small miners joining large pools to decrease
orphan rates.
Miners get paid on average once every ten minutes. The size of fees and the
number of fee transactions does not change the payout rate.
Further, we are very far from the point (in my appraisal) where fees are
high enough to block home users from using the network.
Bitcoin has many high-value use cases such as savings. We should not throw
away the core innovation of monetary sovereignty in pursuit of supporting
0.1% of the world's daily transactions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/92e8b405/attachment.html>

2023-06-07 17:58:20 UTC

- reply

📅 Original date posted:2017-03-29
📝 Original message:> > When considering what block size is acceptable, the impact of running
bitcoin in the background on affordable, non-dedicated home-hardware should
be a top consideration.
> Why is that a given? Is there math that outlines what the risk levels
are for various configurations of node distributions, vulnerabilities,
etc? How does one even evaluate the costs versus the benefits of node
costs versus transaction fees?
It's a political assessment. Full nodes are the ultimate arbiters of
consensus. When a contentious change is suggested, only the full nodes have
the power to either accept or reject this contentious change. If home users
are not running their own full nodes, then home users have to trust and
rely on other, more powerful nodes to represent them. Of course, the more
powerful nodes, simply by nature of having more power, are going to have
different opinions and objectives from the users. And it's impossible for
5000 nodes to properly represent the views of 5,000,000 users. Users
running full nodes is important to prevent political hijacking of the
Bitcoin protocol. Running a full node yourself is the only way to guarantee
(in the absence of trust - which Bitcoin is all about eliminating trust)
that changes you are opposed to are not introduced into the network.
> Disk space is not the largest cost, either today or in the future.
Without historical checkpointing in some fashion, bandwidth costs are more
than 2 orders of magnitude higher cost than every other cost for full
listening nodes.
This statement is not true for home users, it is true for datacenter nodes.
For home users, 200 GB of bandwidth and 500 GB of bandwidth largely have
the exact same cost. I pay a fixed amount of money for my internet, and if
I use 500 GB the cost is identical to if I use 200 GB. So long as bandwidth
is kept under my home bandwidth cap, bandwidth for home nodes is _free_.
Similarly, disk space may only be $2/TB in bulk, but as a home user I have
a $1000 computer with 500 GB of total storage, 100 GB seems
(psychologically) to cost a lot closer to $200 than to $2. And if I go out
and buy an extra drive to support Bitcoin, it's going to cost about $50 no
matter what drive I pick, because that's just how much you have to spend to
get a drive. The fact that I get an extra 900 GB that I'm not using is
irrelevant - I spent $50 explicitly so I could run a bitcoin node.
The financials of home nodes follow a completely different math than the
costs you are citing by quoting datacenter prices.
> I don't know how to evaluate the impacts of RAM or CPU usage, or
consequently electricity usage for a node yet. I'm open to quantifying any
of those if there's a method, but it seems absurd that ram could even
become a signficant factor given the abundance of cheap ram nowadays with
few programs needing it.
Many home machines only have 4GB of RAM. (I am acutely aware of this
because my own software consumes about 3.5GB of RAM, which means all of our
users stuck at 4 GB cannot use my software and Chrome at the same time).
0.14 uses more than 1 GB of RAM. This I think is not really a problem for
most people, but it becomes a problem if the amount of RAM required grows
enough that they can't have all of their programs open at the same time.
1GB I think is really the limit you'd want to have before you'd start
seeing users choose not to run nodes simply because they'd rather have 300
tabs open instead.
CPU usage I think is pretty minimal. Your node is pretty busy during IBD
which is annoying but tolerable. And during normal usage a user isn't even
going to notice. Same for electricity. They aren't going to notice at the
end of the month if their electricity bill is a dollar higher because of
Bitcoin.
> The consequence of your logic that holds node operational costs down is
that transaction fees for users go up, adoption slows as various use cases
become impractical, price growth suffers, and alt coins that choose lower
fees over node cost concerns will exhibit competitive growth against
Bitcoin's crypto-currency market share. Even if you are right, that's
hardly a tradeoff not worth thoroughly investigating from every angle, the
consequences could be just as dire for Bitcoin in 10 years as it would be
if we made ourselves vulnerable.
This is very much worth considering. If transaction fees are so high that
there is no use case at all for people unwilling to buy extra hardware for
Bitcoin (a dedicated node or whatever), then there is no longer a reason to
worry about these people as users. However, I think the fees would have to
get in the $50 range for that to start to be the case. When talking about
emergency funds - that is, $10k+ that you keep in case your government
defaults, hyperinflates, seizes citizen assets, etc. etc. (situations that
many Bitcoin users today have to legitimately worry about), then you are
going to be making a few transactions per year at most, and the cost of
fees on a home node may be $150 / yr, while the cost of dedicated hardware
might be $150/yr ($600 box amortized over 4 years). We are two orders of
magnitude away from this type of fee pressure, so I think it continues to
make sense to be considering the home nodes as the target that we want to
hit.
> What about periodically committing the entire UTXO set to a special
checkpoint block which becomes the new de facto Genesis block?
This should be discussed in another thread but I don't think I'm alone in
saying that I think this could actually be done in a secure / safe /
valuable way if you did it correctly. It would reduce bandwidth pressure on
archive nodes, reduce disk pressure on full nodes, and imo make for a more
efficient network overall.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/930defe5/attachment-0001.html>

2023-06-07 17:58:17 UTC

- reply

📅 Original date posted:2017-03-29
📝 Original message:On Mar 29, 2017 12:20 PM, "Andrew Johnson" <andrew.johnson83 at gmail.com>
wrote:
What's stopping these users from running a pruned node? Not every node
needs to store a complete copy of the blockchain.
Pruned nodes are not the default configuration, if it was the default
configuration then I think you would see far more users running a pruned
node.
But that would also substantially increase the burden on archive nodes.
Further discussion about disk space requirements should be taken to another
thread.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/9f1bb665/attachment.html>

2023-06-07 17:58:14 UTC

- reply

📅 Original date posted:2017-03-29
📝 Original message:Perhaps you are fortunate to have a home computer that has more than a
single 512GB SSD. Lots of consumer hardware has that little storage. Throw
on top of it standard consumer usage, and you're often left with less than
200 GB of free space. Bitcoin consumes more than half of that, which feels
very expensive, especially if it motivates you to buy another drive.
I have talked to several people who cite this as the primary reason that
they are reluctant to join the full node club.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/68629ee3/attachment.html>

2023-06-07 17:58:06 UTC

- reply

📅 Original date posted:2017-03-29
📝 Original message:On Mar 29, 2017 9:50 AM, "Martin Lízner via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Im tending to believe, that HF is necessary evil now.
I will firmly disagree. We know how to do a soft-fork blocksize increase.
If it is decided that a block size increase is justified, we can do it with
extension blocks in a way that achieves full backwards compatibility for
all nodes.
Barring a significant security motivation, there is no need to hardfork.
I am also solidly unconvinced that increasing the blocksize today is a good
move, even as little as SegWit does. It's too expensive for a home user to
run a full node, and user-run full nodes are what provide the strongest
defence against political manuveuring.
When considering what block size is acceptable, the impact of running
bitcoin in the background on affordable, non-dedicated home-hardware should
be a top consideration.
Disk space I believe is the most significant problem today, with RAM being
the second most significant problem, and finally bandwidth consumption as
the third most important consideration. I believe that v0.14 is already too
expensive on all three fronts, and that block size increases shouldn't be
considered at all until the requirements are reduced (or until consumer
hardware is better, but I believe we are talking 3-7 years of waiting if we
pick that option).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/873b902d/attachment.html>

2023-06-07 17:57:13 UTC

- reply

📅 Original date posted:2017-03-12
📝 Original message:It has taken almost 6 months for SegWit adoption to get to where it is
today. I don't think it will take that long to reach similar adoption for
UASF SegWit, but conservatively we want to give it at least that much time.
It's really important to stress here that a UASF will split and become the
minority chain if a majority of the transaction accepting nodes on the
network do not agree to strictly follow the UASF and outright reject blocks
that do not signal for SegWit at the designated date.
Before setting a flag day, I think we should get written cooperation
agreements from the largest economic players in Bitcoin. This would include:
Bitfinex
Bitflyer
BitGo
BitPay
Bitstamp
Blockchain.info
Blockcypher
Coinbase
Huobi
Kraken
Gemeni
OkCoin
Poloniex
(feel free to discuss this list)
100% cooperation is not necessary, but close to 100% cooperation is
strongly desired. It should be noted that their cooperation is only
required because they are sufficiently powerful to threaten the success of
a UASF, particularly because many of these entities hold users bitcoins.
Once a convincing majority is on-board, I suggest we release a UASF patch
that activates a full year after release. This is because a UASF is a big
gamble that requires a large majority of the economy has upgraded.
Though that is a very long time, SegWit can always be activated early with
miner cooperation.
------
As an extra note, if the UASF triggers with majority economy support and
the miners resist, a minority block reward chain may be the longest chain
for a while. However, when the majority block reward chain does catch up,
the minority reward chain will be entirely obliterated, eliminating all
block rewards, all transaction history, and making a ton of money vanish
all at once.
This makes it very dangerous for an exchange, payment processor, online
wallet, or miner to oppose the UASF if there is significant momentum behind
it. This gives the UASF a powerful snowball effect once a few major parties
(or the majority of tiny full nodes) have decided to commit to the UASF.
On the other hand, failure means a permanent coin split, so it is still
necessary to exercise caution that exceeds the caution of a normal soft
fork.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170312/f12ebb1f/attachment.html>

2023-06-07 17:57:04 UTC

- reply

📅 Original date posted:2017-03-06
📝 Original message:On Mar 5, 2017 6:48 PM, "Eric Voskuil" <eric at voskuil.org> wrote:
Independent of one's opinion on the merits of one fork or another, the
state of centralization in Bitcoin is an area of great concern. If "we" can
sit down with 75% of the economy and/or 90% of the hash power (which of
course has been done) and negotiate a change to any rule, Bitcoin is a
purely political money.
If "we" can do this, so can "they".
e
There is no doubt that politics play a big role in all of this. Also no
doubt that broader decentralization would be superior. But miner activated
soft forks and user activated soft forks do not need discussions with
centralized parties to move forward. It is merely two different methods for
pushing a soft fork through the network.
The key is that it's a soft fork. Old nodes continue to work as always,
whether the soft fork deploys or not.
User activated soft forks, or perhaps more accurately called 'economically
forced soft forks' are a tool to use if the miners are in clear opposition
to the broader economy. They only work if the broader economy actually
fully supports the soft fork, which is much more difficult to measure than
miner support. And miners with deeper pockets may be able to resist for
some time, effectively performing a rewardless 51% attack and maintaining a
split network for some time. The miners would lose lots of money, but old
nodes would feel all the burn of a hard fork, followed by a sudden deep
reorg when the network finally 'heals'.
I guess in some sense you'd be playing chicken with the miners. If the
split is not instantly successful there would be a lot of damage to old
nodes, even if the majority of new nodes had upgraded. (but there would
also be a lot of damage to the miners).
On Mar 5, 2017 9:31 PM, "Nick ODell" <nickodell at gmail.com> wrote:
>I also think that the UASF is a good idea. Hashrate follows coin price. If
the UASF has the higher coin price, the other chain will be annihilated. If
the UASF has a lower coin price, the user activated chain can still exist
(though their coins can be trivially stolen on the majority chain).
I don't think that's true. Say there are two forks of Blahcoin. Alice
thinks there's a 55% chance that Fork A will succeed. Bob thinks there's a
55% chance that Fork B will succeed. Alice trades all of her Fork B coins
for all of Bob's Fork A coins. Now, Bob and Alice both have a stake in one
fork or the other succeeding. Alice starts spending more time around Fork A
users; Bob starts spending his time with Fork B users.
This is not relevant to a UASF. The existing nodes on the network have a
single formal definition for longest chain. If the UASF is successful, the
old nodes will follow the new soft fork and there will be only one chain.
Spirit of Bitcoin or not, the UASF is successful and there is no coin split
or network fork.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170306/3ec9ee10/attachment.html>

2023-06-07 17:57:02 UTC

- reply

📅 Original date posted:2017-03-05
📝 Original message:I also think that the UASF is a good idea. Hashrate follows coin price. If
the UASF has the higher coin price, the other chain will be annihilated. If
the UASF has a lower coin price, the user activated chain can still exist
(though their coins can be trivially stolen on the majority chain).
The success of the UASF depends entirely on the price. And actually, the
price is easy to manipulate. If you, as an economically active full node,
refuse to acknowledge the old chain and demand that incoming coins arrive
over the UASF chain. In doing so, you drive down the utility of the old
chain and drive up the utility of the new chain. This ultimately impacts
the price.
I think it would be pretty easy to get high confidence of the success of a
UASF. Basically you need all the major economic hubs to agree to upgrade
and then exclusively accept UASF coins. I don't have a comprehensive list,
but if we could sign on 75% of the major exchanges and payment processors,
and get 75% of the wallets to upgrade, then the UASF would be very likely
to successfully obliterate the old rules, as miners would be unable to sell
their coins or pay their bills by stubbornly sticking to the old chain.
It's less risky than a hard fork by far, because there is zero risk of coin
split if the UASF has majority hashrate, which will follow majority
economic value.
A serious proposal I think would get all the code ready and merged, but
without setting a flag day. Then we would get signatures from the major
institutions promising to use the software and saying that they are ready
for a flag day. After that, you release a patch with a flag day 12 months
in the future. People can upgrade immediately, and have a full year to
transition.
That gives tons of time for people to upgrade, and tons of confidence that
the UASF will end up as the majority chain.
If we cannot get enough major exchanges, payment processors, and other
economic hubs to upgrade, the flag day should remain upset, as the risk of
coin split will be non-zero.
I would suggest that a carefully executed UASF is much riskier than a soft
fork, but far, far less risky than a hard fork.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170305/fa9b6571/attachment-0001.html>