jl2012 at xbt.hk [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-07-22 to 2016-04-23
💬 Posted a total of 79 messages
📚 Participated in the following categories: bitcoin-dev, BIP-draft, META, Was: Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4

Profile Code

nprofile1qqstv83w0n9lf27h7jt3t330ftr6j09a6h4dqvtz08zltl5mrrws42sycpdyg

Author Public Key

npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4

Show more details

Last Notes

2023-06-07 17:50:11

- reply

📅 Original date posted:2016-04-23
📝 Original message:In the past month, there are a number of revisions in BIP141 and 143. Except
the use of BIP9 for deployment, none of these edits was a result of a change
of consensus behavior of the reference implementation. Instead, the text
were edited for clarifications or corrections to match the reference
implementation. The consensus specification (except the use of BIP9) has not
changed since early Feb 2016, if not earlier.
History of BIP141 and revision proposals
https://github.com/bitcoin/bips/commits/master/bip-0141.mediawiki
https://github.com/bitcoin/bips/pull/365
https://github.com/bitcoin/bips/pull/376
History of BIP143
https://github.com/bitcoin/bips/commits/master/bip-0143.mediawiki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160423/dedfdc10/attachment.html>

2023-06-07 17:50:08

- reply

📅 Original date posted:2016-04-18
📝 Original message:I just realize that if we have OP_CAT, OP_CHECKPRIVATEKEYVERIFY (aka OP_CHECKPRIVPUBPAIR) is not needed (and is probably better for privacy)
Bob has the prikey-x for pubkey-x. Alice and Bob will agree to a random secret nonce, k. They calculate r, in the same way as signing a transaction.
The script is:
SIZE <r-length + 1> ADD <0x30> SWAP CAT <0x02|r-length|r> CAT SWAP CAT <pubkey-x> CECHKSIGVERIFY <Bob pubkey hash> CHECKSIG
To redeem, Bob has to provide:
<Bob sig> <0x02|s-length|s|sighashtype>
With k, s and sighash, Alice (and only Alice) can recover the prikey-x with the well-known k-reuse exploit
( https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm )
The script will be much cleaner if we remove the DER encoding in the next generation of CHECKSIG
The benefit is prikey-x remains a secret among Alice and Bob. If they don’t mind exposing the prikey-x, they could use r = x coordinate of pubkey-x, which means k = prikey-x (https://bitcointalk.org/index.php?topic=291092.0) This would reduce the witness size a little bit as a DUP may be used
From: bitcoin-dev-bounces at lists.linuxfoundation.org [mailto:bitcoin-dev-bounces at lists.linuxfoundation.org] On Behalf Of Tier Nolan via bitcoin-dev
Sent: Monday, 29 February, 2016 19:53
Cc: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP CPRKV: Check private key verify
On Mon, Feb 29, 2016 at 10:58 AM, Mats Jerratsch <matsjj at gmail.com <mailto:matsjj at gmail.com> > wrote:
This is actually very useful for LN too, see relevant discussion here
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011827.html
Is there much demand for trying to code up a patch to the reference client? I did a basic one, but it would need tests etc. added.
I think that segregated witness is going to be using up any potential soft-fork slot for the time being anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160419/232ba8d8/attachment.html>

2023-06-07 17:50:04

- reply

📅 Original date posted:2016-04-01
📝 Original message:BIP draft: https://github.com/jl2012/bips/blob/mast/bip-mast.mediawiki
Reference implementation:
https://github.com/jl2012/bitcoin/commit/f335cab76eb95d4f7754a718df201216a49
75d8c
This BIP defines a new witness program type that uses a Merkle tree to
encode mutually exclusive branches in a script. This enables complicated
redemption conditions that are currently not possible, improves privacy by
hiding unexecuted scripts, and allows inclusion of non-consensus enforced
data with very low or no additional cost.
The reference implementation is a small and simple patch on top of BIP141
(segwit), however, I have no intention to push this before segwit is
enforced. Instead, I hope the MAST will come with many new op codes,
particularly Schnorr signature.

2023-06-07 17:49:54

- reply

📅 Original date posted:2016-03-22
📝 Original message:Do you mean BIP141?
Your example is an error by BIP141:
1*4 + 79999*1 = 80003 > 80000
From: bitcoin-dev-bounces at lists.linuxfoundation.org [mailto:bitcoin-dev-bounces at lists.linuxfoundation.org] On Behalf Of Sergio Demian Lerner via bitcoin-dev
Sent: Monday, 21 March, 2016 10:51
To: bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Subject: [bitcoin-dev] BIP147 minor error
The BIP147 reads:
Sigop cost is defined. The cost of a sigop in traditional script is 4, while the cost of a sigop in witness program is 1.
The new rule is total sigop cost ≤ 80,000.
But the code implements:
if (nSigOps + (nWitSigOps + 3) / 4 > MAX_BLOCK_SIGOPS)
... error....
Which is not the same.
For example:
nSigOps = 1
nWitSigOps =79999
Is not an error by BIP definition but it's an error by the implemented code.
Regards, Sergio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160322/5be2f7b5/attachment.html>

2023-06-07 17:49:08

- reply

📅 Original date posted:2016-02-12
📝 Original message:Seems it could be done without any new opcode:
Bob is trading b Bitcoins for a altcoins.
1. Bob Pays D Bitcoins to
IF
<now+2days> CLTV DROP <Alice PK> CHECKSIG
ELSE
HASH160 <hash secret B> EQUALVERIFY <Bob PK> CHECKSIG
ENDIF
2. Alice pays a altcoins to
IF
HASH160 <hash secret B> EQUALVERIFY <Alice PK> CHECKSIG
ELSE
HASH160 <hash secret A> EQUALVERIFY <Bob PK> CHECKSIG
ENDIF
3. Bob pays b Bitcoins to
IF
<now+1days> CLTV DROP <Bob PK> CHECKSIG
ELSE
HASH160 <hash secret A> EQUALVERIFY <Alice PK> CHECKSIG
ENDIF
4. Alice claims output from step 3 and reveals secret A
5. Bob claims output from step 2
6. Bob claims output from step 1 and reveals secret B
From: bitcoin-dev-bounces at lists.linuxfoundation.org [mailto:bitcoin-dev-bounces at lists.linuxfoundation.org] On Behalf Of Tier Nolan via bitcoin-dev
Sent: Friday, 12 February, 2016 04:05
To: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Subject: [bitcoin-dev] BIP CPRKV: Check private key verify
There was some discussion on the bitcointalk forums about using CLTV for cross chain transfers.
Many altcoins don't support CLTV, so transfers to those coins cannot be made secure.
I created a protocol. It uses on cut and choose to allow commitments to publish private keys, but it is clunky and not entirely secure.
I created a BIP draft for an opcode which would allow outputs to be locked unless a private key was published that matches a given public key.
https://github.com/TierNolan/bips/blob/cpkv/bip-cprkv.mediawiki
<https://www.avast.com/sig-email>
This email has been sent from a virus-free computer protected by Avast.
<https://www.avast.com/sig-email> www.avast.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160212/055b7677/attachment-0001.html>

2023-06-07 17:49:03

- reply

📅 Original date posted:2016-02-10
📝 Original message:I am actually suggesting 1 hardfork, not 2. However, different rules are
activated at different time to enhance safety and reduce disruption. The
advantage is people are required to upgrade once, not twice. Any clients
designed for stage 2 should also be ready for stage 3.
-----Original Message-----
From: Matt Corallo [mailto:lf-lists at mattcorallo.com]
Sent: Wednesday, 10 February, 2016 06:15
To: jl2012 at xbt.hk; bitcoin-dev at lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A roadmap to a better header format and bigger
block size
As for your stages idea, I generally like the idea (and mentioned it may be
a good idea in my proposal), but am worried about scheduling two hard-forks
at once....Lets do our first hard-fork first with the things we think we
will need anytime in the visible future that we have reasonable designs for
now, and talk about a second one after we've seen what did/didnt blow up
with the first one.
Anyway, this generally seems reasonable - it looks like most of this matches
up with what I said more specifically in my mail yesterday, with the
addition of timewarp fixes, which we should probably add, and Luke's header
changes, which I need to spend some more time thinking about.
Matt

2023-06-07 17:49:02

- reply

📅 Original date posted:2016-02-09
📝 Original message:I would like to present a 2-3 year roadmap to a better header format and
bigger block size
Objectives:
1. Multistage rule changes to make sure everyone will have enough time to
upgrade
2. Make mining easier, without breaking existing mining hardware and the
Stratum protocol
3. Make future hardfork less disruptive (with Luke-Jr's proposal)
Stage 1 is Segregated Witness (BIP141), which will not break any existing
full or light nodes. This may happen in Q2-Q3 2016
Stage 2 is fixes that will break existing full nodes, but not light nodes:
a. Increase the MAX_BLOCK_SIZE (the exact value is not suggested in this
roadmap), potentially change the witness discount
b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts
c. (optional) Move segwit's commitments to the header Merkle tree. This is
optional at this stage as it will be fixed in Stage 3 anyway
This may happen in Q1-Q2 2017
Stage 3 is fixes that will break all existing full nodes and light nodes:
a. Full nodes upgraded to Stage 2 will not need to upgrade again, as the
rules and activation logic should be included already
b. Change the header format to Luke-Jr's proposal, and move all commitments
(tx, witness, etc) to the new structure. All existing mining hardware with
Stratum protocol should work.
c. Reclaiming unused bits in header for mining. All existing mining chips
should still work. Newly designed chips should be ready for the new rule.
d. Fix the time warp attack
This may happen in 2018 to 2019
Pros:
a. Light nodes (usually less tech-savvy users) will have longer time to
upgrade
b. The stage 2 is opt-in for full nodes.
c. The stage 3 is opt-in for light nodes.
Cons:
a. The stage 2 is not opt-in for light nodes. They will blindly follow the
longest chain which they might actually don't want to
b. Non-upgraded full nodes will follow the old chain at Stage 2, which is
likely to have lower value.
c. Non-upgraded light nodes will follow the old chain at Stage 3, which is
likely to have lower value. (However, this is not a concern as no one should
be mining on the old chain at that time)
-------------------------------
An alternative roadmap would be:
Stage 2 is fixes that will break existing full nodes and light nodes.
However, they will not follow the minority chain
a. Increase the MAX_BLOCK_SIZE, potentially change the witness discount
b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts
c. Change the header format to Luke-Jr's proposal, and move all commitments
(tx, witness, etc) to the new structure.
This may happen in mid 2017 or later
Stage 3 is fixes that will break all existing full nodes and light nodes.
a. Full nodes and light nodes upgraded to Stage 2 will not need to upgrade
again, as the rules and activation logic should be included already
b. Reclaiming unused bits in header for mining. All existing mining chips
should still work.
c. Fix the time warp attack
This may happen in 2018 to 2019
Pros:
a. The stage 2 and 3 are opt-in for everyone
b. Even failing to upgrade, full nodes and light nodes won't follow the
minority chain at stage 2
Cons:
a. Non-upgraded full/light nodes will follow the old chain at Stage 3, which
is likely to have lower value. (However, this is not a concern as no one
should be mining on the old chain at that time)
b. It takes longer to implement stage 2 to give enough time for light node
users to upgrade
-------------------------------
In terms of safety, the second proposal is better. In terms of disruption,
the first proposal is less disruptive
I would also like to emphasize that it is miners' responsibility, not the
devs', to confirm that the supermajority of the community accept changes in
Stage 2 and 3.
Reference:
Matt Corallo's proposal:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403.
html
Luke-Jr's proposal:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012377.
html

2023-06-07 17:48:54

- reply

📅 Original date posted:2016-02-08
📝 Original message:Thanks for this proposal. Just some quick response:
1. The segwit hardfork (BIP HF) could be deployed with BIP141 (segwit
softfork). BIP141 doesn't need grace period. BIP HF will have around 1 year
of grace period.
2. Threshold is 95%. Using 4 versoin bits: a) BIP 141; b) BIP HF; c) BIP 141
if BIP HF has already got 95%; d) BIP HF if BIP141 has already got 95%.
Voting a and c (or b and d) at the same time is invalid. BIP 141 is
activated if a>95% or (a+c>95% and b+d>95%). BIP HF is activated if b>95% or
(a+c>95% and b+d>95%).
3. Fix time warp attack: this may break some SPV implementation
4. Limiting non-segwit inputs may make some existing signed tx invalid. My
proposal is: a) count the number of non-segwit sigop in a tx, including
those in unexecuted branch (sigop); b) measure the tx size without scripgSig
(size); c) a new rule is SUM(sigop*size) < some_value . This allows
calculation without actually running the script.
-----Original Message-----
From: bitcoin-dev-bounces at lists.linuxfoundation.org
[mailto:bitcoin-dev-bounces at lists.linuxfoundation.org] On Behalf Of Matt
Corallo via bitcoin-dev
Sent: Tuesday, 9 February, 2016 03:27
To: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Subject: [bitcoin-dev] On Hardforks in the Context of SegWit
Hi all,
I believe we, today, have a unique opportunity to begin to close the book on
the short-term scaling debate.
First a little background. The scaling debate that has been gripping the
Bitcoin community for the past half year has taken an interesting turn in
2016. Until recently, there have been two distinct camps - one proposing a
significant change to the consensus-enforced block size limit to allow for
more on-blockchain transactions and the other opposing such a change,
suggesting instead that scaling be obtained by adding more flexible systems
on top of the blockchain. At this point, however, the entire Bitcoin
community seems to have unified around a single vision - roughly 2MB of
transactions per block, whether via Segregated Witness or via a hard fork,
is something that can be both technically supported and which adds more
headroom before second-layer technologies must be in place. Additionally, it
seems that the vast majority of the community agrees that segregated witness
should be implemented in the near future and that hard forks will be a
necessity at some point, and I don't believe it should be controversial
that, as we have never done a hard fork before, gaining experience by
working towards a hard fork now is a good idea.
With the apparent agreement in the community, it is incredibly disheartening
that there is still so much strife, creating a toxic environment in which
developers are not able to work, companies are worried about their future
ability to easily move Bitcoins, and investors are losing confidence. The
way I see it, this broad unification of visions across all parts of the
community places the burden of selecting the most technically-sound way to
achieve that vision squarely on the development community.
Sadly, the strife is furthered by the huge risks involved in a hard fork in
the presence of strife, creating a toxic cycle which prevents a safe hard
fork. While there has been talk of doing an "emergency hardfork" as an
option, and while I do believe this is possible, it is not something that
will be easy, especially for something as controversial as rising fees.
Given that we have never done a hard fork before, being very careful and
deliberate in doing so is critical, and the technical community working
together to plan for all of the things that might go wrong is key to not
destroying significant value.
As such, I'd like to ask everyone involved to take this opportunity to
"reset", forgive past aggressions, and return the technical debates to
technical forums (ie here, IRC, etc).
As what a hard fork should look like in the context of segwit has never
(!) been discussed in any serious sense, I'd like to kick off such a
discussion with a (somewhat) specific proposal.
First some design notes:
* I think a key design feature should be taking this opportunity to add
small increases in decentralization pressure, where possible.
* Due to the several non-linear validation time issues in transaction
validation which are fixed by SegWit's signature-hashing changes, I strongly
believe any hard fork proposal which changes the block size should rely on
SegWit's existence.
* As with any hard fork proposal, its easy to end up pulling in hundreds of
small fixes for any number of protocol annoyances. In order to avoid doing
this, we should try hard to stick with a few simple changes.
Here is a proposed outline (to activate only after SegWit and with the
currently-proposed version of SegWit):
1) The segregated witness discount is changed from 75% to 50%. The block
size limit (ie transactions + witness/2) is set to 1.5MB. This gives a
maximum block size of 3MB and a "network-upgraded" block size of roughly
2.1MB. This still significantly discounts script data which is kept out of
the UTXO set, while keeping the maximum-sized block limited.
2) In order to prevent significant blowups in the cost to validate
pessimistic blocks, we must place additional limits on the size of many
non-segwit transactions. scriptPubKeys are now limited to 100 bytes in size
and may not contain OP_CODESEPARATOR, scriptSigs must be push-only (ie no
non-push opcodes), and transactions are only allowed to contain up to 20
non-segwit inputs. Together these limits limit total-bytes-hashed in block
validation to under 200MB without any possibility of making existing outputs
unspendable and without adding additional per-block limits which make
transaction-selection-for-mining difficult in the face of attacks or
non-standard transactions. Though 200MB of hashing (roughly 2 seconds of
hash-time on my high-end
workstation) is pretty strongly centralizing, limiting transactions to fewer
than 20 inputs seems arbitrarily low.
Along similar lines, we may wish to switch MAX_BLOCK_SIGOPS from
1-per-50-bytes across the entire block to a per-transaction limit which is
slightly looser (though not too much looser - even with libsecp256k1
1-per-50-bytes represents 2 seconds of single-threaded validation in just
sigops on my high-end workstation).
3) Move SegWit's generic commitments from an OP_RETURN output to a second
branch in the merkle tree. Depending on the timeline this may be something
to skip - once there is tooling for dealing with the extra OP_RETURN output
as a generic commitment, the small efficiency gain for applications checking
the witness of only one transaction or checking a non-segwit commitment may
not be worth it.
4) Instead of requiring the first four bytes of the previous block hash
field be 0s, we allow them to contain any value. This allows Bitcoin mining
hardware to reduce the required logic, making it easier to produce
competitive hardware [1].
I'll deliberately leave discussion of activation method out of this
proposal. Both jl2012 and Luke-Jr recently begun some discussions about
methods for activation on this list, and I'd love to see those continue.
If folks think a hard fork should go ahead without SPV clients having a say,
we could table #4, or activate #4 a year or two after 1-3 activate.
[1] Simpler here may not be entirely true. There is potential for
optimization if you brute force the SHA256 midstate, but if nothing else,
this will prevent there being a strong incentive to use the version field as
nonce space. This may need more investigation, as we may wish to just set
the minimum difficulty higher so that we can add more than 4 nonce-bytes.
Obviously we cannot reasonably move forward with a hard fork as long as the
contention in the community continues. Still, I'm confident continuing to
work towards SegWit as a 2MB-ish soft-fork in the short term with some plans
on what a hard fork should look like if we can form broad consensus can go a
long way to resolving much of the contention we've seen.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:48:52

- reply

📅 Original date posted:2016-02-07
📝 Original message:This looks very interesting. The first time implementing it might be more
painful but that will make subsequent hardforks a lot easier.
Do you think it's good to include the median timestamp of the past 11 blocks
after the block height in coinbase? That would make it easier to use it as
activation threshold of consensus rule changes.
For the witness commitment, it will also be treated as a merge mined
commitment?
It is also good to emphasize that it is the responsibility of miners, not
devs, to ensure that the hardfork is accepted by the supermajority of the
economy.
-----Original Message-----
From: bitcoin-dev-bounces at lists.linuxfoundation.org
[mailto:bitcoin-dev-bounces at lists.linuxfoundation.org] On Behalf Of Luke
Dashjr via bitcoin-dev
Sent: Sunday, 7 February, 2016 17:53
To: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Subject: [bitcoin-dev] Pre-BIP Growth Soft-hardfork
Here's a draft BIP I wrote almost a year ago. I'm going to look into
revising and completing it soon, and would welcome any suggestions for doing
so.
This hardfork BIP aims to accomplish a few important things:
- Finally deploying proper merge-mining as Satoshi suggested before he left.
- Expanding the nonce space miners can scan in-chip, avoiding expensive
calculations on the host controller as blocks get larger.
- Provide a way to safely deploy hardforks without risking leaving old nodes
vulnerable to attack.
https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki
Luke
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:48:44

- reply

📅 Original date posted:2016-02-07
📝 Original message:You are making a very naïve assumption that miners are just looking for
profit for the next second. Instead, they would try to optimize their short
term and long term ROI. It is also well known that some miners would mine at
a loss, even not for ideological reasons, if they believe that their action
is beneficial to the network and will provide long term ROI. It happened
after the last halving in 2012. Without any immediate price appreciation,
the hashing rate decreased by only less than 10%
http://bitcoin.sipa.be/speed-ever.png
From: bitcoin-dev-bounces at lists.linuxfoundation.org
[mailto:bitcoin-dev-bounces at lists.linuxfoundation.org] On Behalf Of Jonathan
Toomim via bitcoin-dev
Sent: Monday, 8 February, 2016 01:11
To: Anthony Towns <aj at erisian.com.au>
Cc: bitcoin-dev at lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
megabytes
On Feb 7, 2016, at 7:19 AM, Anthony Towns via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org
<mailto:bitcoin-dev at lists.linuxfoundation.org> > wrote:
The stated reasoning for 75% versus 95% is "because it gives "veto power"
to a single big solo miner or mining pool". But if a 20% miner wants to
"veto" the upgrade, with a 75% threshold, they could instead simply use
their hashpower to vote for an upgrade, but then not mine anything on
the new chain. At that point there'd be as little as 55% mining the new
2MB chain with 45% of hashpower remaining on the old chain. That'd be 18
minute blocks versus 22 minute blocks, which doesn't seem like much of
a difference in practice, and at that point hashpower could plausibly
end up switching almost entirely back to the original consensus rules
prior to the grace period ending.
Keep in mind that within a single difficulty adjustment period, the
difficulty of mining a block on either chain will be identical. Even if the
value of a 1MB branch coin is $100 and the hashrate on the 1 MB branch is
100 PH/s, and the value of a 2 MB branch coin is $101 and the hashrate on
the 2 MB branch is 1000 PH/s, the rational thing for a miner to do (for the
first adjustment period) is to mine on the 2 MB branch, because the miner
would earn 1% more on that branch.
So you're assuming that 25% of the hashrate chooses to remain on the
minority version during the grace period, and that 20% chooses to switch
back to the minority side. The fork happens. One branch has 1 MB blocks
every 22 minutes, and the other branch has 2 MB blocks every 18 minutes. The
first branch cannot handle the pre-fork transaction volume, as it only has
45% of the capacity that it had pre-fork. The second one can, as it has 111%
of the pre-fork capacity. This makes the 1 MB branch much less usable than
the 2 MB branch, which in turn causes the market value of newly minted coins
on that branch to fall, which in turn causes miners to switch to the more
profitable 2MB branch. This exacerbates the usability difference, which
exacerbates the price difference, etc. Having two competing chains with
equal hashrate using the same PoW function and nearly equal features is not
a stable state. Positive feedback loops exist to make the vast majority of
the users and the hashrate join one side.
Basically, any miners who stick to the minority branch are going to lose a
lot of money.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160208/4325182f/attachment.html>

2023-06-07 17:48:32

- reply

