Nostr notes by

📅 Original date posted:2017-06-13 📝 Original message:> ...

2023-06-07T18:03:10Z

In reply to nevent1q…hls9
_________________________

📅 Original date posted:2017-06-13
📝 Original message:> Wallet nodes being able to fully validate and choose whether or not to
accept a particular chain is an important part of bitcoins security
model.

What you're describing is effectively the same as BU.

Nodes follow chains, they do not decide the victor. The average user
follows the default of the software, which is to follow the longest valid
chain. Forcing the average user to decide which software to run is far
more valuable than allowing "the software" to decide things, when in fact
all it will do is decide the previous default.

> One would not want to
> use this method to try and activate a controversial hard fork since
> it's trivial for miners to false signal. The orphaning period
> effectively forces miners to make a decision but does not necessarily
> force them to make a particular decision

This is true and a good point. A false signal from miners could trick the
honest miners into forking off prematurely with a minority.

> it only lets
> you see the nversion of the current stratum job since you don't get a
> full bock header. There's always a risk here that miners build on top
> of invalid blocks when SPV mining.

This is the job of the stratum server and the pool operator. These are
distinct responsibilities; Miners should choose a pool operator in line
with their desires. Solo mining is basically dead, as it will never again
be practical(and has not been for at least 2 years) for the same hardware
that does the mining to also do full node operation.

If the pool operator/stratum server also does not do validation, then any
number of problems could occur.

On Mon, Jun 12, 2017 at 10:44 PM, James Hilliard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Mon, Jun 12, 2017 at 9:23 PM, Zheming Lin via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > The BIP is described using Chinese and English. If any part is missing
> or need more specific, please reply. Forgive for my poor English.
> >
> > This method will incorporate any upgrade that affects non-mining nodes.
> They should beware that the rule has been changed.
> >
> > TLDR: Major miners activate and orphan the minor. That ensures all
> miners upgrades. Then invalid the tx from not upgrading nodes. Nodes must
> upgrade (with other protocol upgrade codes) in order to work. Then the
> final miner vote over protocol upgrade, with all nodes has the same
> upgraded codes.
> >
> > <pre>
> > BIP: ???
> > Title: Demonstration of Phase in Full Network Upgrade Activated by Miners
> > Author: LIN Zheming
> > Status: Draft
> > Type: Standards Track
> > Created: 2017-06-12
> > </pre>
> >
> > ==Summary==
> >
> > 本方法并不是来源于个人，而是中文比特币社区中集体智慧的结果。 
> > This idea was not created by an individual but is a product of
> collaboration in the Chinese bitcoin community between different interest
> groups. 
> >
> > 这是一种在协议升级时，对全网挖矿和非挖矿节点进行保护和激励的方法，避免不参与挖矿的节点没有升级的动力而受到损失。 
> > This method is put forth to incentivize and to protect mining nodes and
> non-mining nodes during protocol upgrading. With this incentive mechanism,
> the non-mining nodes will not suffer monetary loss from chain
> splitting. 
> >
> > 发信号的多数矿工在达到激活条件后第一个宽限期（一个难度周期）后设置新区块版本号，孤立未升级矿工的低版本号的块。
> 通过最初的中本聪共识，在第一个宽限期结束后，所有矿工将升级至最新版本或使用最新版本。在第二个宽限期（一个难度周期）后，矿工将仅接受新版本的交易，
> 未升级的客户端发送的旧版本交易将无法得到新节点的转播也无法进入新版本区块。这将在保护用户资产的同时，提醒不挖矿的钱包节点升级。
> 并在升级代码中加入对协议进行改动的部分。钱包升级后将由挖矿节点投票实施该项改动，以达成协议改动的广泛部署。 
> >
> > After the activation condition is met, majority miners will set a new
> block versionbits after the first grace period(a difficulty change of 2016
> blocks). The blocks with lower versionbits will be orphaned. In terms of
> the Nakamoto Consensus, the end of the first grace period will force all
> mining nodes upgraded to signal a new version of consensus. After the
> second grace period ( a difficulty change of 2016 blocks), mining nodes
> will only accept transactions with new versionbits. Transactions from nodes
> not upgrading will not be relayed nor included in blocks with new
> versionbits. This will protect funds of non-mining nodes from utilizing
> replay attack and will function as a notification for them to upgrade.
> Codes dealing with protocol upgrade could be included in the upgrade. After
> the non-mining node upgrades, mining nodes will vote to activate the
> protocol upgrade and this will achieve the broad/widespread deployment of
> the protocol upgrade. 
> >
> > 在该项改动广泛部署至客户端之后，依然由其激活条件控制。 
> > The protocol upgrade depends on its activate condition independently
> even after the change deployed among nodes. 
> >
> > ==Motivation==
> >
> > 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。
> 当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受
> 的链。这将影响钱包节点的安全。 
> > In view of the fact that the original Bitcoin consensus did not consider
> the non-mining wallet nodes(as mentioned above), the result is that
> upgrading the consensus of these wallet nodes is passive and lazy. When
> there is disagreement in the direction of the upgrade, the miners have no
> mechanism to ensure that the chain being extended is the chain widely
> accepted by the wallet nodes. This also adversely affects the security of
> the wallet nodes. 
> Wallet nodes being able to fully validate and choose whether or not to
> accept a particular chain is an important part of bitcoins security
> model.
> >
> > 使用该方法可以在保证钱包节点资产安全的情况下，且通过增加激励让钱包节点升级协议。一旦钱包节点升级协议，保证矿工节点不仅工作在算力最长链上，
> 还工作在比特币生态环境中其他钱包节点所使用的最长链上。在中本聪共识下不会出现分叉，以实现渐进式的协议升级。 
> >
> > Apart from ensuring the asset security of wallet nodes, this method can
> be used to provide additional incentives to upgrade the protocol for the
> wallet nodes. Once the wallet nodes upgrade their protocol, the miners'
> nodes can be guaranteed to work - not only on the longest chain, but also
> on the longest chain used by other wallet nodes in the broader bitcoin
> sphere. Under the Nakamoto Consensus, there will be no persistent forks as
> protocol upgrades can be phased in. 
> There is no way to guarantee a wallet node will accept a particular
> block since that is always up to the user.
> >
> > ==Specification==
> >
> > 1. 挖矿节点将使用 versionbits 版本位来定义支持信号。BIP 生效时，所有区块需要使用制定的 nVersion 来发送信号 
> > 2. 挖矿节点将使用 tx version 来定义当前的交易版本。当前的 tx version 是 1，将允许 tx version 为 2
> 的交易，并在第二个宽限期之后，使 tx version 为 1 的交易非法。 
> >
> > 1. Mining nodes signal by setting a version bit. While this BIP is
> active, all blocks must set the chosen nVersion. 
> > 2. Mining nodes will use tx version to define current version
> transactions. Current tx version is 1, and tx version 2 will be allowed.
> After the second grace period, tx version 1 will be regarded as
> invalid. 
> Sounds like this would cause issues with pre-signed time locked
> transactions.
> >
> >
> > ==Deployment==
> > 协议升级，将分成三步逐步实施。并有一个可选的第四步来集成协议升级代码。 
> >
> > Protocol upgrading will phase in over three stages. We can have an
> optional fourth stage to integrate codes of protocol upgrade. 
> >
> > 1. 信号阶段。挖矿节点使用 versionbits 发送支持信号。挖矿节点在监测到 55% 的区块即前 1109/2016
> 个区块均发送了相同的支持信号，进入下一阶段。 
> > 2. 矿工节点升级。经过了第一个宽限期 2016 的区块后，且总信号区块超过了 2218/4032，就开始使用新的区块版本打包区块，
> 并同时开始孤立旧版本。此时所有节点和钱包，将可以使用新版本号发送交易，同时兼容旧版本号交易。 
> > 3. 钱包节点升级。在挖矿节点监测到第二个宽限期 4032 个连续的新版本的区块后，开始拒绝旧版本号的交易，只打包／
> 转播新版本号的交易。同时将从内存池中删除旧版本号的交易。 
> > 4. （可选的）协议升级。在第三阶段中包含有第四阶段的升级代码。当我们确保钱包节点升级到支持新版本交易后，必然包含了第四阶段的升级代码。
> 则此时可以通过矿工节点投票的方式完成全网络的协议升级。
> >
> > 1. Signal stage: Mining nodes signal using BIP9. The next stage will be
> activated after 55% (1109) of 2016 blocks has the signal. 
> >
> > 2. Mining nodes upgrade stage: After a first grace period of 2016 blocks
> and total signalling blocks passed 2218 of 4032 blocks, miners broadcasting
> blocks with new versionbits in block headers will orphan blocks with old
> versionbits. At this stage all nodes can send transactions with new
> versionbits, and transactions with old versionbits will be compatible. 
> >
> > 3. Non-mining nodes upgrade stage: after 4032 continuous blocks with new
> versionbits, mining nodes will start to refuse transactions with old
> versionbits. Only transactions with new versionbits can be relayed and
> included in blocks. Transactions with old versionbits can be safely purged
> from memory pools. 
> >
> > 4. (Optional)Protocol Upgrade stage: The codes dealing with protocol
> upgrade can be integrated in the third stage. After the non-mining nodes
> upgrades to support newer version of transactions, the codes with protocol
> upgrade must be included and now we can use miner vote to activate and
> finish this upgrade. 
> >
> > 至此，协议升级完成。 
> >
> > At this point, the protocol upgrade have phased in. 
> >
> > ==Benefits==
> >
> > 1. 仅需要多数的矿工发信号后即可激活。在中本聪的比特币论文中，99.9% 的可能性下，55% 的矿工将在 340 个区块后确保成为最长链。
> 这将最大可能减小通过控制少数算力而拖延网络升级的可能性。我们可以预见到在算力信号超过 51%
> 后，挖矿节点将迅速的在第一个宽限期内进行升级。 
> > 2. 在两个宽限期内，钱包节点交易不受影响，有足够的时间升级钱包软件。 
> > 3. 版本信息包含在 block header 中，并不影响 SPV 挖矿过程。（看起来是？） 
> > 4. 在两个宽限期后，钱包节点将必须升级钱包，否则因没有算力支持将无法发送交易，也无法确认。
> 相对于在节点间重新达成新的共识，这种状况并没有更糟糕。 
> > 5. 钱包节点的账本将得到尊重和保护。使用链下钱包的用户将需要在钱包服务提供商的声明之后决定提至链上钱包或跟随。 
> > 6. 将来的协议升级，可以在升级客户端版本同时绑定协议升级代码并进行独立的激活投票。这将预留足够的时间让节点升级软件以支持新的协议。
> 即使矿工投票激活失败也不影响现状。 
> >
> > 1. The activation only requires majority miners signal. As described in
> the paper by Satoshi Nakamoto, 55% miners will be in the longest chain
> after 340 blocks, with 99.9% certainty. This will minimize the possibility
> of delaying network upgrades by controlling a small number of hashing
> power. We can foresee that after 51% signalling, all miners will upgrade
> within the first grace period. 
> Technically soft forks can be implemented at 55% hashpower already
> without an orphaning period(like BIP16). Those that don't upgrade
> would just be at risk of mining invalid blocks. One would not want to
> use this method to try and activate a controversial hard fork since
> it's trivial for miners to false signal. The orphaning period
> effectively forces miners to make a decision but does not necessarily
> force them to make a particular decision since they can simply choose
> to reject the fork and false signal.
> > 2. During the first two grace periods, non-mining nodes will not be
> affected. They have enough time to upgrade their software. 
> > 3. Versionbits included in block header, not influencing the SPY mining.
> 
> The widely deployed stratum based SPV mining does not really provide a
> proper way to validate nversion of the previous block, it only lets
> you see the nversion of the current stratum job since you don't get a
> full bock header. There's always a risk here that miners build on top
> of invalid blocks when SPV mining.
> > 4. After two grace periods, all nodes must be upgraded. Otherwise they
> cannot send transactions or get any confirmations. Compared with forming
> new consensus among nodes, the situation is not worse than before. 
> Previous consensus changes have largely been done in backwards
> compatible ways which lets users opt-in to new features. In general
> backwards compatibility is considered a good thing, this seems to make
> that worse.
> > 5. The ledger in non-mining wallet nodes is honored and reserved. Users
> of off-chain wallet services can decide whether or not to follow the
> service providers after they got the public notification from the service
> providers. 
> > 6. Protocol upgrades in the future can be bonded with the upgrades of
> nodes, and the upgrades activate through miners vote independently. There
> would be enough time for nodes to be upgraded in order to support new
> protocols. Even in case of failing in miner activation, the situation will
> not worsen and the status quo will remain. 
> >
> >
> > ==Risks==
> >
> > 1. 算力的波动会影响最长链的结果。因此越高的激活比例要求将减少短时间分叉的危险。 
> > 2. 矿工可能发假信号来避免被孤立，但在钱包节点看来无法区分是否是假信号，只能升级。而钱包节点升级之后，矿工也将跟随。 
> > 3. 钱包节点可能发假信号来仅升级版本号而不支持绑定的协议升级代码，但钱包节点数量无法判别，
> 严肃的真实节点应当跟随可证实的矿工投票结果。 
> > 4. 存在少部分矿工和钱包节点共谋，在新协议升级激活后依然使用老协议挖矿的可能。这种可能随时发生无法杜绝，
> 但通过让沉默的大多数钱包节点升级的方式可以降低这种行为带来的利益。 
> >
> > 1. The fluctuation of the hashing power will affect the result of the
> longest chain. Higher activating requirement means a lower risk of
> temporary fork. 
> > 2. Miners could simply signal to avoid being orphaned, but from the
> perspective of non-mining wallet nodes, they can't distinguish the false
> signal from the true signal. They must upgrade with the assumption that the
> signals are all true. After all the non-mining nodes have upgraded, the
> miners signalling false signal should follow. 
> Miners can simply announce they are false signalling with coinbase
> tags and other methods. This activation method would likely not be
> viable for controversial changes.
> > 3. Non-mining wallet nodes could false signal without supporting the new
> protocol but since the total number of nodes cannot be distinguished,
> genuine nodes should follow the proven result provided by miners vote. 
> Users would likely take into account markets and other factors when
> deciding what to do, the total number of nodes doesn't really matter
> much. Miner signalling is not necessarily indicative of economic and
> user support.
> > 4. Miners and non-mining nodes could conspire to fork using old protocol
> consensus. It can't be eliminated, just like in the past but through most
> passive non-mining nodes being upgraded, their benefit is reduced. 
> >
> >
> > ==Implementation==
> > ___TBD___
> >
> > _______________________________________________
> > 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/20170613/1f587ffa/attachment-0001.html>;

