<unnamed>

Public Key

npub1hzkv59ax7ax80nv2fzvcgmveqyk3k5sg9gq695n48l9scenf5c9sa7nzv7

Profile Code

nprofile1qqst3tx2z7n0wnrhek9y3xvydkvsztgm2gyz5qdz6f6nljcvve56vzcpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqshc0z9

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 18:02:01 UTC

- reply

📅 Original date posted:2017-05-30
📝 Original message:Yann, Unfortunately sybil attacks [[https://en.wikipedia.org/wiki/Sybil_attack#Description]](https://en.wikipedia.org/wiki/Sybil_attack#Description) would prevent this from working... even if there was some way to prove that an entity performed the transaction validation. Proving the relay of transaction data to others is also vulnerable to sybil attack.
-------- Original Message --------
Subject: [bitcoin-dev] Improvement Proposal
Local Time: May 30, 2017 8:48 AM
UTC Time: May 30, 2017 1:48 PM
From: bitcoin-dev at lists.linuxfoundation.org
To: bitcoin-dev at lists.linuxfoundation.org
Improvement Proposal
To allow users devices (including mobile and/or IoT devices). to connect and some how participate in the same BTC bock chain network without mining.
The incentive for this participants can be a lottery schema, running in "parallel to mining in the same network" and in the block-chain.
Rewarding some lucky participant user (and/or miner?) randomly every specific period of time.
Participants will pay the price on each connection round.
Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170530/773e2132/attachment-0001.html>

2023-06-07 18:00:33 UTC

- reply

📅 Original date posted:2017-04-26
📝 Original message:Johnson Lau,
> not change the commitment structure as suggested by another post
Not sure if you realize my proposal is backwards compatible. We could also merge the two arrays, which would be harder to compress, but a more simple format. Below I gave an example of how this would be backwards compatible.
1-byte - OP_RETURN (0x6a)
1-byte - Push the following 36 bytes (0x24)
4-byte - Commitment header (0xaa21a9ed)
32-byte - Commitment hash: Double-SHA256(witness root hash|witness reserved value*)
variable bytes - Extension roots: array of {extension identifier, extension root length, extension root}
bytes onwards: Optional data with no consensus meaning
* "witness reserved value" _must_ also go in the input's scriptSig/witness field
Here is an example of the "Extension roots" with this format:
Extension roots: 2, {0, 0, []}, {1, 0, []}
size = 2 // two elements in Commitment hash
{ext.id = 0, length = 0, empty} // First element is the wtxid merkle root hash, must be calculated, not specified here
{ext.id = 1, length = 0, empty} // Second element is the "witness reserved value", which is found in the scriptSig
Later after all the miners upgrade, we could stop using the ext.id = 1 and also stop putting the unneccesary value in scriptSig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170426/b8487e38/attachment-0001.html>

2023-06-07 18:00:32 UTC

- reply

📅 Original date posted:2017-04-26
📝 Original message:Luke,
I can't really advise on your proposed changes... but I have a couple new suggestions:
=== Future Proof Commitment Extension Methodology ===
1. I'm not a fan of how ambiguous the direction is on handling future commitment extensions. See https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Extensible_commitment_structure.
1-byte - OP_RETURN (0x6a)
1-byte - Push the following 36 bytes (0x24)
4-byte - Commitment header (0xaa21a9ed)
32-byte - Commitment hash: Double-SHA256(witness root hash|witness reserved value*)
39th byte onwards: Optional data with no consensus meaning
* "witness reserved value" _must_ also go in the input's scriptSig/witness field... blah blah blah warning warning.
Where is the new "witness reserved value" going to go for the next extension? Why waste 32 bytes in some arbitrary location, and then later when there is an extension, eventually be wasting 32 more bytes at some other arbitrary location?
Here's a more well defined/future proof proposal that uses fewer bytes:
1-byte - OP_RETURN (0x6a)
1-byte - Push the following 36 bytes (0x24)
4-byte - Commitment header (0xaa21a9ed)
32-byte - Commitment hash: Double-SHA256(extension root A|extension root B|extension root C...)
variable bytes - Extension identifiers: array of extension identifiers
variable bytes - Extension roots: array of {extension identifier, extension root length, extension root}
next byte onwards - Optional data with no consensus meaning
- The extension identifiers are ordered the same as the order of the extension roots in the merkle root.
- The extension identifiers can be highly compacted together using a custom compression algorithm.
- The array length for the extension roots can be a utf8-like format, where up to 0-127 can be represented with one byte, and 128-16383 can be represented with two bytes.
- The extension roots themselves only need to be provided for the sake of clients that are unable or not desiring to compute a particular extension root, but do want to verify some of the extension roots.
This design is much more future proof, and uses less space. With SegWit only, this would take up maybe 1 byte for the extension identifiers (compressed length 1 and id 0 for wtxroot), and 1 byte for the extension roots (array length = 0).
=== Replay Attack Prevention ===
2. Implement the Policy ID 'replay attack" prevention that I have suggested (but is in dev list purgatory), which increases each wtx length by 1 byte. This can be reduced in a block by clustering Policy ID ranges in the coinbase... or by guessing the Policy ID. Witness data would sign on the Policy ID... preventing replay if at least one branch adopted a new Policy ID.
Cheers,
Praxeology Guy
-------- Original Message --------
Subject: [bitcoin-dev] Segwit v2
Local Time: April 20, 2017 3:28 PM
UTC Time: April 20, 2017 8:28 PM
From: bitcoin-dev at lists.linuxfoundation.org
To: bitcoin-dev at lists.linuxfoundation.org
Since BIP 141's version bit assignment will timeout soon, and needing renewal,
I was thinking it might make sense to make some minor tweaks to the spec for
the next deployment. These aren't critical, so it's perfectly fine if BIP 141
activates as-is (potentially with BIP 148), but IMO would be an improvement if
a new deployment (non-BIP148 UASF and/or new versionbit) is needed.
1. Change the dummy marker to 0xFF instead of 0. Using 0 creates ambiguity
with incomplete zero-input transactions, which has been a source of confusion
for raw transaction APIs. 0xFF would normally indicate a >32-bit input count,
which is impossible right now (it'd require a >=158 GB transaction) and
unlikely to ever be useful.
2. Relax the consensus rules on when witness data is allowed for an input.
Currently, it is only allowed when the scriptSig is null, and the scriptPubKey
being spent matches a very specific pattern. It is ignored by "upgrade-safe"
policy when the scriptPubKey doesn't match an even-more-specific pattern.
Instead, I suggest we allow it (in the consensus layer only) in combination
with scriptSig and with any scriptPubKey, and consider these cases to be
"upgrade-safe" policy ignoring.
The purpose of the second change is to be more flexible to any future
softforks. I consider it minor because we don't know of any possibilities
where it would actually be useful.
Thoughts?
Luke
_______________________________________________
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/20170426/6a50a078/attachment.html>

2023-06-07 18:00:04 UTC

- reply

📅 Original date posted:2017-04-14
📝 Original message:Chris,
>Food for thought, why are we rejecting *all* blocks that do not signal segwit? Can't we just reject blocks that *do not* signal segwit, but *do* contain segwit transactions? It seems silly to me that if a miner mines a block with all pre segwit txs to reject that block. Am I missing something here?
If you read my email, you will see that I am requesting that gmaxwell or someone code up an alternative that doesn't unnecessarily orphan blocks, just as you are requesting.
> Re: old blocks containing SegWit transactions
From my understanding, old blocks can contain txos w/ the new SegWit format. But if transaction tries to spend a new SegWit format txo in an old block, such would already break protocol rules, particularly for SegWit activated nodes. And old nodes don't have code that even knows how to spend SegWit format txos. Worst case, such may lead to a fork if <= 50% of the miners are verifying SegWit blocks.
> Re: Reckless hand waving:
Maybe first you need to prove that forks are necessarily bad for our long term success. How much do we need to be getting delayed in rolling out new good policy before we come to consensus on forking from the delayers?
The operating assumption of 148 is that no matter what we are going to fork. So might as well do it then in a controlled manner instead of later when someone creates an invalid SegWit block. Then my only recommendation would be to also implement a boilerplate replay attack prevention just in case the SegWit delayers aren't bluffing.
Cheers,
Praxeology Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170414/9c02fbf0/attachment.html>

2023-06-07 18:00:03 UTC

- reply

📅 Original date posted:2017-04-14
📝 Original message:Gregory Maxwell,
Criticizing 148 without suggesting a specific alternative leaves the community in disarray.
I know you are emphasizing patience. But at the same time, with your patience we are allowing ourselves to get dicked for longer than necessary.
I think that core could easily develop code that could create a solid/reliable date/height based activation to allow miners to create SegWit block candidates and having nodes fully verify them. Shaolinfry is the only person Ive seen actually make such a proposal: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014049.html. His makes it so that SegWit default gets activated at the end of the BIP9 signalling timeframe instead of default leaving it non-activated.
I agree that 148 is is not ideal. Non-SegWit signaling blocks are not a Denial of Service, given that other activation methods are available. Someone just needs to code something up that is better that we can all use in a satisfying time frame. So far 148 is the most practical and reliable method I'm aware of.
If 148 causes orphaning and a fork, I don't think such really matters in the long term. The non-SegWit miners will probably just quickly give up their orphans once they realize that money users like being able to have non-mutable TX IDs. If they do create a long lasting branch... well that is good too, I'd be happy to no longer have them in our community. Good luck to them in creating a competitive money, so that we can all enjoy lower transaction fees.
SegWit has already undergone enough testing. It is time to activate it.
Cheers,
Praxeology Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170414/a6c9a6ec/attachment.html>

2023-06-07 17:59:49 UTC

- reply

📅 Original date posted:2017-04-08
📝 Original message:Eric Voskuil,
TL;DR: Electrical power is a general purpose consumer good vs PoW mining equipment is a single purpose consumer good. Hence the mining equipment rent is the barrier to entry, given if you invest in power generation capital you could use the power for a different purpose.
Each unit of electrical power (1 V* A = 1 Watt) is a finite unit of a highly non-durable consumable good.
It is true that electrical power is created by utilizing capital equipment, and the capital rent + labor of generating such power is the basis for the "Power Cost" component of the ideal miner competition profit equation.
But... electrical power is a general consumer good that can be used for many things, so investing in the capital to create it is not a very risky endeavor.
On the other hand, Bitcoin mining equipment capital is an EXTEREMELY specific kind of capital that only has exactly one use: efficiently/competitively mining a coin that has a particular PoW algorithm. Hence investing in bitcoin mining equipment is a more risky endeavor than power generation capital. Such a risk is a barrier to entry, and it is the barrier that is most considered when an entity considers mining Bitcoins.
Mature Arithmetic Logic Unit (ALU) bound PoW algorithms lacking new attacks (cryptographic definition) can only be out-dated by more efficient, more general purpose (less specific case proprietary) transistor fabrication technology.
Memory Latency bound PoW algorithms lacking new attacks (cryptographic definition) have the risk of being encumbered by all sorts of physical hardware patent inventions. This is because latency has significantly more room for such specific-to-PoW non-general purpose inventions... beyond additional patents relating to memory technology on top of ALU patents. Patents, I should point out, either cause the price of capital equipment to increase or enforce a monopoly on the capital... neither of which are desirable.
The capital maturity outlook of memory latency bound algorithms is also significantly worse than ALU bound... due to all of the expected future patent-able optimizations that could improve memory latency. Hence investing in memory latency bound mining equipment is even riskier because of the likeliness of a new patented optimization making your capital non-competitive, and given its specific nature, worthless.
This discussion brings me to a new insight. We have said that some places have "cheaper" power than others, due to the non-durable nature of electrical power. With the existence of Bitcoin, given other cost factors being less significant, Bitcoin causes all sources of power everywhere to be more equal in price at a particular time.
Now you might argue that memory latency bound PoW algorithms result in the mining capital component being the larger component than the electricity component being a good thing because: then mining would be less local to otherwise untapped (cheap) power sources. The problem with this is that as the mining capital matures (as all the optimizations are found, and the patents run out), we go strait back to the power cost being the largest component... and we had to suffer all the years of various entities unpredictably attaining a monopoly on mining in order to get there.
Please let me know if I made a mistake.
Thanks,
Praxeology Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/f2ddc5bf/attachment-0001.html>

2023-06-07 17:59:48 UTC

- reply

📅 Original date posted:2017-04-08
📝 Original message:ASICBOOST causes Bitcoin's PoW to become more memory/latency throttled instead of raw computation throttled.
There is the equation:
Power Cost + Captial Rent + Labor ~= block reward + fees
Capital Rent is a barrier to entry, and hence in desiring a more distributed system, we would like to minimize the Capital Rent portion of the equation.
Resolving memory/latency throttle requires a greater Captial Rent than raw computation throttle.
Hence (agreeing with Luke), ASICBOOST is not desirable, even if it wasn't a government enforced monopoly on mining.
Please let me know if I made a mistake.
Thanks,
Praxeology Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/57669e84/attachment.html>

2023-06-07 17:59:47 UTC

- reply

📅 Original date posted:2017-04-07
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/94f12622/attachment.html>

2023-06-07 17:59:31 UTC

- reply

📅 Original date posted:2017-04-07
📝 Original message:shaolinfry,
Not sure if you noticed my comments on your earlier orphaning proposal... but if you did you should already know that I really like this proposal... particularly since orphaning valid old blocks is completely unnecessary.
I really like how you pulled out the "lockinontimeout" variable so that this same method could be used in future softfork proposals... instead of hardcoding a special case hack for SegWit.
- it would be nice if the user could set this variable in a configuration file.
- it would be nice if the user could set the "nTimeout" in "src/chainparams.cpp" in a configuratoin file too. This could be used allow a user to expedite when a softfork would become active on his node when combined with ."lockinontimeout".
Developers such as the Core team could put more conservative values in the program, and then community members such as miners and nodes who feel more strongly about SegWit could either compile their own settings or maybe copy a popular configuration file if such was made possible.
Cheers,
Praxeology Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/5c37bfa4/attachment-0001.html>

2023-06-07 17:59:31 UTC

- reply

📅 Original date posted:2017-04-07
📝 Original message:Ryan Grant,
TLDR Unless I'm missing something, your claim that a misconfiguration would result in a stop chain is wrong because BIP9 only works on soft forks.
Does BIP9 work with hard forks? Pretty sure it is only for soft forks. If you want to make a hard fork, there is not much point in waiting for any particular miner hash power adoption rate.
With a softfork, here is the only condition for a "stopped chain":
1. User adopts more stringent rules.
2. Someone maliciously creates an invalid block as evaluated by the more stringent rules in #1, but that is valid to older nodes
3. No one ever mines a different block at the height of the block in #2, instead all of the miners only build on top of the block built at #2.
The user would have to adopt a soft fork at a time where no miner has also done the same, and where someone creates a contradictory block (which normally wouldn't happen unless someone was being malicious).
Never the less, I kind of like the idea of the user being notified when a newly activated more stringent soft fork rule caused a block to be rejected. The first time it happens, a message could come up, and then for some time after maybe it would be logged somewhere easily accessible. Such an event could be an excellent trigger to enable replay attack prevention, although maybe not automatically... unless everyone was pretty sure that a long-standing competing fork was likely to occur.
Cheers,
Praxeology Guy
-------- Original Message --------
Subject: Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in
Local Time: April 7, 2017 8:55 AM
UTC Time: April 7, 2017 1:55 PM
From: bitcoin-dev at lists.linuxfoundation.org
To: Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
The primary failure mode of a user's misconfiguration of nTimeout will
be a stopped chain.
If less-sophisticated users are offered these configuration settings
then chaintip progress failures that result from them should be
prominently displayed.
_______________________________________________
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/20170407/3fcd54e0/attachment.html>

2023-06-07 17:58:53 UTC

- reply

📅 Original date posted:2017-04-01
📝 Original message:Peter Todd,
This MMR structure looks good to me. I really like how wallets keep their MMR proof and txo index instead of requiring the entire network to maintain an index on txids w/ plain old utxo snapshots.
Re: "only left or right child of inner node be a fully spent node"... that sounds fine to me, but the software should virtually consider that the previous dissapearing leaf nodes still exist. It would instead say be a special case handled by the meta hashing function. Would save a good amount of time from unneccesary hashing. Might also do the rule: if a parent node has a single fully spent child node, its hash is equal to its other child's hash.
Below is questions about txo/utxo MMR commitments after reading: "https://petertodd.org/2016/delayed-txo-commitments".
I'm mainly concerned about the performance of recalculating all of the node hashes on old spends. But probably with a long enough delay policy, it shouldn't be an issue.
Then the issues with people keeping their MMR proofs up to date and discovering received txos before they get pruned. Sure would be nice if a wallet didn't have to keep on updating their MMR proof. Hopefully spends would refer to old txos by their MMR index.
How are you ordering MMR additions? Are you only adding old utxos to the MMR? Or every old txo? I think you are doing all old txos (mostly would be spent nodes), but why not just old utxos? Are you doing it to make MMR index = blockchain txo index, so such an index can be used in all TX inputs except for non-confirmed transactions? Potentially a tx could use a MMR.ix, allblock'stxo.ix (if we want to maintian that index), or tx.id & vout.ix depending on how old the tx is.
What is the process for removing old utxos from the utxo set, and placing them into the MMR? Are you going to keep height in the utxo db, and then iterate through the whole thing?
Are you still proposing a 1 year txo commitment delay? Do you have any data/preformance studies judging the cost of a larger utxo and longer delay vs smaller utxo and shorder delay? I would figure a longer delay would be better as long as the utxo doesn't get too big. Longer delay means less MMR maintainance.
Have you considered not making a new commitment on every block, instead maybe every 6*24 blocks or so? This could reduce the number of times the same nodes are re-hashed, while not having much impact on security.
What about re-orgs? You'd have to restore the previous leaf & inner nodes. You'd need both the txos and MMR proofs, right? It looks like you clear this info from the TXO journal when the delay duration threshold is met. I guess this info might also be stored with the block data, and could be recovered from there.
What are your current thoughts on block size weighting for MMR proofs? Just count the extra byte length that full nodes need to relay as simliar to SegWit witness data?
Cheers,
Praxeology Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170401/0059dc09/attachment.html>

2023-06-07 17:58:15 UTC

- reply

📅 Original date posted:2017-03-29
📝 Original message:Peter R said: "On that topic, are there any existing proposals detailing a canonical ordering of the UTXO set and a scheme to calculate the root hash?"
I created such here: "A Commitment-suitable UTXO set "Balances" file data structure": https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013692.html
In short it periodically makes snapshots on the state of the UTXO N blocks ago, where N = the snapshot period. UTXOs are ordered by TXID. I've also implemented it in C and tested making them.
gmaxwell says the utxo data format will change and I have other recommended changes to the chainstate database in order to make this more efficient. He pointed me to another similar solution... and suggested this would be done later after SegWit and after the UTXO data format was changed in the chainstate database.
Cheers,
Praxeology Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/7498459c/attachment.html>

2023-06-07 17:58:07 UTC

- reply

📅 Original date posted:2017-03-29
📝 Original message:I think at least the three following things have to be done before the block size can be increased by any significant amount:
1. A network protocol defined UTXO snapshot format be defined, UTXO snapshots being created automatically in a deterministic periodic and low-cost fashion. Ability to synchronize starting from such a UTXO snapshot as requested by a user.
2. SPV support from a pruned node that has the latest UTXO snapshot. Probably requires committing the UTXO snapshot hash to the block.
3. Given the above fixes the problem of needing full block chain history storage, and people are comfortable with such a security model, a good portion of the network can switch to this security model, and still satisfy our desire for the system to be sufficiently distributed. This requires lots of testing.
4. More current studies on the effect of increasing the block size on synchronizing node drop out due to other reasons such as network bandwidth, memory, and CPU usage.
Without doing the above, scheduling to increasing the block size would be wreckless.
Cheers,
Praxeology Guy
-------- Original Message --------
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Local Time: March 29, 2017 2:10 PM
UTC Time: March 29, 2017 7:10 PM
From: bitcoin-dev at lists.linuxfoundation.org
To: Martin Lízner <martin.lizner at gmail.com>, Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
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/44936f5e/attachment-0001.html>

2023-06-07 17:57:15 UTC

- reply

📅 Original date posted:2017-03-26
📝 Original message:"Activation of segwit is defined by BIP9. After 15 Nov 2016 and before 15 Nov 2017 UTC, if in a full retarget cycle at least 1916 out of 2016 blocks is signaling readiness, segwit will be activated in the retarget cycle after the next one"
Just change BIP9 and the code to say "if in a full retarget cycle at least 1 out of 2016 blocks" and call it done. Or something very similar to this that effectively does the exact same thing. :) Wasting too much time on this. 15 Nov 2017 is plenty of time to be ready for SegWit, and if a participant is not ready by then they are either unreasonably lazy, a manipulator, or manipluted, and we don't need them.
If non-upgrading miners refuse to build on segwit blocks, or build on malicious invalid segwit blocks, then so be it. We fork. We have spent enough time trying to convince people who don't think for themselves... if they are still manipulated now then its time for us to give up on helping them see the light and instead let them learn the hard way.
Cheers,
Praxeology Guy
-------- Original Message --------
Subject: Re: [bitcoin-dev] Flag day activation of segwit
Local Time: March 13, 2017 5:18 PM
UTC Time: March 13, 2017 10:18 PM
From: bitcoin-dev at lists.linuxfoundation.org
To: shaolinfry <shaolinfry at protonmail.ch>, Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
>time >= 1506816000 && time <= 1510704000 && !IsWitnessEnabled()
This has a different start time from the first post.
>if (pindex->GetMedianTimePast() >= 1538352000 && pindex->GetMedianTimePast() <= 1510704000 ...
Thanks,
--Nick
On Mon, Mar 13, 2017 at 4:36 AM, shaolinfry via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
From: luke at dashjr.org
On Sunday, March 12, 2017 3:50:27 PM shaolinfry via bitcoin-dev wrote:
> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017
> inclusive if (pindex->GetMedianTimePast() >= 1538352000 &&
> pindex->GetMedianTimePast() <= 1510704000 &&
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) {
> if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params,
> Consensus::DEPLOYMENT_SEGWIT)) != 0) {
> return state.DoS(2, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID,
> "bad-no-segwit");
> }
> }
I don't think this is actually BIP 9 compatible. Once activated, the bit loses
its meaning and should not be set. So you need to check that it hasn't locked-
in already...
I believe that is handled.
time >= 1506816000 && time <= 1510704000 && !IsWitnessEnabled()
Signalling is only required from October 1st until the BIP9 timeout, or, until segwit is activated. The bit becomes free after activation/timeout as per BIP9. Also, the default behaviour of BIP9 in Bitcoin Core is to signal through the LOCKED_IN period - it would be trivial to add a condition to not require mandatory signalling during LOCKED_IN but since miners signal by default during this period, I figured I would leave it.
I thought about 5% tolerance. but I don't think it makes sense since miners will already have plenty of warning this is coming up and the intent of the mandatory signalling period is quite clear. It also seems a bit weird to say "it's mandatory but not for 5%". If miners are required to signal, they need to signal. It also adds unnecessary complexity to an otherwise simple patch.
That said, I have no strong feelings either way on both counts, but I chose to present the simplest option first.
_______________________________________________
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/20170326/44bc5edb/attachment.html>