📅 Original date posted:2016-02-07
📝 Original message:From: Gavin Andresen [mailto:gavinandresen at gmail.com]
Sent: Friday, 5 February, 2016 06:16
To: Gregory Maxwell <greg at xiph.org>
Cc: jl2012 <jl2012 at xbt.hk>; Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork bit BIP
>It is always possible I'm being dense, but I still don't understand how this proposal makes a chain-forking situation better for anybody.
>If there are SPV clients that don't pay attention to versions in block headers, then setting the block version negative doesn't directly help them, they will ignore it in any case.
It is unfortunate SPV clients are not following that. However, they SHOULD follow that. It becomes a self fulfilling prophecy if we decide not to do that if SPV are not following that.
>If the worry is full nodes that are not upgraded, then a block with a negative version number will, indeed, fork them off the the chain, in exactly the same way a block with new hard-forking consensus rules would. And with the same consequences (if there is any hashpower not paying attention, then a worthless minority chain might continue on with the old rules).
It will distinguish between a planned hardfork and an accidental hardfork, and full nodes may react differently. Particularly, a planned unknown hardfork is a strong indication that the original chain has become economic minority and the non-upgraded full node should stop accepting incoming tx immediately.
>If the worry is not-upgraded SPV clients connecting to the old, not-upgraded full nodes, I don't see how this proposed BIP helps.
Same for not-upgraded full nodes following not-upgraded full nodes. Anyway, the header with enough PoW should still be propagated.
>I think a much better idea than this proposed BIP would be a BIP that recommends that SPV clients to pay attention to block version numbers in the headers that they download, and warn if there is a soft OR hard fork that they don't know about.
Normal version number only suggests softforks, which is usually not a concern for SPV clients. An unknown hardfork is a completely different story as the values of the forks are completely unknown.
>It is also a very good idea for SPV clients to pay attention to timestamps in the block headers that the receive, and to warn if blocks were generated either much slower or faster than statistically likely. Doing that (as Bitcoin Core already does) will mitigate Sybil attacks in general.
Yes, they should.
--
--
Gavin Andresen

2023-06-07 17:46:14

- reply

📅 Original date posted:2015-12-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Mon, Dec 14, 2015 at 12:14 AM, Danny Thorpe <danny.thorpe at gmail.com>
wrote:
> What is the current behavior / cost that this proposal is trying to
> avoid? Are ancient utxos required to be kept in memory always in a
> fully validating node, or can ancient utxos get pushed out of memory
> like a normal LRU caching db?
I don't see why it must be kept in memory. But storage is still a
problem. With the 8 year limit and a fixed max block size, it indirectly
sets an upper limit for UTXO set.
Chris Priest via bitcoin-dev :
> This isn't going to kill bitcoin, but it won't make it any better.
Do you believe that thousands of volunteer full nodes are obliged to
store an UTXO record, just because one paid US$0.01 to an anonymous
miner 100 years ago? It sounds insanely cheap, isn't it? My proposal (or
similar proposal by Peter Todd) is to solve this problem. Many
commercial banks have a dormant threshold less than 8 years so I believe
it is a balanced choice.
Back to the topic, I would like to further elaborate my proposal.
We have 3 types of full nodes:
Archive nodes: full nodes that store the whole blockchain
Full UTXO nodes: full nodes that fully store the latest UTXO state, but
not the raw blockchain
Lite UTXO nodes: full nodes that store only UTXO created in that past
420000 blocks
Currently, if one holds nothing but a private key, he must consult
either an archive node or a full UTXO node for the latest UTXO state to
spend his coin. We currently do not have any lite UTXO node, and such
node would not work properly beyond block 420000.
With the softfork I described in my original post, if the UTXO is
created within the last 420000 blocks, the key holder may consult any
type of full node, including a lite UTXO node, to create the
transaction.
If the UTXO has been confirmed by more than 420000 blocks, a lite UTXO
node obviously can't provide the necessary information to spend the
coin. However, not even a full UTXO node may do so. A full UTXO node
could tell the position of the UTXO in the blockchain, but can't provide
all the information required by my specification. Only an archive node
may do so.
What extra information is needed?
(1) If your UTXO was generated in block Y, you first need to know the
TXO state (spent / unspent) of all outputs in block Y at block (Y +
420000). Only UTXOs at that time are relevant.
(2) You also need to know if there was any spending of any block Y UTXOs
after block (Y + 420000).
It is not possible to construct the membership prove I require without
these information. It is designed this way, so that lite UTXO nodes
won't need to store any dormant UTXO records: not even the hash of
individual dormant UTXO records. If the blockchain grows to insanely
big, it may take days or weeks to retrieve to records. However, I don't
think this is relevant as one has already left his coins dormant for >8
years. Actually, you don't even need the full blockchain. For (1), all
you need is the 420000 blocks from Y to Y+420000 minus any witness data,
as you don't need to do any validation. For (2), you just need the
coinbase of Y+420001 to present, where any spending would have been
committed, and retrieve the full block only if a spending is found.
So the Bitcoin Bank (miners) is not going to shred your record and
confiscate your money. Instead, the Bank throws your record to the
garage (raw blockchain). You can search for your record by yourself, or
employ someone (archive node) to search it for you. In any case it
incurs costs. But as thousands of bankers have kept your record on their
limited desk space for 8 years for free (though one of them might
receive a fraction of a penny from you), you shouldn't complain with any
moral, technical, or legal reason. And no matter what users say, I
believe something like this will happen when miners and full nodes can't
handle the UTXO set.
I'd like to see more efficient proposals that archive the same goals.
p.s. there were some typos in my original. The second sentence of the
second paragraph should be read as "For every block X+420000, it will
commit to a hash for all UTXOs generated in block X."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQGcBAEBCAAGBQJWbbR2AAoJEO6eVSA0viTScEoL/RPlsxr0A5wTtgdi+9i4AFlV
Sw/He89+YPGe5VCG74YNAPLEUF1/rICzUJ4DulvNTOo/5xtmkv5ok4bD7v1JZnH3
DE2PExMQYs2X4Qm6mkcwi8IWlMR2U5j5ebUq21Kj4AqVFj9UcQmYGhPehB2f+cM9
Wki/TDwNj5fV8AZ4uR9pPgaf+bvVQQ9BOOLiIMiTbphNCx1hfGfYcsqmXlCbGk9A
PatGR88aQTxpa7PhbCZwwf76cKuOaYYZeHr9jRR9RL5rZVXgE1SI/niBytJhXaP8
lwYtk4Bpz0IGd23v1dArNQQoOp5Xycbeq1l1qyv/qtxju65No+dhqiEcFBZVI1AS
VcndMQ+yvNuxVgib2Ifh9YjXelWAqqLzzoVcz2RxXh6HJ0tVKxBokwdAcsclZb93
zQ1JhDR4vBpLquytZA8lDIxJraNCdB/KEAOAey6ljP3zL7fBLBp1oZw4DDDtFy8V
EMjrOSVnjyuyfey2YXsGnnHuQS0mpwmSroV2400uGQ==
=2xRy
-----END PGP SIGNATURE-----

2023-06-07 17:46:12

- reply

📅 Original date posted:2015-12-12
📝 Original message:It is a common practice in commercial banks that a dormant account might
be confiscated. Confiscating or deleting dormant UTXOs might be too
controversial, but allowing the UTXOs set growing without any limit
might not be a sustainable option. People lose their private keys.
People do stupid things like sending bitcoin to 1BitcoinEater. We
shouldn’t be obliged to store everything permanently. This is my
proposal:
Dormant UTXOs are those UTXOs with 420000 confirmations. In every block
X after 420000, it will commit to a hash for all UTXOs generated in
block X-420000. The UTXOs are first serialized into the form:
txid|index|value|scriptPubKey, then a sorted Merkle hash is calculated.
After some confirmations, nodes may safely delete the UTXO records of
block X permanently.
If a user is trying to redeem a dormant UTXO, in addition the signature,
they have to provide the scriptPubKey, height (X), and UTXO value as
part of the witness. They also need to provide the Merkle path to the
dormant UTXO commitment.
To confirm this tx, the miner will calculate a new Merkle hash for the
block X, with the hash of the spent UTXO replaced by 1, and commit the
hash to the current block. All full nodes will keep an index of latest
dormant UTXO commitments so double spending is not possible. (a
"meta-UTXO set")
If all dormant UTXOs under a Merkle branch are spent, hash of the branch
will become 1. If all dormant UTXOs in a block are spent, the record for
this block could be forgotten. Full nodes do not need to remember which
particular UTXO is spent or not, since any person trying to redeem a
dormant UTXO has to provide such information.
It becomes the responsibility of dormant coin holders to scan the
blockchain for the current status of the UTXO commitment for their coin.
They may also need to pay extra fee for the increased tx size.
This is a softfork if there is no hash collision but this is a
fundamental assumption in Bitcoin anyway. The proposal also works
without segregated witness, just by replacing "witness" with "scriptSig"

2023-06-07 17:46:09

- reply

📅 Original date posted:2015-12-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Pieter Wuille 2015-12-13 13:07 :
> The use of a NOP opcode to indicate a witness script was something I
> considered at first too, but it's not really needed. You wouldn't be
> able to use that opcode in any place a normal opcode could occur, as
> it needs to be able to inspect the full scriptSig (rather than just
> its resulting stack) anyway. So both in practice and conceptually it
> is only really working as a template that gets assigned a special
> meaning (like P2SH did). We don't need an opcode for that, and instead
> we could say that any scriptPubKey (or redeemscript) that consists of
> a single push is a witness program.
>
>> 5. The most significant byte of serialized script is the version byte,
>> an
>> unsigned number
>> 6. If the version byte is 0x00, the script must fail
>
> What is that good for?
Just to make sure a script like OP_0 OP_SEGWIT will fail.
Anyway, your design may be better so forget it
>> 7. If the version byte is 0x02 to 0xff, the rest of the serialized
>> script is
>> ignored and the output is spendable with any form of witness (even if
>> the
>> witness contains something invalid in the current script system, e.g.
>> OP_RETURN)
>
> Do you mean the scriptPubKey itself, or the script that follows after
> the version byte?
> * The scriptPubKey itself: that's in contradiction with your rule 4,
> as segwit scripts are by definition only a push (+ opcode), so they
> can't be an OP_RETURN.
> * The script after the version byte: agree - though it doesn't
> actually need to be a script at all even (see further).
I am not referring to the serialized script, but the witness. Basically,
it doesn't care what the content look like.
> It is useful however to allow segwit inside P2SH
Agree
> So let me summarize by giving an equivalent to your list above,
> reflecting how my current prototype works:
> A) A scriptPubKey or P2SH redeemscript that consists of a single push
> of 2 to 41 bytes gets a new special meaning, and the byte vector
> pushed by it is called the witness program.
Why 41 bytes? Do you expect all witness program to be P2SH-like?
> The program
> must not fail and result in a single TRUE on the stack, and nothing
> else (to prevent stuffing the witness with pointless data during relay
> of transactions).
Could we just implement this as standardness rule? It is always possible
to stuff the scriptSig with pointless data so I don't think it's a new
attack vector. What if we want to include the height and tx index of
the input for compact fraud proof? Such fraud proof should not be an
opt-in function and not be dependent on the version byte
For the same reason, we should also allow traditional tx to have data
in the witness field, for any potential softfork upgrade
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQGcBAEBCAAGBQJWbbugAAoJEO6eVSA0viTSD8oMAKFvd/+KZgH13tErEA+iXzF5
pwT4/eoQWSTvxIDVrFN+9wV79ogO4/aiCDEdmNF2IZD3QqmhKl7iOPw2SEseRTbe
e1r5z67yuudXyEQocZvy5+NOUp3N978b8weuRsHWG1HXgxTRmgZTrEeNtbEUs0X2
n5l6e0scnZAu70svBXr8X9HnOm2P/QLxtAqyNW19caCi+Dg/4Curx48tXQ/I9IxT
SYFVzB++FIoua49Cf1RJN+dUfywg67wT5l9NX4uWAX0qNB+p6BPP8df/72G/u564
NIaJs3IFiUaNktXz9aDM4s7pSzR6PlCK6LFKjE52sBY5uREHGU4PnfX9YqtwiEXA
Hr3YoFiepxAwl6icJi3wHKa6i0NGvj1fR1h6xuJ7ulzNv5mwuzXPOgvTDK4wpejl
ee8wsQZwmzchAfgyfPsgSaPh/jjBwm2S+WDMbL4HDmnWqVDl8dG3I/b3XP0aegY9
4RxPhLOA1qToNDGhnm+JNqT60OKgatpDN/4bRgRscA==
=4B1D
-----END PGP SIGNATURE-----

2023-06-07 17:46:08

- reply

📅 Original date posted:2015-12-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I'm trying to list the minimal consensus rule changes needed for segwit
softfork. The list does not cover the changes in non-consensus critical
behaviors, such as relay of witness data.
1. OP_NOP4 is renamed as OP_SEGWIT
2. A script with OP_SEGWIT must fail if the scriptSig is not completely
empty
3. If OP_SEGWIT is used in the scriptPubKey, it must be the only and the
last OP code in the scriptPubKey, or the script must fail
4. The OP_SEGWIT must be preceded by exactly one data push (the
"serialized script") with at least one byte, or the script must fail
5. The most significant byte of serialized script is the version byte,
an unsigned number
6. If the version byte is 0x00, the script must fail
7. If the version byte is 0x02 to 0xff, the rest of the serialized
script is ignored and the output is spendable with any form of witness
(even if the witness contains something invalid in the current script
system, e.g. OP_RETURN)
8. If the version byte is 0x01,
8a. rest of the serialized script is deserialized, and be interpreted as
the scriptPubKey.
8b. the witness is interpreted as the scriptSig.
8c. the script runs with existing rules (including P2SH)
9. If the script fails when OP_SEGWIT is interpreted as a NOP, the
script must fail. However, this is guaranteed by the rules 2, 3, 4, 6 so
no additional check is needed.
10. The calculation of Merkle root in the block header remains unchanged
11. The witness commitment is placed somewhere in the block, either in
coinbase or an OP_RETURN output in a specific tx
Format of the witness commitment:
The witness commitment could be as simple as a hash tree of all witness
in a block. However, this is bad for further development of sum tree for
compact SPV fraud proof as we have to maintain one more tree in the
future. Even if we are not going to implement any sum checking in first
version of segwit, it's better to make it easier for future softforks.
(credit: gmaxwell)
12. The block should indicate how many sum criteria there are by
committing the number following the witness commitment
13. The witness commitment is a hash-sum tree with the number of sum
criteria committed in rule 12
14. Each sum criterion is a fixed 8 byte signed number (Negative value
is allowed for use like counting delta-UTXO. 8 bytes is needed for fee
commitment. Multiple smaller criteria may share a 8 byte slot, as long
as they do not allow negative value)
15. Nodes will ignore the sum criteria that they do not understand, as
long as the sum is correctly calculated
Size limit:
16. We need to determine the size limit of witness
17. We also need to have an upper limit for the number of sum criteria,
or a malicious miner may find a block with many unknown sum criteria and
feed unlimited amount of garbage to other nodes.
All other functions I mentioned in my wish list could be softforked
later to this system
To mitigate the risk described in rule 17, we may ask miners to vote for
an increase (but not decrease) in the number of sum criteria. Initially
there should be 0 sum criteria. If we would like to introduce a new
criteria, miners will support the proposal by setting the number of sum
criteria as 1. However, until 95% of miners support the increase, all
values of the extra sum criteria must be 0. Therefore, even a malicious
miner may declare any amount of sum criteria, those criteria unknown to
the network must be 0, and no extra data is needed to construct the
block. This voting mechanism could be a softfork over rule 12 and 13,
and is not necessary in the initial segwit deployment.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQGcBAEBCAAGBQJWbY0jAAoJEO6eVSA0viTSU1oMAJIrYWerwk84poZBL/ezEsIp
9fCLnFZ4lyO2ijAm5UmwLXGijY03kqp29b0zmyIWV2WuoeW2lN64tLHQRilT0+5R
n5/viQOMv0C0MYs525+/dpNkk2q2MiFmyyozdbU6zcyfdkrkYdChCFOQ9GsxzQHk
n4lL4/RSKdqJZg4x2yEGgdyKA6XrQHaFirdr/K2bhhbk4Q0SOuYjy8Wxa2oCHFCC
WG4K2NBnKCI7DuVXQK+ZC8dYXMwbemeFfPHY6dZVti7j/OFsllyxno/CFKO3rsCs
+uko4XJk6pH0Ncjrc1n0l0v9xIKF5hTqSxFs+GVvhkiBdTDZVe7CdedO9qJWf1hE
bbmLXTURCDQUFe9F3uKsnYfMoD5eniWHx2OQcJcNPlLMJd9zObB3HdgFMW6N53KN
QXLmxobU/xFhmFknz1ShGEIdGSaH0gqnb+WEkO5v5vBO4L6Cikc+lcp7zXqQzWpW
uqm3QSrbKcbR6JEwDFoGQpDkcqpwpTIrOAk4B1jJRg==
=J2KF
-----END PGP SIGNATURE-----
Gregory Maxwell 於 2015-12-10 04:51 寫到:
> On Thu, Dec 10, 2015 at 6:47 AM, jl2012--- via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> 4. Sum of fee, sigopcount, size etc as part of the witness hash tree:
>> for
>
> I should have also commented on this: the block can indicate how many
> sum criteria there are; and then additional ones could be soft-forked
> in. Haven't tried implementing it yet, but there you go. :)

2023-06-07 17:46:07

- reply

📅 Original date posted:2015-12-10
📝 Original message:It seems the current consensus is to implement Segregated Witness. SW
opens many new possibilities but we need a balance between new features
and deployment time frame. I'm listing by my priority:
1-2 are about scalability and have highest priority
1. Witness size limit: with SW we should allow a bigger overall block
size. It seems 2MB is considered to be safe for many people. However,
the exact size and growth of block size should be determined based on
testing and reasonable projection.
2. Deployment time frame: I prefer as soon as possible, even if none of
the following new features are implemented. This is not only a technical
issue but also a response to the community which has been waiting for a
scaling solution for years
3-6 promote safety and reduce level of trust (higher priority)
3. SIGHASH_WITHINPUTVALUE [1]: there are many SIGHASH proposals but this
one has the highest priority as it makes offline signing much easier.
4. Sum of fee, sigopcount, size etc as part of the witness hash tree:
for compact proof of violations in these parameters. I prefer to have
this feature in SWv1. Otherwise, that would become an ugly softfork in
SWv2 as we need to maintain one more hash tree
5. Height and position of an input as part of witness will allow compact
proof of non-existing UTXO. We need this eventually. If it is not done
in SWv1, we could softfork it nicely in SWv2. I prefer this earlier as
this is the last puzzle for compact fraud proof.
6. BIP62 and OP_IF malleability fix [2] as standardness rules:
involuntary malleability may still be a problem in the relay network and
may make the relay less efficient (need more research)
7-15 are new features and long-term goals (lower priority)
7. Enable OP_CAT etc:
OP_CAT will allow tree signatures described by [3]. Even without Schnorr
signature, m-of-n multisig will become more efficient if m < n.
OP_SUBSTR/OP_LEFT/OP_RIGHT will allow people to shorten a payment
address, while sacrificing security.
I'm not sure how those disabled bitwise logic codes could be useful
Multiplication and division may still considered to be risky and not
very useful?
8. Schnorr signature: for very efficient multisig [3] but could be
introduced later.
9. Per-input lock-time and relative lock-time: define lock-time and
relative lock-time in witness, and signed by user. BIP68 is not a very
ideal solution due to limited lock time length and resolution
10. OP_PUSHLOCKTIME and OP_PUSHRELATIVELOCKTIME: push the lock-time and
relative lock-time to stack. Will allow more flexibility than OP_CLTV
and OP_CSV
11. OP_RETURNTURE which allows softfork of any new OP codes [4]. It is
not really necessary with the version byte design but with OP_RETURNTURE
we don't need to pump the version byte too frequently.
12. OP_EVAL (BIP12), which enables Merkleized Abstract Syntax Trees
(MAST) with OP_CAT [5]. This will also obsolete BIP16. Further
restrictions should be made to make it safe [6]:
a) We may allow at most one OP_EVAL in the scriptPubKey
b) Not allow any OP_EVAL in the serialized script, nor anywhere else in
the witness (therefore not Turing-complete)
c) In order to maintain the ability to statically analyze scripts, the
serialized script must be the last push of the witness (or script
fails), and OP_EVAL must be the last OP code in the scriptPubKey
13. Combo OP codes for more compact scripts, for example:
OP_MERKLEHASH160, if executed, is equivalent to OP_SWAP OP_IF OP_SWAP
OP_ENDIF OP_CAT OP_HASH160 [3]. Allowing more compact tree-signature and
MAST scripts.
OP_DUPTOALTSTACK, OP_DUPFROMALTSTACK: copy to / from alt stack without
removing the item
14. UTXO commitment: good but not in near future
15. Starting as a softfork, moving to a hardfork? SW Softfork is a quick
but dirty solution. I believe a hardfork is unavoidable in the future,
as the 1MB limit has to be increased someday. If we could plan it ahead,
we could have a much cleaner SW hardfork in the future, with codes
pre-announced for 2 years.
[1] https://bitcointalk.org/index.php?topic=181734.0
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011679.html
[3] https://blockstream.com/2015/08/24/treesignatures/
[4] https://bitcointalk.org/index.php?topic=1106586.0
[5]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010977.html
[6] https://bitcointalk.org/index.php?topic=58579.msg690093#msg690093

2023-06-07 17:46:02

- reply

