Good morning Greg,
> On Wed, Jun 20, 2018 at 12:12 PM, ZmnSCPxj via bitcoin-dev
>
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > This has the advantage that the Graftroot signature commits to a single
> > outpoint and cannot be used to spend all outpoints that happen to pay to
> > the s
On 19.6.2018 19:16, Pieter Wuille wrote:
>> 1) Why isn't the global type 0x03 (BIP-32 path) per-input? How do we
>> know, which BIP-32 path goes to which input? The only idea that comes to
>> my mind is that we should match the input's scriptPubKey's pubkey to
>> this 0x03's key (the public key).
>
Hi,
On 19.6.2018 19:16, Pieter Wuille via bitcoin-dev wrote:
> Yes, the reason is address reuse. It may be discouraged, but it still
> happens in practice (and unfortunately it's very hard to prevent
> people from sending to the same address twice).
>
> It's certainly possible to make them per-inp
Hello,
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
> suggestions, I fear that it may be too late. I know of a few other develope
>Hmm, upon further reflection, maybe it's not even worth including *any*
per-output data, aside from what the original transaction contains.
>The output redeem script is either:
- unknown, because we have received only an address from the receiver
- or it is known, because it is ours and in that c
On Thu, Jun 21, 2018 at 4:29 AM, matejcik wrote:
> In the case of everything per-input, the naive Signer can do this:
> 1. (in the global section) pre-serialize the transaction
> 2. (in each input) find and fill out scriptPubKey from the provided UTXO
> 3. (for a given BIP32 path) check if the mas
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 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 7:56 PM, Peter D. Gray via bitcoin-dev
wrote:
> PSBT is something we need, and has been missing from the ecosystem
> for a long time. Let's push this out and start talking about future
> versions after we learn from this one.
When you implement proposals that have little t
"David A. Harding" writes:
> On Tue, Jun 19, 2018 at 02:02:51PM -0400, David A. Harding wrote:
>> Anyone can rewrite a SIGHASH_NOINPUT input's outpoint, but the actual
>> transaction containing the settlement is expected to have (at least) two
>> inputs, with the second one originating the fees.
10 matches
Mail list logo
