<unnamed>

Public Key

npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4

Profile Code

nprofile1qqstv83w0n9lf27h7jt3t330ftr6j09a6h4dqvtz08zltl5mrrws42spz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsq6a7u2

Publishing to

relay.snort.social

nos.lol

relay.damus.io

Last Notes

2023-06-07 17:48:44 UTC

- 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:46:14 UTC

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

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

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

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

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

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

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

- 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:00 UTC

- 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:41:37 UTC

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

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

- 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:40:52 UTC

- 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:45 UTC

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

- 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:39:25 UTC

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

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

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

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

- 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:17 UTC

- 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:37:57 UTC

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

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

- 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:36:38 UTC

- 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:04 UTC

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

- 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:33:36 UTC

- 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 15:49:21 UTC

- reply

2023-06-07 15:49:20 UTC

- reply

2023-06-07 15:49:19 UTC

- reply

2023-06-07 15:47:43 UTC

- reply

2023-06-07 15:47:22 UTC

- reply

2023-06-07 15:45:44 UTC

- reply

2023-06-07 15:45:29 UTC

- 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 15:42:33 UTC

- reply

📅 Original date posted:2015-07-22
📝 Original message:Quoting Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>:
>
> Having said that, in general triggering events without verifying a
> supermajority of miner support can be very dangerous. Without miner
> support the chain is insecure, and can be attacked. For instance a
> blocksize limit increase that a majority of miners choose not to
> implement raises huge risks of reorg for any miners who attempt to
> create large blocks, and huge risks of payment reversal for any
> merchants accepting transactions in such blocks. Note how with BIP102,
> extending the original Bitcoin chain is inherently an attack on the
> Garzik chain.
>
> For that reason I think BIP102 is extremely poorly designed. I can only
> conclude that Jeff Garzik is either deliberately trolling us and/or
> manipulating discussion with a badly designed proposal that he doesn't
> actually expect to be adopted verbatim, or is incompetent.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000031c12b6af038524fd5dd28115b7f5591e046423cebaf6d1
To avoid any risk of reorg, the hardfork may require that the first
block with GetMedianTimePast() after a pre-determined time (the "flag
block") MUST be version 0. The exception is applied ONLY to the flag
block.
Alternatively, the hardfork may require that the flag block MUST be
larger than 1MB. Comparing with exploiting the block version, this
does not require additional exceptions in consensus rules. However,
miner may need to artificially inflate the size of the flag block and
that could be trouble in coding. I don't have any preference.
Old nodes will not accept the new chain because it violates BIP66 /
block size limit. New nodes will not accept the old chain because its
flag block is not version 0 / not larger than 1MB.
This is actually checkpointing in a decentralized way. In that case,
we can say goodbye to the old chain forever, as long as all major
merchants and exchanges agree to upgrade. Miner support is less
relevant. It is a no-brainer for miners to support the new chain,
unless they don't want to sell or spend their bitcoin, or just give up
mining after heavily investing in ASIC.
jl2012

2023-06-07 15:42:32 UTC

- reply

📅 Original date posted:2015-07-23
📝 Original message:Quoting Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Sorry, but I think you need to re-read my first message. What you've
> written below has nothing to do with what I actually said re: how
> you're BIP102 and associated pull-req doesn't measure miner consensus.
>
>
I think I have already answered this with my previous mail. If there
is consensus among major exchanges and merchants, the preference of
miners are not particularly relevant. A checkpoint could be
implemented in a decentralized way to make sure miners of the original
chain won't be able to overtake the new chain.
Bitcoin has no intrinsic value. Bitcoin has value because people are
willing to exchange it with something really valuable (e.g. a pizza;
or USD which could buy a pizza). If most bitcoin-accepting business
agree to follow BIP102 and ONLY BIP102, then BIP102 is THE Bitcoin,
and the original chain is just a dSHA256 alt-coin which one can't even
merge mine with BIP102. Switching to BIP102 is the only economically
viable choice for miners.
Having said that, a miner voting may still be useful. It is just to
make sure enough miners are ready for the change, instead of measuring
their consensus. For example, the new rule will be implemented 1) 1
week after 70% of miners are ready; or 2) on 1 Feb 2016, whichever
happens first.
For SPV wallets, they have to strengthen their security model after
the BIP66 fork, anyway. They should be able to identify potential
consensus fork in the network and stop accepting incoming txs when it
is in doubt. My "version 0 flag block" proposal could be a good
generic way to indicate a hardfork to SPV wallets. (see my previous
email on this topic)