On Wednesday, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev wrote:
> To completely replicate the original behaviour, one may use:
> "DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if script}
> ELSE DROP {else script} ENDIF"
This is much uglier than expected. IMO if that's
> On August 16, 2016 at 8:27 PM Russell O'Connor via bitcoin-dev
> wrote:
>
> Okay.
>
> I'm not really opposed to this BIP, but I am worried that fighting script
> malleability is a battle that can never be won; even leaving one avenue of
> malleability open is probably just as bad as having
On Tue, Aug 16, 2016 at 08:27:54PM -0400, Russell O'Connor via bitcoin-dev
wrote:
> Okay.
>
> I'm not really opposed to this BIP, but I am worried that fighting script
> malleability is a battle that can never be won; even leaving one avenue of
> malleability open is probably just as bad as havin
Okay.
I'm not really opposed to this BIP, but I am worried that fighting script
malleability is a battle that can never be won; even leaving one avenue of
malleability open is probably just as bad as having many avenues of
malleability, so it just doesn't seem worthwhile to me.
On Tue, Aug 16, 20
Hi all,
Thanks again Jonas for starting this!
I worked on a similar proposal a while back (never posted), approaching
the same problem as if a merchant's website accepted xpubs/public keys,
created multi-signature addresses, and wanted the user to easily sign
offline instead of using some javascr
On 08/16/2016 12:22 PM, Luke Dashjr via bitcoin-dev wrote:
> It would be best if the hardware protocol were standardised, so the user
> doesn't need a plugin of *any* sort... I notice some hardware wallets have
> begun to implement (or reuse) Trezor's interface, so that would seem a good
> place
On Tue, Aug 16, 2016 at 10:52 PM, Russell O'Connor via bitcoin-dev
wrote:
> I see.
>
> But is it really necessary to soft fork over this issue? Why not just make
> it a relay rule? Miners are already incentivized to modify transactions to
> drop excess witness data and/or prioritize (versions of
On Wed, Aug 17, 2016 at 09:36:02AM +1000, Aiqin Li via bitcoin-dev wrote:
> Out of curiosity, what is the technical reason a normal ECC-enabled
> smart-card cannot be used for the hardware signing component of a wallet
> app? (Since if it can, its standardization must have been discussed.)
>
> Deb
Out of curiosity, what is the technical reason a normal ECC-enabled
smart-card cannot be used for the hardware signing component of a wallet
app? (Since if it can, its standardization must have been discussed.)
Debian wiki gives a list of such cards with related opensource software
to access t
I see.
But is it really necessary to soft fork over this issue? Why not just make
it a relay rule? Miners are already incentivized to modify transactions to
drop excess witness data and/or prioritize (versions of) transactions based
on their cost. If a miner wants to mine a block with excess wi
On Tue, Aug 16, 2016 at 6:30 PM, Pieter Wuille
wrote:
> On Aug 17, 2016 00:23, "Russell O'Connor via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > If one's goal is to mess with an transaction to prevent it from being
> mined, it is more effective to just not relay the trans
On Aug 17, 2016 00:36, "Russell O'Connor" wrote:
> Can I already do something similar with replace by fee, or are there
limits on that?
BIP125 and mempool eviction both require the replacing transaction to have
higher fee, to compensate for the cost of relaying the replaced
transaction(s).
--
On Aug 17, 2016 00:23, "Russell O'Connor via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> If one's goal is to mess with an transaction to prevent it from being
mined, it is more effective to just not relay the transaction rather than
to mess with the witness. Given two transacti
On Tue, Aug 16, 2016 at 3:43 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Tue, Aug 16, 2016 at 07:37:19PM +, Luke Dashjr via bitcoin-dev
> wrote:
> > On Tuesday, August 16, 2016 5:53:08 PM Johnson Lau via bitcoin-dev wrote:
> > > A new BIP is prepared to
I agree this is an interesting area of transaction malleability to still
consider in the future, and minimization of these areas of malleability
with regards to its impact on the p2p network should be easy to resolve
and (hopefully) well-understood by script writers in the future.
On Tue, Aug 16,
On Tue, Aug 16, 2016 at 07:37:19PM +, Luke Dashjr via bitcoin-dev wrote:
> On Tuesday, August 16, 2016 5:53:08 PM Johnson Lau via bitcoin-dev wrote:
> > A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in
> > P2WSH:
> > https://github.com/jl2012/bips/blob/minimalif/bip-minimal
On Tuesday, August 16, 2016 5:53:08 PM Johnson Lau via bitcoin-dev wrote:
> A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in
> P2WSH:
> https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki
> https://github.com/bitcoin/bitcoin/pull/8526
I am not sure this makes
On Tuesday, August 16, 2016 2:10:04 PM Jonas Schnelli via bitcoin-dev wrote:
> The BIP describes two approaches how to communicate (pipe and
> URI-scheme) with the signing-devices app, although, in my opinion, all
> major platform do support the URI approach (maybe we could drop the pipe
> approach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in P2WSH:
https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki
https://github.com/bitcoin/bitcoin/pull/8526
BIP: x
Title: Dealing with OP_IF and OP_NOTIF malle
Hello Jonas,
thanks for your efforts of writing the draft for the standard.
First, this only describes detached signing. A wallet also needs to
connect with a hardware wallet at some time to learn the xpubs
controlled by the hardware. Do you plan to have this in a separate
standard or should th
> On August 16, 2016 at 6:20 AM Luke Dashjr wrote:
>
>
> On Tuesday, August 16, 2016 10:10:01 AM Johnson Lau via bitcoin-dev wrote:
> > Specification
> >
> > Every signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG,
> > or OP_CHECKMULTISIGVERIFY, to which ECDSA verification is
On 16/08/16 17:13, Jonas Schnelli wrote:
> I'm aware of this approach but I don't think this makes sense long term.
> We need a better way on the protocol level to validate inputs amounts
> (where segwit is a first step towards this).
So you basically rephrased what I am saying but in another word
> I think it does not make sense to try to get this standardized for
> current Bitcoin transactions. They are just too complex.
>
> What might be interesting is to have something similar for Segwit and
> Lightning transactions.
>
> * TREZOR performs extended validation of the inputs, when all of
I think it does not make sense to try to get this standardized for
current Bitcoin transactions. They are just too complex.
What might be interesting is to have something similar for Segwit and
Lightning transactions.
* TREZOR performs extended validation of the inputs, when all of
prev-txs are s
Hi
Unfortunately, there is no standard in how desktop- or mobile-wallets
can interact with a hardware device resulting in wallet vendors adding
plugins with proprietary code for non-standardized interfaces.
I started a BIP (extreme draft, feel free to improve language, grammar
and content) to add
On Tuesday, August 16, 2016 10:10:01 AM Johnson Lau via bitcoin-dev wrote:
> Specification
>
> Every signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG,
> or OP_CHECKMULTISIGVERIFY, to which ECDSA verification is applied,
Not 20-byte witness v0 programs?
> These operators all p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
As discussed in the 11 Aug 2016 IRC meeting
(https://bitcoincore.org/en/meetings/2016/08/11/#softfork-to-make-low-s-required),
a new BIP with implementation is prepared to make low S value signature as a
consensus rule:
https://github.com/jl2012/
27 matches
Mail list logo
