While I haven't looked at the BitVM in detail, I would like to mention that
Simplicity's core language (excluding introspection primitives) has the
same expressivity as Boolean circuits.
A few years ago I did some experiments to compile Simplicity expressions to
a system of polynomial constraints
It's been said before, but I'll say it again:
If we ban "arbitrary data", however you want to define it, then actors will
simply respond by encoding their data within sets of public keys. Public
key data is indistinguishable from random data, and, unless we are willing
to pad the blockchain with
One more thing (Again apologies. This idea of doing partial verification is
novel to me, and I see now that I should have just waited to give a
consolidated reply).
Focusing in on the example of performing 2 character quick checks. There
are 7 different ways of building the table used in this
Sorry for the repeated replies, but I would like to make one more remark
regarding the 1 character "quick check".
Because the 1 character "quick check" state is so small, the procedure
becomes simplified to just using a single table. You start with the
specified initial state, which would be the
After some consultation, I now see that generators for all degree 2 BCH
codes, such as ours, are smooth and factor into quadratic and linear
components.
Anyhow the upshot of all this is that you can perform a "quickcheck"
verification of the codex32 strings for whatever size of verification you
After some poking around at the math, I do see that the 13 character
generator (for regular sized shares) is reasonably "smooth", having roots
at T{11}, S{16}, and C{24}.
This means we could build a "quick check" worksheet to evaluate the string
modulo (x - T) to verify a 5 bit checksum, whose
On Sun, Feb 19, 2023 at 3:13 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>Codex32 allows the individual to periodically perform their
>recollection on paper in a private room without electronics and use
>nothing but a pen and some loookup tables
On Sun, Feb 19, 2023 at 5:13 PM Andrew Poelstra via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Sun, Feb 19, 2023 at 10:13:33AM -1000, David A. Harding wrote:
>
> I'm curious about whether there's a way to prevent this attack without
> > otherwise compromising the properties
On Sat, Feb 18, 2023 at 5:11 AM vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Also, it gives us a hint, that if any Script upgrade will be considered in
> the future, we can think about doing it in a way, where unused parts can be
> pruned, without invalidating
I've been asked by Dr. Curr and Professor Snead to forward this message to
this mailing list, as it may be of general interest to Bitcoin users.
Dear Colleague:
In 1967, during excavation for the construction of a new shopping center in
Monroeville, Pennsylvania, workers uncovered a vault
Yes. If you would otherwise sign the tapleaf, then I would recommend also
signing the entire tapbranch.
On Sat, Feb 11, 2023 at 12:15 AM Anthony Towns wrote:
> On 9 February 2023 12:04:16 am AEST, Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote
se: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> --- Original Message ---
> On Tuesday, February 7th, 2023 at 18:35, Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> There is a bug in Ta
There is a bug in Taproot that allows the same Tapleaf to be repeated
multiple times in the same Taproot, potentially at different Taplevels
incurring different Tapfee rates.
The countermeasure is that you should always know the entire Taptree when
interacting with someone's Tapspend.
On Tue,
On Sat., Feb. 4, 2023, 21:01 Peter Todd, wrote:
>
>
> On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via bitcoin-dev
> wrote:
> >Since bytes in the witness are cheaper than bytes in the script pubkey,
> >there is a crossover point in data size where i
Since bytes in the witness are cheaper than bytes in the script pubkey,
there is a crossover point in data size where it will simply be cheaper to
use witness data. Where that crossover point is depends on the finer
details of the overhead of the two methods, but you could make some
reasonable
On Fri, Nov 4, 2022 at 4:04 PM Trey Del Bonis via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Instead of that approach, I assume we have fairly granular transaction
> introspection opcodes from a list in Elements [2] (which seem like they
> aren't actually used in mainnet
On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> However, what *is* important about what Satoshi wrote is that it is sort
> of the "social contract" of what Bitcoin is that we can all sort of
> minimally agree to. This makes it
>From my limited academic interactions, people generally take the "honest"
to mean following the rules (regardless of how bad it is for you to follow
those rules). This has in turn led to some blockchain designs based on
their own absurd set of rules, and simply waiving away their issues by
in the
mempool.
Also your point about centralization pressure is well taken.
On Mon, Jul 11, 2022 at 5:56 PM Peter Todd wrote:
> On Mon, Jul 11, 2022 at 05:36:52PM -0400, Peter Todd via bitcoin-dev wrote:
> > On Mon, Jul 11, 2022 at 04:35:02PM -0400, Russell O'Connor via
> bitcoin-dev wrote:
On Mon, Jul 11, 2022 at 2:19 PM Bram Cohen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> If transaction fees came in at an even rate over time all at the exact
> same level then they work fine for security, acting similarly to fixed
> block rewards. Unfortunately that isn't
On Fri, May 13, 2022 at 5:43 PM Anthony Towns wrote:
> For any specific opcode proposal, I think you still want to consider
>
> 1) how much you can do with it
> 2) how efficient it is to validate (and thus how cheap it is to use)
> 3) how easy it is to make it do what you want
> 4) how
On Wed, May 11, 2022 at 11:07 PM ZmnSCPxj wrote:
> Good morning Russell,
>
> > On Wed, May 11, 2022 at 7:42 AM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > REMEMBER: `OP_CAT` BY ITSELF DOES NOT ENABLE COVENANTS, WHETHER
> RECURSIVE OR NOT.
> >
> >
> > I
On Wed, May 11, 2022 at 7:42 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> REMEMBER: `OP_CAT` BY ITSELF DOES NOT ENABLE COVENANTS, WHETHER RECURSIVE
> OR NOT.
>
I think the state of the art has advanced to the point where we can say
"OP_CAT in tapscript enables
Hi alicexbt,
As far as I understand things, I believe the whole notion of a MUST_SIGNAL
state is misguided today. Please correct me if I'm misunderstanding
something here.
Back when BIP8 was first proposed by Shaolin Fry, we were in a situation
where many existing clients waiting for segwit
On Fri, May 6, 2022 at 2:01 PM Jorge Timón via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Russell O'Connor wrote the definitive explanation for how ST arose in
>> the consensus process and how it was designed to make everyone
>> unhappy. It's a great explanation of what we
On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud wrote:
> @Russel
> > the original MES vault .. commits to the destination address during
> unvaulting
>
> I see. Looking at the MES16 paper, OP_COV isn't described clearly enough
> for me to understand that it does that. However, I can imagine how it
his all wrong.
>
> On 4/22/22 10:25 AM, Russell O'Connor via bitcoin-dev wrote:
> > It's not the attackers *only choice to succeed*. If an attacker steals
> the hot key, then they have
> > the option to simply wait for the user to unvault their funds of their
> own a
On Sat, Apr 23, 2022 at 12:56 AM Billy Tetrud
wrote:
> > If an attacker steals the hot key, then they have the option to simply
> wait for the user to unvault their funds
>
> This is definitely true. Its kind of a problem with most vault proposals.
> Its one of the primary reasons I designed an
On Fri, Apr 22, 2022 at 12:29 PM James O'Beirne via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> This vault design (https://github.com/jamesob/simple-ctv-vault)
> is a good benchmark for evaluating covenant proposals because it's (i)
> simple and (ii) has high utility for many
On Thu, Apr 21, 2022 at 1:04 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> - is there really any benefit to doing it as a NOP vs a taproot-only
>opcode like TXHASH? Theoretically, sure, that saves some bytes; but as
>was pointed out on
Thanks for the clarification.
You don't think referring to the microcode via its hash, effectively using
32-byte encoding of opcodes, is still rather long winded?
On Tue, Mar 22, 2022 at 12:23 PM ZmnSCPxj wrote:
> Good morning Russell,
>
> > Setting aside my thoughts that something like
Setting aside my thoughts that something like Simplicity would make a
better platform than Bitcoin Script (due to expression operating on a more
narrow interface than the entire stack (I'm looking at you OP_DEPTH)) there
is an issue with namespace management.
If I understand correctly, your
On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón wrote:
>
> A major contender to the Speedy Trial design at the time was to mandate
>> eventual forced signalling, championed by luke-jr. It turns out that, at
>> the time of that proposal, a large amount of hash power simply did not have
>> the
On Fri, Mar 11, 2022 at 7:18 AM Jorge Timón wrote:
> I talked about this. But the "no-divergent-rules" faction doesn't like it,
> so we can pretend we have listened to this "faction" and addressed all its
> concerns, I guess.
> Or perhaps it's just "prosectution complex", but, hey, what do I
On Thu., Mar. 10, 2022, 08:04 Jorge Timón via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> You're right, we shouldn't get personal. We shouldn't ignore feedback from
> me, mark friedenbach or luke just because of who it comes from.
>
For goodness sake Jorge, enough with the
The circuit generated from Simplicity was larger than the hand made one.
On Sat, Mar 5, 2022 at 6:20 PM ZmnSCPxj wrote:
> Good morning Russell,
>
> > On Sat, Mar 5, 2022 at 8:41 AM Jeremy Rubin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > It seems like a decent
On Sat, Mar 5, 2022 at 8:41 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> It seems like a decent concept for exploration.
>
> AJ, I'd be interested to know what you've been able to build with Chia
> Lisp and what your experience has been... e.g. what does the
On Thu, Feb 17, 2022 at 9:27 AM Anthony Towns wrote:
>
> I guess that's all partly dependent on thinking that, TXHASH isn't
> great for tx introspection (especially without CAT) and, (without tx
> introspection and decent math opcodes), DLCs already provide all the
> interesting oracle behaviour
On Tue, Feb 15, 2022 at 10:45 PM Rusty Russell
wrote:
> Jeremy Rubin writes:
> > Hi Rusty,
> >
> > Please see my post in the other email thread
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html
> >
> > The differences in this regard are several, and worth
> >> 2. (from Suhas) "once a valid transaction is created, it should not
> become invalid later on unless the inputs are double-spent."
> > This doesn't seem like a huge concern to me
>
> I agree that this shouldn't be a concern. In fact, I've asked numerous
> people in numerous places what
On Tue, Feb 15, 2022 at 1:57 PM Jeremy Rubin
wrote:
> Hi Rusty,
>
> Please see my post in the other email thread
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html
>
> The differences in this regard are several, and worth understanding beyond
> "you can iterate
On Mon, Jan 31, 2022 at 8:16 PM Anthony Towns wrote:
> On Fri, Jan 28, 2022 at 08:56:25AM -0500, Russell O'Connor via bitcoin-dev
> wrote:
> > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
> > For more complex interactions, I
The hash would normally also cover the hash flags in use, and would be
different in those two cases.
But yes, it seems at the last minute I did include a suggestion to disable
covering the flag themselves in the hash and appear to have accidentally
allowed for recursive covenants (a common
On Fri, Jan 28, 2022 at 10:14 AM James O'Beirne
wrote:
> > Technical debt isn't a measure of weight of transactions.
>
> Sorry, my original sentence was a little unclear. I meant to say that the
> notion that CTV is just a subpar waypoint en route to a more general
> covenant system may not be
On Thu, Jan 27, 2022 at 7:19 PM James O'Beirne
wrote:
> > I don't think implementing a CTV opcode that we expect to largely be
> obsoleted by a TXHASH at a later date is yielding good value from a soft
> fork process.
>
> This presumes the eventual adoption of TXHASH (or something like it).
>
On Thu, Jan 27, 2022 at 8:34 PM Anthony Towns wrote:
> > An Alternative Proposal::
> > ...
>
> > For similar reasons, TXHASH is not amenable to extending the set of
> txflags
> > at a later date.
>
> > I believe the difficulties with upgrading TXHASH can be mitigated by
> > designing a robust
on of perhaps scalability).
> - Bringing CTV to an implemented state of near-unanimous "we could do
> this, technically" is good for concretely driving the process of review for
> any covenant proposals forward, irrespective of if we ultimately activate.
> (I.e., if there were a reas
Recapping the relationship between CTV and ANYPREVOUT::
It is known that there is a significant amount of overlap in the
applications that are enabled by the CTV and ANYPREVOUT proposals despite
the fact that their primary applications (congestion control for CTV and
eltoo lightning channels for
On Wed, Jul 7, 2021 at 9:12 AM Russell O'Connor
wrote:
>
> On Wed, Jul 7, 2021 at 12:26 AM ZmnSCPxj wrote:
>
>> Good morning Russell,
>>
>> > Hi ZmnSCPxj,
>> >
>> > I don't believe we need to ban Turing completeness for the sake of
>> banning Turing completeness.
>>
>> Well I believe we should
On Wed, Jul 7, 2021 at 12:26 AM ZmnSCPxj wrote:
> Good morning Russell,
>
> > Hi ZmnSCPxj,
> >
> > I don't believe we need to ban Turing completeness for the sake of
> banning Turing completeness.
>
> Well I believe we should ban partial Turing-completeness, but allow total
>
If the main outstanding issue is whether to split R or S, I think as far as
Elements goes, I am inclined to go with the CAT option regardless of
whether Bitcoin chooses to split R/S or not (not that I'm necessarily a
decision maker here).
The issue here is that (a) Elements already has CAT, and
On Tue, Jul 6, 2021 at 2:26 AM Billy Tetrud wrote:
> > when people are talking about enabling covenants, we are talking about
> whether OP_CAT should be allowed or not
>
> Are they? Are you implying that anything that enables covenants is
> equivalent to enabling OP_CAT? Generally when I think
Hi ZmnSCPxj,
I don't believe we need to ban Turing completeness for the sake of banning
Turing completeness. My concerns have always been around ensuring that
transaction and block validation is not unduly burdensome for nodes. So
for Bitcoin Script, we want to bound the amount of resources
On Sun, Jul 4, 2021 at 9:02 PM Russell O'Connor
wrote:
> Bear in mind that when people are talking about enabling covenants, we are
> talking about whether OP_CAT should be allowed or not.
>
> That said, recursive covenants, the type that are most worrying, seems to
> require some kind of
Bear in mind that when people are talking about enabling covenants, we are
talking about whether OP_CAT should be allowed or not.
That said, recursive covenants, the type that are most worrying, seems to
require some kind of OP_TWEAK operation, and I haven't yet seen any
evidence that this can be
On Sun, Jul 4, 2021 at 1:30 PM Jeremy wrote:
> I don't really see the point of CHECKSIGFROMSTACKADD since it's not bound
> to the txdata? When might you use this?
>
I don't feel strongly about *ADD. I just figured it might be useful to do
a 2-of-3 between Alice, Bob and an Oracle signed value.
There is one line written at
https://github.com/ElementsProject/elements/pull/949/files#r660130155. I
suppose we need to decide on which variants of *VERIFY and *ADD we want to
include (presumably all of them) and choose which opcodes they will be
assigned to. And I guess for CHECKSIGFROMSTACKADD
Hi Jermy,
As you are aware, we, and by we I mean mostly Sanket, are developing an
updated OP_CHECKSIGFROMSTACK implementation for tapscript on elements. The
plan here would be to effectively support the an interface to the
variable-length extension of BIP-0340 schnorr signatures.
BIP-0340 would
On Sat, Jun 12, 2021 at 3:59 AM Billy Tetrud wrote:
> > taproot annex
>
> From what I can tell, the annex is basically additional inputs to a script
> that might have additional constraints put on it. Is that right? I don't
> quite follow how moving the max height to the annex helps script
On Fri, Jun 11, 2021 at 7:12 AM James MacWhyte wrote:
> @Billy I like the idea. It is very obvious how useful an opcode like this
> would be! (My background is in wallet implementation)
>
> @Russell I do understand your concerns of monotonism, however I'm having a
> hard time really coming up
As it stands today, in order to double spend a transaction during a reorg,
one must take an active role of recognizing that a reorg has happened, hope
that the new branch has completely omitted your spending transaction, and
then quickly broadcast a replacement transaction with a higher fee to
This is a continuation of the thread at
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018760.html
on this topic.
I still remain unconvinced that we ought to give up on the "reorg safety"
property that is explicitly part of Bitcoin's design.
On Thu, Jun 10, 2021 at 1:56 PM
Firstly, a minor point is that your proposal is a soft-fork, not a
hard-fork.
But more importantly, adding limitations on OP_RETURN transactions is not
helpful. Users who want to embed arbitrary data in their transactions can
always do so by encoding their data inside the values of legacy
>From https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119:
We can't safely do OP_BLOCKNUMBER. In the event of a block chain reorg
> after a segmentation, transactions need to be able to get into the chain in
> a later block. The OP_BLOCKNUMBER transaction and all its dependants would
On Tue, Apr 6, 2021 at 12:27 PM Russell O'Connor
wrote:
> On Tue, Apr 6, 2021 at 12:23 PM David A. Harding wrote:
>
>>
>> You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days" )
>>
>> Ten minute estimators can say:
>>
>> You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 *
On Tue, Apr 6, 2021 at 12:23 PM David A. Harding wrote:
>
> You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days" )
>
> Ten minute estimators can say:
>
> You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 * 2016))
> minutes" )
>
> And nine minute estimators can say:
>
>
I'm pretty sure that the question of "is signalling still possible by the
time enough miners have upgraded and are ready to start signalling?"
Strongly benefits from a guaranteed number of signaling periods that height
based activation offers. Especially for the short activation period of
Speedy
Hi Andrew,
This is a slight misunderstanding of the proposal. Rather than an extended
lockin period (a term I've erroneously used in the past) it is really a
minimum activation height.
Thus using your figures it would instead be:
* start height = 681408 /* about May 1st */
* timeout height =
Appologies as I've rearranged your comments in my reply.
On Wed, Mar 3, 2021 at 5:14 PM Matt Corallo
wrote:
>
> On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote:
>
> After a normal and successful Core update with LOT=false, we will have
> more data showing broad co
While I support essentially any proposed taproot activation method,
including a flag day activation, I think it is premature to call BIP8 dead.
Even today, I still think that starting with BIP8 LOT=false is, generally
speaking, considered a reasonably safe activation method in the sense that
I
On Thu, Oct 8, 2020 at 11:00 AM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Rather than go through that again, I'd prefer we use the
> backwards compatible proposal from BIPs PR#945 and, if we want to
> maximize safety, consensus restrict v1 witness program
With the help of Pieter I've recently made some interesting mathematical
observations about Bech32 codewords and Shamir's secret sharing:
(1) Affine combinations of two Bech32 codewords is again a valid Bech32
codeword.
(2) Lagrange polynomials form a partition of unity.
The consequences of
15, 2020 at 5:05 PM Greg Sanders wrote:
> Can you make it clear what the bold vs not-bold numbers mean?
>
> On Wed, Jul 15, 2020 at 4:56 PM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Wed, Nov 13, 2019 at 1:31 AM Pi
On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> That brings me to Matt's point: there is no need to do this right now. We
> can simply amend BIP173 to only permit length 20 and length 32 (and only
> length 20 for v0, if you like;
I don't believe that 60 bytes is a problem here. SHA256 padding includes a
length value of the original message data. Thus a padded non-64 byte
transaction can never be the same as any padded 64-byte value, and
therefore after applying the SHA256 compression function the resulting
hashes cannot
On Sat, May 2, 2020 at 10:26 AM Anthony Towns wrote:
>
> except that we'd arguably still be missing:
>
> is this a coinbase output? (Coin.fCoinBase)
> what was the height of the coin? (Coin.nHeight)
>
> Maybe committing to the coinbase flag would have some use, but committing
> to the
> If you didn't verify the output scriptPubKeys, you would *only* be able
> to care about fees since you couldn't verify where any of the funds went?
> And you'd only be able to say fees are "at least x", since they could be
> more if one of the scriptPubKeys turned out to be OP_TRUE eg. That
While I'm not entirely convinced yet that accertaining non-ownership of an
input is a robust method of solving the problem here, I also see little
reason not to amend BIP-341 as proposed. The ScriptPubKeys in question is
already indirectly covered through the outpoints, so it is just a matter of
On Sun, Mar 22, 2020 at 5:43 AM Tim Ruffing wrote:
> On Sat, 2020-03-21 at 12:59 -0400, Russell O'Connor wrote:
> > Public keys are deterministic and can be spot checked. In fact,
> > AFAIU if hardened HD key derivations are not used, then spot checking
> > is very easy.
> >
> > While spot
On Sat, Mar 21, 2020 at 12:46 PM Tim Ruffing via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Pieter,
>
> Let's take a step back first. If we believe that malicious hardware
> wallets are big enough of a concern, then signing is only part of the
> problem. The other issue is
On Wed, Feb 26, 2020 at 2:56 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> As a replacement for paper, something like this makes sense v.s. what you
> do with a ledger presently.
>
> However, shamir's shares notoriously have the issue that the key does
> exist
On Sun, Feb 23, 2020 at 11:26 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 2. Nonce generation
>
> All other semantical changes are around more secure nonce generation
> in BIP 340, dealing with various failure cases:
>
> * To protect against fault
After chatting with andytoshi and others, and some more thinking I've been
convinced that my specific concern about other users masquerading other
people pubkeys as their own in complex scripts is actually a non-issue.
No matter what you write in Script (today), you are limited to expressing
some
On Thu, Nov 28, 2019 at 3:07 AM Anthony Towns wrote:
> FWIW, there's discussion of this at
> http://www.erisian.com.au/taproot-bip-review/log-2019-11-28.html#l-65
>
I think variants like signing the position of the enclosing
OP_IF/OP_NOTIF/OP_ELSE of the OP_IF/OP_NOTIF/OP_ELSE block that the
Thanks for this work Jeremy.
I know we've discussed this before, but I'll restate my concerns with
adding a new "global" state variable to the Script interpreter for tracking
whether the previous opcode was a push-data operation or not. While it
isn't so hard to implement this in Bitcoin Core's
Hi all,
I'd like to revisit an old topic from last year about the data signed in
tapscript signatures <
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016508.html
>.
The current tapscript proposal requires a signature on the last executed
CODESEPRATOR position. I'd like
I do like the idea of length prefixing the witness program. I will note
that the 1 byte witness version is really more like a 1 character witness
version. There are 17 different segwit versions and there are 32
characters in the bech32 alphabet. That leaves 15 unused characters that
we can use
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>
>
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.
The two byte limit is derived from the block size / weight limit, which
limits the maximum size of a transaction,
Bitcoin Core is somewhat outside my core competence, but the various
OP_PUSHDATA are already multi-byte opcodes and GetOp already has a data
return parameter that is suitable for returning the payload of an immediate
32-byte data variant of OP_SECURETHEBAG. All that I expect is needed is to
I suspect that your conjecture is true. And given that it is plausible
that we would want to add an opcode to tweak public keys, it seems like a
reason design to avoid accidental covenants.
(That said, I strongly prefer that the SECURETHEBAG data be the 32-bytes
immediately following the opcode
u clarify this comment?
>
> We do in fact commit to the script and scriptsig itself (not the witness
> stack) in OP_SECURETHEBAG (unless I'm missing what you meant)?
>
> On Thu, Jun 20, 2019, 10:59 AM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wr
Just to be clear, while OP_CHECKTXDIGESTVERIFY would enable this style of
covenants if it pulled data from the stack, the OP_SECURETHEBAG probably
cannot create covenants even if it were to pull the data from the stack
unless some OP_TWEEKPUBKEY operation is added to Script because the
"commitment
On Sat, Jun 8, 2019 at 11:59 PM Rusty Russell wrote:
> "Russell O'Connor" writes:
> > Hi Rusty,
> >
> > On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> The new "emergency RBF" rule:
> >>
> >> 6. If the original
Hi Rusty,
On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> The new "emergency RBF" rule:
>
> 6. If the original transaction was not in the first 4,000,000 weight
> units of the fee-ordered mempool and the replacement transaction
On Sat, Jun 1, 2019 at 12:47 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi All,
>
> OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*.
> OP_SECURETHEBAG does more or less the same thing, but fixes malleability
> issues and lifts the single output
On Mon, May 27, 2019 at 3:21 AM Anthony Towns wrote:
> On Wed, May 22, 2019 at 05:01:21PM -0400, Russell O'Connor via bitcoin-dev
> wrote:
> > Bitcoin Script appears designed to be a flexible programmable system that
> > provides generic features to be composed to achiev
Allowing multiple inputs is certainly better than the 1 restriction COSHV.
However, I agree on your preference for a RISC+CISC approach. Which is why
instead of COSHV or CHECK_TXID_TEMPLACE_DATA we should do the more RISC-y
thing and begin adding transaction reflection primitives, starting with
In order of escalating scope of amendments to OP_COSHV, I suggest
1) Peeking at surrounding data surrounding data should definitely be
replaced by a pushdata-like op-code that uses the subsequent 32-bytes
directly. The OP_SUCCESSx upgrade path specifically allows for this, and
avoids
On Wed, May 22, 2019 at 5:01 PM Russell O'Connor
wrote:
> In concert, these two operations enable:
>
> * Oracle signature verification, including discrete log contracts.
>
Jonas informs me that I've misunderstood how discreet log contracts work.
The DLC signatures are not directly checked by
1 - 100 of 206 matches
Mail list logo
