jl2012 [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-12-16 to 2016-02-05
💬 Posted a total of 20 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub14vwgt02663pkxx54kg5t693shaavmvnldhsp49sve7asw7p36lkqljyksm

Profile Code

nprofile1qqs2k8y9h4ddgsmrr22my29azcct77kdkflkmcq6jcxvlwc80qca0mqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dswq9svs

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub14vwgt02663pkxx54kg5t693shaavmvnldhsp49sve7asw7p36lkqljyksm

Show more details

Last Notes

2023-06-07 19:48:34

- reply

📅 Original date posted:2016-02-05
📝 Original message:BIP draft: Hard fork opt-in mechanism for SPV nodes:
https://github.com/bitcoin/bips/pull/320
This is a supplement, instead of a replacement, of the hardfork bit BIP:
https://github.com/bitcoin/bips/pull/317
They solves different problems:
The hardfork bit tells full and SPV that a planned hardfork (instead of
a softfork) has happened.
This BIP makes sure SPV nodes won't lose any money in a hardfork, even
if they do not check the hardfork bit.
---------------------
BIP: ?
Title: Hard fork opt-in mechanism for SPV nodes
Author: Johnson Lau <jl2012 at xbt.hk>
Status: Draft
Type: Standard Track
Created: 2016-02-05
ABSTRACT
This document specifies a new algorithm for the transaction commitment
in block header, to ensure that SPV nodes will not automatically follow
a planned hard fork without explicit opt-in consent.
[1]MOTIVATION
A hard fork in Bitcoin is a consensus rule change where previously
invalid blocks become valid. For the operators of fully validating
nodes, migration to the new fork requires conscious actions. However,
this may not be true for SPV node, as many consensus rules are
transparent to them. SPV nodes may follow the chain with most
proof-of-work, even if the operators do not agree with the economical or
ideological properties of the chain.
By specifying a new algorithm for the transaction commitment in block
header, migration to the new fork requires explicit opt-in consent for
SPV nodes. It is expected that this proposal will be implemented with
other backward-incompatible consensus rule changes at the same time.
[2]SPECIFICATION
The calculation of Merkle root remains unchanged. Instead of directly
committing the Merkle root to the header, we commit
Double-SHA256(zero|merkle_root|zero)
where zero is 0x0000....0000 with 32 bytes.
[3]RATIONALE
Since the header structure is not changed, non-upgraded SPV nodes will
still be able to verify the proof-of-work of the new chain, and they
will follow the new chain if it has most proof-of-work. However, they
will not be able to the accept any incoming transactions on the new
chain since they cannot verify them with the new commitment format. At
the same time, SPV nodes will not accept any new transactions on the old
chain, as they find it has less proof-of-work. Effectively, SPV nodes
stop accepting any transactions, until their operators take further
actions.
Zero-padding is applied before and after the merkle_root, so it is not
possible to circumvent the rule change with any current implementations,
even for faulty ones.
A future hard fork should change the padding value to stop non-upgraded
SPV nodes from processing new transactions.
Hard forks may sometimes be totally uncontroversial and make barely
noticeable change (BIP50 [4], for example). In such cases, changing the
padding value may not be needed as it may cause unnecessary disruption.
The risk and benefit should be evaluated case-by-case.
[5]COMPATIBILITY
As a mechanism to indicate hard fork deployment, this BIP breaks
backward compatibility intentionally. However, without further changes
in the block header format, non-upgraded full nodes and SPV nodes could
still verify the proof-of-work of upgraded blocks.
INTERACTION WITH FRAUD PROOF SYSTEM A fraud proof system is full nodes
that will generate compact proofs to testify invalid blocks on the
blockchain, verifiable by SPV nodes. Hard forks without any malicious
intention may also be considered as a "fraud" among non-upgraded nodes.
This may not be desirable, as the SPV node may accept devalued tokens on
the old chain with less proof-of-work. With this BIP, non-upgraded SPV
nodes will always believe the new chain is valid (since they cannot
verify any fraud proof), while cannot be defrauded as they will not see
any incoming transactions.
[6]COPYRIGHT
This document is placed in the public domain.
Links:
------
[1]
https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#motivation
[2]
https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#specification
[3]
https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#rationale
[4] https://github.com/jl2012/bips/blob/merkleroot/bip-0050.mediawiki
[5]
https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#compatibility
[6]
https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#copyright
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160205/df2b2606/attachment.html>

2023-06-07 19:48:29

- reply

📅 Original date posted:2016-02-04
📝 Original message:Gavin Andresen 於 2016-02-04 12:36 寫到:
> This BIP is unnecessary, in my opinion.
>
> I'm going to take issue with items (2) and (3) that are the motivation
> for this BIP:
>
> " 2. Full nodes and SPV nodes following original consensus rules may
> not be aware of the deployment of a hardfork. They may stick to an
> economic-minority fork and unknowingly accept devalued legacy tokens."
>
> If a hardfork is deployed by increasing the version number in blocks
> (as is done for soft forks), then there is no risk-- Full and SPV
> nodes should notice that they are seeing up-version blocks and warn
> the user that they are using obsolete software.
>
> It doesn't matter if the software is obsolete because of hard or soft
> fork, the difference in risks between those two cases will not be
> understood by the typical full node or SPV node user.
Thanks for your comments.
In the case of a softfork, as long as an user waits for a few
confirmations, the risk of money loss is very low. In the worst case
they run a full node with SPV security. In the case of a hardfork, the
consequence of failing to upgrade to the economic majority fork *is*
fatal, even if an user waits for 1000 confirmations. Not to mention the
risk of having 2 economically active forks. That's why wallets should
STOP accepting and sending tx after a hardfork bit is detected and wait
for users' instructions.
> " 3. In the case which the original consensus rules are also valid
> under the new consensus rules, users following the new chain may
> unexpectedly reorg back to the original chain if it grows faster than
> the new one. People may find their confirmed transactions becoming
> unconfirmed and lose money."
>
> If a hard or soft fork uses a 'grace period' (as described in BIP 9 or
> BIP 101) then there is essentially no risk that a reorg will happen
> past the triggering block. A block-chain re-org of two thousand or
> more blocks on the main Bitcoin chain is unthinkable-- the economic
> chaos would be massive, and the reaction to such a drastic (and
> extremely unlikely) event would certainly be a hastily imposed
> checkpoint to get everybody back onto the chain that everybody was
> using for economic transactions.
No, the "triggering block" you mentioned is NOT where the hardfork
starts. Using BIP101 as an example, the hardfork starts when the first
>1MB is mined. For people who failed to upgrade, the "grace period" is always zero, which is the moment they realize a hardfork.
> Since I don't agree with the motivations for this BIP, I don't think
> the proposed mechanism (a negative-version-number-block) is necessary.
> And since it would simply add more consensus-level code, I believe the
> keep-it-simple principle applies.
>
> --
>
> --
> Gavin Andresen

2023-06-07 19:48:28

- reply

📅 Original date posted:2016-02-04
📝 Original message:https://github.com/bitcoin/bips/pull/317
ABSTRACT
This document specifies a proposed change to the semantics of the sign
bit of the "version" field in Bitcoin block headers, as a mechanism to
indicate a hardfork is deployed. It alleviates certain risks related to
a hardfork by introducing an explicit "point of no return" in the
blockchain. This is a general mechanism which should be employed by any
planned hardfork in the future.
[1]MOTIVATION
Hardforks in Bitcoin are usually considered as difficult and risky,
because:
* Hardforks require not only support of miners, but also, most
importantly, supermajority support of the Bitcoin economy. As a result,
softfork deployment mechanisms described in BIP 34 [2] or BIP 9 [3] are
not enough for introducing hardforks safely.
* Full nodes and SPV nodes following original consensus rules may not
be aware of the deployment of a hardfork. They may stick to an
economic-minority fork and unknowingly accept devalued legacy tokens.
* In the case which the original consensus rules are also valid under
the new consensus rules, users following the new chain may unexpectedly
reorg back to the original chain if it grows faster than the new one.
People may find their confirmed transactions becoming unconfirmed and
lose money.
The first issue involves soliciting support for a hardfork proposal,
which is more a political topic than a technical one. This proposal aims
at alleviating the risks related to the second and third issues. It
should be employed by any planned hardfork in the future.
[4]DEFINITIONS
See BIP99 [5]
[6]SPECIFICATION
HARDFORK BIT The sign bit in nVersion is defined as the hardfork bit.
Currently, blocks with this header bit setting to 1 are invalid, since
BIP65 [7] interprets nVersion as a signed number and requires it to be ≥
4. Among the 640 bits in the block header, this is the only one which is
fixed and serves no purpose, and therefore the best way to indicate the
deployment of a hardfork.
FLAG BLOCK Any planned hardfork must have one and only one flag block
which is the "point of no return". To ensure monotonicity, flag block
should be determined by block height, or as the first block with
GetMedianTimePast() greater than a threshold. Other mechanisms could be
difficult for SPV nodes to follow. The height/time threshold could be a
predetermined value or relative to other events (e.g. 10000 blocks / 100
days after 95% of miner support). The exact mechanism is out of the
scope of this BIP. No matter what mechanism is used, the threshold is
consensus critical. It must be publicly verifiable with only blockchain
data, and preferably SPV-friendly (i.e. verifiable with block headers
only, without downloading any transaction).
Flag block is constructed in a way that nodes with the original
consensus rules must reject. On the other hand, nodes with the new
consensus rules must reject a block if it is not a flag block while it
is supposed to be. To achieve these goals, the flag block must
* have the hardfork bit setting to 1, and
* follow any other rules required by the hardfork
If these conditions are not fully satisfied, upgraded nodes shall reject
the block.
The hardfork bit must be turned off in the successors of the flag block,
until the deployment of the next hardfork.
Although a hardfork is officially deployed when flag block is generated,
the exact behavioural change is out of the scope of this BIP. For
example, a hardfork may not be fully active until certain time after the
flag block.
CONCURRENT HARDFORK PROPOSALS To avoid confusion and unexpected
behaviour, a flag block should normally signify the deployment of only
one hardfork. Therefore, a hardfork proposal has to make sure that its
flag block threshold is not clashing with other ongoing hardfork
proposals.
In the case that the version bits mechanism is used in deploying a
hardfork, height of the flag block should take a value of32N + B, where
N is a positive integer and B is the position of bit B defined in BIP9
[8]. This guarantees that no clash may happen with another hardfork
proposal using BIP9.
UNCONTROVERSIAL SUBTLE HARDFORKS Hardforks may sometimes be totally
uncontroversial and make barely noticeable change (BIP50 [9], for
example). In such cases, the use of hardfork bit may not be needed as it
may cause unnecessary disruption. The risk and benefit should be
evaluated case-by-case.
AUTOMATIC WARNING SYSTEM When a flag block for an unknown hardfork is
found on the network, full nodes and SPV nodes should alert their users
and/or stop accepting/sending transactions. It should be noted that the
warning system could become a denial-of-service vector if the attacker
is willing to give up the block reward. Therefore, the warning may be
issued only if a few blocks are built on top of the flag block in a
reasonable time frame. This will in turn increase the risk in case of a
real planned hardfork so it is up to the wallet programmers to decide
the optimal strategy. Human warning system (e.g. the emergency alert
system in Bitcoin Core) could fill the gap.
[10]COMPATIBILITY
As a mechanism to indicate hardfork deployment, this BIP breaks backward
compatibility intentionally. However, without further changes in the
block header format, full nodes and SPV nodes could still verify the
Proof-of-Work of a flag block and its successors.
HARDFORK INVOLVING CHANGE IN BLOCK HEADER FORMAT If a hardfork involves
a new block header format, the original format should still be used for
the flag block and a reasonable period afterwards, to make sure existing
nodes realize that an unknown hardfork has been deployed.
VERSION BITS This proposal is also compatible with the BIP9. The version
bits mechanism could be employed to measure miner support towards a
hardfork proposal, and to determine the height or time threshold of the
flag block. Also, miners of the flag block may still cast votes for
other concurrent softfork or hardfork proposals as normal.
POINT OF NO RETURN After the flag block is generated, a miner may
support either the original rules or the new rules, but not both. It is
not possible for miners in one fork to attack or overtake the other fork
without giving up the mining reward of their preferred fork.
[11]COPYRIGHT
This document is placed in the public domain.
Links:
------
[1]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#motivation
[2] https://github.com/jl2012/bips/blob/hardforkbit/bip-0034.mediawiki
[3] https://github.com/jl2012/bips/blob/hardforkbit/bip-0009.mediawiki
[4]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#definitions
[5] https://github.com/jl2012/bips/blob/hardforkbit/bip-0099.mediawiki
[6]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#specification
[7] https://github.com/jl2012/bips/blob/hardforkbit/bip-0065.mediawiki
[8]
https://github.com/jl2012/bips/blob/hardforkbit/bip-0009.mediawiki#Mechanism
[9] https://github.com/jl2012/bips/blob/hardforkbit/bip-0050.mediawiki
[10]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#compatibility
[11]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#copyright
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160204/d4208f4f/attachment.html>

2023-06-07 19:47:22

- reply

📅 Original date posted:2015-12-29
📝 Original message:What if someone complains? We can't even tell whether a complaint is
legit or just trolling. That's why I think we need some general
consensus rules which is not written in code, but as a social contract.
Breaking those rules would be considered as a hardfork and is allowed
only in exceptional situation.
Jonathan Toomim via bitcoin-dev 於 2015-12-29 07:42 寫到:
> That sounds like a rather unlikely scenario. Unless you have a
> specific reason to suspect that might be the case, I think we don't
> need to worry about it too much. If we announce the intention to
> perform such a soft fork a couple of months before the soft fork
> becomes active, and if nobody complains about it destroying their
> secret stash, then I think that's fair enough and we could proceed.
>
> On Dec 28, 2015, at 11:47 PM, jl2012 via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Do we need to consider that someone may have a timelocked big tx, with
>> private key lost?
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:47:21

- reply

📅 Original date posted:2015-12-29
📝 Original message:Do we need to consider that someone may have a timelocked big tx, with
private key lost?
I think we need to tell people not to do this. Related discussion:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011656.html
Peter Todd via bitcoin-dev 於 2015-12-29 00:35 寫到:
> Occured to me that this hasn't been mentioned before...
>
> We can trivially fix the quadratic CHECK(MULTI)SIG execution time issue
> by soft-forking in a limitation on just SignatureHash() to only return
> true if the tx size is <100KB. (or whatever limit makes sense)
>
> This fix has the advantage over schemes that limit all txs, or try to
> count sigops, of being trivial to implement, while still allowing for a
> future CHECKSIG2 soft-fork that properly fixes the quadratic hashing
> issue; >100KB txs would still be technically allowed, it's just that
> (for now) there'd be no way for them to spend coins that are
> cryptographically secured.
>
> For example, if we had an issue with a major miner exploiting
> slow-to-propagate blocks(1) to harm their competitors, this simple fix
> could be deployed as a soft-fork in a matter of days, stopping the
> attack quickly.
>
> 1)
> www.mail-archive.com/bitcoin-development at lists.sourceforge.net/msg03200.html
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:47:20