📅 Original date posted:2015-12-09
📝 Original message:Although the plan is to implement SW with softfork, I think many
important (but non-consensus critical) components of the network would
be broken and many things have to be redefined.
1. Definition of "Transaction ID". Currently, "Transaction ID" is simply
a hash of a tx. With SW, we may need to deal with 2 or 3 IDs for each
tx. Firstly we have the "backward-compatible txid" (bctxid), which has
exactly the same meaning of the original txid. We also have a "witness
ID" (wid), which is the hash of the witness. And finally we may need a
"global txid" (gtxid), which is a hash of bctxid|wid. A gtxid is needed
mainly for the relay of txs between full nodes. bctxid and wid are
consensus critical while gtxid is for relay network only.
2. IBLT / Bitcoin relay network: As the "backward-compatible txid"
defines only part of a tx, any relay protocols between full nodes have
to use the "global txid" to identify a tx. Malleability attack targeting
relay network is still possible as the witness is malleable.
3. getblocktemplete has to be upgraded to deal with witness data and
witness IDs. (Stratum seems to be not affected? I'm not sure)
4. Protocols relying on the coinbase tx (e.g. P2Pool, merged mining):
depends on the location of witness commitment, these protocols may be
broken.
Feel free to correct me and add more to the list.

2023-06-07 17:44:18

- reply

📅 Original date posted:2015-11-06
📝 Original message:I assume this proposal is implemented at the same time as BIP62. As long
as OP_IF/OP_NOTIF interprets the argument as a number, zero-padded
number and negative zero are already prohibited in BIP62
Tier Nolan via bitcoin-dev 於 2015-11-06 04:37 寫到:
> I meant not to use the OP_PUSH opcodes to do the push.
>
> Does OP_0 give a zero length byte array?
>
> Would this script return true?
>
> OP_0
>
> OP_PUSHDATA1 (length = 1, data = 0)
>
> OP_EQUAL
>
> The easiest definition is that OP_0 and OP_1 must be used to push the
> data and not any other push opcodes.
>
> On Fri, Nov 6, 2015 at 9:32 AM, Oleg Andreev <oleganza at gmail.com>
> wrote:
>
>>> One and zero should be defined as arrays of length one.
>> Otherwise, it is still possible to mutate the transaction by
>> changing the length of the array.
>>>
>>> They should also be minimally encoded but that is covered by
>> previous rules.
>>
>> These two lines contradict each other. Minimally-encoded "zero" is
>> an array of length zero, not one. I'd suggest defining this
>> explicitly here as "IF/NOTIF argument must be either zero-length
>> array or a single byte 0x01".
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:44:16

- reply

📅 Original date posted:2015-11-06
📝 Original message:I have a new BIP draft for fixing OP_IF and OP_NOTIF malleability.
Please comment:
https://github.com/jl2012/bips/blob/master/opifmalleability.mediawiki
Copied below:
BIP: x
Title: Dealing with OP_IF and OP_NOTIF malleability
Author: jl2012 <jl2012 at xbt.hk>
Status: Draft
Type: Standards Track
Created: 2015-11-06
Abstract
As an supplement to BIP62, this document specifies proposed changes to
the Bitcoin transaction validity rules in order to make malleability of
transactions with OP_IF and OP_NOTIF impossible.
Motivation
OP_IF and OP_NOTIF are flow control codes in the Bitcoin script system.
The programme flow is decided by whether the top stake value is 0 or
not. However, this behavior opens a source of malleability as a third
party may alter a non-zero flow control value to any other non-zero
value without invalidating the transaction.
As of November 2015, OP_IF and OP_NOTIF are not commonly used in the
blockchain. However, as more sophisticated functions such as
OP_CHECKLOCKTIMEVERITY are being introduced, OP_IF and OP_NOTIF will
become more popular and the related malleability should be fixed. This
proposal serves as a supplement to BIP62 and should be implemented with
other malleability fixes together.
Specification
If the transaction version is 3 or above, the flow control value for
OP_IF and OP_NOTIF must be either 0 or 1, or the transaction fails.
This is to be implemented with BIP62.
Compatibility
This is a softfork. To ensure OP_IF and OP_NOTIF transactions created
before the introduction of this BIP will still be accpeted by the
network, the new rules only apply to transactions of version 3 or above.
For people who want to preserve the original behaviour of OP_IF and
OP_NOTIF, an OP_0NOTEQUAL could be used before the flow control code to
transform any non-zero value to 1.
Reference
BIP62: https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki

2023-06-07 17:44:04

- reply

📅 Original date posted:2015-11-02
📝 Original message:Currently, a tx maybe included in a block only if its locktime (x) is
smaller than the timestamp of a block (y)
BIP113 says that a tx maybe included in a block only if x is smaller
than the median-time-past (z)
It is already a consensus rule that y > z. Therefore, if x < z, x < y
The new rule is absolutely stricter than the old rule, so it is a
softfork. Anything wrong with my interpretation?
Luke Dashjr via bitcoin-dev 於 2015-11-01 14:06 寫到:
> BIP 113 makes things valid which currently are not (any transaction
> with a
> locktime between the median time past, and the block nTime). Therefore
> it is a
> hardfork. Yet the current BIP describes and deploys it as a softfork.
>
> Furthermore, Bitcoin Core one week ago merged #6566 adding BIP 113
> logic to
> the mempool and block creation. This will probably produce invalid
> blocks
> (which CNB's safety TestBlockValidity call should catch), and should be
> reverted until an appropriate solution is determined.
>
> Rusty suggested something like adding N hours to the median time past
> for
> comparison, and to be a proper hardfork, this must be max()'d with the
> block
> nTime. On the other hand, if we will have a hardfork in the next year
> or so,
> it may be best to just hold off and deploy as part of that.
>
> Further thoughts/input?
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:44:03

- reply

📅 Original date posted:2015-11-03
📝 Original message:The other strategy is to have an informational BIP to define "safe" use
of Bitcoin.
1. scriptPubKey must be one of the following types: P2PK, P2PKH, P2SH,
n-of-m multisig with m < 4 (with or without CLTV or CSV, we should
define standard use of CLTV and CSV)
2. For P2SH, the serialized script must be one of the standard type
3. No use of unknown transaction version
4. Tx size < 100k
5. If conditions 1-4 are all satisfied, the locktime must not be longer
than 4 years from the creation of the tx
6. If at least one of the conditions 1-4 is not satisfied, the lock time
must not be longer than 6 months from the creation of the tx
7. A chain of unconfirmed transactions is unsafe due the malleability
8. Tx created by wallet software last updated 1 year ago is unsafe
9. Permanently deleting a private key is unsafe (that might be safe if
stricter practice is followed)
We must not introduce a new rule that may permanently invalidate a safe
tx, unless in emergency. Even in emergency, we should try to preserve
backward compatibility as much as possible (see the example at the end
of my message)
Being unsafe means there is a chance that the tx may become
unconfirmable, outputs become unspendable, or funds may be stolen
without a private key.
A grace period of 5 years must be given for "soft-fork" type change of
any of the rules. For example it is ok to introduce new standard script
anytime but not to remove.
----------------------
Back to Gavin's original question. If you want to somehow keep backward
compatibility for expensive-to-validate transactions in the future, you
may have rules like there could only be at most one
expensive-to-validate transaction in every 10 blocks, until year 2025. I
know this is over-complicated but it's a possible way to address your
concern.
Gavin Andresen via bitcoin-dev 於 2015-11-02 15:33 寫到:
> On Sun, Nov 1, 2015 at 6:46 PM, Tier Nolan via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> For guidelines
>>
>> * Transaction version numbers will be increased, if possible
>>
>> * Transactions with unknown/large version numbers are unsafe to use
>> with locktime
>>
>> * Reasonable notice is given that the change is being contemplated
>>
>> * Non-opt-in changes will only be to protect the integrity of the
>> network
>>
>> Locked transaction that can be validated without excessive load on
>> the network should be safe to use, even if non-standard.
>>
>> An OP_CAT script that requires TBs of RAM to validate crosses the
>> threshold of reasonableness.
>
> I like those guidelines, although I'm sure there may be lots of
> arguing over what fits under "protects the integrity of the network"
> or what constitutes "reasonable notice" (publish a BIP at least 30
> days before rolling out a change? 60 days? a year?)
>
> --
>
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:44:00

- reply

📅 Original date posted:2015-11-01
📝 Original message:My answer is simply "No", you don't have to maintain backward
compatibility for non-standard tx.
The same question applies to P2SH. Before the deployment of BIP16, one
could have created a time-locked tx with one of the output was in the
form of HASH160 <hash> EQUAL. The <hash>, however, is not a hash of a
valid serialized script, so the output is now permanently frozen.
It also applies to all the OP codes disabled by Satoshi: one could have
created a time-locked tx with those now disabled OP codes.
Same for BIP65 with the use of OP_NOP2. Following your logic, we can't
make any softfork related to the script system.
I think it is very important to make it clear that non-standard txs and
non-standard scripts may become invalid in the future
Gavin Andresen via bitcoin-dev 於 2015-10-28 10:06 寫到:
> I'm hoping this fits under the moderation rule of "short-term changes
> to the Bitcoin protcol" (I'm not exactly clear on what is meant by
> "short-term"; it would be lovely if the moderators would start a
> thread on bitcoin-discuss to clarify that):
>
> Should it be a requirement that ANY one-megabyte transaction that is
> valid
> under the existing rules also be valid under new rules?
>
> Pro: There could be expensive-to-validate transactions created and
> given a
> lockTime in the future stored somewhere safe. Their owners may have no
> other way of spending the funds (they might have thrown away the
> private
> keys), and changing validation rules to be more strict so that those
> transactions are invalid would be an unacceptable confiscation of
> funds.
>
> Con: It is extremely unlikely there are any such large, timelocked
> transactions, because the Core code has had a clear policy for years
> that
> 100,000-byte transactions are "standard" and are relayed and
> mined, and
> larger transactions are not. The requirement should be relaxed so that
> only
> valid 100,000-byte transaction under old consensus rules must be valid
> under new consensus rules (larger transactions may or may not be
> valid).
>
> I had to wrestle with that question when I implemented BIP101/Bitcoin
> XT
> when deciding on a limit for signature hashing (and decided the right
> answer was to support any "non-attack"1MB transaction; see
> https://bitcoincore.org/~gavin/ValidationSanity.pdf [1] for more
> details).
>
> --
>
> --
> Gavin Andresen
>
>
> Links:
> ------
> [1] https://bitcoincore.org/~gavin/ValidationSanity.pdf
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:43:06

- reply

📅 Original date posted:2015-10-09
📝 Original message:You are mixing multiple issues.
1. It is not possible to "checkpoint" in a totally decentralized and
trustless way. You need the whole blockchain to confirm its validity, as
a single invalid tx in the history will invalidate ALL blocks after it,
even if the invalid tx is irrelevant to you.
2. Downloading the whole blockchain does not mean you need to store the
whole blockchain. Spent transactions outputs can be safely removed from
your harddrive. Please read section 7 of Satoshi's paper:
https://bitcoin.org/bitcoin.pdf . This function is already implemented
in Bitcoin Core 0.11
3. If you don't even want to download the whole blockchain, you can
download and validate the portions that your are interested. Satoshi
called it Simplified Payment Verification (SPV), the section 8 of his
paper. It is secure as long as >50% of miners are honest. Android
Bitcoin Wallet is an SPV wallet based on bitcoinj.
Finally, I think this kind of question would be better asked on the
bitcointalk forum. The mailing list should be more specific to
development, not merely some vague idea.
telemaco via bitcoin-dev 於 2015-10-08 23:18 寫到:
> Hello,
>
> I have been working on database engineering for many years and there
> are some things i don't understand very well about how bitcoin
> architecture works. I have not written here because i would not like
> to disturb development with yet another of those far to implement
> ideas that does not contribute to actual code as sometimes is said
> here.
>
> On any case today I have been listening the last beyond bitcoin video
> about the new bitshares 2.0 and how they are changing the transaction
> structure to do it more similar to what relational database management
> systems have been doing for 30 years.
>
> Keep a checkpointed state and just carry the new transactions. On
> rdbms, anyone if they want to perform historical research or
> something, they can just get the transaction log backups and reply
> every single transaction since the beginning of history.
> Why is bitcoin network replying every single transaction since the
> beginning and not start from a closer state. Why is that information
> even stored on every core node? Couldn't we just have a checkpointed
> state and the new transactions and leave to "historical" nodes or
> collectors the backup of all the transactions since the beginning of
> history?
>
> Replication rdbms have been working with this model for some time,
> just being able to replicate at table, column, index, row or even db
> level between many datacenters/continents and already serving the
> financial world, banks and exchanges. Their tps is very fast because
> they only transfer the smallest number of transactions that nodes
> decide to be suscribed to, maybe japan exchange just needs
> transactional info from japanese stocks on nasdaq or something
> similar. But even if they suscribe to everything, the transactional
> info is to some extent just a very small amount of information.
>
> Couldn't we have just a very small transactional system with the
> fewest number of working transactions and advancing checkpointed
> states? We should be able to have nodes of the size of watches with
> that structure, instead of holding everything for ever for all
> eternity and hope on moore's law to keep us allowing infinite growth.
> What if 5 internet submarine cables get cut on a earth movement or war
> or there is a shortage of materials for chip manufacturing and the
> network moore's law cannot keep up. Shouldn't performance optimization
> and capacity planning go in both ways?. Having a really small working
> "transaction log" allows companies to rely some transactional info to
> little pdas on warehouses, or just relay a small amount of information
> to a satellite, not every single transaction of the company forever.
>
> After all if we could have a very small transactional workload and
> leave behind the overload of all the previous transactions, we could
> have bitcoin nodes on watches and have an incredibly decentralized
> system that nobody can disrupt as the decentralization would be
> massive. We could even create a very small odbc, jdbc connector on the
> bitcoin client and just let any traditional rdbms system handle the
> heavy load and just let bitcoin core rely everyone and his mother to a
> level that noone could ever disrupt a very small amount of
> transactional data.
>
> Just some thoughts. Please don't be very harsh, i am still researching
> bitcoin code and my intentions are the best as i cannot be more
> passionate about the project.
>
> Thanks,
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:42:24

- reply

📅 Original date posted:2015-10-03
📝 Original message:BIP68 allows per-input locktime, though I don't know how this could be
useful.
BIP68 and BIP112 are mostly ready. If we try to reimplement
relative-locktime without using nSequence, we may need to wait for
another year for deployment.
A compromise is to make BIP68 optional, indicated by a bit in tx
nVersion, as I suggested earlier (1). This will allow deploying
relative-locktime without further delay while not permanently limiting
future upgrades.
(1)
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010043.html
Peter Todd via bitcoin-dev 於 2015-10-03 10:30 寫到:
> BIP68 and BIP112 collectively define the CHECKSEQUENCEVERIFY semantics,
> which can be summarized conceptually as a relative CHECKLOCKTIMEVERIFY.
> However, CSV does define behavior for the previously undefined
> nSequence
> field, which is the only "free-form" field we currently have in the
> transaction serialization format that can be used for future upgrades -
> we should justify this new behavior carefully as it limits our options
> in the future. Adding new fields to the serialization format is very
> difficult, due to the very broad system-wide impact of the hard-fork
> required to do so.
>
> So we need to make the case for two main things:
>
> 1) We have applications that need a relative (instead of absolute CLTV)
>
> 2) Additionally to RCLTV, we need to implement this via nSequence
>
> To show we need RCLTV BIP112 provides the example "Escrow with
> Timeout",
> which is a need that was brought up by GreenAddress, among others; I
> don't think we have an issue there, though getting more examples would
> be a good thing. (the CLTV BIP describes seven use cases, and one
> additional future use-case)
>
> However I don't think we've done a good job showing why we need to
> implement this feature via nSequence. BIP68 describes the new nSequence
> semantics, and gives the rational for them as being a
> "Consensus-enforced tx replacement" mechanism, with a bidirectional
> payment channel as an example of this in action. However, the
> bidirectional payment channel concept itself can be easily implemented
> with CLTV alone. There is a small drawback in that the initial
> transaction could be delayed, reducing the overall time the channel
> exists, but the protocol already assumes that transactions can be
> reliably confirmed within a day - significantly less than the proposed
> 30 days duration of the channel. That example alone I don't think
> justifies a fairly complex soft-fork that limits future upgrades; we
> need more justification.
>
> So, what else can the community come up with? nSequence itself exists
> because of a failed feature that turned out to not work as intended;
> it'd be a shame to make that kind of mistake again, so let's get our
> semantics and use-cases in the BIPs and documented before we deploy.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:42:11

- reply

📅 Original date posted:2015-10-02
📝 Original message:According to the Oxford Dictionary, "coin" as a verb means "invent (a
new word or phrase)". Undoubtedly you created the first functional SPV
client but please retract the claim "I coined the term SPV" or that's
plagiarism.
And I'd like to highlight the following excerpt from the whitepaper:
"the simplified method can be fooled by an attacker's fabricated
transactions for as long as the attacker can continue to overpower the
network. One strategy to protect against this would be to accept alerts
from network nodes when they detect an invalid block, prompting the
user's software to download the full block and alerted transactions to
confirm the inconsistency."
Header only clients without any fraud detecting mechanism are functional
but incomplete SPV implementations, according to Sathoshi's original
definition. This might be good enough for the first generation SPV
wallet, but eventually SPV clients should be ready to detect any rule
violation in the blockchain, including things like block size (as
Satoshi mentioned "invalid block", not just "invalid transaction").
Mike Hearn via bitcoin-dev 於 2015-10-02 08:23 寫到:
> FWIW the "coining" I am referring to is here:
>
> https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285 [4]
>
> OK, with that, here goes. Firstly some terminology. I'm going to call
> these things SPV clients for "simplified payment verification".
> Headers-only is kind of a mouthful and "lightweight client" is too
> vague, as there are several other designs that could be described as
> lightweight like RPC frontend and Stefans WebCoin API approach
>
> At that time nobody used the term "SPV wallet" to refer to what apps
> like BreadWallet or libraries like bitcoinj do. Satoshi used the term
> "client only mode", Jeff was calling them "headers only client" etc.
> So I said, I'm going to call them SPV wallets after the section of the
> whitepaper that most precisely describes their operation.

2023-06-07 17:41:37

- reply

📅 Original date posted:2015-09-29
📝 Original message:Jonathan Toomim (Toomim Bros) via bitcoin-dev 於 2015-09-29 09:30 寫到:
> SPV clients will appear to behave normally, and
> will continue to show new transactions and get confirmations in a
> timely fashion. However, they will be systematically susceptible to
> attack from double-spends that attempt to spend funds in a way that
> the upgraded nodes will reject. These transactions will appear to get
> 1 confirmation, then regress to zero conf, every single time. These
> attacks can be performed for as long as someone mines with the old
> version.
1. Who told you to accept 1-confirmation tx? Satoshi recommended 6
confirmations in the whitepaper. Take your own risk if you do not follow
his advice.
2. This is true only if your SPV client naively follows the longest
chain without even looking at the block version. This might be good
enough for the 1st generation SPV client, but future generations should
at least have basic fraud detecting mechanism.
> If an attacker thinks he could get more than 25 BTC of
> double-spends per block, he might even choose to mine with the
> obsolete version in order to get predictable orphans and to trick SPV
> clients and fully verifying wallets on the old version.
This point is totally irrelevant. No matter there is a softfork or not,
SPV users are always vulnerable to such double-spending attack if they
blindly follow the longest chain AND accept 1-confirmation. The fiat
currency system might be safer for them.

2023-06-07 17:41:35

- reply

📅 Original date posted:2015-09-28
📝 Original message:Mike Hearn via bitcoin-dev 於 2015-09-28 11:38 寫到:
> My point about IsStandard is that miners can and do bypass it,
> without expecting that to carry financial consequences or lower the
> security of other users. By making it so a block which includes
> non-standard transactions can end up being seen as invalid, you are
> increasing the risk of accidents that carry financial consequences.
Bypassing IsStandard should be considered as an "expert mode". The
message should be "don't bypass it unless you understand what you are
doing".
By the way, miners are PAID to protect the network. It is their greatest
responsibility to follow the development and keep their software up to
date.
> How do ordinary Bitcoin users benefit from this rollout strategy? Put
> simply, what is the point of this whole complex soft fork endeavour?
Let me try to answer this question. Softfork is beneficial to non-mining
full nodes as they will follow the majority chain. In the case of a
hardfork (e.g. BIP101), non-upgrading full nodes will insist to follow
the minority chain. (unless you believe that all non-miner should use an
SPV client)
Put it in a different angle. In a softfork, the new fork is a persistent
95% attack against the old fork, which will force all in-cooperating
miners to join (or leave). In a hardfork, however, there is no mechanism
to stop the old fork and we may have 2 chains co-exist for a long time.
Although it is not mentioned in the whitepaper, the ability to softfork
is a feature of Bitcoin. Otherwise, we won't have these OP_NOPs and the
original OP_RETURN.

2023-06-07 17:41:25

- reply

📅 Original date posted:2015-09-27
📝 Original message:+1 for deploying BIP65 immediately without further waiting. Agree with
all Peter's points.
If BIP65 has to follow the 0.12 schedule, it will take almost 9 months
from now to complete the softfork. I don't see any good reason to wait
for that long. We have too much talk, too little action.
Some mining pools hinted that they may adopt BitcoinXT at the end of
2015. If we could start deploying BIP65 earlier, they will have a
patched version by the time they switch. Gavin has agreed to support
BIP65 in XT.
By the way, is there any chance to backport it to 0.9? In the deployment
of BIP66 some miners requested a backport to 0.9 and that's why we have
0.9.5.

2023-06-07 17:41:02

- reply

📅 Original date posted:2015-09-23
📝 Original message:There could not be a worse timing than this for those in China (3-4am),
Japan/Korea (4-5am), and Australia (3-6am depends on which part of the
country). Maybe we have no dev in this part of the planet? Is there any
chance to review the timing in a weekly or monthly basis (also with a
doodle vote?)
Will there be any agenda published before the meetings? If I'm really
interested in the topics, I'll have some reasons to get up in the middle
of the night.
Wladimir J. van der Laan via bitcoin-dev 於 2015-09-22 10:36 寫到:
> Hello,
>
> There was overwhelming response that weekly IRC meetings are a good
> thing.
>
> Thanks to the doodle site we were able to select a time slot that
> everyone (that voted) is available:
>
> Thursday 19:00-20:00 UTC, every week, starting September 24 (next
> Thursday)
>
> I created a shared Google Calendar here:
> https://www.google.com/calendar/embed?src=MTFwcXZkZ3BkOTlubGliZjliYTg2MXZ1OHNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ
>
> The timezone of this calendar is Reykyavik (Iceland) which is UTC+0.
> However, you can use the button on the lower right to add the calendar
> to your own calendar, which will then show the meeting in your own
> timezone.
>
> See you then,
>
> Wladimir
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:40:52

- reply

📅 Original date posted:2015-09-21
📝 Original message:It is possible to softfork. Just use Iceland time. Iceland time = UTC
without DST
Btc Drak via bitcoin-dev 於 2015-09-18 16:34 寫到:
> Urgh... Can we hardfork time? It's clearly in need of an upgrade...
>
> On Fri, Sep 18, 2015 at 9:31 PM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
>
>> On Fri, Sep 18, 2015 at 8:27 PM, Matt Corallo via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> Google Calendar is localized, but has an option to change the
>> timezone
>>> of an event, it just doesnt have UTC in its options. So, yes, we
>> should
>>> use something that observes DST in roughly the same way as
>> everyone else
>>> - CEST/PDT/EST/etc.
>>
>> uh. There is fairly little global consistency in DST usage. Lots of
>> places do dst on different dates.
>>
>> So if it's in some DST timezone it's likely to move twice each
>> change
>> for some subset of the people who do it.
>>
>> E.g. europe and US end DST one week apart.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:40:46

