Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
What if OP_TXHASH is a no op except for the purpose of emulating CTV and APO? On Wed, Jan 26, 2022 at 5:16 PM Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Russell, > > Thanks for this email, it's great to see this approach described. > > A few preliminary notes of feedback: > > 1) a Verify approach can be made to work for OP_TXHASH (even with CTV > as-is) E.g., suppose a semantic added for a single byte stack[-1] sighash > flag to read the hash at stack[-2], then the hash can be passed in instead > of put on the stack. This has the disadvantage of larger witnesses, but the > advantage of allowing undefined sighash flags to pass for any hash type. > 2) using the internal key for APO covenants is not an option because it > makes transaction construction interactive and precludes contracts with a > NUMS point taproot key. Instead, if you want similar savings, you should > advocate an OP_GENERATOR which puts G on the stack. Further, an untagged > APO variant which has split R and S values would permit something like > OP_GENERATOR OP_GENERATOR CHECKSIGAPO, which would be only 2 more > bytes than CTV. > 3) I count something like 20 different flags in your proposal. As long as > flags are under 40 bytes (and 32 assuming we want it to be easy) without > upgrading math this should be feasible to manipulate on the stack > programmatically. This is ignoring some of the more flexible additions you > mention about picking which outputs/inputs are included. However, 20 flags > means that for testing we would want comprehensive tests and understanding > for ~1 million different flag combos and the behaviors they expose. I think > this necessitates a formal model of scripting and transaction validity > properties. Are there any combinations that might be undesirable? > 4) Just hashing or not hashing isn't actually that flexible, because it > doesn't natively let you do things like (for example) TLUV. You really do > need tx operations for directly manipulating the data on the stack to > construct the hash if you want more flexible covenants. This happens to be > compatible with either a Verify or Push approach, since you either > destructure a pushed hash or build up a hash for a verify. > 5) Flexible hashing has the potential for quadratic hashing bugs. The > fields you propose seem to be within similar range to work you could cause > with a regular OP_HASH256, although you'd want to be careful with some of > the proposed extensions that you don't create risk of quadratic hashing, > which seems possible with an output selecting opcode unless you cache > properly (which might be tricky to do). Overall for the fields explicitly > mentioned, seems safe, the "possibles" seem to have some more complex > interactions. E.g., CTV with the ability to pick a subset of outputs would > be exposed to quadratic hashing. > 6) Missing field: covering the annex or some sub-range of the annex > (quadratic hashing issues on the latter) > 7) It seems simpler to, for many of these fields, push values directly (as > in OP_PUSHTXDATA from Johnson Lau) because the combo of flags to push the > hash of a single output's amount to emulate OP_AMOUNT looks 'general but > annoying'. It may make more sense to do the OP_PUSHTXDATA style opcode > instead. This also makes it simpler to think about the combinations of > flags, since it's really N independent multi-byte opcodes. > > > Ultimately if we had OP_TXHASH available "tomorrow", I would be able to > build out the use cases I care about for CTV (and more). So I don't have an > opposition on it with regards to lack of function. > > However, if one finds the TXHASH approach acceptable, then you should also > be relatively fine doing APO, CTV, CSFS, TXHASH acceptable in any order > (whenever "ready"), unless you are particularly sensitive to "technical > debt" and "soft fork processes". The only costs of doing something for CTV > or APO given an eventual TXHASH is perhaps a wasted key version or the 32 > byte argument of a NOP opcode and some code to maintain. > > Are there other costs I am missing? > > However, as it pertains to actual rollout: > > - OP_TXHASH+CSFSV doesn't seem to be the "full" set of things needed (we > still need e.g. OP_CAT, Upgraded >=64 bit Math, TLUV or OP_TWEAK > OP_TAPBRANCH OP_MANIPULATETAPTREE, and more) to full realize covenanting > power it intends to introduce. > - What sort of timeline would it take to ready something like TXHASH (and > desired friends) given greater scope of testing and analysis (standalone + > compared to CTV)? > - Is there opposition from the community to this degree of > general/recursive covenants? > - Does it make "more sense" to invest the research and development effort > that would go into proving TXHASH safe, for example, into Simplicity > instead? > > Overall, *my opinion *is that: > > - TXHASH is an acceptable theoretical approach, and I am happy to put more > thought into it and maybe draft a prototype of
[bitcoin-dev] Renaming full nodes
Much of the confusion around the Bitcoin protocol is the concept that mining nodes 'control' the network. I suggest renaming full nodes- to something like "validator node" to emphasize that full nodes check if blocks are valid. Then we could say: "Bitcoin is decentralized because anyone can run a validator node, even on a low-end laptop." ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Bitcoin is a protocol
Bitcoin is a protocol. Protocols should be: Secure; Backwards compatible; Forward compatible; and agreed by consensus For Bitcoin, these properties are particularly important. The fourth one is important not just because Bitcoin is a payment network, but because more eyes on code creates security. More eyes on code may help protocol design. Taproot is good. Sapio proposal is good. Let’s work together for constructive, positive, secure, and forward compatible upgrades to Bitcoin. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
Making Bitcoin function after 2038 is by definition a hard fork I feel if we do HF, we should bundle other HF changes with it... On Wed, Oct 13, 2021 at 5:19 PM vjudeu via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > It seems that Bitcoin Core will stop working in 2038 because of assertion > checking if the current time is non-negative. Also, the whole chain will > halt after reaching median time 0x in 2106. More information: > https://bitcointalk.org/index.php?topic=5365359.0 > > I wonder if that kind of issues are possible to fix in a soft-fork way. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Proposal: Auto-shutdown as 5-year fork window
If MTP-11 is greater than 5 years after the release date of the current software version, the full node should shut down automatically. This would allow writing code that gives the community ~5 years to upgrade to a version that executes a new hard fork while keeping everyone in consensus, provided the change is non-controversial. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Fwd: Reducing block reward via soft fork
> Well, it is done automatically every 4 years :) Bitcoin's price has always been increasing exponentially faster than the block size has been exponentially decreasing. > It is a self-balancing system - more people shout about Bitcoin being dirty -> less adoption -> lower the price -> less energy consumption. Surely we can strive for adoption and be environmentally friendly? Bitcoin currently consumes as much power as a small nation-state, giving it nation-state security. A 51% attack can reverse recent transactions. I don't think 99% of transactions need that level of security– and if we don't improve environmental-friendliness, adoption will decrease, so the price will decrease, so less mining will happen, so security will be hurt anyway. > I am all for making Bitcoin green(er), but IMHO there shall be no short-termism of the sort "Elon complained + price dropped 40% - lets go radically change things". I agree, Bitcoin shouldn't do anything just because a celebrity said something. However, this would be the ideal time to make such a change, riding off the public attitude to build social consensus around such a change. Also, this reduces inflation, good for Bitcoin hodlers ;) > IMHO if we want to make BTC cleaner we can add functionality where users can prioritise some miners over the others, with the view that users will prioritise "green" miners and they will get more TX fees, and there will be economic incentive to go green. This proposal would be great too. On Sun, May 23, 2021 at 6:42 AM Anton Ragin wrote: > Well, it is done automatically every 4 years :) It is a self-balancing > system - more people shout about Bitcoin being dirty -> less adoption -> > lower the price -> less energy consumption. Add on top the fact that in > 2024 block rewards will fall 50% anyway and someday it will be zero. > > I am all for making Bitcoin green(er), but IMHO there shall be no > short-termism of the sort "Elon complained + price dropped 40% - lets go > radically change things". > > IMHO if we want to make BTC cleaner we can add functionality where users > can prioritise some miners over the others, with the view that users will > prioritise "green" miners and they will get more TX fees, and there will be > economic incentive to go green. > > On Sun, 23 May 2021, 09:49 James Lu via bitcoin-dev, < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Background >> === >> Reducing the block reward reduces the incentive to mine. It reduces the >> maximum energy price at which mining is profitable, reducing the energy use. >> >> Bitcoins have value because they are accepted by full node users, from >> individual node operators, to exchanges and custodians like Coinbase. >> Anything else and the Bitcoins don't exist and are worthless. Like all >> currencies, Bitcoin has value because others recognize that they have value. >> >> Idea >> === >> Reduce the block reward by adding fewer coins to the UTXO set per block. >> This should be done gradually >> >> Consensus layer >> === >> This is a soft fork, because it tightens the >> >> Some Possible Weaknesses >> === >> - It will cost less than a nation-state of energy to reverse recent >> Bitcoin transactions. >> - Some miners may protest and lobby exchanges. >> - By pushing mining towards the cheapest energy sources, centralization >> increases towards Chinese miners. >> - The Bitcoin network may split if consensus is not built before flag day. >> >> However, given the current political headwinds and widespread public >> discussion around Bitcoin's energy use, it may be socially possible to >> ask individual users and major exchanges to install a version of Bitcoin >> with a reduced block reward. >> >> Alternatives >> === >> Instead of outright rejecting transactions (and the blocks that contain >> them) that attempt to spend increased block rewards, treat them as no-ops. >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Reducing block reward via soft fork
Background === Reducing the block reward reduces the incentive to mine. It reduces the maximum energy price at which mining is profitable, reducing the energy use. Bitcoins have value because they are accepted by full node users, from individual node operators, to exchanges and custodians like Coinbase. Anything else and the Bitcoins don't exist and are worthless. Like all currencies, Bitcoin has value because others recognize that they have value. Idea === Reduce the block reward by adding fewer coins to the UTXO set per block. This should be done gradually Consensus layer === This is a soft fork, because it tightens the Some Possible Weaknesses === - It will cost less than a nation-state of energy to reverse recent Bitcoin transactions. - Some miners may protest and lobby exchanges. - By pushing mining towards the cheapest energy sources, centralization increases towards Chinese miners. - The Bitcoin network may split if consensus is not built before flag day. However, given the current political headwinds and widespread public discussion around Bitcoin's energy use, it may be socially possible to ask individual users and major exchanges to install a version of Bitcoin with a reduced block reward. Alternatives === Instead of outright rejecting transactions (and the blocks that contain them) that attempt to spend increased block rewards, treat them as no-ops. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