- reply

📅 Original date posted:2015-12-24
📝 Original message:The SW payment address format BIP draft is ready and is pending BIP
number assignment:
https://github.com/bitcoin/bips/pull/267
This is the 3rd BIP for segwit. The 2nd one for Peer Services is being
prepared by Eric Lombrozo
Eric Lombrozo via bitcoin-dev 於 2015-12-23 10:22 寫到:
> I've been working with jl2012 on some SEGWIT BIPs based on earlier
> discussions Pieter Wuille's implementation. We're considering
> submitting three separate BIPs:
>
> CONSENSUS BIP: witness structures and how they're committed to blocks,
> cost metrics and limits, the scripting system (witness programs), and
> the soft fork mechanism.
>
> PEER SERVICES BIP: relay message structures, witnesstx serialization,
> and other issues pertaining to the p2p protocol such as IBD,
> synchronization, tx and block propagation, etc...
>
> APPLICATIONS BIP: scriptPubKey encoding formats and other wallet
> interoperability concerns.
>
> The Consensus BIP is submitted as a draft and is pending BIP number
> assignment: https://github.com/bitcoin/bips/pull/265 [1]
> The other two BIPS will be drafted soon.
>
> ---
> Eric
>
> Links:
> ------
> [1] https://github.com/bitcoin/bips/pull/265
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:47:20

