Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT
On 1 October 2016 at 08:02, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Saturday, October 01, 2016 4:01:04 AM Rusty Russell wrote: > > > - Otherwise of hash is compared to lower of blockhash. > > Lower in what endian? Why only that endian? Why only lower? I can see a > possible use case where one wants to look at only the high bits to ensure > their transaction is only valid in a block with at least a certain > difficulty... Why not use segwit versioning for all this stuff? That lets you re-enable the bitwise operations like OP_AND, permitting arbitrary bit-masks. Further, the "at least a certain difficulty" problem suggests a solution by extending the validity of opcodes like OP_LESSTHAN etc. to 256-bit inputs. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Multi-hash mining with Bitcoin holder voting
Further to recent posts to this list concerning mining with more than one hash function, Adam Perlow and me have a (longish) proposal/analysis on combining multi-hash with bitcoin stake voting on what the mix of hashes should be. Two novelties are: * Targeting a ratio of blocks mined under each hash function, in a similar way to difficulty targeting. * Analysis of voting on this ratio in terms of "voting on a simplex", using extant research to choose a good method of doing so. One point about mining under multiple hashes is that it offers existing miners a way back in after a contentious hard fork. Shame to waste all that hardware… Read at http://topynate.net/wp-content/uploads/2017/03/proportionateresponse.pdf (archived at http://www.webcitation.org/6pEZLlZoW) Nathan Cook ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148
The problem with >100kb transactions isn't that there are a lot of already-signed transactions out there, or even that there are good use cases for them, but that such transactions and use cases could exist, and there is no way of disallowing them without possibly costing someone a lot of money. Slowly reducing the limit doesn't really solve this problem. I propose to make them hard enough to confirm that no-one will use them without a very good reason. Just require that any block containing an outsized transaction be mined at a greater difficulty – quadratically greater. Such a block is more expensive *for the block's miner*, not just for the other miners, or for other nodes. Anyone who really, really needs to use a 400kb transaction can pay a miner to mine it. Quadratic hashing isn't risky when it is inherently limited by a corresponding reduction in the rate at which the "bad" blocks can be generated. That said, there's nothing I can see which is actually good about large, expensive to validate transactions, and so >1MB transactions should remain invalid, as they are today. Nathan Cook On 2 June 2017 at 22:40, Jared Lee Richardson via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has > quadratic hashing risks, and maybe James' 10KB is too ambitious; but even > if so, a simple 1MB tx size limit would clearly do the trick. The broader > point is that quadratic hashing is not a compelling reason to keep > blockmaxsize post-HF: does someone have a better one? > > I think this is exactly the right direction to head. There are > arguments to be made for various maximum sizes... Maybe the limit > could be set to 1mb initially, and at a distant future block > height(years?) automatically drop to 500kb or 100kb? That would give > anyone with existing systems or pre-signed transactions several years > to adjust to the change. Notification could (?possibly?) be done with > a non-default parameter that must be changed to continue to use 100kb > - <1mb transactions, so no one running modern software could claim > they were not informed when that future date hits. > > I don't see any real advantages to continuing to support transactions > larger than 100kb excepting the need to update legacy use cases / > already signed transactions. > > On Tue, May 30, 2017 at 8:07 PM, Jacob Eliosoff via bitcoin-dev >wrote: > > Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has > > quadratic hashing risks, and maybe James' 10KB is too ambitious; but > even if > > so, a simple 1MB tx size limit would clearly do the trick. The broader > > point is that quadratic hashing is not a compelling reason to keep > > blockmaxsize post-HF: does someone have a better one? > > > > > > > > On May 30, 2017 9:46 PM, "Jean-Paul Kogelman via bitcoin-dev" > > wrote: > >> > >> That would invalidate any pre-signed transactions that are currently out > >> there. You can't just change the rules out from under people. > >> > >> > >> On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev > >> wrote: > >> > >> > >>> > >>> The 1MB classic block size prevents quadratic hashing > >>> problems from being any worse than they are today. > >>> > >> > >> Add a transaction-size limit of, say, 10kb and the quadratic hashing > >> problem is a non-issue. Donezo. > >> > >> ___ > >> 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 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 mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.
You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki) if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html and the ensuing thread. Nathan Cook On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Difficulty change has profound impact on miner’s production thereby > introduce the biggest risk while considering an investment. > Commodity markets offer futures and options to hedge risks on traditional > trading venues. Some might soon list difficulty futures. > > I think we could do much better than them natively within Bitcoin. > > A better solution could be a transaction that uses nLocktime denominated > in block height, such that it is valid after the difficulty adjusted block > in the future. > A new OP_DIFFICULTY opcode would put onto stack the value of difficulty > for the block the transaction is included into. > The output script may then decide comparing that value with a strike which > key can spend it. > The input of the transaction would be a multi-sig escrow of those who > entered the bet. > The winner would broadcast. > > Once signed by both the transaction would not carry any counterparty risk > and would not need an oracle to settle according to the bet. > > I plan to draft a BIP for this as I think this opcode would serve > significant economic interest of Bitcoin economy, and is compatible with > Bitcoin’s aim not to introduce 3rd party to do so. > > Do you see a fault in this proposal or want to contribute? > > Tamas Blummer > > ___ > 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
Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.
It's true that it fetches the block hash; the idea is to compare the block hash's numeric value to the desired (uncompressed) difficulty directly, using a 256-bit version of OP_LESSTHAN. Nathan Cook On Thu, 23 May 2019 at 22:18, Tamas Blummer wrote: > That opcode would not help as it fetches block hash and not the content of > the header. > > On May 23, 2019, at 21:05, Nathan Cook wrote: > > You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke > Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki) > if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. > See > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html > and > the ensuing thread. > > Nathan Cook > > > On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Difficulty change has profound impact on miner’s production thereby >> introduce the biggest risk while considering an investment. >> Commodity markets offer futures and options to hedge risks on traditional >> trading venues. Some might soon list difficulty futures. >> >> I think we could do much better than them natively within Bitcoin. >> >> A better solution could be a transaction that uses nLocktime denominated >> in block height, such that it is valid after the difficulty adjusted block >> in the future. >> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty >> for the block the transaction is included into. >> The output script may then decide comparing that value with a strike >> which key can spend it. >> The input of the transaction would be a multi-sig escrow of those who >> entered the bet. >> The winner would broadcast. >> >> Once signed by both the transaction would not carry any counterparty risk >> and would not need an oracle to settle according to the bet. >> >> I plan to draft a BIP for this as I think this opcode would serve >> significant economic interest of Bitcoin economy, and is compatible with >> Bitcoin’s aim not to introduce 3rd party to do so. >> >> Do you see a fault in this proposal or want to contribute? >> >> Tamas Blummer >> >> ___ >> 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
Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.
You're right, I didn't remember the whole procedure. You provide the 80-byte header in the spend script, duplicate it on the stack, hash it, and compare to what OP_CHECKBLOCKATHEIGHT gives you. Then you do bit masking on the header with OP_AND to extract the difficulty. You can compare two compressed difficulties directly by using more bit masking to separate the exponent and mantissa. On Thu, 23 May 2019 at 22:54, Tamas Blummer wrote: > Block hash can suggest much higher difficulty than what is in effect, so > OP_CHECKBLOCKATHEIGHT would not work to decide if difficulty is above the > level of the bet. > > > On May 23, 2019, at 21:45, Tamas Blummer > wrote: > > > > I see. The uncompressing needs to be done either to compare. How are > chances for that BIP? > > > > This BIP would be explicitly offering risk managment of miners biggest > risk. > > Doing so without relying on external markets or oracle, self cointained > would be an impressive and adequate feature. > > > > Tamas Blummer > > > >> On May 23, 2019, at 21:21, Nathan Cook wrote: > >> > >> It's true that it fetches the block hash; the idea is to compare the > block hash's numeric value to the desired (uncompressed) difficulty > directly, using a 256-bit version of OP_LESSTHAN. > >> > >> Nathan Cook > >> > >> > >> On Thu, 23 May 2019 at 22:18, Tamas Blummer > wrote: > >> That opcode would not help as it fetches block hash and not the content > of the header. > >> > >>> On May 23, 2019, at 21:05, Nathan Cook wrote: > >>> > >>> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by > Luke Dashjr ( > https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki) if you > also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. See > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html > and the ensuing thread. > >>> > >>> Nathan Cook > >>> > >>> > >>> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >>> Difficulty change has profound impact on miner’s production thereby > introduce the biggest risk while considering an investment. > >>> Commodity markets offer futures and options to hedge risks on > traditional trading venues. Some might soon list difficulty futures. > >>> > >>> I think we could do much better than them natively within Bitcoin. > >>> > >>> A better solution could be a transaction that uses nLocktime > denominated in block height, such that it is valid after the difficulty > adjusted block in the future. > >>> A new OP_DIFFICULTY opcode would put onto stack the value of > difficulty for the block the transaction is included into. > >>> The output script may then decide comparing that value with a strike > which key can spend it. > >>> The input of the transaction would be a multi-sig escrow of those who > entered the bet. > >>> The winner would broadcast. > >>> > >>> Once signed by both the transaction would not carry any counterparty > risk and would not need an oracle to settle according to the bet. > >>> > >>> I plan to draft a BIP for this as I think this opcode would serve > significant economic interest of Bitcoin economy, and is compatible with > Bitcoin’s aim not to introduce 3rd party to do so. > >>> > >>> Do you see a fault in this proposal or want to contribute? > >>> > >>> Tamas Blummer > >>> > >>> ___ > >>> 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