Christopher Gilliard [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-02-17 to 2021-04-24
💬 Posted a total of 17 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-08 00:51:58

- reply

📅 Original date posted:2021-04-20
📝 Original message:I have created two additional BIPs that are associated with the BIP that I
sent to the mailing list last week. They can be found here:
1.) storage:
https://github.com/cgilliard/bips/blob/storage/bip-XXXX.mediawiki
2.) notarization:
https://github.com/cgilliard/bips/blob/notarization-l2/bip-XXXX.mediawiki
Let me know if there is any feedback or comments.
Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210420/345369fd/attachment-0001.html>

2023-06-08 00:51:49

- reply

📅 Original date posted:2021-04-20
📝 Original message:Zach,
Thanks for the comments. I just sent out another email to the dev alias
with the other two BIPs that I mentioned last week. It is pending approval
now. I think it will talk about some of the things you mentioned. To avoid
having a lot of comments about those BIPs on this thread, let's use the new
thread for discussing those BIPs.
--Chris
On Tue, Apr 20, 2021 at 1:45 AM Zach Greenwood <zachgrw at gmail.com> wrote:
> [Note: this is my first post to the list]
>
> Businesses storing data on-chain is undesirable but sadly unavoidable.
> Therefore one might as well *facilitate* data storage beyond just OP_RETURN
> by offering a more efficient way to store data on-chain, while still being
> almost as expensive in use per byte of payload (i.e., data) compared to
> using OP_RETURN.
>
> Storing data using OP_RETURN is still inefficient per byte of payload so a
> more efficient dedicated data storing facility might be created that stores
> more payload data per on-chain byte. Such a facility should be (marginally)
> cheaper to use per payload byte compared to using a hack such as OP_RETURN.
> This would encourage the use of this facility in favor of OP_RETURN or
> other hacks, while at the same time dramatically reducing the footprint of
> storing data on-chain.
>
> Zac
>
> On Tue, Apr 20, 2021 at 4:29 AM yanmaani--- via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> > If only one hash is allowed per block, then those who wish to utilize
>> > the hash will have to out-bid each other ("fee-bidding"). This hash can
>> > then be used to create another chain ("merged-mining")
>>
>> Merged mining at present only needs one hash for a merkle root, and
>> that's stored in the coinbase. It would be even simpler to add the
>> following rules:
>>
>> 1) No OP_RETURN transactions allowed at all
>> 2) If you want to commit data, do so in that one transaction in the
>> coinbase
>>
>> Also curious about how you'd handle the payment - do I need to put in a
>> transaction that burns bitcoins for the tx fee? That isn't free in terms
>> of storage either.
>> _______________________________________________
>> 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/20210420/4995536f/attachment-0001.html>

2023-06-08 00:51:48

- reply