- reply

📅 Original date posted:2015-12-27
📝 Original message:The SW payment address format BIP is completely rewritten to introduce 2
types of new addresses:
https://github.com/bitcoin/bips/pull/267
jl2012 via bitcoin-dev 於 2015-12-24 09:22 寫到:
> The SW payment address format BIP draft is ready and is pending BIP
> number assignment:
> https://github.com/bitcoin/bips/pull/267
>
> This is the 3rd BIP for segwit. The 2nd one for Peer Services is being
> prepared by Eric Lombrozo
>
> Eric Lombrozo via bitcoin-dev 於 2015-12-23 10:22 寫到:
>> I've been working with jl2012 on some SEGWIT BIPs based on earlier
>> discussions Pieter Wuille's implementation. We're considering
>> submitting three separate BIPs:
>>
>> CONSENSUS BIP: witness structures and how they're committed to blocks,
>> cost metrics and limits, the scripting system (witness programs), and
>> the soft fork mechanism.
>>
>> PEER SERVICES BIP: relay message structures, witnesstx serialization,
>> and other issues pertaining to the p2p protocol such as IBD,
>> synchronization, tx and block propagation, etc...
>>
>> APPLICATIONS BIP: scriptPubKey encoding formats and other wallet
>> interoperability concerns.
>>
>> The Consensus BIP is submitted as a draft and is pending BIP number
>> assignment: https://github.com/bitcoin/bips/pull/265 [1]
>> The other two BIPS will be drafted soon.
>>
>> ---
>> Eric
>>
>> Links:
>> ------
>> [1] https://github.com/bitcoin/bips/pull/265
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:47:17

