As I see the BIP it is basically stressing that ver 1 transactions are
malleable.
It then addresses the need for unmalleable transactions for e.g. spending
unconfirmed outputs in a deterministic way (i.e. no 3rd party can sabotage) -
this transaction type is defined as ver 3.
A lot of clients
We've done forking changes before much faster than a year and that was with
less experience. If we want, we can get this done within months.
On 20 Feb 2014 16:30, Michael Gronager grona...@mac.com wrote:
As I see the BIP it is basically stressing that ver 1 transactions are
malleable.
It then
On Thu, Feb 20, 2014 at 6:08 AM, Mike Hearn m...@plan99.net wrote:
We've done forking changes before much faster than a year and that was with
less experience. If we want, we can get this done within months.
You mean P2SH... which your implementation has only picked up support
for in the last
I think we should get Pieter's proposal done and implemented quickly. I
agree with Mike, it doesn't have to take a long time for the core network
to fully support this.
Getting wallets to start generating transaction.version=3 might take years,
but that is OK.
--
--
Gavin Andresen
On Thu, Feb 20, 2014 at 6:29 AM, Gavin Andresen gavinandre...@gmail.com wrote:
I think we should get Pieter's proposal done and implemented quickly. I
agree with Mike, it doesn't have to take a long time for the core network to
fully support this.
Getting wallets to start generating
Great, I'm hearing rough consensus to proceed with Pieter's plan.
RE: far from confident on malleability routes: I'm reasonably confident
that we can squash malleability for IsStandard, SIGHASH_ALL transactions. A
proper proof of DSA signature un-malleability (or an lower bound for how
much work
I hereby request a BIP number.
On Thu, Feb 20, 2014 at 3:58 PM, Gavin Andresen gavinandre...@gmail.com wrote:
Great, I'm hearing rough consensus to proceed with Pieter's plan.
RE: far from confident on malleability routes: I'm reasonably confident
that we can squash malleability for
On Thu, Feb 20, 2014 at 7:11 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
I hereby request a BIP number.
62 assigned.
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to
No, I was thinking of the height in coinbase change. At any rate, p2sh was
supported by the consensus code in bitcoinj for a long time already, since
it was first written.
Support for sending to such addresses in the wallet appeared once an app
that wanted that support also appeared, which seems
On Thu, Feb 20, 2014 at 10:07 PM, Mike Hearn m...@plan99.net wrote:
No, I was thinking of the height in coinbase change. At any rate, p2sh was
supported by the consensus code in bitcoinj for a long time already, since
it was first written.
Support for sending to such addresses in the wallet
Why introduce a new transaction version for this purpose ? Wouldn't it be more
elegant to simply let:
1. the next bitcoin version prettify all relayed transactions as
deterministic transactions fulfilling the scheme 1-6 effectively blocking any
malleability attack? If miners would upgrade then
On Wed, Feb 19, 2014 at 3:11 PM, Michael Gronager grona...@mac.com wrote:
Why introduce a new transaction version for this purpose ? Wouldn't it be
more elegant to simply let:
1. the next bitcoin version prettify all relayed transactions as
deterministic transactions fulfilling the scheme
Longer term it would be more ideal have a canonical identifier for the transaction before it even gets to the chain to support these use cases, even if wallets are able to properly identify the status of it's transactions.
-Allen
One possible work-around to get back trusted transaction chaining
Twisting your words a bit I read:
* you want to support relay of transactions that can be changed on the fly, but
you consider it wrong to modify them.
* #3 is already not forwarded, but you still find it relevant to support it.
Rational use cases of #3 will be pretty hard to find given the
On Wed, Feb 19, 2014 at 12:28 PM, Michael Gronager grona...@mac.com wrote:
Twisting your words a bit I read:
* you want to support relay of transactions that can be changed on the fly,
but you consider it wrong to modify them.
* #3 is already not forwarded, but you still find it relevant to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
While we might be able to get away with a retroactive change in meaning right
now in the future that won't be so easy. There are lots if proposed
applications for nLockTime-using protocols that depend on transactions (or
parts of transactions)
dOn Wed, Feb 19, 2014 at 12:49 PM, Peter Todd p...@petertodd.org wrote:
While we might be able to get away with a retroactive change in meaning right
now in the future that won't be so easy. There are lots if proposed
applications for nLockTime-using protocols that depend on transactions (or
On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager grona...@mac.com wrote:
I think that we could guarantee fewer incidents by making version 1
transactions unmalleable and then optionally introduce a version 3 that
supported the malleability feature. That way most existing problematic
Regarding chains of transactions intended to be published at once together,
wouldn't it be easier to add a only-mine-with-child flag?
That way the parent transactions aren't actually valid unless spent
together with the transaction that depends on it, and only the original
will have a child
This is somewhat problematic in my use case since some parts need to be in
the chain earlier than others and have the same ID as expected.
https://bitcointalk.org/index.php?topic=260898.10
I haven't gone back to see if there are any ways around it, but the main
problem here is I need the
You could pregenerate entire trees of alternative outcomes where you pick
one branch / chain to broadcast based on the real world events as they
happen.
But I see another problem regarding use of oracles, if you have a P2SH
address with 2-of-3 signatures or similar in the chain, amd some
Instead of trying to remove the possibility of transaction
malleability, would it make sense to define a new, canonical
transaction hash/ID (cTxID), which would be a hash of the part of the
transaction data which we know is not malleable, and have clients use
this cTxID internally, thus making the
I think the solution is simply to encourage Bitcoin software developers to
design their software to use this static ID, instead of the full
transaction hash.If MtGox had talked those IDs instead of the TX ID,
their software would've correctly identified the mutated transactions and
there would
While that solution does work for many use cases, it does make it much
harder to do anything needing chained transactions. Granted, this is the
short term solution for current implementations, but having a transaction
identifier that does not change does open up other use cases.
For example,
Agreed. I'm not suggesting that malleability shouldn't be fixed or isn't a
problem. I would love to be able to leverage chained TX for Bitcoin
contracts. But that in its current state it doesn't have to be complicated
to deal with it.
Changing the protocol to use these static IDs is a pretty
On Wed, Feb 12, 2014 at 10:12 AM, Rune Kjær Svendsen
runesv...@gmail.com wrote:
Instead of trying to remove the possibility of transaction
malleability, would it make sense to define a new, canonical
transaction hash/ID (cTxID),
Yes, that is one proposal:
On 02/10/2014 12:33 AM, Pieter Wuille wrote:
The proposed document is here: https://gist.github.com/sipa/8907691
If we are bumping nVersion, how about dropping DER encoding completely
and using just 64 bytes directly for signature?
Also using 2 different variable integer encodings (in addition
It's also not necessary for wallet software - it's really just for
human consumption.
A wallet can easily detect inputs being respent in another
transaction. You don't need a static hash for that (which wouldn't
need with all hash types, non-malleability double spends, ...).
On Wed, Feb 12, 2014
On Wed, Feb 12, 2014 at 5:56 PM, Pavol Rusnak st...@gk2.sk wrote:
On 02/10/2014 12:33 AM, Pieter Wuille wrote:
The proposed document is here: https://gist.github.com/sipa/8907691
If we are bumping nVersion, how about dropping DER encoding completely
and using just 64 bytes directly for
On Wed, Feb 12, 2014 at 7:12 AM, Rune Kjær Svendsen runesv...@gmail.com wrote:
Instead of trying to remove the possibility of transaction
malleability, would it make sense to define a new, canonical
transaction hash/ID (cTxID), which would be a hash of the part of the
transaction data which we
We're talking about two slightly different things. If their system had
tracked by inputs and outputs (or some kind of static ID) , their system
wouldn't have been issuing refunds/replacements/cancellations in the first
place.
I agree with you that the reissuing code should also guarantee that
On 02/12/2014 08:44 AM, Alan Reiner wrote:
Changing the protocol to use these static IDs is a pretty fundamental
change that would never happen in Bitcoin. But they can still be
useful at the application level to mitigate these issues.
Not to mention that it would be potentially very
On Wednesday, February 12, 2014 8:27:52 PM Mark Friedenbach wrote:
On 02/12/2014 08:44 AM, Alan Reiner wrote:
Changing the protocol to use these static IDs is a pretty fundamental
change that would never happen in Bitcoin. But they can still be
useful at the application level to mitigate
I apologize if this has been discussed many times before.
As a long term solution to malleable transactions, wouldn't it be possible
to modify the signatures to be of the entire transaction. Why do you have
to zero out the inputs? I can see that this would be a hard fork, and
maybe it would be
On Wed, Feb 12, 2014 at 4:39 PM, Alex Morcos mor...@gmail.com wrote:
I apologize if this has been discussed many times before.
It has been, but there are probably many people like you who have not
bothered researching who may also be curious.
As a long term solution to malleable transactions,
Hello all,
it was something I planned to do since a long time, but with the
recent related issues popping up, I finally got around to writing a
BIP about how we can get rid of transaction malleability over time.
The proposed document is here: https://gist.github.com/sipa/8907691
I expect most
On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:
Hello all,
it was something I planned to do since a long time, but with the
recent related issues popping up, I finally got around to writing a
BIP about how we can get rid of transaction malleability over time.
The proposed
On Sunday, February 09, 2014 11:33:02 PM Pieter Wuille wrote:
The proposed document is here: https://gist.github.com/sipa/8907691
Rule 3 4 are already enforced.
AFAIK nVersion==3 transactions are not currently considered non-standard?
Luke
38 matches
Mail list logo
