Re: [bitcoin-dev] Bitcoin Legal Defense Fund

To belatedly answer Rene's question: Yes, we hope so. To start, the Fund will focus on the defense of the pending litigation and new litigation that may arise. However, we intend to build up the capacity to provide competent third-party advice to developers on strategies to reduce their liability.

Re: [bitcoin-dev] Idea: More decimal places for lower minimum fee

Fee rates in Bitcoin Core are measured in satoshis/kB. There are a couple places where a minimum of 1000 satoshis/kB is assumed. Setting "incrementalrelayfee" to a smaller than default value and either leaving "minrelaytxfee" unset or also setting it smaller will be sufficient to allow your node

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

I had the same concern, or a miner could fill the remainder of the block with their own high fee paying transactions if blocks were required to be full. On Fri, Sep 29, 2017 at 7:55 AM Daniele Pinna via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Maybe I'm getting this wrong but

Re: [bitcoin-dev] Responsible disclosure of bugs

I don't think I know the right answer here, but I will point out two things that make this a little more complicated. 1 - There are lots of altcoin developers and while I'm sure the majority would greatly appreciate the disclosure and would behave responsibly with the information, I don't know whe

Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]

"it was ACKed by everyone else that I heard from" - I don't think you should read into that much. I felt like this whole conversation was putting the cart before the horse. You might very well have some good ideas in your roadmap update, to tell you the truth, I didn't even read it. But I don't t

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

nd wrong statements about. See some of the past discussion on this list. On Sun, Mar 26, 2017 at 4:13 AM, Chris Pacia wrote: > > > On Mar 25, 2017 10:38 PM, "Alex Morcos via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > As a

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

Surely you are aware that what you are proposing is vastly different from the way soft forks have historically worked. First of all, the bar for miners being on the new chain is extremely high, 95%. Second of all, soft forks make rule restrictions on classes of transactions that are already non-s

Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments)

I think this conversation has gone off the rails and is no longer really appropriate for the list. But just to be clear to any readers. Bitcoin Core absolutely does rely on the impossibility of a hash collision for maintaining consensus. This happens in multiple places in the code but in particu

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

huh? can you give an example of how a duplicate transaction hash (in the same chain) can happen given BIP34? On Wed, Nov 16, 2016 at 7:00 PM, Eric Voskuil via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 11/16/2016 03:58 PM, Jorge Timón via bitcoin-dev wrote: > > On Wed, Nov

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

I think we are misunderstanding the effect of this change. It's still "OK" for a 50k re-org to happen. We're just saying that if it does, we will now have potentially introduced a hard fork between new client and old clients if the reorg contains earlier signaling for the most recent ISM soft fork