- reply

📅 Original date posted:2015-09-18
📝 Original message:Btc Drak 於 2015-09-18 02:42 寫到:
> On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Btc Drak 於 2015-09-17 15:12 寫到:
>>
>>> Forgive me if I have missed the exact use-case, but this seems
>>> overly
>>> complex. Surely fill-or-kill refers to getting a transaction
>>> confirmed
>>> within a few confirms or to drop the tx from the mempool so it
>>> wont be
>>> considered for inclusion anymore. As such, you could just
>>> repurpose a
>>> small range of nLocktime such that a TX will be accepted into
>>> mempool
>>> for a specific period before expiring.
>>
>> What I'm describing is to implement fill-or-kill as consensus rule.
>> Certainly, we could implement it at the P2P network level:
>> everything is the same as I described, but the nLockTime2 and
>> nKillTime are for reference only and tx validity depends only on the
>> nLockTime. Benevolent miners should drop the tx after the suggested
>> kill time but there is no guarantee
>
> Sure, you can make the scheme I describe consensus based by adding the
> rule tx is not valid to mine after expiry: this still keeps the
> simplicity I described.
If you simply redefine a range of unused nLockTime as nKillTime, users
will be constrained to use either nLockTime or nKillTime, but not both
in the same tx.
If we are willing to scarify a large range of tx nVersion, say
10-15bits, the nKillTime data could be embedded there.
Another option is nSequence, which will allow per-input nKillTime and
nLockTime.
The cleanest way, of course, is a hardfork to add a new nKillTime field
to the tx so people could use nLockTime and nKillTime in parallel.

2023-06-07 17:40:45

- reply

📅 Original date posted:2015-09-18
📝 Original message:Peter Todd via bitcoin-dev 於 2015-09-17 18:44 寫到:
> It can be implemented by a "treat like Coinbase" flag in the
> UTXO set, set when the output is created.
I think this is the cleanest way to implement the maturity requirement.
I understand why we need maturity, However, requiring 100 block maturity
will unfortunately make the system much less appealing since the
recipient may not like it. A fill-or-kill tx may still be used as the
initial funding tx to the Lightning Network, as long as the counterparty
is willing to take the extra risk.
Actually, a fill-or-kill tx is slight safer than a coinbase tx,
depending on the difference between the absolute kill time and actual
confirmation time. In a re-org, an orphaned coinbase tx is permanently
invalidated and has no hope to be included again. However, an orphaned
fill-or-kill tx may still be confirmed by another miner. If there is
still a few days until the absolute kill time, a fill-or-kill tx is
basically as safe as a normal tx.
With possibility of re-org and unpredictable block interval in mind,
height-based fill-or-kill is not very useful since it is difficult for
users to determine the actual kill time. If we could abolish the idea of
height-based fill-or-kill, the resolution of time-based fill-or-kill
might be improved.
------------------------------------
Chun Wang 於 2015-09-17 18:33 寫到:
> We are currently using nLockTime for share info and nSequence for
> extranonce2. I have carefully reviewed the reference implementation of
> BIP68 and it should be compatible, but this proposal may break the
> implementation unless it does not affect coinbase transactions.
>
The fill-or-kill system is totally optional, using a bit flag in tx
nVersion to indicate. Everything should be fine unless you are also
messing with the nVersion
-------------------------------------
Btc Drak 於 2015-09-17 15:12 寫到:
> Forgive me if I have missed the exact use-case, but this seems overly
> complex. Surely fill-or-kill refers to getting a transaction confirmed
> within a few confirms or to drop the tx from the mempool so it wont be
> considered for inclusion anymore. As such, you could just repurpose a
> small range of nLocktime such that a TX will be accepted into mempool
> for a specific period before expiring.
What I'm describing is to implement fill-or-kill as consensus rule.
Certainly, we could implement it at the P2P network level: everything is
the same as I described, but the nLockTime2 and nKillTime are for
reference only and tx validity depends only on the nLockTime. Benevolent
miners should drop the tx after the suggested kill time but there is no
guarantee
-------------------------------------
I made a mistake in this example:
> A user wants his tx get confirmed in the block 630000, the first block
> with reward below 10BTC. He is willing to pay high fee but don't want
> it gets into another block. He will set nLockTime2 = 210,000 and
> nKillTime = 0
The correct nLockTime2 for this example should be 210000/4 = 52500

2023-06-07 17:40:43

- reply

📅 Original date posted:2015-09-17
📝 Original message:Fill-or-kill tx is not a new idea and is discussed in the Scaling
Bitcoin workshop. In Satoshi's implementation of nLockTime, a huge range
of timestamp (from 1970 to 2009) is wasted. By exploiting this unused
range and with compromise in the time resolution, a fill-or-kill system
could be built with a softfork.
-----------
Two new parameters, nLockTime2 and nKillTime are defined:
nLockTime2 (Range: 0-1,853,010)
0: Tx could be confirmed at or after block 420,000
1: Tx could be confirmed at or after block 420,004
.
.
719,999: Tx could be confirmed at or after block 3,299,996 (about 55
years from now)
720,000: Tx could be confirmed if the median time-past >= 1,474,562,048
(2016-09-22)
720,001: Tx could be confirmed if the median time-past >= 1,474,564,096
(2016-09-22)
.
.
1,853,010 (max): Tx could be confirmed if the median time-past >=
3,794,966,528 (2090-04-04)
nKillTime (Range: 0-2047)
if nLockTime2 < 720,000, the tx could be confirmed at or before block
(nLockTime2 + nKillTime * 4)
if nLockTime2 >= 720,000, the tx could be confirmed if the median
time-past <= (nLockTime2 - 720,001 + nKillTime) * 2048
Finally, nLockTime = 500,000,000 + nKillTime + nLockTime2 * 2048
Setting a bit flag in tx nVersion will activate the new rules.
The resolution is 4 blocks or 2048s (34m)
The maximum confirmation window is 8188 blocks (56.9 days) or
16,769,024s (48.5 days)
For example:
With nLockTime2 = 20 and nKillTime = 100, a tx could be confirmed only
between block 420,080 and 420,480
With nLockTime2 = 730,000 and nKillTime = 1000, a tx could be confirmed
only between median time-past of 1,495,042,048 and 1,497,090,048
----------------
Why is this a softfork?
Remember this formula: nLockTime = 500,000,000 + nKillTime + nLockTime2
* 2048
For height based nLockTime2 (<= 719,999)
For nLockTime2 = 0 and nKillTime = 0, nLockTime = 500,000,000, which
means the tx could be confirmed after 1970-01-01 with the original lock
time rule. As the new rule does not allow confirmation until block
420,000, it's clearly a softfork.
It is not difficult to see that the growth of nLockTime will never catch
up nLockTime2.
At nLockTime2 = 719,999 and nKillTime = 2047, nLockTime = 1,974,559,999,
which means 2016-09-22. However, the new rule will not allow
confirmation until block 3,299,996 which is decades to go
For time based nLockTime2 (> 720,000)
For nLockTime2 = 720,000 and nKillTime = 0, nLockTime = 1,974,560,000,
which means the tx could be confirmed after median time-past
1,474,560,000 (assuming BIP113). However, the new rule will not allow
confirmation until 1,474,562,048, therefore a soft fork.
For nLockTime2 = 720,000 and nKillTime = 2047, nLockTime =
1,974,562,047, which could be confirmed at 1,474,562,047. Again, the new
rule will not allow confirmation until 1,474,562,048. The 1 second
difference makes it a soft fork.
Actually, for every nLockTime2 value >= 720,000, the lock time with the
new rule must be 1-2048 seconds later than the original rule.
For nLockTime2 = 1,853,010 and nKillTime = 2047, nLockTime =
4,294,966,527, which is the highest possible value with the 32-bit
nLockTime
----------------
User's perspective:
A user wants his tx either filled or killed in about 3 hours. He will
set a time-based nLockTime2 according to the current median time-past,
and set nKillTime = 5
A user wants his tx get confirmed in the block 630000, the first block
with reward below 10BTC. He is willing to pay high fee but don't want it
gets into another block. He will set nLockTime2 = 210,000 and nKillTime
= 0
----------------
OP_CLTV
Time-based OP_CLTV could be upgraded to support time-based nLockTime2.
However, height-based OP_CLTV is not compatible with nLockTime2. To
spend a height-based OP_CLTV output, user must use the original
nLockTime.
We may need a new OP_CLTV2 which could verify both nLockTime and
nLockTime2
----------------
55 years after?
The height-based nLockTime2 will overflow in 55 years. It is very likely
a hard fork will happen to implement a better fill-or-kill system. If
not, we could reboot everything with another tx nVersion for another 55
years.

2023-06-07 17:40:42

- reply

📅 Original date posted:2015-09-17
📝 Original message:How many years of relative lock time do we need? It really depends why
we need a relative lock time in the first place, what what does it offer
in addition to CHECKLOCKTIMEVERIFY. The only case I know is when the
confirmation taking too long, CLTV may expire before the tx is
confirmed. For use case like this, 1 year of relative lock time is much
more than enough, since Bitcoin is basically worthless if it takes
months to confirm a tx with a reasonable fee.
Is there any other use case of CSV that is irreplaceable by CLTV? There
is only one example in the BIP CSV draft.
For the timebased relative lock time, 256 seconds of granularity is more
than enough since the block interval is 600s. Although it is not
impossible to reduce the block interval in the future, that will be a
hardfork anyway and we may just hardfork BIP68/CSV at the same time.
Mark Friedenbach via bitcoin-dev 於 2015-08-27 19:32 寫到:
> So I've created 2 new repositories with changed rules regarding
> sequencenumbers:
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers2 [2]
>
> This repository inverts (un-inverts?) the sequence number. nSequence=1
> means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD means
> 1 second relative lock-height. nSequence>=0x80000000 (most significant
> bit set) is not interpreted as a relative lock-time.
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers3 [3]
>
> This repository not only inverts the sequence number, but also
> interprets it as a fixed-point number. This allows up to 5 year
> relative lock times using blocks as units, and saves 12 low-order bits
> for future use. Or, up to about 2 year relative lock times using
> seconds as units, and saves 4 bits for future use without second-level
> granularity. More bits could be recovered from time-based locktimes by
> choosing a higher granularity (a soft-fork change if done correctly).
>
> On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach
> <mark at friedenbach.org> wrote:
>
>> To follow up on this, let's say that you want to be able to have up
>> to 1 year relative lock-times. This choice is somewhat arbitrary and
>> what I would like some input on, but I'll come back to this point.
>>
>> * 1 bit is necessary to enable/disable relative lock-time.
>>
>> * 1 bit is necessary to indicate whether seconds vs blocks as the
>> unit of measurement.
>>
>> * 1 year of time with 1-second granularity requires 25 bits.
>> However since blocks occur at approximately 10 minute intervals on
>> average, having a relative lock-time significantly less than this
>> interval doesn't make much sense. A granularity of 256 seconds would
>> be greater than the Nyquist frequency and requires only 17 bits.
>>
>> * 1 year of blocks with 1-block granularity requires 16 bits.
>>
>> So time-based relative lock time requires about 19 bits, and
>> block-based relative lock-time requires about 18 bits. That leaves
>> 13 or 14 bits for other uses.
>>
>> Assuming a maximum of 1-year relative lock-times. But what is an
>> appropriate maximum to choose? The use cases I have considered have
>> only had lock times on the order of a few days to a month or so.
>> However I would feel uncomfortable going less than a year for a hard
>> maximum, and am having trouble thinking of any use case that would
>> require more than a year of lock-time. Can anyone else think of a
>> use case that requires >1yr relative lock-time?
>>
>> TL;DR
>>
>> On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach
>> <mark at friedenbach.org> wrote:
>>
>> A power of 2 would be far more efficient here. The key question is
>> how long of a relative block time do you need? Figure out what the
>> maximum should be ( I don't know what that would be, any ideas?) and
>> then see how many bits you have left over.
>>
>> On Aug 23, 2015 7:23 PM, "Jorge Timón"
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
>>> discussion has any thought been given to represent one block with
>> more
>>> than one increment? This would leave additional space for future
>>> signaling, or allow, for example, higher resolution numbers for a
>>> sharechain commitement.
>>
>> No, I don't think anybody thought about this. I just explained this
>> to
>> Pieter using "for example, 10 instead of 1".
>> He suggested 600 increments so that it is more similar to
>> timestamps.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>
>
>
> Links:
> ------
> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> [2] https://github.com/maaku/bitcoin/tree/sequencenumbers2
> [3] https://github.com/maaku/bitcoin/tree/sequencenumbers3
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:39:55

- reply

📅 Original date posted:2015-09-10
📝 Original message:Inspired by Pieter's Tree Signatures, I believe Merkleized Abstract
Syntax Trees (MAST) could be implemented with only OP_CAT and OP_EVAL
(BIP12).
The idea is very simple. Using a similar example in Pieter's paper,
scriptSig = <sig> <serialized sub-script 10> Z1 0 1 1 X6 1 K9 0
<serialized script>
scriptPubKey = DUP HASH160 <hash serialized script> EQUALVERIFY EVAL
serialized script = 8 PICK SHA256 (SWAP IF SWAP ENDIF CAT SHA256)*4 <R>
EQUALVERIFY EVAL
This will run the 10-th sub-script, when there are 11 sub-scripts in the
MAST
I think this is the easiest way to enable MAST since the reference
implementation for BIP12 is already there. We could enable OP_CAT only
inside OP_EVAL so this will be a pure softfork.
Ref:
Tree Signatures: https://blockstream.com/2015/08/24/treesignatures/
BIP12: https://github.com/bitcoin/bips/blob/master/bip-0012.mediawiki

2023-06-07 17:39:25

- reply

📅 Original date posted:2015-09-03
📝 Original message:Jeff Garzik via bitcoin-dev 於 2015-09-03 00:05 寫到:
> Schemes proposing to pay with difficulty / hashpower to change block
> size should be avoided. The miners incentive has always been fairly
> straightforward - it is rational to deploy new hashpower as soon as
> you can get it online. Introducing the concepts of (a) requiring
> out-of-band collusion to change block size and/or (b) requiring miners
> to have idle hashpower on hand to change block size are both
> unrealistic and potentially corrosive. That potentially makes the
> block size - and therefore fee market - too close, too sensitive to
> the wild vagaries of the mining chip market.
>
> Pay-to-future-miner has neutral, forward looking incentives worth
> researching.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Ref:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010723.html
I explained here why pay with difficulty is bad for everyone: miners and
users, and described the use of OP_CLTV for pay-to-future-miner
However, a general problem of pay-to-increase-block-size scheme is it
indirectly sets a minimal tx fee, which could be difficult and
arbitrary, and is against competition

2023-06-07 17:39:25

- reply

📅 Original date posted:2015-09-03
📝 Original message:Assuming that:
1. The current block size is 1MB
2. The block reward for a full block is 25.5BTC including tx fee
3. Miner is required to pay x% of reward penalty if he is trying to
increase the size of the next block by x%
If a miner wants to increase the block size by 1 byte, the block size
has to increase by 0.0001%, and the penalty will be 0.0000255BTC/byte.
For a typical 230byte tx that'd be 0.005865BTC, or 1.35USD at current
rate. This is the effective minimum tx fee.
Jeff Garzik 於 2015-09-03 10:18 寫到:
> Thanks for the link. I readily admit only having given
> pay-to-future-miner a little bit of thought. Not convinced it sets a
> minimal tx fee in all cases.
>
> On Thu, Sep 3, 2015 at 12:55 AM, <jl2012 at xbt.hk> wrote:
>
>> Jeff Garzik via bitcoin-dev 於 2015-09-03 00:05 寫到:
>>
>>> Schemes proposing to pay with difficulty / hashpower to change
>>> block
>>> size should be avoided. The miners incentive has always been
>>> fairly
>>> straightforward - it is rational to deploy new hashpower as soon
>>> as
>>> you can get it online. Introducing the concepts of (a) requiring
>>> out-of-band collusion to change block size and/or (b) requiring
>>> miners
>>> to have idle hashpower on hand to change block size are both
>>> unrealistic and potentially corrosive. That potentially makes
>>> the
>>> block size - and therefore fee market - too close, too sensitive
>>> to
>>> the wild vagaries of the mining chip market.
>>>
>>> Pay-to-future-miner has neutral, forward looking incentives worth
>>> researching.
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> [1]
>>
>> Ref:
>>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010723.html
>> [2]
>>
>> I explained here why pay with difficulty is bad for everyone:
>> miners and users, and described the use of OP_CLTV for
>> pay-to-future-miner
>>
>> However, a general problem of pay-to-increase-block-size scheme is
>> it indirectly sets a minimal tx fee, which could be difficult and
>> arbitrary, and is against competition
>
>
>
> Links:
> ------
> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010723.html

2023-06-07 17:39:20

- reply

📅 Original date posted:2015-09-03
📝 Original message:1. I think there is no need to have resolution at byte level, while
resolution at MB level is not enough. kB would be a better choice.
2. In my specification a v4 block without a vote is invalid, so there is
no need to consider absent or invalid votes
3. We should allow miners to explicitly vote for the status quo, so they
don't need to change the coinbase vote every time the size is changed.
They may indicate it by /BV/ in the coinbase, and we should look for the
first "/BVd*/" instead of "/BVd+/"
4. Alternatively, miners may vote in different styles: /BV1234567/,
/BV1500K/, /BV3M/. The first one means 1.234567MB, the second one is
1.5MB, the last one is 3MB. The pattern is "/BV(\d+[KM]?)?/"
Tier Nolan via bitcoin-dev 於 2015-09-03 07:59 寫到:
> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> *
>>
>> hardLimit floats within the range 1-32M, inclusive.
>
> Does the 32MB limit actually still exist anywhere in the code? In
> effect, it is re-instating a legacy limitation.
>
> The message size limit is to minimize the storage required per peer.
> If a 32MB block size is required, then each network input buffer must
> be at least 32MB. This makes it harder for a node to support a large
> number of peers.
>
> There is no reason why a single message is used for each block. Using
> the merkleblock message (or a different dedicated message), it would
> be possible to send messages which only contain part of a block and
> have a limited maximum size.
>
> This would allow receiving parts of a block from multiple sources.
>
> This is a separate issue but should be considered if moving past 32MB
> block sizes (or maybe as a later protocol change).
>
>> * Changing hardLimit is accomplished by encoding a proposed value
>> within a block's coinbase scriptSig.
>>
>> * Votes refer to a byte value, encoded within the pattern "/BVd+/"
>> Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If there is
>> more than one match with with pattern, the first match is counted.
>
> Is there a need for byte resolution? Using MB resolution would use up
> much fewer bytes in the coinbase.
>
> Even with the +/- 20% rule, miners could vote for the nearest MB.
> Once the block size exceeds 5MB, then there is enough resolution
> anyway.
>
>> * Absent/invalid votes and votes below minimum cap (1M) are
>> counted as 1M votes. Votes above the maximum cap (32M) are counted
>> as 32M votes.
>
> I think abstains should count for the status quo. Votes which are out
> of range should be clamped.
>
> Having said that, if core supports the change, then most miners will
> probably vote one way or another.
>
>> New hardLimit is the median of the followings:
>> min(current hardLimit * 1.2, 20-percentile)
>> max(current hardLimit / 1.2, 80-percentile)
>> current hardLimit
>
> I think this is unclear, though mathematically exact.
>
> Sort the votes for the last 12,000 blocks from lowest to highest.
>
> Blocks which don't have a vote are considered a vote for the status
> quo.
>
> Votes are limited to +/- 20% of the current value. Votes that are out
> of range are considered to vote for the nearest in range value.
>
> The raise value is defined as the vote for the 2400th highest block
> (20th percentile).
>
> The lower value is defined as the vote for the 9600th highest block
> (80th percentile).
>
> If the raise value is higher than the status quo, then the new limit
> is set to the raise value.
>
> If the lower value is lower than the status quo, then the new limit is
> set to the lower value.
>
> Otherwise, the size limit is unchanged.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:39:17

- reply

📅 Original date posted:2015-09-03
📝 Original message:Some comments:
* The 75% rule is meaningless here. Since this is a pure relaxation of
rules, there is no such thing as "invalid version 4 blocks"
*
The implication threshold is unclear. Is it 95% or 80%?
* Softfork requires a very high threshold (95%) to "attack" the
original fork. This makes sure that unupgraded client will only see the
new fork.
* In the case of hardfork, however, the new fork is unable to attack
the original fork, and unupgraded client will never see the new fork.
The initiation of a hardfork should be based on its acceptance by the
economic majority, not miner support. 95% is an overkill and may
probably never accomplished. I strongly prefer a 80% threshold rather
than 95%.
* As I've pointed out, using 20-percentile rather than median creates
an incentive to 51% attack the uncooperative minority.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html
Having said that, I don't have a strong feeling about the use of
20-percentile as threshold to increase the block size. That means the
block size is increased only when most miners agree, which sounds ok to
me.
However, using 20-percentile as threshold to DECREASE the block size
could be very dangerous. Consider that the block size has been stable at
8MB for a few years. Everyone are happy with that. An attacker would
just need to acquire 21% of mining power to break the status quo and
send us all the way to 1MB. The only way to stop such attempt is to 51%
attack the attacker. That'd be really ugly.
For technical and ethical reasons, I believe the thresholds for increase
and decrease must be symmetrical: increase the block size when the
x-percentile is bigger than the current size, decrease the block size
when the (100-x)-percentile is smaller than the current size. The
overall effect is: the block size remains unchanged unless 80% of miners
agree to.
* Please consider the use of "hardfork bit" to signify the hardfork:
https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/
https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki
* Or, alternatively, please combine the hardfork with a softfork. I'm
rewriting the specification as follow (changes underlined):
* Replace static 1M block size hard limit with a floating limit
("hardLimit").
*
hardLimit floats within the range 1-32M, inclusive.
*
Initial value of hardLimit is 1M, preserving current system.
* Changing hardLimit is accomplished by encoding a proposed value
within a block's coinbase scriptSig.
* Votes refer to a byte value, encoded within the pattern "/BVd+/"
Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If there is
more than one match with with pattern, the first match is counted.
* Absent/invalid votes and votes below minimum cap (1M) are counted as
1M votes. Votes above the maximum cap (32M) are counted as 32M votes.
* A new hardLimit is calculated at each difficult adjustment period
(2016 blocks), and applies to the next 2016 blocks.
* Calculate hardLimit by examining the coinbase scriptSig votes of the
previous 12,000 blocks, and taking the 20th percentile and 80th
percentile.
* New hardLimit is the median of the followings:
* min(current hardLimit * 1.2, 20-percentile)
* max(current hardLimit / 1.2, 80-percentile)
* current hardLimit
* version 4 block: the coinbase of a version 4 block must match this
pattern: "/BVd+/"
* 70% rule: If 8,400 of the last 12,000 blocks are version 4 or
greater, reject invalid version 4 blocks. (testnet4: 501 of last 1000)
* 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks
are version 4 or greater, reject all version <= 3 blocks. (testnet4: 750
of last 1000)
* Block version number is calculated after masking out high 16 bits
(final bit count TBD by versionBits outcome).
Jeff Garzik via bitcoin-dev 於 2015-09-02 23:33 寫到:
> BIP 100 initial public draft:
> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]
>
> Emphasis on "initial" This is a starting point for the usual open
> source feedback/iteration cycle, not an endpoint that Must Be This
> Way.
>
>
>
> Links:
> ------
> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
>
> _______________________________________________
> 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/20150903/9bfb6c46/attachment.html>

