David Vorick [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-05-21 to 2019-08-20
💬 Posted a total of 35 messages
📚 Participated in the following categories: Bitcoin-development, softfork proposal, bitcoin-dev, Pre-BIP
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub14h948ndawt32ps3y225sslch8344tmw8k5z0lxuxr6wq9tu6sl2qj9yjx0

Profile Code

nprofile1qqs2mj6nek7h9c4qcgj992gg0utnc664ahrm2p8lnwrpa8qz47dg04qpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds62guss

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub14h948ndawt32ps3y225sslch8344tmw8k5z0lxuxr6wq9tu6sl2qj9yjx0

Show more details

Last Notes

2023-06-07 20:00:21

- 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 20:00:17

- 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 19:59:51

- 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 19:59:28

- reply

📅 Original date posted:2017-04-06
📝 Original message:>
> Another thing that could be done is increase the number of times SHA256 is
> performed... but now we are really talking about altering the PoW
> algorithm. Correct me if I'm wrong: The more number of times its
> performed, the less any patent-able pre or post calculation
> skipping/caching have an effect on efficiency.
>
The more complex that the PoW algorithm is, the more likely it is that
someone finds a unique and special method for optimizing it that they are
able to patent. And the more difficult it is to create specialized hardware
to run that algorithm, meaning that there will be fewer players who are
able to do so profitably (higher fixed costs).
If you want to talk about changing the PoW algorithm, you really want to be
looking to simplify it so that it's more obvious (not that you can ever be
completely sure) that there are no hidden or unexpected optimizations that
someone could patent.
We can even do a lot better than SHA. Cryptographic hash functions need to
be collision resistant, and collision resistance is the property that
usually breaks. Preimage resistance and partial preimage resistance (and
second preimage resistance) is generally easier to protect - to the best of
our knowledge, md5 would actually still be a secure PoW function today.
It's bitterly ironic to me that so much research and effort has been put
into making asic-resistant PoW algorithms when in the long run
asic-resistance only leads to problems like these - single parties who have
found significant optimizations and not shared them, completely destroying
any chance of a level playing field and giving themselves a centralized
monopoly - a result that is supremely unhealthy for the rest of the
community.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/35d33b8c/attachment.html>

2023-06-07 19:59:19

- 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 19:59:18

- 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 19:58:33

- 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 19:58:29

- reply

📅 Original date posted:2017-03-31
📝 Original message:Sure, your math is pretty much entirely irrelevant because scaling systems
to massive sizes doesn't work that way.
At 400B transactions per year we're looking at block sizes of 4.5 GB, and a
database size of petabytes. How much RAM do you need to process blocks like
that? Can you fit that much RAM into a single machine? Okay, you can't fit
that much RAM into a single machine. So you have to rework the code to
operate on a computer cluster.
Already we've hit a significant problem. You aren't going to rewrite
Bitcoin to do block validation on a computer cluster overnight. Further,
are storage costs consistent when we're talking about setting up clusters?
Are bandwidth costs consistent when we're talking about setting up
clusters? Are RAM and CPU costs consistent when we're talking about setting
up clusters? No, they aren't. Clusters are a lot more expensive to set up
per-resource because they need to talk to eachother and synchronize with
eachother and you have a LOT more parts, so you have to build in
redundancies that aren't necessary in non-clusters.
Also worth pointing out that peak transaction volumes are typically 20-50x
the size of typical transaction volumes. So your cluster isn't going to
need to plan to handle 15k transactions per second, you're really looking
at more like 200k or even 500k transactions per second to handle
peak-volumes. And if it can't, you're still going to see full blocks.
You'd need a handful of experts just to maintain such a thing. Disks are
going to be failing every day when you are storing multiple PB, so you
can't just count a flat cost of $20/TB and expect that to work. You're
going to need redundancy and tolerance so that you don't lose the system
when a few of your hard drives all fail within minutes of eachother. And
you need a way to rebuild everything without taking the system offline.
This isn't even my area of expertise. I'm sure there are a dozen other
significant issues that one of the Visa architects could tell you about
when dealing with mission-critical data at this scale.
--------
Massive systems operate very differently and are much more costly per-unit
than tiny systems. Once we grow the blocksize large enough that a single
computer can't do all the processing all by itself we get into a world of
much harder, much more expensive scaling problems. Especially because we're
talking about a distributed system where the nodes don't even trust each
other. And transaction processing is largely non-parallel. You have to
check each transaction against each other transaction to make sure that
they aren't double spending eachother. This takes synchronization and
prevents 500 CPUs from all crunching the data concurrently. You have to be
a lot more clever than that to get things working and consistent.
When talking about scalability problems, you should ask yourself what other
systems in the world operate at the scales you are talking about. None of
them have cost structures in the 6 digit range, and I'd bet (without
actually knowing) that none of them have cost structures in the 7 digit
range either. In fact I know from working in a related industry that the
cost structures for the datacenters (plus the support engineers, plus the
software management, etc.) that do airline ticket processing are above $5
million per year for the larger airlines. Visa is probably even more
expensive than that (though I can only speculate).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170331/229b0e3d/attachment.html>

