Re: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption

[Sjors Provoost via bitcoin-dev]

> Op 22 feb. 2018, om 13:19 heeft Ryan Grant via bitcoin-dev 
>  het volgende geschreven:
> 
> On Fri, Feb 9, 2018 at 7:29 AM, Jeremy  wrote:
>> utility of this construction can be improved if we introduce functionality
>> that makes a script invalid after a certain time
> 
> Tagging this thread with "nExpiryTime".  Search archives for more.

Fill-or-kill transaction was the term used on the list:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011042.html
 


Sjors___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption

[Gregory Maxwell via bitcoin-dev]

On Thu, Feb 22, 2018 at 7:44 PM, Daniel Edgecumbe via bitcoin-dev
 wrote:
> I don't think that binding grafts to a particular transaction requires this 
> aggregation.
> It seems to me that you could just sign H(txid, script) rather than H(script).
> I'm not aware of whether this would break aggregation.


That would require that you know the txid in advance. Sometimes you
do-- and a graftroot sighash flag could handle that... but usually you
wouldn't.  The case where you already do know it can sort of be
covered today without using the graftroot:  Sign a transaction
spending the multisig coin to the graft.  This isn't a strict
alternative however, because it's not atomic: you could imagine that
txn being announced and then the graft not being spent, while someone
would like to spend a different graft.  That non-atomiticity could be
addressed by making the graft spends an OR of all the other graft
spends but that isn't scalable or private.  Regardless, still doesn't
work if the graft isn't created after the fact.

The aggregation bit has the property of working just in time, even on
grafts created in advance.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption

[Daniel Edgecumbe via bitcoin-dev]

> However,  the non-interactive schnorr aggregation trick[1] can be
applied to merge the S values of all graftroots and signatures in a
transaction into a single aggregate.  With this approach only a single
R value for each graftroot need be published, lowering the overhead to
~32 bytes-- the same as taproot. This has a side benefit of binding
the published grafts to a particular transaction, which might help
avoid some screwups.

I don't think that binding grafts to a particular transaction requires this 
aggregation.
It seems to me that you could just sign H(txid, script) rather than H(script).
I'm not aware of whether this would break aggregation.

---
Daniel Edgecumbe / esotericnonsense
esotericnonse...@esotericnonsense.com
https://esotericnonsense.com
https://danedgecumbe.com
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption

[Ryan Grant via bitcoin-dev]

On Fri, Feb 9, 2018 at 7:29 AM, Jeremy  wrote:
> utility of this construction can be improved if we introduce functionality
> that makes a script invalid after a certain time

Tagging this thread with "nExpiryTime".  Search archives for more.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption

[Jeremy via bitcoin-dev]

I'm also highly interested in the case where you sign a delegate
conditional on another delegate being signed, e.g. a bilateral agreement.

In order for this to work nicely you also need internally something like
segwit so that you can refer to one side's delegation by a signature-stable
identity.

I don't have a suggestion of a nice way to do this at this time, but will
stew on it.

--
@JeremyRubin 


On Thu, Feb 8, 2018 at 11:29 PM, Jeremy  wrote:

> This might be unpopular because of bad re-org behavior, but I believe the
> utility of this construction can be improved if we introduce functionality
> that makes a script invalid after a certain time (correct me if I'm
> wrong, I believe all current timelocks are valid after a certain time and
> invalid before, this is the inverse).
>
> Then you can exclude old delegates by timing/block height arguments, or
> even pre-sign delegates for different periods of time (e.g., if this
> happens in the next 100 blocks require y, before the next 1000 blocks but
> after the first 100 require z, etc).
>
>
>
> --
> @JeremyRubin 
> 
>
> On Mon, Feb 5, 2018 at 11:58 AM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant 
>> wrote:
>> > Am I reading correctly that this allows unilateral key rotation (to a
>> > previously unknown key), without invalidating the interests of other
>> > parties in the existing multisig (or even requiring any on-chain
>> > transaction), at the cost of storing the signed delegation?
>>
>> Yes, though I'd avoid the word rotation because as you note it doesn't
>> invalidate the interests of any key, the original setup remains able
>> to sign.  You could allow a new key of yours (plus everyone else) to
>> sign, assuming the other parties agree... but the old one could also
>> still sign.
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption

[Jeremy via bitcoin-dev]

This might be unpopular because of bad re-org behavior, but I believe the
utility of this construction can be improved if we introduce functionality
that makes a script invalid after a certain time (correct me if I'm wrong,
I believe all current timelocks are valid after a certain time and invalid
before, this is the inverse).

Then you can exclude old delegates by timing/block height arguments, or
even pre-sign delegates for different periods of time (e.g., if this
happens in the next 100 blocks require y, before the next 1000 blocks but
after the first 100 require z, etc).



--
@JeremyRubin 


On Mon, Feb 5, 2018 at 11:58 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant  wrote:
> > Am I reading correctly that this allows unilateral key rotation (to a
> > previously unknown key), without invalidating the interests of other
> > parties in the existing multisig (or even requiring any on-chain
> > transaction), at the cost of storing the signed delegation?
>
> Yes, though I'd avoid the word rotation because as you note it doesn't
> invalidate the interests of any key, the original setup remains able
> to sign.  You could allow a new key of yours (plus everyone else) to
> sign, assuming the other parties agree... but the old one could also
> still sign.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption

[Gregory Maxwell via bitcoin-dev]

On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant  wrote:
> Am I reading correctly that this allows unilateral key rotation (to a
> previously unknown key), without invalidating the interests of other
> parties in the existing multisig (or even requiring any on-chain
> transaction), at the cost of storing the signed delegation?

Yes, though I'd avoid the word rotation because as you note it doesn't
invalidate the interests of any key, the original setup remains able
to sign.  You could allow a new key of yours (plus everyone else) to
sign, assuming the other parties agree... but the old one could also
still sign.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption

[Ryan Grant via bitcoin-dev]

Am I reading correctly that this allows unilateral key rotation (to a
previously unknown key), without invalidating the interests of other
parties in the existing multisig (or even requiring any on-chain
transaction), at the cost of storing the signed delegation?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev