Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

On Sun, Dec 20, 2015 at 11:35 AM, Peter Todd <p...@petertodd.org> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > > > On 20 December 2015 08:30:45 GMT-08:00, Chris Pacia <ctpa...@gmail.com> > wrote: > >On Dec 20, 2015 6:34 AM, "J

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

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

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

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

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

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

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <pieter.wui...@gmail.com> wrote: > On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > 2) If block size stays at 1M, the Bitcoin Core developer team should >

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <pieter.wui...@gmail.com> wrote: > On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > 2) If block size stays at 1M, the Bitcoin Core developer team should >

[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

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

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

On Wed, Dec 16, 2015 at 3:59 PM, Pieter Wuille <pieter.wui...@gmail.com> wrote: > On Wed, Dec 16, 2015 at 9:38 PM, Jeff Garzik via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > 4.3. Observations on new block economic model > > > > SW complic

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

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

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

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

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

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

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

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

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

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

[bitcoin-dev] Block size: It's economics & user preparation & moral hazard

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

Re: [bitcoin-dev] Standard BIP Draft: Turing Pseudo-Completeness

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.

[bitcoin-dev] Scaling Bitcoin - summarizing non-jgarzik block size BIPs

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

Re: [bitcoin-dev] Test Results for : Datasstream Compression of Blocks and Tx's

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,

Re: [bitcoin-dev] Contradiction in BIP65 text?

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

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

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

[bitcoin-dev] Proposed list moderation policy and conduct

Introduction --- This mailing list, bitcoin-dev, aim to facilitate constructive discussion of issues related to technical development of the bitcoin protocol and the Bitcoin Core reference implementation. We can achieve this, in part, by behaving well towards each other, so that

Re: [bitcoin-dev] Fwd: Bitcoin Core 0.12.0 release schedule

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

[bitcoin-dev] Scheduling refactors (was Re: Bitcoin Core 0.12.0 release schedule)

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

Re: [bitcoin-dev] Crossing the line? [Was: Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!]

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

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

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

Re: [bitcoin-dev] Design Competition

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

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

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

Re: [bitcoin-dev] libconsensus and bitcoin development process

don't 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: > >> On Tue, Sep 15

[bitcoin-dev] On bitcoin-dev list admin and list noise

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

Re: [bitcoin-dev] Bitcoin mining idea

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

Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule

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 >

[bitcoin-dev] Scaling Bitcoin conference micro-report

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

Re: [bitcoin-dev] libconsensus and bitcoin development process

hould *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 bre

[bitcoin-dev] libconsensus and bitcoin development process

[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

Re: [bitcoin-dev] BIP 100 specification

sion 4 blocks. (testnet4: 501 of last 1000) >7. 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks >are version 4 or greater, reject all version <= 3 blocks. (testnet4: 750 of >last 1000) >8. Block version number is calculated after

Re: [bitcoin-dev] block size - pay with difficulty

-diff even when the network desperately needs an upgrade. > > > > > > > On Thu, Sep 3, 2015 at 2:57 AM, Gregory Maxwell <gmaxw...@gmail.com> > wrote: > >> On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev >> <bitcoin-dev@lists.linuxfoundatio

Re: [bitcoin-dev] BIP 100 specification

ntile. > > New hardLimit is the median of the followings: > > > > min(current hardLimit * 1.2, 20-percentile) > > max(current hardLimit / 1.2, 80-percentile) > > current hardLimit > > > > version 4 block: the coinbase of a version 4 block must match thi

Re: [bitcoin-dev] block size - pay with difficulty

even when the network desperately needs an upgrade. On Thu, Sep 3, 2015 at 2:57 AM, Gregory Maxwell <gmaxw...@gmail.com> wrote: > On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > (b) requiring miners to hav

Re: [bitcoin-dev] BIP 100 specification

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

[bitcoin-dev] BIP 100 repo

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

Re: [bitcoin-dev] BIP 100 repo

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,

[bitcoin-dev] block size - pay with difficulty

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

[bitcoin-dev] BIP 100 specification

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

Re: [bitcoin-dev] BIP 100 repo

size at any time, without a vote. On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr <l...@dashjr.org> 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 ad

Re: [bitcoin-dev] Questiosn about BIP100

20th percentile, though there is some argument to take the 'mode' of several tranches On Thu, Aug 27, 2015 at 11:07 AM, Andrew C achow...@gmail.com wrote: I have been reading the pdf and one thing I can't figure out is what you mean by most common floor. Is that the smallest block size that

Re: [bitcoin-dev] Questiosn about BIP100

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

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

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 p...@petertodd.org wrote: On Fri, Aug 21, 2015 at 01:48:23AM -0400, Jeff Garzik via

Re: [bitcoin-dev] Miners are struggling with blocks far smaller than 750KB blocks and resorting to SPV mining

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

Re: [bitcoin-dev] Bitcoin XT Fork

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

Re: [bitcoin-dev] Minimum Block Size

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: Hey

Re: [bitcoin-dev] Bitcoin Core and hard forks

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 Core

Re: [bitcoin-dev] Bitcoin Core and hard forks

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