📅 Original date posted:2017-06-07 📝 Original message:I ...

2023-06-07T18:02:32Z

In reply to nevent1q…unaf
_________________________

📅 Original date posted:2017-06-07
📝 Original message:I think this BIP represents a gamble, and the gamble may not be a good
one. The gamble here is that if the segwit2x changes are rolled out
on time, and if the signatories accept the bit4 + bit1 signaling
proposals within BIP91, the launch will go smoother, as intended. But
conversely, if either the segwit2x signatories balk about the Bit1
signaling OR if the timelines for segwit2mb are missed even by a bit,
it may cause the BIP148 chainsplit to be worse than it would be
without. Given the frequent concerns raised in multiple places about
the aggressiveness of the segwit2x timelines, including the
non-hardfork timelines, this does not seem like a great gamble to be
making.

The reason I say it may make the chainsplit be worse than it would
otherwise be is that it may provide a false sense of safety for BIP148
that currently does not currently exist(and should not, as it is a
chainsplit). That sense of safety would only be legitimate if the
segwit2x signatories were on board, and the segwit2x code effectively
enforced BIP148 simultaneously, neither of which are guaranteed. If
users and more miners had a false sense that BIP148 was *not* going to
chainsplit from default / segwit2x, they might not follow the news if
suddenly the segwit2x plan were delayed for a few days. While any
additional support would definitely be cheered on by BIP148
supporters, the practical reality might be that this proposal would
take BIP148 from the "unlikely to have any viable chain after flag day
without segwit2x" category into the "small but viable minority chain"
category, and even worse, it might strengthen the chainsplit just days
before segwit is activated on BOTH chains, putting the BIP148
supporters on the wrong pro-segwit, but still-viable chain.

If Core had taken a strong stance to include BIP148 into the client,
and if BIP148 support were much much broader, I would feel differently
as the gamble would be more likely to discourage a chainsplit (By
forcing the acceleration of segwit2x) rather than encourage it (by
strengthening an extreme minority chainsplit that may wind up on the
wrong side of two segwit-activated chains). As it stands now, this
seems like a very dangerous attempt to compromise with a small but
vocal group that are the ones creating the threat to begin with.

Jared

On Tue, Jun 6, 2017 at 5:56 PM, James Hilliard via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Due to the proposed calendar(https://segwit2x.github.io/) for the
> SegWit2x agreement being too slow to activate SegWit mandatory
> signalling ahead of BIP148 using BIP91 I would like to propose another
> option that miners can use to prevent a chain split ahead of the Aug
> 1st BIP148 activation date.
>
> The splitprotection soft fork is essentially BIP91 but using BIP8
> instead of BIP9 with a lower activation threshold and immediate
> mandatory signalling lock-in. This allows for a majority of miners to
> activate mandatory SegWit signalling and prevent a potential chain
> split ahead of BIP148 activation.
>
> This BIP allows for miners to respond to market forces quickly ahead
> of BIP148 activation by signalling for splitprotection. Any miners
> already running BIP148 should be encouraged to use splitprotection.
>
> <pre>
> BIP: splitprotection
> Layer: Consensus (soft fork)
> Title: User Activated Soft Fork Split Protection
> Author: James Hilliard <james.hilliard1 at gmail.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-3-Clause
> CC0-1.0
> </pre>
>
> ==Abstract==
>
> This document specifies a coordination mechanism for a simple majority
> of miners to prevent a chain split ahead of BIP148 activation.
>
> ==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==
>
> The biggest risk of BIP148 is an extended chain split, this BIP
> provides a way for a simple majority of miners to eliminate that risk.
>
> This BIP provides a way for a simple majority of miners to coordinate
> activation of the existing segwit deployment with less than 95%
> hashpower before BIP148 activation. Due to time constraints unless
> immediately deployed BIP91 will likely not be able to enforce
> mandatory signalling of segwit before the Aug 1st activation of
> BIP148. This BIP provides a method for rapid miner activation of
> SegWit mandatory signalling ahead of the BIP148 activation date. Since
> the primary goal of this BIP is to reduce the chance of an extended
> chain split as much as possible we activate using a simple miner
> majority of 65% over a 504 block interval rather than a higher
> percentage. This BIP also allows miners to signal their intention to
> run BIP148 in order to prevent a chain split.
>
> ==Specification==
>
> 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.
>
> ==Deployment==
>
> This BIP will be deployed by "version bits" with a 65%(this can be
> adjusted if desired) activation threshold BIP9 with the name
> "splitprotecion" and using bit 2.
>
> This BIP starts immediately and is a BIP8 style soft fork since
> mandatory signalling will start on midnight August 1st 2017 (epoch
> time 1501545600) regardless of whether or not this BIP has reached its
> own signalling threshold. This BIP will cease to be active when segwit
> is locked-in.
>
> === Reference implementation ===
>
> <pre>
> // Check if Segregated Witness is Locked In
> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
> Consensus::Params& params)
> {
> LOCK(cs_main);
> return (VersionBitsState(pindexPrev, params,
> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
> THRESHOLD_LOCKED_IN);
> }
>
> // SPLITPROTECTION mandatory segwit signalling.
> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==
> THRESHOLD_LOCKED_IN &&
> !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> // Segwit is not locked in
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
> and is not active.
> {
> bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> VERSIONBITS_TOP_BITS;
> bool fSegbit = (pindex->nVersion &
> VersionBitsMask(chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SEGWIT)) != 0;
> if (!(fVersionBits && fSegbit)) {
> return state.DoS(0, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
> }
> }
>
> // BIP148 mandatory segwit signalling.
> int64_t nMedianTimePast = pindex->GetMedianTimePast();
> if ( (nMedianTimePast >= 1501545600) && // Tue 01 Aug 2017 00:00:00 UTC
> (nMedianTimePast <= 1510704000) && // Wed 15 Nov 2017 00:00:00 UTC
> (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> // Segwit is not locked in
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )
> // and is not active.
> {
> bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> VERSIONBITS_TOP_BITS;
> bool fSegbit = (pindex->nVersion &
> VersionBitsMask(chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SEGWIT)) != 0;
> if (!(fVersionBits && fSegbit)) {
> return state.DoS(0, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
> }
> }
> </pre>
>
> https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:splitprotection-v0.14.1
>
> ==Backwards Compatibility==
>
> This deployment is compatible with the existing "segwit" bit 1
> deployment scheduled between midnight November 15th, 2016 and midnight
> November 15th, 2017. This deployment is also compatible with the
> existing BIP148 deployment. This BIP is compatible with BIP91 only if
> BIP91 activates before it and before BIP148. Miners will need to
> upgrade their nodes to support splitprotection otherwise they may
> build on top of an invalid block. While this bip is active users
> should either upgrade to splitprotection or wait for additional
> confirmations when accepting payments.
>
> ==Rationale==
>
> Historically we have used IsSuperMajority() to activate soft forks
> such as BIP66 which has a mandatory signalling requirement for miners
> once activated, this ensures that miners are aware of new rules being
> enforced. This technique can be leveraged to lower the signalling
> threshold of a soft fork while it is in the process of being deployed
> in a backwards compatible way. We also use a BIP8 style timeout to
> ensure that this BIP is compatible with BIP148 and that BIP148
> compatible mandatory signalling activates regardless of miner
> signalling levels.
>
> By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
> deployment, this BIP can cause the existing "segwit" deployment to
> activate without needing to release a new deployment. As we approach
> BIP148 activation it may be desirable for a majority of miners to have
> a method that will ensure that there is no chain split.
>
> ==References==
>
> *[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html
> Mailing list discussion]
> *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283
> P2SH flag day activation]
> *[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]
> *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
> *[[bip-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]]
> *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]
> *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for
> Version 0 Witness Program]]
> *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]]
> *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]
> *[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]
> *[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits]
>
> ==Copyright==
>
> This document is dual licensed as BSD 3-clause, and Creative Commons
> CC0 1.0 Universal.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2017-06-02 📝 Original message:> ...

