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
https://github.com/bitcoin/bitcoin/blob/v0.9.3/src/main.cpp#L617-620
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 very
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,
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 calculate
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
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 scriptSig
in
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
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
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
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 Sunday
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
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
thing at a time.
On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse stephencalebmo...@gmail.com
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_RCLTV even with this being
implemented.
In use cases such as micropayment
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
14 matches
Mail list logo
