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

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

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

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

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

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

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

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

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

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 -

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

On Tue, Feb 16, 2016 at 6:46 PM, Luke Dashjr <l...@dashjr.org> 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"

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

[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

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] Proposed new policy for transactions that depend on other unconfirmed transactions

trees (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: >

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

s of chain depth? > > Thanks, > -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 chai

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

ed >> entire tx dependency trees (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: >> &

[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

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

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 mining

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