2023-06-07 17:38:43

- reply

📅 Original date posted:2015-08-31
📝 Original message:Bryan Bishop via bitcoin-dev 於 2015-08-30 14:56 寫到:
>
> SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY
> SIGHASH_WITHOUT_PREV_VALUE
> SIGHASH_WITHOUT_INPUT_TXID
> SIGHASH_WITHOUT_INPUT_INDEX
> SIGHASH_WITHOUT_INPUT_SEQUENCE
> SIGHASH_WITHOUT_OUTPUT_SCRIPTPUBKEY
> SIGHASH_WITHOUT_OUTPUT_VALUE
> SIGHASH_WITHOUT_INPUTS
> SIGHASH_WITHOUT_OUTPUTS
> SIGHASH_WITHOUT_INPUT_SELF
> SIGHASH_WITHOUT_OUTPUT_SELF
> SIGHASH_WITHOUT_TX_VERSION
> SIGHASH_WITHOUT_TX_LOCKTIME
> SIGHASH_SIGN_STACK_ELEMENT:
> https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md
>
Thanks for your summary. This one seems particularly interesting.
However, it does not allow fine adjustment for each input and output
separately, so I wonder if it really "fully enable any seen or unforseen
use case of the CTransactionSignatureSerializer." as it claims.

2023-06-07 17:38:21

- reply

📅 Original date posted:2015-08-30
📝 Original message:Sorry to be off-topic but SNR of the mailing list is really getting
ridiculous.
Stop trolling and feeding the trolls.
Before you click "send", remember that your message will be sent to the
inbox of hundreds or thousands of people.
Ref:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010463.html
Vinyas via bitcoin-dev 於 2015-08-30 11:16 寫到:
> No No
> On Aug 30, 2015, at 14:47, s7r via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> 2^256 x _NO_
>>

2023-06-07 17:38:17

- reply

📅 Original date posted:2015-08-27
📝 Original message:Very good, I can't wait to see it. Please code it up and submit a pull
request to github. Don't expect someone will do it for you.
prabhat via bitcoin-dev 於 2015-08-27 08:06 寫到:
> snip.
> Folks, suggest something, scrap my idea, but let's build something to
> save this ecosystem, otherwise it is impossible to realise this dream
> of decentralized currency. Other coins and protocols are there who may
> implement something, and egoists always meet the ashes.
>

2023-06-07 17:38:05

- reply

📅 Original date posted:2015-08-23
📝 Original message:Someone is going to burn 150BTC to create a backlog of 30-day in
September.
https://www.reddit.com/r/Bitcoin/comments/3hgke4/coinwallet_says_bitcoin_stress_test_in_september/
However, the money could be spent more wisely by encouraging mining of
the first few big blocks
Assumptions:
1. OP_CSV and BIP68 are enabled
2. Max tx size remains 1MB
The donor will create a transaction, with an input of 150BTC, and 10
outputs:
1. 0 BTC to "OP_RETURN <garbage>"
2. 42 BTC to "OP_1 OP_CSV"
3. 21 BTC to "OP_2 OP_CSV"
4. 10.5 BTC to "OP_3 OP_CSV"
5. 5.25 BTC to "OP_4 OP_CSV"
6. 2.625 BTC to "OP_5 OP_CSV"
7. 1.3125 BTC to "OP_6 OP_CSV"
8. 0.65625 BTC to "OP_7 OP_CSV"
9. 0.328125 BTC to "OP_8 OP_CSV"
10. 0.328125 BTC to "OP_9 OP_CSV"
The first output will fill up the size to 1MB.
This tx could not be confirmed by a pre-hardfork miner because the
coinbase tx will consume some block space. The first big block miner
will be able to collect 66BTC of fee. The block confirming the first big
block will collect 42BTC of fee, etc. This will create a long enough
chain to bootstrap the hardfork.
The amount is chosen to make sure the difference is <25BTC, so miners
would have less incentive to create a fork instead of confirming other's
block. However, a miner cartel may launch a 51% attack to collect all
money. Such incentive may be reduced by adjusting the distribution of
donation. (Actually, such cartel may be formed anytime, just for
collecting more block reward)

2023-06-07 17:38:01

- reply

📅 Original date posted:2015-08-28
📝 Original message:Mode could be ruled out immediately. Just consider this: 34% 8MB, 33%
1.5MB, 33% 1.2MB
I personally believe the median is the most natural and logical choice.
51% of miners can always force the 49% to follow the simple majority
choice through a 51% attack. Using median will eliminate the incentive
to 51% attack due to this reason. The incentive to 51% attack will exist
when you use any value other than 50-percentile. The further it is from
50, the bigger the incentive.
Having said that, I don't think it is an absolutely bad idea to use a
value other than 50-percentile. The exact value is debatable.
However, if you use something other than median, you should make it
symmetrical. For example, the block size will increase if the
20-percentile is bigger than the current limit, and the block size will
decrease if the 80-percentile is smaller than the current limit.
Jeff Garzik via bitcoin-dev 於 2015-08-27 16:49 寫到:
> 20th percentile, though there is some argument to take the 'mode' of
> several tranches
>
> On Thu, Aug 27, 2015 at 11:07 AM, Andrew C <achow101 at gmail.com> wrote:
>
>> I have been reading the pdf and one thing I can't figure out is what
>> you mean by "most common floor". Is that the smallest block size
>> that has a vote or the block size with the most votes or something
>> else?
>>
>> On Mon, Aug 24, 2015 at 10:40 AM Jeff Garzik <jgarzik at gmail.com>
>> wrote:
>>
>> Great questions.
>>
>> - Currently working on technical BIP draft and implementation,
>> hopefully for ScalingBitcoin.org. Only the PDF is publicly
>> available as of today.
>> - Yes, the initial deployment is in the same manner as size votes.
>>
>> On Fri, Aug 21, 2015 at 7:38 PM, Andrew C via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hi all,
>>
>> Is there any client or code that currently implements BIP 100? And
>> how will it be deployed? WIll the initial fork be deployed in the
>> same manner that the max block size changes are deployed described
>> in the bip?
>>
>> Thanks
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>
>
>
> Links:
> ------
> [1] 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

2023-06-07 17:37:59

- reply

📅 Original date posted:2015-08-29
📝 Original message:We need some game theory experts to analyse this but I see there are 3
major problems:
1. Tragedy of the commons: Some miners have to scarify their income to
increase the block size, and all miners will share the beneficial
outcome of the increase. All miners would like to be free riders.
2. Promote the formation of mining cartel: miners have to make sure that
their vote for increase is supported by at least 50% of miners, or they
will lose income for nothing. A miner also needs to make sure that he is
not voting "excessively" (in terms of size and vote count), as the
excessive part will never be counted due to the use of median. So
basically you will either have exactly 1009 miners voting for the same
size increase in a cycle, or have no vote for increase at all. That will
require a lot of offline negotiations. Such cartel may work ONLY if
mining is highly centralized, and miners trust each other. Also, there
is no mechanism to punish those who betray the cartel.
3. Imbalance of power: it is costly to increase the size, while totally
free to decrease the size
Btc Drak via bitcoin-dev 於 2015-08-28 16:28 寫到:
> I have received a lot of feedback on the original gist[1], reddit[2],
> ML and IRC and have reworked the text somewhat.
>
> I also request the BIP maintainer for a BIP number assignment
>
> [1] https://gist.github.com/btcdrak/1c3a323100a912b605b5
> [2]
> https://www.reddit.com/r/Bitcoin/comments/3ibia0/bipxx_consensus_based_block_size_retargeting/
>
> Pull request: https://github.com/bitcoin/bips/pull/187
>
> <pre>
> BIP: XX
> Title: Consensus based block size retargeting algorithm
> Author: BtcDrak <btcdrak at gmail.com>
> Status: Draft
> Type: Standards Track
> Created: 2015-08-21
> </pre>
>
> ==Abstract==
>
> A method of altering the maximum allowed block size of the Bitcoin
> protocol
> using a consensus based approach.
>
> ==Motivation==
>
> There is a belief that Bitcoin cannot easily respond to raising the
> blocksize limit if popularity was to suddenly increase due to a mass
> adoption
> curve, because co-ordinating a hard fork takes considerable time, and
> being
> unable to respond in a timely manner would irreparably harm the
> credibility of
> bitcoin.
>
> Additionally, predetermined block size increases are problematic
> because they
> attempt to predict the future, and if too large could have unintended
> consequences like damaging the possibility for a fee market to develop
> as block subsidy decreases substantially over the next 9 years;
> introducing
> or exacerbating mining attack vectors; or somehow affect the network in
> unknown
> or unpredicted ways. Since fixed changes are hard to deploy, the damage
> could be
> extensive.
>
> Dynamic block size adjustments also suffer from the potential to be
> gamed by the
> larger hash power.
>
> Free voting as suggested by BIP100 allows miners to sell their votes
> out of band
> at no risk, and enable the sponsor the ability to manipulate the
> blocksize.
> It also provides a cost free method or the larger pools to vote in ways
> to
> manipulate the blocksize such to disadvantage or attack smaller pools.
>
>
> ==Rationale==
>
> By introducing a cost to increase the block size ensures the mining
> community
> will collude to increase it only when there is a clear necessity, and
> reduce it
> when it is unnecessary. Larger miners cannot force their wishes so
> easily
> because not only will they have to pay extra a difficulty target, then
> can be
> downvoted at no cost by the objecting hash power.
>
> Using difficulty as a penalty is better than a fixed cost in bitcoins
> because it
> is less predictable.
>
>
> ==Specification==
>
> The initial block size limit shall be 1MB.
>
> Each time a miner creates a block, they may vote to increase or
> decrease the
> blocksize by a maximum of 10% of the current block size limit. These
> votes will
> be used to recalculate the new block size limit every 2016 blocks.
>
> Votes are cast using the block's coinbase field.
>
> The first 4 bytes of the coinbase field shall be repurposed for voting
> as an
> unsigned long integer which will be the block size in bytes.
>
> If a miner votes for an increase, the block hash must meet a difficulty
> target
> which is proportionally larger than the standard difficulty target
> based on the
> percentage increase they voted for.
>
> Votes proposing decreasing the block size limit do not need to meet a
> higher
> difficulty target.
>
> Miners can vote for no change by voting for the current block size.
>
> For blocks to be valid the blockhash must meet the required difficulty
> target
> for the vote otherwise the block is invalid and will be rejected.
>
> Every 2016 blocks, the block size limit will be recalculated by the
> median of
> all votes in the last 2016 blocks. This will redefine the block size
> limit for
> the next 2016 blocks.
>
> Blocks that are larger than the calculated base block size limit are
> invalid and
> will be rejected.
>
> The base block size limit may not reduce below 1MB.
>
>
> ==Acknowledgements==
>
> This proposal is based on ideas and concepts derived from the writings
> of
> Meni Rosenfeld and Gregory Maxwell.
>
>
> ==Copyright==
>
> This work is placed in the public domain.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:37:57

- reply

📅 Original date posted:2015-08-31
📝 Original message:Jorge Timón 於 2015-08-30 14:56 寫到:
> On Sun, Aug 30, 2015 at 7:13 PM, <jl2012 at xbt.hk> wrote:
>> This is based on the assumption that miners would always like to use
>> up the
>> last byte of the available block size. However, this is just not true:
>>
>> 1. The 6 year blockchain history has shown that most miners have a
>> soft cap
>> with their block size.
>>
>> 2. Chinese miners, controlling 60% of the network, rejected Gavin's
>> initial
>> 20MB proposal and asked for 8MB:
>> http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size
>> [...]
>
> No, I'm not making such assumption. I'm focusing on what they CAN do,
> while suspending judgement on their good will and not trying to
> predict their future behavior from historic behaviour.
> With 60% of the hashrate, you can easily get 100% by orphaning
> everybody else's blocks. More importantly, being under the same
> jurisdiction they can be forced to behave in certain way (for example,
> censor transactions) by law.
> I'm very worried about the current situation no matter how benevolent
> current miners are. Thus weakening the only limit to mining
> centralization that we have at the consensus rule level seems
> extremely risky at this point.
The reason for 60% of block were generated in China is same as the
reason for 60% of your clothes were made in China. The electricity there
is the cheapest on the planet. Many dams were built in the past 10 years
and now they have huge amount of surplus electricity due to economic
downturn.
Not sure if you are aware of this thread:
https://bitcointalk.org/index.php?topic=1072474.0 . Could you imagine
this in any developed country? As long as mining is largely dependent on
energy, there is no hope to break the balance/imbalance.
Bandwidth is probably only a few percent of miners' cost. There is no
evidence that the current level of centralization is a result of block
size. Instead, clear evidence has shown that centralization is a result
of pool mining*, invention of ASIC, and disparity of energy cost. (*
People started pool mining in 2010 because they wanted lower variance,
not because of the inability to run a full node)
>> For many reasons miners may want to have a smaller block size, which
>> we
>> don't need to list them here. Although they can limit it by a softfork
>> or
>> even 51% attack, it is a very violent process. Why don't we just allow
>> them
>> to vote for a lower limit?
>>
>> So I think the right way is to choose a mining-centralization-safe
>> limit,
>> and let it free float within a range based on miner's vote. If we are
>> lucky
>> enough to have some responsible miners, they will keep it as low as
>> possible, until the legitimate tx volume catches up. Even in the worst
>> case,
>> the block size is still mining-centralization-safe. The upper limit
>> may
>> increase linearly, if not exponentially, until we find a better
>> long-term
>> solution. (sort of a combination of BIP100 and 101, with different
>> parameters)
>
> My point is, a "soft cap" determined by miners clearly doesn't protect
> us from mining centralization: the "hard cap" does.
> Knowing that, and given that miners can currently set their own policy
> block size maximum, what does this "voting on a lower limit" achieve?
> What are the gains? Why are we "lucky" if they keep the lower one as
> low as possible?
Even if we could quantify the level of centralization, it is a continuum
and we must compromise between utility and centralization. Unless
BIP101/103 is adopted, adjusting the hard cap always require a hardfork.
For obvious technical and political reasons we can't have hardfork too
frequently. Therefore, we need to leave some leeway: the hard cap may be
a bit too high for today, but we are sure that technology will catch up
in the near future.
Assuming we have plenty amount of "benevolent" miners, they will keep
the block size low unless there is a real demand for larger block space.
This is different from setting an individual soft limit, as that will
lead to block size scarcity and therefore higher tx fee, which may be
good for all miners. And as we say "miners can always decrease the block
size with softfork or 51% attack", BIP100 materializes this possibility
in a much smoother way.
I say "lucky" because I wholeheartedly believe it is good to keep the
block as small as we really need. We can't do this by an equation so I
would prefer to leave the power to miners (and they always have this
power, anyway).
>
>> For the matter of "urgency", I agree with you that there is no actual
>> urgency AT THIS MOMENT. However, if a hardfork may take 5 years to
>> deploy
>> (as you suggested), we really have the urgency to make a decision now.
>
> Thank you for admitting it is not urgent!
> I suggested 5 years for the concrete hardfork in bip99 because it's
> clearly non-urgent and I wanted to be very conservative. I'm happy to
> reduce that to say, 1 year (specially given that the change is very
> simple to implement).
> For a simple block size change (like, say bip102) 1 year (maybe 6
> months + miner's confirmation) is probably more than enough as well.
> And we can always deploy an urgency hardfork if it is necessary.
>
>> Actually, the main point is not urgency but uncertainty. We have
>> debated for
>> 5 years. Why won't we have 5 more years of debate, plus 5 years of
>> deployment delay? Are we sticking to 1MB for 10 years? In that case
>> Bitcoin
>> Core must be abandoned by the economic majority and a Schism fork must
>> occur.
>
> Fortunately we haven't been discussing this for 5 years, I don't know
> where you get that from.
Jeff and Satoshi discussed this in 2010, although the flame throwing
debate did not start until 2013.
> A schism fork it's certainly always a possibility but I would only
> consider it after an urgency hardfork (once the issue becomes urgent)
> fails due to not being uncontroversial.
> Would you agree with me on that?
> What would be your criterion for considering an increase in block size
> urgent?
The problem is the definition of "urgency" itself is controversial. And
I believe an urgent hardfork should only be done as a bug fix, not
implementation of a new feature. Block size increase should be a planned
feature, as we don't want the tx fee raised to 10USD, before suddenly
dropping to 0.01USD with the hardfork.
I don't think it's urgent today because my free tx always get mined. I
don't know what is urgent and different people have different
definition, but in general I think that should be measured by tx fee in
USD. 0.001USD/byte may be intolerable for many people. (It's about
$0.0001/byte now, and $0.0005/byte when it was $1200/BTC). It's not
difficult to reach this level given the halving and potential bull
market is coming.
> Mine is: we should consider a block increase only when minimum market
> fees for transactions to be mined (currently zero satoshis) increase
> above a high fee (admittedly undefined, but certainly greater than
> zero).
As I argued above, it's already too late when things become really
urgent. That will lead to serious market disruption, and the uncertainty
could be very harmful to the development of the bitcoin economy.
> Even if it's "urgent", I think we should only increase the maximum if,
> at the same time, the new size can be considered safe
> mining-centralization-wise (unfortunately we don't have any metric to
> measure that nor enough tools to realistically simulate different
> sizes in different network topologies at the moment). But once we have
> them, the next discussion will be much simpler, so I don't see the
> need for block size maximum that changes over time (neither
> exponentially nor linearly).
>
> Would you agree with me that mining centralization should be the most
> important criterion when changing the block size maximum rule rather
> than the level of minimum fees?
As I said above, strictly limiting the block size may have little effect
on mining centralization (because block size at this level is not a
determining factor), while it may seriously suppress the utility.
I'm all for mining decentralization but block size is just not the right
way to improve the situation.
> If the community can't agree on this, I'm afraid there will be a
> schism hardfork eventually. Another possibility is that those who
> aren't concerned with mining centralization start their own altcoin
> (centralizedcoin? ), maybe a spinoff [
> https://bitcointalk.org/index.php?topic=563972.0 ] if they want to
> keep Bitcoin's utxo at the moment of the separation.
>
> But if the community agrees with this and just disagrees on the
> maximum block size consensus rule having any effect on mining
> centralization (like Gavin and I disagree), we should calm down and
> use scientific processes to find out what the relation between the two
> actually is (if there's any relation at all).
>
> Would you agree with me on this?
I agree with you, but the balance between centralization and utility is
also important. (and I believe the difference between 1MB and 8MB is
tolerable, at least I must keep my full node running at this level)
I also have an idea to have a "decentralizedcoin", with very small
blocks and everyone could mine with a CPU. That would be interesting if
it is backed by famous devs in this area and is not
yet-another-scamcoin.

2023-06-07 17:37:56

- reply

📅 Original date posted:2015-08-30
📝 Original message:Jorge Timón via bitcoin-dev 於 2015-08-29 16:41 寫到:
>
> I still don't see the point in having a lower moving size maximum.
> If 8 MB is mining-centralization-safe, let's move directly to 8 MB
> without adding this seemingly useless extra complexity.
> If it's not, mining voting on a lower moving maximum won't make it
> safer.
>
> Once we have more objective tools (centralization metrics, simulators,
> etc...) to determine whether or not a block size is
> mining-centralization-safe for a given point in time (looking at
> current centralization and current technology available), I don't see
> the problem with repeating the equivalent of bip102 periodically
> (every 2 years?) to adapt the size to better technology or lower
> mining centralization.
> It would be also helpful to have a tool to somehow measure "size
> increase urgency" (ie right now free transactions get mined and blocks
> aren't full or close to be full, I don't think the current general
> sense of urgency on this matter is justified).
>
> With all respect, I believe bip100 and this proposal are
> over-engineering; and bip101 and bip103 (pieter's) are
> overly-optimistic (in their exponential technological growth
> assumptions).
This is based on the assumption that miners would always like to use up
the last byte of the available block size. However, this is just not
true:
1. The 6 year blockchain history has shown that most miners have a soft
cap with their block size.
2. Chinese miners, controlling 60% of the network, rejected Gavin's
initial 20MB proposal and asked for 8MB:
http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size
3. BTCChina supports BIP100 and will vote for 2MB at the beginning, with
8MB as a mid-term goal:
https://vip.btcchina.com/page/noticetemplate?id=100.
BTCChina is controlling 12% of the network in the past month. If BIP100
uses the 20-percentile vote as the block size, it takes only 8% more
vote to keep the size at 2MB
For many reasons miners may want to have a smaller block size, which we
don't need to list them here. Although they can limit it by a softfork
or even 51% attack, it is a very violent process. Why don't we just
allow them to vote for a lower limit?
So I think the right way is to choose a mining-centralization-safe
limit, and let it free float within a range based on miner's vote. If we
are lucky enough to have some responsible miners, they will keep it as
low as possible, until the legitimate tx volume catches up. Even in the
worst case, the block size is still mining-centralization-safe. The
upper limit may increase linearly, if not exponentially, until we find a
better long-term solution. (sort of a combination of BIP100 and 101,
with different parameters)
--------
For the matter of "urgency", I agree with you that there is no actual
urgency AT THIS MOMENT. However, if a hardfork may take 5 years to
deploy (as you suggested), we really have the urgency to make a decision
now. Actually, the main point is not urgency but uncertainty. We have
debated for 5 years. Why won't we have 5 more years of debate, plus 5
years of deployment delay? Are we sticking to 1MB for 10 years? In that
case Bitcoin Core must be abandoned by the economic majority and a
Schism fork must occur.

2023-06-07 17:37:55

- reply

📅 Original date posted:2015-08-29
📝 Original message:I am quite skeptical about any pay-to-increase proposal because it is
difficult to predict the game dynamics and determine the right amount of
penalty. But anyway, here is my response to your revised proposal:
1. I agree with you that there should be a cap in the rate of change,
and also the maximum possible size. This is already part of BIP100
2. Requiring a higher difficulty is bad for everyone:
a) it increases the variance of the miner;
b) average confirmation time for all tx are increased. It may even
cause a feedback: many tx in mempool -> increase block size -> wait
longer for confirmation -> more tx in mempool;
c) difficulty of the next round will be decreased, leading to a greater
fluctuation in confirmation time.
Instead, you should require miners to burn their coinbase reward. This
is effectively same as higher difficulty but is good for everyone: a)
mining variance and confirmation time unchanged; b) all bitcoin holders
become relatively richer
If you don't want to burn any bitcoin, you may require the miner the
send to penalty to <840000 + current height> OP_CHECKLOCKTIMEVERIFY,
which will subsidize the mining when the block reward drops below 1 BTC
3. It is a better idea to allow mining of a bigger block immediately,
which reduces (but not eliminates) the problem of tragedy of the
commons. However, you can't use the blocksize as the vote. Mining an
empty block doesn't mean the miner wants to decrease the block size to
200 bytes. That will just encourage some miners to fill up a block with
garbage which does no good for anyone. Therefore, you need to look at
both the actual block size and the coinbase vote, and always take the
bigger value to determine the penalty and the max block size of next
round. If a miner includes nothing in the coinbase, it should be
consider as a vote for the current max block size.
Btc Drak via bitcoin-dev 於 2015-08-29 06:15 寫到:
> On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Mark and Jorge,
>
> I am very glad you have brought up this particular objection because
> it's something I thought about but was unclear if it was an opinion
> that would be shared by others. I chose to omit it from the proposal
> to see if it would come up during peer review.
>
> I feel that giving miners a blank cheque to increase blocksize, by any
> means, goes against a key design of bitcoin's security model. Full
> nodes keep miners honest by ensuring by validating their blocks. Under
> any voting-only scheme there is no way for full nodes to keep miners
> in cheque because miner have free reign to increase the blocksize.
>
> This problem can be solved by introducing a hard cap on blocksize. By
> introducing an upper limit miners now have the freedom to increase
> blocksize but only within defined parameters. Remember my proposal
> allows blocksize to increase and decrease in such a way that miners
> must collectively agree if they want the size to increase.
>
> I believe the idea of a hard upper limit has become rather politicised
> but is essential to the security model of bitcoin.
>
> With respect to the flexicap idea where miners can create a larger
> block by paying extra difficulty, I believe that proposal has a
> critical flaw because, as Gavin pointed out, it makes it very
> expensive (and risky) to include a few extra transactions. I believe
> it suffers from tragedy of the commons because there is no incentive
> for the mining community to reach consensus. Each and every block is
> going to be a gamble, "should we include a few extra transactions at
> the risk of losing the block?". Under my proposal miners can
> collectively agree to change the blocksize. Let's say they want a 10%
> increase, they can collude together to make that increase and once
> reached, it remains until they want to change it again. Yet, the upper
> hard limit keeps the ultimate control of the maximum block size
> squarely in the hands of full nodes.
>
> Whilst the exact number may be up for discussion, I would propose an
> initial upper limit of 8MB, so under my proposal the blocksize would
> be flexible between 1MB and 8MB.
>
> An alternative methodology to voting in the coinbase would be to
> change the vote to be the blocksize itself
>
> 1. miners pay extra difficulty to create a larger block.
> 2. every 2016 blocks the average or median of the last 2016 blocks is
> calculated and becomes the new maximum blocksize limit.
>
> This would retain incentive to collude to increase blocksize, as well
> as the property of costing to increase while being free to propose
> decrease.
>
> It would still require an upper blocksize limit in order for full
> nodes to retain control. Without an upper limit, any proposal is going
> to break the security model as full nodes give up some oversight
> control over miners.
>
> Another way of looking at these ideas is we're raising blocksize hard
> limit (to 8MB or whatever is decided), but making a soft of "softer"
> or inner limit part of consensus. Such a concept is not really
> departing from the current idea of a soft limit except to make it
> consensus enforced. Obviously it's not identical, but I think you can
> see the similarities.
>
> Does that make sense?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:37:02