2023-06-07T18:02:20Z

In reply to nevent1q…pw2k
_________________________

📅 Original date posted:2017-06-02
📝 Original message:> Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has quadratic hashing risks, and maybe James' 10KB is too ambitious; but even if so, a simple 1MB tx size limit would clearly do the trick. The broader point is that quadratic hashing is not a compelling reason to keep blockmaxsize post-HF: does someone have a better one?

I think this is exactly the right direction to head. There are
arguments to be made for various maximum sizes... Maybe the limit
could be set to 1mb initially, and at a distant future block
height(years?) automatically drop to 500kb or 100kb? That would give
anyone with existing systems or pre-signed transactions several years
to adjust to the change. Notification could (?possibly?) be done with
a non-default parameter that must be changed to continue to use 100kb
- <1mb transactions, so no one running modern software could claim
they were not informed when that future date hits.

I don't see any real advantages to continuing to support transactions
larger than 100kb excepting the need to update legacy use cases /
already signed transactions.

On Tue, May 30, 2017 at 8:07 PM, Jacob Eliosoff via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has
> quadratic hashing risks, and maybe James' 10KB is too ambitious; but even if
> so, a simple 1MB tx size limit would clearly do the trick. The broader
> point is that quadratic hashing is not a compelling reason to keep
> blockmaxsize post-HF: does someone have a better one?
>
>
>
> On May 30, 2017 9:46 PM, "Jean-Paul Kogelman via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> That would invalidate any pre-signed transactions that are currently out
>> there. You can't just change the rules out from under people.
>>
>>
>> On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>
>>>
>>> The 1MB classic block size prevents quadratic hashing
>>> problems from being any worse than they are today.
>>>
>>
>> Add a transaction-size limit of, say, 10kb and the quadratic hashing
>> problem is a non-issue. Donezo.
>>
>> _______________________________________________
>> 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
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2017-04-09 📝 Original message:I can ...

2023-06-07T17:59:51Z

In reply to nevent1q…h9ew
_________________________

📅 Original date posted:2017-04-09
📝 Original message: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.
>
>
> On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Jimmy Song,
>>
>> Why would the actual end users of Bitcoin (the long term and short term
>> owners of bitcoins) who run fully verifying nodes want to change Bitcoin
>> policy in order to make their money more vulnerable to 51% attack?
>>
>> If anything, we would be making policy changes to prevent the use of
>> patented PoW algorithms instead of making changes to enable them.
>>
>> Thanks,
>> Praxeology Guy
>>
>> _______________________________________________
>> 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/20170409/8d1ffe05/attachment-0001.html>;

📅 Original date posted:2017-04-06 📝 Original message:To me, ...

2023-06-07T17:59:21Z

In reply to nevent1q…gzpt
_________________________

📅 Original date posted:2017-04-06
📝 Original message:To me, all of these miss the main objection. If a miner found an
optimization and kept it for themselves, that's their prerogative.
But if that optimization also happens to directly discourage the
growth and improvement of the protocol in many unforseen ways, and it
also encourages the miner to include fewer transactions per block,
that directly hurts Bitcoin and its future. Something should clearly
be done about it when the latter is at issue. I agree with you that
the former is a relative nonissue.

On Wed, Apr 5, 2017 at 11:24 PM, 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.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2017-04-01 📝 Original message:> ...

2023-06-07T17:58:42Z

In reply to nevent1q…mgth
_________________________

📅 Original date posted:2017-04-01
📝 Original message:> If a typical personal computer cannot run a node
> there is no security.

If you can't describe an attack that is made possible when typical
personal computers can't run nodes, this kind of logic has no place in
this discussion.

On Fri, Mar 31, 2017 at 4:13 PM, Eric Voskuil via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 03/31/2017 02:23 PM, Rodney Morris via bitcoin-dev wrote:
>> If the obsession with every personal computer being able to run a
>> fill node continues then bitcoin will be consigned to the dustbin
>> of history,
>
> The cause of the block size debate is the failure to understand the
> Bitcoin security model. This failure is perfectly exemplified by the
> above statement. If a typical personal computer cannot run a node
> there is no security.
>
> e
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQEcBAEBCAAGBQJY3uJ8AAoJEDzYwH8LXOFOrBoH/1VdXQObKZ2JPHL387Sd8qT4
> zzWt8tKFD+6/uCS8re97h1lZcbwb3EzBOB1J15mJ3fqTOU/rPCitN+JZAMgpw/z9
> NGNp4KQDHo3vLiWWOq2GhJzyVAOcDKYLsY8/NrHK91OtABD2XIq9gERwRoZZE4rb
> OPSjSAGvDK8cki72O7HpyEKX5WEyHsHNK/JmBDdTjlzkMcNEbBlYMgO24RC6x+UA
> 8Fh17rOcfGv6amIbmS7mK3EMkkGL83WmsgJKXNl4inI1R8z5hVKRqOFMPxmTDXVc
> dEHtw8poHOX1Ld85m0+Tk2S7IdH66PCnhsKL9l6vlH02uAvLNfKxb+291q2g3YU=
> =HPCK
> -----END PGP SIGNATURE-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2017-04-01 📝 Original message:> ...

2023-06-07T17:58:41Z

In reply to nevent1q…uc3q
_________________________

📅 Original date posted:2017-04-01
📝 Original message:> 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.

When I first began to enter the blocksize debate slime-trap that we
have all found ourselves in, I had the same line of reasoning that you
have now. It is clearly untenable that blockchains are an incredibly
inefficient and poorly designed system for massive scales of
transactions, as I'm sure you would agree. Therefore, I felt it was
an important point for people to accept this reality now and stop
trying to use Blockchains for things they weren't good for, as much
for their own good as anyone elses. I backed this by calculating some
miner fee requirements as well as the very issue you raised. A few
people argued with me rationally, and gradually I was forced to look
at a different question: Granted that we cannot fit all desired
transactions on a blockchain, how many CAN we effectively fit?

It took another month before I actually changed my mind. What changed
it was when I tried to make estimations, assuming all the reasonable
trends I could find held, about future transaction fees and future
node costs. Did they need to go up exponentially? How fast, what
would we be dealing with in the future? After seeing the huge
divergence in node operational costs without size increases($3 vs
$3000 after some number of years stands out in my memory), I tried to
adjust various things, until I started comparing the costs in BTC
terms. I eventually realized that comparing node operational costs in
BTC per unit time versus transaction costs in dollars revealed that
node operational costs per unit time could decrease without causing
transaction fees to rise. The transaction fees still had to hit $1 or
$2, sometimes $4, to remain a viable protection, but otherwise they
could become stable around those points and node operational costs per
unit time still decreased.

None of that may mean anything to you, so you may ignore it all if you
like, but my point in all of that is that I once used similar logic,
but any disagreements we may have does not mean I magically think as
you implied above. Some people think blockchains should fit any
transaction of any size, and I'm sure you and I would both agree
that's ridiculous. Blocks will nearly always be full in the future.
There is no need to attempt to handle unusual volume increases - The
fee markets will balance it and the use-cases that can barely afford
to fit on-chain will simply have to wait for awhile. The question is
not "can we handle all traffic," it is "how many use-cases can we
enable without sacrificing our most essential features?" (And for
that matter, what is each essential feature, and what is it worth?)

There are many distinct cut-off points that we could consider. On the
extreme end, Raspberry Pi's and toasters are out. Data-bound mobile
phones are out for at least the next few years if ever. Currently the
concern is around home user bandwidth limits. The next limit after
that may either be the CPU, memory, or bandwidth of a single top-end
PC. The limit after that may be the highest dataspeeds that large,
remote Bitcoin mining facilities are able to afford, but after fees
rise and a few years, they may remove that limit for us. Then the
next limit might be on the maximum amount of memory available within a
single datacenter server.

At each limit we consider, we have a choice of killing off a number of
on-chain usecases versus the cost of losing the nodes who can't reach
the next limit effectively. I have my inclinations about where the
limits would be best set, but the reality is I don't know the numbers
on the vulnerability and security risks associated with various node
distributions. I'd really like to, because if I did I could begin
evaluating the costs on each side.

> How much RAM do you need to process blocks like that?

That's a good question, and one I don't have a good handle on. How
does Bitcoin's current memory usage scale? It can't be based on the
UTXO, which is 1.7 GB while my node is only using ~450mb of ram. How
does ram consumption increase with a large block versus small ones?
Are there trade-offs that can be made to write to disk if ram usage
grew too large?

If that proved to be a prohibitively large growth number, that becomes
a worthwhile number to consider for scaling. Of note, you can
currently buy EC2 instances with 256gb of ram easily, and in 14 years
that will be even higher.

> So you have to rework the code to operate on a computer cluster.

I believe this is exactly the kind of discussion we should be having
14 years before it might be needed. Also, this wouldn't be unique -
Some software I have used in the past (graphite metric collection)
came pre-packaged with the ability to scale out to multiple machines
split loads and replicate the data, and so could future node software.

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

Bandwidth costs are, as intra-datacenter bandwidth is generally free.
The other ones warrant evaluation for the distant future. I would
expect that CPU resources is the first thing we would have to change -
13 thousand transactions per second is an awful lot to process. I'm
not intimately familiar with the processing - Isn't it largely
signature verification of the transaction itself, plus a minority of
time spent checking and updating utxo values, and finally a small
number of hashes to check block validity? If signature verification
was controlling, a specialized asic chip(on a plug-in card) might be
able to verify signatures hundreds of times faster, and it could even
be on a cheap 130nm chipset like the first asic miners rushed to
market. Point being, there are options and it may warrant looking
into after the risk to node reductions.

