I have created three additional BIPs that are associated with my recent
proposals. They can be found here:
https://github.com/cgilliard/bips/blob/notification/bip-.mediawiki
and here:
https://github.com/cgilliard/bips/blob/moderation/bip-.mediawiki
and here:
https://github.com/cgilliar
einvented Namecoin ;)
>
> On 2021-04-21 20:28, Christopher Gilliard via bitcoin-dev wrote:
> > I have created an additional BIP that is associated with the recent
> > BIPs that I have sent to the mailing list. This one defines a
> > decentralized naming protocol. The BIP can be f
I have created an additional BIP that is associated with the recent BIPs
that I have sent to the mailing list. This one defines a decentralized
naming protocol. The BIP can be found here:
https://github.com/cgilliard/bips/blob/naming/bip-.mediawiki
Please reply with any feedback, questions, or
Thanks Prayank. I think the next step for both of these proposals is to
define an API. I thought about including that in the BIPs and decided it
wasn't necessary yet to get the ideas across initially. Maybe when the APIs
are defined they could go into the BIP, but it's probably better to have in
a
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 th
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-.mediawiki
2.) notarization:
https://github.com/cgilliard/bips/blob/notarization-l2/bip-.m
, Apr 17, 2021 at 3:50 PM Peter Todd wrote:
> On Sat, Apr 17, 2021 at 03:57:55AM +, 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 o
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 peopl
s 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 c
ssumptions 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,
ds.
> --
> @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@lists.linuxfoundation.org> wrote:
>
>> I have created a BIP which can be found h
tions, 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.
&
, 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@lists.linuxfoundation.org> wrote:
>
>> I have created a BIP which can be
I have created a BIP which can be found here:
https://github.com/cgilliard/bips/blob/notarization/bip-.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
__
#x27;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, Christ
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 é
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 propos
17 matches
Mail list logo
