Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

On Fri, 16 Apr 2021 at 13:47, ZmnSCPxj wrote: > Good morning LL, > > > On Tue, 16 Mar 2021 at 11:25, David A. Harding via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > I curious about whether anyone informed about ECC and QC > > > knows how to create output scripts with

[bitcoin-dev] BIP - limiting OP_RETURN / HF

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 __

[bitcoin-dev] Update on Taproot activation releases

I discussed in the last Taproot activation meeting notes the plans for an alternative release to Bitcoin Core with the Speedy Trial activation mechanism (BIP 8, consistent use of block height) followed by a BIP 8(1 year, LOT=true). This has now been released (version 0.1) under the name "Bitcoin Co

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

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-s

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

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 coor

Re: [bitcoin-dev] Designing Bitcoin Smart Contracts with Sapio (available on Mainnet today)

Good morning Jeremy, et al., > Bitcoin Developers, > > I'm very excited to introduce Sapio[0] formally to you all. This seems quite interesting to me as well! I broadly agree with the rant on monetary units. In C-Lightning we always (except for some legacy fields that will eventually be remove

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

>>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. I

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

>> 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

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

On Fri, Apr 16, 2021 at 03:34:33PM +, Christopher Gilliard via bitcoin-dev wrote: > This sounds like a good justification to remove the legacy multi-signature > capabilities as well. > Doing so would confiscate coins, and also it is impossible to remove legacy multisignatures in general witho

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

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

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

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 wrote: > NACK -- I

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

For every workaround, someone may have a long lost stash that you'd be confiscating :) https://bitcoin.stackexchange.com/questions/90127/why-does-this-coinbase-transaction-have-two-op-return-outputs ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfou

Re: [bitcoin-dev] Designing Bitcoin Smart Contracts with Sapio (available on Mainnet today)

Hi ZmnSCPxj, Funny you mention BlueSpec -- I actually took 6.175[1] in my undergraduate studies with Arvind, BlueSpec's creator, and have often cited it as an inspiration for Sapio given that the target of program compilation is essentially a transaction circuit and I have a decent amount of exper

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

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 suggest

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

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 plea

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

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 fir

[bitcoin-dev] Gradual transition to an alternate proof without a hard fork.

Not sure of the best place to workshop ideas, so please take this with a grain of salt. Starting with 3 assumptions: - assume that there exists a proof-of-burn that, for Bitcoin's purposes, accurately-enough models the investment in and development of ASICs to maintain miner incentive. - assume t

Re: [bitcoin-dev] Gradual transition to an alternate proof without a hard fork.

I think you need to hard deprecate the PoW for this to work, otherwise all old miners are like "toxic waste". Imagine one miner turns on a S9 and then ramps up difficulty for everyone else. On Fri, Apr 16, 2021, 2:08 PM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote:

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

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 wrote: > Hi Chris, > > I agree with all the points that were made by others. You should also be > aware that layer two idea

Re: [bitcoin-dev] Gradual transition to an alternate proof without a hard fork.

> I think you need to hard deprecate the PoW for this to work, otherwise all > old miners are like "toxic waste". what would be the incentive? a POB would be required on every block (and would be lost if not used). so any miner doing this would just be doing "extra work" and strictly losing m

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

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 (pubke