> You'd need a handful of experts just to maintain such a thing.

I don't think this is as big a deal as it first might seem. The
software would already come written to be spanned onto multiple
machines - it just needs to be configured. For the specific question
at hand, the exchange would already have IT staff and datacenter
capacity/operations for their other operations. In the more general
case, the numbers involved don't work out to extreme concerns at that
level. The highest cpu usage I've observed on my nodes is less than
5%, less than 1% for the time I just checked, handling ~3 tx/s. So
being conservative, if it hits 100% on one core at 60-120 tx/s, that
works out to ~25-50 8-core machines. But again, that's a 2-year old
laptop CPU and we're talking about 14 years into the future. Even if
it was 25 machines, that's the kind of operation a one or two man IT
team just runs on the side with their extra duties. It isn't enough
to hire a fulltime tech for.

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

I mean, that's literally what Amazon does for you with S3, which was
even cheaper than the EBS datastore pricing I was looking at. So....
Even disregarding that, raid operation was a solved thing more than 10
years ago, and hard drives 14 years out would be roughly ~110 TB for a
$240 hard drive at a 14%/year growth rate. In 2034 the blockchain
would fit on 10 of those. Not exactly a "failing every day" kind of
problem. By 2040, you'd need *gasp* 22 $240 hard drives. I mean, it
is a lot, but not a lot like you're implying.

> And you need a way to rebuild everything without taking the system offline.

That depends heavily upon the tradeoffs the businesses can make. I
don't think node operation at an exchange is a five-nines uptime
operation. They could probably tolerate 3 nines. The worst that
happens is occasionally people's withdrawals and deposit are delayed
slightly. It won't shut down trading.

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

Visa stores the only copy. They can't afford to lose the data.
Bitcoin isn't like that, as others pointed out. And for most
businesses, if their node must be rebooted periodically, it isn't a
huge deal.

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

Ok, when is that point, and what is the tradeoff in terms of nodes?
Just because something is hard doesn't mean it isn't worth doing.
That's just a defeatist attitude. How big can we get, for what
tradeoffs, and what do we need to do to get there?

> You have to check each transaction against each other transaction to make sure that they aren't double spending eachother.

This is really not that hard. Have a central database, update/check
the utxo values in block-store increments. If a utxo has already been
used this increment, the block is invalid. If the database somehow
got too big(not going to happen at these scales, but if it did), it
can be sharded trivially on the transaction information. These are
solved problems, the free database software that's available is pretty
powerful.

> You have to be a lot more clever than that to get things working and consistent.

NO, NOT CLEVER. WE CAN'T DO THAT.

Sorry, I had to. :)

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

I know of and have experience working with systems that handled
several orders of magnitude more data than this. None of the issues
brought up above are problems that someone hasn't solved. Transaction
commitments to databases? Data consistency across multiple workers?
Data storage measured in exabytes? Data storage and updates
approaching hundreds of millions of datapoints per second? These
things are done every single day at numerous companies.

On Fri, Mar 31, 2017 at 11:23 AM, David Vorick <david.vorick at gmail.com> wrote:
> 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).

📅 Original date posted:2017-03-30 📝 Original message:> ...

2023-06-07T17:58:33Z

In reply to nevent1q…gvgt
_________________________

📅 Original date posted:2017-03-30
📝 Original message:> Further, we are very far from the point (in my appraisal) where fees are
high enough to block home users from using the network.

This depends entirely on the usecase entirely. Most likely even without a
blocksize increase, home purchases will be large enough to fit on the
blocksize in the forseeable future. Microtransactions(<$0.25) on the other
hand aren't viable no matter what we try to do - There's just too much data.

Most likely, transaction fees above $1 per tx will become unappealing for
many consumers, and above $10 is likely to be niche-level. It is hard to
say with any certainty, but average credit card fees give us some
indications to work with - $1.2 on a $30 transaction, though paid by the
business and not the consumer.

Without blocksize increases, fees higher than $1/tx are basically
inevitable, most likely before 2020. Running a node only costs $10/month
if that. If we were going to favor node operational costs that highly in
the weighting, we'd better have a pretty solid justification with
mathematical models or examples.

> We should not throw away the core innovation of monetary sovereignty in
pursuit of supporting 0.1% of the world's daily transactions.

If we can easily have both, why not have both?

An altcoin with both will take Bitcoin's monetary sovereignty crown by
default. No crown, no usecases, no Bitcoin.

On Thu, Mar 30, 2017 at 9:14 AM, David Vorick via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> 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.
>
>
> _______________________________________________
> 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/20170330/697743ea/attachment.html>;

📅 Original date posted:2017-03-30 📝 Original message:> ...

2023-06-07T17:58:22Z

In reply to nevent1q…khk2
_________________________

📅 Original date posted:2017-03-30
📝 Original message:> You are only looking at technical aspects and missing the political
aspect.

Nodes don't do politics. People do, and politics is a lot larger with a
lot more moving parts than just node operation.

> full nodes protect the user from the change of any properties of Bitcoin
which they do not agree with.

Full nodes protect from nothing if the chain they attempt to use is
nonfunctional.

> The ability to retain this power for users is of prime importance and is
arguably what gives Bitcoin most of it's value
> Any increase in the cost to run a full node is an increase in cost to
maintain monetary sovereignty

This power is far more complicated than just nodes. You're implying that
node operation == political participation. Node operation is only a very
small part of the grand picture of the bitcoin balance of power.

> The ability for a user to run a node is what keeps the miners honest and
prevents them from rewriting any of Bitcoin's rules.

No, it isn't. Nodes disagreeing with miners is necessary but not
sufficient to prevent that. Nodes can't utilize a nonfunctional chain, nor
can they utilize a coin with no exchanges.

> What makes Bitcoin uncensorable

Only two things - 1. Node propagation being strong enough that a target
node can't be surrounded by attacker nodes (or so that attacker nodes can't
segment honest nodes), and 2. Miners being distributed in enough countries
and locations to avoid any single outside attacker group from having enough
leverage to prevent transaction inclusion, and miners also having enough
incentives(philosophical or economic) to refuse to collude towards
transaction exclusion.

Being able to run a node yourself has no real effect on either of the two.
Either we have enough nodes that an attacker can't segment the network or
we don't.

> What gives confidence that the 21 million limit will be upheld

What you're describing would result in a fork war. The opposition to this
would widespread and preventing an attempt relies upon mutual destruction.
If users refused to get on board, exchanges would follow users. If miners
refused to get on board, the attempt would be equally dead in the water.
It would require a majority of users, businesses and miners to change the
limit; Doing so without an overwhelming majority(90% at least) would still
result in a contentious fork that punished both sides(in price, confidence,
adoption, and possibly chain or node attacks) for refusing to agree.

Nodes have absolutely no say in the matter if they can't segment the
network, and even if they could their impact could be repaired. Users !=
Nodes.

> What makes transactions irreversible

Err, this makes me worry that you don't understand how blockchains work...
This is because miners are severely punished for attempting to mine on
anything but the longest chain. Nodes have absolutely no say in the
matter, they always follow the longest chain unless a hardfork was
applied. If the hardfork has overwhelming consensus, i.e. stopping a 51%
attack, then the attack would be handled. If the hardfork did not have
overwhelming consensus it would result in another fork war requiring users,
businesses, and miners to actively decide which to support and how, and
once again would involve mutual destruction on both forks.

Nodes don't decide any of these things. Nodes follow the longest chain,
and have no practical choices in the matter. Users not running nodes
doesn't diminish their power - Mutual destruction comes from the market
forces on the exchanges, and they could give a rats ass whether you run a
node or not.

> The market is not storing 10s of billions of dollars in Bitcoin despite
all it's risks because it is useful for everyday transactions, that is a
solved problem in every part of the world (Cash/Visa/etc..).

This is just the "bitcoin is gold" argument. Bitcoin is not gold. For
someone not already a believer, Bitcoin is a risky, speculative investment
into a promising future technology, whereas gold is a stable physical asset
with 4,000 years of acceptance history that has the same value in nearly
every city on the planet. Bitcoin is difficult to purchase and difficult
to find someone to exchange for goods or services. Literally the only
reason we have 10s of billions of dollars of value is because speculation,
which includes nearly all Bitcoin users/holders and almost all businesses
and miners. While Bitcoin borrows useful features from gold, it has more
possible uses, including uses that were never possible before Bitcoin
existed, and we believe that gives it huge potential.

The ability of other systems to do transactions, like visa or cash, come
with the limitations of those systems. Bitcoin was designed to break those
limitations and STILL provide the ability to do transactions. We might all
agree Bitcoin isn't going to ever solve the microtransaction problem, at
least not on-chain, but saying Bitcoin doesn't need utility is just
foolish. Gold doesn't need utility, gold has 4,000 years of history. We
don't.

> Even if we fork to 2MB, 5MB, 10MB. It is irrelevant in the larger
picture, transaction capacity will still be too low for global usage in the
medium-long term.

Which is why it needs to be a formula or a continuous process, not a single
number.

> Even if it fails to live up to the hype, you should not discount the
market innovating solutions when there is money to be made.

That's like saying it would be better to do nothing so someone else solves
our problem for us than it would be for us to do what we can to solve it
ourselves. Someone else solving our problem may very well be Ethereum, and
"solving it for us" is pulling Bitcoin investments, users and nodes away
into Ethereum.

> The additional capacity from blocksize increases are linear improvements
with very large systemic costs compared with the userbase and usage which
is growing exponentially.

The capacity increases do not have to be linear. The increases in utility
are linear with blocksize increases, but so are the costs. There's no
reason those blocksize increases can't be tied to or related to usage
increases, so long as the concerns about having too few nodes (or too few
fees) for security are handled.

On Thu, Mar 30, 2017 at 12:11 AM, Luv Khemani <luvb at hotmail.com> wrote:

