On Sun, Dec 20, 2015 at 12:21 PM, joe2015--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Remember this is proposed as an alternative to hardforks, which is also a
> "nuclear option". Hardforks carry significant risks such as permanently
> splitting Bitcoin into two chains if
On Sun, Dec 20, 2015 at 11:35 AM, Peter Todd wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On 20 December 2015 08:30:45 GMT-08:00, Chris Pacia
> wrote:
> >On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" <
> >bitcoin-de
On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> What I proprosed is that a consensus-critical maximum UTXO age be part
> of the protocol; UTXO's younger than that age are expected to be cached.
> For UTXO's older than that age, they can
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 later 95%
> confirmation anyway).
> On Dec 18, 2015 9:02 PM, "Jeff Ga
>From a code standpoint, based off height is easy.
My first internal version triggered on block 406,800 (~May 5), and each
block increased by 20 bytes thereafter.
It was changed to time, because time was the standard used in years past
for other changes; MTP flag day is more stable than block hei
On Fri, Dec 18, 2015 at 2:56 AM, Pieter Wuille
wrote:
> On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik wrote:
> >> You present this as if the Bitcoin Core development team is in charge
> >> of deciding the network consensus rules, and is responsible for making
> >
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 developer team should
> sign a
> > collective note stating their desire to transition to a
On Thu, Dec 17, 2015 at 1:46 PM, jl2012 wrote:
> 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
>
On Wed, Dec 16, 2015 at 5:09 PM, Jeff Garzik wrote:
> SW presents a blended price and blended basket of two goods. You can
> interact with the Service through the blended price, but that does not
> erase the fact that the basket contains two separate from similar resources.
>
>
On Wed, Dec 16, 2015 at 9:44 PM, Eric Lombrozo wrote:
> At least SW *is* a scaling solution (albeit most of the important benefits
> are long term). The issue of fee events has nothing to do with scaling - it
> has to do with economics...specifically whether we should be subsidizing
> transaction
On Wed, Dec 16, 2015 at 3:50 PM, Matt Corallo
wrote:
> 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 re
On Wed, Dec 16, 2015 at 1:36 PM, jl2012 wrote:
> 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 d
On Wed, Dec 16, 2015 at 5:09 PM, Jeff Garzik wrote:
> SW presents a blended price and blended basket of two goods. You can
> interact with the Service through the blended price, but that does not
> erase the fact that the basket contains two separate from similar resources.
>
Maybe a new analogy helps.
SW presents a blended price and blended basket of two goods. You can
interact with the Service through the blended price, but that does not
erase the fact that the basket contains two separate from similar resources.
A different set of economic actors uses one resource
On Wed, Dec 16, 2015 at 4:24 PM, Jorge Timón wrote:
> Assuming we adopt bip102, eventually you will be able to say exactly the
> same about 2 MB. When does this "let's not change the economics" finishes
> (if ever)?
>
The question is answered in the original email.
In the short term, the risk o
On Wed, Dec 16, 2015 at 3:59 PM, Pieter Wuille
wrote:
> On Wed, Dec 16, 2015 at 9:38 PM, Jeff Garzik via bitcoin-dev
> wrote:
> > 4.3. Observations on new block economic model
> >
> > SW complicates block economics by creating two separate, supply limited
> >
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 developer team should
> sign a
> > collective note stating their desire to transition to a
1. Summary
Segregated Witness (SegWitness, SW) is being presented in the context of
Scaling Bitcoin. It has useful attributes, notably addressing a major
malleability vector, but is not a short term scaling solution.
2. Definitions
Import Fee Event, ECE, TFM, FFM from previous email.
Older cl
All,
Following the guiding WP principle of Assume Good Faith, I've been trying
to boil down the essence of the message following Scaling Bitcoin. There
are key bitcoin issues that remain outstanding and pressing, that are*
orthogonal to LN & SW*.
I create multiple proposals and try multiple angl
There is no need for a BIP draft. "Turing complete" is just a fancy,
executive-impressing term for "it can run any computer program", or put
even more simply, "it can loop"
Furthermore, the specification of such a language is trivial. It is the
economics of validation that is the complex piece.
To collect things into one place, I was asked by Kanzure to cover
non-jgarzik block size BIPs in a quick summary, and the Scaling Bitcoin
conf folks have graciously allocated a bit of extra time for this.
e.g. BIP 100.5, 103, 105, 106 - "the serious ones"
If there is some input people would like
Thanks for providing an in-depth, data driven analysis.
It is surprising that zlib provides better compression at the high end. I
wonder if that is due to our specific data patterns - many zeroes - which
probably puts us into the zlib dictionary fast path.
On Sat, Nov 28, 2015 at 4:41 PM, Pete
On Fri, Nov 13, 2015 at 4:48 PM, xor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> This clearly says that funds can be frozen.
> Can the BIP65-thing be used to freeze funds or can it not be?
>
This language definitely trips up or worries several folks - it's been
mentioned a
Comments:
1) cblock seems a reasonable way to extend the protocol. Further wrapping
should probably be done at the stream level.
2) zlib has crappy security track record.
3) A fallback path to non-compressed is required, should compression fail
or crash.
4) Most blocks and transactions have ru
On Wed, Oct 28, 2015 at 4:28 PM, Sean Lynch wrote:
> On Fri, Oct 23, 2015 at 1:23 AM Lucas Betschart via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Facebook has a LevelDB fork which is maintained.
>> It's called RocksDB and the API seems to be nearly the same as for
>> Lev
Here is the beginnings of an implementation to replace leveldb with sqlite:
https://github.com/jgarzik/bitcoin/tree/2015_sqlite
It builds, but still needs work before passing tests.
It was noted that leveldb is unmaintained, and this is part of researching
alternatives that are maintained and rel
core committers) or similar.
TBD
Jeff Garzik
[btcdrak? Johnathan? Others were listed in the IRC meeting, but the
bitcoinstats site is down right here]
Further Context
---
Other resources, while not formally part of this code of conduct, can
provide useful context and guidance for
- It is true that hard forks produce a much cleaner outcome, in terms of
well defined behavior across the entire network.
- Replacing an opcode should not result in undefined behavior. The
non-upgraded behavior is defined and deterministic.
- IsStandard remains an assistant. Miners may mine non
To reduce the list noise level, drama level and promote inclusion, my own
personal preference (list admin hat: off, community member hat: on) is for
temporal bans based on temporal circumstances. Default to
pro-forgiveness. Also, focus on disruption of the list as a metric, rather
than focusing o
On Thu, Oct 1, 2015 at 5:41 AM, Marcel Jamin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I guess the question then becomes why bitcoin still is <1.0.0
>
I've said the same thing years ago. Originally the "1.0" was a target for
whenever "client mode" as planned by Satoshi wa
On Thu, Sep 24, 2015 at 7:25 AM, Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 2015-11-01
> ---
> - Open Transifex translations for 0.12
> - Soft translation string freeze (no large or unnecessary changes)
> - Finalize and close translation for
On Wed, Sep 30, 2015 at 3:56 PM, Mike Hearn wrote:
> Field experience shows it successfully delivers new features to end users
>> without a global software upgrade.
>>
>
> The global upgrade is required for all full nodes in both types. If a full
> node doesn't upgrade then it no longer does what
On Wed, Sep 30, 2015 at 1:11 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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
Right; In general, the consensus is to decouple from Bitcoin Core releases.
On Wed, Sep 30, 2015 at 1:57 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via
> bitcoin-dev wrote:
> > 2015-12-01
This sounds like a cool competition; it is also off-topic for this mailing
list, which is focused on bitcoin protocol and reference implementation
development.
On Wed, Sep 30, 2015 at 2:37 AM, Richard Olsen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> All,
>
> We are looking
On Tue, Sep 29, 2015 at 8:07 PM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> What happened years ago is not really relevant as Bitcoin has changed and
>> the stakeholders have expanded. What is relevant is the actual
>> description. Whatever you want to discus
On Tue, Sep 29, 2015 at 7:16 PM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On 9/29/2015 7:02 PM, Jonathan Toomim (Toomim Bros) wrote:
>
>> Making statements about a developer's personal character is also
>> off-topic for this list.
>>
>
> If that were true the
ACK
On Thu, Sep 24, 2015 at 7:25 AM, Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello all,
>
> The next major release of Bitcoin Core, 0.12.0 is planned for the end of
> the year. Let's propose a more detailed schedule:
>
> 2015-11-01
> ---
This is off-topic for this list.
On Sun, Sep 27, 2015 at 1:53 PM, Neil Haran via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi,
>
> I have an idea for a gamified bitcoin mining app that I'd like to partner
> with someone on that is very good with cryptography and knows the bi
This was discussed in IRC, but (did I miss it?) never made it to the list
outside of being buried in a longer summary.
There is a common complain that bitcoin-dev is too noisy. The response
plan is to narrow the focus of the list to near term technical changes to
the bitcoin protocol and its impl
know who
> those few are, so even if they all wrote "Yeah, we'll do that," I wouldn't
> recognize that I got what I wanted.
>
> notplato
>
> On Tue, Sep 22, 2015 at 11:12 AM, Jorge Timón <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
During Scaling Bitcoin, Bitcoin Core committers and notable contributors
got together and chatted about where a "greatest common denominator" type
consensus might be. The following is a without-attribution (Chatham House)
summary. This is my own personal summary of the chat; any errors are my
own
d *always* be uncontroversial because
> essentially functionality is not changing. If functionality changes (e.g.
> you try to sneak in a big fix or feature tweak "because it's small") the PR
> should be rejected outright. Additionally, if we break down refactoring
> into t
[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 lib.
To someone not closely reviewing the seemingly endless stream of
libconsensu
Take a look at the latest update:
- swiped Tier Nolan verbiage, which I agree was usefully more clear
- added 'M' suffix and removed 'V' from coinbase scriptSig
On Thu, Sep 3, 2015 at 12:32 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 1. I think there is no need
in general for markets and systems. Thus the
binary conclusion of "not get used" or "volatility"
On Thu, Sep 3, 2015 at 10:31 AM, Jeff Garzik wrote:
> It's written as 'a' and/or 'b'. If you don't have idle hashpower, then
> payi
ame theory choice can be to avoid
paying-for-diff even when the network desperately needs an upgrade.
On Thu, Sep 3, 2015 at 2:57 AM, Gregory Maxwell wrote:
> On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev
> wrote:
> > (b) requiring miners to have idle
> > hashp
2. max(current hardLimit / 1.2, 80-percentile)
> 3. current hardLimit
> 5. version 4 block: the coinbase of a version 4 block must match
>this pattern: "/BV\d+/"
>6. 70% rule: If 8,400 of the last 12,000 blocks are version 4 or
>greater, reject inv
he median of the followings:
> >
> > min(current hardLimit * 1.2, 20-percentile)
> > max(current hardLimit / 1.2, 80-percentile)
> > current hardLimit
> >
> > version 4 block: the coinbase of a version 4 block must match this
> pattern:
> > "/BV\d+/
Thanks for the link. I readily admit only having given pay-to-future-miner
a little bit of thought. Not convinced it sets a minimal tx fee in all
cases.
On Thu, Sep 3, 2015 at 12:55 AM, wrote:
> Jeff Garzik via bitcoin-dev 於 2015-09-03 00:05 寫到:
>
>> Schemes proposing to pay wit
Oh, and answering your question about the 1M: It is a safety rail. It can
perform no worse on the low end than the current system. Eliminates
unlikely scenarios that squeeze users.
On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr wrote:
> On Wednesday, September 02, 2015 11:58:54 PM Jeff Gar
Schemes proposing to pay with difficulty / hashpower to change block size
should be avoided. The miners incentive has always been fairly
straightforward - it is rational to deploy new hashpower as soon as you can
get it online. Introducing the concepts of (a) requiring out-of-band
collusion to ch
size at any time, without a vote.
On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr wrote:
> On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev
> wrote:
> > The repo: https://github.com/jgarzik/bip100
>
> What is the purpose of the newly added 1 MB floor? It se
BIP 100 initial public draft:
https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
Emphasis on "initial" This is a starting point for the usual open source
feedback/iteration cycle, not an endpoint that Must Be This Way.
___
bitcoin-dev mail
Oops, link paste fail.
The repo: https://github.com/jgarzik/bip100
On Wed, Sep 2, 2015 at 7:51 PM, Jeff Garzik wrote:
> Opened a repo containing the full text of BIP 100 discussion document, in
> markdown format.
>
> The BIP 100 formal spec will be checked in here as well, befor
Opened a repo containing the full text of BIP 100 discussion document, in
markdown format.
The BIP 100 formal spec will be checked in here as well, before submitting
to upstream bips.git repo.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundatio
block size that has a
> vote or the block size with the most votes or something else?
>
> On Mon, Aug 24, 2015 at 10:40 AM Jeff Garzik wrote:
>
>> Great questions.
>>
>> - Currently working on technical BIP draft and implementation, hopefully
>> for ScalingBit
There is a duplicated column.
BIP 100 voting is /BV\d+/
On Fri, Aug 21, 2015 at 9:24 AM, Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I hacked together a simple tracking page for the 'block votes', it
> currently includes the 8MB vote and XT, as well as th
Great questions.
- Currently working on technical BIP draft and implementation, hopefully
for ScalingBitcoin.org. Only the PDF is publicly available as of today.
- Yes, the initial deployment is in the same manner as size votes.
On Fri, Aug 21, 2015 at 7:38 PM, Andrew C via bitcoin-dev <
bitcoi
I don't see any link to data backing up "Bloom filter usage has declined
significantly"
Is there actual data showing this feature's use is declining or
non-existent?
On Fri, Aug 21, 2015 at 1:55 AM, Peter Todd wrote:
> On Fri, Aug 21, 2015 at 01:48:23AM -0400, Jeff
If this is widely deployed + enabled, what is the impact to current wallets
in use?
On Fri, Aug 21, 2015 at 12:46 AM, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Peter: Since I stole most of this text from your old BIP, should I leave
> you as an author?
>
> BI
As jl2012 indicated, this is an insufficient analysis.
You cannot assume that because X time passed since the last block, the
miner's internal block maker has updated the template, and from there, is
shipped out to the hashers in the field. Further, even if you update the
block template at time Y
bitcoin-dev for protocol discussion and bitcoin-core for Bitcoin Core
discussion?
As Jorge notes, a general discussion list has existed for a long time with
little use.
On Wed, Aug 19, 2015 at 5:58 AM, Btc Drak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Aug 19, 20
A lot of this detail and worry is eliminated by simply asking BIP 102
maintainers to change to a different bit that works best for everyone.
Existing nVersion garbage will get buried in sufficient time window to
prevent anything from triggering.
Just settle on a specific standard, reserve bits for
In times of controversy or flamewar on the Linux kernel mailing list,
occasionally fake "Linus Torvalds" or other spoofed posts would appear. It
is the nature of email. Just ignore it.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
h
"minimum" an interesting topic.
- Traffic levels may not produce a minimum size block
- Miners can always collude to produce a lowered maximum block size, a sort
of minimum maximum
On Sun, Aug 16, 2015 at 12:41 PM, Levin Keller via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
Many miners are already voting on BIP 100 -- see the blocks published.
The BIP itself should be submitted w/ implementation in the next 2 weeks.
On Wed, Aug 12, 2015 at 12:44 PM, odinn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash:
+1 Glad to see this work.
The Bitcoin Core wallet is a bit neglected these days - maintained but not
advancing.
On Tue, Aug 11, 2015 at 5:02 AM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi
> (excuse
I wouldn't go quite that far. The reality is somewhere in the middle, as
Bryan Cheng noted in this thread:
Quoting BC,
> Upgrading to a version of Bitcoin Core that is incompatible with your
ideals is in no way a forced choice, as you have stated in your email;
forks, alternative clients, or stay
Addendum:
Please do not interpret - as many have - my points as advocating against
letting a fee market ever develop(!).
Fees are useful against DoS, increasing cost of attack etc. Further,
continuing the artificially-low fee policy ad infinitum is unsustainable
and constitutes a moral hazard.
On Wed, Jul 22, 2015 at 11:03 AM, Alex Morcos wrote:
> Over the last 6 years there may not have been fee pressure, but certainly
> there was the expectation that it was going to happen. Look at all the
> work that has been put into fee estimation, why do that work if the
> expectation was there
On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I don't agree with you at all.
>
> This is a case where if Jeff doesn't understand that issue, he's
> proposing changes that he's not competent enough to understand, and it'd
> save us a l
On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Some people have called the prospect of limited block space and the
> development of a fee market a change in policy compared to the past. I
> respectfully disagree with that. Bitcoin C
Opening a mailing list thread on this BIP:
BIP PR: https://github.com/bitcoin/bips/pull/173
Code PR: https://github.com/bitcoin/bitcoin/pull/6451
The general intent of this BIP is as a minimum viable alternative plan to
my preferred proposal (BIP 100).
If agreement is not reached on a more compr
It sounds like you are seeking transaction expiration from the mempool, not
CPFP.
On Sat, Jul 11, 2015 at 4:30 PM, Dan Bryant wrote:
> I think a compromise will be somewhere in the middle. I think most people
> would be OK with TXs that don't have enough fees for P2P transfer to stay
> in dea
The miners with invalid blocks were punished with a loss of bitcoin
income...
On Sat, Jul 11, 2015 at 4:05 AM, Nathan Wilcox
wrote:
> Thesis: The disincentive miners have for verifying transactions is
> problematic and weakens the network's robustness against forks.
>
> According to the 2015-07
This is a good explanation but it does not address reachability. TX_a, the
first tx sent out on the network, presumably has insufficient fee to get
mined - which also means it did not necessarily even reach all miners.
Simply sending out TX_b with added fee does not guarantee that nodes
suddenly
CPFP is interesting, but it does not fully cover the case it is trying to
address: If TX_a goes out without sufficient fee, sending out a new TX_b
will not help TX_a suddenly reach nodes/miners that ignored TX_a.
On Fri, Jul 10, 2015 at 12:09 PM, Richard Moore wrote:
> Hey guys,
>
> With all
On Fri, Jul 3, 2015 at 1:33 AM, Jeremy Rubin <
jeremy.l.rubin.tra...@gmail.com> wrote:
> Moxie looks fantastic! The reason I thought RISC-V was a good selection is
> the very active development community which is pushing the performance of
> the ISA implementations forward. Can you speak to the he
If the freedom to pick architecture exists, Moxie is a nice, compact, easy
to audit alternative:
http://moxielogic.org/blog/pages/architecture.html
https://github.com/jgarzik/moxiebox
Scaling can occur at the core level, rather than hyper-pipelining, keeping
the architecture itself nice
Older nodes have been phased out in the past. For example, protocol
versions older than 209 were phased out.
Follow the yellow brick git trail starting at
18c0fa97d0408a3ee8e4cb39c08156f7667f99ac
On Sat, Jun 27, 2015 at 3:53 PM, Natanael wrote:
> Old versions of software that can't be sandbox
Generally agreed w/ all this.
To preserve digital signatures now and in the future, and make mbox
archives actually useful, a minimum modification policy is needed.
On Sat, Jun 27, 2015 at 3:21 PM, grarpamp wrote:
> On Sun, Jun 21, 2015 at 9:14 PM, Frank Flores wrote:
> > If you're going to
ecause the block chain does not offer what they need. That's
> sad, but it is inevitable at any size: some uses fit, some don't.
>
> --
> Pieter
> On Jun 26, 2015 7:57 PM, "Jeff Garzik" wrote:
>
>> It is not "fear" of fee pressure.
>>
On Fri, Jun 26, 2015 at 8:24 AM, Pieter Wuille
wrote:
> On Fri, Jun 26, 2015 at 5:22 PM, Milly Bitcoin
> wrote:
>
>> >None of this is a reason why the size can't increase. However, in my
>> opinion, we should do it because we believe it increases utility and
>> understand the risks; not because
It is not "fear" of fee pressure.
1) Blocks are mostly not-full on average.
2) Absent long blocks and stress tests, there is little fee pressure above
the anti-spam relay fee metric, because of #1.
3) As such, inducing fee pressure is a delta, a change from years-long
bitcoin economic policy. E
On Thu, Jun 25, 2015 at 6:41 AM, Eric Lombrozo wrote:
> Wladimir is doing an amazing job under difficult circumstances. Give the
> guy a break, please
A+ agreed. He is not an elected decider - he is the Bitcoin Core release
manager, and has been doing a damn fine job.
_
Ladies & gents, please do not feed the troll. This has been explained to
Milly multiple times in the past, on previous mailing list & github with no
impact.
On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin wrote:
> I'm sorry but that is the kind of defensive, cultish response everyone
> gets wh
BIPs are accepted into BIP repo with a low "reasonable" threshold.
Code is accepted into the Bitcoin Core repo when it is likely that the
community will accept a change.
There is no voting in the way you think. Devs commit changes the users will
accept and use. Users "fire" developers by choosin
e done it."
> >
> > You did address that, to be fair - in your TODO, this link:
> > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
> >
> > contained the following link:
> >
> > http://gavinandresen.ninja/bigger-blocks-another-way
> >
>
test 2
___
Bitcoin-dev mailing list
Bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
90 matches
Mail list logo
