t; didn't have the time.
>
> Another alternative would be to use the Vendor tree, but that would
> prefix the mimetype with "vnd." so it would end up being something like
> "application/vnd.bitcoin.psbt". I did not think this was an reasonable
> so I did not c
t; https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions
>
> Thanks!
>
> — Christopher Allen [via iPhone]
>
> On Tue, Aug 31, 2021 at 11:41 AM Peter D. Gray via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > Hi list!
&g
Hi list!
I am proposing to register the following MIME (RFC 2046) media types with the
IANA:
bitcoin/psbt
- aka. a BIP-174 file, in binary
- does not make any claims about signed/unsigned status; lets leave that to
the file
bitcoin/txn
- aka. wire-ready fully-signed transaction
Hi Tobias.
The most recent release of Coldcard now offers "Seed XOR" to solve
similar problems. It allows any numbers of standard BIP-39
compatible seed phrases to be bitwise XOR'ed together to make a new seed.
Coldcard can split an existing seed into 2, 3 or 4 new phrases, or
you can take your e
Hard no to this idea:
On Thu, Feb 11, 2021 at 02:29:46PM -0800, Christopher Allen proposed:
...
> /48'/0'/0'/3'/PBKDF(complex string)'
As someone who has helped people find UTXO at key paths they didn't
know/want, this is a terrible idea. Key derivation paths should be
small, sequential integers,
I like this proposal and I see it's value: "One seed to rule them all."
Not hard to implement either.
---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD
5A2A5B10
On Fri, Mar 20, 2020 at 03:44:01PM +, Ethan Kosakovsky wrote:
> I would like to present a propos
> In your proposal, it is the Signer who adds the signature, so it
> will receive a PSBT without auth sigs and thus that could be mutated to
> trigger those bugs anyways.
The Signer may be signing a PSBT that was corrupted by the MitM,
but at least later users of the signed PSBT can detect that oc
Thanks for the useful comments guys. I understand where you are
coming from, but my PoV is from the deep embedded side.
On Mon, Jan 13, 2020 at 06:39:28AM +, Andrew Chow wrote:
> ... In fact, I'm not quite
> sure what kind of attack you are trying to defend against with this
> proposal.
I don
## Background
PSBT files in transit are at risk of MiTM changes. This isn't
supposed to matter, but as another layer of defence, I would like
to add two signatures to PSBT files when they are processed by the
PSBT Signer. These additional fields would be optional, and should
pass through existing
Thanks I get the idea better now: You want the PSBT creator to be
able to indicate to the signers that it (the PSBT creator) controls
specific outputs that don't otherwise look like change.
Some problems:
> extended private key of the current signer derived from the
> signer's root to m/204208360
I haven't studied the new proposal in depth, but my first impression is:
Wouldn't it just be easier and better to just sign the entire "outputs" section
of the PSBT?
The signature would cover every byte, and therefore would cover any
future BIP additions to the outputs area, and also help non-mu
On Fri, Apr 26, 2019 at 05:21:06PM +0200, Stepan Snigirev wrote:
...
> Currently in PSBT there is no way to reliably say if the output uses the
> keys derived from the same root keys as the inputs aside from the key owned
Writing the multisig support for Coldcard, I've come to the same conclusion.
...
> I believe that this discussion has become bikeshedding and is really no
> longer constructive.
...
Thanks for saying this Andrew! I agree with your point of view, and personally
I'm ready to lock this BIP down ... or at least move it to the next level of
approval.
...
> I propose to mov
On Fri, Jun 22, 2018 at 06:28:33PM -0400, Achow101 wrote:
> After reading the comments here about BIP 174, I would like to propose the
> following changes:
>
> - Moving redeemScripts, witnessScripts, and BIP 32 derivation paths to
> per-input and per-output data
...
I like this. I agree it's ma
On Tue, Jun 19, 2018 at 05:20:34PM +0200, Jonas Schnelli wrote:
...
>
> I don’t see any reasons why space would be an issue.
>
> HWWs probably can’t handle PBST natively since it is not optimised for
> presenting various informations in a signing-verification.
The Coldcard hardware wallet is PSB
On Thu, Jun 21, 2018 at 04:32:07PM +0200, Tomas Susanka wrote:
...
> First of all, let me thank you for all the hard work you and others have
> put into this.
>
> On 21.6.2018 02:39, Achow101 via bitcoin-dev wrote:
> > While I agree that the BIP itself should be revised to reflect these
> > sugge
On Fri, Jun 15, 2018 at 04:34:40PM -0700, Pieter Wuille wrote:
...
> First of all, it's unclear to me to what extent projects have already
> worked on implementations, and thus to what extent the specification
> is still subject to change. A response of "this is way too late" is
> perfectly fine.
.
17 matches
Mail list logo