>
> >> 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.
>
> >I think you're conflating mining with node operation here. Node users
> only power is to block the propagation of certain things. Since miners
> also have a node endpoint, they can cut the node users out of the equation
> by linking with eachother directly - something they already do out of
> practicality for propagation. Node users do not have the power to
> arbitrate consensus, that is why we have blocks and PoW.
>
> You are only looking at technical aspects and missing the political aspect.
>
> Node users decide what a Bitcoin is. It matters not how much hash power is
> behind a inflationary supply chain fork, full nodes protect the user from
> the change of any properties of Bitcoin which they do not agree with. The
> ability to retain this power for users is of prime importance and is
> arguably what gives Bitcoin most of it's value. Any increase in the cost to
> run a full node is an increase in cost to maintain monetary sovereignty.
> The ability for a user to run a node is what keeps the miners honest and
> prevents them from rewriting any of Bitcoin's rules.
>
> If it's still difficult to grasp the above paragraph, ask yourself the
> following questions,
> - What makes Bitcoin uncensorable
> - What gives confidence that the 21 million limit will be upheld
> - What makes transactions irreversible
> - If hashpower was king as you make it to be, why havn't miners making up
> majority hashrate who want bigger blocks been able to change the blocksize?
>
> The market is not storing 10s of billions of dollars in Bitcoin despite
> all it's risks because it is useful for everyday transactions, that is a
> solved problem in every part of the world (Cash/Visa/etc..).
>
> Having said that, i fully empathise with your view that increasing
> transaction fees might allow competitors to gain marketshare for low value
> use cases. By all means, we should look into ways of solving the problem.
> But all these debates around blocksize is a total waste of time. Even if we
> fork to 2MB, 5MB, 10MB. It is irrelevant in the larger picture, transaction
> capacity will still be too low for global usage in the medium-long term.
> The additional capacity from blocksize increases are linear improvements
> with very large systemic costs compared with the userbase and usage which
> is growing exponentially. Lightning potentially offers a couple or orders
> of magnitude of scaling and will make blocksize a non-issue for years to
> come. Even if it fails to live up to the hype, you should not discount the
> market innovating solutions when there is money to be made.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/d09eebbf/attachment-0001.html>;

📅 Original date posted:2017-03-29 📝 Original message:> ...

2023-06-07T17:58:21Z

In reply to nevent1q…a3l0
_________________________

📅 Original date posted:2017-03-29
📝 Original message:> It's a political assessment. Full nodes are the ultimate arbiters of
consensus.

That's not true unless miners are thought of as the identical to nodes,
which is has not been true for nearly 4 years now. Nodes arbitrating a
consensus the BU theory - that nodes can restrain miners - but it doesn't
work. If miners were forked off from nonminers, the miner network could
keep their blockchain operational under attack from the nodes far better
than nodes could keep their blockchain operational under attack from the
miners. The miners could effectively grind the node network to a complete
halt and probably still run their own fork unimpeded at the same time.
This would continue until the the lack of faith in the network drove the
miners out of business economically, or until the node network capitulated
and followed the rules of the miner network.

The reason BU isn't a dire threat is that there's a great rift between the
miners just like there is between the average users, just as satoshi
intended, and that rift gives the user network the economic edge.

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

I think you're conflating mining with node operation here. Node users only
power is to block the propagation of certain things. Since miners also
have a node endpoint, they can cut the node users out of the equation by
linking with eachother directly - something they already do out of
practicality for propagation. Node users do not have the power to
arbitrate consensus, that is why we have blocks and PoW.

> 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. [..] that changes you are opposed to
are not introduced into the network.

This isn't true. Non-miner nodes cannot produce blocks. Their opinion is
not represented in the blockchain in any way, the blockchain is entirely
made up of blocks. They can commit transactions, but the transactions must
follow an even stricter set of rules and short of a user activated PoW
change, the miners get to decide. It might be viable for us to introduce
ways for transactions to vote on things, but that also isn't nodes voting -
that's money voting.

Bitcoin is structured such that nodes have no votes because nodes cannot be
trusted. They don't inherently represent individuals, they don't
inherently represent value, and they don't commit work that is played
against eachother to achieve a game theory equilibrium. That's miners.

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

Your assumption is predicated upon the idea that users pay a fixed cost for
any volume of bandwidth. That assertion is true for some users but not
true for others, and it is becoming exceedingly less true in recent years
with the addition of bandwidth caps by many ISP's. Even users without a
bandwidth cap can often get a very threatening letter if they were to max
their connection 24/7. Assuming unlimited user bandwidth in the future and
comparing that with limited datacenter bandwidth is extremely short
sighted. Fundamentally, if market forces have established that datacenter
bandwidth costs $0.09 per GB, what makes you think that ISP's don't have to
deal with the same limitations? They do, the difference is that $0.09 per
GB times the total usage across the ISP's customer base is far, far lower
than $80 times the number of customers. The more that a small group of
customers deviating wildly becomes a problem for them, the more they will
add bandwidth caps or send threatening letters or even rate-limit or stop
serving those users.

Without that assumption, your math and examples fall apart - Bandwidth
costs for full archival nodes are nearly 50 times higher than storage costs
no matter whether they are at home or in a datacenter.

> The financials of home nodes follow a completely different math than the
costs you are citing by quoting datacenter prices.

No, they really aren't without your assumption. Yes, they are somewhat
different - If someone has a 2TB hard drive but only ever uses 40% of it,
the remaining hard drive space would have a cost of zero. Those specific
examples break down when you average over several years and fifty thousand
users. If that same user was running a bitcoin node and hard drive space
was indeed a concern, they would factor that desire into the purchase of
their next computer, preferring those with larger hard drives. That
reintroduces the cost with the same individual who had no cost before. The
cost difference doesn't work out to the exact same numbers as the
datacenter costs, who have a better economy of scale but also have profit
and business overhead, but all of the math I've done indicates that over
thousands of individuals and several years of time, the costs land in the
same ballpark. For example - Comcast bandwidth cap = 1000gb @ ~$80/month.
$0.08/GB. Amazon's first tier is currently $0.09. Much closer than I
even expected before I worked out the math. I'm open to being proven wrong.

> 0.14 uses more than 1 GB of RAM.

I'm running 0.13.2 and only see 300 mb of ram. Why is 0.14 using three
times the ram?

> 1GB I think is really the limit you'd want to have before you'd start
seeing users choose not to run nodes simply

Again, while I sympathize with the concept, I don't believe holding the
growth of the entire currency back based on minimum specs is a fair
tradeoff. The impact on usecases that depend on a given fee level is total
obliteration. That's unavoidable for things like microtransactions, but a
fee level of $1/tx allows for hundreds of opportunities that a fee level of
$100/tx does not. That difference may be the deciding factor in the
network effect between Bitcoin and a competitor altcoin. Bitcoin dying out
because a better-operated coin steals its first-mover advantage is just as
bad as bitcoin dying out because an attacker halted tx propagation and
killed the network. Probably even worse - First mover advantages are
almost never retaken, but the network could recover from a peering attack
with software changes and community/miner responses.

> However, I think the fees would have to get in the $50 range for that to
start to be the case.

I calculated this out. If blocksizes aren't increased, but price increases
continue as they have in the last 3-5 years, per-node operational costs for
one month drop from roughly $10-15ish (using datacenter numbers, which you
said would be higher than home user numbers and might very well be when
amortized thoroughly) down to $5-8 in less than 8 years. If transaction
fees don't rise at all due to blockspace competition (i.e., they offset
only the minimum required for miners to economically protect Bitcoin),
they'll be above $10 in less than 4 years. I believe that comparing
1-month of node operational costs versus 1 transaction fee is a reasonable,
albeit imperfect, comparison of when users will stop caring.

That's not very far in the future at all, and fee-market competition will
probably be much, much worse for us and better for miners.

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

So I don't mean to be rude here, but this kind of thinking is very poor
logic when applied to anyone who isn't already a libertarian Bitcoin
supporter. By anyone outside the Bitcoin world's estimation, Bitcoin is an
extremely high risk, unreliable store of value. We like to compare it to
"digital gold" because of the parameters that Satoshi chose, but saying it
does not make it true. For someone not already a believer, Bitcoin is a
risky, speculative investment into a promising future technology, and gold
is a stable physical asset with 4,000 years of acceptance history that has
the same value in nearly every city on the planet. Bitcoin is difficult to
purchase and difficult to find someone to exchange for goods or services.

Could Bitcoin become more like what you described in the future? A lot of
us hope so or we wouldn't be here right now. But in the meantime, any
other crypto currency that choses parameters similar to gold could eclipse
Bitcoin if we falter. If their currency is more usable because they
balance the ratio of node operational costs/security versus transaction
fees/usability, they have a pretty reasonable chance of doing so. And then
you won't store your $10k+ in bitcoin, you'll store in $altcoin. The
market doesn't really care who wins.

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

That's nothing, we've never had any fee competition at all until basically
November of last year. From December to March transaction fees went up by
250%, and they doubled from May to December before that. Transactions per
year are up 80% per year for the last 4 years. Things are about to get
screwed.

On Wed, Mar 29, 2017 at 1:28 PM, David Vorick via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> > > 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.
>
>
> _______________________________________________
> 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/20170329/58af5724/attachment-0001.html>;

📅 Original date posted:2017-03-29 📝 Original message:> ...

2023-06-07T17:58:19Z

In reply to nevent1q…9vtm
_________________________

📅 Original date posted:2017-03-29
📝 Original message:> I’m confident that we could work with the miners who we have good
relationships with to start including the root hash of the (lagging) UTXO
set in their coinbase transactions, in order to begin transforming this
idea into reality.

By itself, this wouldn't work without a way for a new node to differentiate
between a false history and a true one.

> We could also issue regular transactions from “semi-trusted” addresses
controlled by known people that include the same root hash in an OP_RETURN
output, which would allow cross-checking against the miners’ UTXO
commitments, as part of this initial “prototype”

This might work, but I fail to understand how a new node could verify an
address / transaction without a blockchain to back it. Even if it could,
it becomes dependent upon those addresses not being compromised, and the
owners of those addresses would become targets for potential government
operations.

Having the software silently attempt to resolve the problem is risky unless
it is foolproof. Otherwise, users will assume their software is showing
them the correct history/numbers implicitly, and if the change the utxo
attacker made was small, the users might be able to follow the main chain
totally until it was too late and the attacker struck with an address that
otherwise never transacted. Sudden, bizarre, hard to debug fork and
potentially double spend against people who picked up the fraudulent utxo.

Users already treat wallet software with some level of suspicion, asking if
they can trust x or y or z, or like the portion of the BU community
convinced that core has been compromised by blockstream bigwigs. Signed
releases could provide the same thing but would encourage both open-source
security checks of the signed utxo's and potentially of users to check
download signatures.

Either approach is better than what we have now though, so I'd support
anything.

