On Wed, Nov 16, 2016 at 2:58 PM, Eric Voskuil via bitcoin-dev
wrote:
> This sort of statement represents one consequence of the aforementioned bad
> precedent.
>
> Are checkpoints good now?
Checkpoints are not necessary for consensus and work is being done to
remove them completely from Bitcoin C
On Mon, Oct 17, 2016 at 1:17 PM, Tom Zander via bitcoin-dev
wrote:
> You are asking people to create everyone-can-spend transactions that would
> mean a loss of funds to everyone that used it if we do find a major flaw and
> need to rollback.
Please, nobody is asking for this.
Nobody should produ
As has been mentioned there have been a lot of time to upgrade
software to support segwit. Furthermore, since it is a softfork, there
will be plenty of time after activation too for those taking a "wait
and see" approach.
You keep insisting on "2 months after activation", but that's not how
BIP9 w
Hello, since trying to encapsulate consensus code without exposing
anything else (see my post from january
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012235.html
) wasn't succesful in getting review, I decided to turn "phase 2" into
"expose verifyHeader" again. I was previ
When would miners vote no to receive more funds?
Also, why would they spend the funds buying X once they get them?
On Oct 3, 2016 00:58, "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> One side benefit of OP_COUNT_ACKS is that it enables a completely
> dif
No, anyone with the bip32 public seed can do the same as the receiver as
"watch only". The only difference is rhat the receiver can actually spend
the coins. As gmaxwell explained, if it's expensive for everyone, it will
be also expensive for the receiver (assuming no interaction after the bip32
pu
On May 19, 2016 01:53, "Peter Todd" wrote:
tip of the tree.
> >
> > How expensive it is to update a leaf from this tree from unspent to
spent?
>
> log2(n) operations.
Updating a leaf is just as expensive as adding a new one?
That's not what I expected.
Or is adding a new one O (1) ?
Anyway, than
On May 17, 2016 15:23, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> # TXO Commitments
>
> Specifically TXO commitments proposes a Merkle Mountain Range¹ (MMR), a
> type of deterministic, indexable, insertion ordered merkle tree, which
allows
> new items to be chea
On May 12, 2016 00:43, "Timo Hanke via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> This is what I meant. If existing hardware gets forked-out it will
inevitably lead to the creation of an altcoin. Simply because the hardware
exists and can't be used for anything else both chains
On May 11, 2016 05:15, "Timo Hanke via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Again: this is unlike the hypothetical persistence of two chains after a
hardfork that is only contentious but doesn’t change the mining algorithm,
the kind of hardfork you are proposing would gu
On Mar 10, 2016 17:28, "Mustafa Al-Bassam" wrote:
>
> The fact that it takes very little time and effort to prevent a BIP from
reaching final status, means that in an base of millions of users it's
guaranteed that some disgruntled or bored person out there will attack it,
even if it's for the lulz
On Mar 10, 2016 16:51, "Mustafa Al-Bassam via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I think in general this sounds like a good definition for a hard-fork
> becoming active. But I can envision a situation where someone will try
> to be annoying about it and point to one ins
On Mar 10, 2016 02:04, "Mustafa Al-Bassam via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> >A hard-fork BIP requires adoption from the entire Bitcoin economy,
> particularly including those selling desirable goods and services in
> exchange for bitcoin payments, as well as Bitco
There's an absurd fee (non-consensus) check already. Maybe that check can
be improved, but probably the wallet layer is more appropriate for this.
On Mar 3, 2016 16:23, "Henning Kopp via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi,
> I think there is no need to do a hardfork
On Feb 6, 2016 16:37, "Gavin Andresen" wrote:
>
> Responding to "28 days is not long enough" :
Any thoughts on the "95% better than 75%" and "grace period before miner
coordination instead of after" comments ?
> I suspect there ARE a significant percentage of un-maintained full
nodes-- probably
If it is to be uncontroversial and everybody will upgrade, there's no
fear of a "veto power" and there's no good reason not to wait for 95%
block version signaling for deployment coordination, ideally using
bip9.
But that's for chosing the exact block where to start. The grace
period to give time t
On Feb 4, 2016 19:29, "Luke Dashjr via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Thursday, February 04, 2016 5:14:49 PM jl2012 via bitcoin-dev wrote:
> > ABSTRACT
> >
> > This document specifies a proposed change to the semantics of the sign
> > bit of the "version" field
Concept ACK. I've been talking about adding this to BIP99 since before
scaling bitcoin Hong Kong, so it will be nice to have a BIP to just point
to. Also I hadn't thought about concurrent deployment of 2 hardforks, nice.
On Feb 4, 2016 23:30, "Gavin Andresen via bitcoin-dev" <
bitcoin-dev@lists.li
It is true that are many levels of consensus and that term itself is
not incorrect for any of the meanings.
Maybe we should try to start distinguishing between different types of
"consensus".
In BIP99 the only concepts that are needed are "consensus rules" and
"adoption consensus" (aka "community
In the section
https://github.com/luke-jr/bips/blob/bip-biprevised/bip-biprevised.mediawiki#formally-defining-consensus
Can we please find another term for the "consensus" here (which is
often confused with "consensus rules", "consensus code" etc)?
In BIP99 I used the term "uncontroversial", but
On Fri, Jan 29, 2016 at 5:39 PM, Gavin Andresen via bitcoin-dev
wrote:
> On Thu, Jan 28, 2016 at 9:31 PM, Jannes Faber via bitcoin-dev
> wrote:
> It doesn't matter much where in the difficulty period the fork happens; if
> it happens in the middle, the lower-power fork's difficulty will adjust a
On Tue, Jan 12, 2016 at 8:17 PM, Eric Voskuil wrote:
> Jorge, first, thanks again for your work on this.
>
> Without creating and using a public blockchain interface in phase 2, how
> will you isolate the database dependency from consensus critical code?
> Is it that the interface will exist but y
After talking to some people about libconsensus in the last Hong Kong
conference I realized that my initial plan of exposing one more thing
at a time would actually probably slow things down.
There's still a promised pdf with pictures that will be released, and
actually drafting the UML pictures h
On Fri, Jan 8, 2016 at 4:50 PM, Gavin Andresen via bitcoin-dev
wrote:
> And to fend off the messag that I bet somebody is composing right now:
>
> Yes, I know about a "security first" mindset. But as I said earlier in the
> thread, there is a tradeoff here between crypto strength and code
> compl
Is there a link to the IRC discussion?
On Jan 1, 2016 12:49 AM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Tue, Dec 22, 2015 at 05:31:19PM -0800, Peter Todd via bitcoin-dev
wrote:
> > # Summary
>
> Updates from IRC discussion:
Is there a link to the IRC dis
On Dec 26, 2015 7:30 PM, "Eric Lombrozo via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I should have stated that we're assuming the actual total hashrate
remains constant.
But that's not reasonable if you are assuming that the total reward per
unit of time drops, that's what
The hashpower is a function of the block reward (subsidy + fees): it's
economically irrational to have costs greater than the reward (better just
turn off your miners) and in a perfect competition (a theoretical model)
profits tend to zero. That is, the costs tend to equal revenue (block
reward).
O
On Dec 26, 2015 5:45 PM, "Pieter Wuille via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> My opinion is that the role of Bitcoin Core maintainers is judging
whether consensus for a hard fork exists, and is technically necessary and
safe. We don't need a hashpower vote to decide whe
On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Unfortunately, this also means longer confirmation times, lower
throughput, and lower miner revenue. Note, however, that confirmations
would (on average) represent more PoW, so fewer confirma
To clarify, although I have defended the deployment of segwit as a
hardfork, I have no strong opinion on whether to do that or do it as a
softfork first and then do a hardfork to move things out of the
coinbase to a better place.
I have a strong opinion against never doing the later hardfork though
On Dec 18, 2015 9:43 PM, "Peter Todd" wrote:
> FWIW all these median time based schemes should be using median time
past: the point is to use a time that the block creator has no direct
control of, while still tying the rule to wall clock time for planning
purposes.
Well, if after the "planned cl
I believe the attacks are the same for height or median time of the prev
block are equal, only the time of the current block has more edge cases.
On Dec 18, 2015 9:15 PM, "Jeff Garzik" wrote:
> My preference is height activation + one step per block (i.e. also
> height). Height seems KISS.
>
> A
Well, if it's not going to be height, I think median time of the previous
block is better than the time of the current one, and would also solve Chun
Wang's concerns.
But as said I prefer to use heights that correspond to diff recalculation
(because that's the window that bip9 will use for the late
I agree that nHeight is the simplest option and is my preference.
Another option is to use the median time from the previous block (thus you
know whether or not the next block should start the miner confirmation or
not). In fact, if we're going to use bip9 for 95% miner upgrade
confirmation, it wo
To me it's getting clearer and clearer that th frintier between
softforks and hardforks it's softer than we thought.
Aoftforks should start having a minimum median time deplayment day (be
it height or median time, I don't care, just not header.nTime).
TYDGFHdfthfg64565$%^$
On Fri, Dec 18, 2015 at
On Thu, Dec 17, 2015 at 8:44 PM, Peter Todd via bitcoin-dev
wrote:
> If Bitcoin remains decentralized, miners have veto power over any
> blocksize increases. You can always soft-fork in a blocksize reduction
> in a decentralized blockchain that actually works.
You can always schism hardfork miner
Although I agree that how safe a pre-hardfork upgrade period is depends on
the complexity of the changes (we should assume everyone may need time to
reimplementat it themselves in their own implementations, not just upgrade
bitcoin core) and bip102 is indeed a very simple hardfork, I think less
tha
On Dec 16, 2015 10:08 PM, "Jeff Garzik via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille
wrote:
>>
>> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
>> wrote:
>> > 2) If block size stays at 1M, the Bitcoin Core develo
On Fri, Dec 11, 2015 at 10:45 PM, Luke Durback wrote:
>>If it's voting for something consensus, you will need something special. If
>> it's not consensus (ie external) thw voting doesn't have to hit the chain at
>> all.
>
> I had in mind voting for something that can't be trusted if done externall
On Dec 9, 2015 5:40 PM, "Gavin Andresen" wrote:
>
> On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> I think it would be logical to do as part of a hardfork that moved
>> commitments generally; e.g. a better position for merged m
well "only executed once" (every time someone verifies that transaction)...
On Dec 11, 2015 4:36 PM, "Jorge Timón" wrote:
>
> On Dec 10, 2015 7:36 AM, "Luke Durback" wrote:
> >
> > Tomorrow, I'll work on writing a way to do voting on proposals with BTC
> used as voting shares (This will be diffi
On Dec 10, 2015 7:36 AM, "Luke Durback" wrote:
>
> Tomorrow, I'll work on writing a way to do voting on proposals with BTC
used as voting shares (This will be difficult as I do not know FORTH).
That seems like a fairly simple, useful example that will require loops and
reused functions. I'll add
On Dec 10, 2015 10:10 AM, "Luke Durback via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> This, combined with the ability to make new transactions arbitrarily
would allow a function to pay its creator.
I don't understand what you mean by "a function" in this context, I assume
you
Fair enough.
On Dec 9, 2015 4:03 PM, "Gregory Maxwell" wrote:
> On Wed, Dec 9, 2015 at 7:54 AM, Jorge Timón wrote:
> > From this question one could think that when you said "we can do the
> > cleanup hardfork later" earlier you didn't really meant it. And that
> > you will oppose to that hardfor
On Wed, Dec 9, 2015 at 7:29 AM, Gregory Maxwell via bitcoin-dev
wrote:
> What was being discussed was the location of the witness commitment;
> which is consensus critical regardless of where it is placed. Should
> it be placed in an available location which is compatible with the
> existing netwo
On Wed, Dec 9, 2015 at 1:58 AM, Jorge Timón wrote:
> struct hashRootStruct
> {
> uint256 hashMerkleRoot;
> uint256 hashWitnessesRoot;
> int32_t nHeight;
> }
Or better, for forward compatibility (we may want to include more
things apart from nHeight and hashWitnessesRoot in the future):
struct ha
On Wed, Dec 9, 2015 at 12:59 AM, Gregory Maxwell via bitcoin-dev
wrote:
> On Tue, Dec 8, 2015 at 3:12 PM, Gavin Andresen via bitcoin-dev
> wrote:
> We already have consensus critical enforcement there, the height,
> which has almost never been problematic. (A popular block explorer
> recently mis
On Dec 9, 2015 7:41 AM, "Jonathan Toomim via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I also think that a hard fork is better for SegWit, as it reduces the
size of fraud proofs considerably, makes the whole design more elegant and
less kludgey, and is safer for clients who do
On Dec 8, 2015 7:08 PM, "Wladimir J. van der Laan via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> - Gregory linked to an implementation but as he mentions it is not
completely
> finished yet. ETA for a Segwit testnet is later this month, then you
can test as well.
Testnet4
Both CPFP and RBF are relay/mining policy and cannot be made consensus
rules because you cannot know which transactions have been received by a
givrn peer and which have not (or at what time). Consensus rules can only
validate information that's in the blockchain.
On Nov 29, 2015 5:33 AM, "Vincent
On Nov 26, 2015 12:06 AM, "Mark Friedenbach via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Again my objection would go away if we renamed nSequence, but I actually
think the nSequence name is better...
I suggested to rename nSequence to nMaturity on this list even before the
bi
On Nov 24, 2015 1:21 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Whatever we call it, deciding on that is a simple s/FOO/BAR/ prior to
> release.
While I agree we're not in a hurry, the more we wait, the longer docs (to
be modified later) will accumulate ma
I agree, I believe the first name that an op with equivalent functionality
had was simply op_maturity.
At least I remember we discussed such an opcode when discussing pegged
sidechains' design.
I kind of dislike the check_x_verify naming pattern. We want all new
operands to return if whatever they
On Tue, Nov 17, 2015 at 11:17 PM, telemaco via bitcoin-dev
wrote:
> Shouldn't a odbc jdbc jconnect or equivalent be totally transparent for the
> consensus code?
Yes, but we're only testing levelDB and we couldn't assure that it
won't produce unintentional consensus forks with other databases
beh
I can always link to the BIP when I reopen that commit as independent
instead of the other way around.
Btw, the PR needs rebase (probably the conflict is in the README).
On Mon, Nov 16, 2015 at 11:10 PM, Marco Pontello wrote:
> OK, adding the relevant code fragment is probably the simplest and di
On Wed, Nov 18, 2015 at 10:13 AM, Shuning Hong wrote:
> 2015-11-15 20:16 GMT+08:00 Jorge Timón
> :
>> The time threshold must be set enough in the future to give users time to
>> upgrade. But we can perceive miners' adoption, so if the system knows they
>> haven't upgraded, it should wait for t
Not a native english speaker myself, so I may have missed some things...
Yes, sorry about the link. I guess you can point to #6230 . I can
rebase it if needed but I would close it again because I don't want to
have too many things from #6382 opened at the same time (is noisy and
worse for review).
On Mon, Nov 16, 2015 at 2:52 AM, Rusty Russell wrote:
> We have strayed far from both the Subject line and from making progress
> on bitcoin development. Please redirect to bitcoin-discuss.
>
> I have set the moderation bits on the three contributors from here down
> (CC'd): your next post will g
On Sat, Nov 14, 2015 at 10:11 PM, Luke Dashjr wrote:
> On Saturday, November 14, 2015 10:52:12 AM Jorge Timón via bitcoin-dev wrote:
>> Currently bip99 recommends 95% miner upgrade confirmation with version bits
>> (bip9) for uncontroversial hardforks just like it does for
Thank you for incorporating the feedback, specifically thank you for
using the genesis block hash as the unique chain ID.
I wen't through the BIP draft and left a few of comments, but I really
like its simplicity and focus. Good work!
On Sun, Nov 15, 2015 at 3:14 AM, Marco Pontello via bitcoin-de
Going back on topic, I believe libconsensus shouldn't depend on any
particular database because assuming it will continue to be stateless
(the current libbitcoinconsensus is stateless) end therefore has no
storage. I know some people disagree in various degrees.
At the same time, the parts of the c
On Nov 15, 2015 5:10 AM, "Peter R via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> What rules does Bitcoin obey?
Thanks to the worl of many people, part of the consensus rules are finally
encapsulated in the libbitcoinconsensus library. I'm currently writing a
document to compl
I agree with the usefulness of at least trying to define a formal set
of criteria.
I'm afraid that with proposals that schedule future increases to the
blocksize consensus maximum or leave it for miners to decide (like
BIP100, BIP101 and BIP103) cannot be evaluated without making
assumptions about
Currently bip99 recommends 95% miner upgrade confirmation with version bits
(bip9) for uncontroversial hardforks just like it does for uncontroversial
softforks. It is true that in the case of hardforks miners don't decide and
it's the whole economy who has to upgrade before activation, but "the wh
On Thu, Nov 12, 2015 at 9:12 PM, Luke Dashjr via bitcoin-dev
wrote:
> On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev wrote:
>> * Mining code will use starting priority for ease of implementation
>
> This should be optional, at least for 0.12.
The ease of implementation is
On Thu, Nov 5, 2015 at 8:36 PM, Luke Dashjr wrote:
> Ok, then my point is that "signature malleability" is not particularly
> problematic or interesting alone, and the only way to get a practically-useful
> solution, is to address all kinds of malleability.
I disagree. Segregated witnesses, for e
On Tue, Nov 3, 2015 at 11:01 PM, Luke Dashjr via bitcoin-dev
wrote:
> On Tuesday, November 03, 2015 9:44:02 PM Christian Decker wrote:
>> So this is indeed a form of desired malleability we will likely not be able
>> to fix. I'd argue that this goes more into the direction of double-spending
>> th
On Fri, Oct 16, 2015 at 3:26 AM, Rusty Russell via bitcoin-dev
wrote:
> ... Gavin just told me about setmocktime. That's fast service!
Once more functions (specially consensus-critical functions) take
nTime explicitly as parameter instead of relying on the
library-unfriendly GetAdjustedTime(), t
On Mon, Oct 5, 2015 at 2:29 PM, Clément Elbaz wrote:
> The problem is that some transactions that are meaningless to you are
> actually meaningful to people using an upgraded Bitcoin software.
>
> Therefore during a softfork, while you can not miss the existence of a
> transaction, you can miss it
On Mon, Oct 5, 2015 at 2:10 PM, Mike Hearn wrote:
> Hi Jorge,
>
> I'm glad we seem to be reaching agreement that hard forks aren't so bad
> really and can even have advantages. It seems the remaining area of
> disagreement is this rollout specifically.
>>
>> a non-upgraded full node and an upgrade
On Fri, Oct 2, 2015 at 4:12 AM, GC via bitcoin-dev
wrote:
> Or, you know, enter some discussions on what exactly are the issues that SPV
> clients face during soft forks and see if anything can be done (on all
> sides) to mitigate the risks.
This has already been discussed. The recommended risk m
"Consensus" it's a term we use for consensus critical code and we
refer to different machines (potentially with different software)
validating in exactly the same way.
I think also using the term for people agreeing on what those
consensus rules is confusing, so in BIP99 I used the term
"uncontrove
On Oct 5, 2015 2:08 PM, "Clément Elbaz" wrote:
>
> It will get correct results about :
> - the existence every block
> - the existence of every transaction
>
> It will get incorrect results :
> - about the nature of some transactions
Given the assumptions above, only of transactions without enoug
On Oct 5, 2015 1:28 PM, "Mike Hearn via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Well, let's agree to disagree on these two things:
>
> - I define "working" for a full node as verifying everything; if a node
starts skipping bits then I'd say it's not really "working" accordi
On Oct 2, 2015 12:46 PM, "NxtChg" wrote:
>
>
> >...obviously not for so called "ASIC-resistance" [an absurd term coined
to promote some altcoins]
>
> Yet another fallacy of "all-or-nothing" thinking, which is so abundant in
the Core camp.
>
> The fact that you can build ASIC for any kind of algori
On Oct 2, 2015 10:03 AM, "Daniele Pinna via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> should an algorithm that guarantees protection from ASIC/FPGA
optimization be found.
This is demonstrably impossible: anything that can be done with software
can be done with hardware. This
On Oct 1, 2015 12:14 AM, "Jorge Timón" wrote:
>
> On Wed, Sep 30, 2015 at 11:06 PM, Mike Hearn wrote:
> >> Exactly, all those "mini divergences" eventually disappear
> >
> > A miner that has accepted a newly invalid transaction into its memory
pool
> > and is trying to mine it, will keep producin
On Wed, Sep 30, 2015 at 11:06 PM, Mike Hearn wrote:
>> Exactly, all those "mini divergences" eventually disappear
>
> A miner that has accepted a newly invalid transaction into its memory pool
> and is trying to mine it, will keep producing invalid blocks forever until
> the owner shuts it down an
On Sep 30, 2015 9:56 PM, "Mike Hearn via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Jorge has said soft forks always lead to network convergence. No, they
don't. You get constant mini divergences until everyone has upgraded, as
opposed to a single divergence with a hard fork (
Yes, I believe consensus rule changes don't need to be couple with
major releases, there's no problem that I can see in them being minor
releases if they're not ready on time for a major release.
On Wed, Sep 30, 2015 at 7:57 PM, Luke Dashjr via bitcoin-dev
wrote:
> On Thursday, September 24, 2015
On Wed, Sep 30, 2015 at 7:11 PM, Mike Hearn via bitcoin-dev
wrote:
> Several people have asked several times now: given the very real and widely
> acknowledged downsides that come with a soft fork, what is the specific
> benefit to end users of doing them?
As previously explained, the biggest adv
Gavin, you assume that users must necessarily always follow the
hashrate majority, but this is not true.
In fact, it is the opposite: market forces make the hashrate follow the users.
Not following the hashrate majority is not necessarily insane.
If some users aren't happy with the new hardfork ru
On Tue, Sep 29, 2015 at 2:07 PM, Mike Hearn wrote:
> Hi Jorge,
>
>> Yes, there is a difference. Assuming the hashrate majority upgrades, in
>> the case of a softfork [snip] .. In the case of a hardfork [snip]
>
> Yes, I know what the difference between them is at a technical level. You
> didn'
On Sep 28, 2015 7:14 PM, "Mike Hearn via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>> 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.
>
>
> There isn't any difference in how long the divergent state exists for.
On Wed, Sep 23, 2015 at 1:49 AM, Dave Scotese wrote:
> If I'm reading this situation correctly, Jeff is basically pointing out that
> developers need more links (hooks, rungs, handholds, data points, whatever
> you want to call them) so that they can see all the things his email
> insinuated are m
On Tue, Sep 22, 2015 at 8:27 PM, Gavin Andresen wrote:
> You need to write a high-level overview document, explaining things like:
>
> + Who should use libconsensus
Separating the consensus code is extremely important for less risky
and wider contributions regardless of what is exposed.
But once
On Fri, Sep 18, 2015 at 2:07 AM, Wladimir J. van der Laan via
bitcoin-dev wrote:
> My long-term vision of bitcoind is a P2P node with validation and blockchain
> store, with a couple of data sources that can be subscribed to or pulled from.
I agree with this long term vision.
Here's how I think
On Tue, Sep 15, 2015 at 6:10 AM, Jeff Garzik via bitcoin-dev
wrote:
> [collating a private mail and a github issue comment, moving it to a
> better forum]
>
> On libconsensus
> ---
> In general there exists the reasonable goal to move consensus state
> and code to a specific, separate
On Fri, Sep 18, 2015 at 12:44 AM, Peter Todd wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On 17 September 2015 12:14:38 GMT-07:00, "Jorge Timón via bitcoin-dev"
> wrote:
>>Fill or kill us normally used for trades and I think it can be
&
On Sep 20, 2015 10:58 PM, "Rusty Russell" wrote:
>
> Jorge Timón writes:
> > I disagree with the importance of this concern and old soft/hardforks
will
> > replace this activation mechanism with height, so that's an argument in
> > favor of using the height from the start. This is "being discusse
ep 19, 2015 4:01 AM, "Luke Dashjr" wrote:
> On Thursday, September 17, 2015 7:14:38 PM Jorge Timón via bitcoin-dev
> wrote:
> > As Mark points out this can be made safe by requiring that all the
> outputs
> > of a transaction that can expire have op_maturity/csv/
proposing to use the block time or the median block time?
For some hardforks/softforks the block time complicates the implementation
(ie in acceptToMemoryPool) as discussed in the mentioned thread.
On Sep 19, 2015 1:24 AM, "Rusty Russell" wrote:
> Jorge Timón via bitcoin-dev
> wr
s/move the genesis block forward/move your genesis checkpoint forward/
On Sep 18, 2015 4:37 PM, "Jorge Timón" wrote:
> Well, with utxo commitments at some point maybe is enough to validate the
> full headers history but only the last 5 years of ttansaction history
> (assuming utxo commitments are
Well, with utxo commitments at some point maybe is enough to validate the
full headers history but only the last 5 years of ttansaction history
(assuming utxo commitments are buried 5 years worth of blocks in the past).
This scales much better than validating the full history and if we get a 5
year
On Sep 17, 2015 6:48 PM, "Peter Todd" wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On 17 September 2015 12:14:38 GMT-07:00, "Jorge Timón via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> >Fill or k
Fill or kill us normally used for trades and I think it can be confusing.
Previous times this has been discussed it has been discussed under
nExpiryTime or op_height (which enables expiration), for example, in the
freimarkets white paper.
As Mark points out this can be made safe by requiring that
On Thu, Sep 17, 2015 at 12:38 PM, Tier Nolan via bitcoin-dev
wrote:
> The advantage of enforcing the rule when 75% is reached (but only for blocks
> with the bit set) is that miners get early notification that they have
> implemented the rule incorrectly.They might produce blocks that they
> t
I understand your proposal, but I don't see what it accomplishes compared
to applying the new rule from the start (in your own blocks) and wait for
95% for consensus activation (which is my preference and it's much simpler
to implement).
What are the disadvantages of my approach? What are the advan
On Sep 16, 2015 4:49 PM, "Tier Nolan via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
>
> On Wed, Sep 16, 2015 at 9:38 PM, Jorge Timón wrote:
>>
>> No, 95% is safer and will produce less orphaned blocks.
>
> The point of the 75% is just as a test run. Enforcement wouldn't happ
No, 95% is safer and will produce less orphaned blocks.
0%is fine to do it in your own blocks.
I agree on using height vs time. Rusty, what do you mean by being easier
for bip writers? How is writing "block x" any harder than writing "date y".
On Sep 16, 2015 4:32 PM, "Tier Nolan via bitcoin-dev"
101 - 200 of 358 matches
Mail list logo