2023-06-07 19:58:28

- reply

📅 Original date posted:2017-03-31
📝 Original message:No one is suggesting anything like this. The cost of running a node
that could handle 300% of the 2015 worldwide nonbitcoin transaction
volume today would be a rounding error for most exchanges even if
prices didn't rise.
Then explain why PayPal has multiple datacenters. And why Visa has multiple
datacenters. And why the banking systems have multiple datacenters each.
I'm guessing it's because you need that much juice to run a global payment
system at the transaction volumes that they run at.
Unless you have professional experience working directly with transaction
processors handling tens of millions of financial transactions per day, I
think we can fully discount your assessment that it would be a rounding
error in the budget of a major exchange or Bitcoin processor to handle that
much load. And even if it was, it wouldn't matter because it's extremely
important to Bitcoin's security that it's everyday users are able to and
are actively running full nodes.
I'm not going to take the time to refute everything you've been saying but
I will say that most of your comments have demonstrated a similar level of
ignorance as the one above.
This whole thread has been absurdly low quality.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170331/5ce1e10b/attachment.html>

2023-06-07 19:58:26

- reply

📅 Original date posted:2017-03-30
📝 Original message:> What we want is a true fee-market where the miner can decide to make a
block
> smaller to get people to pay more fees, because if we were to go to 16MB
> blocks in one go, the cost of the miner would go up, but his reward based
on
> fees will go down!
> A block so big that 100% of the transactions will always be mined in the
> next block will just cause a large section of people to no longer feel the
> need to pay fees.
> As such I don’t fear the situation where the block size limit goes up a
lot
> in one go, because it is not in anyone’s interest to make the actual block
> size follow.
There have been attacks demonstrated where a malicious miner with
sufficient hashrate can leverage large blocks to exacerbate selfish mining.
Adversarial behaviors from miners need to be considered, it's not safe to
simply assume that a miner won't have reasons to attack the network. We
already know that large empty blocks (rather, blocks with fake
transactions) can be leveraged in ways that both damages the network and
increases miner profits.
In general, fear of other currencies passing Bitcoin is unsubstantiated.
Bitcoin has by far the strongest development team, and also is by far the
most decentralized. To the best of my knowledge, Bitcoin is the only
cryptocurrency out there that is both not-dead and also lacks a strong
central leadership.
A coin like ethereum may even be able to pass Bitcoin in market cap. But
that's okay. Ethereum has very different properties and it's not something
I would trust as a tool to provide me with political sovereignty. Ethereum
passing Bitcoin in market cap does not mean that it has proved superior to
Bitcoin. It could just mean that enterprises are really excited about
permissioned blockchains. That's not interesting to me at any market cap.
Bitcoin's core value add is and should continue to be decentralization and
trustlessness. Nobody is remotely close to competing with Bitcoin on those
fronts, and in my mind that's far more important than any of the other
mania anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/8cc36f43/attachment.html>

2023-06-07 19:58:20

- 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 19:58:17

- 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 19:58:14

- 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 19:58:06

- 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 19:57:26

- reply

📅 Original date posted:2017-03-20
📝 Original message:I am in support of having multiple PoW forks to choose from, but it is
indeed problematic to have one chain running a rotation of algorithms.
The reason I support multiple algos is because we don't want an attacker
secretly making asics ahead of time in the event of an emergency PoW fork.
We want them to be uncertain which of a large selection of algorithms are
going to be used, making pre-emptive asic manufacturing more difficult.
But once an algorithm is chosen that should be the end of the story, just
one algo without rotation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170320/ceaa8c60/attachment.html>