On Wed, Mar 29, 2017 at 1:28 PM, Peter R via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I believe nearly everyone at Bitcoin Unlimited would be supportive of a
> UTXO check-pointing scheme. I’d love to see this happen, as it would
> greatly reduce the time needed to get a new node up-and-running, for node
> operators who are comfortable trusting these commitments.
>
> I’m confident that we could work with the miners who we have good
> relationships with to start including the root hash of the (lagging) UTXO
> set in their coinbase transactions, in order to begin transforming this
> idea into reality. We could also issue regular transactions from
> “semi-trusted” addresses controlled by known people that include the same
> root hash in an OP_RETURN output, which would allow cross-checking against
> the miners’ UTXO commitments, as part of this initial “prototype” system.
>
> This would "get the ball rolling" on UTXO commitments in a permissionless
> way (no one can stop us from doing this). If the results from this
> prototype commitment scheme were positive, then perhaps there would be
> support from the community and miners to enforce a new rule which requires
> the (lagging) root hashes be included in new blocks. At that point, the
> UTXO commitment scheme is no longer a prototype but a trusted feature of
> the Bitcoin network.
>
> On that topic, are there any existing proposals detailing a canonical
> ordering of the UTXO set and a scheme to calculate the root hash?
>
> Best regards,
> Peter
>
>
> On Mar 29, 2017, at 12:33 PM, Daniele Pinna via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> What about periodically committing the entire UTXO set to a special
> checkpoint block which becomes the new de facto Genesis block?
>
> Daniele
>
> ------------------------------
>
> Message: 5
> Date: Wed, 29 Mar 2017 16:41:29 +0000
> From: Andrew Johnson <andrew.johnson83 at gmail.com>
> To: David Vorick <david.vorick at gmail.com>
> Cc: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
> Message-ID:
> <CAAy62_+JtoAuM-RsrAAp5eiGiO+OHLDjzqgbnF2De7TUU7TyYg at mail.gm
> ail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I believe that as we continue to add users to the system by scaling
> capacity that we will see more new nodes appear, but I'm at a bit of a loss
> as to how to empirically prove it.
>
> I do see your point on increasing load on archival nodes, but the majority
> of that load is going to come from new nodes coming online, they're the
> only ones going after very old blocks. I could see that as a potential
> attack vector, overwhelm the archival nodes by spinning up new nodes
> constantly, therefore making it difficult for a "real" new node to get up
> to speed in a reasonable amount of time.
>
> Perhaps the answer there would be a way to pay an archival node a small
> amount of bitcoin in order to retrieve blocks older than a certain cutoff?
> Include an IP address for the node asking for the data as metadata in the
> transaction... Archival nodes could set and publish their own policy, let
> the market decide what those older blocks are worth. Would also help to
> incentivize running archival node, which we do need. Of course, this isn't
> very user friendly.
>
> We can take this to bitcoin-discuss, if we're getting too far off topic.
>
>
> On Wed, Mar 29, 2017 at 11:25 AM David Vorick <david.vorick at gmail.com>
> wrote:
>
> >
> > 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.
> >
> >
> > --
> Andrew Johnson
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/atta
> chments/20170329/9b48ebe3/attachment.html>
>
> ------------------------------
> _______________________________________________
> 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/20170329/8b4cf6b4/attachment.html>;

📅 Original date posted:2017-03-29 📝 Original message:> ...

2023-06-07T17:58:18Z

In reply to nevent1q…9uza
_________________________

📅 Original date posted:2017-03-29
📝 Original message:> 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.

Default configurations aren't a big enough deal to factor into the critical
discussion of node costs versus transaction fee cost. Default
configurations can be changed, and if nodes are negatively affected by a
default configuration, there will be an abundance of information about how
to correct that effect by turning on pruning. Bitcoin can't design with
the assumption that people can't google - If we wanted to cater to that
population group right now, we'd need 100x the blocksize at least.

> But that would also substantially increase the burden on archive nodes.

This is already a big problem from the measurements I've been looking at.
There are alternatives that need to be considered there as well. If we
limit ourselves to not changing the syncing process for most users, the
blocksize limit debate changes drastically. Hard drive costs, CPU costs,
propagation times... none of those things matter because the cost of sync
bandwidth is so incredibly high even now ($130ish per month, see other
email). Even if we didn't increase the blocksize any more than segwit,
we're already seeing sync costs being shifted onto fewer nodes - I.e., Luke
Jr's scan finding ~50k nodes online but only 7k of those show up on sites
like bitnodes.21.co. Segwit will shift it further until the few nodes
providing sync limit speeds and/or max out on connections, providing no
fully-sync'd nodes for a new node to connect to. Then wallet providers /
node software will offer a solution - A bundled utxo checkpoint that
removes the need to sync. This slightly increases centralization, and
increases centralization more if core were to adopt the same approach.

The advantage would be tremendous for such a simple solution - Node costs
would drop by a full order of magnitude for full nodes even today, more
when archival nodes are more restricted, history is bigger, and segwit
blocksizes are in effect, and then blocksizes could be safely increased by
nearly the same order of magnitude, increasing the utility of bitcoin and
the number of people that can effectively use it.

Another, much more complicated option is for the node sync process to
function like a tor network. A very small number of seed nodes could send
data on to only other nodes with the highest bandwidth available(and good
retention policy, i.e. not tightly pruning as they sync), who then spread
it out further and so on. That's complicated though, because as far as I
know the syncing process today has no ability to exchange a selfish syncing
node for a high performing syncing node. I'm not even sure - will a
syncing node opt to sync from a different node that, itself, isn't fully
sync'd but is farther ahead?

At any rate, syncing bandwidth usage is a critical problem for future
growth and is solvable. The upsides of fixing it are huge, though.

On Wed, Mar 29, 2017 at 9:25 AM, David Vorick via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
> 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.
>
>
>
> _______________________________________________
> 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/20170329/6593ee82/attachment.html>;

📅 Original date posted:2017-03-30 📝 Original message:> ...

2023-06-07T17:58:16Z

In reply to nevent1q…kppz
_________________________

📅 Original date posted:2017-03-30
📝 Original message:> The block size itself should be set based on the amount of fees being
paid to miners to make a block.

There's a formula to this as well, though going from that to a blocksize
number will be very difficult. Miner fees need to be sufficient to
maintain economic protection against attackers. There is no reason that
miner fees need to be any higher than "sufficient." I believe that
"sufficient" value can be estimated by considering a potential attacker
seeking to profit from short-selling Bitcoin after causing a panic crash.
If they can earn more profit from shorting Bitcoin than it costs to buy,
build/deploy, and perform a 51% attack to shut down the network, then we
are clearly vulnerable. The equation for the profit side of the equation
can be worked out as:

(bitcoin_price * num_coins_shortable * panic_price_drop_percentage)

The equation for the cost side of the equation depends on the total amount
of miner hardware that the network is sustainably paying to operate,
factoring in all costs of the entire bitcoin mining lifecycle(HW cost,
deployment cost, maintenance cost, electricity, amortized facilities cost,
business overheads, orphan losses, etc) except chip design, which the
attacker may be able to take advantage of for free. For convenience I'm
simplifying that complicated cost down to a single number I'm calling
"hardware_lifespan" although the concept is slightly more involved than
that.

(total_miner_payouts * bitcoin_price * hardware_lifespan)

Bitcoin_price is on boths ides of the equation and so can be divided out,
giving:

Unsafe point = (num_coins_shortable * panic_price_drop_percentage) <
(total_miner_payouts
* hardware_lifespan)

Estimating the total number of shortable coins an attacker of nearly
unlimited funds is tricky, especially when things like high leverage levels
or naked short selling may be offered by exchanges. The percent of damage
the resulting panic would cause is also tricky to estimate, but on both
numbers we can make some rough guesses and see how they play out. With
more conservative numbers like say, 2 year hardware lifespan, 10% short,
70% panic drop you get: 1,300k coins profit, 1800 BTC/day in fees minimum
needed to make the attack cost more than it profits.

Using various inputs and erring on the side of caution, I get a minimum
BTC/day fee range of 500-2000. Unfortunately if the blocksize isn't
increased, a relatively small number of transactions/users have to bear the
full cost of the minimum fees, over time increasing the minimum "safe"
average fee paid to 0.008 BTC, 30x the fees people are complaining about
today, and increasing in real-world terms as price increases. All that
said, I believe the costs for node operation are the number that gets hit
first as blocksizes are increased, at least past 2020. I don't think
blocksizes could be increased to such a size that the insufficient-fee
vulnerability would be a bigger concern than high node operational costs.
The main thing I don't have a good grasp on at the moment is any math to
estimate how many nodes we need to protect against the attacks that can
come from having few nodes, or even a clear understanding of what those
attacks are.

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

This is also totally true. A system that tried to eliminate the fee
markets would be flawed, and fortunately miners have significant reasons to
oppose such a system.

The reverse is also a problem - If miners as a large group sought to lower
blocksizes to force fee markets higher, that could be a problem. I don't
have solutions for the issue at this time, but something I've turned over
in my mind.

On Thu, Mar 30, 2017 at 3:30 AM, Tom Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Thursday, 30 March 2017 07:23:31 CEST Ryan J Martin via bitcoin-dev
> wrote:
> > The original post and the assorted limit proposals---lead me to
> > something I think is worth reiterating: assuming Bitcoin adoption
> > continues to grow at similar or accelerating rates, then eventually the
> > mempool is going to be filled with thousands of txs at all times whether
> > block limits are 1MB or 16MB
>
> This is hopefully true. :)
>
> There is an unbounded amount of demand for block space, and as such it
> doesn’t benefit anyone if the amount of free transactions get out of hand.
> Because freeloaders would definitely be able to completely suffocate
> Bitcoin.
>
> In the mail posted by OP he makes clear that this is a proposal for a hard
> fork to change the block size *limit*. The actual block size would not be
> changed at the same time, it will continue being set based on market values
> or whatever we decide between now and then.
>
> The block size itself should be set based on the amount of fees being paid
> to miners to make a block.
>
> 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.
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/dd71b786/attachment-0001.html>;

📅 Original date posted:2017-03-30 📝 Original message:> ...

2023-06-07T17:58:16Z

In reply to nevent1q…vckx
_________________________

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

I agree in concept with everything you've said here, but I think there's a
frequent misconception that there's a certain level of miner payouts that
miners "deserve" and/or the opposite, that miners "deserve" as little as
possible. The 51% attacks that PoW's shields us from are relatively well
defined, which can be used to estimate the minimum amount of sustainable
fees for shielding. Beyond that minimum amount of fees, the best amount of
fees for every non-miner is the lowest.

Unfortunately miners could arbitrarily decide to limit blocksizes, and
there's little except relay restrictions that everyone else could do about
it. Fortunately miners so far have pushed for blocksize increases at least
as much as anyone else, though the future when Bitcoin adoption stabilizes
would be an unknown.

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

FYI, I don't see this happening again ever, barring brief exceptions,
unless there was a sudden blocksize change, which ideally we'd avoid ever
happening. The stable average value of the transaction fee determines what
kind of business use-cases can be built using Bitcoin. An average fee of
$0.001 usd enables a lot more use cases than $0.10 average fees, and $50.00
average fees still have far more possible use cases than a $1000 average
fee. If fees stabilize low, use cases will spring up to fill the
blockspace, unless miners arbitraily seek to keep the fees above some level.