[bitcoin-dev] New Soft Fork Deployment: CSV (BIP's 68, 112, 113)

Following on my earlier message , I am happy to announce a new soft fork to be deployed using BIP 9 - Version bits. Please review BIP 9

[bitcoin-dev] Soft fork for BIPs 68, 112, and 113

Bitcoin Core is ready to move towards deployment of a soft fork which will implement BIP's 68, 112, and 113. BIP 68 - Relative lock-time using consensus-enforced sequence numbers - https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 112 - CHECKSEQUENCEVERIFY - https://github.com/bit

Re: [bitcoin-dev] [BIP Proposal] New "feefilter" p2p message

On Tue, Feb 16, 2016 at 6:46 PM, Luke Dashjr wrote: > On Tuesday, February 16, 2016 8:20:26 PM Alex Morcos via bitcoin-dev wrote: > > # The feefilter message is defined as a message containing an int64_t > where > > pchCommand == "feefilter" > > What happened

[bitcoin-dev] [BIP Proposal] New "feefilter" p2p message

Hi, I'm proposing the addition of a new optional p2p message to help reduce unnecessary network traffic. The draft BIP is available here and pasted below: https://gist.github.com/morcos/9aab223c443c9258c979 The goal of this message is to take advantage of the fact that when a node has reached it

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

I apologize if this discussion should be moved to -discuss, I'll let the moderators decide, I've copied both. And Gavin, I apologize for picking on you here, because certainly this carelessness in how people represent "facts" applies to both sides, but much of this discussion really infuriates me.

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

I'm also strongly in favor of moving forward with this plan. A couple of points: 1) There has been too much confusion in looking at segwit as an alternative way to increase the block size and I think that is incorrect. It should not be drawn into the block size debate as it brings many needed imp

[bitcoin-dev] New lower policy limits for unconfirmed transaction chains or packages

I just wanted to let everyone know that after much considered review, new lower policy limits on the number and size of related unconfirmed transactions that will be accepted in to the mempool and relayed have been merged into the master branch of Bitcoin Core for 0.12 release. The actual limits w

Re: [bitcoin-dev] Upcoming Transaction Priority Changes

To be clear Luke, its not THAT complicated to maintain the mining policy, but preserving the ability of people to place priority based transactions in a limited mempool world is quite complicated. See recently closed #6992. I think the biggest issue with #6357 is being sure the logic doesn't break

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

t; because it removes ambiguity. 512s granularity makes sense within the > > context of the 10 minute block target. > > > > Thank you for spending so much time carefully considering this BIP and > > reference implementation and please let me know if there there are any > &

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

Mark, You seemed interested in changing BIP 68 to use 16 bits for sequence number in both the block and time versions, making time based sequence numbers have a resolution of 512 seconds. I'm in favor of this approach because it leaves aside 14 bits for further soft forks within the semantics of

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

Peter, Your concern about whether this is the best way to use the nSequence field; would that be addressed by providing more high order bits to signal different uses of the field? At a certain point we're really not limiting the future at all and there is something to be said for not letting the

Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

> -Danny > > > > On Mon, Oct 5, 2015 at 11:45 AM, Alex Morcos via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I'd like to propose updates to the new policy limits on unconfirmed >> transaction chains. >> >> The existing li

Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

t; On Fri, Aug 21, 2015 at 12:22 PM, Matt Corallo via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> I dont see any problem with such limits. Though, hell, if you limited >>> entire tx dependency trees (ie transactions and all required

Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

ie transactions and all required unconfirmed >> transactions for them) to something like 10 txn, maximum two levels >> deep, I also wouldnt have a problem. >> >> Matt >> >> On 08/14/15 19:33, Alex Morcos via bitcoin-dev wrote: >> > Hi everyone, >&

Re: [bitcoin-dev] Hash of UTXO set as consensus-critical

I guess I always assumed that UTXO set commitments were an alternative security model (between SPV and full-node), not that they would cause the existing security model to be deprecated. On Fri, Sep 18, 2015 at 3:43 PM, Patrick Strateman via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wr

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

+1 sounds good to me! On Thu, Sep 17, 2015 at 9:07 PM, Wladimir J. van der Laan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello, > > At Monday's code sprint we had a good idea to schedule a regular developer > meeting in #bitcoin-dev. > > Attendance is of course voluntar

[bitcoin-dev] bitcoin-dev list etiquette

This is a message that I wrote and had hoped that all the core devs would sign on to, but I failed to finish organizing it. So I'll just say it from myself. There has been a valuable discussion over the last several months regarding a hard fork with respect to block size. However the sheer volum

[bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

Hi everyone, I'd like to propose a new set of requirements as a policy on when to accept new transactions into the mempool and relay them. This policy would affect transactions which have as inputs other transactions which are not yet confirmed in the blockchain. The motivation for this policy

Re: [bitcoin-dev] Fees and the block-finding process

Gavin, They are not analogous. Increasing performance and making other changes that will help allow scaling can be done while at small scale or large scale. Dealing with full blocks and the resultant feedback effects is something that can only be done when blocks are full. It's just too complicat

Re: [bitcoin-dev] Fees and the block-finding process

I agree There are a lot of difficult technical problems introduced by insufficient block space that are best addressed now. As well as problems that scale will exacerbate like bootstrapping that we should develop solutions for first. Sent from my iPad > On Aug 8, 2015, at 6:45 PM, Dave Scot

Re: [bitcoin-dev] Block size following technological growth

On Tue, Aug 4, 2015 at 9:12 AM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I would say that things already demonstrately got terrible. The mini

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

Jeff I respectively disagree with many of your points, but let me just point out 2. 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