2023-06-07 19:57:16

- reply

📅 Original date posted:2017-03-13
📝 Original message:That's simply a 51% attack choosing to censor transactions. We could do
that today, ban all transactions that aren't approved by the PBoC.
You respond to that with a PoW hardfork, or by finding some way to prop up
/ subsidize non-censorship miners.
On Mar 13, 2017 5:59 AM, "Nick ODell via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The problem with modifying Bitcoin to work around community norms is that
> it's a two-way street. Other people can do it too.
>
> Let me propose a counter-fork, or a "Double UASF." This is also a BIP9
> fork, and it uses, say, bit 2. starttime is 1489449600, and the end time is
> 1506812400. It enforces every rule that UASF enforces, plus one additional
> rule. If 60% of blocks in any retargeting period signal for Double UASF,
> any descendant block that creates or spends a segregated witness output is
> invalid.
>
> Double UASF signaling never coincides with UASF signaling, because the
> signaling periods don't overlap. Full nodes happily validate the chain,
> because Double UASF doesn't break any rules; it just adds new ones. Miners
> who adopt Double UASF don't need to understand segwit, because all segwit
> transactions are banned. Miners don't need to commit to a wtxid structure,
> either. Per BIP 141, "If all transactions in a block do not have witness
> data, the commitment is optional." Segwit is activated, but useless. Miners
> who *do* adopt segwit will lose money, as their blocks are orphaned.
>
> Thanks,
> --Nick
>
> On Sun, Mar 12, 2017 at 9:50 AM, shaolinfry via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I recently posted about so called "user activated soft forks" and
>> received a lot of feedback. Much of this was how such methodologies could
>> be applied to segwit which appears to have fallen under the miner veto
>> category I explained in my original proposal, where there is apparently a
>> lot of support for the proposal from the economy, but a few mining pools
>> are vetoing the activation.
>>
>> It turns out Bitcoin already used flag day activation for P2SH[1
>> <https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283>],
>> a soft fork which is remarkably similar to segwit. The disadvantage of a
>> UASF for segwit is there is an existing deployment. A UASF would require
>> another wide upgrade cycle (from what I can see, around 80% of existing
>> nodes have upgraded from pre-witness, to NODE_WITNESS capability[2
>> <http://luke.dashjr.org/programs/bitcoin/files/charts/services.html>][3
>> <https://www.reddit.com/r/Bitcoin/comments/5yyqt1/evidence_of_widespread_segwit_support_near50_of/>].
>> While absolute node count is meaningless, the uprgrade trend from version
>> to version seems significant.
>>
>> Also it is quite clear a substantial portion of the ecosystem industry
>> has put in time and resources into segwit adoption, in the form of
>> upgrading wallet code, updating libraries and various other integration
>> work that requires significant time and money. Further more, others have
>> built systems that rely on segwit, having put significant engineering
>> resources into developing systems that require segwit - such as several
>> lightning network system. This is much more significant social proof than
>> running a node.
>>
>> The delayed activation of segwit is also holding back a raft protocol of
>> innovations such as MAST, Covenants, Schnorr signature schemes and
>> signature aggregation and other script innovations of which, much of the
>> development work is already done.
>>
>> A better option would be to release code that causes the existing segwit
>> deployment to activate without requiring a completely new deployment nor
>> subject to hash power veto. This could be achieved if the economic majority
>> agree to run code that rejects non-signalling segwit blocks. Then from the
>> perspective of all existing witness nodes, miners trigger the BIP9
>> activation. Such a rule could come into effect 4-6 weeks before the BIP9
>> timeout. If a large part of the economic majority publicly say that they
>> will adopt this new client, miners will have to signal bip9 segwit
>> activation in order for their blocks to be valid.
>>
>> I have drafted a BIP proposal so the community may discuss
>> https://gist.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c (full
>> text below).
>>
>> References:
>> [1]: https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/
>> main.cpp#L1281-L1283
>> [2]: http://luke.dashjr.org/programs/bitcoin/files/charts/services.html
>> [3]: https://www.reddit.com/r/Bitcoin/comments/5yyqt1/eviden
>> ce_of_widespread_segwit_support_near50_of/
>>
>> Proposal text:
>>
>> <pre>
>> BIP: bip-segwit-flagday
>> Title: Flag day activation for segwit deployment
>> Author: Shaolin Fry <shaolinfry at protonmail.ch>
>> Comments-Summary: No comments yet.
>> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
>> Status: Draft
>> Type: Informational
>> Created: 2017-03-12
>> License: BSD-3-Clause
>> CC0-1.0
>> </pre>
>>
>> ==Abstract==
>>
>> This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as "segwit".
>>
>> ==Definitions==
>>
>> "existing segwit deployment" refer to the BIP9 "segwit" deployment using bit 1, between November 15th 2016 and November 15th 2017 to activate BIP141, BIP143 and BIP147.
>>
>> ==Motivation==
>>
>> Cause the mandatory activation of the existing segwit deployment before the end of midnight November 15th 2017.
>>
>> ==Specification==
>>
>> All times are specified according to median past time.
>>
>> This BIP will be activate between midnight October 1st 2017 (epoch time 1538352000) and midnight November 15th 2017 (epoch time 1510704000) if the existing segwit deployment is not activated before epoch time 1538352000. This BIP will cease to be active when the existing segwit deployment activates.
>>
>> While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected.
>>
>> === Reference implementation ===
>>
>> <pre>
>> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017 inclusive
>> if (pindex->GetMedianTimePast() >= 1538352000 && pindex->GetMedianTimePast() <= 1510704000 && !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) {
>> if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params, Consensus::DEPLOYMENT_SEGWIT)) != 0) {
>> return state.DoS(2, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>> }
>> }
>> </pre>
>>
>> ==Backwards Compatibility==
>>
>> This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017.
>>
>> ==Rationale==
>>
>> Historically, the P2SH soft fork (BIP16) was activated using a predetermined flag day where nodes began enforcing the new rules. P2SH was successfully activated with relatively few issues
>>
>> By orphaning non-signalling blocks during the last month of the BIP9 bit 1 "segwit" deployment, this BIP can cause the existing "segwit" deployment to activate without needing to release a new deployment.
>>
>> ==References==
>>
>> [https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation].
>>
>> ==Copyright==
>>
>> This document is placed in the public domain.
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170313/b9619fd6/attachment-0001.html>

