[bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

I have written the following draft BIP for a new opcode CHECKSEQUENCEVERIFY by Mark Friedenbach, which introduces a form of relative-locktime to Bitcoin's scripting language. https://github.com/btcdrak/bips/blob/bip-checksequenceverify/bip-csv.mediawiki pre BIP: XX Title: CHECKSEQUENCEVERIFY

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Nobody is going to click that... I guess I am nobody. Here's a copy of the text:- *Dynamically Controlled Bitcoin Block Size Max Cap http://upalc.com/maxblocksize.php*

Re: [bitcoin-dev] Bitcoin XTs Tor IP blacklist downloading system has significant privacy leaks.

On Wed, Aug 19, 2015 at 4:45 PM, Mike Hearn via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: The code was peer reviewed, in the XT project. I didn't bother submitting other revisions to Core, obviously, as it was already rejected. The quantity of incorrect statements in this thread

Re: [bitcoin-dev] Bitcoin XT Fork

On Wed, Aug 19, 2015 at 7:20 PM, Peter Todd p...@petertodd.org wrote: Normal GitHub users submitting pull-reqs to Bitcoin Core can't delete other users' comments on their own pull-reqs... IMO that's an abuse of the pull-req process, and in turn, Gavin Andresens's commit access rights for the

Re: [bitcoin-dev] Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork)

On Wed, Aug 19, 2015 at 3:20 PM, Jeff Garzik jgar...@gmail.com wrote: bitcoin-dev for protocol discussion and bitcoin-core for Bitcoin Core discussion? Well -dev or both, I dont particularly see a difference at the moment, and establishing two lists isnt really going to make a difference so

Re: [bitcoin-dev] bitcoin-dev list etiquette

On Wed, Aug 19, 2015 at 11:25 PM, Gary Mulder via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: So guys, do we need a BIP to address the existence of XT and its possible impact to the block chain? I believe there is BIP99 that addresses hard forks.

Re: [bitcoin-dev] Core Devs : can you share your thoughts about all BIPs on this website ?

On Fri, Aug 21, 2015 at 11:55 AM, Yifu Guo via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I like the intend of this attempt to bring more clarity to the blocksize debate, however it would be more help to make this a information site about the current outstanding BIPs and summarize

[bitcoin-dev] Consensus based block size retargeting algorithm (draft)

I wanted to offer a potential way to adjust the block size limit in a democratic way without making it easy to game. This is meant only as a starting point for a general idea. Thresholds and exact figures and the details of the algorithm are up for debate, and possibly some formula based

Re: [bitcoin-dev] Core Devs : can you share your thoughts about all BIPs on this website ?

On Fri, Aug 21, 2015 at 6:10 AM, Nicolas Dorier via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Decision making is not the goal of this site, it is only a way to see various pros and cons of various devs on various proposals in a single place. This is for the community to have a

Re: [bitcoin-dev] Core Devs : can you share your thoughts about all BIPs on this website ?

On Fri, Aug 21, 2015 at 10:29 AM, Peter Todd via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: What might be valuable is to ask devs to explain what their threat models are, what should be at the root of their thinking about the blocksize. That's exactly what the Technical Opinion

Re: [bitcoin-dev] Core Devs : can you share your thoughts about all BIPs on this website ?

I was looking at this site recently and it's not very clear that by clicking the name you get their opinion. I would make that a separate column stated, Technical Opinion. I think you need to include more of the developers/technical people, Adam Back, Mark Friedenback, Jorge Timons, (all of who

Re: [bitcoin-dev] Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork)

On Wed, Aug 19, 2015 at 9:59 AM, Jorge Timón jti...@jtimon.cc wrote: Apparently that existed already: http://sourceforge.net/p/bitcoin/mailman/ But technical people run away from noise while non-technical people chase them wherever their voices sounds more loud. Regarding disruptors, if

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

Please note there is now a PR for this BIP[1] and also a pull request for the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2]. [1] https://github.com/bitcoin/bips/pull/179 [2] https://github.com/bitcoin/bitcoin/pull/6564 ___ bitcoin-dev mailing list

Re: [bitcoin-dev] What Lightning Is

I thought it's worth mentioning there is a specific Lightning Network development mailing list at http://lists.linuxfoundation.org/mailman/listinfo/lightning-dev and already some pretty interesting explanations in the archives. ___ bitcoin-dev mailing

Re: [bitcoin-dev] Memory leaks?