📅 Original date posted:2021-04-16
📝 Original message:Thanks for the feedback. I will take at the links and the video and see if
there's anything that I can incorporate to the BIPs.
On Fri, Apr 16, 2021 at 8:30 PM Ruben Somsen <rsomsen at gmail.com> wrote:
> Hi Chris,
>
> I agree with all the points that were made by others. You should also be
> aware that layer two ideas like yours have already been explored, both by
> myself and others. Allowing one hash per block allows for what I call
> "fee-bidding Blind Merged-Mining" (BMM), which as far as I know was first
> proposed by Paul Storc for Drivechains.[0]
>
> If only one hash is allowed per block, then those who wish to utilize the
> hash will have to out-bid each other ("fee-bidding"). This hash can then be
> used to create another chain ("merged-mining"), while the Bitcoin miners do
> not have to be aware of this other chain ("blind"). There are also non
> fee-bidding variants that function e.g. by burning or locking up bitcoins
> in order to create consensus.
>
> As it turns out, fee-bidding BMM can be achieved using only a covenant
> structure for transactions.[1] You'd have to create a sequence of
> transactions (one per block), to which a hash can be attached. These can
> simply be pre-signed transactions (requires forgetting a key, but the worst
> that can happen is that the chain halts), or an actual covenant using
> either sighash_anyprevout or op_ctv (we don't have these yet) – no
> specialized soft fork (or hard fork) is required.
>
> You might think any decentralized alternative chain requires an altcoin,
> but this can also be avoided with a perpetual one-way peg.[2] For more
> details, I recommend watching this video of the full concept, which I call
> "spacechains": https://youtu.be/N2ow4Q34Jeg
>
> -- Ruben Somsen
>
>
>
> [0] Blind Merged-Mining for Drivechains:
> https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki
>
> [1] Fee-bidding Blind Merged-Mining with covenants:
> https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5
>
> [2] Perpetual one-way peg:
> https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302
>
> On Fri, Apr 16, 2021 at 9:33 PM Kostas Karasavvas via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi Christopher,
>>
>> Some feedback:
>>
>> "OP_RETURN is limited to 40 bytes of data."
>> It is 80 bytes.
>>
>> "A future BIP proposing such a layer two protocol will be forthcoming."
>> So what is this BIP about? Just saying that it would be a nice idea? This
>> BIP should be the one that would go through this L2 suggestion. If one root
>> OP_RETURN substitutes all the rest it should say how that would be done...
>> where would the merkle proofs be stored, what are the trust
>> assumptions that we need to make, etc.
>>
>> "Objections to this proposal" section
>> I agree with others re hard-fork, which would be a good thing of course.
>> My main objection with this proposal is that I don't see a proposal. It
>> seems like wishful thinking... if only we could substitute all the
>> OP_RETURNs with one :-)
>>
>> We have to make sure that a proposal like this (L2, etc.) would make sure
>> that there are incentives that justify the added complexity for the users.
>> Multisig is not the only way data could be stored the wrong way; P2PK,
>> P2PKH, P2SH, P2WPKH, P2WSH can also be used. If the incentives are not good
>> enough people would start using these UTXO-bloat-heavy alternatives.
>>
>> There are a multitude of L2's (kind-of) that do this 'aggregation' of
>> data hashes using merkle trees. Factom is adding a single merkle root per
>> bitcoin block for the millions upon millions of records (of thousand of
>> users) that they keep in their network. Opentimestamps, tierion,
>> blockstacks and others do a similar thing. I have investigated several of
>> those in the past, for one of my projects, but I ended up using plain old
>> OP_RETURN because the overhead of their (L2-like) solution and trust
>> assumptions where not to my liking; at least for my use case. They were
>> pretty solid/useful for other use cases.
>>
>> Unless the proposed L2 is flexible/generic enough it would really
>> prohibit this L2 innovation that OP_RETURN allowed (see above).
>>
>>
>>
>> On Fri, Apr 16, 2021 at 4:32 PM Christopher Gilliard via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> I have created a BIP which can be found here:
>>> https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki
>>>
>>> I'm sending this email to start the discussion regarding this proposal.
>>> If there are any comments/suggestions, please let me know.
>>>
>>> Regards,
>>> Chris
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> --
>> Konstantinos A. Karasavvas
>> Software Architect, Blockchain Engineer, Researcher, Educator
>> https://twitter.com/kkarasavvas
>> _______________________________________________
>> 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/20210416/ea140bb4/attachment-0001.html>

2023-06-08 00:51:46

- reply

📅 Original date posted:2021-04-16
📝 Original message:Thanks for the feedback. Will update the 40 bytes to 80 bytes (40 bytes was
the previous value, but it has since been updated to 80 so that's correct).
Regarding the L2 proposal. I think the BIPs I am working on will address
your questions and I'm hoping to have two more out early next week so
please stay tuned. I'm open to merging those BIPs into this BIP or
vice-versa, but for the sake of making things more readable I broke them
down into several BIPs for the time being.
On Fri, Apr 16, 2021 at 7:15 PM Kostas Karasavvas <kkarasavvas at gmail.com>
wrote:
> Hi Christopher,
>
> Some feedback:
>
> "OP_RETURN is limited to 40 bytes of data."
> It is 80 bytes.
>
> "A future BIP proposing such a layer two protocol will be forthcoming."
> So what is this BIP about? Just saying that it would be a nice idea? This
> BIP should be the one that would go through this L2 suggestion. If one root
> OP_RETURN substitutes all the rest it should say how that would be done...
> where would the merkle proofs be stored, what are the trust
> assumptions that we need to make, etc.
>
> "Objections to this proposal" section
> I agree with others re hard-fork, which would be a good thing of course.
> My main objection with this proposal is that I don't see a proposal. It
> seems like wishful thinking... if only we could substitute all the
> OP_RETURNs with one :-)
>
> We have to make sure that a proposal like this (L2, etc.) would make sure
> that there are incentives that justify the added complexity for the users.
> Multisig is not the only way data could be stored the wrong way; P2PK,
> P2PKH, P2SH, P2WPKH, P2WSH can also be used. If the incentives are not good
> enough people would start using these UTXO-bloat-heavy alternatives.
>
> There are a multitude of L2's (kind-of) that do this 'aggregation' of data
> hashes using merkle trees. Factom is adding a single merkle root per
> bitcoin block for the millions upon millions of records (of thousand of
> users) that they keep in their network. Opentimestamps, tierion,
> blockstacks and others do a similar thing. I have investigated several of
> those in the past, for one of my projects, but I ended up using plain old
> OP_RETURN because the overhead of their (L2-like) solution and trust
> assumptions where not to my liking; at least for my use case. They were
> pretty solid/useful for other use cases.
>
> Unless the proposed L2 is flexible/generic enough it would really prohibit
> this L2 innovation that OP_RETURN allowed (see above).
>
>
>
> On Fri, Apr 16, 2021 at 4:32 PM Christopher Gilliard via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I have created a BIP which can be found here:
>> https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki
>>
>> I'm sending this email to start the discussion regarding this proposal.
>> If there are any comments/suggestions, please let me know.
>>
>> Regards,
>> Chris
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> --
> Konstantinos A. Karasavvas
> Software Architect, Blockchain Engineer, Researcher, Educator
> https://twitter.com/kkarasavvas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210416/33566e5b/attachment-0001.html>

