<unnamed>

Public Key

npub1dpdfw74plzm03mzglkdegp3hqn6qs9yffqefa5kh98mru49nrg7szymz3t

Profile Code

nprofile1qqsxsk5h02sl3dhca3y0mxu5qcmsfaqgzjy5sv576ttjna372je350gpz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqlpszj0

Publishing to

relay.nostr.net

relay.damus.io

nos.lol

Last Notes

2023-06-08 01:19:58 CEST

- reply

📅 Original date posted:2023-03-06
🗒️ Summary of this message: Greg and AJ propose TLUV-ifying the OP_VAULT proposal to avoid recursive script execution and simplify the spec. This change would make OP_VAULT more native to Taproot primitives. The proposal also introduces new opcodes to facilitate consistent witness structure. The change does not affect usage or expressiveness but may allow an optional withdrawal authorization script in the future. Additionally, the proposal suggests reusing OP_CHECKTEMPLATEVERIFY for withdrawal target spends.
📝 Original message:I'm glad to see that Greg and AJ are forming a habit of hammering
this proposal into shape. Nice work fellas.
To summarize:
What Greg is proposing above is to in essence TLUV-ify this proposal.
I.e. instead of relying on hashed commitments and recursive script
execution (e.g. <trigger-sPK-hash> + later presentation of preimage
script for execution), OP_VAULT would instead move through its
withdrawal process by swapping out tapleaf contents according to
specialized rules. If this is opaque (as it was to me), don't fret -
I'll describe it below in the "mechanics" section.
The benefits of this TLUVification are
- we can avoid any nested/recursive script execution. I know the
recursive stuff rankles some greybeards even in spite of it being
bounded to a single call. I'm not sure I share the concern but
maintaining the status quo seems good.
- the spec is easier to reason about, more or less. The opcodes
introduced don't have variadic witness requirements, and each opcode
is only consumed in a single way.
- there's less general indirection. Instead of saying "okay, here's the
hash of the script I'm going to use to authorize trigger
transactions," we're just outright including the trigger auth script
in the tapleaf at the birth of the vault as regular 'ol script that is
evaluated before execution of the OP_VAULT instruction.
Similarly, instead of relying on an implicit rule that an OP_VAULT can
be claimed by a recovery flow, we're relying on a specific tapleaf that
facilitates that recovery with OP_VAULT_RECOVER, described below.
Basically, OP_VAULT would just be implemented in a way that feels
more native to Taproot primitives.
Greg also introduces different opcodes to facilitate consistent
witness structure, rather than the variable ones we have now
since OP_VAULT and OP_UNVAULT can each be spent in two different
contexts. I've changed those a little here; instead of the three general
ones Greg gave, we whittled it down to two: OP_VAULT and
OP_VAULT_RECOVER.
So I think that, barring significant implementation complexity - which
I'll find out about soon and don't expect - this is a good change to the
proposal. As Greg noted, it doesn't really change anything about the
usage or expressiveness... other than the fact that, as a bonus, it
might allow an optional withdrawal authorization script (i.e. trigger
output => final target), which could be useful if e.g. some kind of
size-limiting opcode (e.g. OP_TX_MAXSIZE or something) came around in
the future as a kind of pinning fix.
If that last bit lost you, don't worry - that is speculative, but the
point is that this rework composes well with other stuff.
# CTV use
Another thing that has dawned on us is that we might as well just reuse
OP_CHECKTEMPLATEVERIFY for withdrawal target spends. Ben Carmen and
others realized early on that you can synthesize CTV-like behavior by
spending to a 0-delay OP_UNVAULT output, so something CTVish has always
implicitly been a part of the proposal. But CTV is better studied and
basically as simple as the OP_UNVAULT spend semantics, so the thought is
that we might as well reuse all the existing work (and scrutiny) from
CTV.
As a concrete example, an issue with the existing proposal is that the
existing CTVish OP_UNVAULT behavior has txid malleability, since it
doesn't commit to nVersion or nLockTime or the input sequences. Using
CTV solves this issue. Otherwise we'd basically reinvent it - "something
something convergent evolution."
I think this is a satisfying development, because there's clearly demand
for CTV use in other contexts (DLC efficiency, e.g.), and if it's
required behavior for practical vaults, I think pulling in the existing
BIP-119 that's been worked over for years reduces the conceptual
surface area added by OP_VAULT.
# New mechanics of the proposal
So here I'm going to describe my rendering of Greg and AJ's suggestions.
## Required opcodes
- OP_VAULT: spent to trigger withdrawal
- OP_VAULT_RECOVER: spent to recover
- OP_CHECKTEMPLATEVERIFY: spent into final withdrawal target
Creating an initial deposit
---------------------------
For each vault, vaulted coins are spent to an output with the taproot
structure
taproot(internal_key, {$recovery_leaf, $trigger_leaf, ...})
where
internal_key =
unchanged from original proposal (some very safe recovery key)
$recovery_leaf =
[<opt.> <recovery> <auth>] <recovery sPK hash> OP_VAULT_RECOVER
$trigger_leaf =
<trigger> <auth> <script> <spend-delay> OP_VAULT
... =
other (optional) leaves in the taptree
Triggering a withdrawal request
-------------------------------
To trigger the start of the withdrawal process, an output of the above
form is spent with a witness that contains
- Taproot control block pointing to $trigger_leaf.
- <trigger-vout-idx>, indicating the trigger output which must abide
by the rules given below.
## Output structure
taproot(internal_key, {$recovery_leaf, $expr_withdraw, ...})
where
$recovery_leaf is preserved exactly
$expr_withdraw =
<spend-delay> OP_CSV OP_DROP <target-ctv-hash> OP_CTV
... is preserved exactly
(Spoiler: note here that the only thing that is changing is
s/expr_trigger/expr_withdrawl/ from the initial vault ouput.)
Of course $expr_withdraw *could* be prefixed by an optional "withdrawal
authorization" script, if some sensible use for that is found.
The validation rules are essentially unchanged from the existing
proposal:
- The total amount of all OP_VAULT inputs with matching $recovery_leaf
values must be reflected in output <trigger-vout-idx>
- <trigger-vout-idx> must correspond to an output that is identical to
the input taptree but with the spent tapleaf (OP_VAULT) swapped out
for the timelocked CTV constructed using <target-ctv-hash> and
<spend-delay> as extracted from the spent tapleaf
- internal_key is preserved
- the whole rest of the taptree is preserved
- (this is what ensures the parameters of the vault are forwarded)
All batching, fee management characteristics are the same.
Finalizing withdrawal
---------------------
Happens via script-path spend to $expr_withdraw, i.e. a timelocked
OP_CTV.
Recovery
--------
Can happen from any of the above outputs using the $recovery_leaf
script path in a way very similar to the existing OP_VAULT proposal.
---
To reiterate, all aspects of the existing OP_VAULT proposal are either
preserved or improved upon in terms of malleability reduction,
composability, and flexibility. So big thanks to AJ and Greg.
I'll undertake implementing these changes in the coming days to verify
that they are, as expected, workable.
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230306/0762c458/attachment.html>