2023-06-07 19:57:13

- 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 19:57:11

- reply

📅 Original date posted:2017-03-12
📝 Original message:What, in your appraisal, is the purpose of the block size limit? I think we
will be more able to have a productive discussion around this proposal if
we clear that up first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170312/cb015005/attachment.html>

2023-06-07 19:57:04

- 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 19:57:02

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

2023-06-07 19:55:53

- reply

📅 Original date posted:2017-02-02
📝 Original message:I like the idea of having some way for developers to show that they've
given an idea legitimate consideration, as I feel some proposals are often
considered much more in depth before rejection than the proposer realizes,
however I don't think any sort of on-chain system really makes sense. It
complicates things a lot, adds code, incentives, etc. when really all you
care about is some sort of indication of consideration, support, or
rejection.
I also prefer to think of Bitcoin as a system of vetos rather than a system
of approvals. A lot of times changes will be small, highly technical, and
have no visible impact to your every day user. These types of changes don't
really need support outside the devs. Furthermore, I frankly don't give a
crap if we proposal has support from 85% of the participants if there is a
legitimate technical, social, or political reason that it is a bad idea.
And finally, I don't think it should cost money or political power to raise
an objection. A 13yo who has never been seen before should be able to raise
an objection if they indeed have a legitimate objection. Involving money is
almost certainly going to shut down important valid opinions.
And again, I mostly agree with the motivation. It would be good if it were
easier to figure out who had considered a proposal and what their
objections or praises were. But I would like to see that without any
systemization around what is required to pass or fail a proposal, and with
no barrier to entry (such as voting or sending coins or having a recognized
name like 'Bitfury') to provide an opinion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170202/da014829/attachment.html>

2023-06-07 19:55:23

- reply