2023-06-08 00:51:45

- reply

📅 Original date posted:2021-04-16
📝 Original message:>>Maybe I missed something, but why does this change require a hard fork?
I guess you are right that it doesn't technically require a hard fork, but
I see this proposal as more likely being merged with other hard fork or
soft fork features. It depends on which upgrades are happening at the time.
If there's a specific soft fork being proposed to merge this proposal with,
I can update it.
>> I'm also concerned about the coordination required to get into The One
OP_RETURN Per Block, as this certainly requires some measure of
centralization of that Merkle Tree construction.
This will be discussed further in a future BIP, but the basic idea is that
each miner can run an additional piece of software that builds the tree
structure. It's much like submitting a transaction to the network today, if
one of the miners does not accept it, another likely will.
>> Some of those OP_RETURN outputs have non-zero value. As such, those
outputs are provably unspendable, and they are essentially paying the rest
of the coin holders via supply deflation.
Good point, there are other ways to do proof of burn.
>> Finally, Bitcoin nodes may safely discard OP_RETURN outputs at any time,
since they are unspendable. Thus, nodes can clear a few GB of disk space
whenever they need it, but that data is less than 1% of the total chain
size at the time of writing.
Yes, but that doesn't affect IBD.
On Fri, Apr 16, 2021 at 1:59 PM Clark Moody <clark at clarkmoody.com> wrote:
> Maybe I missed something, but why does this change require a hard fork?
>
> You don't seem to provide any data as part of your rationale, so I'll
> provide some context. As it stands, the chain size sits around 386 GB, with
> OP_RETURN data accounting for 2.5 GB of that.
>
> I'm also concerned about the coordination required to get into The One
> OP_RETURN Per Block, as this certainly requires some measure of
> centralization of that Merkle Tree construction.
>
> Some of those OP_RETURN outputs have non-zero value. As such, those
> outputs are provably unspendable, and they are essentially paying the rest
> of the coin holders via supply deflation.
>
> Finally, Bitcoin nodes may safely discard OP_RETURN outputs at any time,
> since they are unspendable. Thus, nodes can clear a few GB of disk space
> whenever they need it, but that data is less than 1% of the total chain
> size at the time of writing.
>
>
> -Clark
>
>
> On Fri, Apr 16, 2021 at 8:32 AM Christopher Gilliard via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I have created a BIP which can be found here:
>> https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki
>>
>> I'm sending this email to start the discussion regarding this proposal.
>> If there are any comments/suggestions, please let me know.
>>
>> Regards,
>> Chris
>> _______________________________________________
>> 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/20210416/0bb514ec/attachment-0001.html>

2023-06-08 00:51:45

- reply

📅 Original date posted:2021-04-16
📝 Original message:Hah! Very funny! 😁 I am certain that this proposal can be implemented in a
way that doesn't confiscate your "long lost" stash and I may even be
willing to fund a bounty for a deep sea diving expedition to find those
keys for a unit test.
On Fri, Apr 16, 2021 at 4:32 PM Jeremy <jlrubin at mit.edu> wrote:
> NACK -- I happen to have a vault where I made emergency backup pre-signed
> transactions containing two OP_RETURN outputs and have subsequently lost
> the private key in an unfortunate boating incident.
>
> This proposed rule change would serve to confiscate my funds.
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Fri, Apr 16, 2021 at 6:32 AM Christopher Gilliard via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I have created a BIP which can be found here:
>> https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki
>>
>> I'm sending this email to start the discussion regarding this proposal.
>> If there are any comments/suggestions, please let me know.
>>
>> Regards,
>> Chris
>> _______________________________________________
>> 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/20210416/2a3f793d/attachment-0001.html>