I think this thread has gotten to the stage where it should be moved to an issue on Github and not continue to CC the bitcoin-dev list (or any other list tbh). On Thu, Oct 22, 2015 at 5:27 PM, Jonathan Toomim via bitcoin-dev wrote: > You may want to add a

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

Alex, I am sorry for not communicating more clearly. Mark and I discussed your concerns from the last meeting and he made the change. The BIP text still needs to be updated, but the discussed change was added to the PR, albeit squashed making it more non-obvious. BIP68 now explicitly uses 16 bits

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

On Mon, Oct 5, 2015 at 6:26 PM, Tom Zander via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > History has shown that for many decision making processes this doesn't > work, > and this argument has been made to Core. > Until today this was essentially a rule that hurt the things

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

On Mon, Oct 5, 2015 at 5:56 PM, Mike Hearn via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > CLTV deployment is clearly controversial. Many developers other than me > have noted that hard forks are cleaner, and have other desirable > properties. I'm not the only one who sees a big

Re: [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations

This BIP was assigned number 113. I have updated the text accordingly and added credits to Gregory Maxwell. Please see the changes in the pull request: https://github.com/bitcoin/bips/pull/182 On Sat, Aug 22, 2015 at 1:57 AM, Peter Todd via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

I have changed BIPS 112 and 113 to reflect this amended deployment strategy. I'm beginning to think the issues created by Bitcoin XT are so serious it probably deserves converting OPs text into an informational BIP. On Thu, Aug 20, 2015 at 6:42 PM, Mark Friedenbach via bitcoin-dev

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

What about supporting different networks? What if I want to look up testnet for example? blockchain://mainnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a blockchain://testnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a or

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

This BIP has been assigned BIP112 by the BIP repository maintainer. I have updated the pull request accordingly. Regarding the suggestion to cannibalise version, by your own disadvantage list, we would lose fine grained control over txins which neuters the usefulness considerably. Also using

Re: [bitcoin-dev] Censorship

On Mon, Aug 31, 2015 at 10:49 AM, NxtChg wrote: >>While this topic is very interesting, I do not see how it is >>relevant to a mailing list dedicated to technical and academic debate. >>Please can you take this discussion elsewhere. > > Wow. I have Deja Vu. Where have I heard

Re: [bitcoin-dev] Censorship

While this topic is very interesting, I do not see how it is relevant to a mailing list dedicated to technical and academic debate. Please can you take this discussion elsewhere. On Mon, Aug 31, 2015 at 10:35 AM, Zach G via bitcoin-dev wrote: > When I say

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

Without commenting on your proposal at all, the general problem with licensing after the fact is you require the permission of every copyright holder in order to make the change. On Tue, Sep 1, 2015 at 2:30 PM, Ahmed Zsales via bitcoin-dev wrote: > Hello,

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

I have read the proposal. I think you missed my point: every existing transaction author would be required to agree to your proposals for them to be legal, and that's clearly impossible. You'd also need every single miner who published a block. You're much better taking the line that actually, the

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

On Sun, Aug 30, 2015 at 3:20 AM, Jorge Timón wrote: >> Some altcoins (LTC and FTC for example) have the same genesis block hash. > > That's obviously a design mistake in FTC, but it's not unsolvable. FTC could > move their genesis block to the next block (or

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

On Tue, Sep 1, 2015 at 5:12 PM, Danny Thorpe via bitcoin-dev wrote: > Rather than using an inhumanly long hex string from the genesis hash to > distinguish between mainnet and testnet, why not use the network magic bytes > instead? Much shorter, just as

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

I think it gets worse. Who are the copyright owners (if this actually applies). You've got people publishing transaction messages, you've got miners reproducing them and publishing blocks. Who are all the parties involved? Then to take pedantry to the next level, does a miner have permission to

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

Maybe Jeff can clarify but my communications with him seemed to imply he didn't think any kind of difficulty penalty scheme is workable. I strongly dispute that assertion. On Thu, Sep 3, 2015 at 7:23 PM, Jorge Timón wrote: > Greg, I believe Jeff is focusing

Re: [bitcoin-dev] BIP 100 specification

If you read between the lines of what was recently changed and why (reducing to 2MB), it seems reasonable to assume BIP101's allowance opens up some of the attack vector again. On Fri, Sep 4, 2015 at 4:37 PM, Simon Liu via bitcoin-dev wrote: > Maybe grab

Re: [bitcoin-dev] BIP 100 specification

On Thu, Sep 3, 2015 at 3:34 PM, Jeff Garzik wrote: > A discussion of rolling out BIP 100 will not be avoided :) > > It is a hard fork; it would be silly to elide discussion of these key > issues. > > I don't get the community's recent interest in avoiding certain topics. It's

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

I'm rather perplexed about this proposal. What exactly is wrong with the existing BIPs process? I mean, it seems to me anyone can publish a BIP pretty easily in the BIPs repository. There doesnt seems to be any real barrier to entry whatsoever. I know there have been all manner of aspersions, but

Re: [bitcoin-dev] Problem compiling bitcoin-core

I mailed the solution privately, but for the record he was using the wrong build option which should have been --with-gui=no On Mon, Sep 7, 2015 at 9:58 AM, Sriram Karra via bitcoin-dev wrote: > Your problem is it cannot find your Boost libs. Why exactly

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

> but allow meaningful relief to transaction volume pressure in response to > true market demand If blocksize can only increase then it's like a market that only goes up which is unrealistic. Transaction will volume ebb and flow significantly. Some people have been looking at transaction volume

Re: [bitcoin-dev] BIP 100 specification

We should avoid discussing actual hard fork/softfork deployment methodologies when discussing blocksize proposals because deployment is a separate issue. As a recent case in point, look at how BIP65 (CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy. That lead to a focused

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

Sorry not to reply earlier. I have a rather long post. I've split it into two sections, one explaining the background and secondly talking very specifically about your proposal and possible areas to look at. I think there's a key misunderstanding about BIPs and "who decides what in Bitcoin". A

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

Rusty, I think you've covered all the issues discussed now. +1 for submitting to BIPs repo to get an official number. Are you planning to write the implementation? On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi all, > >

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

On Tue, Sep 15, 2015 at 4:26 PM, Jeff Garzik wrote: > The problem comes with the impact of an unfocused stream of refactors to > key code. > > For example, there is much less long term developer impact if refactoring > were _accelerated_, scheduled to be performed in a

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

I also share a lot of Jeff's concerns about refactoring and have voiced them several times on IRC and in private to Jorge, Wladamir and Greg. I meant to do a write up but never got around to it. Jeff has quite eloquently stated the various problems. I would like to share my thoughts on the matter

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

Where do we stand now on which sequencenumbers variation to use? We really should make a decision now. On Fri, Aug 28, 2015 at 12:32 AM, Mark Friedenbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > So I've created 2 new repositories with changed rules regarding >

Re: [bitcoin-dev] Fill-or-kill transaction

On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> 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

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

On Thu, Oct 1, 2015 at 10:05 AM, Marcel Jamin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Any particular reason bitcoin versioning doesn't follow the SemVer spec? > We do: a.b.c, the next major version is, 0.12.0, and maintenance releases are 0.12.1 etc. Release candidates

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

On Sun, Sep 27, 2015 at 7:50 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 10) Waiting for nVersion bits and CHECKSEQUENCEVERIFY will significantly > delay deployment of CLTV > > It's been proposed multiple times that we wait until we can do a single >

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

Regarding the keeping nSequence for future expansion I believe this has been covered in the specification section of BIP68[1]: For transaction version >= 2, if the MSB of nSequence is unset, the field is interpreted as relative locktime, otherwise no special consensus meaning is attached (and thus

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

On Mon, Oct 5, 2015 at 6:33 PM, Peter R via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I also agree with Mike that Core's requirement for unanimous consensus > results in development grid lock and should be revisited. > There is no development gridlock. Look at the IRC logs

Re: [bitcoin-dev] Weekly development meetings on IRC

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 Corallo via bitcoin-dev > wrote: > > Google Calendar is localized, but

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

On Fri, Aug 28, 2015 at 11:24 PM, Gavin gavinandre...@gmail.com wrote: With this proposal, how much would it cost a miner to include an 'extra' 500-byte transaction if the average block size is 900K and it costs the miner 20BTC in electricity/capital/etc to mine a block? If my understanding

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

I have received a lot of feedback on the original gist[1], reddit[2], ML and IRC and have reworked the text somewhat. I also request the BIP maintainer for a BIP number assignment [1] https://gist.github.com/btcdrak/1c3a323100a912b605b5 [2]

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Mon, Dec 21, 2015 at 4:33 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Dec 8, 2015 at 6:07 AM, Wladimir J. van der Laan wrote: > > On Mon, Dec 07, 2015 at 10:02:17PM +, Gregory Maxwell via > bitcoin-dev wrote: > >> TL;DR: I propose we work

[bitcoin-dev] BIP68: Relative lock-time through consensus-enforced sequence numbers (update)

As I am sure you are aware, for the last 5 months work has been on-going to create a relative lock-time proposal using sequence numbers. The implementation can be found at https://github.com/bitcoin/bitcoin/pull/6312. The current implementation is "mempool-only" and the soft-fork would be deployed

Re: [bitcoin-dev] BIP68: Second-level granularity doesn't make sense

On Tue, Nov 24, 2015 at 4:36 AM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The downside of BIP68 as written is users of by-height locktimes have 14 > bits unused in nSequence, but by-time locktimes have just 5 bits unused. > This presents an awkward situation if

Re: [bitcoin-dev] BIP 2 promotion to Final

On Wed, Mar 16, 2016 at 10:24 PM, Luke Dashjr wrote: > BIP Comments are not a part of the BIP itself, merely post-completion notes > from various external parties. So having them external does not make the > BIP > any less self-contained. Right now, this information takes the

Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP

Agreed, this thread is venturing somewhat out of scope for the list. Please can we redirect philosophical discussion to another forum/list such as bitcoin-discuss, which can be found at https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss Repost of the bitcoin-dev posting guidelines

Re: [bitcoin-dev] Status updates for BIP 9, 68, 112, and 113

Fine by me to update BIP68 and BIP112 to Final status. The forks have activated. On Fri, Jul 15, 2016 at 4:30 PM, Luke Dashjr wrote: > Daniel Cousens opened the issue a few weeks ago, that BIP 9 should > progress to > Accepted stage. However, as an informational BIP, it is not

Re: [bitcoin-dev] About ASICBoost

Sergio, It is critically important to the future of Bitcoin that consensus code avoid any unnecessary entanglements with patents because "the free market" allows you and anyone else to make consensus change proposals that rely on (unknown) patents - but this is something we should all be working

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

I think this is already covered in the BIP text:- "As of November 2016, the most recent of these changes (BIP 65, enforced since December 2015) has nearly 50,000 blocks built on top of it. The occurrence of such a reorg that would cause the activating block to be disconnected would raise

Re: [bitcoin-dev] Start time for BIP141 (segwit)

I can see how it looks but actually most of the underlying libraries have already been adapted or are almost finished being adapted for segwit. Since segwit is not live on mainnet, most are not released (either still in PR form or merged to a development branch). As a software developer, I think

Re: [bitcoin-dev] (no subject)

For continuity, Matt took the discussion to the bitcoin-discuss lists here https://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2016-October/000104.html On Sun, Oct 16, 2016 at 9:45 PM, Tom Zander via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sunday, 16 October 2016

Re: [bitcoin-dev] Start time for BIP141 (segwit)

This thread has strayed extensively off topic from the OP which asked a simple question about BIP141 signalling start params. Please move to another thread, or take more general discussion to bitcoin-discuss. Thank you. ___ bitcoin-dev mailing list

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

There actually isn't an activation threshold in Bitcoin Classic. The hard fork rules are active the moment you install the software. As was noted, there aren't any release notes, so you can be forgiven for not knowing that BIP109 support was removed and the proposal rejected. Classic recently

[bitcoin-dev] Announcements on bitcoin-dev

The purpose of this list is Bitcoin protocol discussion of all kinds, including consensus rules that require hard and soft forks and there have been many discussions about both. There is also a clear technical process for proposing, discussing and peer reviewing consensus rule changes via the BIPs

Re: [bitcoin-dev] Unique node identifiers

Nodes are by design not supposed to be identifiable in any way, including persisting identities across IPs changes or when connecting over different networks (e.g. clearnet/tor). Anything that makes Bitcoin less private is a step backwards. Also absolute node count is pretty meaningless since only

Re: [bitcoin-dev] A Segwit2x BIP

I am utterly appalled by this proposal both technically, ethically, and by the process which it has adopted. Hard forks require consensus from the entire ecosystem in order to prevent a fork, funds loss, confusion and harm to the robust guarantees of the Bitcoin system has thus far displayed. I

[bitcoin-dev] BIP proposal: Reserved nversion bits in blockheader

Hi, The following proposal reduces the number of version-bits that can be used for parallel soft-fork signalling, reserving 16 bits for non-specific use. This would reduce the number of parallel soft-fork activations using versionbits to from 29 to 13 and prevent node software from emitting false