📅 Original date posted:2017-01-07
📝 Original message:No, Bitcoin classic only activates if 75% of the _miners_ adopt it. That
says nothing about the broader network and indeed is much easier to achieve
through politicking, bribery, coercion, and other tomfoolery as 75% of the
hashrate is ultimately only a dozen people or so.
You have plenty of channels through which you can make your announcements,
this particular one is not okay.
On Jan 7, 2017 3:12 PM, "Chris Priest via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Bitcoin Classic only activates if 75% of the network adopts it. That
> is not irresponsible or dangerous. It would only be dangerous if it
> activates at 50%, because that would create a situation where its not
> clear which side of the fork has the most proof of work.
>
> On 1/7/17, Eric Lombrozo via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Your release announcement does not make it clear that Bitcoin Classic is
> > incompatible with the current Bitcoin network and its consensus rules. It
> > is a hard fork on mainnet with no safe activation as well as including
> > other unsafe changes. There is also no BIP for the hard fork. There is
> also
> > no evidence of community wide consensus for such a hard fork. This is
> > dangerous and irresponsible.
> >
> >
> > It's wrong to announce software without correctly informing people about
> > the contents or risks. Furthermore, there are no release notes in
> > https://github.com/bitcoinclassic/bitcoinclassic/tree/v1.2.0/doc nor
> > changelog. Without those, it is almost impossible for average users to
> know
> > what is under the hood or what has changed and time consuming for
> > developers to assess.
> >
> > On Fri, Jan 6, 2017 at 2:16 AM, Tom Zander via bitcoin-dev <
> > bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> >> Bitcoin Classic version 1.2.0 is now available from;
> >>
> >> <https://bitcoinclassic.com/gettingstarted.html>
> >>
> >> This is a new major version release, including new features, various
> >> bugfixes and performance improvements.
> >>
> >> This release marks a change in strategy for Bitcoin Classic, moving from
> >> the
> >> very conservative block size proposal based on compromise to one where
> >> Classic truly innovates and provides a long term solution for the market
> >> to
> >> choose and leave behind the restrictions of the old.
> >>
> >> The most visible change in this version is the decentralised block size
> >> solution where node operators decide on the maximum size.
> >>
> >> Bitcoin Classic is focused on providing users a way to get onto the
> >> Bitcoin
> >> network using a high quality validating node for a large set of use
> >> cases.
> >> Classic presents top notch quality processes in this release, to help
> >> anyone
> >> running Bitcoin.
> >>
> >> We include in this release various projects with the beta label. People
> >> who
> >> want to use the Classic node as an on-ramp to Bitcoin will find them
> >> interesting. These projects will need to be enabled in the config by
> >> those
> >> that want to test them.
> >>
> >> More background information on this release and Classic can be seen in
> >> this
> >> video: https://vimeo.com/192789752
> >> The full release notes are on github at
> >> https://github.com/bitcoinclassic/bitcoinclassic/releases/tag/v1.2.0
> >>
> >> --
> >> Tom Zander
> >> Blog: https://zander.github.io
> >> Vlog: https://vimeo.com/channels/tomscryptochannel
> >> _______________________________________________
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170107/cbe422c4/attachment.html>

2023-06-07 19:48:50

- reply