- reply

📅 Original date posted:2015-12-21
📝 Original message:On the -dev IRC I asked the same question and people seem don't like it.
I would like to further elaborate this topic and would like to consult
merchants, exchanges, wallet devs, and users for their preference
Background:
People will be able to use segregated witness in 2 forms. They either
put the witness program directly as the scriptPubKey, or hide the
witness program in a P2SH address. They are referred as "native SW" and
"SW in P2SH" respectively
Examples could be found in the draft BIP:
https://github.com/jl2012/bips/blob/segwit/bip-segwit.mediawiki
As a tx malleability fix, native SW and SW in P2SH are equally good.
The SW in P2SH is better in terms of:
1. It allows payment from any Bitcoin reference client since version
0.6.0.
2. Slightly better privacy by obscuration since people won't know
whether it is a traditional P2SH or a SW tx before it is spent. I don't
consider this is important since the type of tx will be revealed
eventually, and is irrelevant when native SW is more popular
The SW in P2SH is worse in terms of:
1. It requires an additional push in scriptSig, which is not prunable in
transmission, and is counted as part of the core block size
2. It requires an additional HASH160 operation than native SW
3. It provides 160bit security, while native SW provides 256bit
4. Since it is less efficient, the tx fee is likely to be higher than
native SW (but still lower than non-SW tx)
---------------------------
The question: should we have a new payment address format for native SW?
The native SW address in my mind is basically same as existing P2PKH and
P2SH addresses:
BASE58(address_version|witness_program|checksum) , where checksum is the
first 4 bytes of dSHA256(address_version|witness_program)
Why not a better checksum algorithm? Reusing the existing algorithm make
the implementation much easier and safe.
Pros for native SW address:
1. Many people and services are still using BASE58 address
2. Promote the use of native SW which allows lower fee, instead of the
less efficient SW in P2SH
3. Not all wallets and services support payment protocol (BIP70)
4. Easy for wallets to implement
5. Even if a wallet wants to only implement SW in P2SH, they need a new
wallet format anyway. So there is not much exta cost to introduce a new
address format.
6. Since SW is very flexible, this is very likely to be the last address
format to define.
Cons for native SW address:
1. Addresses are bad and should not be used anymore (some arguments
could be found in BIP13)
2. Payment protocol is better
3. With SW in P2SH, it is not necessary to have a new address format
4. Depends on the length of the witness program, the address length
could be a double of the existing address
5. Old wallets won't be able to pay to a new address (but no money could
be lost this way)
------------------------------
So I'd like to suggest 2 proposals:
Proposal 1:
To define a native SW address format, while people can still use payment
protocol or SW in P2SH if the want
Proposal 2:
No new address format is defined. If people want to pay as lowest fee as
possible, they must use payment protocol. Otherwise, they may use SW in
P2SH
Since this topic is more relevant to user experience, in addition to
core devs, I would also like to consult merchants, exchanges, wallet
devs, and users for their preferences.

