In the past month, there are a number of revisions in BIP141 and 143. Except
the use of BIP9 for deployment, none of these edits was a result of a change
of consensus behavior of the reference implementation. Instead, the text
were edited for clarifications or corrections to match the reference
imp
I just realize that if we have OP_CAT, OP_CHECKPRIVATEKEYVERIFY (aka
OP_CHECKPRIVPUBPAIR) is not needed (and is probably better for privacy)
Bob has the prikey-x for pubkey-x. Alice and Bob will agree to a random secret
nonce, k. They calculate r, in the same way as signing a transaction.
BIP draft: https://github.com/jl2012/bips/blob/mast/bip-mast.mediawiki
Reference implementation:
https://github.com/jl2012/bitcoin/commit/f335cab76eb95d4f7754a718df201216a49
75d8c
This BIP defines a new witness program type that uses a Merkle tree to
encode mutually exclusive branches in a script.
Do you mean BIP141?
Your example is an error by BIP141:
1*4 + 7*1 = 80003 > 8
From: bitcoin-dev-boun...@lists.linuxfoundation.org
[mailto:bitcoin-dev-boun...@lists.linuxfoundation.org] On Behalf Of Sergio
Demian Lerner via bitcoin-dev
Sent: Monday, 21 March, 2016 10:51
To: bit
Seems it could be done without any new opcode:
Bob is trading b Bitcoins for a altcoins.
1. Bob Pays D Bitcoins to
IF
CLTV DROP CHECKSIG
ELSE
HASH160 EQUALVERIFY CHECKSIG
ENDIF
2. Alice pays a altcoins to
IF
HASH160 EQUALVERIFY CHECKSIG
ELSE
HASH160 EQUALVERIFY CH
I am actually suggesting 1 hardfork, not 2. However, different rules are
activated at different time to enhance safety and reduce disruption. The
advantage is people are required to upgrade once, not twice. Any clients
designed for stage 2 should also be ready for stage 3.
-Original Message--
I would like to present a 2-3 year roadmap to a better header format and
bigger block size
Objectives:
1. Multistage rule changes to make sure everyone will have enough time to
upgrade
2. Make mining easier, without breaking existing mining hardware and the
Stratum protocol
3. Make future hardfor
Thanks for this proposal. Just some quick response:
1. The segwit hardfork (BIP HF) could be deployed with BIP141 (segwit
softfork). BIP141 doesn't need grace period. BIP HF will have around 1 year
of grace period.
2. Threshold is 95%. Using 4 versoin bits: a) BIP 141; b) BIP HF; c) BIP 141
if BI
From: Gavin Andresen [mailto:gavinandre...@gmail.com]
Sent: Friday, 5 February, 2016 06:16
To: Gregory Maxwell
Cc: jl2012 ; Bitcoin Dev
Subject: Re: [bitcoin-dev] Hardfork bit BIP
>It is always possible I'm being dense, but I still don't understand how this
>proposal makes a chain-forking situ
This looks very interesting. The first time implementing it might be more
painful but that will make subsequent hardforks a lot easier.
Do you think it's good to include the median timestamp of the past 11 blocks
after the block height in coinbase? That would make it easier to use it as
activation
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 actio
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 ha
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
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 e
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
t 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
wrote:
Do we need to consider that someone may have a tim
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 寫到:
Occur
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
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 work
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
p
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).
Rusty Russell via bitcoin-dev 於 2015-12-19 23:14 寫到:
Jonathan Toomim via bitcoin-dev
writes:
On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev
wrote:
1) The risk of an old full node wallet accepting a transaction that
is
invalid to the new rules.
The receiver wallet chooses what
Chris Priest 於 2015-12-19 22:47 寫到:
On 12/19/15, jl2012 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 theoreti
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 engag
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 concatena
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):
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
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 a
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 an
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
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 particula
-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 need
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, Dec 14, 2015 at 12:14 AM, Danny Thorpe
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 o
Fknz1ShGEIdGSaH0gqnb+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
wrote:
4. Sum of fee, sigopcount, size etc as part of the witness
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 th
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 allo
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
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 th
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
Status: Draft
Type: Standards Track
Create
The other strategy is to have an informational BIP to define "safe" use
of Bitcoin.
1. scriptPubKey must be one of the following types: P2PK, P2PKH, P2SH,
n-of-m multisig with m < 4 (with or without CLTV or CSV, we should
define standard use of CLTV and CSV)
2. For P2SH, the serialized scrip
Currently, a tx maybe included in a block only if its locktime (x) is
smaller than the timestamp of a block (y)
BIP113 says that a tx maybe included in a block only if x is smaller
than the median-time-past (z)
It is already a consensus rule that y > z. Therefore, if x < z, x < y
The new rul
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 EQUAL. The , however, is not a hash of
You are mixing multiple issues.
1. It is not possible to "checkpoint" in a totally decentralized and
trustless way. You need the whole blockchain to confirm its validity, as
a single invalid tx in the history will invalidate ALL blocks after it,
even if the invalid tx is irrelevant to you.
2
BIP68 allows per-input locktime, though I don't know how this could be
useful.
BIP68 and BIP112 are mostly ready. If we try to reimplement
relative-locktime without using nSequence, we may need to wait for
another year for deployment.
A compromise is to make BIP68 optional, indicated by a bi
According to the Oxford Dictionary, "coin" as a verb means "invent (a
new word or phrase)". Undoubtedly you created the first functional SPV
client but please retract the claim "I coined the term SPV" or that's
plagiarism.
And I'd like to highlight the following excerpt from the whitepaper:
"
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 spen
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
+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.
So
There could not be a worse timing than this for those in China (3-4am),
Japan/Korea (4-5am), and Australia (3-6am depends on which part of the
country). Maybe we have no dev in this part of the planet? Is there any
chance to review the timing in a weekly or monthly basis (also with a
doodle vot
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
wrote:
On Fri, Sep 18, 2015 at 8:27 PM, Matt
Btc Drak 於 2015-09-18 02:42 寫到:
On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev
wrote:
Btc Drak 於 2015-09-17 15:12 寫到:
Forgive me if I have missed the exact use-case, but this seems
overly
complex. Surely fill-or-kill refers to getting a transaction
confirmed
within a few confirms
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 matu
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
How many years of relative lock time do we need? It really depends why
we need a relative lock time in the first place, what what does it offer
in addition to CHECKLOCKTIMEVERIFY. The only case I know is when the
confirmation taking too long, CLTV may expire before the tx is
confirmed. For use
Inspired by Pieter's Tree Signatures, I believe Merkleized Abstract
Syntax Trees (MAST) could be implemented with only OP_CAT and OP_EVAL
(BIP12).
The idea is very simple. Using a similar example in Pieter's paper,
scriptSig = Z1 0 1 1 X6 1 K9 0
scriptPubKey = DUP HASH160 EQUALVERIFY EVA
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
h
s: /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
wrote:
*
hardLimit floats within the
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
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
Jorge Timón 於 2015-08-30 14:56 寫到:
On Sun, Aug 30, 2015 at 7:13 PM, 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
so
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_
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 w
Sorry to be off-topic but SNR of the mailing list is really getting
ridiculous.
Stop trolling and feeding the trolls.
Before you click "send", remember that your message will be sent to the
inbox of hundreds or thousands of people.
Ref:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev
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 m
We need some game theory experts to analyse this but I see there are 3
major problems:
1. Tragedy of the commons: Some miners have to scarify their income to
increase the block size, and all miners will share the beneficial
outcome of the increase. All miners would like to be free riders.
2.
I have an ugly solution to this problem, with minimal change to the
current softfork logic, and still allows all features described in
sipa's Version bits BIP
1. xVersion = nVersion AND 0b10011000
2. miners supporting BIP65 will set xVersion = 8 or greater
3. If 750 of t
Mode could be ruled out immediately. Just consider this: 34% 8MB, 33%
1.5MB, 33% 1.2MB
I personally believe the median is the most natural and logical choice.
51% of miners can always force the 49% to follow the simple majority
choice through a 51% attack. Using median will eliminate the incen
Rusty Russell 於 2015-08-26 23:08 寫到:
- We should immediately deploy an IsStandard() rule which insists that
nSequence is 0x or 0, so nobody screws themselves when we
soft fork and they had random junk in there.
This is not needed because BIP68 is not active for version 1 tx. No
exi
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
Your proposal also permanently burns a sequence bit. It depends on how
we value a nSequence bit and a nVersion bit. I think there is a
trade-off here:
1. nSequence is signed by each TxIn individually, while all TxIns must
share the same nVersion
2. If nVersion is used to indicate the meaning
Gregory Maxwell via bitcoin-dev 於 2015-08-23 21:01 寫到:
Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
discussion has any thought been given to represent one block with more
than one increment? This would leave additional space for future
signaling, or allow, for example, high
Someone is going to burn 150BTC to create a backlog of 30-day in
September.
https://www.reddit.com/r/Bitcoin/comments/3hgke4/coinwallet_says_bitcoin_stress_test_in_september/
However, the money could be spent more wisely by encouraging mining of
the first few big blocks
Assumptions:
1. OP_CSV
Peter Todd via bitcoin-dev 於 2015-08-19 01:50 寫到:
2) nVersion mask, with IsSuperMajority()
In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would
be masked away, prior to applying standard IsSuperMajority() logic:
block.nVersion & ~0x2007
This means that CLTV/CSV/etc
odinn via bitcoin-dev 於 2015-08-19 07:25 寫到:
The big problem is
BIP101 being deployed as a Schism hardfork.
This is certainly a problem.
No, BitcoinXT won't become a Schism hardfork, or may be just for a few
days, at most.
There is one, and only one scenario that BitcoinXT will win: i
Jorge Timón 於 2015-08-19 05:24 寫到:
On Tue, Aug 18, 2015 at 11:54 AM, jl2012 via bitcoin-dev
wrote:
As I understand, there is already a consensus among core dev that
block size
should/could be raised. The remaining questions are how, when, how
much, and
how fast. These are the questions for
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.
The traffic between the pool server and individual hashers is far busier
than 50kB/30s. If their bandwidth is so limited, hashers would have
switched to other pools already.
All these data may prove is they have very bad mining codes. For
example, their hashers may not be required to update th
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 X
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 wit
lectively pick and choose which of these new
consensus rules you want to apply your transaction.
On Aug 8, 2015 11:51 AM, "jl2012 via bitcoin-dev"
wrote:
BIP68 rules and some of the BIP62 rules are applied only if the tx
version is >=2 and >=3 respectively. Therefore, it is not po
BIP68 rules and some of the BIP62 rules are applied only if the tx
version is >=2 and >=3 respectively. Therefore, it is not possible to
create a tx which follows BIP62 but not BIP68. If we introduce v4 tx
later, BIP62 and BIP68 will all become mandatory.
Some rules, e.g. "scriptPubKey evaluat
Pieter Wuille via bitcoin-dev 於 2015-08-07 12:28 寫到:
On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen
wrote:
On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille
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
f
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
It won't work as you thought. If a miner has 95% of hashing power, he
would have 95% of chance to find the next block and collect the penalty.
In long term, he only needs to pay 5% penalty. It's clearly biased
against small miners.
Instead, you should require the miners to burn the penalty. Wh
atural disaster,
and these scenarios have implications for usage, scale, degree of
decentralization and security.
CS is science, there is no reason for this generation not to apply
rigorous Computer Science to Bitcoin.
Venzen
On 08/04/2015 02:50 PM, jl2012 via bitcoin-dev wrote:
As now we hav
7;s consensus rules are a consensus system, not a democracy.
Find a solution that everyone agrees on, or don't.
On Aug 4, 2015 9:51 AM, "jl2012 via bitcoin-dev"
wrote:
As now we have some concrete proposals
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808
As now we have some concrete proposals
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html),
I think we should wrap up the endless debate with voting by different
stakeholder groups.
-
Candidate proposals
Candidate proposals must be c
I have put it on the github:
https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki
I removed the specification of coinbase message to make it simpler.
Instead, it requires that a flag block must not be shared by multiple
hardfork proposals.
I'm not sure whether it is a Standard, I
Pieter Wuille 於 2015-08-01 16:45 寫到:
On Fri, Jul 31, 2015 at 10:39 AM, jl2012 via bitcoin-dev
wrote:
2. Starting date: 30 days after 75% miner support, but not before
2016-01-12 00:00 UTC
Rationale: A 30-day grace period is given to make sure everyone has
enough time to follow. This is a
Although the chance is very slim, it is possible to have multiple
hardforks sharing the same flag block. For example, different proposals
may decide the flag time based on voting result and 2 proposals may have
the same flag time just by chance. The coinbase message is to preclude
any potential
Yes, data-center operators are bound to follow laws, including NSLs
and gag orders. How about your ISP? Is it bound to follow laws,
including NSLs and gag orders?
https://edri.org/irish_isp_introduces_blocking/
Do you think everyone should run a full node behind TOR? No way, your
repressive
There is a summary of the proposals in my previous mail at
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html
I think there could be a compromise between Gavin's BIP101 and
Pieter's proposal (called "BIP103" here). Below I'm trying to play
with the parameters, whi
I am making some corrections to my previous summary
Currently, there are 4 block size BIP by Bitcoin developers:
BIP100 by Jeff:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
BIP101 by Gavin:
https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki
BIP102 by Jeff: h
Currently, there are 4 block size BIP by Bitcoin developers:
BIP100 by Jeff:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
BIP101 by Gavin:
https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki
BIP102 by Jeff: https://github.com/bitcoin/bips/pull/173/files
BIP???
Quoting Tier Nolan via bitcoin-dev :
On Thu, Jul 23, 2015 at 5:23 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
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-mi
Please feel free to comment, for technical issues and language
BIP: ??
Title: Hardfork bit
Author: jl2012
Status: Draft
Type: Standard Track
Created: 2015-07-23
Abstract
This document specifies a proposed change to the semantics of the most
significant bit of the “version” field in Bitcoin b
Quoting Peter Todd via bitcoin-dev :
-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.
Quoting Gavin Andresen via bitcoin-dev
:
On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
It also requires most clients to be updated to support the new address
system.
That's the killer: introducing Yet Another Type of Bitcoin
Quoting Peter Todd via bitcoin-dev :
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 choo
99 matches
Mail list logo