On Thu, Mar 30, 2017 at 3:30 AM, Tom Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Thursday, 30 March 2017 07:23:31 CEST Ryan J Martin via bitcoin-dev
> wrote:
> > The original post and the assorted limit proposals---lead me to
> > something I think is worth reiterating: assuming Bitcoin adoption
> > continues to grow at similar or accelerating rates, then eventually the
> > mempool is going to be filled with thousands of txs at all times whether
> > block limits are 1MB or 16MB
>
> This is hopefully true. :)
>
> There is an unbounded amount of demand for block space, and as such it
> doesn’t benefit anyone if the amount of free transactions get out of hand.
> Because freeloaders would definitely be able to completely suffocate
> Bitcoin.
>
> In the mail posted by OP he makes clear that this is a proposal for a hard
> fork to change the block size *limit*. The actual block size would not be
> changed at the same time, it will continue being set based on market values
> or whatever we decide between now and then.
>
> The block size itself should be set based on the amount of fees being paid
> to miners to make a block.
>
> 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.
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/1f44fdaf/attachment.html>;

📅 Original date posted:2017-03-29 📝 Original message:> ...

2023-06-07T17:58:14Z

In reply to nevent1q…vghf
_________________________

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

That's very poor logic, sorry. Restricted-space SSD's are not a
cost-effective hardware option for running a node. Keeping blocksizes
small has significant other costs for everyone. Comparing the cost of
running a node under arbitrary conditons A, B, or C when there are far more
efficient options than any of those is a very bad way to think about the
costs of running a node. You basically have to ignore the significant
consequences of keeping blocks small.

If node operational costs rose to the point where an entire wide swath of
users that we do actually need for security purposes could not justify
running a node, that's something important for consideration. For me, that
translates to modern hardware that's relatively well aligned with the needs
of running a node - perhaps budget hardware, but still modern - and
above-average bandwidth caps.

You're free to disagree, but your example only makes sense to me if
blocksize caps didn't have serious consequences. Even if those
consequences are just the threat of a contentious fork by people who are
mislead about the real consequences, that threat is still a consequence
itself.

On Wed, Mar 29, 2017 at 9:18 AM, David Vorick via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> 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.
>
> _______________________________________________
> 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/20170329/24dbcac6/attachment-0001.html>;

📅 Original date posted:2017-03-29 📝 Original message:> I ...

2023-06-07T17:58:11Z

In reply to nevent1q…c679
_________________________

📅 Original date posted:2017-03-29
📝 Original message:> I suggest you take a look at this paper: http://fc16.ifca.ai/
bitcoin/papers/CDE+16.pdf It may help you form opinions based in science
rather than what appears to be nothing more than a hunch. It shows that
even 4MB is unsafe. SegWit provides up to this limit.

I find this paper wholly unconvincing. Firstly I note that he assumes the
price of electricity is 10c/kwh in Oct 2015. As a miner operating and
building large farms at that time, I can guarantee you that almost no large
mines were paying anything even close to that high for electricity, even
then. If he had performed a detailed search on the big mines he would have
found as much, or could have asked, but it seems like it was simply made
up. Even U.S. industrial electricity prices are lower than that.

Moreover, he focuses his math almost entirely around mining, asserting in
table 1 that 98% of the "cost of processing a transaction" as being
mining. That completely misunderstands the purpose of mining. Miners
occasionally trivially resolve double spend conflicts, but miners are
paid(and played against eachother) for economic security against
attackers. They aren't paid to process transactions. Nodes process
transactions and are paid nothing to do so, and their costs are 100x more
relevant to the blocksize debate than a paper about miner costs. Miner's
operational costs relate to economic protection formulas, not the cost of a
transaction.

He also states: "the top 10% of nodes receive a 1MB block 2.4min earlier
than the bottom 10% — meaning that depending on their access to nodes, some
miners could obtain a significant and unfair lead over others in solving
hash puzzles."

He's using 2012-era logic of mining. By October 2015, no miner of any size
was in the bottom 10% of node propagation. If they were a small or medium
sized miner, they mined shares on a pool and would be at most 30 seconds
behind the pool. Pools that didn't get blocks within 20 seconds weren't
pools for long. If they were a huge miner, they ran their own pool with
good propagation times. For a scientific paper, this is reading like
someone who had absolutely no idea what was really going on in the mining
world at the time. But again, none of that relates to transaction "costs."
Transactions cost nodes money; protecting the network costs miners money.
Miners are rewarded with fees; nodes are rewarded only by utility and price
increases.

On Tue, Mar 28, 2017 at 10:53 AM, Alphonse Pace via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Juan,
>
> I suggest you take a look at this paper: http://fc16.ifca.ai/
> bitcoin/papers/CDE+16.pdf It may help you form opinions based in science
> rather than what appears to be nothing more than a hunch. It shows that
> even 4MB is unsafe. SegWit provides up to this limit.
>
> 8MB is most definitely not safe today.
>
> Whether it is unsafe or impossible is the topic, since Wang Chun proposed
> making the block size limit 32MiB.
>
>
> Wang Chun,
>
> Can you specify what meeting you are talking about? You seem to have not
> replied on that point. Who were the participants and what was the purpose
> of this meeting?
>
> -Alphonse
>
> On Tue, Mar 28, 2017 at 12:33 PM, Juan Garavaglia <jg at 112bit.com> wrote:
>
>> Alphonse,
>>
>>
>>
>> In my opinion if 1MB limit was ok in 2010, 8MB limit is ok on 2016 and
>> 32MB limit valid in next halving, from network, storage and CPU perspective
>> or 1MB was too high in 2010 what is possible or 1MB is to low today.
>>
>>
>>
>> If is unsafe or impossible to raise the blocksize is a different topic.
>>
>
>>
>> Regards
>>
>>
>>
>> Juan
>>
>>
>>
>>
>>
>> *From:* bitcoin-dev-bounces at lists.linuxfoundation.org [mailto:
>> bitcoin-dev-bounces at lists.linuxfoundation.org] *On Behalf Of *Alphonse
>> Pace via bitcoin-dev
>> *Sent:* Tuesday, March 28, 2017 2:24 PM
>> *To:* Wang Chun <1240902 at gmail.com>; Bitcoin Protocol Discussion <
>> bitcoin-dev at lists.linuxfoundation.org>
>> *Subject:* Re: [bitcoin-dev] Hard fork proposal from last week's meeting
>>
>>
>>
>> What meeting are you referring to? Who were the participants?
>>
>>
>>
>> Removing the limit but relying on the p2p protocol is not really a true
>> 32MiB limit, but a limit of whatever transport methods provide. This can
>> lead to differing consensus if alternative layers for relaying are used.
>> What you seem to be asking for is an unbound block size (or at least
>> determined by whatever miners produce). This has the possibility (and even
>> likelihood) of removing many participants from the network, including many
>> small miners.
>>
>>
>>
>> 32MB in less than 3 years also appears to be far beyond limits of safety
>> which are known to exist far sooner, and we cannot expect hardware and
>> networking layers to improve by those amounts in that time.
>>
>>
>>
>> It also seems like it would be much better to wait until SegWit activates
>> in order to truly measure the effects on the network from this increased
>> capacity before committing to any additional increases.
>>
>>
>>
>> -Alphonse
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> I've proposed this hard fork approach last year in Hong Kong Consensus
>> but immediately rejected by coredevs at that meeting, after more than
>> one year it seems that lots of people haven't heard of it. So I would
>> post this here again for comment.
>>
>> The basic idea is, as many of us agree, hard fork is risky and should
>> be well prepared. We need a long time to deploy it.
>>
>> Despite spam tx on the network, the block capacity is approaching its
>> limit, and we must think ahead. Shall we code a patch right now, to
>> remove the block size limit of 1MB, but not activate it until far in
>> the future. I would propose to remove the 1MB limit at the next block
>> halving in spring 2020, only limit the block size to 32MiB which is
>> the maximum size the current p2p protocol allows. This patch must be
>> in the immediate next release of Bitcoin Core.
>>
>> With this patch in core's next release, Bitcoin works just as before,
>> no fork will ever occur, until spring 2020. But everyone knows there
>> will be a fork scheduled. Third party services, libraries, wallets and
>> exchanges will have enough time to prepare for it over the next three
>> years.
>>
>> We don't yet have an agreement on how to increase the block size
>> limit. There have been many proposals over the past years, like
>> BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
>> on. These hard fork proposals, with this patch already in Core's
>> release, they all become soft fork. We'll have enough time to discuss
>> all these proposals and decide which one to go. Take an example, if we
>> choose to fork to only 2MB, since 32MiB already scheduled, reduce it
>> from 32MiB to 2MB will be a soft fork.
>>
>> Anyway, we must code something right now, before it becomes too late.
>> _______________________________________________
>> 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/20170329/c0cf92f1/attachment.html>;

📅 Original date posted:2017-03-29 📝 Original message:In ...

2023-06-07T17:58:07Z

In reply to nevent1q…m9yc
_________________________

📅 Original date posted:2017-03-29
📝 Original message:In order for any blocksize increase to be agreed upon, more consensus is
needed. The proportion of users believing no blocksize increases are
needed is larger than the hardfork target core wants(95% consensus). The
proportion of users believing in microtransactions for all is also larger
than 5%, and both of those groups may be larger than 10% respectively. I
don't think either the Big-blocks faction nor the low-node-costs faction
have even a simple majority of support. Getting consensus is going to be a
big mess, but it is critical that it is done.

On Wed, Mar 29, 2017 at 12:49 AM, Martin Lízner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> If there should be a hard-fork, Core team should author the code. Other
> dev teams have marginal support among all BTC users.
>
> Im tending to believe, that HF is necessary evil now. But lets do it in
> conservative approach:
> - Fix historical BTC issues, improve code
> - Plan HF activation date well ahead - 12 months+
> - Allow increasing block size on year-year basis as Luke suggested
> - Compromise with miners on initial block size bump (e.g. 2MB)
> - SegWit
>
> Martin Lizner
>
> On Tue, Mar 28, 2017 at 6:59 PM, Wang Chun via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I've proposed this hard fork approach last year in Hong Kong Consensus
>> but immediately rejected by coredevs at that meeting, after more than
>> one year it seems that lots of people haven't heard of it. So I would
>> post this here again for comment.
>>
>> The basic idea is, as many of us agree, hard fork is risky and should
>> be well prepared. We need a long time to deploy it.
>>
>> Despite spam tx on the network, the block capacity is approaching its
>> limit, and we must think ahead. Shall we code a patch right now, to
>> remove the block size limit of 1MB, but not activate it until far in
>> the future. I would propose to remove the 1MB limit at the next block
>> halving in spring 2020, only limit the block size to 32MiB which is
>> the maximum size the current p2p protocol allows. This patch must be
>> in the immediate next release of Bitcoin Core.
>>
>> With this patch in core's next release, Bitcoin works just as before,
>> no fork will ever occur, until spring 2020. But everyone knows there
>> will be a fork scheduled. Third party services, libraries, wallets and
>> exchanges will have enough time to prepare for it over the next three
>> years.
>>
>> We don't yet have an agreement on how to increase the block size
>> limit. There have been many proposals over the past years, like
>> BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
>> on. These hard fork proposals, with this patch already in Core's
>> release, they all become soft fork. We'll have enough time to discuss
>> all these proposals and decide which one to go. Take an example, if we
>> choose to fork to only 2MB, since 32MiB already scheduled, reduce it
>> from 32MiB to 2MB will be a soft fork.
>>
>> Anyway, we must code something right now, before it becomes too late.
>> _______________________________________________
>> 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/20170329/89ff2027/attachment.html>;