📅 Original date posted:2016-02-10
📝 Original message:> I love seeing data! I was considering 0.10 nodes as 'unmaintained'
because it has been a long time since the 0.11 release.
https://packages.gentoo.org/packages/net-p2p/bitcoin-qt
The Gentoo package manager still has 0.10.2 as the most recent stable
version. Getting a later version of the software on a gentoo setup requires
explicitly telling the package manger to grab a later version. I don't know
what percent of nodes are Gentoo 0.10.2, but I think it's evidence that
0.10 should not be considered 'unmaintained'. People who update their
software regularly will be running 0.10 on Gentoo.
> many of whom have privately told me they are willing and able to run an
extra node or three (or a hundred-and-eleven) once there is a final release.
I'm not clear on the utility of more nodes. Perhaps there is significant
concern about SPV nodes getting enough bandwidth or the network struggling
from the load? Generally though, I believe that when people talk about the
deteriorating full node count they are talking about a reduction in
decentralization. Full nodes are a weak indicator of how likely something
like a change in consensus rules is to get caught, or how many people you
would need to open communication with / extort in order to be able to force
rules upon the network. Having a person spin up multiple nodes doesn't
address either of those concerns, which in my understanding is what most
people care about. My personal concern is with the percentage of the
economy that is dependent on trusting the full nodes they are connected to,
and the overall integrity of that trust. (IE how likely is it that my SPV
node is going to lie to me about whether or not I've received a payment).
I will also point out that lots of people will promise things when they are
seeking political change. I don't know what percentage of promised nodes
would actually be spun up, but I'm guessing that it's going to be
significantly less than 100%. I have similar fears for companies that claim
they have tested their infrastructure for supporting 2MB blocks. Talk is
cheap.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160210/2aed4f42/attachment.html>

2023-06-07 19:37:42

- reply

📅 Original date posted:2015-08-22
📝 Original message:I am not sure that this is on-topic for the bitcoin-dev mailing list, but
it seems politically relevant enough that I'm going to respond.
/r/bitcoin and bitcointalk.org are both discussion websites that pertain to
a specific topic. All (or nearly all) discussion websites pertaining to a
specific topic have a set of rules that get enforced to facilitate relevant
and interesting discussion. These rules help to block spam, and help to
make sure that discussions happen in their appropriate places. The rules in
place on the two primary bitcoin discussion sites have helped facilitate a
large userbase frequented by many relevant experts. I do believe that we
can thank the strict moderation policies for much of the activity that
happens which is technically interesting.
/r/bitcoin and bitcointalk.org are both centralized forums. As such, the
rules are going to be set by a centralized authority. The rules set have
been set to keep the discussion as interesting and relevant as possible.
When a certain theme becomes a massive echo chamber or little more than
beating a dead horse, it makes sense to implement moderation. Calling it
'censorship' is misleading, because a government authority is not
threatening punishment for the discussion of a certain topic. People are
not banned from visiting forums or websites where off-topic (or
against-the-rules) discussion is happening. People's /r/bitcoin rights are
not being revoked because they are subscribed to a controvertial subreddit.
That would be censorship.
Many people are clearly unhappy with the moderation happening on /r/bitcoin
and bitcointalk.org. Luckily, the switching cost for online discussion
forums is very low. I'm now going to invite people to post links to bitcoin
discussion forums where the moderation authority is different.
I know that a recently popular subreddit is /r/bitcoin_uncensored
I am interested to see what other forums people think are worth mentioning.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150822/83360e1e/attachment.html>

2023-06-07 17:49:08

- reply

2023-06-07 17:37:05

- reply

📅 Original date posted:2015-06-20
📝 Original message:I disagree that 11 is a reasonable value. That's less than 2 hours, which
probably wouldn't even last peak trading hours. You want the mempool to be
big enough that low-fee transactions introduced during peak hours are still
around when there's much less activity (it maximizes miner profit and
prevents people/wallets from needing to resubmit after activity has died
down).
I think you'd want something closer to 72. At 1mb or even 8mb blocks, the
memory requirements are pretty reasonable. 20mb blocks and you may have to
reconsider that limit.
On Tue, Jun 9, 2015 at 3:03 PM, Raystonn . <raystonn at hotmail.com> wrote:
> You are right of course. This will work. I like this idea more than
> my own proposed fix, as it doesn’t make any big changes to the economics of
> the system in the way that burning would have.
>
> *From:* Gavin Andresen <gavinandresen at gmail.com>
> *Sent:* Tuesday, June 09, 2015 11:25 AM
> *To:* Raystonn . <raystonn at hotmail.com>
> *Cc:* Loi Luu <loi.luuthe at gmail.com> ; Bitcoin Dev
> <bitcoin-development at lists.sourceforge.net>
> *Subject:* Re: [Bitcoin-development] New attack identified and potential
> solution described: Dropped-transaction spam attack against the block size
> limit
>
> On Tue, Jun 9, 2015 at 1:52 PM, Raystonn . <raystonn at hotmail.com> wrote:
>
>> That does sound good on the surface, but how do we enforce #1 and #2?
>> They seem to be unenforceable, as a miner can adjust the size of the memory
>> pool in his local source.
>>
>
> It doesn't have to be enforced. As long as a reasonable percentage of hash
> rate is following that policy an attacker that tries to flood the network
> will fail to prevent normal transaction traffic from going through and will
> just end up transferring some wealth to the miners.
>
> Although the existing default mining policy (which it seems about 70% of
> hashpower follows) of setting aside some space for high-priority
> transactions regardless of fee might also be enough to cause this attack to
> fail in practice.
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/792f2553/attachment.html>