2023-06-07 19:47:13

- reply

📅 Original date posted:2015-12-21
📝 Original message:I proposed something very similar 2 years ago:
https://bitcointalk.org/index.php?topic=283746.0
This is an interesting academic idea. But the way you implement it will
immediately kill all existing full and SPV nodes (not really dead,
rather like zombie as they can't send and receive any tx).
joe2015--- via bitcoin-dev 於 2015-12-20 05:56 寫到:
> This is a draft.
>
> --joe
>
> Introduction
> ============
>
> It is generally assumed that increasing the blocksize limit requires a
> hardfork. Instead we show that a increasing the limit can be achieved
> using a
> "generalized" softfork. Like standard softforks, generalized softforks
> need a
> mere miner majority (>50% hashpower) rather than global consensus.
>

2023-06-07 19:47:00

- reply

📅 Original date posted:2015-12-20
📝 Original message:Chris Priest via bitcoin-dev 於 2015-12-19 22:34 寫到:
> Block witholding attacks are only possible if you have a majority of
> hashpower. If you only have 20% hashpower, you can't do this attack.
> Currently, this attack is only a theoretical attack, as the ones with
> all the hashpower today are not engaging in this behavior. Even if
> someone who had a lot of hashpower decided to pull off this attack,
> they wouldn't be able to disrupt much. Once that time comes, then I
> think this problem should be solved, until then it should be a low
> priority. There are more important things to work on in the meantime.
>
This is not true. For a pool with 5% total hash rate, an attacker only
needs 0.5% of hash rate to sabotage 10% of their income. It's already
enough to kill the pool

2023-06-07 19:47:00

- reply

📅 Original date posted:2015-12-20
📝 Original message:Chris Priest 於 2015-12-19 22:47 寫到:
> On 12/19/15, jl2012 <jl2012 at xbt.hk> wrote:
>> Chris Priest via bitcoin-dev 於 2015-12-19 22:34 寫到:
>>> Block witholding attacks are only possible if you have a majority of
>>> hashpower. If you only have 20% hashpower, you can't do this attack.
>>> Currently, this attack is only a theoretical attack, as the ones with
>>> all the hashpower today are not engaging in this behavior. Even if
>>> someone who had a lot of hashpower decided to pull off this attack,
>>> they wouldn't be able to disrupt much. Once that time comes, then I
>>> think this problem should be solved, until then it should be a low
>>> priority. There are more important things to work on in the meantime.
>>>
>>
>> This is not true. For a pool with 5% total hash rate, an attacker only
>> needs 0.5% of hash rate to sabotage 10% of their income. It's already
>> enough to kill the pool
>>
>>
>
> This begs the question: If this is such a devastating attack, then why
> hasn't this attack brought down every pool in existence? As far as I'm
> aware, there are many pools in operation despite this possibility.
It did happen:
https://www.reddit.com/r/Bitcoin/comments/28242v/eligius_falls_victim_to_blocksolution_withholding/
The worst thing is that the proof for such attack is probabilistic, not
deterministic.
A smarter attacker may even pretend to be many small miners, make it
even more difficult or impossible to prove who are attacking.
> Then shouldn't this be something the pool deals with, not the bitcoin
> protocol?
The only solution is to ask for KYC registration, unless one could
propose
a cryptographic solution that does not require a consensus fork.

2023-06-07 19:46:55

- reply

📅 Original date posted:2015-12-19
📝 Original message:After the meeting I find a softfork solution. It is very inefficient and
I am leaving it here just for record.
1. In the first output of the second transaction of a block, mining pool
will commit a random nonce with an OP_RETURN.
2. Mine as normal. When a block is found, the hash is concatenated with
the committed random nonce and hashed.
3. The resulting hash must be smaller than 2 ^ (256 - 1/64) or the block
is invalid. That means about 1% of blocks are discarded.
4. For each difficulty retarget, the secondary target is decreased by 2
^ 1/64.
5. After 546096 blocks or 10 years, the secondary target becomes 2 ^
252. Therefore only 1 in 16 hash returned by hasher is really valid.
This should make the detection of block withholding attack much easier.
All miners have to sacrifice 1% reward for 10 years. Confirmation will
also be 1% slower than it should be.
If a node (full or SPV) is not updated, it becomes more vulnerable as an
attacker could mine a chain much faster without following the new rules.
But this is still a softfork, by definition.
---------------
ok, back to topic. Do you mean this?
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-June/001506.html
Peter Todd via bitcoin-dev 於 2015-12-19 13:42 寫到:
> At the recent Scaling Bitcoin conference in Hong Kong we had a chatham
> house rules workshop session attending by representitives of a super
> majority of the Bitcoin hashing power.
>
> One of the issues raised by the pools present was block withholding
> attacks, which they said are a real issue for them. In particular,
> pools
> are receiving legitimate threats by bad actors threatening to use block
> withholding attacks against them. Pools offering their services to the
> general public without anti-privacy Know-Your-Customer have little
> defense against such attacks, which in turn is a threat to the
> decentralization of hashing power: without pools only fairly large
> hashing power installations are profitable as variance is a very real
> business expense. P2Pool is often brought up as a replacement for
> pools,
> but it itself is still relatively vulnerable to block withholding, and
> in any case has many other vulnerabilities and technical issues that
> has
> prevented widespread adoption of P2Pool.
>
> Fixing block withholding is relatively simple, but (so far) requires a
> SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We should
> do this hard-fork in conjunction with any blocksize increase, which
> will
> have the desirable side effect of clearly show consent by the entire
> ecosystem, SPV clients included.
>
>
> Note that Ittay Eyal and Emin Gun Sirer have argued(1) that block
> witholding attacks are a good thing, as in their model they can be used
> by small pools against larger pools, disincentivising large pools.
> However this argument is academic and not applicable to the real world,
> as a much simpler defense against block withholding attacks is to use
> anti-privacy KYC and the legal system combined with the variety of
> withholding detection mechanisms only practical for large pools.
> Equally, large hashing power installations - a dangerous thing for
> decentralization - have no block withholding attack vulnerabilities.
>
> 1) http://hackingdistributed.com/2014/12/03/the-miners-dilemma/
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:46:52

