> On Jun 28, 2019, at 12:21, Tamas Blummer wrote:
>
> 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
Good morning Tamas,
While I think covenants for some kind of debt tool is mildly interesting and an
appropriate solution, I wonder about this particular use-case.
It seems to me that, as either the `Transfer` signers or `Exit` signers are
always involved, that the `Transfer` signers can be
On Fri, Jun 28, 2019 at 10:27:16AM +0200, Tamas Blummer via bitcoin-dev wrote:
> The value of these outputs to Charlie is the proof that he has
> exclusive control of the coins until maturity.
>
> Alice can not issue promissory notes in excess of own capital or
> capital that she was able to
Even if the difference is apparent outside the signed data (in the output).
Signing the data explicitly is more secure.
ie. if some sort of vulnerability / way to break this system for 1-of-1
multisig is found, someone who signed a single sig xpub whitelist will not
be exposed.
2019年6月29日(土)
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
В 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
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.