2023-06-08 00:51:44

- reply

📅 Original date posted:2021-04-17
📝 Original message:Peter, thanks for the links. I'm aware that there are other timestamping
aggregation services that already exist, but I had some different ideas
that integrate into some other services. Also thanks for sending the link
to the single use seal asset transfer. I will take a look at that.
On Sat, Apr 17, 2021 at 3:50 PM Peter Todd <pete at petertodd.org> wrote:
> On Sat, Apr 17, 2021 at 03:57:55AM +0000, Christopher Gilliard via
> bitcoin-dev wrote:
> > Thanks ZmnSCPxj. Yes, I agree there are many ways to embed arbitrary data
> > in the blockchain and it's not feasible to block all of them. That is why
> > it's important to, at the same time as limiting the OP_RETURN to one per
> > block, also propose and implement a layer 2 solution for timestamping
> > so people have a clear and simple upgrade path. That is what I will be
> > discussing in one of the BIPs I intend to release early next week.
>
> Note that an aggregated timestamping service already exists:
>
> https://petertodd.org/2016/opentimestamps-announcement
>
> But timestamping is useless for most things people want to do, as it can't
> commit to a unique history. It merely proves something existed in the
> past. For
> uniqueness, you need something like:
>
> https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
>
>
> Anyway, at current fees being what they are there's no compelling reason
> to try
> to prevent people from embedding data in the Bitcoin block chain with
> consensus
> changes. Economics is preventing that just fine.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210417/618da7c6/attachment.html>

2023-06-08 00:51:43

- reply

📅 Original date posted:2021-04-17
📝 Original message:Thanks ZmnSCPxj. Yes, I agree there are many ways to embed arbitrary data
in the blockchain and it's not feasible to block all of them. That is why
it's important to, at the same time as limiting the OP_RETURN to one per
block, also propose and implement a layer 2 solution for timestamping
so people have a clear and simple upgrade path. That is what I will be
discussing in one of the BIPs I intend to release early next week.
On Fri, Apr 16, 2021 at 11:52 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Christopher,
>
> > >> 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
> multi-signature scriptpubkeys (pubkeys can be generated without knowing the
> private key in order to encode non-key related data). Not only can users
> do this, users have done this in the past. However, this behaviour is
> problematic because such multi-signature "data" scriptpubkeys are
> indistinguishable from "real" multisignature scriptpubkeys, and thus must
> be kept in the UTXO set. This differs from outputs using OP_RETURN which
> are provably unspendable, and therefore can be safely omitted from the UTXO
> set.
> >
> > This sounds like a good justification to remove the legacy
> multi-signature capabilities as well.
>
> The same technique can be used on P2PKH as well --- the "pubkey hash" need
> not be a hash of a public key, it can be a 20-byte commitment, or even an
> ASCII message like "ZmnSCPxj is the best" (20 characters, I counted).
> There is nothing that *can* check if the hash of a public key is indeed
> the hash of a public key unless you actually reveal the public key.
>
> If you need a 32-byte commitment, a P2WSH would work --- again the "script
> hash" need not be a hash of a script, it can be any 32-byte commitment.
>
> In all these cases you have to waste 547 satoshi, but that tends to be
> small compared to tx fees currently.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210417/3299b183/attachment-0001.html>

2023-06-08 00:51:43

- reply

📅 Original date posted:2021-04-16
📝 Original message:>> 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
multi-signature scriptpubkeys (pubkeys can be generated without knowing the
private key in order to encode non-key related data). Not only can users
do this, users have done this in the past. However, this behaviour is
problematic because such multi-signature "data" scriptpubkeys are
indistinguishable from "real" multisignature scriptpubkeys, and thus must
be kept in the UTXO set. This differs from outputs using OP_RETURN which
are provably unspendable, and therefore can be safely omitted from the UTXO
set.
This sounds like a good justification to remove the legacy multi-signature
capabilities as well.
>> Thus, given that it is otherwise impossible to stop people from putting
arbitrary data values into their transactions, then we rather encourage
people who are going to encode their arbitrary data in transaction to use
the OP_RETURN outputs in order to avoid UTXO bloat.
You can't make it completely impossible to do that, but you can make it
harder and at the same time you can provide a solution for doing what they
want to do.
On Fri, Apr 16, 2021 at 1:56 PM Russell O'Connor <roconnor at blockstream.com>
wrote:
> 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
> multi-signature scriptpubkeys (pubkeys can be generated without knowing the
> private key in order to encode non-key related data). Not only can users
> do this, users have done this in the past. However, this behaviour is
> problematic because such multi-signature "data" scriptpubkeys are
> indistinguishable from "real" multisignature scriptpubkeys, and thus must
> be kept in the UTXO set. This differs from outputs using OP_RETURN which
> are provably unspendable, and therefore can be safely omitted from the UTXO
> set.
>
> Thus, given that it is otherwise impossible to stop people from putting
> arbitrary data values into their transactions, then we rather encourage
> people who are going to encode their arbitrary data in transaction to use
> the OP_RETURN outputs in order to avoid UTXO bloat.
>
> Also, as it stands, fees already nudge various participants to consolidate
> their data in the way that you suggest they do.
>
> On Fri, Apr 16, 2021 at 9:32 AM Christopher Gilliard via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I have created a BIP which can be found here:
>> https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki
>>
>> I'm sending this email to start the discussion regarding this proposal.
>> If there are any comments/suggestions, please let me know.
>>
>> Regards,
>> Chris
>> _______________________________________________
>> 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/20210416/ac1b035a/attachment.html>

