Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

Good morning Andrew, Looking over the text... > # I am looking towards integrating memory hard compatibility w/ the mining > algorithm. Memory hard computation allows for time and space complexity for > data storage functionality, and there is a way this can likely be implemented > without

Re: [bitcoin-dev] Provisions (was: PSA: Taproot loss of quantum protections)

Good morning Andrew and Andrea, Further afield: https://en.bitcoin.it/wiki/Taproot_Uses Taproot ring signatures was also asked by Andrea, above page contains this link (have not actually read it myself): https://github.com/jonasnick/taproot-ringsig Regards, ZmnSCPxj

Re: [bitcoin-dev] Taproot NACK

> It's incredible how this troll keeps trolling and the list (bitcoin-dev !!) > keeping attention > > Good troll, really Depending on topic raised, it may be useful to at least answer the troll naively as if it were an honest question, if only so that third parties reading do not get

Re: [bitcoin-dev] Taproot NACK

Good morning JAMES, > Good Afternoon, > > Verifiable and independantly verifiable are not the same. Independantly > scrutinable means any public can scrutinise blockchain to determine it > is honest. It does not rely on involved parties but insistently on the > data published in the blockchain.

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

I enjoyed the reindexing using a distinct subject and I appreciate the new clarifications by those whose instinct was to put effort into a response. Although I try to keep up, some of the taproot QC mitigations that are possible had escaped my attention thus far.

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

Any proposed hard fork will wind up being some sort of Bitcoin sv thing no matter what you propose or no matter how awesome it is they'll be many people in the community who would prefer to continue business as usual. which I'd like to point out seems to be working very, very well. so you should

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

In regards to my BIP proposal, I finally added a bit more details to the draft. So far an interesting discussion to say the least. Best regards, Andrew On Tue, Mar 16, 2021, 9:23 AM Thomas Hartman via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > MY LORD HIS EXCELLENCY: > > It

Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC

On Mon, Mar 15, 2021 at 05:20:04PM +, Luke Dashjr via bitcoin-dev wrote: > At the previous meeting, there was consensus for BIP8 activation parameters > except for LOT, assuming a release around this time. Since then, a release > has not occurred, and the new idea of Speedy Trial has been

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

On 3/15/21 23:44, Luke Dashjr wrote: (To reiterate: I do not intend any of this as a NACK of Taproot.) Frankly, then why parrot arguments you don't agree with in an already-tense discussion? I'm really not sure what there is to gain by dredging up years-old since-settled debates except to

Re: [bitcoin-dev] Provisions (was: PSA: Taproot loss of quantum protections)

On Tue, Mar 16, 2021 at 03:10:21PM +0100, Andrea via bitcoin-dev wrote: > > Hi! Sorry for the OT, could you provide some references to ring signatures > over/for/via taproot (I mean the schema or something like that)? And what is > "Provisions" (the capital letter makes me think it's a

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

Il 16/03/21 00:12, Andrew Poelstra via bitcoin-dev ha scritto: Having exposed keys also lets you do ring signatures over outputs, creating the ability to do private proof of funds via Provisions. Hi! Sorry for the OT, could you provide some references to ring signatures over/for/via

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

On Tue, Mar 16, 2021 at 03:44:25AM +, Luke Dashjr wrote: > (To reiterate: I do not intend any of this as a NACK of Taproot.) > Thanks, although it's still somewhat frustrating to be rehashing this discussion again after so many years. > On Monday 15 March 2021 23:12:18 Andrew Poelstra

Re: [bitcoin-dev] Taproot NACK

Good Afternoon, Verifiable and independantly verifiable are not the same. Independantly scrutinable means any public can scrutinise blockchain to determine it is honest. It does not rely on involved parties but insistently on the data published in the blockchain. The accepted case of P2SH is also

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

Hi, just to clarify this isn't a trade-off on security. Infact, my proposal actually increases the level of security that Bitcoin currently has. There is both an efficiency and cryptography aspect to this proposal. I talked about the higher levels of security a bit in my BIP, and have talked to a

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

Actually disregard my last email, I realize you were replying to somebody else instead of me. Please for proposals not related to my BIP, such as a form of "luck chance lottery", post in a different discussion thread as to not draw confusion. Best regards, Andrew On Sun, Mar 14, 2021, 10:51 PM

Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

MY LORD HIS EXCELLENCY: It is indeed a contest between free markets and central planning. Governments can in effect say, you are permitted to buy energy to smelt aluminum, but not to mine bitcoin, even if bitcoin is more profitable. To the extent that free markets in energy are

Re: [bitcoin-dev] Signature and Script Independent Hierarchy for Deterministic Wallets.

No, wallets don't and shouldn't have to check all script types on recovery. Descriptor Wallets solve all of this. To back up a multisignature wallet, each cosigner stores their xprv (how you do this; BIP39, WIF, etc, is out of scope). and the wallet descriptor. This is done, for example, in

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

I agree with Matt. The naked pubkey is required for some of the benefits being implemented (snicker coinjoins). Even with pubkey hashes, bitcoin could still be stolen because the pubkey is published on spend. Regardless, QC needs to be fixed later on (decades), and shouldn't be a reason to

Re: [bitcoin-dev] Signature and Script Independent Hierarchy for Deterministic Wallets.

See some replies inline. (quoted text from BIP draft) > Date: Sun, 14 Mar 2021 01:51:15 + > From: Robert Spigler > Subject: [bitcoin-dev] Signature and Script Independent Hierarchy for > Deterministic Wallets. > There are many issues with the current standards. As background, BIP 44/49/84

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

> I don't think we should have a followup deployment start so close to to timeout of ST. I think it would be better to schedule the followup around ST, especially since the details around that are fuzzier and dependent on the results of ST itself. Until Core pull request(s) are merged I don't

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

On Tue, 16 Mar 2021 at 09:05, Matt Corallo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > There have been many threads on this before, I'm not sure anything new has > been brought up here. > > Matt > > On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote: > > I do not personally

Re: [bitcoin-dev] Taproot NACK

It's incredible how this troll keeps trolling and the list (bitcoin-dev !!) keeping attention Good troll, really Le 14/03/2021 à 11:13, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev a écrit : > Good Afternoon, > > Since this is on the list I will open without my thank-you. You will > kindly

Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required

Good morning Jeremy, Thank you. Assuming only keys, an easier way of delegating would be simply to give a copy of the privkey outright to the delegatee. However, an advantage of this technique you described is that the delegator can impose additional restrictions that are programmable via any

Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required

inline responses -- @JeremyRubin On Mon, Mar 15, 2021 at 11:10 PM ZmnSCPxj wrote: > Good morning Jeremy, > > This is a very cool idea! > > > Multiple Delegates: By signing a txn with several delegate outputs, it > is possible

Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required

Good morning Jeremy, This is a very cool idea! > Multiple Delegates: By signing a txn with several delegate outputs, it is > possible to enforce multiple disparate conditions. Normally this is > superfluous -- why not just concatenate S1 and S2? The answer is that you may > have S1 require a