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
I'm not sure how well this would work.
Sure it would provide honest historical pricing, but those who wait for
publication confirmation may be at a disadvantage -- to get the best
deal possible Bob would connect to as many nodes as he could, examine
the stream of unconfirmed asks coming in and
Thanks for humoring my questions!
>I think reporting such errors to the wallet would make complete sense.
However i am not clear why we would a separate url for that?
Hmm, thinking about this more, adding a simple status_code in
PaymentRequest would be a much easier way to achieve this. However,
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
Hi Kevin,
On Feb 11, 2014, at 2:00 AM, Kevin Greene wrote:
> Figured I would have a crack at reviewing this since Mike is out for a bit.
> It was great running into you guys at the bitcoin fair in SF! Small world :)
Indeed! It was great meeting you! It's always nice to meet people in person...
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
17 matches
Mail list logo
