On Thu, Feb 20, 2014 at 10:07 PM, Mike Hearn 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 appeared onc
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 O
On Thu, Feb 20, 2014 at 7:11 AM, Pieter Wuille wrote:
> I hereby request a BIP number.
62 assigned.
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pit
I hereby request a BIP number.
On Thu, Feb 20, 2014 at 3:58 PM, Gavin Andresen 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 IsStandard, SIGHASH_ALL tra
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
On Thu, Feb 20, 2014 at 6:29 AM, Gavin Andresen 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 transaction.version=3 might
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:08 AM, Mike Hearn 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 month or so?
-
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" wrote:
> As I see the BIP it is basically stressing that ver 1 transactions are
> malleable.
>
> It then addresses
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
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
transac
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 Contract
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 refe
On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager 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
> implementations wou
dOn Wed, Feb 19, 2014 at 12:49 PM, Peter Todd 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
> parts of tran
-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) bei
On Wed, Feb 19, 2014 at 12:28 PM, Michael Gronager 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 support it.
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 fact
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
On Wed, Feb 19, 2014 at 3:11 PM, Michael Gronager 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 1-6 effecti
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 the
On Wed, Feb 12, 2014 at 4:39 PM, Alex Morcos 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, wouldn't it be
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 s
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 mit
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 insec
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 bot
On Wed, Feb 12, 2014 at 7:12 AM, Rune Kjær Svendsen 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 know is not m
On Wed, Feb 12, 2014 at 5:56 PM, Pavol Rusnak 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 signature?
T
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 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
On Wed, Feb 12, 2014 at 10:12 AM, Rune Kjær Svendsen
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: https://github.com/sipa/bitcoin/commits/normtxid
Bu
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 f
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, Alic
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
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 th
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
---
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 prop
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 ru
38 matches
Mail list logo