- reply

📅 Original date posted:2015-08-20
📝 Original message:Peter Todd via bitcoin-dev 於 2015-08-19 01:50 寫到:
>
>
> 2) nVersion mask, with IsSuperMajority()
>
> In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would
> be masked away, prior to applying standard IsSuperMajority() logic:
>
> block.nVersion & ~0x20000007
>
> This means that CLTV/CSV/etc. miners running Bitcoin Core would create
> blocks with nVersion=8, 0b1000. From the perspective of the
> CLTV/CSV/etc. IsSuperMajority() test, XT/Not-Bitcoin-XT miners would
> be
> advertising blocks that do not trigger the soft-fork.
>
> For the perpose of soft-fork warnings, the highest known version can
> remain nVersion=8, which is triggered by both XT/Not-Bitcoin-XT blocks
> as well as a future nVersion bits implementation. Equally,
> XT/Not-Bitcoin-XT soft-fork warnings will be triggered, by having an
> unknown bit set.
>
> When nVersion bits is implemented by the Bitcoin protocol, the plan of
> setting the high bits to 0b001 still works. The three lowest bits will
> be unusable for some time, but will be eventually recoverable as
> XT/Not-Bitcoin-XT mining ceases.
>
> Equally, further IsSuperMajority() softforks can be accomplished with
> the same masking technique.
>
> This option does complicate the XT-coin protocol implementation in the
> future. But that's their problem, and anyway, the maintainers
> (Hearn/Andresen) has strenuously argued(5) against the use of
> soft-forks
> and/or appear to be in favor of a more centralized mandatory update
> schedule.(6)
>
If you are going to mask bits, would you consider to mask all bits
except the 4th bit? So other fork proposals may use other bits for
voting concurrently.
And as I understand, the masking is applied only during the voting
stage? After the softfork is fully enforced with 95% support, the
nVersion will be simply >=8, without any masking?

2023-06-07 17:36:45

- reply

📅 Original date posted:2015-08-19
📝 Original message:Jorge Timón 於 2015-08-19 05:24 寫到:
> On Tue, Aug 18, 2015 at 11:54 AM, jl2012 via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> As I understand, there is already a consensus among core dev that
>> block size
>> should/could be raised. The remaining questions are how, when, how
>> much, and
>> how fast. These are the questions for the coming Bitcoin Scalability
>> Workshops but immediate consensus in these issues are not guaranteed.
>>
>> Could we just stop the debate for a moment, and agree to a scheduled
>> experimental hardfork?
>>
>> Objectives (by order of importance):
>>
>> 1. The most important objective is to show the world that reaching
>> consensus
>> for a Bitcoin hardfork is possible. If we could have a successful one,
>> we
>> would have more in the future
>
> Apart from classifying all potential consensus rule changes and
> recommend a deployment path for each case, deploying an
> uncontroversial hardfork is one of the main goals of bip99:
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009837.html
>
>> 2. With a slight increase in block size, to collect data for future
>> hardforks
>
> The uncontroversial hardfork doesn't need to change the maximum block
> size: there's plenty of hardfork proposals out there, some of them
> very well tested (like the proposed hardfork in bip99).
You misunderstand my intention. The experiment is not about a random
hardfork. It's about a block size increase hardfork. The data will help
us to design further hardfork on block size.
To make it less controversial, the size must not be too big.
To allow a meaningful experiment, the size must not be too small.
Technically we could make it 1.01MB but that defeats all objectives I
listed and there is no point to do it.
That's why I suggest 1.5MB.
>> 1. Today, we all agree that some kind of block size hardfork will
>> happen on
>> t1=*1 June 2016*
>
> I disagree with this. I think it should be schedule at least a year
> after it is deployed in the newest versions.
> Maybe there's something special about June 2016 that I'm missing.
I hope the fork could be done before the halving, which (hopefully) we
may have a new bitcoin rush
There was only 2 months for the BIP50 hardfork. You may argue that's a
"bug fix" but practically there is no difference: people not fixing the
bug in 2 months was forked off. Four months of grace period (Feb to June
2016) is already a double of that.
Also, if we could have zero grace period for softfork, why must we have
a ultra-long period for hardfork? (Unless you also agree to have an
1-year grace period for softfork. I don't buy the "softfork is safer
than hardfork" theory. The recent BIP66 fork has clearly shown why it is
wrong: non-upgrading full nodes are not full nodes)
The problem is many people won't update until they must do so. So 4
months or 1 year make little difference

2023-06-07 17:36:43

- reply

📅 Original date posted:2015-08-19
📝 Original message:odinn via bitcoin-dev 於 2015-08-19 07:25 寫到:
> The big problem is
>> BIP101 being deployed as a Schism hardfork.
>
> This is certainly a problem.
>
No, BitcoinXT won't become a Schism hardfork, or may be just for a few
days, at most.
There is one, and only one scenario that BitcoinXT will win: it is
supported by major exchanges, merchants, and investors, and they request
miners to support it. When BIP101 is activated, these exchanges will
refuse to accept or exchange tokens from the old chain. Miners in the
old chain can't sell their newly generated coins and can't pay the
electricity bill. They will soon realize that they are mining fool's
gold and will be forced to switch to the new chain or sell their ASIC.
The old chain will be abandoned and has no hope to revive without a
hardfork to decrease the difficulty. The dust will settle in days if not
hours.
Will the adoption of BitcoinXT lead by miners? No, it won't. Actually,
Chinese miners who control 60% of the network has already said that they
would not adopt XT. So they must not be the leader in this revolution.
Again, miners need to make sure they could sell their bitcoin in a good
price, and that's not possible without support of exchanges and
investors.
What about that Not-Bitcoin-XT? The creator of the spoof client may stay
anonymous, but the miners cannot. 95% of the blocks come from known
entities and they have to be responsible to their actions. And again,
they have real money in stake. If bitcoin is destroyed, their ASIC
serves at best as very inefficient heaters.
So Bitcoin-XT is basically in a win-all-or-lose-all position. It all
relies on one condition: the support of major exchanges, merchants, and
investors. Their consensus is what really matters. With their consensus,
that could not be a Schism hardfork. Without their consensus, nothing
will happen.
-------
Or let me analyse in a different angle. BitcoinXT is in no way similar
to your examples of Schism hardforks. All of your examples, "ASIC-reset
hardfork", "Anti-Block-creator hardfork", and "Anti-cabal hardfork", are
hostile to the current biggest miners and will destroy their investment.
These miners have no choice but stick to the original protocol so 2
chains MUST coexist. However, BIP101 has no such effect at all and
miners may freely switch between the forks. They will always choose the
most valuable fork, so only one fork will survive.

2023-06-07 17:36:38

- reply

📅 Original date posted:2015-08-18
📝 Original message:As I understand, there is already a consensus among core dev that block
size should/could be raised. The remaining questions are how, when, how
much, and how fast. These are the questions for the coming Bitcoin
Scalability Workshops but immediate consensus in these issues are not
guaranteed.
Could we just stop the debate for a moment, and agree to a scheduled
experimental hardfork?
Objectives (by order of importance):
1. The most important objective is to show the world that reaching
consensus for a Bitcoin hardfork is possible. If we could have a
successful one, we would have more in the future
2. With a slight increase in block size, to collect data for future
hardforks
3. To slightly relieve the pressure of full block, without minimal
adverse effects on network performance
With the objectives 1 and 2 in mind, this is to NOT intended to be a
kick-the-can-down-the-road solution. The third objective is more like a
side effect of this experiment.
Proposal (parameters in ** are my recommendations but negotiable):
1. Today, we all agree that some kind of block size hardfork will happen
on t1=*1 June 2016*
2. If no other consensus could be reached before t2=*1 Feb 2016*, we
will adopt the backup plan
3. The backup plan is: t3=*30 days* after m=*80%* of miner approval, but
not before t1=*1 June 2016*, the block size is increased to s=*1.5MB*
4. If the backup plan is adopted, we all agree that a better solution
should be found before t4=*31 Dec 2017*.
Rationale:
t1 = 1 June 2016 is chosen to make sure everyone have enough time to
prepare for a hardfork. Although we do not know what actually will
happen but we know something must happen around that moment.
t2 = 1 Feb 2016 is chosen to allow 5 more months of negotiations (and 2
months after the workshops). If it is successful, we don't need to
activate the backup plan
t3 = 30 days is chosen to make sure every full nodes have enough time to
upgrade after the actual hardfork date is confirmed
t4 = 31 Dec 2017 is chosen, with 1.5 year of data and further debate,
hopefully we would find a better solution. It is important to
acknowledge that the backup plan is not a final solution
m = 80%: We don't want a very small portion of miners to have the power
to veto a hardfork, while it is important to make sure the new fork is
secured by enough mining power. 80% is just a compromise.
s = 1.5MB. As the 1MB cap was set 5 years ago, there is no doubt that
all types of technology has since improved by >50%. I don't mind making
it a bit smaller but in that case not much valuable data could be
gathered and the second objective of this experiment may not be
archived.
--------------------
If the community as a whole could agree with this experimental hardfork,
we could announce the plan on bitcoin.org and start coding of the patch
immediately. At the same time, exploration for a better solution
continues. If no further consensus could be reached, a new version of
Bitcoin Core with the patch will be released on or before 1 Feb 2016 and
everyone will be asked to upgrade immediately.

2023-06-07 17:36:37

- reply

📅 Original date posted:2015-08-28
📝 Original message:I have an ugly solution to this problem, with minimal change to the
current softfork logic, and still allows all features described in
sipa's Version bits BIP
1. xVersion = nVersion AND 0b10000000000000000000000000011000
2. miners supporting BIP65 will set xVersion = 8 or greater
3. If 750 of the last 1000 blocks are xVersion >= 8, reject invalid
xVersion 8 (or greater) blocks
4. If 950 of the last 1000 blocks are xVersion >= 8, reject all blocks
with xVersion < 8
So the logic is exactly the same as BIP66, with the AND masking in step
1. After the BIP65 softfork is implied, xVersion may take only one of
the following values: 8, 16, 24
This is basically moving the "high bits" in sipa's proposal to the
middle of the nVersion field. After the BIP65 softfork, this will still
leave 29 available bits for parallel soft forks, just in different
position.
This is ugly, but I believe this is the easiest solution
Ref: https://gist.github.com/sipa/bf69659f43e763540550
Peter Todd via bitcoin-dev 於 2015-08-27 19:19 寫到:
> On Thu, Aug 27, 2015 at 11:08:32PM +0100, Btc Drak wrote:
>> This BIP was assigned number 113.
>>
>> I have updated the text accordingly and added credits to Gregory
>> Maxwell.
>>
>> Please see the changes in the pull request:
>> https://github.com/bitcoin/bips/pull/182
>
> On Thu, Aug 27, 2015 at 11:11:10PM +0100, Btc Drak via bitcoin-dev
> wrote:
>> I have changed BIPS 112 and 113 to reflect this amended deployment
>> strategy. I'm beginning to think the issues created by Bitcoin XT are
>> so serious it probably deserves converting OPs text into an
>> informational BIP.
>
> I thought we had decided that the masking thing doesn't work as
> intended?
>
> To recap, XT nodes are producing blocks with nVersion=0b001...111
>
> You're suggesting that we apply a mask of ~0b001...111 then trigger the
> soft-fork on nVersion >= 0b0...100 == 4, with miners producing blocks
> with
> nVersion=0b0...1000
>
> That will work, but it still uses up a version bit. The reason why is
> blocks with nVersion=0b001...000 - the intended deployment of the
> nVersion bits proposal - will be rejected by the nVersion >= 4 rule,
> hard-forking them off the network. In short, we have in fact "burnt" a
> version bit unnecessarily.
>
> If you're going to accept hard-forking some people off the network, why
> not just go with my stateless nVersion bits w/ time-expiration proposal
> instead? The only case where it leads to a hard-fork is if a soft-fork
> has been rejected by the time the upgrade deadline is reached. It's
> easy
> to set this multiple years into the future, so I think in practice it
> won't be a major issue for non-controversial soft-forks.
>
> Equally, spending the time to implement the original stateful nVersion
> bits proposal is possible as well, though higher risk due to the extra
> complexity of tracking soft-fork state.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:36:15

- reply

📅 Original date posted:2015-08-17
📝 Original message:The traffic between the pool server and individual hashers is far busier
than 50kB/30s. If their bandwidth is so limited, hashers would have
switched to other pools already.
All these data may prove is they have very bad mining codes. For
example, their hashers may not be required to update the transaction
list regularly. I don't think they are struggling. They are just too
lazy or think that's too risky to improve their code. After all, they
are generating half million USD per day and a few seconds of downtime
would hurt.
By the way, vast majority of the full blocks (>0.99MB) on the blockchain
are generated by Chinese pools.
Luv Khemani via bitcoin-dev 於 2015-08-17 04:42 寫到:
> Hi all,
>
> I previously mentioned in a post that i believe that technically
> nodes are capable of handling blocks an order of magnitude larger than
> the current blocksize limit, the only missing thing was an incentive
> to run them. I have been monitoring the blockchain for the past couple
> of weeks and am seeing that even miners who have all the incentives
> are for whatever reason struggling to download and validate much
> smaller blocks.
>
> The data actually paints a very grim picture of the current
> bandwidth/validating capacity of the global mining network.
>
> See the following empty blocks mined despite a non-trivial elapsed
> time from the previous block just from the past couple of days alone
> (Data from insight.bitpay.com):
>
> EmptyBlock /Time since previous block/ Size of previous
> block(bytes)/Mined by
> ====================================================370165 29s 720784
> Antpool
> 370160 31s 50129 BTCChinaPool
> 370076 49s 469988 F2Pool
> 370059 34s 110994 Antpool
> 370057 73s 131603 Antpool
>
> We have preceding blocks as small as 50KB with 30s passing and the
> miner continues to mine empty blocks via SPV mining.
> The most glaring case is Block 370057 where despite 73s elapsing and
> the preceding block being a mere 131KB, the miner is unable to
> download/validate fast enough to include transactions in his block.
> Unless ofcourse the miner is mining empty blocks on purpose, which
> does not make sense as all of these pools do mine blocks with
> transactions when the elapsed time is greater.
>
> This is a cause for great concern, because if miners are SPV mining
> for a whole minute for <750KB blocks, at 8MB blocks, the network will
> just fall apart as a significant portion of the hashing power SPV
> mines throughout. All a single malicious miner has to do is mine an
> invalid block on purpose, let these pools SPV mine on top of them
> while it mines a valid block free of their competition. Yes, these
> pools deserve to lose money in that event, but the impact of reorgs
> and many block orphans for anyone not running a full node could be
> disastrous, especially more so in the XT world where Mike wants
> everyone to be running SPV nodes. I simply don't see the XT fork
> having any chance of surviving if SPV nodes are unreliable.
>
> And if these pools go out of business, it will lead to even more
> mining centralization which is already too centralized today.
>
> Can anyone representing these pools comment on why this is happening?
> Are these pools on Matt's relay network?
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:36:04

- reply

📅 Original date posted:2015-08-17
📝 Original message:Thanks to mining centralization, such attempts won't be successful.
Asking mining pools to mine spoofing blocks in their real name is even
harder than asking them to run the real BitcoinXT
Node count is always manipulable, there is nothing new. People running
this will only be interpreted as XT-supporters.
Julie via bitcoin-dev 於 2015-08-16 18:34 寫到:
> Announcing Not-BitcoinXT
>
> https://github.com/xtbit/notbitcoinxt#not-bitcoin-xt
>
>
>
>
> -------------------------------------------------
>
> ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out
> of the NSA's hands!
> $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No
> bandwidth quotas!
> Commercial and Bulk Mail Options!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:35:37

- reply

📅 Original date posted:2015-08-15
📝 Original message:Sign with the key 5EC948A1 or shut up, you scammer
Satoshi Nakamoto via bitcoin-dev 於 2015-08-15 13:43 寫到:
> I have been following the recent block size debates through the
> mailing list. I had hoped the debate would resolve and that a fork
> proposal would achieve widespread consensus. However with the formal
> release of Bitcoin XT 0.11A, this looks unlikely to happen, and so I
> am forced to share my concerns about this very dangerous fork.
>
> The developers of this pretender-Bitcoin claim to be following my
> original vision, but nothing could be further from the truth. When I
> designed Bitcoin, I designed it in such a way as to make future
> modifications to the consensus rules difficult without near unanimous
> agreement. Bitcoin was designed to be protected from the influence of
> charismatic leaders, even if their name is Gavin Andresen, Barack
> Obama, or Satoshi Nakamoto. Nearly everyone has to agree on a change,
> and they have to do it without being forced or pressured into it. By
> doing a fork in this way, these developers are violating the "original
> vision" they claim to honour.
>
> They use my old writings to make claims about what Bitcoin was
> supposed to be. However I acknowledge that a lot has changed since
> that time, and new knowledge has been gained that contradicts some of
> my early opinions. For example I didn't anticipate pooled mining and
> its effects on the security of the network. Making Bitcoin a
> competitive monetary system while also preserving its security
> properties is not a trivial problem, and we should take more time to
> come up with a robust solution. I suspect we need a better incentive
> for users to run nodes instead of relying solely on altruism.
>
> If two developers can fork Bitcoin and succeed in redefining what
> "Bitcoin" is, in the face of widespread technical criticism and
> through the use of populist tactics, then I will have no choice but to
> declare Bitcoin a failed project. Bitcoin was meant to be both
> technically and socially robust. This present situation has been very
> disappointing to watch unfold.
>
> Satoshi Nakamoto
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:35:02

- reply

📅 Original date posted:2015-08-27
📝 Original message:Rusty Russell 於 2015-08-26 23:08 寫到:
> - We should immediately deploy an IsStandard() rule which insists that
> nSequence is 0xFFFFFFFF or 0, so nobody screws themselves when we
> soft fork and they had random junk in there.
This is not needed because BIP68 is not active for version 1 tx. No
existing wallet would be affected.
>
> Aside: I'd also like to have nLockTime apply even if nSequence !=
> 0xFFFFFFFF (another mistake I made). So I'd like an IsStandard() rule
> to say it nLockTime be 0 if an nSequence != 0xFFFFFFFF. Would that
> screw anyone currently?
Do you mean "have nLockTime apply even if nSequence = 0xFFFFFFFF"? This
is a softfork. Should we do this together with BIP65, BIP68 and BIP112?
> Thanks,
> Rusty.

2023-06-07 17:35:01