📅 Original date posted:2017-03-29 📝 Original message:> ...

2023-06-07T17:58:06Z

In reply to nevent1q…hjxl
_________________________

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

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

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. With historical syncing discounted(i.e. pruned or nonlistening
nodes) bandwidth costs are still higher than hard drive costs.

Today: Full listening node, 133 peers, measured 1.5 TB/mo of bandwidth
consumption over two multi-day intervals. 1,500 GB/month @ ec2 low-tier
prices = $135/month, 110 GB storage = $4.95. Similar arguments extend to
consumer hardware - Comcast broadband is ~$80/mo depending on region and
comes with 1.0 TB cap in most regions, so $120/mo or even $80/mo would be
in the same ballpark. A consumer-grade 2GB hard drive is $70 and will last
for at least 2 years, so $2.93/month if the hard drive was totally
dedicated to Bitcoin and $0.16/month if we only count the percentage that
Bitcoin uses.

For a non-full listening node, ~25 peers I measured around 70 GB/month of
usage over several days, which is $6.3 per month EC2 or $5.6 proportional
Comcast cost. If someone isn't supporting syncing, there's not much point
in them not turning on pruning. Even if they didn't, a desktop in the $500
range typically comes with 1 or 2 TB of storage by default, and without
segwit or a blocksize cap increase, 3 years from now the full history will
only take up the 33% of the smaller, three year old, budget-range PC hard
drive. Even then if we assume the hard drive price declines of the last 4
years hold steady(14%, very low compared to historical gains), 330gb of
data only works out to a proportional monthly cost of $6.20 - still
slightly smaller than his bandwidth costs, and almost entirely removable by
turning on pruning since he isn't paying to help others sync.

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. CPU usage and thus electricity costs might become
a factor, I just don't know how to quantify it at various block scales.
Currently cpu usage isn't taxing any hardware that I run a node on in any
way I have been able to notice, not including the syncing process.

> I am also solidly unconvinced that increasing the blocksize today is a
good move, even as little as SegWit does.

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.

And even if an altcoin can't take Bitcoin's dominance by lower fees, we
will not end up with millions of home users running nodes, ever. If they
did so, that would be orders of magnitude fee market competition, and
continuing increases in price, while hardware costs decline. If
transaction fees go up from space limitations, and they go up even further
in real-world terms from price increases, while node costs decline,
eventually it will cost more to send a transaction than it does to run a
node for a full month. No home users would send transactions because the
fee costs would be higher than anything they might use Bitcoin for, and so
they would not run a node for something they don't use - Why would they?
The cost of letting the ratio between node costs and transaction costs go
in the extreme favor of node costs would be worse - Lower Bitcoin
usability, adoption, and price, without any meaningful increase in security.

How do we evaluate the math on node distributions versus various attack
vectors?

On Wed, Mar 29, 2017 at 8:57 AM, David Vorick via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
> 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).
>
> _______________________________________________
> 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/20170329/2e9b6644/attachment-0001.html>;

📅 Original date posted:2017-03-29 📝 Original message:> ...

2023-06-07T17:58:05Z

In reply to nevent1q…cjn6
_________________________

📅 Original date posted:2017-03-29
📝 Original message:> While Segwit's change from 1 mb size limit to 4 mb weight limit seems to
be controversial among some users [..] I don't think it's very interesting
to discuss further size increases.

I think the reason for this is largely because SegWit as a blocksize
increase isn't very satisfying. It resolves to a one-time increase with no
future plans, thus engendering the same objections as people who demand we
just "raise the number to N." People can argue about what N should be, but
when N is just a flat number, we know we'll have to deal with the issue
again.

In that light I think it is even more essential to continue to discuss the
blocksize debate and problem.

> I find more interesting to talk to the users and see how they think
Segwit harms them,

>From an inordinant amount of time spent reading Reddit, I believe this
largely comes down to the rumor that has a deathgrip on the BU community -
That Core are all just extensions of Blockstream, and blockstream wants to
restrict growth on-chain to force growth of their 2nd layer
services(lightning and/or sidechains).

I believe the tone of the discussion needs to be changed, and have been
trying to work to change that tone for weeks now. There's one faction that
believes that Bitcoin will rarely, if ever, benefit from a blocksize
increase, and fees rising is a desired/unavoidable result. There's a
different faction that believes Bitcoin limits are arbitrary and that all
people worldwide should be able to put any size transactions, even
microtransactions, on-chain. Both factions are extreme in their viewpoints
and resort to conspiracy theories to interpret the actions of
Core(blockstream did it) or BU(Jihan controls everything and anyone who
says overwise is a shill paid by Roger Ver!)

It is all very unhealthy for Bitcoin. Both sides need to accept that
microtransactions from all humans cannot go on-chain, and that never
increasing the blocksize doesn't mean millions of home users will run
nodes. The node argument breaks down economically and the microtransaction
argument is an impossible mountain for a blockchain to climb.

On Wed, Mar 29, 2017 at 2:37 AM, Jorge Timón via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> While Segwit's change from 1 mb size limit to 4 mb weight limit seems to
> be controversial among some users (I find that very often it is because
> they have been confused about what segwit does or even outright lied about
> it) I don't think it's very interesting to discuss further size increases.
> I find more interesting to talk to the users and see how they think Segwit
> harms them, maybe we missed something in segwit that needs to be removed
> for segwit to become uncontroversial, or maybe it is just disinformation.
>
> On the other hand, we may want to have our first uncontroversial hardfork
> asap, independently of block size. For example, we could do something as
> simple as fixing the timewarp attack as bip99 proposes. I cannot think of a
> hf that is easier to implement or has less potential for controversy than
> that.
>
> On 29 Mar 2017 8:32 am, "Bram Cohen via bitcoin-dev" <bitcoin-dev at lists.
> linuxfoundation.org> wrote:
>
> On Tue, Mar 28, 2017 at 9:59 AM, Wang Chun via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>> The basic idea is, as many of us agree, hard fork is risky and should
>> be well prepared. We need a long time to deploy it.
>>
>
> Much as it may be appealing to repeal the block size limit now with a
> grace period until a replacement is needed in a repeal and replace
> strategy, it's dubious to assume that an idea can be agreed upon later when
> it can't be agreed upon now. Trying to put a time limit on it runs into the
> possibility that you'll find that whatever reasons there were for not
> having general agreement on a new setup before still apply, and running
> into the embarrassing situation of winding up sticking with the status quo
> after much sturm and drang.
>
>
> _______________________________________________
> 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/20170329/5ef03fb4/attachment-0001.html>;

📅 Original date posted:2017-03-29 📝 Original message:> ...

2023-06-07T17:58:01Z

In reply to nevent1q…xwgp
_________________________

📅 Original date posted:2017-03-29
📝 Original message:> That said, for that to be alleviated we
could simply do something based on historical transaction growth (which
is somewhat linear, with a few inflection points),

Where do you get this? Transaction growth for the last 4 years averages to
+65% per year and the last 2 is +80% per year. That's very much not linear.

On Tue, Mar 28, 2017 at 10:13 AM, Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Not sure what "last week's meeting" is in reference to?
>
> Agreed that the hard fork should be well-prepared, but I think its
> dangerous to think that a hard fork as agreed upon would be a simple
> relaxation of the block size. For example, Johnson Lau's previous
> proposal, Spoonnet, which I think is probably one of the better ones,
> would be incompatible with these rules.
>
> I, of course, worry about what happens if we cannot come to consensus on
> a number to soft fork down to, potentially significantly risking miner
> profits (and, thus, the security of Bitcoin) if a group is able to keep
> things "at the status quo". That said, for that to be alleviated we
> could simply do something based on historical transaction growth (which
> is somewhat linear, with a few inflection points), but that number ends
> up being super low (eg somewhere around 2MB at the next halving, which
> SegWit itself already provides :/.
>
> We could, of course, focus on designing a hard fork's activation and
> technical details, with a very large block size increase in it (ie
> closer to 4/6MB at the next halving or so, something we at least could
> be confident we could develop software for), with intention to soft fork
> it back down if miner profits are suffering.
>
> Matt
>
> On 03/28/17 16:59, Wang Chun via bitcoin-dev wrote:
> > I've proposed this hard fork approach last year in Hong Kong Consensus
> > but immediately rejected by coredevs at that meeting, after more than
> > one year it seems that lots of people haven't heard of it. So I would
> > post this here again for comment.
> >
> > The basic idea is, as many of us agree, hard fork is risky and should
> > be well prepared. We need a long time to deploy it.
> >
> > Despite spam tx on the network, the block capacity is approaching its
> > limit, and we must think ahead. Shall we code a patch right now, to
> > remove the block size limit of 1MB, but not activate it until far in
> > the future. I would propose to remove the 1MB limit at the next block
> > halving in spring 2020, only limit the block size to 32MiB which is
> > the maximum size the current p2p protocol allows. This patch must be
> > in the immediate next release of Bitcoin Core.
> >
> > With this patch in core's next release, Bitcoin works just as before,
> > no fork will ever occur, until spring 2020. But everyone knows there
> > will be a fork scheduled. Third party services, libraries, wallets and
> > exchanges will have enough time to prepare for it over the next three
> > years.
> >
> > We don't yet have an agreement on how to increase the block size
> > limit. There have been many proposals over the past years, like
> > BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
> > on. These hard fork proposals, with this patch already in Core's
> > release, they all become soft fork. We'll have enough time to discuss
> > all these proposals and decide which one to go. Take an example, if we
> > choose to fork to only 2MB, since 32MiB already scheduled, reduce it
> > from 32MiB to 2MB will be a soft fork.
> >
> > Anyway, we must code something right now, before it becomes too late.
> > _______________________________________________
> > 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/20170329/5cb7adbe/attachment-0001.html>;