Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

It is disappointing that F2Pool would enable full RBF when the safe alternative, first-seen-safe RBF, is also available, especially since the fees they would gain by supporting full RBF over FSS RBF would likely be negligible. Did they consider using FSS RBF instead? Best, Stephen On Fri, Jun 19,

Re: [Bitcoin-development] Ninki Wallet view on blocksize debate

Ben, How does your wallet calculate the fee that should be paid to miners? Do they automatically adjust when transactions take a long time to be confirmed? And how does it respond when transactions are not mined successfully, such as when blocks are full? I strongly urge Gavin to withdraw from th

Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure

Vincent, > Some changes: > > Votes need to be 100%, not 50.01%. That way small miners have a fair > chance. A 50.01% vote means large miners call the shots. > While I like the idea of possibly requiring more than 50%, you wouldn't want to have a situation where a minority of uncooperative (or just

Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure

Pindar, yes and it's a good idea to separate the hard/soft fork upgrades. The point > being here is that we're also establishing a process for the community to > self-determine the way forward in a transparent and verifiable manner. > > What's not to like? :) > > I'll probably have some time on Su

Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure

> > Why do it as an OP_RETURN output? It could be a simple token in the > coinbase input script, similar to how support for P2SH was signaled among > miners. And why should there be an explicit token for voting for the status > quo? Simply omitting any indication should be an implicit vote for the

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

> > That would also introduce the anomaly of a script that was once valid > becoming later invalid, when nothing varies other than time. That is > not super compatible with the current model of reprocessing > transactions in later blocks if the block they were first in gets > reorged. > Very good

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

t; opcode and its enabling applications. But, well, one thing at a time. > > On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse > wrote: > >> Hi Mark, >> >> Overall, I like this idea in every way except for one: unless I am >> missing something, we may still need an OP_

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

Hi Mark, Overall, I like this idea in every way except for one: unless I am missing something, we may still need an OP_RCLTV even with this being implemented. In use cases such as micropayment channels where the funds are locked up by multiple parties, the enforcement of the relative locktime can

Re: [Bitcoin-development] Why do we need a MAX_BLOCK_SIZE at all?

This exact question came up on the Bitcoin Stack Exchange once. I gave an answer here: http://bitcoin.stackexchange.com/questions/37292/whats-the-purpose-of-a-maximum-block-size/37303#37303 On Mon, Jun 1, 2015 at 2:32 PM, Jim Phillips wrote: > Ok, I understand at least some of the reason that bl

[Bitcoin-development] Max Block Size: Simple Voting Procedure

This is likely very similar to other proposals, but I want to bring voting procedures back into the discussion. The goal here is to create a voting procedure that is as simple as possible to increase the block size limit. Votes are aggregated over each 2016 block period. Each coinbase transaction

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

> > An option would be that the height is included in the scriptSig for all >> transactions, but for non-coinbase transctions, the height used is zero. >> > No need to add an extra field to the transaction just to include the > height. We can just add a rule that the height specified in the scriptS

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

Hi Gregory, In particular not covering the ID allows for transaction replay which > can result in monetary losses far more severe than any possible > mishandling of malleability could result in. Byzantine attackers can > costlessly replay your old transactions any time anyone reuses an > address,

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

Hi William, I personally prefer this solution, since it nails the problem > completely with one simple and obvious change. The BIP 62 approach is > more like a game of wac-a-mole. > The two are complementary, not competing. BIP62 prevents *non-signers* from mutating the transactions, which is ver

Re: [Bitcoin-development] Build your own nHashType

Hi Mike, Hi Stephen, > > It's an interesting idea. I'm not sure that all the combinations make > sense. Excluding the connected output script or value but still signing the > prev tx hash appears pointless: the script cannot change anyway, and you > still need to know what it is to actually calcul

[Bitcoin-development] Build your own nHashType

Seeking feedback on a proposal that will allow a transaction signer to explicitly specify what is to be serialized for the signature hash. The basic idea is to make the nHashType general enough that we won't need a new sighash flag every time a new use case comes up. If implemented into bitcoin (v

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

I agree with Gregory Maxwell, I don't think it would be as easy as just changing IsCoinBase(), since there are places where the code assumes that the coinbase's vin doesn't spend any prevouts and/or has size 1. For example, here