- reply

📅 Original date posted:2015-08-24
📝 Original message:Your proposal also permanently burns a sequence bit. It depends on how
we value a nSequence bit and a nVersion bit. I think there is a
trade-off here:
1. nSequence is signed by each TxIn individually, while all TxIns must
share the same nVersion
2. If nVersion is used to indicate the meaning of nSequence (as I
suggested):
Pros:
It saves a nSequence bit and allows more space for redefining the
nSequence
Cons:
It burns a nVersion bit.
All TxIns in a tx must share the same meaning for their nSequence
3. If nSequence is used to indicate the meaning of itself (as you
suggested):
Pros:
It saves a nVersion bit
Different TxIn may have different meaning with their nSequence
Cons:
It burns a nSequence bit, thus less space for extension
I don't think there is a perfect choice. However, I still prefer my
proposal because:
1. nSequence is signed by each TxIn individually and could be more
interesting than nVersion.
2. If nVersion is expected to be a monotonic number, 2 bytes = 65536
versions is enough for 65 millenniums if it ticks once per year. 4 bytes
is an overkill. Why don't we spend a bit if there is a good reason? Most
softforks (e.g. OP_CLTV, OP_CSV, BIP66) are not optional. These kind of
optional new functions would not be common and should never use up the
version bits. (or, could you suggest a better use of the tx version
bits?)
Mark Friedenbach 於 2015-08-23 22:54 寫到:
> Sorry this was meant for the list:
>
> There are only 32 bits in the version field. If you're going to spend
> a bit for perpetuity to indicate whether or not a feature is active,
> you'd better have a good reason to make that feature optional.
>
> I haven't seen a compelling use case for having BIP 68 be optional in
> that way. As you note, BIP 68 semantics is already optional by
> toggling the most significant bit, and that doesn't permanently burn a
> version bit.

2023-06-07 17:35:00

- reply

📅 Original date posted:2015-08-23
📝 Original message:Gregory Maxwell via bitcoin-dev 於 2015-08-23 21:01 寫到:
>
> Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
> discussion has any thought been given to represent one block with more
> than one increment? This would leave additional space for future
> signaling, or allow, for example, higher resolution numbers for a
> sharechain commitement.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
I think this comment is more related to BIP68 instead of OP_CSV? Without
further complicating the BIP68, I believe the best way to leave room for
improvement is to spend a bit in tx nVersion to indicate the activation
of BIP68. I have raised this issue before with
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010043.html
However, it seems Mark isn't in favor of my proposal
The idea is not to permanently change the meaning of nSequence.
Actually, BIP68 is "only enforced if the most significant bit of the
sequence number field is set." So BIP68 is optional, anyway. All I
suggest is to move the flag from nSequence to nVersion. However, this
will leave much bigger room for using nSequence for other purpose in the
future.
AFAIK, nSequence is the only user definable and signed element in TxIn.
There could be more interesting use of this field and we should not
change its meaning permanently. (e.g. if nSequence had 8 bytes instead
of 4 bytes, it could be used to indicate the value of the input to fix
this problem: https://bitcointalk.org/index.php?topic=181734.0 )

2023-06-07 17:34:28

- reply

📅 Original date posted:2015-08-08
📝 Original message:I think I have explained my motivation but let me try to make it
clearer.
For example, BIP62 says "scriptPubKey evaluation will be required to
result in a single non-zero value". If we had BIP62 before BIP16, P2SH
could not be done in the current form because BIP16 leaves more than one
element on the stake for non-upgrading nodes. BIP17 also violates BIP62.
BIP68 is "only enforced if the most significant bit of the sequence
number field is set.", so it is optional, anyway. All I do is to move
the flag from sequence number to version number.
The blocksize debate shows how a permanent softfork may cause trouble
later. We need to be very careful when doing further softforks, making
sure we will have enough flexibility for further development.
Mark Friedenbach 於 2015-08-08 14:56 寫到:
> It is not a bug that you are unable to selectively choose these
> features with higher version numbers. The version selection is in
> there at all because there is a possibility that there exists already
> signed transactions which would violate these new rules. We wouldn't
> want these transactions to become unspendable. However moving forward
> there is no reason to selectively pick and choose which of these new
> consensus rules you want to apply your transaction.
> On Aug 8, 2015 11:51 AM, "jl2012 via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> BIP68 rules and some of the BIP62 rules are applied only if the tx
>> version is >=2 and >=3 respectively. Therefore, it is not possible
>> to create a tx which follows BIP62 but not BIP68. If we introduce v4
>> tx later, BIP62 and BIP68 will all become mandatory.
>>
>> Some rules, e.g. "scriptPubKey evaluation will be required to
>> result in a single non-zero value" in BIP62, will cause trouble when
>> we try to introduce a new script system with softfork.
>>
>> I suggest to divide the tx version field into 2 parts: the higher 4
>> bits and lower 28 bits.
>>
>> BIP62 is active for a tx if its highest bits are 0000, and the
>> second lowest bit is 1.
>>
>> BIP68 is active for a tx if its highest bits are 0000, and the
>> third lowest bit is 1.
>>
>> So it will be easier for us to re-purpose the nSequence, or to take
>> advantage of malleability in the future. If this is adopted, the
>> nSequence high bit requirement in BIP68 becomes unnecessary as we
>> could easily switch it off.
>>
>> The low bits will allow 28 independent BIPs and should be ample for
>> many years. When they are exhausted, we can switch the high bits to
>> a different number (1-15) and redefine the meaning of low bits. By
>> that time, some of the 28 BIPs might have become obsoleted or could
>> be merged.
>>
>> (I'm not sure if there are other draft BIPs with similar
>> interpretation of tx version but the comments above should also
>> apply to them)
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>
>
> Links:
> ------
> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:34:27

- reply

📅 Original date posted:2015-08-08
📝 Original message:BIP68 rules and some of the BIP62 rules are applied only if the tx
version is >=2 and >=3 respectively. Therefore, it is not possible to
create a tx which follows BIP62 but not BIP68. If we introduce v4 tx
later, BIP62 and BIP68 will all become mandatory.
Some rules, e.g. "scriptPubKey evaluation will be required to result in
a single non-zero value" in BIP62, will cause trouble when we try to
introduce a new script system with softfork.
I suggest to divide the tx version field into 2 parts: the higher 4 bits
and lower 28 bits.
BIP62 is active for a tx if its highest bits are 0000, and the second
lowest bit is 1.
BIP68 is active for a tx if its highest bits are 0000, and the third
lowest bit is 1.
So it will be easier for us to re-purpose the nSequence, or to take
advantage of malleability in the future. If this is adopted, the
nSequence high bit requirement in BIP68 becomes unnecessary as we could
easily switch it off.
The low bits will allow 28 independent BIPs and should be ample for many
years. When they are exhausted, we can switch the high bits to a
different number (1-15) and redefine the meaning of low bits. By that
time, some of the 28 BIPs might have become obsoleted or could be
merged.
(I'm not sure if there are other draft BIPs with similar interpretation
of tx version but the comments above should also apply to them)

2023-06-07 17:33:36

- reply

📅 Original date posted:2015-08-07
📝 Original message:Pieter Wuille via bitcoin-dev 於 2015-08-07 12:28 寫到:
> On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen
> <gavinandresen at gmail.com> wrote:
>
>> On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille
>> <pieter.wuille at gmail.com> wrote:
>>
>>> I guess my question (and perhaps that's what Jorge is after): do
>>> you feel that blocks should be increased in response to (or for
>>> fear of) such a scenario.
>>
>> I think there are multiple reasons to raise the maximum block size,
>> and yes, fear of Bad Things Happening as we run up against the 1MB
>> limit is one of the reasons.
>>
>> I take the opinion of smart engineers who actually do resource
>> planning and have seen what happens when networks run out of
>> capacity very seriously.
>
> This is a fundamental disagreement then. I believe that the demand is
> infinite if you don't set a fee minimum (and I don't think we should),
> and it just takes time for the market to find a way to fill whatever
> is available - the rest goes into off-chain systems anyway. You will
> run out of capacity at any size, and acting out of fear of that
> reality does not improve the system. Whatever size blocks are actually
> produced, I believe the result will either be something people
> consider too small to be competitive ("you mean Bitcoin can only do 24
> transactions per second?" sounds almost the same as "you mean Bitcoin
> can only do 3 transactions per second?"), or something that is very
> centralized in practice, and likely both.
What if we reduce the block size to 0.125MB? That will allow 0.375tx/s.
If 3->24 sounds "almost the same", 3->0.375 also sounds almost the same.
We will have 50000 full nodes, instead of 5000, since it is so
affordable to run a full node.
If 0.125MB sounds too extreme, what about 0.5/0.7/0.9MB? Are we going to
have more full nodes?
No, I'm not trolling. I really want someone to tell me why we
should/shouldn't reduce the block size. Are we going to have more or
less full nodes if we reduce the block size?

2023-06-07 17:33:29

- reply

📅 Original date posted:2015-08-07
📝 Original message:It won't work as you thought. If a miner has 95% of hashing power, he
would have 95% of chance to find the next block and collect the penalty.
In long term, he only needs to pay 5% penalty. It's clearly biased
against small miners.
Instead, you should require the miners to burn the penalty. Whether this
is a good idea is another issue.
Wes Green via bitcoin-dev 於 2015-08-06 19:52 寫到:
> Bitcoin is built on game theory. Somehow we seem to have forgotten
> that and are trying to fix our "block size issue" with magic numbers,
> projected percentage growth of bandwidth speeds, time limits, etc...
> There are instances where these types of solutions make sense, but
> this doesn't appear to be one of them. Lets return to game theory.
>
> Proposal: Allow any miner to, up to, double the block size at any
> given time - but penalize them. Using the normal block reward,
> whatever percentage increase the miner makes over the previous limit
> is taken from both the normal reward and fees. The left over is
> rewarded to the next miner that finds a block.
>
> If blocks stay smaller for an extended period of time, it goes back
> down to the previous limit/ x amount decrease/% decrease (up for
> debate)
>
> Why would this work?: Miners only have incentive to do raise the limit
> when they feel there is organic growth in the network. Spam attacks,
> block bloat etc would have to be dealt with as it is currently. There
> is no incentive to raise the size for spam because it will subside and
> the penalty will have been for nothing when the attack ends and block
> size goes back down.
>
> I believe it would have the nice side effect of forcing miners to hold
> the whole block chain. I believe SPV does not allow you to see all the
> transactions in a block and be able to calculate if you should be
> adding more to your reward transaction if the last miner made the
> blocks bigger. Because of this, the miners would also have an eye on
> blockchain size and wont want it getting huge too fast (outsize of
> Moore's law of Nielsen's Law). Adding to the gamification.
>
> This system would encourage block size growth due to organic growth
> and the penalty would encourage it to be slow as to still keep reward
> high and preserve ROE.
>
> What this would look like: The miners start seeing what looks like
> natural network growth, and make the decision (or program an
> algorithm, the beauty is it leaves the "how" up to the miners) to
> increase the blocksize. They think that, in the long run, having
> larger blocks will increase their revenue and its worth taking the hit
> now for more fees later. They increase the size to 1.25 MB. As a
> result, they reward would be 18.75 (75%). The miner fees were .5BTC.
> The miner fees are also reduced to .375BTC. Everyone who receives that
> block can easily calculate 1) if the previous miner gave themselves
> the proper reward 2) what the next reward should be if they win it.
> Miners now start building blocks with a 31.25 reward transaction and
> miner fee + .125.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:33:21

- reply

📅 Original date posted:2015-08-07
📝 Original message:Your proposal fails here:
"If the block defined in the Guarantee Message has not been shown"
What is blockchain? You can see blockchain as a mechanism to prove
something has been shown by certain order. Therefore, it is not possible
to prove something has not been shown with blockchain.
Your proposal works only with a centralized trusted party.
Arnoud Kouwenhoven - Pukaki Corp via bitcoin-dev 於 2015-08-05 15:07 寫到:
> Hello all.
>
> We’d like to share an idea we have to dramatically increase the
> bitcoin block propagation speed after a new block has been mined for
> the first time.

2023-06-07 17:32:58

- reply