2023-06-08 01:18:21 CEST

- reply

📅 Original date posted:2023-01-10
🗒️ Summary of this message: Discussion on potential improvements to the OP_VAULT implementation, including the use of signatures for recovery paths and the compatibility with Taproot-only extensions. There is also debate on the usefulness of batching withdrawals.
📝 Original message:Forwarding in some conceptual feedback from the pull request.
>From ariard:
> I've few open questions, like if the recovery path should be committed
with a signature rather than protected by a simple scriptpubkey preimage.
That's something I've wondered about too. I have to ruminate on AJ's good
post about this, but a pretty straightforward way of enabling this (at the
expense of some complexity) is to do something like "if
<recovery-path-hash> is 32 bytes, treat it as it's currently used. If it's
33 bytes, use the first byte as a parameter for how to interpret it." To
start with, an extra prefix byte of 0x00 could mean "require a witness
satisfying the scriptPubKey that hashes to the remaining 32 bytes" in the
same way we do the unvault signing. This would enable a "sign-to-recover"
flow at the option of the user, specified during vault creation.
> The current OP_VAULT implementation is using OP_NOP repurposing but this
doesn't seem compatible with Taproot-only extensions (e.g ANYPREVOUT) and
maybe a OP_SUCCESS could be used.
Yes, with Greg's suggestion of putting <target-hash> on the witness stack
during OP_VAULT (-> OP_UNVAULT) spend, we could conceivably move
OP_VAULT/OP_UNVAULT into Taproot-only OP_SUCCESSx opcodes. I haven't
thought hard about how worthwhile it is to preserve the ability to use
OP_VAULT in pre-Taproot contexts.
> There is a conceptual wonder, if a CTV and template malleability approach
wouldn't better suit the vault use-case and allow other ones, as such
better re-usability of primitives.
I dedicated a whole section of the paper ("Precomputed vaults with
covenants") to explaining why precomputed covenant mechanisms have big
shortcomings for vaults.
That said, a number of people have commented about OP_VAULT's ability to
(inefficiently) emulate CTV. I'm still very supportive of CTV, I just don't
really have any uses I personally understand inside and out aside from
vaults... so if others do, they should really post about it on this list
and we should resume working on an activation for CTV!
---
>From naumenkogs:
> I'm personally not sure batching withdrawals is that compelling... It's a
nice-to-have, but I'd think about the benefits dropping this feature would
provide.
Having familiarity with a few large-scale custodial operations, I think
batching is a really big deal. And if you're going to support multiple
deposits to the same vault, no support for batching is going to result in a
lot of unnecessary output creation even as a small user if you're, e.g.,
doing weekly automated deposits from an exchange to a vault you've
configured.
Darosior comments:
> On the contrary i think the batching feature is very compelling. The
impossibility to batch Unvaults in Revault is a major drawback: it
significantly increases the cost of any realistic operation (you need one
whole additional transaction per input, and each have likely more than one
output). It also potentially increases the cost on the network (you'd
likely want some sort of anchor output on each Unvault tx, that you might
not spend, so that's 2*n outputs created with n the number of coins spent):
we definitely don't want to prevent batching. The ability to batch the
recovery transactions (what we called Emergency tx in Revault) is also very
compelling but i think your comment was only about batched withdrawals.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230110/de2020d1/attachment-0001.html>

2023-06-08 01:18:19 CEST

- reply

📅 Original date posted:2023-01-10
🗒️ Summary of this message: Discussion on proposed improvements to Bitcoin's vault system, including using pay-to-contract construction for recovery path and a generic OP_UNVAULT.
📝 Original message:Thanks for the thoughtful reply AJ.
> I don't think that makes sense? With a general scheme, you'd only be
> bloating the witness data (perhaps including the witness script) not
> the scriptPubKey?
Sorry, sloppy language on my part. To be charitable, I'm talking about
the "figurative sPK," which of course these days lives in the witness
for script-path-ish spends. Maybe the witness discount means that
"complicated" scripts aren't as big a deal, depending on the actual
difference in raw script size.
> I think it might be better to use a pay-to-contract construction for
> the recovery path, rather than an empty witness.
So I guess the one advantage that what you're proposing has over just
using a recovery-path key signature is that it's all derivable from your
cold privkey; you don't have to worry about accidentally losing the
recovery-path key.
Of course you're still vulnerable to spurious sweeps if the
sha256(secret) value gets found out, which presumably you'd want in an
accessible cache to avoid touching the cold secret every time you want
to sweep.
What do you think about the idea of making the recovery-path
authorization behavior variable on a single byte flag preceding the 32
byte data push, as I mentioned in another post? I think it may make
sense to leave this option open to end-users (and also allow for some
upgradeability).
> I think a generic OP_UNVAULT can be used to simulate OP_CTV: replace
> "<h> OP_CTV" with "<000..0> 0 <h> OP_UNVAULT".
Yup, that's an inefficient way of emulating CTV. If people want CTV, we
should just look at activating CTV. Greg Sanders has a thing about
"jetting" CTV into this proposal (I think) so that the code-paths are
shared, but I haven't figured out how that would work. They really
don't share that much code AFAICT.
> The paper seems to put "OP_UNVAULT" first, but the code seems to
> expect it to come last, not sure what's up with that inconsistency.
Again some sloppy notation on my part. What I sort of meant in the paper
was a kind of functional notation `OP_VAULT(param1, param2, ...)`. Let's
chalk that up to my inexperience actually working on script stuff.
> I think there's maybe a cleverer way of batching / generalising
> checking that input/output amounts match.
>
> [...]
>
> * set C = the sum of each output that has a vault tag with
> #recovery=X
This would also need to take into account that the <spend-delay>s are
compatible, but your point is well taken.
> I think one meaningful difference between these two approaches is that
> the current proposal means unvaulting locks up the entire utxo for the
> delay period, rather than just the amount you're trying to unvault.
This is a really good point and I think is one that's important to
incorporate with a change to the existing proposal.
A simple fix for facilitating the use of a "partial revault" while the
OP_UNVAULT UTXO is outstanding would be to allow for an optional
third output that is a redeposit back to the identical OP_VAULT sPK that
is being spent by the OP_UNVAULT transaction, then the script
interpreter would just ensure that the nValue of those two outputs sums
to the sum of the input nValues.
I can see what you're saying about having more generic "group amounts by
compatible vault params, and then compare to similarly grouped outputs,"
but I'm just wondering if there are other uses that enables besides the
partial-revault thing I mentioned above. If not, I'd probably rather just
stick
with something simple like having the third optional re-vault output.
> Changing the unvault construction to have an optional OP_VAULT output
> would remedy that, I think.
Oh - okay, this is what you're saying. Right!
Is that a sufficient change, or are there other benefits that the more
complicated clever-I/O-vault-grouping would enable that you have in
mind?
> What would it look like to just hide all this under taproot?
>
> [...]
>
> It also needs some way of constructing "unvault[X]", which could be a
> TLUV-like construction.
>
> That all seems possible to me; though certainly needs more work/thought
> than just having dedicated opcodes and stuffing the data directly in
> the sPK.
I think this is a very important comparison to do, but I'm eager to see
code for things like this. There have been a lot of handwavey proposals
lately without tangible code artifacts. I'm eager to see what these
alternatives look like in practice - i.e. in functional tests.
Thanks again for the great mail.
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230110/a5579378/attachment.html>

2023-06-08 01:18:18 CEST

- reply

📅 Original date posted:2023-01-10
🗒️ Summary of this message: Greg suggested a way to enable all outputs in vault lifecycles to be P2TR, which would conceal the operation of the vault, and allow OP_VAULT/OP_UNVAULT opcodes to be implemented as Taproot-only OP_SUCCESSx opcodes. The problem is how to enable something similar for witness v0 outputs.
📝 Original message:Greg explained his suggestion to me off-list, and I think it's a good one.
To summarize, consider the normal "output flow" of an expected vault use:
(i) output to be vaulted
=> (ii) OP_VAULT output
=> (iii) OP_UNVAULT "trigger" output
=> (iv) final output
In my existing draft implementation, all outputs aside from (iii), the
OP_UNVAULT trigger, can be P2TR or P2WSH. In other words, those outputs can
hide their true script until spend. In my draft, the OP_UNVAULT trigger had
to be bare so that the script interpreter could inspect part of it for
validity: "does this OP_UNVAULT have the same <recovery-spk-hash> and
<spend-delay> as the OP_VAULT?"
If that output wasn't bare, because the <target-hash> is variable at the
time of OP_UNVAULT output creation, the script interpreter would have no
way of constructing the expected scriptPubKey.
Greg's suggestion would allow that output to be any kind of script. He
suggests to put the <target-hash> onto the witness stack when spending the
OP_VAULT output (and creating the OP_UNVAULT output). If we did that, the
script interpreter could e.g. use a NUMS point (i.e. a publicly known point
with no usable private key) to construct a Taproot configuration that looks
like
tr(NUMS, {<OP_UNVAULT <recovery-key> <spend-delay> <target-hash>})
and check if the scriptPubKey of the proposed OP_UNVAULT output matches
that. This would allow all outputs in vault lifecycles to be P2TR, for
example, which would conceal the operation of the vault - a very nice
feature!
This would also allow the OP_VAULT/OP_UNVAULT opcodes to be implemented as
Taproot-only OP_SUCCESSx opcodes, if that was decided to be preferable.
The problem is how to (and whether to) enable something similar for witness
v0 outputs. For example, if we want the (ii) and (iii) output scripts to
live behind P2WSH. One (kind of hacky) option to enable this is to have the
script interpreter construct the expected OP_UNVAULT scriptPubKey on the
basis of what witness version it sees. For example, if it sees "OP_0 <32
bytes data>", it would use <target-hash> on the witness stack to construct
a fitting P2WSH scriptPubKey that is compatible with the OP_VAULT being
spent, and then match against that. But if it detects "OP_1 <32 bytes
data>", it would do the same process for an expected Taproot-with-NUMS
output.
---
Anyway, sorry if that was more verbose than necessary, but I think it's a
really great suggestion from Greg. I'll look at modifying the
implementation accordingly. I'd be curious to hear what others think as
well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230110/c1b0d445/attachment.html>

2023-06-08 01:18:17 CEST

- reply

📅 Original date posted:2023-01-09
🗒️ Summary of this message: The OP_UNVAULT scriptPubKey must be a bare script and contain the target hash for validating the spend, while the OP_VAULT spend witness stack requires an additional witness data item for the unvault path. This proposal allows unbound destinations and unbound time for inheritance designs in wallets.
📝 Original message:Hey Greg,
I think what you're trying to get at here is that the OP_UNVAULT
scriptPubKey *must* be a bare script so that the OP_VAULT spend logic can
verify that we're spending an OP_VAULT output into a compatible OP_UNVAULT
output, and that's true. The OP_UNVAULT scriptPubKey also must contain the
target hash because that has is used when validating that spend to ensure
that the final unvault target matches what was advertised when the
OP_UNVAULT output was created.
So I'm not sure what problem you're trying to solve by putting the target
hash on the OP_VAULT spend witness stack. If it were placed there, it
wouldn't be accessible during OP_UNVAULT spend AFAICT. I agree it would be
nice to figure out a way to allow the OP_UNVAULT scriptPubKey to not be
bare, which may require moving the target hash out of it, but we'd have to
figure out a mechanism to properly forward the target hash for validation.
Best,
James
On Mon, Jan 9, 2023 at 2:32 PM Greg Sanders <gsanders87 at gmail.com> wrote:
> Hi James and co,
>
> Currently there is no way to make this compatible with scripthashes of any
> kind, since the script interpreter has no insight into the OP_UNVAULT
> outputs' "execution script", and one of the arguments of OP_UNVAULT is
> freeform, resulting in an unpredictable output scriptpubkey.
>
> I think the fix is just requiring a single additional witness data item
> during OP_VAULT spend(for unvault path), mandating the
> <target-outputs-hash> to be included in the witness stack as an input to
> OP_VAULT opcode, and transaction introspection then checks to make sure the
> witness item and the corresponding output script template matches the
> expected.
>
> This would only be necessary for the unvaulting path, and not for the
> recovery path.
>
> Cheers,
> Greg
>
> On Mon, Jan 9, 2023 at 2:10 PM rot13maxi via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hey James,
>>
>> Really cool proposal. I’ve been thinking a lot lately about script paths
>> for inheritance. In a lot of the “have a relative time lock that allows a
>> different key to spend coins, or allows a smaller threshold of a multisig
>> to spend” schemes, you have the problem of needing to “refresh” all of your
>> coins when the timelock is close to maturation. In a lot of the “use
>> multisig with ephemeral keys to emulate covenants” schemes, you have to
>> pre-commit to the terminal destination well in advance of the spend-path
>> being used, which leads to all kinds of thorny questions about security and
>> availability of *those* keys. In other words, you either have to have
>> unbound destinations but a timer that needs resetting, or you have unbound
>> time but fixed destinations. This design gets you the best of both because
>> the destination SPKs aren’t committed to until the unvaulting process
>> starts. This (or something like this with destination binding at
>> unvault-time) would be an incredibly useful tool for inheritance designs in
>> wallets.
>>
>> I need to think a bit more about the recovery path not having any real
>> encumbrances on it. Maybe in practice if you’re worried about DoS, you have
>> UTXOs that commit to multiple vault paths that have tweaked recovery
>> destinations or something, or maybe it really is the right move to say that
>> if recovery is triggered, you probably do want it for all of your inflight
>> unvaultings.
>>
>> Looking forward to reading this a few more times and talking more about
>> it.
>>
>> Thanks!
>> rijndael
>>
>>
>> On Mon, Jan 9, 2023 at 11:07 AM, James O'Beirne via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> For the last few years, I've been interested in vaults as a way to
>> substantially derisk custodying Bitcoin, both at personal and commercial
>> scales. Instead of abating with familiarity, as enthusiasm sometimes
>> does, my conviction that vaults are an almost necessary part of bitcoin's
>> viability has only grown over the years.
>>
>> Since people first started discussing vaults, it's been pretty clear that
>> some kind of covenant-enabling consensus functionality is necessary to
>> provide the feature set necessary to make vault use practical.
>>
>> Earlier last year I experimented with using OP_CTV[1], a limited covenant
>> mechanism, to implement a "minimum-viable" vault design. I found that the
>> inherent limitations of a precomputed covenant scheme left the resulting
>> vault implementation wanting, even though it was an improvement over
>> existing strategies that rely on presigned transactions and (hopefully)
>> ephemeral keys.
>>
>> But I also found proposed "general" covenant schemes to be
>> unsuitable for this use. The bloated scriptPubKeys, both in size and
>> complexity, that would result when implementing something like a vault
>> weren't encouraging. Also importantly, the social-consensus quagmire
>> regarding which covenant proposal to actually deploy feels at times
>> intractable.
>>
>> As a result, I wanted to explore a middle way: a design solely concerned
>> with making the best vault use possible, with covenant functionality as a
>> secondary consideration. In other words, a proposal that would deliver
>> the safety benefits of vaults to users without getting hung up on
>> trying to solve the general problem of covenants.
>>
>> At first this design, OP_VAULT, was just sort of a pipe dream. But as I
>> did more thinking (and eventually implementing) I became more convinced
>> that, even if it isn't considered for soft-fork, it is a worthwhile
>> device to serve as a standard benchmark against which other proposals
>> might be judged.
>>
>> I wrote a paper that summarizes my findings and the resulting proposal:
>> https://jameso.be/vaults.pdf
>>
>> along with an accompanying draft implementation:
>> https://github.com/bitcoin/bitcoin/pull/26857
>>
>> I might work on a BIP if there's interest.
>>
>> James
>>
>> [1]: https://github.com/jamesob/simple-ctv-vault
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230109/b0fc1b4c/attachment.html>

2023-06-08 01:18:16 CEST

- reply

📅 Original date posted:2023-01-09
🗒️ Summary of this message: James O'Beirne proposes a new design, OP_VAULT, for Bitcoin vaults that prioritizes safety benefits without getting hung up on solving the general problem of covenants.
📝 Original message:For the last few years, I've been interested in vaults as a way to
substantially derisk custodying Bitcoin, both at personal and commercial
scales. Instead of abating with familiarity, as enthusiasm sometimes
does, my conviction that vaults are an almost necessary part of bitcoin's
viability has only grown over the years.
Since people first started discussing vaults, it's been pretty clear that
some kind of covenant-enabling consensus functionality is necessary to
provide the feature set necessary to make vault use practical.
Earlier last year I experimented with using OP_CTV[1], a limited covenant
mechanism, to implement a "minimum-viable" vault design. I found that the
inherent limitations of a precomputed covenant scheme left the resulting
vault implementation wanting, even though it was an improvement over
existing strategies that rely on presigned transactions and (hopefully)
ephemeral keys.
But I also found proposed "general" covenant schemes to be
unsuitable for this use. The bloated scriptPubKeys, both in size and
complexity, that would result when implementing something like a vault
weren't encouraging. Also importantly, the social-consensus quagmire
regarding which covenant proposal to actually deploy feels at times
intractable.
As a result, I wanted to explore a middle way: a design solely concerned
with making the best vault use possible, with covenant functionality as a
secondary consideration. In other words, a proposal that would deliver
the safety benefits of vaults to users without getting hung up on
trying to solve the general problem of covenants.
At first this design, OP_VAULT, was just sort of a pipe dream. But as I
did more thinking (and eventually implementing) I became more convinced
that, even if it isn't considered for soft-fork, it is a worthwhile
device to serve as a standard benchmark against which other proposals
might be judged.
I wrote a paper that summarizes my findings and the resulting proposal:
https://jameso.be/vaults.pdf
along with an accompanying draft implementation:
https://github.com/bitcoin/bitcoin/pull/26857
I might work on a BIP if there's interest.
James
[1]: https://github.com/jamesob/simple-ctv-vault
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230109/21bf137d/attachment.html>

2023-06-08 01:03:27 CEST

- reply

📅 Original date posted:2022-02-11
📝 Original message:I don't oppose recursive covenants per se, but in prior posts I have
expressed uncertainty about proposals that enable more "featureful"
covenants by adding more kinds of computation into bitcoin script.
Not that anyone here is necessarily saying otherwise, but I am very
interested in limiting operations in bitcoin script to "verification" (vs.
"computation") to the extent practical, and instead encouraging general
computation be done off-chain. This of course isn't a new observation and I
think the last few years have been very successful to that effect, e.g. the
popularity of the "scriptless scripts" idea and Taproot's emphasis on
embedding computational artifacts in key tweaks.
My (maybe unfounded?) worry about opcodes like OP_CAT and OP_TX is that
more logic will live in script than is necessary, and so the burden to
verify the chain may grow and the extra "degrees of freedom" in script may
make it harder to reason about. But I guess at this point there aren't
alternative means to construct new kinds of sighashes that are necessary
for some interesting covenants.
One thing I like about CTV is that it buys a lot of functionality without
increasing the "surface area" of script's design. In general I think there
is a lot to be said for this "jets"-style approach[0] of codifying the
script operations that you'd actually want to do into single opcodes. This
adds functionality while introducing minimal surface area to script, giving
script implementers more flexibility for, say, optimization. But of course
this comes at the cost of precluding experimentation, and probably
requiring more soft-forking. Though whether the place for script
experimentation using more general-purpose opcodes on the main chain is
another interesting debate...
Sorry for going a little off-topic there.
[0]: https://medium.com/blockstream/simplicity-jets-release-803db10fd589
On Thu, Feb 10, 2022 at 7:55 PM David A. Harding via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev
> wrote:
> > Whether [recursive covenants] is an issue or not precluding this sort
> > of design or not, I defer to others.
>
> For reference, I believe the last time the merits of allowing recursive
> covenants was discussed at length on this list[1], not a single person
> replied to say that they were opposed to the idea.
>
> I would like to suggest that anyone opposed to recursive covenants speak
> for themselves (if any intelligent such people exist). Citing the risk
> of recursive covenants without presenting a credible argument for the
> source of that risk feels to me like (at best) stop energy[2] and (at
> worst) FUD.
>
> -Dave
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html
> [2]
> http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html
> (thanks to AJ who told me about stop energy one time when I was
> producing it)
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220211/bf500325/attachment.html>

2023-06-07 20:17:25 CEST

- reply

📅 Original date posted:2019-04-03
📝 Original message:Thanks for the reply, Jonas. I should've figured someone had hit the
mailing list with this one before!
In hindsight, I may have overemphasized the use of this for low-powered
mobile devices. Indeed I think this may also be a worthwhile optimization
for common hardware too.
On the margin, if a user wants to interact with Bitcoin they will download
software that allows them to do it immediately - this results in many
people defaulting to a light client. If Bitcoin were able to initialize
from scratch in a comparable amount of time and then populate the full
chain in the background, we may have many more people *incidentally*
running full nodes.
Regardless of whether or not we use UTXO snapshots per se, I'd argue that
the pattern of doing some kind of quick initialization (whether it's with
assumed-valid data, or headers-contingent data like BIP157) and then
performing full validation in the background is a good way to ensure that
we have a healthier population of full nodes than we would otherwise.
For this reason, and (as Ethan points out) because IBD's linear setup time
is infeasible in the long-term, I think this pattern is an obvious
direction for the bitcoin client to go.
> * Do we semi-trust the peer that servers the UTXO set (compared to a
block or tx which we can validate)? What channel to we use to serve the
snapshot?
As you note in your post from 2016, where and how we retrieve the snapshot
is more or less immaterial because we compare a hash of its contents to a
previously specified value that the code ships with (the `assumeutxo`
hash). We don't need to trust the source serving it to us, although
bandwidth DoS prevention via some kind chunked delivery from peers would be
worth thinking about.
Regards,
James
On Wed, Apr 3, 2019 at 2:37 AM Jonas Schnelli <dev at jonasschnelli.ch> wrote:
> Thanks James for the post.
>
> I proposed a similar idea [1] back in 2016 with the difference of signing
> the UTXO-set hash in a gitian-ish way.
>
> While the idea of UTXO-set-syncs are attractive, there are probably still
> significant downsides in usability (compared to models with less security),
> mainly:
> * Assume the UTXO set is 6 weeks old (which seems a reasonable age for
> providing enough security) a peer using that snapshot would still require
> to download and verify ~6048 blocks (~7.9GB at 1.3MB blocks,… probably
> CPU-days on a phone)
> * Do we semi-trust the peer that servers the UTXO set (compared to a block
> or tx which we can validate)? What channel to we use to serve the snapshot?
>
> If the goal is to run a full node on a consumer device that is also been
> used for other CPU intense operations (like a phone, etc.), I’m not sure if
> this proposal will lead to a satisfactory user experience.
>
> The longer I think around this problem, the more I lean towards accepting
> the fact that one need to use dedicated hardware in his own environment to
> perform a painless full validation.
>
> /jonas
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012478.html
>
> > Am 02.04.2019 um 22:43 schrieb James O'Beirne via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>:
> >
> > Hi,
> >
> > I'd like to discuss assumeutxo, which is an appealing and simple
> > optimization in the spirit of assumevalid[0].
> >
> > # Motivation
> >
> > To start a fully validating bitcoin client from scratch, that client
> currently
> > needs to perform an initial block download. To the surprise of no one,
> IBD
> > takes a linear amount time based on the length of the chain's history.
> For
> > clients running on modest hardware under limited bandwidth constraints,
> > say a mobile device, completing IBD takes a considerable amount of time
> > and thus poses serious usability challenges.
> >
> > As a result, having fully validating clients run on such hardware is
> rare and
> > basically unrealistic. Clients with even moderate resource constraints
> > are encouraged to rely on the SPV trust model. Though we have promising
> > improvements to existing SPV modes pending deployment[1], it's worth
> > thinking about a mechanism that would allow such clients to use trust
> > models closer to full validation.
> >
> > The subject of this mail is a proposal for a complementary alternative
> to SPV
> > modes, and which is in the spirit of an existing default, `assumevalid`.
> It may
> > help modest clients transact under a security model that closely
> resembles
> > full validation within minutes instead of hours or days.
> >
> > # assumeutxo
> >
> > The basic idea is to allow nodes to initialize using a serialized
> version of the
> > UTXO set rendered by another node at some predetermined height. The
> > initializing node syncs the headers chain from the network, then obtains
> and
> > loads one of these UTXO snapshots (i.e. a serialized version of the UTXO
> set
> > bundled with the block header indicating its "base" and some other
> metadata).
> >
> > Based upon the snapshot, the node is able to quickly reconstruct its
> chainstate,
> > and compares a hash of the resulting UTXO set to a preordained hash
> hard-coded
> > in the software a la assumevalid. This all takes ~23 minutes, not
> accounting for
> > download of the 3.2GB snapshot[2].
> >
> > The node then syncs to the network tip and afterwards begins a
> simultaneous
> > background validation (i.e., a conventional IBD) up to the base height
> of the
> > snapshot in order to achieve full validation. Crucially, even while the
> > background validation is happening the node can validate incoming blocks
> and
> > transact with the benefit of the full (assumed-valid) UTXO set.
> >
> > Snapshots could be obtained from multiple separate peers in the same
> manner as
> > block download, but I haven't put much thought into this. In concept it
> doesn't
> > matter too much where the snapshots come from since their validity is
> > determined via content hash.
> >
> > # Security
> >
> > Obviously there are some security implications due consideration. While
> this
> > proposal is in the spirit of assumevalid, practical attacks may become
> easier.
> > Under assumevalid, a user can be tricked into transacting under a false
> history
> > if an attacker convinces them to start bitcoind with a malicious
> `-assumevalid`
> > parameter, sybils their node, and then feeds them a bogus chain
> encompassing
> > all of the hard-coded checkpoints[3].
> >
> > The same attack is made easier in assumeutxo because, unlike in
> assumevalid,
> > the attacker need not construct a valid PoW chain to get the victim's
> node into
> > a false state; they simply need to get the user to accept a bad
> `-assumeutxo`
> > parameter and then supply them an easily made UTXO snapshot containing,
> say, a
> > false coin assignment.
> >
> > For this reason, I recommend that if we were to implement assumeutxo, we
> not
> > allow its specification via commandline argument[4].
> >
> > Beyond this risk, I can't think of material differences in security
> relative to
> > assumevalid, though I appeal to the list for help with this.
> >
> > # More fully validating clients
> >
> > A particularly exciting use-case for assumeutxo is the possibility of
> mobile
> > devices functioning as fully validating nodes with access to the
> complete UTXO
> > set (as an alternative to SPV models). The total resource burden needed
> to start a node
> > from scratch based on a snapshot is, at time of writing, a ~(3.2GB
> > + blocks_to_tip * 4MB) download and a few minutes of processing time,
> which sounds
> > manageable for many mobile devices currently in use.
> >
> > A mobile user could initialize an assumed-valid bitcoin node within an
> hour,
> > transact immediately, and complete a pruned full validation of their
> > assumed-valid chain over the next few days, perhaps only doing the
> background
> > IBD when their device has access to suitable high-bandwidth connections.
> >
> > If we end up implementing an accumulator-based UTXO scaling design[5][6]
> down
> > the road, it's easy to imagine an analogous process that would allow
> very fast
> > startup using an accumulator of a few kilobytes in lieu of a multi-GB
> snapshot.
> >
> > ---
> >
> > I've created a related issue at our Github repository here:
> > https://github.com/bitcoin/bitcoin/issues/15605
> >
> > and have submitted a draft implementation of snapshot usage via RPC here:
> > https://github.com/bitcoin/bitcoin/pull/15606
> >
> > I'd like to discuss here whether this is a good fit for Bitcoin
> conceptually. Concrete
> > plans for deployment steps should be discussed in the Github issue, and
> after all
> > that my implementation may be reviewed as a sketch of the specific
> software
> > changes necessary.
> >
> > Regards,
> > James
> >
> >
> > [0]:
> https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks
> > [1]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki
> > [2]: as tested at height 569895, on a 12 core Intel Xeon Silver 4116 CPU
> @ 2.10GHz
> > [3]:
> https://github.com/bitcoin/bitcoin/blob/84d0fdc/src/chainparams.cpp#L145-L161
> > [4]: Marco Falke is due credit for this point
> > [5]: utreexo: https://www.youtube.com/watch?v=edRun-6ubCc
> > [6]: Boneh, Bunz, Fisch on accumulators:
> https://eprint.iacr.org/2018/1188
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190403/e631ec0b/attachment.html>

2023-06-07 20:17:24 CEST

- reply

📅 Original date posted:2019-04-04
📝 Original message:I recommend that anyone following this thread read through the recent IRC
exchange between Greg Maxwell and Luke Dashjr:
http://www.erisian.com.au/bitcoin-core-dev/log-2019-04-04.html
<http://www.erisian.com.au/bitcoin-core-dev/log-2019-04-04.html>
The conversation starts on line 205 at 2019-04-04T02:54:50.
On Thu, Apr 4, 2019 at 2:38 AM Jim Posen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Learning C++ is something within everyone's capability. Even people who do
>> not
>> wish to learn it can hire someone to perform review for them.
>>
>
> Anyone with enough knowledge of C++ to audit the entire the Bitcoin Core
> codebase is more than capable of running it with assumeutxo disabled and
> checking the hard-coded vale themself.
>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190404/91235d28/attachment-0001.html>

2023-06-07 20:17:21 CEST

- reply

📅 Original date posted:2019-04-02
📝 Original message:Hi,
I'd like to discuss assumeutxo, which is an appealing and simple
optimization in the spirit of assumevalid[0].
# Motivation
To start a fully validating bitcoin client from scratch, that client
currently
needs to perform an initial block download. To the surprise of no one, IBD
takes a linear amount time based on the length of the chain's history. For
clients running on modest hardware under limited bandwidth constraints,
say a mobile device, completing IBD takes a considerable amount of time
and thus poses serious usability challenges.
As a result, having fully validating clients run on such hardware is rare
and
basically unrealistic. Clients with even moderate resource constraints
are encouraged to rely on the SPV trust model. Though we have promising
improvements to existing SPV modes pending deployment[1], it's worth
thinking about a mechanism that would allow such clients to use trust
models closer to full validation.
The subject of this mail is a proposal for a complementary alternative to
SPV
modes, and which is in the spirit of an existing default, `assumevalid`. It
may
help modest clients transact under a security model that closely resembles
full validation within minutes instead of hours or days.
# assumeutxo
The basic idea is to allow nodes to initialize using a serialized version
of the
UTXO set rendered by another node at some predetermined height. The
initializing node syncs the headers chain from the network, then obtains and
loads one of these UTXO snapshots (i.e. a serialized version of the UTXO set
bundled with the block header indicating its "base" and some other
metadata).
Based upon the snapshot, the node is able to quickly reconstruct its
chainstate,
and compares a hash of the resulting UTXO set to a preordained hash
hard-coded
in the software a la assumevalid. This all takes ~23 minutes, not
accounting for
download of the 3.2GB snapshot[2].
The node then syncs to the network tip and afterwards begins a simultaneous
background validation (i.e., a conventional IBD) up to the base height of
the
snapshot in order to achieve full validation. Crucially, even while the
background validation is happening the node can validate incoming blocks and
transact with the benefit of the full (assumed-valid) UTXO set.
Snapshots could be obtained from multiple separate peers in the same manner
as
block download, but I haven't put much thought into this. In concept it
doesn't
matter too much where the snapshots come from since their validity is
determined via content hash.
# Security
Obviously there are some security implications due consideration. While this
proposal is in the spirit of assumevalid, practical attacks may become
easier.
Under assumevalid, a user can be tricked into transacting under a false
history
if an attacker convinces them to start bitcoind with a malicious
`-assumevalid`
parameter, sybils their node, and then feeds them a bogus chain encompassing
all of the hard-coded checkpoints[3].
The same attack is made easier in assumeutxo because, unlike in assumevalid,
the attacker need not construct a valid PoW chain to get the victim's node
into
a false state; they simply need to get the user to accept a bad
`-assumeutxo`
parameter and then supply them an easily made UTXO snapshot containing,
say, a
false coin assignment.
For this reason, I recommend that if we were to implement assumeutxo, we not
allow its specification via commandline argument[4].
Beyond this risk, I can't think of material differences in security
relative to
assumevalid, though I appeal to the list for help with this.
# More fully validating clients
A particularly exciting use-case for assumeutxo is the possibility of mobile
devices functioning as fully validating nodes with access to the complete
UTXO
set (as an alternative to SPV models). The total resource burden needed to
start a node
from scratch based on a snapshot is, at time of writing, a ~(3.2GB
+ blocks_to_tip * 4MB) download and a few minutes of processing time, which
sounds
manageable for many mobile devices currently in use.
A mobile user could initialize an assumed-valid bitcoin node within an hour,
transact immediately, and complete a pruned full validation of their
assumed-valid chain over the next few days, perhaps only doing the
background
IBD when their device has access to suitable high-bandwidth connections.
If we end up implementing an accumulator-based UTXO scaling design[5][6]
down
the road, it's easy to imagine an analogous process that would allow very
fast
startup using an accumulator of a few kilobytes in lieu of a multi-GB
snapshot.
---
I've created a related issue at our Github repository here:
https://github.com/bitcoin/bitcoin/issues/15605
and have submitted a draft implementation of snapshot usage via RPC here:
https://github.com/bitcoin/bitcoin/pull/15606
I'd like to discuss here whether this is a good fit for Bitcoin
conceptually. Concrete
plans for deployment steps should be discussed in the Github issue, and
after all
that my implementation may be reviewed as a sketch of the specific software
changes necessary.
Regards,
James
[0]:
https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks
[1]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki
[2]: as tested at height 569895, on a 12 core Intel Xeon Silver 4116 CPU @
2.10GHz
[3]:
https://github.com/bitcoin/bitcoin/blob/84d0fdc/src/chainparams.cpp#L145-L161
[4]: Marco Falke is due credit for this point
[5]: utreexo: https://www.youtube.com/watch?v=edRun-6ubCc
[6]: Boneh, Bunz, Fisch on accumulators: https://eprint.iacr.org/2018/1188
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190402/46b25dd8/attachment-0001.html>

2023-06-07 19:43:03 CEST

- reply

📅 Original date posted:2015-10-07
📝 Original message:This has been confirmed as a bug. Thanks again for reporting. I've filed a
fix here (https://github.com/bitcoin/bitcoin/pull/6777), and will be
writing tests to prevent regressions.
On Wed, Oct 7, 2015 at 4:32 PM, James O'Beirne <james.obeirne at gmail.com>
wrote:
> Hey, Daniel.
>
> Patch author here. Thanks for the diligence; I think this indeed may be an
> oversight, though I'm going to need to look into a bit more thoroughly at
> home. Curious that it didn't fail any of the automated tests.
>
> Correct me if I'm wrong, but the only actual invocation of that method is
> here
> <https://github.com/bitcoin/bitcoin/blob/master/src/rpcblockchain.cpp#L448>
> (and even then, proxied through a few layers of CCoinView-machinery). In
> fact, this line
> <https://github.com/bitcoin/bitcoin/blob/master/src/coins.cpp#L48> makes
> me suspect that the implementation of GetStats you reference may be dead
> code.
>
> In any case, you raise a good point: if users of CLevelDBWrapper go
> directly for the iterator, they run the risk of dealing with obfuscated
> data. This should be remedied somehow.
>
> I'll give it more look this evening.
>
> Thanks again for the find,
> James
>
> On Wed, Oct 7, 2015 at 10:25 AM, Daniel Kraft via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi!
>>
>> I hope this is not a stupid question, but I thought I'd ask here first
>> instead of opening a Github ticket (in case I'm wrong).
>>
>> With the recently merged "obfuscation" patch, content of the
>> "chainstate" LevelDB is obfuscated by XOR'ing against a random "key".
>> This is handled by CLevelDBWrapper's Read/Write methods, which probably
>> cover most of the usecases.
>>
>> *However*, shouldn't it also be handled when iterating over the
>> database? In particular, I would expect that the obfuscation key is
>> applied before line 119 in txdb.cpp (i. e., while iterating over the
>> coin database in CCoinsViewDB::GetStats).
>>
>> Is there a reason why this need not be done there, or is this an actual
>> oversight?
>>
>> Yours,
>> Daniel
>>
>> --
>> http://www.domob.eu/
>> OpenPGP: 1142 850E 6DFF 65BA 63D6 88A8 B249 2AC4 A733 0737
>> Namecoin: id/domob -> https://nameid.org/?name=domob
>> --
>> Done: Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
>> To go: Mon-Pri
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151007/ce7d4d3f/attachment-0001.html>

2023-06-07 19:43:02 CEST

- reply

📅 Original date posted:2015-10-07
📝 Original message:Hey, Daniel.
Patch author here. Thanks for the diligence; I think this indeed may be an
oversight, though I'm going to need to look into a bit more thoroughly at
home. Curious that it didn't fail any of the automated tests.
Correct me if I'm wrong, but the only actual invocation of that method is
here
<https://github.com/bitcoin/bitcoin/blob/master/src/rpcblockchain.cpp#L448>
(and even then, proxied through a few layers of CCoinView-machinery). In
fact, this line
<https://github.com/bitcoin/bitcoin/blob/master/src/coins.cpp#L48> makes me
suspect that the implementation of GetStats you reference may be dead code.
In any case, you raise a good point: if users of CLevelDBWrapper go
directly for the iterator, they run the risk of dealing with obfuscated
data. This should be remedied somehow.
I'll give it more look this evening.
Thanks again for the find,
James
On Wed, Oct 7, 2015 at 10:25 AM, Daniel Kraft via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi!
>
> I hope this is not a stupid question, but I thought I'd ask here first
> instead of opening a Github ticket (in case I'm wrong).
>
> With the recently merged "obfuscation" patch, content of the
> "chainstate" LevelDB is obfuscated by XOR'ing against a random "key".
> This is handled by CLevelDBWrapper's Read/Write methods, which probably
> cover most of the usecases.
>
> *However*, shouldn't it also be handled when iterating over the
> database? In particular, I would expect that the obfuscation key is
> applied before line 119 in txdb.cpp (i. e., while iterating over the
> coin database in CCoinsViewDB::GetStats).
>
> Is there a reason why this need not be done there, or is this an actual
> oversight?
>
> Yours,
> Daniel
>
> --
> http://www.domob.eu/
> OpenPGP: 1142 850E 6DFF 65BA 63D6 88A8 B249 2AC4 A733 0737
> Namecoin: id/domob -> https://nameid.org/?name=domob
> --
> Done: Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
> To go: Mon-Pri
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151007/d8da0a40/attachment.html>