Jared Lee Richardson [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-03-29 to 2017-06-14
💬 Posted a total of 38 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:03:11

- reply

📅 Original date posted:2017-06-13
📝 Original message:> and allows for resource requirements
> that are too high for many users to validate. The block size settings
> there are effectively placebo controls.
Right, but that's my point. Any level of control the fullnodes believe
they have is effectively a placebo, unless the opposition to the miners is
essentially unanimous (and maybe not even then, if the chainsplit doesn't
have any miners to get to the next difficulty change or gets attacked
repeatedly).
> I'm advocating that resource requirements be low
> enough that full validation remains possible for a large percentage of
> the economy.
We're derailed from the main thread at this point, but just wanted to state
that I agree in part. The part I don't agree with is when a single
transaction begins to cost more than a month's worth of full validation,
which has already happened at least once last week, the full validation is
on its way to becoming worthless. The two costs have to be balanced for
the coin to have utility for its users.
I agree with the rest.
Jared
On Tue, Jun 13, 2017 at 5:23 PM, James Hilliard <james.hilliard1 at gmail.com>
wrote:
> On Tue, Jun 13, 2017 at 2:35 PM, Jared Lee Richardson
> <jaredr26 at gmail.com> wrote:
> >> 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.
>
> BU by default uses an "Accept Depth" parameter which effectively lets
> miners decide block size rules and allows for resource requirements
> that are too high for many users to validate. The block size settings
> there are effectively placebo controls.
>
> >
> > 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.
>
> That's largely true that they typically don't decide the victor in
> soft forks unless they are the ones to activate the rules
> changes(satoshi did this a few times in the early days), however they
> make it very difficult for a hard fork to be activated without
> consent. Yes, I'm not advocating for having runtime consensus settings
> for nodes either, I'm advocating that resource requirements be low
> enough that full validation remains possible for a large percentage of
> the economy.
>
> >
> >> 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.
>
> More likely the false signal would be used during the orphaning period
> to prevent blocks from being orphaned for miners that don't want to
> follow the fork.
>
> >
> >> 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.
>
> Yes, there is a good amount of risk with validationless mining right
> now here since it's well known that over half of mining pools use
> validationless mining to some degree. This may not be too bad though
> due to fallbacks but the risk is probably fairly implementation
> specific.
>
> >
> >
> >
> >
> > 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/825eb1cb/attachment-0001.html>

2023-06-07 18:03:10

- reply

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

2023-06-07 18:02:45

- reply

📅 Original date posted:2017-06-07
📝 Original message:> BIP148 however is a consensus change that can
> be rectified if it gets more work, this would act as an additional
> incentive for mine the BIP148 side since there would be no wipeout
> risk there.
This statement is misleading. Wipeout risks don't apply to any consensus
changes; It is a consensus change, it can only be abandoned. The BIP148
chain carries just as many risks of being abandoned or even more with
segwit2x on the table. No miner would consider "wipeout risk" an advantage
when the real threat is chain abandonment.
> Higher transaction fees on a minority chain can compensate miners for
> a lower price which would likely be enough to get the BIP148 chain to
> a difficulty reduction.
Higher transaction fees suffers the same problem as exchange support does.
Without replay protection, it is very difficult for any average user to
force transactions onto one chain or the other. Thus, without replay
protection, the UASF chain is unlikely to develop any viable fee market;
Its few miners 99% of the time will simply choose from the highest fees
that were already available to the other chain, which is basically no
advantage at all.
> ETC replay protection was done after the fork on an as
> needed basis(there are multiple reliable techniques that can be used
> to split UTXO's), the same can happen with BIP148 and it is easier to
> do with Bitcoin than with the ETH/ETC split IMO.
ETC replay protection was added because they were already a hardfork and
without it they would not have had a viable chain. BIP148 is not supposed
to be a hardfork, and if it added replay protection to remain viable it
would lose the frequently touted "wipeout advantage" as well as the ability
to call itself a softfork. And are you seriously suggesting that what
happened with ETC and ETH is a desirable and good situation for Bitcoin,
and that UASF is ETC?
> A big reason BIP148 still has support is because up until SegWit
> actually activates there's no guarantee segwit2mb will actually have
> the necessary support to activate SegWit.
For a miners blowing through six million dollars a day in mining
operational costs, that's a pretty crappy reason. Serious miners can't
afford to prop up a non-viable chain based on philosophy or maybes. BIP148
is based entirely upon people who aren't putting anything on the line
trying to convince others to take the huge risks for them. With
deceptively fallacious logic, in my opinion.
Even segwit2x is based on the assumption that all miners can reach
consensus. Break that assumption and segwit2x will have the same problems
as UASF.
> This is largely an issue due to segwit2x's bundling, if the SW and HF
> part of segwit2x were unbundled then there would be no reason to delay
> BIP91 activation
They are bundled. Segwit alone doesn't have the desired overwhelming
consensus, unless core wishes to fork 71% to 29%, and maybe not even that
high. That's the technical reason, and they can't be unbundled without
breaking that consensus.
Jared
On Wed, Jun 7, 2017 at 4:11 PM, James Hilliard <james.hilliard1 at gmail.com>
wrote:
> On Wed, Jun 7, 2017 at 5:53 PM, Jared Lee Richardson <jaredr26 at gmail.com>
> wrote:
> >> There are 2 primary factors involved here, economic support and
> > hashpower either of which is enough to make a permanent chain split
> > unlikely, miners will mine whichever chain is most profitable(see
> > ETH/ETC hashpower profitability equilibrium for an example of how this
> > works in practice)
> >
> > That's not a comparable example. ETC did not face potentially years of
> slow
> > blocktimes before it normalized, whereas BIP148 is on track to do exactly
> > that. Moreover, ETC represented a fundamental break from the majority
> > consensus that could not be rectified, whereas BIP148 represents only a
> > minority attempt to accelerate something that an overwhelming majority of
> > miners have already agreed to activate under segwit2x. Lastly ETC was
> > required to add replay protection, just like any minority fork proposed
> by
> > any crypto-currency has been, something that BIP148 both lacks and
> refuses
> > to add or even acknowledge the necessity of. Without replay protection,
> ETC
> > could not have become profitable enough to be a viable minority chain.
> If
> > BIP148's chain is not the majority chain and it does not have replay
> > protection, it will face the same problems, but that required replay
> > protection will turn it into a hardfork. This will be a very bad
> position
> > for UASF supporters to find themselves in - Either hardfork and hope the
> > price is higher and the majority converts, or die as the minority chain
> with
> > no reliable methods of economic conversion.
> Higher transaction fees on a minority chain can compensate miners for
> a lower price which would likely be enough to get the BIP148 chain to
> a difficulty reduction. BIP148 however is a consensus change that can
> be rectified if it gets more work, this would act as an additional
> incentive for mine the BIP148 side since there would be no wipeout
> risk there. ETC replay protection was done after the fork on an as
> needed basis(there are multiple reliable techniques that can be used
> to split UTXO's), the same can happen with BIP148 and it is easier to
> do with Bitcoin than with the ETH/ETC split IMO.
> >
> > I believe, but don't have data to back this, that most of the BIP148
> > insistence comes not from a legitimate attempt to gain consensus (or else
> > they would either outright oppose segwit2mb for its hardfork, or they
> would
> > outright support it), but rather from an attempt for BIP148 supporters to
> > save face for BIP148 being a failure. If I'm correct, that's a terrible
> and
> > highly non-technical reason for segwit2mb to bend over backwards
> attempting
> > to support BIP148's attempt to save face.
> A big reason BIP148 still has support is because up until SegWit
> actually activates there's no guarantee segwit2mb will actually have
> the necessary support to activate SegWit.
> >
> >> The main issue is just one of activation timelines, BIP91 as
> > is takes too long to activate unless started ahead of the existing
> > segwit2x schedule and it's unlikely that BIP148 will get pushed back
> > any further.
> >
> > Even if I'm not correct on the above, I and others find it hard to accept
> > that this timeline conflict is segwit2x's fault. Segwit2x has both some
> > flexibility and broad support that crosses contentious pro-segwit and
> > pro-blocksize-increase divisions that have existed for two years.
> BIP148 is
> > attempting to hold segwit2x's timelines and code hostage by claiming
> > inflexibility and claiming broad support, and not only are neither of
> those
> > assertions are backed by real data, BIP148 (by being so inflexible) is
> > pushing a position that deepens the divides between those groups. For
> there
> > to be technical reasons for compatibility (so long as there are
> tradeoffs,
> > which there are), there needs to be hard data showing that BIP148 is a
> > viable minority fork that won't simply die off on its own.
> This is largely an issue due to segwit2x's bundling, if the SW and HF
> part of segwit2x were unbundled then there would be no reason to delay
> BIP91 activation, this is especially a problem since it takes a good
> deal of time to properly code and test a HF. Unfortunately segwit2x
> has been quite inflexible in regards to the bundling aspect even
> though there are clearly no technical reasons for it to be there.
> >
> > Jared
> >
> >
> > On Wed, Jun 7, 2017 at 3:23 PM, James Hilliard <
> james.hilliard1 at gmail.com>
> > wrote:
> >>
> >> On Wed, Jun 7, 2017 at 4:50 PM, Jared Lee Richardson <
> jaredr26 at gmail.com>
> >> wrote:
> >> > Could this risk mitigation measure be an optional flag? And if so,
> >> > could it+BIP91 signal on a different bit than bit4?
> >> It's fairly trivial for miners to signal for BIP91 on bit4 or a
> >> different bit at the same time as the code is trivial enough to
> >> combine
> >> >
> >> > The reason being, if for some reason the segwit2x activation cannot
> >> > take place in time, it would be preferable for miners to have a more
> >> > standard approach to activation that requires stronger consensus and
> >> > may be more forgiving than BIP148. If the segwit2x activation is on
> >> > time to cooperate with BIP148, it could be signaled through the
> >> > non-bit4 approach and everything could go smoothly. Thoughts on that
> >> > idea? It may add more complexity and more developer time, but may
> >> > also address your concerns among others.
> >> This does give miners another approach to activate segwit ahead of
> >> BIP148, if segwit2x activation is rolled out and activated immediately
> >> then this would not be needed however based on the timeline here
> >> https://segwit2x.github.io/ it would not be possible for BIP91 to
> >> enforce mandatory signalling ahead of BIP148. Maybe that can be
> >> changed though, I've suggested an immediate rollout with a placeholder
> >> client timeout instead of the HF code initially in order to accelerate
> >> that.
> >> >
> >> >> Since this BIP
> >> >> only activates with a clear miner majority it should not increase the
> >> >> risk of an extended chain split.
> >> >
> >> > The concern I'm raising is more about the psychology of giving BIP148
> >> > a sense of safety that may not be valid. Without several more steps,
> >> > BIP148 is definitely on track to be a risky chainsplit, and without
> >> > segwit2x it will almost certainly be a small minority chain. (Unless
> >> > the segwit2x compromise falls apart before then, and even in that case
> >> > it is likely to be a minority chain)
> >> There are 2 primary factors involved here, economic support and
> >> hashpower either of which is enough to make a permanent chain split
> >> unlikely, miners will mine whichever chain is most profitable(see
> >> ETH/ETC hashpower profitability equilibrium for an example of how this
> >> works in practice) however there may be lag time immediately after the
> >> split if there is an economic majority but not a hashpower majority
> >> initially. This is risk mitigation that only requires miners support
> >> however. The main issue is just one of activation timelines, BIP91 as
> >> is takes too long to activate unless started ahead of the existing
> >> segwit2x schedule and it's unlikely that BIP148 will get pushed back
> >> any further.
> >> >
> >> > Jared
> >> >
> >> >
> >> > On Wed, Jun 7, 2017 at 2:42 PM, James Hilliard
> >> > <james.hilliard1 at gmail.com> wrote:
> >> >> I don't really see how this would increase the likelihood of an
> >> >> extended chain split assuming BIP148 is going to have
> >> >> non-insignificant economic backing. This BIP is designed to provide a
> >> >> risk mitigation measure that miners can safely deploy. Since this BIP
> >> >> only activates with a clear miner majority it should not increase the
> >> >> risk of an extended chain split. At this point it is not completely
> >> >> clear how much economic support there is for BIP148 but support
> >> >> certainly seems to be growing and we have nearly 2 months until
> BIP148
> >> >> activation. I intentionally used a shorter activation period here so
> >> >> that decisions by miners can be made close to the BIP148 activation
> >> >> date.
> >> >>
> >> >> On Wed, Jun 7, 2017 at 4:29 PM, Jared Lee Richardson
> >> >> <jaredr26 at gmail.com> wrote:
> >> >>> 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170607/875ec296/attachment-0001.html>

2023-06-07 18:02:21

- reply

📅 Original date posted:2017-06-02
📝 Original message:> The above decision may quickly become very controversial. I don't think
it's what most users had/have in mind when they discuss a "2MB+SegWit"
solution.
> With the current 1MB+SegWit, testing has shown us that normal usage
results in ~2 or 2.1MB blocks.
> I think most users will expect a linear increase when Base Size is
increased to 2000000 bytes and Total Weight is increased to 8000000 bytes.
With normal usage, the expected results would then be ~4 or 4.2MB blocks.
I think Calvin is correct here, the secondary limit is not what people
anticipated with the segwit + 2mb agreement. It would not kill the
agreement for me, but it might for others.
What is the justification for the secondary limitation? Is there hard data
to back this? The quadratic hashing problem is frequently brought up, but
that is trivially handled with a hard 1mb transaction limit and on the
other thread there's talk/suggestions of an even lower limit. Are there
any other reasons for this limitation, and is there data to justify those
concerns? If not, this should be left out in favor of a transaction size
limit. If so, hard data would go a long way to dealing with the conversy
this will create.
> Shaolin Fry’s “Mandatory activation of segwit deployment”[3] is included
to:
> > cause the existing "segwit" deployment to activate without needing to
release a new deployment.
> Both of the aforementioned activation options (“fast-activation” and
“flag-day activation”) serve to prevent unnecessary delays in the network
upgrade process, addressing a common criticism of the Scaling Agreement and
providing an opportunity for cooperation and unity instead.
This is likely to cause more controversy and unfortunately has the tightest
timelines. Unlike the SW2mb working group's timelines, a hard-coded
timeline couldn't be changed with mutual agreement from the signers.
Given the chance of bit1 accidental activation without clear signaling for
the required bit4 2mb hard fork, I don't think the fair or acceptable
tradeoff is for flag day to require bit1 signaling only. *Flag day should
be modified to accept either bit1 signaling, OR to accept bit4 signaling IF
the 80% threshold hasn't been met.* In this way the anti-segwit working
group members are not in danger of an activated bit1 segwit without also
getting their portion of the compromise, the bit4 signaled HF. If flag day
accepts bit4 OR bit1, AND bit4 requires both bit1 and bit4 once 80% is
reached, flag day is nearly guaranteed to get its stated desire within 1750
blocks (bit4 accepted until block 800; bit4+bit1 signaled afterwards until
95%), but without the chance that the WG signers won't get what they agreed
to.
*That seems like a minor compromise for BIP148. Thoughts on this change to
flag day / BIP148?*
In addition, the aggressiveness of the timelines and the complexity of the
merged COOP proposal may require the BIP148 flag day to be pushed back. I
would think some day in September is achievable, but I'm not sure if August
1st will be.
Jared
On Tue, May 30, 2017 at 3:20 PM, CalvinRechner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> In principle, there is complete flexibility when it comes to the specific
> consensus details of the hard fork. One common suggestion has been to phase
> in a gradual blocksize increase beyond the initial 2MB cap included in
> Luke-Jr's proposal (a la BIP103); this would certainly be a welcome
> inclusion in the Omnibus Proposal, provided that is what we want. The
> reasoning behind incorporating Luke-Jr's 2MB limit and discount-rebalancing
> was to satisfy the conditions of the Scaling Agreement while ensuring
> maximum safety, minimum code discrepancies, and minimum controversy among
> the community; these priorities seem imperative, considering the extreme
> timeline constraints we are working under and the goals of the proposal. To
> put it more simply, the intent of the proposal was to serve as a template
> for the minimum viable fork that can achieve true consensus. A gradual
> increase to a larger size cap, especially if it were reasonably
> conservative, would be wholly in accordance with the Omnibus Proposal if
> that is what it takes to achieve the cooperation between community,
> industry, and developers in this critical moment of Bitcoin's history.
>
>
> The purpose of the Omnibus Proposal is singlefold: to achieve the goals of
> the Consensus 2017 Scaling Agreement in the most maximally-compatible way.
> We can minimize disruption and loss potential all around by solving these
> problems in a compatibility-oriented manner. It is possible to fulfill both
> the letter and the spirit of the Scaling Agreement, to the complete
> satisfaction of all involved, while preventing chain-split risks in the
> meantime.
>
>
> There is no justification for incompatibility with existing deployment
> approaches, when there is the possibility to work together towards our
> mutual goals instead. The most rational option is to join forces and avoid
> any chain-split potential for as long as possible. Under the Omnibus
> Proposal, once SegWit is activated, the terms of the hard fork are locked
> in automatically, set to activate 6 months later. The proposal guarantees
> that a successful SegWit activation is followed by a hard fork. Beyond
> enforcing the hard fork rules beginning at block height HardForkHeight, the
> Omnibus Proposal simply represents compatibility with the existing
> SegWit-activation deployment approaches.
>
>
> By committing to this proposal, we can ensure unity, at least for now.
> There do not appear to be any arguments to the contrary. Why squander this
> opportunity for consensus and harmony? We can leverage the momentum of
> several disparate movements, and perhaps enjoy some much-needed social
> solidarity. In a way, everyone can get what they want, and through
> cooperation, we avoid the risk of a costly fracture.
>
>
> The Segwit2x Team has begun work on an implementation of the Consensus
> Scaling Agreement, their operational timeline including the publication of
> a BIP on June 16, 2017.[1] I call upon the developers and maintainers of
> this initiative to consider and honor the Omnibus Proposal, extended or
> modified as needed, as the guiding approach to your development effort.
> Almost every component of the code exists, in some form or fashion, in the
> various constituent proposals' reference implementations, most of which
> have already undergone a significant degree of peer review.
>
>
> We cannot afford to delay, nor to reimplement; the launch timeline is
> aggressively optimistic as it is. The quickest and safest approach to
> achieving the goals set forth at Consensus 2017 is to leverage the existing
> tools and proposals for the job. We can solve our problems properly,
> cooperatively.
>
>
> I humbly ask that Jeff Garzik, Barry Silbert, Mike Belshe, and all of the
> other wonderful, intelligent collaborators on this project step forward and
> support the cooperative, compatibility-oriented approach of the Omnibus
> Proposal.
>
>
> This is the best way to maximize value for everyone. We have a real
> opportunity to collaborate and work together on the same team. The Omnibus
> Proposal, designed in exact accordance with a powerful industry agreement
> and incorporating the feedback and suggestions provided from within both
> the developer community and the community-at-large, stands the best chance
> of uniting everyone under a common front.
>
>
> Please, for the love of Bitcoin, let us do our best to cooperate.
>
>
>
> [1] https://imgur.com/a/a2oPs
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> -------- Original Message --------
> Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
> Local Time: May 29, 2017 6:49 PM
> UTC Time: May 29, 2017 11:49 PM
> From: opetruzel at gmail.com
> To: CalvinRechner <calvinrechner at protonmail.com>
> Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
>
> >>if the community wishes to adopt (by unanimous consensus) a 2 MB block
> size hardfork, this is probably the best way to do it right now... Legacy
> Bitcoin transactions are given the witness discount, and a block size limit
> of 2 MB is imposed.<<
>
>
> The above decision may quickly become very controversial. I don't think it's
> what most users had/have in mind when they discuss a "2MB+SegWit" solution.
>
> With the current 1MB+SegWit, testing has shown us that normal usage
> results in ~2 or 2.1MB blocks.
>
> I think most users will expect a linear increase when Base Size is
> increased to 2000000 bytes and Total Weight is increased to 8000000 bytes.
> With normal usage, the expected results would then be ~4 or 4.2MB blocks.
>
> Am I missing something here, or does Luke's suggested 2MB cap completely
> nullify that expected linear increase? If so, why? What's the logic behind
> this decision?
>
> I'd love to be armed with a good answer should my colleagues ask me the
> same obvious question, so thank you ahead of time!
>
> Respectfully,
> Oliver Petruzel
>
>
>
>
> _______________________________________________
> 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/20170602/abfac0e2/attachment-0001.html>

2023-06-07 17:59:51

- reply

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

2023-06-07 17:59:21

- reply

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

2023-06-07 17:59:21

- reply

📅 Original date posted:2017-04-06
📝 Original message:> We are not going to invalidate covert asicboost without a fight. And we are working with a system that actively (and is demonstrably very effective at doing it) resists changes which are contentious. This is definitely a contentious change, because an important part of the community (the miners) is going to be actively resisting it.
I'd just like to point out, invalidating asicboost has only a very
limited number of potential detractors. Only a mining farm that
self-mined and used custom software would be able to exploit this.
Every other mining farm on the planet, plus any users wishing for more
transactions to be included in blocks would be in favor of this,
assuming the theory that it favors fewer transactions is correct.
That makes it less contentious than many other alternatives. It might
even force the mining operation(s) in question to flip and support SW
in order to avoid losing face and/or appearing guilty.
As an additional plus, nearly all of the BU crowd and most BU
supporting miners would have little reason to object to Asicboost -
Based on philosophy alone, but not based on any practical
considerations.
Jared
On Wed, Apr 5, 2017 at 8:23 PM, David Vorick via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I have a practical concern related to the amount of activation energy
> required to get something like this through. We are talking about
> implementing something that would remove tens to hundreds of millions of
> dollars of mining revenue for miners who have already gambled that this
> income would be available to them.
>
> That's not something they are going to let go of without a fight, and we've
> already seen this with the segwit resistance. Further, my understanding is
> that this makes a UASF a lot more difficult. Mining hardware that has unique
> optimizations on one chain only can resist a UASF beyond a simple economic
> majority, because they can do more hashes on the same amount of revenue.
> Threshold for success is no longer 51%, especially if you are expecting the
> miners to struggle (and this is a case where they have a very good reason to
> struggle). Any resistance from the hashrate during the early days of a UASF
> will inevitably cause large reorgs for older nodes, and is not much better
> than a hardfork.
>
> I don't know what the right answer is. But I know that we are not going to
> get segwit without a fight. We are not going to invalidate covert asicboost
> without a fight. And we are working with a system that actively (and is
> demonstrably very effective at doing it) resists changes which are
> contentious. This is definitely a contentious change, because an important
> part of the community (the miners) is going to be actively resisting it.
>
> I urge everybody to realize how difficult something like this is going to be
> to pull off. We are literally talking about invalidating hardware (or at
> least the optimized bits). It's only going to succeed if everybody is
> conclusively on board. As you consider proposals, realize that anything
> which is not the simplest and least contentious is already dead.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:58:47

- reply

📅 Original date posted:2017-04-01
📝 Original message:> Remember that the "hashpower required to secure bitcoin" is determined
> as a percentage of total Bitcoins transacted on-chain in each block
Can you explain this statement a little better? What do you mean by
that? What does the total bitcoins transacted have to do with
hashpower required?
On Fri, Mar 31, 2017 at 2:22 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hey Sergio,
>
> You appear to have ignored the last two years of Bitcoin hardfork
> research and understanding, recycling instead BIP 102 from 2015. There
> are many proposals which have pushed the state of hard fork research
> much further since then, and you may wish to read some of the posts on
> this mailing list listed at https://bitcoinhardforkresearch.github.io/
> and make further edits based on what you learn. Your goal of "avoid
> technical changes" appears to not have any basis outside of perceived
> compromise for compromise sake, only making such a hardfork riskier
> instead.
>
> At a minimum, in terms of pure technical changes, you should probably
> consider (probably among others):
>
> a) Utilizing the "hard fork signaling bit" in the nVersion of the block.
> b) Either limiting non-SegWit transactions in some way to fix the n**2
> sighash and FindAndDelete runtime and memory usage issues or fix them by
> utilizing the new sighash type which many wallets and projects have
> already implemented for SegWit in the spending of non-SegWit outputs.
> c) Your really should have replay protection in any HF. The clever fix from
> Spoonnet for poor scaling of optionally allowing non-SegWit outputs to
> be spent with SegWit's sighash provides this all in one go.
> d) You may wish to consider the possibility of tweaking the witness
> discount and possibly discounting other parts of the input - SegWit went
> a long ways towards making removal of elements from the UTXO set cheaper
> than adding them, but didn't quite get there, you should probably finish
> that job. This also provides additional tuneable parameters to allow you
> to increase the block size while not having a blowup in the worst-case
> block size.
> e) Additional commitments at the top of the merkle root - both for
> SegWit transactions and as additional space for merged mining and other
> commitments which we may wish to add in the future, this should likely
> be implemented an "additional header" ala Johnson Lau's Spoonnet proposal.
>
> Additionally, I think your parameters here pose very significant risk to
> the Bitcoin ecosystem broadly.
>
> a) Activating a hard fork with less than 18/24 months (and even then...)
> from a fully-audited and supported release of full node software to
> activation date poses significant risks to many large software projects
> and users. I've repeatedly received feedback from various folks that a
> year or more is likely required in any hard fork to limit this risk, and
> limited pushback on that given the large increase which SegWit provides
> itself buying a ton of time.
>
> b) Having a significant discontinuity in block size increase only serves
> to confuse and mislead users and businesses, forcing them to rapidly
> adapt to a Bitcoin which changed overnight both by hardforking, and by
> fees changing suddenly. Instead, having the hard fork activate technical
> changes, and then slowly increasing the block size over the following
> several years keeps things nice and continuous and also keeps us from
> having to revisit ye old blocksize debate again six months after activation.
>
> c) You should likely consider the effect of the many technological
> innovations coming down the pipe in the coming months. Technologies like
> Lightning, TumbleBit, and even your own RootStock could significantly
> reduce fee pressure as transactions move to much faster and more
> featureful systems.
>
> Commitments to aggressive hard fork parameters now may leave miners
> without much revenue as far out as the next halving (which current
> transaction growth trends are indicating we'd just only barely reach 2MB
> of transaction volume, let alone if you consider the effects of users
> moving to systems which provide more features for Bitcoin transactions).
> This could lead to a precipitous drop in hashrate as miners are no
> longer sufficiently compensated.
>
> Remember that the "hashpower required to secure bitcoin" is determined
> as a percentage of total Bitcoins transacted on-chain in each block, so
> as subsidy goes down, miners need to be paid with fees, not just price
> increases. Even if we were OK with hashpower going down compared to the
> value it is securing, betting the security of Bitcoin on its price
> rising exponentially to match decreasing subsidy does not strike me as a
> particularly inspiring tradeoff.
>
> There aren't many great technical solutions to some of these issues, as
> far as I'm aware, but it's something that needs to be incredibly
> carefully considered before betting the continued security of Bitcoin on
> exponential on-chain growth, something which we have historically never
> seen.
>
> Matt
>
>
> On March 31, 2017 5:09:18 PM EDT, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>Hi everyone,
>>
>>Segwit2Mb is the project to merge into Bitcoin a minimal patch that
>>aims to
>>untangle the current conflict between different political positions
>>regarding segwit activation vs. an increase of the on-chain blockchain
>>space through a standard block size increase. It is not a new solution,
>>but
>>it should be seen more as a least common denominator.
>>
>>Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB
>>block
>>size hard-fork activated ONLY if segwit activates (95% of miners
>>signaling), but at a fixed future date.
>>
>>The sole objective of this proposal is to re-unite the Bitcoin
>>community
>>and avoid a cryptocurrency split. Segwit2Mb does not aim to be best
>>possible technical solution to solve Bitcoin technical limitations.
>>However, this proposal does not imply a compromise to the future
>>scalability or decentralization of Bitcoin, as a small increase in
>>block
>>size has been proven by several core and non-core developers not to
>>affect
>>Bitcoin value propositions.
>>
>>In the worst case, a 2X block size increase has much lower economic
>>impact
>>than the last bitcoin halving (<10%), which succeeded without problem.
>>
>>On the other side, Segwit2Mb primary goal is to be minimalistic: in
>>this
>>patch some choices have been made to reduce the number of lines
>>modified in
>>the current Bitcoin Core state (master branch), instead of implementing
>>the
>>most elegant solution. This is because I want to reduce the time it
>>takes
>>for core programmers and reviewers to check the correctness of the
>>code,
>>and to report and correct bugs.
>>
>>The patch was built by forking the master branch of Bitcoin Core,
>>mixing a
>>few lines of code from Jeff Garzik's BIP102, and defining a second
>>versionbits activation bit (bit 2) for the combined activation.
>>
>>The combined activation of segwit and 2Mb hard-fork nVersion bit is 2
>>(DEPLOYMENT_SEGWIT_AND_2MB_BLOCKS).
>>
>>This means that segwit can still be activated without the 2MB hard-fork
>>by
>>signaling bit 1 in nVersion (DEPLOYMENT_SEGWIT).
>>
>>The tentative lock-in and hard-fork dates are the following:
>>
>>Bit 2 signaling StartTime = 1493424000; // April 29th, 2017
>>
>>Bit 2 signaling Timeout = 1503964800; // August 29th, 2017
>>
>>HardForkTime = 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT
>>
>>
>>The hard-fork is conditional to 95% of the hashing power has approved
>>the
>>segwit2mb soft-fork and the segwit soft-fork has been activated (which
>>should occur 2016 blocks after its lock-in time)
>>
>>For more information on how soft-forks are signaled and activated, see
>>https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
>>
>>This means that segwit would be activated before 2Mb: this is
>>inevitable,
>>as versionbits have been designed to have fixed activation periods and
>>thresholds for all bits. Making segwit and 2Mb fork activate together
>>at a
>>delayed date would have required a major re-write of this code, which
>>would
>>contradict the premise of creating a minimalistic patch. However, once
>>segwit is activated, the hard-fork is unavoidable.
>>
>>Although I have coded a first version of the segwit2mb patch (which
>>modifies 120 lines of code, and adds 220 lines of testing code), I
>>would
>>prefer to wait to publish the source code until more comments have been
>>received from the community.
>>
>>To prevent worsening block verification time because of the O(N^2)
>>hashing
>>problem, the simple restriction that transactions cannot be larger than
>>1Mb
>>has been kept. Therefore the worse-case of block verification time has
>>only
>>doubled.
>>
>>Regarding the hard-fork activation date, I want to give enough time to
>>all
>>active economic nodes to upgrade. As of Fri Mar 31 2017,
>>https://bitnodes.21.co/nodes/ reports that 6332 out of 6955 nodes (91%)
>>have upgraded to post 0.12 versions. Upgrade to post 0.12 versions can
>>be
>>used to identify economic active nodes, because in the 0.12 release
>>dynamic
>>fees were introduced, and currently no Bitcoin automatic payment system
>>can
>>operate without automatic discovery of the current fee rate. A pre-0.12
>>would require constant manual intervention.
>>Therefore I conclude that no more than 91% of the network nodes
>>reported by
>>bitnodes are active economic nodes.
>>
>>As Bitcoin Core 0.12 was released on February 2016, the time for this
>>91%
>>to upgrade has been around one year (under a moderate pressure of
>>operational problems with unconfirmed transactions).
>>Therefore we can expect a similar or lower time to upgrade for a
>>hard-fork,
>>after developers have discussed and approved the patch, and it has been
>>reviewed and merged and 95% of the hashing power has signaled for it
>>(the
>>pressure not to upgrade being a complete halt of the operations).
>>However I
>>suggest that we discuss the hard-fork date and delay it if there is a
>>real
>>need to.
>>
>>Currently time works against the Bitcoin community, and so is delaying
>>a
>>compromise solution. Most of the community agree that halting the
>>innovation for several years is a very bad option.
>>
>>After the comments collected by the community, a BIP will be written
>>describing the resulting proposal details.
>>
>>If segwit2mb locks-in, before hard-fork occurs all bitcoin nodes should
>>be
>>updated to a Segwit2Mb enabled node to prevent them to be forked-away
>>in a
>>chain with almost no hashing-power.
>>
>>The proof of concept patch was made for Bitcoin Core but should be
>>easily
>>ported to other Bitcoin protocol implementations that already support
>>versionbits. Lightweight (SPV) wallets should not be affected as they
>>generally do not check the block size.
>>
>>I personally want to see the Lightning Network in action this year, use
>>the
>>non-malleability features in segwit, see the community discussing other
>>exciting soft-forks in the scaling roadmap, Schnorr sigs, drivechains
>>and
>>MAST.
>>
>>I want to see miners, developers and industry side-by-side pushing
>>Bitcoin
>>forward, to increase the value of Bitcoin and prevent high transaction
>>fees
>>to put out of business use-cases that could have high positive social
>>impact.
>>
>>I believe in the strength of a unified Bitcoin community. If you're a
>>developer, please give your opinion, suggest changes, audit it, and
>>take a
>>stand with me to unlock the current Bitcoin deadlock.
>>
>>Contributions to the segwit2mb project are welcomed and awaited. The
>>only
>>limitation is to stick to the principle that the patch should be as
>>simple
>>to audit as possible. As an example, I wouldn't feel confident if the
>>patch
>>modified more than ~150 lines of code.
>>
>>Improvements unrelated to a 2 Mb increase or segwit, as beneficial as
>>it
>>may be to Bitcoin, should not be part of segwit2Mb.
>>
>>This proposal should not prevent other consensus proposals to be
>>simultaneously merged: segwit2mb is a last resort solution in case we
>>can
>>not reach consensus on anything better.
>>
>>Again, the proposal is only a starting point: community feedback is
>>expected and welcomed.
>>
>>Regards,
>>Sergio Demian Lerner
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:58:42

- reply

📅 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

2023-06-07 17:58:18

- reply

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

2023-06-07 17:58:11

- reply

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

2023-06-07 17:58:07

- reply

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

2023-06-07 17:58:06

- reply

📅 Original date posted:2017-03-29
📝 Original message:> When considering what block size is acceptable, the impact of running
bitcoin in the background on affordable, non-dedicated home-hardware should
be a top consideration.
Why is that a given? Is there math that outlines what the risk levels are
for various configurations of node distributions, vulnerabilities, etc?
How does one even evaluate the costs versus the benefits of node costs
versus transaction fees?
> 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>

2023-06-07 17:58:01

- reply

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