📅 Original date posted:2015-08-04
📝 Original message:As I mentioned, the candidate proposals must go through usual peer
review process, which includes proper testing, I assume.
Scaling down is always possible with softforks, or miners will simply
produce smaller blocks. BIP100 has a scaling down mechanism but it still
requires miners to vote so it doesn't really make much difference
But anyway, this is off-topic, as candidate proposals may include
mechanism for scaling down.
Venzen Khaosan 於 2015-08-04 05:23 寫到:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> It is not scientific or sensible to go from proposal stage straight to
> voting and then implementation stage.
>
> The proposals you have diligently gathered, summarized and presented
> in your document must go through testing, and scenario simulation with
> published results, in order for objective evaluation to be made
> possible.
>
> For that matter, even "running up against a capacity limit" has not
> been simulated or tested. Additionally, (and looking the other way)
> there is a lack of provision for scaling DOWN in the current proposals
> - - hard to envision, yes - but what goes up will eventually come down.
> A global credit contraction is not unlikely, nor is natural disaster,
> and these scenarios have implications for usage, scale, degree of
> decentralization and security.
>
> CS is science, there is no reason for this generation not to apply
> rigorous Computer Science to Bitcoin.
>
> Venzen
>
>
> On 08/04/2015 02:50 PM, jl2012 via bitcoin-dev wrote:
>> As now we have some concrete proposals
>> (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html),
>>
>>
> I think we should wrap up the endless debate with voting by different
>> stakeholder groups.
>>
>> --------------------------------- Candidate proposals
>>
>> Candidate proposals must be complete BIPs with reference
>> implementation which are ready to merge immediately. They must
>> first go through the usual peer review process and get approved by
>> the developers in a technical standpoint, without political or
>> philosophical considerations. Any fine tune of a candidate proposal
>> may not become an independent candidate, unless it introduces some
>> “real” difference. “No change” is also one of the voting options.
>> --------------------------------- Voter groups
>>
>> There will be several voter groups and their votes will be counted
>> independently. (The time frames mentioned below are just for
>> example.)
>>
>> Miners: miners of blocks with timestamp between 1 to 30 Sept 2015
>> are eligible to vote. One block one vote. Miners will cast their
>> votes by signing with the bitcoin address in coinbase. If there are
>> multiple coinbase outputs, the vote is discounted by output value /
>> total coinbase output value. Many well-known pools are reusing
>> addresses and they may not need to digitally sign their votes. In
>> case there is any dispute, the digitally signed vote will be
>> counted.
>>
>> Bitcoin holders: People with bitcoin in the UTXO at block 372500
>> (around early September) are eligible to vote. The total “balance”
>> of each scriptPubKey is calculated and this is the weight of the
>> vote. People will cast their votes by digital signature. Special
>> output types: Multi-sig: vote must be signed according to the
>> setting of the multi-sig. P2SH: the serialized script must be
>> provided Publicly known private key: not eligible to vote
>> Non-standard script according to latest Bitcoin Core rules: not
>> eligible to vote in general. May be judged case-by-case
>>
>> Developers: People with certain amount of contribution in the past
>> year in Bitcoin Core or other open sources wallet / alternative
>> implementations. One person one vote.
>>
>> Exchanges: Centralized exchanges listed on Coindesk Bitcoin Index,
>> Winkdex, or NYSE Bitcoin index, with 30 days volume >100,000BTC
>> are invited. This includes Bitfinex, BTC China, BitStamp, BTC-E,
>> itBit, OKCoin, Huobi, Coinbase. Exchanges operated for at least 1
>> year with 100,000BTC 30-day volume may also apply to be a voter in
>> this category. One exchange one vote.
>>
>> Merchants and service providers: This category includes all
>> bitcoin accepting business that is not centralized fiat-currency
>> exchange, e.g. virtual or physical stores, gambling sites, online
>> wallet service, payment processors like Bitpay, decentralized
>> exchange like Localbitcoin, ETF operators like Secondmarket Bitcoin
>> Investment Trust. They must directly process bitcoin without
>> relying on third party. They should process at least 100BTC in the
>> last 30-days. One merchant one vote.
>>
>> Full nodes operators: People operating full nodes for at least 168
>> hours (1 week) in July 2015 are eligible to vote, determined by the
>> log of Bitnodes. Time is set in the past to avoid manipulation. One
>> IP address one vote. Vote must be sent from the node’s IP address.
>>
>> -------------------- Voting system
>>
>> Single transferable vote is applied.
>> (https://en.wikipedia.org/wiki/Single_transferable_vote). Voters
>> are required to rank their preference with “1”, “2”, “3”, etc, or
>> use “N” to indicate rejection of a candidate. Vote counting starts
>> with every voter’s first choice. The candidate with fewest votes is
>> eliminated and those votes are transferred according to their
>> second choice. This process repeats until only one candidate is
>> left, which is the most popular candidate. The result is presented
>> as the approval rate: final votes for the most popular candidate /
>> all valid votes
>>
>> After the most popular candidate is determined, the whole counting
>> process is repeated by eliminating this candidate, which will find
>> the approval rate for the second most popular candidate. The
>> process repeats until all proposals are ranked with the approval
>> rate calculated.
>>
>> -------------------- Interpretation of results:
>>
>> It is possible that a candidate with lower ranking to have higher
>> approval rate. However, ranking is more important than the
>> approval rate, unless the difference in approval rate is really
>> huge. 90% support would be excellent; 70% is good; 50% is marginal;
>> <50% is failed.
>>
>> -------------------- Technical issues:
>>
>> Voting by the miners, developers, exchanges, and merchants are
>> probably the easiest. We need a trusted person to verify the
>> voters’ identity by email, website, or digital signature. The
>> trusted person will collect votes and publish the named votes so
>> anyone could verify the results.
>>
>> For full nodes, we need a trusted person to setup a website as an
>> interface to vote. The votes with IP address will be published.
>>
>> For bitcoin holders, the workload could be very high and we may
>> need some automatic system to collect and count the votes. If
>> people are worrying about reduced security due to exposed raw
>> public key, they should move their bitcoin to a new address before
>> voting.
>>
>> Double voting: people are generally not allowed to change their
>> mind after voting, especially for anonymous voters like bitcoin
>> holders and solo miners. A double voting attempt from these classes
>> will invalidate all related votes.
>>
>> Multiple identity: People may have multiple roles in the Bitcoin
>> ecology. I believe they should be allowed to vote in all
>> applicable categories since they are contributing more than other
>> people.
>>
>> _______________________________________________ bitcoin-dev mailing
>> list bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVwISfAAoJEGwAhlQc8H1mygAH/jxe3C5RjPlsSKfIg+CikEwi
> kSttrZKr45s6EzayUqyBjBensgsgQCYKo3RLUq8lSpeJdZSmfu4qis09iZVJmKNX
> klA/CTuiHTE8jGgwjAHNeeAI/ZQSFOYictzk4OVTSQWoMuB8Wq6S+QXCiUbulOGH
> E/vHQz25ZNPX0+Z1Ypx26kSglBNzWJT1cdtyAvd3SDOTMuRVcH9y4aECSB+399Jt
> BT2pBOYCJjrXfuU0lh26yph08UyIKSoToCJ4jxEtBzf4COYppsO0dzHeboYkwLMo
> +ZuBhz5Bv9Fy5d6AcQtCUjBJE0dZvyAjf7Zc3U9X5ZXe5sAx/zC36O307YtneHI=
> =f/pR
> -----END PGP SIGNATURE-----

2023-06-07 17:32:55

- reply

📅 Original date posted:2015-08-04
📝 Original message:> Bitcoin's consensus rules are a consensus system
What is your definition of "consensus"? Do you mean 100% agreement?
Without a vote how do you know there is 100% (or whatever percentage)
agreement?
> Find a solution that everyone agrees on, or don't.
Who are the "everyone"?
Pieter Wuille 於 2015-08-04 05:03 寫到:
> I would like to withdraw my proposal from your self-appointed vote.
>
> If you want to let a majority decide about economic policy of a
> currency, I suggest fiat currencies. They have been using this
> approach for quite a while, I hear.
>
> Bitcoin's consensus rules are a consensus system, not a democracy.
> Find a solution that everyone agrees on, or don't.
> On Aug 4, 2015 9:51 AM, "jl2012 via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> As now we have some concrete proposals
>>
> (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html
>> [1]), I think we should wrap up the endless debate with voting by
>> different stakeholder groups.
>>
>> ---------------------------------
>> Candidate proposals
>>
>> Candidate proposals must be complete BIPs with reference
>> implementation which are ready to merge immediately. They must first
>> go through the usual peer review process and get approved by the
>> developers in a technical standpoint, without political or
>> philosophical considerations. Any fine tune of a candidate proposal
>> may not become an independent candidate, unless it introduces some
>> “real” difference. “No change” is also one of the voting
>> options.
>> ---------------------------------
>> Voter groups
>>
>> There will be several voter groups and their votes will be counted
>> independently. (The time frames mentioned below are just for
>> example.)
>>
>> Miners: miners of blocks with timestamp between 1 to 30 Sept 2015
>> are eligible to vote. One block one vote. Miners will cast their
>> votes by signing with the bitcoin address in coinbase. If there are
>> multiple coinbase outputs, the vote is discounted by output value /
>> total coinbase output value.
>> Many well-known pools are reusing addresses and they may not need
>> to digitally sign their votes. In case there is any dispute, the
>> digitally signed vote will be counted.
>>
>> Bitcoin holders: People with bitcoin in the UTXO at block 372500
>> (around early September) are eligible to vote. The total
>> “balance” of each scriptPubKey is calculated and this is the
>> weight of the vote. People will cast their votes by digital
>> signature.
>> Special output types:
>> Multi-sig: vote must be signed according to the setting of the
>> multi-sig.
>> P2SH: the serialized script must be provided
>> Publicly known private key: not eligible to vote
>> Non-standard script according to latest Bitcoin Core rules: not
>> eligible to vote in general. May be judged case-by-case
>>
>> Developers: People with certain amount of contribution in the past
>> year in Bitcoin Core or other open sources wallet / alternative
>> implementations. One person one vote.
>>
>> Exchanges: Centralized exchanges listed on Coindesk Bitcoin Index,
>> Winkdex, or NYSE Bitcoin index, with 30 days volume >100,000BTC are
>> invited. This includes Bitfinex, BTC China, BitStamp, BTC-E, itBit,
>> OKCoin, Huobi, Coinbase. Exchanges operated for at least 1 year with
>> 100,000BTC 30-day volume may also apply to be a voter in this
>> category. One exchange one vote.
>>
>> Merchants and service providers: This category includes all bitcoin
>> accepting business that is not centralized fiat-currency exchange,
>> e.g. virtual or physical stores, gambling sites, online wallet
>> service, payment processors like Bitpay, decentralized exchange like
>> Localbitcoin, ETF operators like Secondmarket Bitcoin Investment
>> Trust. They must directly process bitcoin without relying on third
>> party. They should process at least 100BTC in the last 30-days. One
>> merchant one vote.
>>
>> Full nodes operators: People operating full nodes for at least 168
>> hours (1 week) in July 2015 are eligible to vote, determined by the
>> log of Bitnodes. Time is set in the past to avoid manipulation. One
>> IP address one vote. Vote must be sent from the node’s IP address.
>>
>> --------------------
>> Voting system
>>
>> Single transferable vote is applied.
>> (https://en.wikipedia.org/wiki/Single_transferable_vote [2]). Voters
>> are required to rank their preference with “1”, “2”,
>> “3”, etc, or use “N” to indicate rejection of a candidate.
>> Vote counting starts with every voter’s first choice. The
>> candidate with fewest votes is eliminated and those votes are
>> transferred according to their second choice. This process repeats
>> until only one candidate is left, which is the most popular
>> candidate. The result is presented as the approval rate: final votes
>> for the most popular candidate / all valid votes
>>
>> After the most popular candidate is determined, the whole counting
>> process is repeated by eliminating this candidate, which will find
>> the approval rate for the second most popular candidate. The process
>> repeats until all proposals are ranked with the approval rate
>> calculated.
>>
>> --------------------
>> Interpretation of results:
>>
>> It is possible that a candidate with lower ranking to have higher
>> approval rate. However, ranking is more important than the approval
>> rate, unless the difference in approval rate is really huge. 90%
>> support would be excellent; 70% is good; 50% is marginal; <50% is
>> failed.
>>
>> --------------------
>> Technical issues:
>>
>> Voting by the miners, developers, exchanges, and merchants are
>> probably the easiest. We need a trusted person to verify the
>> voters’ identity by email, website, or digital signature. The
>> trusted person will collect votes and publish the named votes so
>> anyone could verify the results.
>>
>> For full nodes, we need a trusted person to setup a website as an
>> interface to vote. The votes with IP address will be published.
>>
>> For bitcoin holders, the workload could be very high and we may
>> need some automatic system to collect and count the votes. If people
>> are worrying about reduced security due to exposed raw public key,
>> they should move their bitcoin to a new address before voting.
>>
>> Double voting: people are generally not allowed to change their
>> mind after voting, especially for anonymous voters like bitcoin
>> holders and solo miners. A double voting attempt from these classes
>> will invalidate all related votes.
>>
>> Multiple identity: People may have multiple roles in the Bitcoin
>> ecology. I believe they should be allowed to vote in all applicable
>> categories since they are contributing more than other people.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [3]
>
>
> Links:
> ------
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html
> [2] https://en.wikipedia.org/wiki/Single_transferable_vote
> [3] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:32:54

- reply

📅 Original date posted:2015-08-04
📝 Original message:As now we have some concrete proposals
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html),
I think we should wrap up the endless debate with voting by different
stakeholder groups.
---------------------------------
Candidate proposals
Candidate proposals must be complete BIPs with reference implementation
which are ready to merge immediately. They must first go through the
usual peer review process and get approved by the developers in a
technical standpoint, without political or philosophical considerations.
Any fine tune of a candidate proposal may not become an independent
candidate, unless it introduces some “real” difference. “No change” is
also one of the voting options.
---------------------------------
Voter groups
There will be several voter groups and their votes will be counted
independently. (The time frames mentioned below are just for example.)
Miners: miners of blocks with timestamp between 1 to 30 Sept 2015 are
eligible to vote. One block one vote. Miners will cast their votes by
signing with the bitcoin address in coinbase. If there are multiple
coinbase outputs, the vote is discounted by output value / total
coinbase output value.
Many well-known pools are reusing addresses and they may not need to
digitally sign their votes. In case there is any dispute, the digitally
signed vote will be counted.
Bitcoin holders: People with bitcoin in the UTXO at block 372500 (around
early September) are eligible to vote. The total “balance” of each
scriptPubKey is calculated and this is the weight of the vote. People
will cast their votes by digital signature.
Special output types:
Multi-sig: vote must be signed according to the setting of the
multi-sig.
P2SH: the serialized script must be provided
Publicly known private key: not eligible to vote
Non-standard script according to latest Bitcoin Core rules: not eligible
to vote in general. May be judged case-by-case
Developers: People with certain amount of contribution in the past year
in Bitcoin Core or other open sources wallet / alternative
implementations. One person one vote.
Exchanges: Centralized exchanges listed on Coindesk Bitcoin Index,
Winkdex, or NYSE Bitcoin index, with 30 days volume >100,000BTC are
invited. This includes Bitfinex, BTC China, BitStamp, BTC-E, itBit,
OKCoin, Huobi, Coinbase. Exchanges operated for at least 1 year with
100,000BTC 30-day volume may also apply to be a voter in this category.
One exchange one vote.
Merchants and service providers: This category includes all bitcoin
accepting business that is not centralized fiat-currency exchange, e.g.
virtual or physical stores, gambling sites, online wallet service,
payment processors like Bitpay, decentralized exchange like
Localbitcoin, ETF operators like Secondmarket Bitcoin Investment Trust.
They must directly process bitcoin without relying on third party. They
should process at least 100BTC in the last 30-days. One merchant one
vote.
Full nodes operators: People operating full nodes for at least 168 hours
(1 week) in July 2015 are eligible to vote, determined by the log of
Bitnodes. Time is set in the past to avoid manipulation. One IP address
one vote. Vote must be sent from the node’s IP address.
--------------------
Voting system
Single transferable vote is applied.
(https://en.wikipedia.org/wiki/Single_transferable_vote). Voters are
required to rank their preference with “1”, “2”, “3”, etc, or use “N” to
indicate rejection of a candidate.
Vote counting starts with every voter’s first choice. The candidate with
fewest votes is eliminated and those votes are transferred according to
their second choice. This process repeats until only one candidate is
left, which is the most popular candidate. The result is presented as
the approval rate: final votes for the most popular candidate / all
valid votes
After the most popular candidate is determined, the whole counting
process is repeated by eliminating this candidate, which will find the
approval rate for the second most popular candidate. The process repeats
until all proposals are ranked with the approval rate calculated.
--------------------
Interpretation of results:
It is possible that a candidate with lower ranking to have higher
approval rate. However, ranking is more important than the approval
rate, unless the difference in approval rate is really huge. 90% support
would be excellent; 70% is good; 50% is marginal; <50% is failed.
--------------------
Technical issues:
Voting by the miners, developers, exchanges, and merchants are probably
the easiest. We need a trusted person to verify the voters’ identity by
email, website, or digital signature. The trusted person will collect
votes and publish the named votes so anyone could verify the results.
For full nodes, we need a trusted person to setup a website as an
interface to vote. The votes with IP address will be published.
For bitcoin holders, the workload could be very high and we may need
some automatic system to collect and count the votes. If people are
worrying about reduced security due to exposed raw public key, they
should move their bitcoin to a new address before voting.
Double voting: people are generally not allowed to change their mind
after voting, especially for anonymous voters like bitcoin holders and
solo miners. A double voting attempt from these classes will invalidate
all related votes.
Multiple identity: People may have multiple roles in the Bitcoin
ecology. I believe they should be allowed to vote in all applicable
categories since they are contributing more than other people.

2023-06-07 17:32:09

- reply

📅 Original date posted:2015-08-02
📝 Original message:Pieter Wuille 於 2015-08-01 16:45 寫到:
> On Fri, Jul 31, 2015 at 10:39 AM, jl2012 via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> 2. Starting date: 30 days after 75% miner support, but not before
>> 2016-01-12 00:00 UTC
>>
>> Rationale: A 30-day grace period is given to make sure everyone has
>> enough time to follow. This is a compromise between 14 day in BIP101
>> and 1 year in BIP103. I tend to agree with BIP101. Even 1 year is
>> given, people will just do it on the 364th day if they opt to
>> procrastinate.
>
> Given the time recent softforks have taken to deploy, I think that's
> too soon.
Since I'm using "30 days after 75% miner support", the actual deployment
period will be longer than 30 days. Anyway, if all major exchanges and
merchants agree to upgrade, people are forced to upgrade immediately or
they will follow a worthless chain.
>
>> 3. The block size at 2016-01-12 will be 1,414,213 bytes, and
>> multiplied by 1.414213 by every 2^23 seconds (97 days) until exactly
>> 8MB is reached on 2017-05-11.
>>
>> Rationale: Instead of jumping to 8MB, I suggest to increase it
>> gradually to 8MB in 16 months. 8MB should not be particularly
>> painful to run even with current equipment (you may see my earlier
>> post on bitctointalk:
>> https://bitcointalk.org/index.php?topic=1054482.0 ). 8MB is also
>> agreed by Chinese miners, who control >60% of the network.
>
> I have considered suggesting a faster ramp-up in the beginning, but I
> don't think there is indisputable evidence that we can currently deal
> with significantly larger blocks. I don't think "painful" is the right
> criterion either; I'm sure my equipment can "handle" 20 MB blocks too,
> but with a huge impact on network propagation speed, and even more
> people choosing the outsource their full nodes.
>
> Regarding "reasonable", I have a theory. What if we would have had 8
> MB blocks from the start? My guess is that some more people would have
> decided to run their high-transaction-rate use cases on chain, that
> we'd regularly see 4-6 MB blocks, there would be more complaints about
> low full node counts, maybe 90% instead of 60% of the hash rate would
> be have SPV mining agreements with each other, we'd somehow have
> accepted that even worse reality, but people would still be
> complaining about the measly 25 transactions per second that Bitcoin
> could handle on-chain, and be demanding a faster rampup to a more
> "reasonable" 64 MB block size as well.
Since the block reward is miners' major income source, no rational miner
would create mega blocks unless the fee could cover the extra orphaning
risk. Blocks were not constantly full until recent months, and many
miners are still keeping the 750kB soft limit. This strongly suggests
that we won't have 4MB blocks now even Satoshi set a 8MB limit.
I don't have the data now but I believe the Satoshi Dice model failed
not primarily due to the 1MB cap, but the raise in BTC/USD rate. Since
minting reward is a fixed value in BTC, the tx fee must also be valued
in BTC as it is primarily for compensating the extra orphaning risk. As
the BTC/USD rate increases, the tx fee measured in USD would also
increase, making micro-payment (measured in USD) unsustainable.
We might have less full nodes, but it was Satoshi's original plan: "At
first, most users would run network nodes, but as the network grows
beyond a certain point, it would be left more and more to specialists
with server farms of specialized hardware. A server farm would only need
to have one node on the network and the rest of the LAN connects with
that one node." Theoretically, we only require one honest full node to
prove wrongdoing on the blockchain and tell every SPV nodes to blacklist
the invalid chain.
I think SPV mining exists long before the 1MB block became full, and I
don't think we could stop this trend by artificially suppressing the
block size. Miners should just do it properly, e.g. stop mining until
the grandparent block is verified, which would make sure an invalid fork
won't grow beyond 2 blocks.
>> Global bandwidth is expected to grow by 37%/year until 2021 so
>> 27.67% should be safe at least for the coming 10 years.
>> Source:
>>
> https://www.telegeography.com/research-services/global-bandwidth-forecast-service/
>
> I'd rather be conservative here. My primary purpose is trying to
> create an uncontroversial proposal that introduces an expectation of
> growth with technology.
If we could have a longer initial ramp up period, we may adopt a slower
long term parameter. I think we should at least restore the original
32MB limit in a reasonable time frame, say 6-8 years, instead of 20
years in your proposal. If you believe Bitcoin should become a global
settlement network, 32MB would be the very minimum as that is only 75%
of current SWIFT traffic.

2023-06-07 17:32:06

- reply

📅 Original date posted:2015-08-01
📝 Original message:Although the chance is very slim, it is possible to have multiple
hardforks sharing the same flag block. For example, different proposals
may decide the flag time based on voting result and 2 proposals may have
the same flag time just by chance. The coinbase message is to preclude
any potential ambiguity. It also provides additional info to warning
system of non-upgrading nodes.
If we are pretty sure that there won't be other hardfork proposal at the
same time, the coinbase message may not be necessary. With some prior
collaboration, this may also be avoided (e.g. no sharing flag block
allowed as consensus rules of the hardforks)
The "version 0" idea is not compatible with the version bits voting
system, so I have this hardfork bit BIP after thinking more carefully.
Otherwise they are technically similar.
Michael Ruddy 於 2015-08-01 09:05 寫到:
>>> Ok, so set the bit and then include BIP-GIT-HASH of the canonical BIP
>>> on
>>> github in the coinbase?
>>
>>
>> I guess the git hash is not known until the code is written? (correct
>> me if
>> I'm wrong) As the coinbase message is consensus-critical, it must be
>> part of
>> the source code and therefore you can't use any kind of hash of the
>> code
>> itself (a chicken-and-egg problem)
>>
>
> I took Tier's comment to mean that the commit hash (taken from git) of
> the BIP for the particular hard fork being rolled out via your hard
> fork bit mechanism could be used in the coinbase.
> The commit for the BIP is separate from the commit for the code
> changes implementing it.
>
> By using the commit hash of the BIP, it means that the BIP cannot
> specify itself what to put in the coinbase.
> I'd suggest that your hard fork bit proposal allows BIP authors to
> specify, within a 20 byte limit (to let them ripe160 a message or
> something), the unique value to use.
> This would be just as well and would allow the specific hard fork BIPs
> to be updated without having to make code changes (e.g.- for simple
> grammatical updates, post deployment clarification, etc...).
>
> Perhaps more preferable, in order to keep the coinbases small, or, if
> you're worried about BIP authors using duplicate values, then just
> specify in your proposal that the coinbase message include
> "BIP<NUMBER>" as BIP numbers are not going to be reused. All you are
> trying to achieve is something that can be uniquely pattern matched.
>
> Are the reasons for your use of the coinbase message 1) to guard
> against one or more hard forks piggy-backing on another's flag block,
> without prior collaboration, and 2) to have a nicer message in the
> alerting system? If so, you might want to spell that out in your
> proposal. At first, I was thinking that the coinbase thing was not
> entirely necessary since the possibility of multiple hard forks taking
> place concurrently is low. Multiple forking changes could be
> coordinated to all use the same possible voting mechanisms, median
> timestamp, and thus flag block. But if the concern is about competing
> hard forks where two or more forks abandon the original chain and
> attempt to use the same checkpoint block, then I can see why you'd
> need it.
>
> I was reading this proposal alongside another of your messages
> (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009520.html)
> proposing a version 0 or even a >1MB block in the specific case of a
> block size limit hard fork. I can see the >1MB flag block creating DoS
> banning problems. That's more of a practical issue than a consensus
> issue due to the existing mono-culture of full nodes. So, currently a
>> 1MB flag block is not as appealing as a version 0 or this hard fork
> bit proposal. Besides the DoS ban, the >1MB proposal would mean that
> older nodes do not have the chance to notice a fork is happening (for
> alerting) as they would with a version 0 or hard fork bit.
>
> A version 0 flag block would not be able to contain any transactions
> unless the flag block version was assumed to be that of the most
> recent version at the time. This is because we'd want to enforce the
> rules of the previous soft forks that had been locked in. Other than
> that, the version 0 idea seems pretty similar to the hard fork bit
> proposal because you need more context than just the block itself to
> determine if it's a valid flag block (and this extra context is
> probably not great, but I don't have a better idea right now).
>
> Were those reasons part of why you progressed towards this hard fork
> bit proposal?

2023-06-07 17:32:06

- reply

📅 Original date posted:2015-08-03
📝 Original message:I have put it on the github:
https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki
I removed the specification of coinbase message to make it simpler.
Instead, it requires that a flag block must not be shared by multiple
hardfork proposals.
I'm not sure whether it is a Standard, Informational, or Process BIP
I'm also thinking whether we should call it "hardfork bit", "hardfork
flag", or with other name.
Michael Ruddy 於 2015-08-02 06:53 寫到:
> I think your "hardfork bit" proposal is clever.
> It addresses the particular valid concern of re-org facing users of a
> fork that a small/near/fluctuating majority, or less, of mining power
> supported.
> While the "economic majority" argument may be enough on its own in
> that case, it still has some aspect of being a hand wave.
> This proposal adds support to those economic actors, which makes it
> easier for them to switch if/when they choose. That is, it provides a
> good fallback mechanism that allows them to make a decision and say,
> "we're doing this".
> Do you have the latest version up on github, or someplace where it
> would be easier to collaborate on the specific text?

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-07-31
📝 Original message:Yes, data-center operators are bound to follow laws, including NSLs
and gag orders. How about your ISP? Is it bound to follow laws,
including NSLs and gag orders?
https://edri.org/irish_isp_introduces_blocking/
Do you think everyone should run a full node behind TOR? No way, your
repressive government could just block TOR:
http://www.technologyreview.com/view/427413/how-china-blocks-the-tor-anonymity-network/
Or they could raid your home and seize your Raspberry Pi if they
couldn't read your encrypted internet traffic. You will have a hard
time proving you are not using TOR for child porn or cocaine.
https://en.wikipedia.org/wiki/Encryption_ban_proposal_in_the_United_Kingdom
If you are living in a country like this, running Bitcoin in an
offshore VPS could be much easier. Anyway, Bitcoin shouldn't be your
first thing to worry about. Revolution is probably your only choice.
Data-centers would get hacked. How about your Raspberry Pi?
Corrupt data-center employee is probably the only valid concern.
However, there is nothing (except cost) to stop you from establishing
multiple full nodes all over the world. If your Raspberry Pi at home
could no longer fully validate the chain, it could become a
header-only node to make sure your VPS full nodes are following the
correct chaintip. You may even buy hourly charged cloud hosting in
different countries to run header-only nodes at negligible cost.
There is no single point of failure in a decentralized network. Having
multiple nodes will also save you from Sybil attack and geopolitical
risks. Again, if all data-centres and governments in the world are
turning against Bitcoin, it is delusional to think we could fight
against them without using any real weapon.
By the way, I'm quite confident that my current full node at home are
capable of running at 8MB blocks.
Quoting Adam Back <adam at cypherspace.org>:
> I think trust the data-center logic obviously fails, and I was talking
> about this scenario in the post you are replying to. You are trusting the
> data-center operator period. If one could trust data-centers to run
> verified code, to not get hacked, filter traffic, respond to court orders
> without notifying you etc that would be great but that's unfortunately not
> what happens.
>
> Data-center operators are bound to follow laws, including NSLs and gag
> orders. They also get hacked, employ humans who can be corrupt,
> blackmailed, and themselves centralisation points for policy attack.
> Snowden related disclosures and keeping aware of security show this is very
> real.
>
> This isn't much about bitcoin even, its just security reality for hosting
> anything intended to be secure via decentralisation, or just hosting in
> general while at risk of political or policy attack.
>
> Adam

2023-06-07 15:44:25

- reply

📅 Original date posted:2015-07-31
📝 Original message:There is a summary of the proposals in my previous mail at
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html
I think there could be a compromise between Gavin's BIP101 and
Pieter's proposal (called "BIP103" here). Below I'm trying to play
with the parameters, which reasons:
1. Initiation: BIP34 style voting, with support of 750 out of the last
1000 blocks. The "hardfork bit" mechanism might be used:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html
Rationale: This follows BIP101, to make sure the new chain is secure.
Also, no miner would like to be the first one to mine a large block if
they don't know how many others would accept it.
2. Starting date: 30 days after 75% miner support, but not before
2016-01-12 00:00 UTC
Rationale: A 30-day grace period is given to make sure everyone has
enough time to follow. This is a compromise between 14 day in BIP101
and 1 year in BIP103. I tend to agree with BIP101. Even 1 year is
given, people will just do it on the 364th day if they opt to
procrastinate.
2016-01-12 00:00 UTC is Monday evening in US and Tuesday morning in
China. Most pool operators and devs should be back from new year
holiday and not sleeping. (If the initiation is delayed, we may
require that it must be UTC Tuesday midnight)
3. The block size at 2016-01-12 will be 1,414,213 bytes, and
multiplied by 1.414213 by every 2^23 seconds (97 days) until exactly
8MB is reached on 2017-05-11.
Rationale: Instead of jumping to 8MB, I suggest to increase it
gradually to 8MB in 16 months. 8MB should not be particularly painful
to run even with current equipment (you may see my earlier post on
bitctointalk: https://bitcointalk.org/index.php?topic=1054482.0). 8MB
is also agreed by Chinese miners, who control >60% of the network.
4. After 8MB is reached, the block size will be increased by 6.714%
every 97 days, which is equivalent to exactly octuple (8x) every 8.5
years, or double every 2.9 years, or +27.67% per year. Stop growth at
4096MB on 2042-11-17.
Rationale: This is a compromise between 17.7% p.a. of BIP103 and 41.4%
p.a. of BIP101. This will take us almost 8 years from now just to go
back to the original 32MB size (4 years for BIP101 and 22 years for
BIP103)
SSD price is expected to drop by >50%/year in the coming years. In
2020, we will only need to pay 2% of current price for SSD. 98% price
reduction is enough for 40 years of 27.67% growth.
Source: http://wikibon.org/wiki/v/Evolution_of_All-Flash_Array_Architectures
Global bandwidth is expected to grow by 37%/year until 2021 so 27.67%
should be safe at least for the coming 10 years.
Source:
https://www.telegeography.com/research-services/global-bandwidth-forecast-service/
The final cap is a compromise between 8192MB at 2036 of BIP101 and
2048MB at 2063 of BIP103
-----------------------------------
Generally speaking, I think we need to have a faster growth in the
beginning, just to normalize the block size to a more reasonable one.
After all, the 1MB cap was introduced when Bitcoin was practically
worthless and with inefficient design. We need to decide a new
"optimal" size based on current adoption and technology.
About "fee market": I do agree we need a fee market, but the fee
pressure must not be too high at this moment when block reward is
still miner's main income source. We already have a fee market: miners
will avoid building big blocks with low fee because that will increase
the orphan risk for nothing.
About "secondary layer": I respect everyone building secondary layer
over the blockchain. However, while the SWIFT settlement network is
processing 300tps, Bitcoin's current 7tps is just nothing more than an
experiment. If the underlying settlement system does not have enough
capacity, any secondary layer built on it will also fall apart. For
example, people may DoS attack a Lightening network by provoking a
huge amount of settlement request which some may not be confirmed on
time. Ultimately, this will increase the risk of running a LN service
and increase the tx fee inside LN. After all, the value of secondary
layer primarily comes from instant confirmation, not scarcity of the
block space.