I introduced you to gerneralized covenants[1] earlier, but in a domain specific
context that de-routed us from technical discussion. Let me demonstrate the
concept in a more generic use:
A covenant
or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)
would put a coin und
В Sat, 29 Jun 2019 09:19:41 +0900
Jonathan Underwood wrote:
> > Other note: you have 'unused' value of 1 for `m` in your scheme, why
> > not require m=1 for single-sig case, and use 0 as indicator that
> > there are a serlal number following it?
> >
>
> 0x00 is single sig, aka, OP_CHECKSIG
>
В Sat, 29 Jun 2019 09:19:41 +0900
Jonathan Underwood wrote:
> Though outside the scope of this BIP, one difficulty of a whitelist
> feature would be revocation of signatures. If we pre-sign a
> revocation cert and somehow make the wallet blacklist if seen... then
> the question is "if your signer
replies in-line. Thanks!
2019年6月29日(土) 6:46 Dmitry Petukhov :
> In your proposed field key format,
>
> {0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}
>
> I think you can replace the signing pubkey with just a fingerprint of
> the master key, that would save 29 bytes per 0x02 field.
>
Good point.
In your proposed field key format,
{0x02}|{signing_pubkey}|{m}|{xpub}|...|{xpub}
I think you can replace the signing pubkey with just a fingerprint of
the master key, that would save 29 bytes per 0x02 field.
If the only entity that is concerned about the validity of the
signature is those that p
Hi Eric,
Thank you for your questions as they show what concepts need further
explanation, so you understand the potential of this proposal and how it is
helpful to the ecosystem.
Riskless zero bond is in fact the most basic concept of financial engineering.
Yes, there are engineers of finance
Hi Tamas,
There are a number of economic assumptions contained herein. While I understand
you would like to focus on implementation, the worst bugs are requirements
bugs. IMO these should be addressed first. I’ve addressed some possible issues
inline.
> On Jun 28, 2019, at 01:27, Tamas Blummer
Thanks for the reply Peter. Comments inline:
2019年6月28日(金) 23:37 Peter D. Gray :
> 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:
>
I start with a formalisation of loans as common in finance:
A zero bond is a contract between two parties Alice and Bob whereby Alice
receives an amount less than P and has to pay back P at a later time point
called maturity.
The difference between the amount received and P is the interest impli
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
Hmm? If I'm following what you mean, that's not the P2P rules, it's the
> Unserialize code, in particular:
>
> compat/assumptions.h:52:static_assert(sizeof(int) == 4, "32-bit int
> assumed");
>
> serialize.h:289:uint64_t ReadCompactSize(Stream& is)
>
> serialize.h-679-template typename V>
>
On Wed, Jun 26, 2019 at 08:08:01PM -0400, Russell O'Connor via bitcoin-dev
wrote:
> I have a comment about the 'input_index' of the transaction digest for taproot
> signatures. It is currently listed as 2 bytes. I think it would be better to
> expand that to 4 bytes.
FWIW, I think this would be
12 matches
Mail list logo
