> On 27 Apr 2015, at 21:21, Peter Todd wrote:
>
> Even right now there are edge cases without
> good solutions, like how in a multisig environment any of the key
> holders can mutate transactions.
Can't we add requirement for RFC6979 signatures to mitigate this? Of course,
multiple signers ca
On Sat, Apr 25, 2015 at 10:32:36AM -0400, Stephen Morse wrote:
> 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 compe
On Sat, Apr 25, 2015 at 11:51:37PM -0700, Joseph Poon wrote:
> signs the sigScript of the redeemed output.
Err, typo, I meant:
... signs the *scriptPubKey* of the redeemed output.
--
Joseph Poon
--
One dashboard for ser
On Sun, Apr 26, 2015 at 03:01:10AM +0300, s7r wrote:
> It's true that malleability is not the end of the world, but it is
> annoying for contracts and micropayment channels, especially refunds
> spending the fund tx before it is even in the blockchain, relying
> solely on its txid.
Agreed, needing
Thank you all for your comments. The youtube video was indeed very
educative and nice to watch.
It's true that malleability is not the end of the world, but it is
annoying for contracts and micropayment channels, especially refunds
spending the fund tx before it is even in the blockchain, relying
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 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
On Fri, Apr 24, 2015 at 7:58 PM, William Swanson wrote:
> On Thu, Apr 16, 2015 at 9:12 AM, s7r wrote:
>> Thanks for your reply. I agree. Allen has a good point in the previous
>> email too, so the suggestion might not fix anything and complicate things.
>
> The BIP 62 approach to malleability isn
On Thu, Apr 16, 2015 at 9:12 AM, s7r wrote:
> Thanks for your reply. I agree. Allen has a good point in the previous
> email too, so the suggestion might not fix anything and complicate things.
The BIP 62 approach to malleability isn't the only option. Another
approach is to sign the transaction
s7r you may be interested in this video explaining several aspects of
malleability: https://www.youtube.com/watch?v=jyDE-aFqJTs
It is pre BIP62, but I believe it is very relevant and will hopefully
clear some of your doubts.
The signer of TX1 will always be able to change the signature and thus
the
Oh, no, sorry, it also covers bip62.
On Fri, Apr 24, 2015 at 10:55 AM, Jorge Timón wrote:
> s7r you may be interested in this video explaining several aspects of
> malleability: https://www.youtube.com/watch?v=jyDE-aFqJTs
> It is pre BIP62, but I believe it is very relevant and will hopefully
> c
Understood. That is unfortunate, but not the end of the world. If you
could please give feedback also to these last comments / questions:
How far are we at this moment from BIP62? Can an user send a
non-malleable tx now, if enforces some additional rules?
As for the security of the system, it doe
> Anyone can alter the txid - more details needed. The number of altered
> txids in practice is not so high in order to make us believe anyone can
> do it easily. It is obvious that all current bitcoin transactions are
> malleable, but not by anyone and not that easy. At least I like to think
so.
On 4/16/2015 8:34 PM, Mark Friedenbach wrote:
> At this moment anyone can alter the txid. Assume transactions are 100%
> malleable.
>
Anyone can alter the txid - more details needed. The number of altered
txids in practice is not so high in order to make us believe anyone can
do it easily. It i
At this moment anyone can alter the txid. Assume transactions are 100%
malleable.
On Apr 16, 2015 9:13 AM, "s7r" wrote:
> Hi Pieter,
>
> Thanks for your reply. I agree. Allen has a good point in the previous
> email too, so the suggestion might not fix anything and complicate things.
>
> The prob
Hi Pieter,
Thanks for your reply. I agree. Allen has a good point in the previous
email too, so the suggestion might not fix anything and complicate things.
The problem I am trying to solve is making all transactions
non-malleable by default. I guess there is a very good reason why BIP62
will not
On Apr 16, 2015 1:46 AM, "s7r" wrote:
> but for transaction versions? In simple terms, if > 75% from all the
> transactions in the latest 1000 blocks are version 'n', mark all
> previous transaction versions as non-standard and if > 95% from all the
> transactions in the latest 1000 blocks are ver
If I had a time locked signed transaction where I threw away the key, this
would potentially invalidate my transaction.
What is the point of such a rule?
On Wed, Apr 15, 2015 at 6:43 PM, s7r wrote:
> Hi,
>
> Would it be wise to add a consensus rule like the one we have for blocks,
>
> (if > 75%
Hi,
Would it be wise to add a consensus rule like the one we have for blocks,
(if > 75% from last 1000 blocks are version 'n' mark version 'n' as
standard for blocks and if > 95% from the last 1000 blocks are version
'n' mark previous block versions as invalid)
but for transaction versions? In s
19 matches
Mail list logo