2023-06-07 20:31:35

- reply

2023-06-07 20:31:34

- reply

📅 Original date posted:2021-04-16
📝 Original message:I have created a BIP which can be found here:
https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki
I'm sending this email to start the discussion regarding this proposal. If
there are any comments/suggestions, please let me know.
Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210416/deb99d49/attachment.html>

2023-06-07 20:16:30

- reply

📅 Original date posted:2019-02-18
📝 Original message:The proposal includes actual code that does verification, but I didn't
include code for signing. I thought it could be inferred, but I could at
least include a description of how to sign. I am not sure exactly what part
you are referring to by "keys speech", but the signatures are done by ECDSA
keys so it's hard to not include anything about keys even though that's not
the main topic. The "Background on ECDSA keys" section was mainly meant to
give background about what kind of keys Bitcoin uses, for people who
already know that they can easily skip this section so I would probably
think it's best just to leave in. Maybe it should be at the end as an
addendum though. Yes, I did not invent any of this, I'm just documenting
what people actually seem to do because I had to verify signatures as part
of a project I'm working on. I would have liked to have had this document
when I started the project so I thought it might be useful to others since
as far as I can tell this was not specified anywhere. The reason for
including this data in the header is the same that compressed/uncompressed
is included in the header so that you know which type of key the signature
is from and you don't have to try all options to see if any matches. This
is why Trezor did that way and why I documented it. I'm sure there are
other ways to do this, but since this is out there in the field being used
and is a reasonable solution, I thought I'd write it up.
On Mon, Feb 18, 2019 at 2:59 PM Aymeric Vitte <vitteaymeric at gmail.com>
wrote:
> Then, since you wrote this proposal, maybe you should add the very precise
> description of the signing/verification process since it is documented
> nowhere
>
> I don't get the use of the speech regarding keys while it should focus on
> signatures which are summarized in a vague sentence inspired by your ref
> [2] with a not very logical link to the next paragraph stating that r,s
> should be 32B and the whole thing 65B with a header of 1B, you did not
> invent it, that's probably the rule, not sure where it is specified again
> and for what purpose, the header seems completely of no use especially when
> you extend to segwit/bech32 since you just have to check that related
> compressed key matches
> Le 17/02/2019 à 15:14, Christopher Gilliard via bitcoin-dev a écrit :
>
> I have written up a proposed BIP. It has to do with Signature formats when
> using Bitcoin Private keys. It is here:
> https://github.com/cgilliard/BIP/blob/master/README.md
>
> This BIP was written up as suggested in this github issue:
> https://github.com/bitcoin/bitcoin/issues/10542
>
> Note that the proposal is inline with the implementation that Trezor
> implemented in the above issue.
>
> Any feedback would be appreciated. Please let me know what the steps are
> with regards to getting a BIP number assigned or any other process steps
> required.
>
> Regards,
> Chris
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
> Move your coins by yourself (browser version): https://peersm.com/wallet
> Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190218/c16867ac/attachment-0001.html>

2023-06-07 20:16:29

- reply

📅 Original date posted:2019-02-17
📝 Original message:I have written up a proposed BIP. It has to do with Signature formats when
using Bitcoin Private keys. It is here:
https://github.com/cgilliard/BIP/blob/master/README.md
This BIP was written up as suggested in this github issue:
https://github.com/bitcoin/bitcoin/issues/10542
Note that the proposal is inline with the implementation that Trezor
implemented in the above issue.
Any feedback would be appreciated. Please let me know what the steps are
with regards to getting a BIP number assigned or any other process steps
required.
Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190217/c451f5ef/attachment.html>