- reply

📅 Original date posted:2015-12-19
📝 Original message:I have done some calculation for the effect of a SW softfork on the
actual total block size.
Definitions:
Core block size (CBS): The block size as seen by a non-upgrading full
node
Witness size (WS): The total size of witness in a block
Total block size (TBS): CBS + WS
Witness discount (WD): A discount factor for witness for calculation of
VBS (1 = no discount)
Virtual block size (VBS): CBS + (WS * WD)
Witness adoption (WA): Proportion of new format transactions among all
transactions
Prunable ratio (PR): Proportion of signature data size in a transaction
With some transformation it could be shown that:
TBS = CBS / (1 - WA * PR) = VBS / (1 - WA * PR * (1 - WD))
sipa suggested a WD of 25%.
The PR heavily depends on the transaction script type and input-output
ratio. For example, the PR of 1-in 2-out P2PKH and 1-in 1-out 2-of-2
multisig P2SH are about 47% and 72% respectively. According to sipa's
presentation, the current average PR on the blockchain is about 60%.
Assuming WD=25% and PR=60%, the MAX TBS with different MAX VBS and WA is
listed at:
http://i.imgur.com/4bgTMRO.png
The highlight indicates whether the CBS or VBS is the limiting factor.
With moderate SW adoption at 40-60%, the total block size is 1.32-1.56MB
when MAX VBS is 1.25MB, and 1.22-1.37MB when MAX VBS is 1.00MB.
P2SH has been introduced for 3.5 years and only about 10% of bitcoin is
stored this way (I can't find proportion of existing P2SH address). A
1-year adoption rate of 40% for segwit is clearly over-optimistic unless
the tx fee becomes really high.
(btw the PR of 60% may also be over-optimistic, as using SW nested in
P2SH will decrease the PR, and therefore TBS becomes even lower)
I am not convinced that SW softfork should be the *only* short term
scalability solution

2023-06-07 19:46:47

- reply

📅 Original date posted:2015-12-18
📝 Original message:Jonathan Toomim via bitcoin-dev 於 2015-12-17 21:47 寫到:
> Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob
> runs the old rules. Bob creates a p2pkh address for Mallory to use.
> Mallory takes 1 BTC, and creates an invalid SegWit transaction that
> Bob cannot properly validate and that pays into one of Mallory's
> wallets. Mallory then immediately spends the unconfirmed transaction
> into Bob's address. Bob sees what appears to be a valid transaction
> chain which is not actually valid.
>
> Clueless Carol is one of the 4.9% of miners who forgot to upgrade her
> mining node. Carol sees that Mallory included an enormous fee in his
> transactions, so Carol makes sure to include both transactions in her
> block.
>
> Mallory gets free beer.
>
> Anything I'm missing?
You miss the fact that 0-conf is not safe, neither 1-conf. What you are
suggesting is just a variation of Finney attack.

2023-06-07 19:46:41

- reply

📅 Original date posted:2015-12-17
📝 Original message:This is not correct.
As only about 1/3 of nodes support BIP65 now, would you consider CLTV tx
are less secure than others? I don't think so. Since one invalid CLTV tx
will make the whole block invalid. Having more nodes to fully validate
non-CLTV txs won't make them any safer. The same logic also applies to
SW softfork.
You may argue that a softfork would make the network as a whole less
secure, as old nodes have to trust new nodes. However, the security of
all content in the same block must be the same, by definition.
Anyway, I support SW softfork at the beginning, and eventually (~2
years) moving to a hardfork with higher block size limit and better
commitment structure.
Jeff Garzik via bitcoin-dev 於 2015-12-17 13:27 寫到:
>
> Illustration: If SW is deployed via soft fork, the count of nodes
> that validate witness data is significantly lower than the count of
> nodes that validate non-witness data. Soft forks are not trustless
> operation, they depend on miner trust, slowly eroding the trustless
> validation of older nodes over time.
>
> Higher security in one data area versus another produces another
> economic value distinction between the two goods in the basket, and
> creates a "pay more for higher security in core block, pay less for
> lower security in witness" dynamic.
>
> This economic distinction is not present if SW is deployed via hard
> fork.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:46:37

- reply

📅 Original date posted:2015-12-17
📝 Original message:I know my reply is a long one but please read before you hit send. I
have 2 proposals: fast BIP102 + slow SWSF and fast SWSF only. I guess no
one here is arguing for not doing segwit; and it is on the top of my
wish list. My main argument (maybe also Jeff's) is that segwit is too
complicated and may not be a viable short term solution (with the
reasons I listed that I don't want to repeat)
And also I don't agree with you that BIP102 is *strictly* inferior than
segwit. We never had a complex softfork like segwit, but we did have a
successful simple hardfork (BIP50), and BIP102 is very simple. (Details
in my last post. I'm not going to repeat)
Mark Friedenbach 於 2015-12-17 04:33 寫到:
> There are many reasons to support segwit beyond it being a soft-fork.
> For example:
>
> * the limitation of non-witness data to no more than 1MB makes the
> quadratic scaling costs in large transaction validation no worse than
> they currently are;
> * redeem scripts in witness use a more accurate cost accounting than
> non-witness data (further improvements to this beyond what Pieter has
> implemented are possible); and
> * segwit provides features (e.g. opt-in malleability protection) which
> are required by higher-level scaling solutions.
>
> With that in mind I really don't understand the viewpoint that it
> would be better to engage a strictly inferior proposal such as a
> simple adjustment of the block size to 2MB.

2023-06-07 19:46:33

- reply

📅 Original date posted:2015-12-17
📝 Original message:There are at least 2 proposals on the table:
1. SWSF (segwit soft fork) with 1MB virtual block limit, approximately
equals to 2MB actual limit
2. BIP102: 2MB actual limit
Since the actual limits for both proposals are approximately the same,
it is not a determining factor in this discussion
The biggest advantage of SWSF is its softfork nature. However, its
complexity is not comparable with any previous softforks we had. It is
reasonable to doubt if it could be ready in 6 months
For BIP102, although it is a hardfork, it is a very simple one and could
be deployed with ISM in less than a month. It is even simpler than
BIP34, 66, and 65.
So we have a very complicated softfork vs. a very simple hardfork. The
only reason makes BIP102 not easy is the fact that it's a hardfork.
The major criticism for a hardfork is requiring everyone to upgrade. Is
that really a big problem?
First of all, hardfork is not a totally unknown territory. BIP50 was a
hardfork. The accident happened on 13 March 2013. Bitcoind 0.8.1 was
released on 18 March, which only gave 2 months of grace period for
everyone to upgrade. The actual hardfork happened on 16 August.
Everything completed in 5 months without any panic or chaos. This
experience strongly suggests that 5 months is already safe for a simple
hardfork. (in terms of simplicity, I believe BIP102 is even simpler than
BIP50)
Another experience is from BIP66. The 0.10.0 was released on 16 Feb
2015, exactly 10 months ago. I analyze the data on
https://bitnodes.21.co and found that 4600 out of 5090 nodes (90.4%)
indicate BIP66 support. Considering this is a softfork, I consider this
as very good adoption already.
With the evidence from BIP50 and BIP66, I believe a 5 months
pre-announcement is good enough for BIP102. As the vast majority of
miners have declared their support for a 2MB solution, the legacy 1MB
fork will certainly be abandoned and no one will get robbed.
My primary proposal:
Now - 15 Jan 2016: formally consult the major miners and merchants if
they support an one-off rise to 2MB. I consider approximately 80% of
mining power and 80% of trading volume would be good enough
16 - 31 Jan 2016: release 0.11.3 with BIP102 with ISM vote requiring 80%
of hashing power
1 Jun 2016: the first day a 2MB block may be allowed
Before 31 Dec 2016: release SWSF
My secondary proposal:
Now: Work on SWSF in a turbo mode and have a deadline of 1 Jun 2016
1 Jun 2016: release SWSF
What if the deadline is not met? Maybe pushing an urgent BIP102 if
things become really bad.
In any case, I hope a clear decision and road map could be made now.
This topic has been discussed to death. We are just bringing further
uncertainty if we keep discussing.
Matt Corallo via bitcoin-dev 於 2015-12-16 15:50 寫到:
> A large part of your argument is that SW will take longer to deploy
> than a hard fork, but I completely disagree. Though I do not agree
> with some people claiming we can deploy SW significantly faster than a
> hard fork, once the code is ready (probably a six month affair) we can
> get it deployed very quickly. It's true the ecosystem may take some
> time to upgrade, but I see that as a feature, not a bug - we can build
> up some fee pressure with an immediate release valve available for
> people to use if they want to pay fewer fees.
>
> On the other hand, a hard fork, while simpler for the ecosystem to
> upgrade to, is a 1-2 year affair (after the code is shipped, so at
> least 1.5-2.5 from today if we all put off heads down and work). One
> thing that has concerned me greatly through this whole debate is how
> quickly people seem to think we can roll out a hard fork. Go look at
> the distribution of node versions on the network today and work
> backwards to get nearly every node upgraded... Even with a year
> between fork-version-release and fork-activation, we'd still kill a
> bunch of nodes and instead of reducing their security model, lead them
> to be outright robbed.
>

2023-06-07 19:46:25

- reply

📅 Original date posted:2015-12-16
📝 Original message:I would also like to summarize my observation and thoughts after the
Hong Kong workshop.
1. I'm so glad that I had this opportunity to meet so many smart
developers who are dedicated to make Bitcoin better. Regular conference
like this is very important for a young project, and it is particularly
important for Bitcoin, with consensus as the core value. I hope such a
conference could be conducted at least once in 2 years in Hong Kong,
which is visa-friendly for most people in both East and West.
2. I think some consensus has emerged at/after the conference. There is
no doubt that segregated witness will be implemented. For block size, I
believe 2MB as the first step is accepted by the super majority of
miners, and is generally acceptable / tolerable for devs.
3. Chinese miners are requesting consensus among devs nicely, instead of
using their majority hashing power to threaten the community. However,
if I were allowed to speak for them, I think 2MB is what they really
want, and they believe it is for the best interest of themselves and the
whole community
4. In the miners round table on the second day, one of the devs
mentioned that he didn't want to be seen as the decision maker of
Bitcoin. On the other hand, Chinese miners repeatedly mentioned that
they want several concrete proposals from devs which they could choose.
I see no contradiction between these 2 viewpoints.
Below are some of my personal views:
5. Are we going to have a "Fee Event" / "Economic Change Event" in 2-6
months as Jeff mentioned? Frankly speaking I don't know. As the fee
starts to increase, spammers will first get squeezed --- which could be
a good thing. However, I have no idea how many txs on the blockchain are
spam. We also need to consider the effect of halving in July, which may
lead to speculation bubble and huge legitimate tx volume.
6. I believe we should avoid a radical "Economic Change Event" at least
in the next halving cycle, as Bitcoin was designed to bootstrap the
adoption by high mining reward in the beginning. For this reason, I
support an early and conservative increase, such as BIP102 or 2-4-8. 2MB
is accepted by most people and it's better than nothing for BIP101
proponents. By "early" I mean to be effective by May, at least 2 months
before the halving.
7. Segregated witness must be done. However, it can't replace a
short-term block size hardfork for the following reasons:
(a) SW softfork does not allow higher volume if users are not upgrading.
In order to bootstrap the new tx type, we may need the help of
altruistic miners to provide a fee discount for SW tx.
(b) In terms of block space saving, SW softfork is most efficient for
multisig tx, which is still very uncommon
(c) My most optimistic guess is SW will be ready in 6 months, which will
be very close to halving and potential tx volume burst. And it may not
be done in 2016, as it does not only involve consensus code, but also
change in the p2p protocol and wallet design
8. Duplex payment channel / Lightning Network may be viable solutions.
However, they won't be fully functional until SW is done so they are
irrelevant in this discussion
9. No matter what is going to be done / not done, I believe we should
now have a clear road map and schedule for the community: a short-term
hardfork or not? The timeline of SW? It is bad to leave everything
uncertain and people can't well prepared for any potential radical
changes
10. Finally, I hope this discussion remains educated and evidence-based,
and no circling

2023-06-07 19:31:22

- reply

📅 Original date posted:2016-01-05
📝 Original message:A new BIP, as part of the SW softfork, is pending BIP number assignment:
https://github.com/bitcoin/bips/pull/270
This proposal defines a new transaction digest algorithm for signature
verification in version 0 and version 1 witness program, in order to
minimize redundant data hashing in verification (solving the O(n^2)
issue), and to cover the input value by the signature (a frequently
requested feature for cold wallet).
jl2012 via bitcoin-dev 於 2015-12-24 09:22 寫到:
> The SW payment address format BIP draft is ready and is pending BIP
> number assignment:
> https://github.com/bitcoin/bips/pull/267
>
> This is the 3rd BIP for segwit. The 2nd one for Peer Services is being
> prepared by Eric Lombrozo
>
> Eric Lombrozo via bitcoin-dev 於 2015-12-23 10:22 寫到:
>> I've been working with jl2012 on some SEGWIT BIPs based on earlier
>> discussions Pieter Wuille's implementation. We're considering
>> submitting three separate BIPs:
>>
>> CONSENSUS BIP: witness structures and how they're committed to blocks,
>> cost metrics and limits, the scripting system (witness programs), and
>> the soft fork mechanism.
>>
>> PEER SERVICES BIP: relay message structures, witnesstx serialization,
>> and other issues pertaining to the p2p protocol such as IBD,
>> synchronization, tx and block propagation, etc...
>>
>> APPLICATIONS BIP: scriptPubKey encoding formats and other wallet
>> interoperability concerns.
>>
>> The Consensus BIP is submitted as a draft and is pending BIP number
>> assignment: https://github.com/bitcoin/bips/pull/265 [1]
>> The other two BIPS will be drafted soon.
>>
>> ---
>> Eric
>>
>> Links:
>> ------
>> [1] https://github.com/bitcoin/bips/pull/265
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev