Zac Greenwood [ARCHIVE] / is on Nostr

Last Notes

2023-06-07 23:20:06

- reply

📅 Original date posted:2023-03-30
🗒️ Summary of this message: Bitcoin should not add functionality to support private businesses relying on on-chain storage. Such businesses contribute little fees and increase costs for node operators.
📝 Original message:Hi alicexbtc,
Under no circumstance should Bitcoin add any functionality intended to
support private businesses that rely on on-chain storage for their business
model.
Regarding “Fees paid: 150 BTC” (uh, *citation needed*):
To optimize for profitability a business would generally attempt to operate
using zero- or low-fee transactions. Therefore they tend to contribute
comparatively little fees but are depriving public use of these cheap
transactions. Worse, they exert a constant upward pressure on fee levels,
making it more expensive for everyone else to transact.
Unlike miners, node operators do not receive any compensation. They however
incur additional cost for bandwidth, electricity and processing time to not
only support some current business but all businesses in the past that ever
tried to turn a profit at their expense, so also after such business failed
and has been long gone. They foot the bill.
Lastly, I don’t believe there is any value in having for instance Ordinals
spam the blockchain with images of wojaks, bored apes and other crap but
perhaps you wish to clarify why this might be something to be “excited
about”.
Your other arguments are nonsensical so excuse me for ignoring them.
Zac
On Thu, 30 Mar 2023 at 03:57, alicexbt <alicexbt at protonmail.com> wrote:
> Hi Zac,
>
> Let me share what those parasites achieved:
>
> - Fees paid: 150 BTC
> - Lot of users and developers trying bitcoin that either never tried or
> gave up early in 2013-15
> - Mempools of nodes of being busy on weekends and got lots of transactions
> - PSBT became cool and application devs are trying their best to use it in
> different ways
> - Some developers exploring taproot and multisig
> - AJ shared things how covenants could help in fair, non-custodial,
> on-chain auction of ordinals that is MEV resistant although I had shared it
> earlier which involves more steps:
> https://twitter.com/1440000bytes/status/1634368411760476161
> - Investors exploring about funding projects
> - Bitcoin more than Bitcoin and people excited about it
>
> We can have difference of opinion, however I want bitcoin to be money and
> money means different things for people in this world. Please respect that
> else it will become like Linux, something used by 1% of world.
>
> /dev/fd0
> floppy disk guy
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Wednesday, March 29th, 2023 at 12:40 PM, Zac Greenwood via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> > I’m not sure why any effort should be spent on theorizing how new
> opcodes might be used to facilitate parasitical use cases of the blockchain.
> >
> > If anything, business models relying on the ability to abuse the
> blockchain as a data store must be made less feasible, not more.
> >
> > Zac
> >
> >
> > On Fri, 24 Mar 2023 at 20:10, Anthony Towns via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > > On Tue, Mar 07, 2023 at 10:45:34PM +1000, Anthony Towns via
> bitcoin-dev wrote:
> > > > I think there are perhaps four opcodes that are interesting in this
> class:
> > > >
> > > > idx sPK OP_FORWARD_TARGET
> > > > -- sends the value to a particular output (given by idx), and
> > > > requires that output have a particular scriptPubKey (given
> > > > by sPK).
> > > >
> > > > idx [...] n script OP_FORWARD_LEAF_UPDATE
> > > > -- sends the value to a particular output (given by idx), and
> > > > requires that output to have almost the same scriptPubKey as this
> > > > input, _except_ that the current leaf is replaced by "script",
> > > > with that script prefixed by "n" pushes (of values given by [...])
> > > >
> > > > idx OP_FORWARD_SELF
> > > > -- sends the value to a particular output (given by idx), and
> > > > requires that output to have the same scriptPubKey as this input
> > > >
> > > > amt OP_FORWARD_PARTIAL
> > > > -- modifies the next OP_FORWARD_* opcode to only affect "amt",
> > > > rather than the entire balance. opcodes after that affect the
> > > > remaining balance, after "amt" has been subtracted. if "amt" is
> > > > 0, the next OP_FORWARD_* becomes a no-op.
> > >
> > > The BIP 345 draft has been updated [0] [1] and now pretty much defines
> > > OP_VAULT to have the behaviour specced for OP_FORWARD_LEAF_UPDATE
> above,
> > > and OP_VAULT_RECOVER to behave as OP_FORWARD_TARGET above. Despite
> > > that, for this email I'm going to continue using the OP_FORWARD_*
> > > naming convention.
> > >
> > > Given the recent controversy over the Yuga labs ordinal auction [2],
> > > perhaps it's interesting to consider that these proposed opcodes come
> > > close to making it possible to do a fair, non-custodial, on-chain
> auction
> > > of ordinals [3].
> > >
> > > The idea here is that you create a utxo on chain that contains the
> ordinal
> > > in question, which commits to the address of the current leading
> bidder,
> > > and can be spent in two ways:
> > >
> > > 1) it can be updated to a new bidder, if the bid is raised by at least
> > > K satoshis, in which case the previous bidder is refunded their
> > > bid; or,
> > >
> > > 2) if there have been no new bids for a day, the current high bidder
> > > wins, and the ordinal is moved to their address, while the funds
> > > from their winning bid are sent to the original vendor's address.
> > >
> > > I believe this can be implemented in script as follows,
> > > assuming the opcodes OP_FORWARD_TARGET(OP_VAULT_RECOVER),
> > > OP_FORWARD_LEAF_UPDATE(OP_VAULT), OP_FORWARD_PARTIAL (as specced
> above),
> > > and OP_PUSHCURRENTINPUTINDEX (as implemented in liquid/elements [4])
> > > are all available.
> > >
> > > First, figure out the parameters:
> > >
> > > * Set VENDOR to the scriptPubKey corresponding to the vendor's address.
> > > * Set K to the minimum bid increment [5].
> > > * Initially, set X equal to VENDOR.
> > > * Initially, set V to just below the reserve price (V+K is the
> > > minimum initial bid).
> > >
> > > Then construct the following script:
> > >
> > > [X] [V] [SSS] TOALT TOALT TOALT
> > > 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> > > DEPTH NOT IF
> > > 0 10000 FORWARD_PARTIAL
> > > 0 FROMALT FORWARD_TARGET
> > > 1 [VENDOR] FWD_TARGET
> > > 144
> > > ELSE
> > > FROMALT SWAP TUCK FROMALT
> > > [K] ADD GREATERTHANOREQUAL VERIFY
> > > 1 SWAP FORWARD_TARGET
> > > DUP FORWARD_PARTIAL
> > > 0 ROT ROT
> > > FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE
> > > 0
> > > ENDIF
> > > CSV
> > > 1ADD
> > >
> > > where "SSS" is a pushdata of the rest of the script ("TOALT TOALT TOALT
> > > .. 1ADD").
> > >
> > > Finally, make that script the sole tapleaf, accompanied by a NUMS point
> > > as the internal public key, calculate the taproot address corresponding
> > > to that, and send the ordinal to that address as the first satoshi.
> > >
> > > There are two ways to spend that script. With an empty witness stack,
> > > the following will be executed:
> > >
> > > [X] [V] [SSS] TOALT TOALT TOALT
> > > -- altstack now contains [SSS V X]
> > > 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> > > -- this input is the first, so the ordinal will move to the first
> > > output
> > > DEPTH NOT IF
> > > -- take this branch: the auction is over!
> > > 1 [VENDOR] FWD_TARGET
> > > -- output 1 gets the entire value of this input, and pays to
> > > the vendor's hardcoded scriptPubKey
> > > 0 10000 FORWARD_PARTIAL
> > > 0 FROMALT FORWARD_TARGET
> > > -- we forward at least 10k sats to output 0 (if there were 0 sats,
> > > the ordinal would end up in output 1 instead, which would be a
> > > bug), and output 0 pays to scriptPubKey "X"
> > > 144
> > > ELSE .. ENDIF
> > > -- skip over the other branch
> > > CSV
> > > -- check that this input has baked for 144 blocks (~1 day)
> > > 1ADD
> > > -- leave 145 on the stack, which is true. success!
> > >
> > > Alternatively, if you want to increase the bid you provide a stack with
> > > two items: your scriptPubKey and the new bid [X' V']. Execution this
> > > time looks like:
> > >
> > > [X] [V] [SSS] TOALT TOALT TOALT
> > > -- stack contains [X' V'], altstack now contains [SSS V X]
> > > 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> > > -- this input is the first, so the ordinal will move to the first
> > > output
> > > DEPTH NOT IF ... ELSE
> > > -- skip over the other branch (without violating minimalif rules)
> > > FROMALT SWAP TUCK FROMALT
> > > -- stack contains [X' V' X V' V], altstack contains [SSS]
> > > [K] ADD GREATERTHANOREQUAL VERIFY
> > > -- check V' >= V+K, stack contains [X' V' X]
> > > 1 SWAP FORWARD_TARGET
> > > -- output 1 pays to X (previous bidder's scriptPubKey), and the
> > > entire value of this input goes there; stack contains [X' V']
> > > DUP FORWARD_PARTIAL
> > > -- execute "V' FORWARD_PARTIAL", stack contains [X' V']
> > > 0 ROT ROT
> > > -- stack contains [0 X' V']
> > > FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE
> > > -- execute "0 X' V' SSS 3 SSS FORWARD_LEAF_UPDATE" which checks
> > > that output 0 spends at least V' satoshis back to the same
> > > script (because that's how we defined SSS), except the first
> > > three pushes (previously X V SSS) are replaced by X' V' SSS.
> > > 0
> > > ENDIF
> > > CSV
> > > -- "0 CSV" requires nSequnce to be set, which makes the tx rbf'able,
> > > which hopefully makes it harder to pin
> > > 1ADD
> > > -- ends with 1 on the stack; success!
> > >
> > > (The "SSS n SSS FORWARD_LEAF_UPDATE" construct is more or less a quine,
> > > ie a program that outputs its own source code)
> > >
> > > I think that script is about 211 witness bytes, with an additional 40
> > > witness bytes for X'/V', so when making a bid, your tx would be
> > > something like:
> > >
> > > tx header, 10vb
> > > input 0: 103vb for the old bid including witness and control block
> > > input 1: 58vb for a taproot key path spend
> > > output 0: 43vb for the new bid
> > > output 1: 43vb for your change
> > >
> > > for a total of about 257vb -- slightly larger than a regular 2-in-2-out
> > > transaction, but not terribly much. Mostly because input 0 doesn't
> require
> > > a signature -- it's size is effectively 6 pubkeys: X, X' VENDOR twice,
> > > and the script code twice, along with a little extra to encode the
> > > various numbers (10000, 144, K, V, V').
> > >
> > > This approach seems pretty "MEV" resistant: you pay fees via input 1 if
> > > your bid succeeds; if it doesn't, you don't pay any fees. A potential
> > > scalper might want to put in an early low ball bid, then prevent
> > > higher bidders from winning the auction, take control of the ordinal,
> > > and resell it later, but unless they can prevent another miner from
> > > mining alternative bids for 144 blocks, they will fail at that. The bid
> > > is fixed by the bidder and committed to by the signature on input 1, so
> > > frontrunning a bid can't do anything beyond invalidate the bid
> entirely.
> > >
> > > Obviously, this is a pretty limited auction mechanism in various ways;
> > > eg maybe you'd rather specify K as a percentage than an absoute
> increment;
> > > maybe you'd like to have the auction definitely finish by some
> particular
> > > time; maybe you'd like to be able to have the auction be able to
> continue
> > > above 21.47 BTC (2**31 sats); maybe you'd like to do a dutch auction
> > > rather than an english auction. I think you can probably do all those
> > > things with this set of opcodes and clever scripting, though it
> probably
> > > gets ugly.
> > >
> > > I don't think this is easily extensible to taro or rgb style assets,
> > > as rather than being able to ensure the asset is transferred by
> > > controlling the input/output positions, I think you'd need to build
> > > up merkle trees and do point tweaks beyond what's supported by
> > > OP_FORWARD_LEAF_UPDATE/OP_VAULT. Of course, without something like
> > > OP_PUSHCURRENTINPUTINDEX I don't think you could do it for ordinals
> > > either.
> > >
> > > Cheers,
> > > aj
> > >
> > > [0]
> https://github.com/bitcoin/bips/blob/7f747fba82675f28c239df690a07b75529bd0960/bip-0345.mediawiki
> > >
> > > [1] https://twitter.com/jamesob/status/1639019107432513537
> > >
> > > [2]
> https://cointelegraph.com/news/scammers-dream-yuga-s-auction-model-for-bitcoin-nfts-sees-criticism
> > >
> > > [3] Inscriptions remain a wasteful way of publishing/committing
> > > to content, however!
> > >
> > > [4]
> https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md
> > >
> > > [5] Setting K too low probably invites griefing, where a bidder may be
> > > able to use rbf pinning vectors to prevent people who would be willing
> > > to bid substantially higher from getting their bid confirmed on
> > > chain.
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230330/00fa836d/attachment-0001.html>

2023-06-07 23:20:03

- reply

📅 Original date posted:2023-03-29
🗒️ Summary of this message: Efforts should not be made to facilitate parasitical use cases of the blockchain. Business models relying on blockchain abuse must be made less feasible.
📝 Original message:I’m not sure why any effort should be spent on theorizing how new opcodes
might be used to facilitate parasitical use cases of the blockchain.
If anything, business models relying on the ability to abuse the blockchain
as a data store must be made less feasible, not more.
Zac
On Fri, 24 Mar 2023 at 20:10, Anthony Towns via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tue, Mar 07, 2023 at 10:45:34PM +1000, Anthony Towns via bitcoin-dev
> wrote:
> > I think there are perhaps four opcodes that are interesting in this
> class:
> >
> > idx sPK OP_FORWARD_TARGET
> > -- sends the value to a particular output (given by idx), and
> > requires that output have a particular scriptPubKey (given
> > by sPK).
> >
> > idx [...] n script OP_FORWARD_LEAF_UPDATE
> > -- sends the value to a particular output (given by idx), and
> > requires that output to have almost the same scriptPubKey as this
> > input, _except_ that the current leaf is replaced by "script",
> > with that script prefixed by "n" pushes (of values given by [...])
> >
> > idx OP_FORWARD_SELF
> > -- sends the value to a particular output (given by idx), and
> > requires that output to have the same scriptPubKey as this input
> >
> > amt OP_FORWARD_PARTIAL
> > -- modifies the next OP_FORWARD_* opcode to only affect "amt",
> > rather than the entire balance. opcodes after that affect the
> > remaining balance, after "amt" has been subtracted. if "amt" is
> > 0, the next OP_FORWARD_* becomes a no-op.
>
> The BIP 345 draft has been updated [0] [1] and now pretty much defines
> OP_VAULT to have the behaviour specced for OP_FORWARD_LEAF_UPDATE above,
> and OP_VAULT_RECOVER to behave as OP_FORWARD_TARGET above. Despite
> that, for this email I'm going to continue using the OP_FORWARD_*
> naming convention.
>
> Given the recent controversy over the Yuga labs ordinal auction [2],
> perhaps it's interesting to consider that these proposed opcodes come
> close to making it possible to do a fair, non-custodial, on-chain auction
> of ordinals [3].
>
> The idea here is that you create a utxo on chain that contains the ordinal
> in question, which commits to the address of the current leading bidder,
> and can be spent in two ways:
>
> 1) it can be updated to a new bidder, if the bid is raised by at least
> K satoshis, in which case the previous bidder is refunded their
> bid; or,
>
> 2) if there have been no new bids for a day, the current high bidder
> wins, and the ordinal is moved to their address, while the funds
> from their winning bid are sent to the original vendor's address.
>
> I believe this can be implemented in script as follows,
> assuming the opcodes OP_FORWARD_TARGET(OP_VAULT_RECOVER),
> OP_FORWARD_LEAF_UPDATE(OP_VAULT), OP_FORWARD_PARTIAL (as specced above),
> and OP_PUSHCURRENTINPUTINDEX (as implemented in liquid/elements [4])
> are all available.
>
> First, figure out the parameters:
>
> * Set VENDOR to the scriptPubKey corresponding to the vendor's address.
> * Set K to the minimum bid increment [5].
> * Initially, set X equal to VENDOR.
> * Initially, set V to just below the reserve price (V+K is the
> minimum initial bid).
>
> Then construct the following script:
>
> [X] [V] [SSS] TOALT TOALT TOALT
> 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> DEPTH NOT IF
> 0 10000 FORWARD_PARTIAL
> 0 FROMALT FORWARD_TARGET
> 1 [VENDOR] FWD_TARGET
> 144
> ELSE
> FROMALT SWAP TUCK FROMALT
> [K] ADD GREATERTHANOREQUAL VERIFY
> 1 SWAP FORWARD_TARGET
> DUP FORWARD_PARTIAL
> 0 ROT ROT
> FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE
> 0
> ENDIF
> CSV
> 1ADD
>
> where "SSS" is a pushdata of the rest of the script ("TOALT TOALT TOALT
> .. 1ADD").
>
> Finally, make that script the sole tapleaf, accompanied by a NUMS point
> as the internal public key, calculate the taproot address corresponding
> to that, and send the ordinal to that address as the first satoshi.
>
> There are two ways to spend that script. With an empty witness stack,
> the following will be executed:
>
> [X] [V] [SSS] TOALT TOALT TOALT
> -- altstack now contains [SSS V X]
> 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> -- this input is the first, so the ordinal will move to the first
> output
> DEPTH NOT IF
> -- take this branch: the auction is over!
> 1 [VENDOR] FWD_TARGET
> -- output 1 gets the entire value of this input, and pays to
> the vendor's hardcoded scriptPubKey
> 0 10000 FORWARD_PARTIAL
> 0 FROMALT FORWARD_TARGET
> -- we forward at least 10k sats to output 0 (if there were 0 sats,
> the ordinal would end up in output 1 instead, which would be a
> bug), and output 0 pays to scriptPubKey "X"
> 144
> ELSE .. ENDIF
> -- skip over the other branch
> CSV
> -- check that this input has baked for 144 blocks (~1 day)
> 1ADD
> -- leave 145 on the stack, which is true. success!
>
> Alternatively, if you want to increase the bid you provide a stack with
> two items: your scriptPubKey and the new bid [X' V']. Execution this
> time looks like:
>
> [X] [V] [SSS] TOALT TOALT TOALT
> -- stack contains [X' V'], altstack now contains [SSS V X]
> 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> -- this input is the first, so the ordinal will move to the first
> output
> DEPTH NOT IF ... ELSE
> -- skip over the other branch (without violating minimalif rules)
> FROMALT SWAP TUCK FROMALT
> -- stack contains [X' V' X V' V], altstack contains [SSS]
> [K] ADD GREATERTHANOREQUAL VERIFY
> -- check V' >= V+K, stack contains [X' V' X]
> 1 SWAP FORWARD_TARGET
> -- output 1 pays to X (previous bidder's scriptPubKey), and the
> entire value of this input goes there; stack contains [X' V']
> DUP FORWARD_PARTIAL
> -- execute "V' FORWARD_PARTIAL", stack contains [X' V']
> 0 ROT ROT
> -- stack contains [0 X' V']
> FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE
> -- execute "0 X' V' SSS 3 SSS FORWARD_LEAF_UPDATE" which checks
> that output 0 spends at least V' satoshis back to the same
> script (because that's how we defined SSS), except the first
> three pushes (previously X V SSS) are replaced by X' V' SSS.
> 0
> ENDIF
> CSV
> -- "0 CSV" requires nSequnce to be set, which makes the tx rbf'able,
> which hopefully makes it harder to pin
> 1ADD
> -- ends with 1 on the stack; success!
>
> (The "SSS n SSS FORWARD_LEAF_UPDATE" construct is more or less a quine,
> ie a program that outputs its own source code)
>
> I think that script is about 211 witness bytes, with an additional 40
> witness bytes for X'/V', so when making a bid, your tx would be
> something like:
>
> tx header, 10vb
> input 0: 103vb for the old bid including witness and control block
> input 1: 58vb for a taproot key path spend
> output 0: 43vb for the new bid
> output 1: 43vb for your change
>
> for a total of about 257vb -- slightly larger than a regular 2-in-2-out
> transaction, but not terribly much. Mostly because input 0 doesn't require
> a signature -- it's size is effectively 6 pubkeys: X, X' VENDOR twice,
> and the script code twice, along with a little extra to encode the
> various numbers (10000, 144, K, V, V').
>
> This approach seems pretty "MEV" resistant: you pay fees via input 1 if
> your bid succeeds; if it doesn't, you don't pay any fees. A potential
> scalper might want to put in an early low ball bid, then prevent
> higher bidders from winning the auction, take control of the ordinal,
> and resell it later, but unless they can prevent another miner from
> mining alternative bids for 144 blocks, they will fail at that. The bid
> is fixed by the bidder and committed to by the signature on input 1, so
> frontrunning a bid can't do anything beyond invalidate the bid entirely.
>
> Obviously, this is a pretty limited auction mechanism in various ways;
> eg maybe you'd rather specify K as a percentage than an absoute increment;
> maybe you'd like to have the auction definitely finish by some particular
> time; maybe you'd like to be able to have the auction be able to continue
> above 21.47 BTC (2**31 sats); maybe you'd like to do a dutch auction
> rather than an english auction. I think you can probably do all those
> things with this set of opcodes and clever scripting, though it probably
> gets ugly.
>
> I don't think this is easily extensible to taro or rgb style assets,
> as rather than being able to ensure the asset is transferred by
> controlling the input/output positions, I think you'd need to build
> up merkle trees and do point tweaks beyond what's supported by
> OP_FORWARD_LEAF_UPDATE/OP_VAULT. Of course, without something like
> OP_PUSHCURRENTINPUTINDEX I don't think you could do it for ordinals
> either.
>
> Cheers,
> aj
>
> [0]
> https://github.com/bitcoin/bips/blob/7f747fba82675f28c239df690a07b75529bd0960/bip-0345.mediawiki
>
> [1] https://twitter.com/jamesob/status/1639019107432513537
>
> [2]
> https://cointelegraph.com/news/scammers-dream-yuga-s-auction-model-for-bitcoin-nfts-sees-criticism
>
> [3] Inscriptions remain a wasteful way of publishing/committing
> to content, however!
>
> [4]
> https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md
>
> [5] Setting K too low probably invites griefing, where a bidder may be
> able to use rbf pinning vectors to prevent people who would be willing
> to bid substantially higher from getting their bid confirmed on
> chain.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230329/66e43c91/attachment.html>

2023-06-07 23:11:37

- reply

📅 Original date posted:2022-07-13
📝 Original message:> your proof is incorrect (or, rather, relies on a highly unrealistic
assumption)
The assumption that coin are lost ar a constant rate is not required. Tail
emission will asymptotically decrease the rate of inflation to zero, at
which point the increase in coin exactly matches the amount of coin lost.
The rate at which coin are lost is irrelevant.
This is easy to see. Consider no coin are ever lost. The rate of inflation
will slowly decline to zero as the amount of coin grows to infinity.
However, lost coin ensures that the point at which the rate of inflation
becomes zero will be reached sooner.
If a black swan event destroys 90% of all coin, the constant tail emission
will instantly begin to inflate the supply at a 10x higher percentage. The
inflation expressed as a percentage will also immediately start to decline
because each new coin will inflate the total supply with a slightly smaller
percentage than the previous new coin. The rate of inflation will continue
to decline until zero, at which point it again matches the coin-loss
induced deflation rate.
Another scenario. Suppose that the number of coin lost becomes
significantly less for instance because better wallets and a more mature
ecosystem prevent many common coin loss events. A constant issuance of new
coin would increase the total supply, but each new coin would add less to
the total supply when expressed as a percentage. The rate of inflation
would decline to zero, at which point it again has matched the rate of
deflation due to coin loss.
Even when the rate at which coin are lost will not be constant, a tail
emission will tend to an equilibrium.
It must be observed that tail emission causes the total *potential* supply
to vary greatly depending on the deflation rate. In a low-deflation
scenario, the supply will have to grow much larger before an equilibrium
can be reached than in a scenario with moderate deflation rate. Not being
able to predict the ultimate total supply of coin is however seems
undesirable. But is it really?
The rate of inflation required for keeping Bitcoin useful highly depends on
the value of the token. At US$100k, a tail emission of 1 BTC per block
ensures safety within a few blocks for even large amounts. Continuing this
example, 1 BTC per block would mean 5.25m extra coin per 100 years. At 21m
coins and 1 BTC perpetual reward per block, the rate of inflation would be
0.25% per year.
This should put things a bit into perspective.
On Tue, 12 Jul 2022 at 01:58, Anthony Towns via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Jul 11, 2022 at 08:56:04AM -0400, Erik Aronesty via bitcoin-dev
> wrote:
> > > Alternatively, losses could be at a predictable rate that's entirely
> > > different to the one Peter assumes.
> > No, peter only assumes that there *is* a rate.
>
> No, he assumes it's a constant rate. His integration step gives a
> different result if lambda changes with t:
> https://www.wolframalpha.com/input?i=dN%2Fdt+%3D+k+-+lambda%28t%29*N
>
> On Mon, Jul 11, 2022 at 12:59:53PM -0400, Peter Todd via bitcoin-dev wrote:
> > Give me an example of an *actual* inflation rate you expect to see,
> given a
> > disaster of a given magnitude.
>
> All I was doing was saying your proof is incorrect (or, rather, relies
> on a highly unrealistic assumption), since I hadn't seen anybody else
> point that out already.
>
> But even if the proof were correct, I don't think it provides a useful
> mechanism (since there's no reason to think miners gaining all the coins
> lost in a year will be sufficient for anything), and I don't really
> think the "security budget" framework (ie, that the percentage of total
> supply given to miners each year is what's important for security)
> you're implicitly relying on is particularly meaningful.
>
> So no, not particularly interested in diving into it any deeper.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220713/37d7c521/attachment.html>

2023-06-07 23:11:17

- reply

📅 Original date posted:2022-07-09
📝 Original message:Sorting a seed alphabetically reduces entropy by ~29 bits.
A 12-word seed has (12, 12) permutations or 479 million, which is ln(469m)
/ ln(2) ~= 29 bits of entropy. Sorting removes this entropy entirely,
reducing the seed entropy from 128 to 99 bits.
Zac
On Fri, 8 Jul 2022 at 16:09, James MacWhyte via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> What do you do if the "first" word (of 12), happens to be the last word in
>> the list alphabetically?
>>
>
> That couldn't happen. If one word is the very last from the wordlist, it
> would end up at the end of your mnemonic once you rearrange your 12 words
> alphabetically.
>
> However!
>
> (@vjudeu) Choosing 11 random words and then sorting them alphabetically
> before assigning a checksum would reduce entropy considerably. If you think
> about it, to bruteforce the entire keyspace one would only need to come up
> with every possible combination of 11 words + 1 checksum. I'm not the best
> at napkin math, but I think that leaves you with around 10 trillion
> combinations, which would only take a couple months to exhaust with
> hardware that can do 1 million guesses per second.
>
>
> James
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220709/fade4b82/attachment.html>

2023-06-07 23:07:50

- reply

📅 Original date posted:2022-04-22
📝 Original message:On Fri, 22 Apr 2022 at 09:56, Keagan McClelland via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I think that trying to find ways to activate non-invasive changes should
> be everyone's goal, *even if* they personally may not have an immediate use
> case
>
A change that increases the number of use cases of Bitcoin affects all
users and is *not* non-invasive. More use cases means more blockchain usage
which increases the price of a transaction for *everyone*.
I like the maxim of Peter Todd: any change of Bitcoin must benefit *all*
users. This means that every change must have well-defined and transparent
benefits. Personally I believe that the only additions to the protocol that
would still be acceptable are those that clearly benefit layer 2 solutions
such as LN *and* do not carry the dangerous potential of getting abused by
freeloaders selling commercial services on top of “free” eternal storage on
the blockchain.
Zac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220422/0fd0ef11/attachment.html>

2023-06-07 23:02:13

- reply

📅 Original date posted:2022-01-21
📝 Original message:The name of the fund should ideally unambiguously clarify its scope, i.e.,
Bitcoin & development. So maybe “Bitcoin Developers Community LDF”. Or
perhaps “Bitcoin Technical Community LDF” which nicely abbreviates to
BTCLDF.
Zac
On Thu, 13 Jan 2022 at 19:49, jack via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Prayank,
>
> > On 13 Jan 2022, at 10:13, Prayank <prayank at tutanota.de> wrote:
> > I had few suggestions and feel free to ignore them if they do not make
> sense:
> >
> > 1.Name of this fund could be anything and 'The Bitcoin Legal Defense
> Fund' can be confusing or misleading for newbies. There is nothing official
> in Bitcoin however people believe things written in news articles and some
> of them might consider it as an official bitcoin legal fund.
>
> Excellent point. Will come up with a better name.
>
> Open to ideas and suggestions on all.
>
> jack
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220121/c16855a6/attachment.html>

2023-06-07 22:57:26

- reply

📅 Original date posted:2021-08-05
📝 Original message:Hi Billy,
> It sounds like you're proposing an opcode
No. I don’t have enough knowledge of Bitcoin to be able to tell how (and
if) rate-limiting can be implemented as I suggested. I am not able to
reason about opcodes, so I kept my description at a more functional level.
> I still don't understand why its useful to specify those as absolute
block heights
I feel that this a rather uninteresting data representation aspect that’s
not worth going back and forth about. Sure, specifying the length of the
epoch may also be an option, although at the price of giving up some
functionality, and without much if any gains.
By explicitly specifying the start and end block of an epoch, the user has
more flexibility in shifting the epoch (using alternate values for
epochStart and epochEnd) and simultaneously increasing the length of an
epoch. These seem rather exotic features, but there’s no harm in retaining
them.
> if you have a UTXO encumbered by rateLimit(epochStart = 800100, epochEnd
= 800200, limit = 100k, remain = 100k), what happens if you don't spend
that UTXO before block 800200?
The rate limit remains in place. So if this UTXO is spent in block 900000,
then at most 100k may be spent. Also, the new epoch must be at least 100
blocks and remain must correctly account for the actual amount spent.
> This is how I'd imagine creating an opcode like this:
> rateLimit(windowSize = 144 blocks, limit = 100k sats)
This would require the system to bookkeep how much was spent since the
first rate-limited output. It is a more intuitive way of rate-limiting but
it may be much more difficult to implement, which is why I went with the
epoch-based rate limiting solution. In terms of functionality, I believe
the two solutions are nearly identical for all practical purposes.
Your next section confuses me. As I understand it, using an address as
input for a transaction will always spends the full amount at that address.
That’s why change addresses are required, no? If Bitcoin were able to pay
exact amounts then there wouldn’t be any need for change outputs.
Zac
On Thu, 5 Aug 2021 at 08:39, Billy Tetrud <billy.tetrud at gmail.com> wrote:
> > A maximum amount is allowed to be spent within EVERY epoch.
>
> It sounds like you're proposing an opcode that takes in epochStart and
> epochEnd as parameters. I still don't understand why its useful to specify
> those as absolute block heights. You mentioned that this enables more
> straightforward validation logic, but I don't see how. Eg, if you have a
> UTXO encumbered by rateLimit(epochStart = 800100, epochEnd = 800200, limit
> = 100k, remain = 100k), what happens if you don't spend that UTXO before
> block 800200? Is the output no longer rate limited then? Or is the opcode
> calculating 800200-800100 = 100 and applying a rate limit for the next
> epoch? If the first, then the UTXO must be spent within one epoch to remain
> rate limited. If the second, then it seems nearly identical to simply
> specifying window=100 as a parameter instead of epochStart and epochEnd.
>
> > then there must be only a single (rate-limited) output
>
> This rule would make transactions tricky if you're sending money into
> someone else's wallet that may be rate limited. If the requirement is that
> only you yourself can send money into a rate limited wallet, then this
> point is moot but it would be ideal to not have such a requirement.
>
> This is how I'd imagine creating an opcode like this:
>
> rateLimit(windowSize = 144 blocks, limit = 100k sats)
>
> This would define that the epoch is 1 day's worth of blocks. This would
> evenly divide bitcoin's retarget period and so each window would start and
> end at those dividing lines (eg the first 144 blocks of the retargetting
> period, then the second, then the third, etc).
>
> When this output is spent, it ensures that there's a maximum of 100k sats
> is sent to addresses other than the originating address. It also records
> the amount spent in the current 144 block window for that address (eg by
> simply recording the already-spent amount on the resulting UTXO and having
> an index that allows looking up UTXOs by address and adding them up). That
> way, when any output from that address is spent again, if a new 144 block
> window has started, the limit is reset, but if its still within the same
> window, the already-spent amounts for UTXOs from that address are added up
> and subtracted from the limit, and that number is the remaining limit a
> subsequent transaction needs to adhere to.
>
> This way, 3rd party could send transactions into an address like this, and
> multiple outputs can be combined and used to spend to arbitrary outputs (up
> to the rate limit of course).
>
> On Wed, Aug 4, 2021 at 3:48 AM Zac Greenwood <zachgrw at gmail.com> wrote:
>
>> > Ah I see, this is all limited to within a single epoch.
>>
>> No, that wouldn't be useful. A maximum amount is allowed to be spent
>> within EVERY epoch.
>>
>> Consider an epoch length of 100 blocks with a spend limit of 200k per
>> epoch. The following is allowed:
>>
>> epoch1 (800101 - 800200): spend 120k in block 800140. Remaining for
>> epoch1: 80k;
>> epoch1 (800101 - 800200): spend another 60k in block 800195. Remaining
>> for epoch1: 20k;
>> epoch2 (800201 - 800300): spend 160k in block 800201. Remaining for
>> epoch2: 40k.
>>
>> Since the limit pertains to each individual epoch, it is allowed to spend
>> up to the full limit at the start of any new epoch. In this example, the
>> spending was as follows:
>>
>> 800140: 120k
>> 800195: 60k
>> 800201: 160k.
>>
>> Note that in a span of 62 blocks a total of 340k sats was spent. This may
>> seem to violate the 200k limit per 100 blocks, but this is the result of
>> using a per-epoch limit. This allows a maximum of 400k to be spent in 2
>> blocks llke so: 200k in the last block of an epoch and another 200k in the
>> first block of the next epoch. However this is inconsequential for the
>> intended goal of rate-limiting which is to enable small spends over time
>> from a large amount and to prevent theft of a large amount with a single
>> transaction.
>>
>> To explain the proposed design more clearly, I have renamed the params as
>> follows:
>>
>> epochStart: block height of first block of the current epoch (was: h0);
>> epochEnd: block height of last block of the current epoch (was: h1);
>> limit: the maximum total amount allowed to be spent within the current
>> epoch (was: a);
>> remain: the remaining amount allowed to be spent within the current epoch
>> (was: a_remaining);
>>
>> Also, to illustrate that the params are specific to a transaction, I will
>> hence precede the param with the transaction name like so:
>> tx8_limit, tx31c_remain, tx42z_epochStart, ... etc.
>>
>> For simplicity, only transactions with no more than one rate-limited
>> input are considered, and with no more than two outputs: one rate-limited
>> change output, and a normal (not rate-limited) output.
>>
>> Normally, a simple transaction generates two outputs: one for a payment
>> to a third party and one for the change address. Again for simplicity, we
>> demand that a transaction which introduces rate-limiting must have only a
>> single, rate-limited output. The validation rule might be: if a transaction
>> has rate-limiting params and none of its inputs are rate-limited, then
>> there must be only a single (rate-limited) output (and no second or change
>> output).
>>
>> Consider rate limiting transactions tx1 having one or more normal (non
>> rate-limited) inputs:
>>
>> tx1 gets included at block height 800004;
>> The inputs of tx1 are not rate-limited => tx1 must have only a single
>> output which will become rate-limited;
>> params: tx1_epochStart=800001, tx1_epochEnd=800100, tx1_limit=200k,
>> tx1_remain=200k;
>> => This defines that an epoch has 100 blocks and no more than 200k sats
>> may be spent in any one epoch. Within the current epoch, 200k sats may
>> still be spent.
>>
>> This transaction begins to rate-limit a set of inputs, so it has a single
>> rate-limited output.
>> Let's explore transactions that have the output of tx1 as their input. I
>> will denote the output of tx1 as "out1".
>>
>> tx2a has out1 as its only input;
>> tx2a spends 50k sats and gets included at block height 803050;
>> tx2a specifies the following params for its change output "chg2a":
>> chg2a_epochStart=803001, chg2a_epochEnd=803100;
>> chg2a_limit=200k, chg2a_remain=150k.
>>
>> To enforce rate-limiting, the system must validate the params of the
>> change output chg2a to ensure that overspending is not allowed.
>>
>> The above params are allowed because:
>> => 1. the epoch does not become smaller than 100 blocks [(chg2a_epochEnd
>> - chg2a_epochStart) >= (tx1_epochEnd - tx1_epochStart)]
>> => 2. tx1_limit has not been increased (ch2a_limit <= tx1_limit)
>> => 3. the amount spent (50k sats) does not exceed tx1_remain AND does not
>> exceed chg2a_limit;
>> => 4. chg2a_remain" is 50k sats less than chg2a_limit.
>>
>> A transaction may also further constrain further spending like so:
>>
>> tx2b has out1as its only input;
>> tx2b spends 8k sats and gets included at block height 808105;
>> tx2b specifies the following params for its change output "chg2b":
>> chg2b_epochStart=808101, chg2b_epochEnd=808250;
>> chg2b_limit=10k, chg2b_remain=0.
>>
>> These params are allowed because:
>> => 1. the epoch does not become smaller than100 blocks. It is fine to
>> increase the epoch to 150 blocks because it does not enable exceeding the
>> original rate-limit;
>> => 2. the limit (chg2b_limit) has been decreased to 10k sats, further
>> restricting the maximum amount allowed to be spent within the current and
>> any subsequent epochs;
>> => 3. the amount spent (10k sats) does not exceed tx1_remain AND does not
>> exceed chg2b_limit;
>> => 4. chg2b_remain has been set to zero, meaning that within the current
>> epoch (block height 808101 to and including 808250), tx2b cannot be used as
>> a spending input to any transaction.
>>
>> Starting from block height 808251, a new epoch will start and the
>> rate-limited output of tx2b may again be used as an input for a subsequent
>> rate-limited transaction tx3b. This transaction tx3b must again be
>> accompanied by params that do not violate the rate-limit as defined by the
>> params of tx2b and which are stored with output out2b. So, the epoch of
>> tx3b must be at minimum 150 blocks, the maximum that is allowed to be spent
>> per epoch is at most 10k sats, and chg3b_remain must be decreased by at
>> least the amount spent by tx3b.
>>
>> From the above, the rate-limiting mechanics should hopefully be clear and
>> full set of validation rules could be defined in a more generalized way
>> with little additional effort.
>>
>> Note that I conveniently avoided talking about how to represent the
>> parameters within transactions or outputs, simply because I currently lack
>> enough understanding to reason about this. I am hoping that others may
>> offer help.
>>
>> Zac
>>
>>
>> On Tue, Aug 3, 2021 at 8:12 PM Billy Tetrud <billy.tetrud at gmail.com>
>> wrote:
>>
>>> > To enable more straightforward validation logic.
>>> > within the current epoch
>>>
>>> Ah I see, this is all limited to within a single epoch. I think that
>>> sufficiently limits the window of time in which nodes have to store
>>> information for rate limited outputs. However, I don't see how specifying
>>> block ranges simplifies the logic - wouldn't this complicate the logic with
>>> additional user-specified constraints? It also prevents the output from
>>> being able to be rate limited over the span of multiple epochs, which would
>>> seem to make it a lot more difficult to use for certain types of wallets
>>> (eg cold wallets).
>>>
>>> I think I see the logic of your 'remaining' parameter there. If you
>>> start with a single rate-limited input, you can split that into many
>>> outputs, only one of which have a 'remaining' balance. The rest can simply
>>> remain unspendable for the rest of the epoch. That way these things don't
>>> need to be tied together. However, that doesn't solve the problem of 3rd
>>> parties being able to send money into the wallet.
>>>
>>> > I don't believe that the marginal added functionality would justify
>>> the increased implementation complexity
>>>
>>> Perhaps, but I think there is a lot of benefit in allowing these kinds
>>> of things to operate as similarly as possible to normal transactions, for
>>> one because of usability reasons. If each opcode has its own quirks that
>>> are not intuitively related to their purpose (eg if a rate-limited wallet
>>> had no way to get a receiving address), it would confuse end-users (eg who
>>> wonder how to get a receiving address and how they can ask people to send
>>> money into their wallet) or require a lot of technical complexity in
>>> applications (eg to support something like cooperatively connecting with
>>> their wallet so that a transaction can be made that creates a new
>>> single-output for the wallet). A little complexity in this opcode can save
>>> a lot of external complexity here I think.
>>>
>>> > my understanding of Bitcoin is way too low to be able to write a BIP
>>> and do the implementation
>>>
>>> You might be able to find people willing to help. I would be willing to
>>> help write the BIP spec. I'm not the right person to help with the
>>> implementation, but perhaps you could find someone else who is. Even if the
>>> BIP isn't adopted, it could be a starting point or inspiration for someone
>>> else to write an improved version.
>>>
>>> On Mon, Aug 2, 2021 at 2:32 AM Zac Greenwood <zachgrw at gmail.com> wrote:
>>>
>>>> [Note: I've moved your reply to the newly started thread]
>>>>
>>>> Hi Billy,
>>>>
>>>> Thank you for your kind and encouraging feedback.
>>>>
>>>> I don't quite understand why you'd want to define a specific span of
>>>>> blocks for the rate limit. Why not just specify the size of the window (in
>>>>> blocks) to rate limit within, and the limit?
>>>>
>>>>
>>>> To enable more straightforward validation logic.
>>>>
>>>> You mentioned change addresses, however, with the parameters you
>>>>> defined, there would be no way to connect together the change address with
>>>>> the original address, meaning they would have completely separate rate
>>>>> limits, which wouldn't work since the change output would ignore the
>>>>> previous rate limit.
>>>>
>>>>
>>>> The rate-limiting parameters must be re-specified for each rate-limited
>>>> input. So, a transaction that has a rate-limited input is only valid if its
>>>> output is itself rate-limited such that it does not violate the
>>>> rate-limiting constraints of its input.
>>>>
>>>> In my thread-starter, I gave the below example of a rate-limited
>>>> address a2 that serves as input for transaction t2:
>>>>
>>>> a2: 99.8 sats at height 800100;
>>>> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k;
>>>>
>>>> Transaction t2:
>>>> Included at block height 800200
>>>> Spend: 400k + fees.
>>>> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k.
>>>>
>>>> Note how transaction t2 re-specifies the rate-limiting parameters.
>>>> Validation must ensure that the re-specified parameters are within bounds,
>>>> i.e., do not allow more spending per epoch than the rate-limiting
>>>> parameters of its input address a2. Re-specifying the rate-limiting
>>>> parameters offers the flexibility to further restrict spending, or to
>>>> disable any additional spending within the current epoch by setting
>>>> a_remaining to zero.
>>>>
>>>> Result:
>>>> Value at destination address: 400k sats;
>>>> Rate limiting params at destination address: none;
>>>> Value at change address a3: 99.4m sats;
>>>> Rate limiting params at change address a3: h0=800144, h1=800287,
>>>> a=500k, a_remaining=100k.
>>>>
>>>> As a design principle I believe it makes sense if the system is able to
>>>> verify the validity of a transaction without having to consider any
>>>> transactions that precede its inputs. As a side-note, doing away with this
>>>> design principle would however enable more sophisticated rate-limiting
>>>> (such as rate-limiting per sliding window instead of rate-limiting per
>>>> epoch having a fixed start and end block), but while at the same time
>>>> reducing the size of per rate-limiting transaction (because it would enable
>>>> specifying the rate-limiting parameters more space-efficiently). To test
>>>> the waters and to keep things relatively simple, I chose not to go into
>>>> this enhanced form of rate-limiting.
>>>>
>>>> I haven't gone into how to process a transaction having multiple
>>>> rate-limited inputs. The easiest way to handle this case is to not allow
>>>> any transaction having more than one rate-limited input. One could imagine
>>>> complex logic to handle transactions having multiple rate-limited inputs by
>>>> creating multiple rate-limited change addresses. However at first glance I
>>>> don't believe that the marginal added functionality would justify the
>>>> increased implementation complexity.
>>>>
>>>> I'd be interested in seeing you write a BIP for this.
>>>>
>>>>
>>>> Thank you, but sadly my understanding of Bitcoin is way too low to be
>>>> able to write a BIP and do the implementation. However I see tremendous
>>>> value in this functionality. Favorable feedback of the list regarding the
>>>> usefulness and the technical feasibility of rate-limiting functionality
>>>> would of course be an encouragement for me to descend further down the
>>>> rabbit hole.
>>>>
>>>> Zac
>>>>
>>>>
>>>> On Sun, Aug 1, 2021 at 10:09 AM Zac Greenwood <zachgrw at gmail.com>
>>>> wrote:
>>>>
>>>>> [Resubmitting to list with minor edits. My previous submission ended
>>>>> up inside an existing thread, apologies.]
>>>>>
>>>>> Hi list,
>>>>>
>>>>> I'd like to explore whether it is feasible to implement new scripting
>>>>> capabilities in Bitcoin that enable limiting the output amount of a
>>>>> transaction based on the total value of its inputs. In other words, to
>>>>> implement the ability to limit the maximum amount that can be sent from an
>>>>> address.
>>>>>
>>>>> Two use cases come to mind:
>>>>>
>>>>> UC1: enable a user to add additional protection their funds by
>>>>> rate-limiting the amount that they are allowed to send during a certain
>>>>> period (measured in blocks). A typical use case might be a user that
>>>>> intends to hodl their bitcoin, but still wishes to occasionally send small
>>>>> amounts. Rate-limiting avoids an attacker from sweeping all the users'
>>>>> funds in a single transaction, allowing the user to become aware of the
>>>>> theft and intervene to prevent further thefts.
>>>>>
>>>>> UC2: exchanges may wish to rate-limit addresses containing large
>>>>> amounts of bitcoin, adding warm- or hot-wallet functionality to a
>>>>> cold-storage address. This would enable an exchange to drastically reduce
>>>>> the number of times a cold wallet must be accessed with private keys that
>>>>> give access to the full amount.
>>>>>
>>>>> In a typical setup, I'd envision using multisig such that the user has
>>>>> two sets of private keys to their encumbered address (with a "set" of keys
>>>>> meaning "one or more" keys). One set of private keys allows only for
>>>>> sending with rate-limiting restrictions in place, and a second set of
>>>>> private keys allowing for sending any amount without rate-limiting,
>>>>> effectively overriding such restriction.
>>>>>
>>>>> The parameters that define in what way an output is rate-limited might
>>>>> be defined as follows:
>>>>>
>>>>> Param 1: a block height "h0" indicating the first block height of an
>>>>> epoch;
>>>>> Param 2: a block height "h1" indicating the last block height of an
>>>>> epoch;
>>>>> Param 3: an amount "a" in satoshi indicating the maximum amount that
>>>>> is allowed to be sent in any epoch;
>>>>> Param 4: an amount "a_remaining" (in satoshi) indicating the maximum
>>>>> amount that is allowed to be sent within the current epoch.
>>>>>
>>>>> For example, consider an input containing 100m sats (1 BTC) which has
>>>>> been rate-limited with parameters (h0, h1, a, a_remaining) of (800000,
>>>>> 800143, 500k, 500k). These parameters define that the address is
>>>>> rate-limited to sending a maximum of 500k sats in the current epoch that
>>>>> starts at block height 800000 and ends at height 800143 (or about one day
>>>>> ignoring block time variance) and that the full amount of 500k is still
>>>>> sendable. These rate-limiting parameters ensure that it takes at minimum
>>>>> 100m / 500k = 200 transactions and 200 x 144 blocks or about 200 days to
>>>>> spend the full 100m sats. As noted earlier, in a typical setup a user
>>>>> should retain the option to transact the entire amount using a second (set
>>>>> of) private key(s).
>>>>>
>>>>> For rate-limiting to work, any change output created by a transaction
>>>>> from a rate-limited address must itself be rate-limited as well. For
>>>>> instance, expanding on the above example, assume that the user spends 200k
>>>>> sats from a rate-limited address a1 containing 100m sats:
>>>>>
>>>>> Start situation:
>>>>> At block height 800000: rate-limited address a1 is created;
>>>>> Value of a1: 100.0m sats;
>>>>> Rate limiting params of a1: h0=800000, h1=800143, a=500k,
>>>>> a_remaining=500k;
>>>>>
>>>>> Transaction t1:
>>>>> Included at block height 800100;
>>>>> Spend: 200k + fee;
>>>>> Rate limiting params: h0=800000, h1=800143, a=500k, a_remaining=300k.
>>>>>
>>>>> Result:
>>>>> Value at destination address: 200k sats;
>>>>> Rate limiting params at destination address: none;
>>>>> Value at change address a2: 99.8m sats;
>>>>> Rate limiting params at change address a2: h0=800000, h1=800143,
>>>>> a=500k, a_remaining=300k.
>>>>>
>>>>> In order to properly enforce rate limiting, the change address must be
>>>>> rate-limited such that the original rate limit of 500k sats per 144 blocks
>>>>> cannot be exceeded. In this example, the change address a2 were given the
>>>>> same rate limiting parameters as the transaction that served as its input.
>>>>> As a result, from block 800100 up until and including block 800143, a
>>>>> maximum amount of 300k sats is allowed to be spent from the change address.
>>>>>
>>>>> Example continued:
>>>>> a2: 99.8 sats at height 800100;
>>>>> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k;
>>>>>
>>>>> Transaction t2:
>>>>> Included at block height 800200
>>>>> Spend: 400k + fees.
>>>>> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k.
>>>>>
>>>>> Result:
>>>>> Value at destination address: 400k sats;
>>>>> Rate limiting params at destination address: none;
>>>>> Value at change address a3: 99.4m sats;
>>>>> Rate limiting params at change address a3: h0=800144, h1=800287,
>>>>> a=500k, a_remaining=100k.
>>>>>
>>>>> Transaction t2 is allowed because it falls within the next epoch
>>>>> (running from 800144 to 800287) so a spend of 400k does not violate the
>>>>> constraint of 500k per epoch.
>>>>>
>>>>> As could be seen, the rate limiting parameters are part of the
>>>>> transaction and chosen by the user (or their wallet). This means that the
>>>>> parameters must be validated to ensure that they do not violate the
>>>>> intended constraints.
>>>>>
>>>>> For instance, this transaction should not be allowed:
>>>>> a2: 99.8 sats at height 800100;
>>>>> Rate-limit params of a2: h0=800000, h1=800143, a=500k,
>>>>> a_remaining=300k;
>>>>>
>>>>> Transaction t2a:
>>>>> Included at block height 800200;
>>>>> Spend: 400k + fees;
>>>>> Rate-limit params: h0=800124, h1=800267, a=500k, a_remaining=100k.
>>>>>
>>>>> This transaction t2a attempts to shift the epoch forward by 20 blocks
>>>>> such that it starts at 800124 instead of 800144. Shifting the epoch forward
>>>>> like this must not be allowed because it enables spending more that the
>>>>> rate limit allows, which is 500k in any epoch of 144 blocks. It would
>>>>> enable overspending:
>>>>>
>>>>> t1: spend 200k at 800100 (epoch 1: total: 200k);
>>>>> t2a: spend 400k at 800200 (epoch 2: total: 400k);
>>>>> t3a: spend 100k at 800201 (epoch 2: total: 500k);
>>>>> t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspending for
>>>>> epoch 2).
>>>>>
>>>>> Specifying the rate-limiting parameters explicitly at every
>>>>> transaction allows the user to tighten the spending limit by setting
>>>>> tighter limits or for instance by setting a_remainder to 0 if they wish to
>>>>> enforce not spending more during an epoch. A second advantage of explicitly
>>>>> specifying the four rate-limiting parameters with each transaction is that
>>>>> it allows the system to fully validate the transaction without having to
>>>>> consider any previous transactions within an epoch.
>>>>>
>>>>> I will stop here because I would like to gauge interest in this idea
>>>>> first before continuing work on other aspects. Two main pieces of work jump
>>>>> to mind:
>>>>>
>>>>> Define all validations;
>>>>> Describe aggregate behaviour of multiple (rate-limited) inputs, proof
>>>>> that two rate-limited addresses cannot spend more than the sum of their
>>>>> individual limits.
>>>>>
>>>>> Zac
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210805/55d5d18c/attachment-0001.html>

2023-06-07 22:57:24

- reply

📅 Original date posted:2021-08-04
📝 Original message:> Ah I see, this is all limited to within a single epoch.
No, that wouldn't be useful. A maximum amount is allowed to be spent within
EVERY epoch.
Consider an epoch length of 100 blocks with a spend limit of 200k per
epoch. The following is allowed:
epoch1 (800101 - 800200): spend 120k in block 800140. Remaining for epoch1:
80k;
epoch1 (800101 - 800200): spend another 60k in block 800195. Remaining for
epoch1: 20k;
epoch2 (800201 - 800300): spend 160k in block 800201. Remaining for epoch2:
40k.
Since the limit pertains to each individual epoch, it is allowed to spend
up to the full limit at the start of any new epoch. In this example, the
spending was as follows:
800140: 120k
800195: 60k
800201: 160k.
Note that in a span of 62 blocks a total of 340k sats was spent. This may
seem to violate the 200k limit per 100 blocks, but this is the result of
using a per-epoch limit. This allows a maximum of 400k to be spent in 2
blocks llke so: 200k in the last block of an epoch and another 200k in the
first block of the next epoch. However this is inconsequential for the
intended goal of rate-limiting which is to enable small spends over time
from a large amount and to prevent theft of a large amount with a single
transaction.
To explain the proposed design more clearly, I have renamed the params as
follows:
epochStart: block height of first block of the current epoch (was: h0);
epochEnd: block height of last block of the current epoch (was: h1);
limit: the maximum total amount allowed to be spent within the current
epoch (was: a);
remain: the remaining amount allowed to be spent within the current epoch
(was: a_remaining);
Also, to illustrate that the params are specific to a transaction, I will
hence precede the param with the transaction name like so:
tx8_limit, tx31c_remain, tx42z_epochStart, ... etc.
For simplicity, only transactions with no more than one rate-limited input
are considered, and with no more than two outputs: one rate-limited change
output, and a normal (not rate-limited) output.
Normally, a simple transaction generates two outputs: one for a payment to
a third party and one for the change address. Again for simplicity, we
demand that a transaction which introduces rate-limiting must have only a
single, rate-limited output. The validation rule might be: if a transaction
has rate-limiting params and none of its inputs are rate-limited, then
there must be only a single (rate-limited) output (and no second or change
output).
Consider rate limiting transactions tx1 having one or more normal (non
rate-limited) inputs:
tx1 gets included at block height 800004;
The inputs of tx1 are not rate-limited => tx1 must have only a single
output which will become rate-limited;
params: tx1_epochStart=800001, tx1_epochEnd=800100, tx1_limit=200k,
tx1_remain=200k;
=> This defines that an epoch has 100 blocks and no more than 200k sats may
be spent in any one epoch. Within the current epoch, 200k sats may still be
spent.
This transaction begins to rate-limit a set of inputs, so it has a single
rate-limited output.
Let's explore transactions that have the output of tx1 as their input. I
will denote the output of tx1 as "out1".
tx2a has out1 as its only input;
tx2a spends 50k sats and gets included at block height 803050;
tx2a specifies the following params for its change output "chg2a":
chg2a_epochStart=803001, chg2a_epochEnd=803100;
chg2a_limit=200k, chg2a_remain=150k.
To enforce rate-limiting, the system must validate the params of the change
output chg2a to ensure that overspending is not allowed.
The above params are allowed because:
=> 1. the epoch does not become smaller than 100 blocks [(chg2a_epochEnd -
chg2a_epochStart) >= (tx1_epochEnd - tx1_epochStart)]
=> 2. tx1_limit has not been increased (ch2a_limit <= tx1_limit)
=> 3. the amount spent (50k sats) does not exceed tx1_remain AND does not
exceed chg2a_limit;
=> 4. chg2a_remain" is 50k sats less than chg2a_limit.
A transaction may also further constrain further spending like so:
tx2b has out1as its only input;
tx2b spends 8k sats and gets included at block height 808105;
tx2b specifies the following params for its change output "chg2b":
chg2b_epochStart=808101, chg2b_epochEnd=808250;
chg2b_limit=10k, chg2b_remain=0.
These params are allowed because:
=> 1. the epoch does not become smaller than100 blocks. It is fine to
increase the epoch to 150 blocks because it does not enable exceeding the
original rate-limit;
=> 2. the limit (chg2b_limit) has been decreased to 10k sats, further
restricting the maximum amount allowed to be spent within the current and
any subsequent epochs;
=> 3. the amount spent (10k sats) does not exceed tx1_remain AND does not
exceed chg2b_limit;
=> 4. chg2b_remain has been set to zero, meaning that within the current
epoch (block height 808101 to and including 808250), tx2b cannot be used as
a spending input to any transaction.
Starting from block height 808251, a new epoch will start and the
rate-limited output of tx2b may again be used as an input for a subsequent
rate-limited transaction tx3b. This transaction tx3b must again be
accompanied by params that do not violate the rate-limit as defined by the
params of tx2b and which are stored with output out2b. So, the epoch of
tx3b must be at minimum 150 blocks, the maximum that is allowed to be spent
per epoch is at most 10k sats, and chg3b_remain must be decreased by at
least the amount spent by tx3b.
>From the above, the rate-limiting mechanics should hopefully be clear and
full set of validation rules could be defined in a more generalized way
with little additional effort.
Note that I conveniently avoided talking about how to represent the
parameters within transactions or outputs, simply because I currently lack
enough understanding to reason about this. I am hoping that others may
offer help.
Zac
On Tue, Aug 3, 2021 at 8:12 PM Billy Tetrud <billy.tetrud at gmail.com> wrote:
> > To enable more straightforward validation logic.
> > within the current epoch
>
> Ah I see, this is all limited to within a single epoch. I think that
> sufficiently limits the window of time in which nodes have to store
> information for rate limited outputs. However, I don't see how specifying
> block ranges simplifies the logic - wouldn't this complicate the logic with
> additional user-specified constraints? It also prevents the output from
> being able to be rate limited over the span of multiple epochs, which would
> seem to make it a lot more difficult to use for certain types of wallets
> (eg cold wallets).
>
> I think I see the logic of your 'remaining' parameter there. If you start
> with a single rate-limited input, you can split that into many outputs,
> only one of which have a 'remaining' balance. The rest can simply remain
> unspendable for the rest of the epoch. That way these things don't need to
> be tied together. However, that doesn't solve the problem of 3rd parties
> being able to send money into the wallet.
>
> > I don't believe that the marginal added functionality would justify the
> increased implementation complexity
>
> Perhaps, but I think there is a lot of benefit in allowing these kinds of
> things to operate as similarly as possible to normal transactions, for one
> because of usability reasons. If each opcode has its own quirks that are
> not intuitively related to their purpose (eg if a rate-limited wallet had
> no way to get a receiving address), it would confuse end-users (eg who
> wonder how to get a receiving address and how they can ask people to send
> money into their wallet) or require a lot of technical complexity in
> applications (eg to support something like cooperatively connecting with
> their wallet so that a transaction can be made that creates a new
> single-output for the wallet). A little complexity in this opcode can save
> a lot of external complexity here I think.
>
> > my understanding of Bitcoin is way too low to be able to write a BIP and
> do the implementation
>
> You might be able to find people willing to help. I would be willing to
> help write the BIP spec. I'm not the right person to help with the
> implementation, but perhaps you could find someone else who is. Even if the
> BIP isn't adopted, it could be a starting point or inspiration for someone
> else to write an improved version.
>
> On Mon, Aug 2, 2021 at 2:32 AM Zac Greenwood <zachgrw at gmail.com> wrote:
>
>> [Note: I've moved your reply to the newly started thread]
>>
>> Hi Billy,
>>
>> Thank you for your kind and encouraging feedback.
>>
>> I don't quite understand why you'd want to define a specific span of
>>> blocks for the rate limit. Why not just specify the size of the window (in
>>> blocks) to rate limit within, and the limit?
>>
>>
>> To enable more straightforward validation logic.
>>
>> You mentioned change addresses, however, with the parameters you defined,
>>> there would be no way to connect together the change address with the
>>> original address, meaning they would have completely separate rate limits,
>>> which wouldn't work since the change output would ignore the previous rate
>>> limit.
>>
>>
>> The rate-limiting parameters must be re-specified for each rate-limited
>> input. So, a transaction that has a rate-limited input is only valid if its
>> output is itself rate-limited such that it does not violate the
>> rate-limiting constraints of its input.
>>
>> In my thread-starter, I gave the below example of a rate-limited address
>> a2 that serves as input for transaction t2:
>>
>> a2: 99.8 sats at height 800100;
>> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k;
>>
>> Transaction t2:
>> Included at block height 800200
>> Spend: 400k + fees.
>> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k.
>>
>> Note how transaction t2 re-specifies the rate-limiting parameters.
>> Validation must ensure that the re-specified parameters are within bounds,
>> i.e., do not allow more spending per epoch than the rate-limiting
>> parameters of its input address a2. Re-specifying the rate-limiting
>> parameters offers the flexibility to further restrict spending, or to
>> disable any additional spending within the current epoch by setting
>> a_remaining to zero.
>>
>> Result:
>> Value at destination address: 400k sats;
>> Rate limiting params at destination address: none;
>> Value at change address a3: 99.4m sats;
>> Rate limiting params at change address a3: h0=800144, h1=800287, a=500k,
>> a_remaining=100k.
>>
>> As a design principle I believe it makes sense if the system is able to
>> verify the validity of a transaction without having to consider any
>> transactions that precede its inputs. As a side-note, doing away with this
>> design principle would however enable more sophisticated rate-limiting
>> (such as rate-limiting per sliding window instead of rate-limiting per
>> epoch having a fixed start and end block), but while at the same time
>> reducing the size of per rate-limiting transaction (because it would enable
>> specifying the rate-limiting parameters more space-efficiently). To test
>> the waters and to keep things relatively simple, I chose not to go into
>> this enhanced form of rate-limiting.
>>
>> I haven't gone into how to process a transaction having multiple
>> rate-limited inputs. The easiest way to handle this case is to not allow
>> any transaction having more than one rate-limited input. One could imagine
>> complex logic to handle transactions having multiple rate-limited inputs by
>> creating multiple rate-limited change addresses. However at first glance I
>> don't believe that the marginal added functionality would justify the
>> increased implementation complexity.
>>
>> I'd be interested in seeing you write a BIP for this.
>>
>>
>> Thank you, but sadly my understanding of Bitcoin is way too low to be
>> able to write a BIP and do the implementation. However I see tremendous
>> value in this functionality. Favorable feedback of the list regarding the
>> usefulness and the technical feasibility of rate-limiting functionality
>> would of course be an encouragement for me to descend further down the
>> rabbit hole.
>>
>> Zac
>>
>>
>> On Sun, Aug 1, 2021 at 10:09 AM Zac Greenwood <zachgrw at gmail.com> wrote:
>>
>>> [Resubmitting to list with minor edits. My previous submission ended up
>>> inside an existing thread, apologies.]
>>>
>>> Hi list,
>>>
>>> I'd like to explore whether it is feasible to implement new scripting
>>> capabilities in Bitcoin that enable limiting the output amount of a
>>> transaction based on the total value of its inputs. In other words, to
>>> implement the ability to limit the maximum amount that can be sent from an
>>> address.
>>>
>>> Two use cases come to mind:
>>>
>>> UC1: enable a user to add additional protection their funds by
>>> rate-limiting the amount that they are allowed to send during a certain
>>> period (measured in blocks). A typical use case might be a user that
>>> intends to hodl their bitcoin, but still wishes to occasionally send small
>>> amounts. Rate-limiting avoids an attacker from sweeping all the users'
>>> funds in a single transaction, allowing the user to become aware of the
>>> theft and intervene to prevent further thefts.
>>>
>>> UC2: exchanges may wish to rate-limit addresses containing large amounts
>>> of bitcoin, adding warm- or hot-wallet functionality to a cold-storage
>>> address. This would enable an exchange to drastically reduce the number of
>>> times a cold wallet must be accessed with private keys that give access to
>>> the full amount.
>>>
>>> In a typical setup, I'd envision using multisig such that the user has
>>> two sets of private keys to their encumbered address (with a "set" of keys
>>> meaning "one or more" keys). One set of private keys allows only for
>>> sending with rate-limiting restrictions in place, and a second set of
>>> private keys allowing for sending any amount without rate-limiting,
>>> effectively overriding such restriction.
>>>
>>> The parameters that define in what way an output is rate-limited might
>>> be defined as follows:
>>>
>>> Param 1: a block height "h0" indicating the first block height of an
>>> epoch;
>>> Param 2: a block height "h1" indicating the last block height of an
>>> epoch;
>>> Param 3: an amount "a" in satoshi indicating the maximum amount that is
>>> allowed to be sent in any epoch;
>>> Param 4: an amount "a_remaining" (in satoshi) indicating the maximum
>>> amount that is allowed to be sent within the current epoch.
>>>
>>> For example, consider an input containing 100m sats (1 BTC) which has
>>> been rate-limited with parameters (h0, h1, a, a_remaining) of (800000,
>>> 800143, 500k, 500k). These parameters define that the address is
>>> rate-limited to sending a maximum of 500k sats in the current epoch that
>>> starts at block height 800000 and ends at height 800143 (or about one day
>>> ignoring block time variance) and that the full amount of 500k is still
>>> sendable. These rate-limiting parameters ensure that it takes at minimum
>>> 100m / 500k = 200 transactions and 200 x 144 blocks or about 200 days to
>>> spend the full 100m sats. As noted earlier, in a typical setup a user
>>> should retain the option to transact the entire amount using a second (set
>>> of) private key(s).
>>>
>>> For rate-limiting to work, any change output created by a transaction
>>> from a rate-limited address must itself be rate-limited as well. For
>>> instance, expanding on the above example, assume that the user spends 200k
>>> sats from a rate-limited address a1 containing 100m sats:
>>>
>>> Start situation:
>>> At block height 800000: rate-limited address a1 is created;
>>> Value of a1: 100.0m sats;
>>> Rate limiting params of a1: h0=800000, h1=800143, a=500k,
>>> a_remaining=500k;
>>>
>>> Transaction t1:
>>> Included at block height 800100;
>>> Spend: 200k + fee;
>>> Rate limiting params: h0=800000, h1=800143, a=500k, a_remaining=300k.
>>>
>>> Result:
>>> Value at destination address: 200k sats;
>>> Rate limiting params at destination address: none;
>>> Value at change address a2: 99.8m sats;
>>> Rate limiting params at change address a2: h0=800000, h1=800143, a=500k,
>>> a_remaining=300k.
>>>
>>> In order to properly enforce rate limiting, the change address must be
>>> rate-limited such that the original rate limit of 500k sats per 144 blocks
>>> cannot be exceeded. In this example, the change address a2 were given the
>>> same rate limiting parameters as the transaction that served as its input.
>>> As a result, from block 800100 up until and including block 800143, a
>>> maximum amount of 300k sats is allowed to be spent from the change address.
>>>
>>> Example continued:
>>> a2: 99.8 sats at height 800100;
>>> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k;
>>>
>>> Transaction t2:
>>> Included at block height 800200
>>> Spend: 400k + fees.
>>> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k.
>>>
>>> Result:
>>> Value at destination address: 400k sats;
>>> Rate limiting params at destination address: none;
>>> Value at change address a3: 99.4m sats;
>>> Rate limiting params at change address a3: h0=800144, h1=800287, a=500k,
>>> a_remaining=100k.
>>>
>>> Transaction t2 is allowed because it falls within the next epoch
>>> (running from 800144 to 800287) so a spend of 400k does not violate the
>>> constraint of 500k per epoch.
>>>
>>> As could be seen, the rate limiting parameters are part of the
>>> transaction and chosen by the user (or their wallet). This means that the
>>> parameters must be validated to ensure that they do not violate the
>>> intended constraints.
>>>
>>> For instance, this transaction should not be allowed:
>>> a2: 99.8 sats at height 800100;
>>> Rate-limit params of a2: h0=800000, h1=800143, a=500k, a_remaining=300k;
>>>
>>> Transaction t2a:
>>> Included at block height 800200;
>>> Spend: 400k + fees;
>>> Rate-limit params: h0=800124, h1=800267, a=500k, a_remaining=100k.
>>>
>>> This transaction t2a attempts to shift the epoch forward by 20 blocks
>>> such that it starts at 800124 instead of 800144. Shifting the epoch forward
>>> like this must not be allowed because it enables spending more that the
>>> rate limit allows, which is 500k in any epoch of 144 blocks. It would
>>> enable overspending:
>>>
>>> t1: spend 200k at 800100 (epoch 1: total: 200k);
>>> t2a: spend 400k at 800200 (epoch 2: total: 400k);
>>> t3a: spend 100k at 800201 (epoch 2: total: 500k);
>>> t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspending for epoch
>>> 2).
>>>
>>> Specifying the rate-limiting parameters explicitly at every transaction
>>> allows the user to tighten the spending limit by setting tighter limits or
>>> for instance by setting a_remainder to 0 if they wish to enforce not
>>> spending more during an epoch. A second advantage of explicitly specifying
>>> the four rate-limiting parameters with each transaction is that it allows
>>> the system to fully validate the transaction without having to consider any
>>> previous transactions within an epoch.
>>>
>>> I will stop here because I would like to gauge interest in this idea
>>> first before continuing work on other aspects. Two main pieces of work jump
>>> to mind:
>>>
>>> Define all validations;
>>> Describe aggregate behaviour of multiple (rate-limited) inputs, proof
>>> that two rate-limited addresses cannot spend more than the sum of their
>>> individual limits.
>>>
>>> Zac
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210804/d529d396/attachment-0001.html>

2023-06-07 22:57:21

- reply

📅 Original date posted:2021-08-02
📝 Original message:[Note: I've moved your reply to the newly started thread]
Hi Billy,
Thank you for your kind and encouraging feedback.
I don't quite understand why you'd want to define a specific span of blocks
> for the rate limit. Why not just specify the size of the window (in blocks)
> to rate limit within, and the limit?
To enable more straightforward validation logic.
You mentioned change addresses, however, with the parameters you defined,
> there would be no way to connect together the change address with the
> original address, meaning they would have completely separate rate limits,
> which wouldn't work since the change output would ignore the previous rate
> limit.
The rate-limiting parameters must be re-specified for each rate-limited
input. So, a transaction that has a rate-limited input is only valid if its
output is itself rate-limited such that it does not violate the
rate-limiting constraints of its input.
In my thread-starter, I gave the below example of a rate-limited address a2
that serves as input for transaction t2:
a2: 99.8 sats at height 800100;
Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k;
Transaction t2:
Included at block height 800200
Spend: 400k + fees.
Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k.
Note how transaction t2 re-specifies the rate-limiting parameters.
Validation must ensure that the re-specified parameters are within bounds,
i.e., do not allow more spending per epoch than the rate-limiting
parameters of its input address a2. Re-specifying the rate-limiting
parameters offers the flexibility to further restrict spending, or to
disable any additional spending within the current epoch by setting
a_remaining to zero.
Result:
Value at destination address: 400k sats;
Rate limiting params at destination address: none;
Value at change address a3: 99.4m sats;
Rate limiting params at change address a3: h0=800144, h1=800287, a=500k,
a_remaining=100k.
As a design principle I believe it makes sense if the system is able to
verify the validity of a transaction without having to consider any
transactions that precede its inputs. As a side-note, doing away with this
design principle would however enable more sophisticated rate-limiting
(such as rate-limiting per sliding window instead of rate-limiting per
epoch having a fixed start and end block), but while at the same time
reducing the size of per rate-limiting transaction (because it would enable
specifying the rate-limiting parameters more space-efficiently). To test
the waters and to keep things relatively simple, I chose not to go into
this enhanced form of rate-limiting.
I haven't gone into how to process a transaction having multiple
rate-limited inputs. The easiest way to handle this case is to not allow
any transaction having more than one rate-limited input. One could imagine
complex logic to handle transactions having multiple rate-limited inputs by
creating multiple rate-limited change addresses. However at first glance I
don't believe that the marginal added functionality would justify the
increased implementation complexity.
I'd be interested in seeing you write a BIP for this.
Thank you, but sadly my understanding of Bitcoin is way too low to be able
to write a BIP and do the implementation. However I see tremendous value in
this functionality. Favorable feedback of the list regarding the usefulness
and the technical feasibility of rate-limiting functionality would of
course be an encouragement for me to descend further down the rabbit hole.
Zac
On Sun, Aug 1, 2021 at 10:09 AM Zac Greenwood <zachgrw at gmail.com> wrote:
> [Resubmitting to list with minor edits. My previous submission ended up
> inside an existing thread, apologies.]
>
> Hi list,
>
> I'd like to explore whether it is feasible to implement new scripting
> capabilities in Bitcoin that enable limiting the output amount of a
> transaction based on the total value of its inputs. In other words, to
> implement the ability to limit the maximum amount that can be sent from an
> address.
>
> Two use cases come to mind:
>
> UC1: enable a user to add additional protection their funds by
> rate-limiting the amount that they are allowed to send during a certain
> period (measured in blocks). A typical use case might be a user that
> intends to hodl their bitcoin, but still wishes to occasionally send small
> amounts. Rate-limiting avoids an attacker from sweeping all the users'
> funds in a single transaction, allowing the user to become aware of the
> theft and intervene to prevent further thefts.
>
> UC2: exchanges may wish to rate-limit addresses containing large amounts
> of bitcoin, adding warm- or hot-wallet functionality to a cold-storage
> address. This would enable an exchange to drastically reduce the number of
> times a cold wallet must be accessed with private keys that give access to
> the full amount.
>
> In a typical setup, I'd envision using multisig such that the user has two
> sets of private keys to their encumbered address (with a "set" of keys
> meaning "one or more" keys). One set of private keys allows only for
> sending with rate-limiting restrictions in place, and a second set of
> private keys allowing for sending any amount without rate-limiting,
> effectively overriding such restriction.
>
> The parameters that define in what way an output is rate-limited might be
> defined as follows:
>
> Param 1: a block height "h0" indicating the first block height of an epoch;
> Param 2: a block height "h1" indicating the last block height of an epoch;
> Param 3: an amount "a" in satoshi indicating the maximum amount that is
> allowed to be sent in any epoch;
> Param 4: an amount "a_remaining" (in satoshi) indicating the maximum
> amount that is allowed to be sent within the current epoch.
>
> For example, consider an input containing 100m sats (1 BTC) which has been
> rate-limited with parameters (h0, h1, a, a_remaining) of (800000, 800143,
> 500k, 500k). These parameters define that the address is rate-limited to
> sending a maximum of 500k sats in the current epoch that starts at block
> height 800000 and ends at height 800143 (or about one day ignoring block
> time variance) and that the full amount of 500k is still sendable. These
> rate-limiting parameters ensure that it takes at minimum 100m / 500k = 200
> transactions and 200 x 144 blocks or about 200 days to spend the full 100m
> sats. As noted earlier, in a typical setup a user should retain the option
> to transact the entire amount using a second (set of) private key(s).
>
> For rate-limiting to work, any change output created by a transaction from
> a rate-limited address must itself be rate-limited as well. For instance,
> expanding on the above example, assume that the user spends 200k sats from
> a rate-limited address a1 containing 100m sats:
>
> Start situation:
> At block height 800000: rate-limited address a1 is created;
> Value of a1: 100.0m sats;
> Rate limiting params of a1: h0=800000, h1=800143, a=500k, a_remaining=500k;
>
> Transaction t1:
> Included at block height 800100;
> Spend: 200k + fee;
> Rate limiting params: h0=800000, h1=800143, a=500k, a_remaining=300k.
>
> Result:
> Value at destination address: 200k sats;
> Rate limiting params at destination address: none;
> Value at change address a2: 99.8m sats;
> Rate limiting params at change address a2: h0=800000, h1=800143, a=500k,
> a_remaining=300k.
>
> In order to properly enforce rate limiting, the change address must be
> rate-limited such that the original rate limit of 500k sats per 144 blocks
> cannot be exceeded. In this example, the change address a2 were given the
> same rate limiting parameters as the transaction that served as its input.
> As a result, from block 800100 up until and including block 800143, a
> maximum amount of 300k sats is allowed to be spent from the change address.
>
> Example continued:
> a2: 99.8 sats at height 800100;
> Rate-limit params: h0=800000, h1=800143, a=500k, a_remaining=300k;
>
> Transaction t2:
> Included at block height 800200
> Spend: 400k + fees.
> Rate-limiting params: h0=800144, h1=800287, a=500k, a_remaining=100k.
>
> Result:
> Value at destination address: 400k sats;
> Rate limiting params at destination address: none;
> Value at change address a3: 99.4m sats;
> Rate limiting params at change address a3: h0=800144, h1=800287, a=500k,
> a_remaining=100k.
>
> Transaction t2 is allowed because it falls within the next epoch (running
> from 800144 to 800287) so a spend of 400k does not violate the constraint
> of 500k per epoch.
>
> As could be seen, the rate limiting parameters are part of the transaction
> and chosen by the user (or their wallet). This means that the parameters
> must be validated to ensure that they do not violate the intended
> constraints.
>
> For instance, this transaction should not be allowed:
> a2: 99.8 sats at height 800100;
> Rate-limit params of a2: h0=800000, h1=800143, a=500k, a_remaining=300k;
>
> Transaction t2a:
> Included at block height 800200;
> Spend: 400k + fees;
> Rate-limit params: h0=800124, h1=800267, a=500k, a_remaining=100k.
>
> This transaction t2a attempts to shift the epoch forward by 20 blocks such
> that it starts at 800124 instead of 800144. Shifting the epoch forward like
> this must not be allowed because it enables spending more that the rate
> limit allows, which is 500k in any epoch of 144 blocks. It would enable
> overspending:
>
> t1: spend 200k at 800100 (epoch 1: total: 200k);
> t2a: spend 400k at 800200 (epoch 2: total: 400k);
> t3a: spend 100k at 800201 (epoch 2: total: 500k);
> t4a: spend 500k at 800268 (epoch 2: total: 1000k, overspending for epoch
> 2).
>
> Specifying the rate-limiting parameters explicitly at every transaction
> allows the user to tighten the spending limit by setting tighter limits or
> for instance by setting a_remainder to 0 if they wish to enforce not
> spending more during an epoch. A second advantage of explicitly specifying
> the four rate-limiting parameters with each transaction is that it allows
> the system to fully validate the transaction without having to consider any
> previous transactions within an epoch.
>
> I will stop here because I would like to gauge interest in this idea first
> before continuing work on other aspects. Two main pieces of work jump to
> mind:
>
> Define all validations;
> Describe aggregate behaviour of multiple (rate-limited) inputs, proof that
> two rate-limited addresses cannot spend more than the sum of their
> individual limits.
>
> Zac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210802/49badd38/attachment.html>

2023-06-07 22:57:12

- reply

📅 Original date posted:2021-07-28
📝 Original message:Hi Billy,
Thank you for your comprehensive reply. My purpose was to find out whether
a proposal to somehow limit the amount being sent from an address exists
and to further illustrate my thoughts by giving a concrete example of how
this might work functionally without getting to deep into the
technicalities.
As for your assumption: for an amount limit to have the desired effect, I
realize now that there must also exist some limit on the number of
transactions that will be allowed from the encumbered address.
Taking a step back, a typical use case would be a speculating user
intending to hodl bitcoin but who still wishes to be able to occasionally
transact minor amounts.
Ideally, such user should optionally still be able to bypass the rate limit
and spend the entire amount in a single transaction by signing with an
additional private key (multisig).
During the setup phase, a user sends all their to-be-rate-limited coin to a
single address. When spending from this rate limited address, any change
sent to the change address must be rate limited as well using identical
parameters. I believe that’s also what you’re suggesting.
I believe that a smart wallet should be able to set up and maintain
multiple rate-limited addresses in such a way that their aggregate
behaviour meets any rate-limiting parameters as desired by the user. This
ought to alleviate your privacy concerns because it means that the wallet
will be able to mix outputs.
The options for the to-be implemented rate-limiting parameters vary from
completely arbitrary to more restrictive.
Completely arbitrary parameters would allow users to set up a rate limit
that basically destroys their funds, for instance rate-limiting an address
to an amount of 1 satoshi per 100 blocks.
More restrictive rate limits would remove such footgun and may require that
only a combination of parameters are allowed such that all funds will be
spendable within a set number of blocks (for instance 210,000).
As for the rate-limiting parameters, in addition to a per-transaction
maximum of (minimum amount in satoshi or a percentage of the total amount
stored at the address), also the transaction frequency must be limited. I
would propose this to be expressed as a number of blocks before a next
transaction can be sent from the encumbered address(es).
I believe such user-enabled rate-limiting is superior to one that requires
a third party.
As an aside, I am not sure how a vault solution would be able to prevent an
attacker who is in possession of the vaults’ private key from sabotaging
the user by replacing the user transaction with one having a higher fee
every time the user attempts to transact. I am probably missing something
here though.
Zac
On Tue, 27 Jul 2021 at 19:21, Billy Tetrud <billy.tetrud at gmail.com> wrote:
> Hi Zac,
>
> I haven't heard of any proposal for limiting the amount that can be sent
> from an address. I assume you mean limiting the amount that can be sent in
> a period of time - eg something that would encode that for address A, only
> X bitcoin can be sent from the address in a given day/week/etc, is that
> right? That would actually be a somewhat difficult thing to do in the
> output-based system Bitcoin uses, and would be easier in an account based
> system like Ethereum. The problem is that each output is separate, and
> there's no concept in bitcoin of encumbering outputs together.
>
> What you could do is design a system where coins would be combined in a
> single output, and then encumber that output with a script that allows a
> limited amount of coin be sent to a destination address and requires all
> other bitcoins be returned to sender in a new change output that is also
> timelocked. That way, the new change output can't be used again until the
> timelock expires (eg a week). However, to ensure this wallet works
> properly, any deposit into the wallet would have to also spend the wallet's
> single output, so as to create a new single output at that address. So 3rd
> parties wouldn't be able to arbitrarily send money in (or rather, they
> could, but each output would have its own separate spending limit).
>
> > such kind of restriction would be extremely effective in thwarting the
> most damaging type of theft being the one where all funds are swept in a
> single transaction
>
> It would. However a normal wallet vault basically already has this
> property - a thief can't simply sweep funds instantly, but instead the
> victim will see an initiated transaction and will be able to reverse it
> within a delay time-window. I don't think adding a spending limit would add
> meaningful security to a delayed-send wallet vault like that. But it could
> be used to increase the security of a wallet vault that can be instantly
> spent from - ie if the attacker successfully steals funds, then the victim
> has time to go gather their additional keys and move the remaining
> (unstolen) funds into a new wallet.
>
> OP_CD could potentially be augmented to allow specifying limit amounts for
> each destination, which would allow you to create a wallet like this. It
> would be a bit of an awkward wallet to use tho, since you couldn't receive
> directly into it from a 3rd party and you also couldn't keep separate
> outputs (which is bad for privacy).
>
> An alternate way of doing this that you don't need any new opcodes for
> would be to have a 3rd party service that signs multisig transactions from
> a wallet only up to a limit. The end-user could have additional keys such
> that the 3rd party can't prevent them from accessing that (if they turn
> uncooperative), and the 3rd party would only have a single key so they
> can't steal funds, but the user would sign a transaction with one key, and
> the 3rd party with another as long as the spending limit hasn't been
> reached. This wouldn't have much counterparty risk, but would be a less
> awkward wallet than what I described above - meaning anyone could send
> funds into the wallet without defeating the spending limit, and privacy
> could be kept intact (minus the fact that the 3rd party would know what
> your outputs are).
>
> BT
>
> On Tue, Jul 27, 2021 at 4:18 AM Zac Greenwood <zachgrw at gmail.com> wrote:
>
>> Hi Billy,
>>
>> On the topic of wallet vaults, are there any plans to implement a way to
>> limit the maximum amount to be sent from an address?
>>
>> An example of such limit might be: the maximum amount allowed to send is
>> max(s, p) where s is a number of satoshi and p a percentage of the total
>> available (sendable) amount.
>>
>> A minimum value may be imposed on the percentage to ensure that the
>> address can be emptied within a reasonable number of transactions. The
>> second parameter s allows a minimum permitted amount. (This is necessary
>> because with only the percentage parameter the minimum permitted amount
>> converges to zero, making it impossible to empty the address).
>>
>> There may be other ways too. In my view, such kind of restriction would
>> be extremely effective in thwarting the most damaging type of theft being
>> the one where all funds are swept in a single transaction.
>>
>> Zac
>>
>>
>> On Tue, 27 Jul 2021 at 03:26, Billy Tetrud via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hey James,
>>>
>>> In the examples you mentioned, what I was exploring was a mechanism of
>>> attack by which the attacker could steal user A's key and use that key to
>>> send a transaction with the maximum possible fee. User B would still
>>> receive some funds (probably), but if the fee could be large, the attacker
>>> would either do a lot of damage to user B (griefing) or could make an
>>> agreement with a miner to give back some of the large fee (theft).
>>>
>>> But as for use cases, the proposal mentions a number of use cases
>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md#motivation> and
>>> most overlap with the use cases of op_ctv <https://utxos.org/uses/> (Jeremy
>>> Rubin's website for op_ctv has a lot of good details, most of which are
>>> also relevant to op_cd). The use case I'm most interested in is wallet
>>> vaults. This opcode can be used to create a wallet vault where the user
>>> only needs to use, for example, 1 key to spend funds, but the attacker must
>>> steal 2 or more keys to spend funds. The benefits of a 2 key wallet vault
>>> like this vs a normal 2-of-2 multisig wallet are that not only does an
>>> attacker have to steal both keys (same level of security), but also the
>>> user can lose one key and still recover their funds (better redundancy) and
>>> also that generally the user doesn't need to access their second key - so
>>> that can remain in a much more secure location (which would also probably
>>> make that key harder to steal). The only time the second key only comes
>>> into play if one key is stolen and the attacker attempts to send a
>>> transaction. At that point, the user would go find and use his second key
>>> (along with the first) to send a revoke transaction to prevent the attacker
>>> from stealing their funds. This is somewhat akin to a lightning watchtower
>>> scenario, where your wallet would watch the chain and alert you about an
>>> unexpected transaction, at which point you'd manually do a revoke (vs a
>>> watchtower's automated response). You might be interested in taking a look
>>> at this wallet vault design
>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/op_cdWalletVault1.md>
>>> that uses OP_CD or even my full vision
>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults> of the
>>> wallet vault I want to be able to create.
>>>
>>> With a covenant opcode like this, its possible to create very usable and
>>> accessible but highly secure wallets that can allow normal people to hold
>>> self custody of their keys without fear of loss or theft and without the
>>> hassle of a lot of safe deposit boxes (or other secure seed storage
>>> locations).
>>>
>>> Cheers,
>>> BT
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Jul 26, 2021 at 2:08 PM James MacWhyte <macwhyte at gmail.com>
>>> wrote:
>>>
>>>> Hi Billy!
>>>>
>>>> See above, but to break down that situation a bit further, these are
>>>>> the two situations I can think of:
>>>>>
>>>>> 1. The opcode limits user/group A to send the output to user/group
>>>>> B
>>>>> 2. The opcode limits user A to send from one address they own to
>>>>> another address they own.
>>>>>
>>>>> I'm trying to think of a good use case for this type of opcode. In
>>>> these examples, an attacker who compromises the key for user A can't steal
>>>> the money because it can only be sent to user B. So if the attacker wants
>>>> to steal the funds, they would need to compromise the keys of both user A
>>>> and user B.
>>>>
>>>> But how is that any better than a 2-of-2 multisig? Isn't the end result
>>>> exactly the same?
>>>>
>>>> James
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210728/9ad7f8bf/attachment-0001.html>

2023-06-07 22:57:11

- reply

📅 Original date posted:2021-07-27
📝 Original message:Hi Billy,
On the topic of wallet vaults, are there any plans to implement a way to
limit the maximum amount to be sent from an address?
An example of such limit might be: the maximum amount allowed to send is
max(s, p) where s is a number of satoshi and p a percentage of the total
available (sendable) amount.
A minimum value may be imposed on the percentage to ensure that the address
can be emptied within a reasonable number of transactions. The second
parameter s allows a minimum permitted amount. (This is necessary because
with only the percentage parameter the minimum permitted amount converges
to zero, making it impossible to empty the address).
There may be other ways too. In my view, such kind of restriction would be
extremely effective in thwarting the most damaging type of theft being the
one where all funds are swept in a single transaction.
Zac
On Tue, 27 Jul 2021 at 03:26, Billy Tetrud via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hey James,
>
> In the examples you mentioned, what I was exploring was a mechanism of
> attack by which the attacker could steal user A's key and use that key to
> send a transaction with the maximum possible fee. User B would still
> receive some funds (probably), but if the fee could be large, the attacker
> would either do a lot of damage to user B (griefing) or could make an
> agreement with a miner to give back some of the large fee (theft).
>
> But as for use cases, the proposal mentions a number of use cases
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md#motivation> and
> most overlap with the use cases of op_ctv <https://utxos.org/uses/> (Jeremy
> Rubin's website for op_ctv has a lot of good details, most of which are
> also relevant to op_cd). The use case I'm most interested in is wallet
> vaults. This opcode can be used to create a wallet vault where the user
> only needs to use, for example, 1 key to spend funds, but the attacker must
> steal 2 or more keys to spend funds. The benefits of a 2 key wallet vault
> like this vs a normal 2-of-2 multisig wallet are that not only does an
> attacker have to steal both keys (same level of security), but also the
> user can lose one key and still recover their funds (better redundancy) and
> also that generally the user doesn't need to access their second key - so
> that can remain in a much more secure location (which would also probably
> make that key harder to steal). The only time the second key only comes
> into play if one key is stolen and the attacker attempts to send a
> transaction. At that point, the user would go find and use his second key
> (along with the first) to send a revoke transaction to prevent the attacker
> from stealing their funds. This is somewhat akin to a lightning watchtower
> scenario, where your wallet would watch the chain and alert you about an
> unexpected transaction, at which point you'd manually do a revoke (vs a
> watchtower's automated response). You might be interested in taking a look
> at this wallet vault design
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/op_cdWalletVault1.md>
> that uses OP_CD or even my full vision
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults> of the
> wallet vault I want to be able to create.
>
> With a covenant opcode like this, its possible to create very usable and
> accessible but highly secure wallets that can allow normal people to hold
> self custody of their keys without fear of loss or theft and without the
> hassle of a lot of safe deposit boxes (or other secure seed storage
> locations).
>
> Cheers,
> BT
>
>
>
>
>
> On Mon, Jul 26, 2021 at 2:08 PM James MacWhyte <macwhyte at gmail.com> wrote:
>
>> Hi Billy!
>>
>> See above, but to break down that situation a bit further, these are the
>>> two situations I can think of:
>>>
>>> 1. The opcode limits user/group A to send the output to user/group B
>>> 2. The opcode limits user A to send from one address they own to
>>> another address they own.
>>>
>>> I'm trying to think of a good use case for this type of opcode. In these
>> examples, an attacker who compromises the key for user A can't steal the
>> money because it can only be sent to user B. So if the attacker wants to
>> steal the funds, they would need to compromise the keys of both user A and
>> user B.
>>
>> But how is that any better than a 2-of-2 multisig? Isn't the end result
>> exactly the same?
>>
>> James
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210727/c75c3771/attachment.html>

2023-06-07 22:55:41

- reply

📅 Original date posted:2021-06-30
📝 Original message:Hi Eric,
> A node (software) doesn’t enforce anything. Merchants enforce consensus
rules
… by running a node which they believe to enforce the rules of Bitcoin.
A node definitely enforces consensus rules and defines what is Bitcoin. I
am quite disturbed that this is even being debated here.
Zac
On Wed, 30 Jun 2021 at 11:17, Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Prayank,
>
>
>
> > So majority hash power not following the consensus rules can result in
> chain split?
>
>
>
> Any two people on different rules implies a chain split. That’s presumably
> why rule changes are called forks. There is no actual concept of “the
> rules” just one set of rules or another.
>
>
>
> > Why would majority of miners decide to mine a chain that nobody wants to
> use?
>
>
>
> I don’t presume to know why people prefer one thing over another, or what
> people want to use, nor does economics.
>
>
>
> > What are different things possible in this case based on game theory?
>
>
>
> I’ve seen no actual demonstration of the relevance of game theory to
> Bitcoin. People throw the words around quite a bit, but I can’t give you an
> answer because I have found no evidence of a valid game theoretic model
> applicable to Bitcoin. It’s not a game, it’s a market.
>
>
>
> > Do miners and mining pools participate in discussions before signaling
> for a soft fork begins?
>
>
>
> Who knows, I don’t get invited to round table meetings.
>
>
>
> > Can they still mine something else post activation even if signaling
> readiness for soft fork?
>
>
>
> A person can mine whatever they want. Signaling does not compel a miner to
> enforce. Each block mined is anonymous. But each miner seeing the signals
> of others, unless they are coordinating, would presumably assume that
> others will enforce.
>
>
>
> > Who enforces consensus rules technically in Bitcoin? Full nodes or
> Miners?
>
>
>
> A node (software) doesn’t enforce anything. Merchants enforce consensus
> rules when they reject trading for something that they don’t consider
> money. Every time two people trade both party validates what they receive
> (not what they trade away). Those receiving Bitcoin are economically
> relevant and their power is a function of how much they are doing so.
>
>
>
> Miners censor, which is inconsequential unless enforced. Majority miners
> can enforce censorship by simply not building on any non-censoring blocks.
> This is what soft fork enforcement is.
>
>
>
> > Is soft fork signaling same as voting?
>
>
>
> I don’t see that it needs a label apart from signaling. There are many
> kinds of voting. It would be hard to equate signaling with any of them.
> It’s a public signal that the miner who mined a given block miner intends
> to censor, that’s all.
>
>
>
> > According to my understanding, miners follow the consensus rules
> enforced by full nodes and get (subsidy + fees) for their work.
>
>
>
> Miners mine a chain, which ever one they want. There are many. They earn
> the block reward.
>
>
>
> > Signaling is not voting although lot of people consider it voting
> including some mining pools and exchanges.
>
>
>
> What people consider it is inconsequential. It has clearly defined
> behavior.
>
>
>
> e
>
>
>
> *From:* Prayank <prayank at tutanota.de>
> *Sent:* Sunday, June 27, 2021 5:01 AM
> *To:* eric at voskuil.org
> *Cc:* Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
> *Subject:* Re: [bitcoin-dev] Trinary Version Signaling for softfork
>
>
>
> Hello Eric,
>
>
>
> I have few questions:
>
>
>
> > Without majority hash power support, activation simply means you are off
> on a chain split.
>
>
>
> So majority hash power not following the consensus rules can result in
> chain split? Why would majority of miners decide to mine a chain that
> nobody wants to use? What are different things possible in this case based
> on game theory?
>
>
>
> > And activation without majority hash power certainly does not “ensure”
> this.
>
>
>
> Do miners and mining pools participate in discussions before signaling for
> a soft fork begins? Can they still mine something else post activation even
> if signaling readiness for soft fork?
>
>
>
> > If one wants to enforce a soft fork (or otherwise censor) this is
> accomplished by mining (or paying others to do so). Anyone can mine, so
> everyone gets a say. Mining is trading capital now for more later. If
> enough people want to do that, they can enforce a soft fork. It’s time
> Bitcoiners stop thinking of miners as other people. Anyone can mine, and
> that’s your vote.
>
>
>
> Who enforces consensus rules technically in Bitcoin? Full nodes or Miners?
>
>
>
> Is soft fork signaling same as voting?
>
>
>
> According to my understanding, miners follow the consensus rules enforced
> by full nodes and get (subsidy + fees) for their work. Signaling is not
> voting although lot of people consider it voting including some mining
> pools and exchanges.
>
>
>
>
>
> --
>
> Prayank
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210630/8cf81a27/attachment-0001.html>

2023-06-07 22:55:36

- reply

📅 Original date posted:2021-06-30
📝 Original message:> Majority hash power does have the ability to determine what gets
confirmed.
Miners don’t have the ability to decide whether a block is valid.
Hash power is only recognized as such if it is used for creating a valid
block, i.e., a block that strictly follows all the rules as set by the node
software that transacting users choose to run.
If suddenly 70% of all hash power decided to start mining blocks that are
invalid according to the rules set in the users’ software, then these
invalid blocks will be disregarded. From a user perspective, 70% of all
hash power will seem to have disappeared.
In short, users define what is Bitcoin, not miners. This is fundamental to
being decentralized.
On Tue, 29 Jun 2021 at 23:17, Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Jun 29, 2021, at 12:28, Jorge Timón <jtimon at jtimon.cc> wrote:
>
>
> "Confirmation" isn't needed for softforks.
>
>
> All transactions require confirmation. Splitting does not change this.
>
> Softforks are not compatible without miner enforcement. So soft forking
> without it has essentially the same effect as hard forking, the chain
> splits.
>
> Miners controlling confirmation doesn't mean miners control the rules,
> they never did.
>
>
> Please define “control” because these statements hinge on that word.
> Nobody “controls” the rules of others, nor did anyone claim that to be the
> case. Majority hash power does have the ability to determine what gets
> confirmed. That is the central design principle of proof of work. It takes
> that decision out of the hands of politicians and places it at the feet of
> the market.
>
> Read section 11 of the bitcoin paper "even with a majority of hashrate one
> cannot arbitrarily change rules or forge signatures.
>
>
> Never claimed that was the case. One can run any rules that one desires.
>
> You may say users chosing the rules is "politicial". Isn't miners deciding
> them for users more political?
>
>
> No, it’s economic. The largest investment in mining (including highest
> fees paid to incentivize it) determines censorship resistance.
>
> Whatever you call it, it is still how free software works: users decide
> what to run.
>
>
> A *person* can run whatever software they want. Money requires that others
> agree (same rules), and to be money bitcoin requires confirmation.
>
> It is extremely disappointing to see how few developers seem to ubderstand
> this, or even care about users deciding or miners not deciding the rules.
>
>
> It’s poorly understood because there are so many who should know better
> making very misleading statements.
>
> How can we expect users to understand bitcoin when most developers don't
> seem to understand it?
>
>
> Clearly we cannot.
>
> It is really sad.
>
> On Tue, Jun 29, 2021, 19:17 Eric Voskuil <eric at voskuil.org> wrote:
>
>>
>> > On Jun 29, 2021, at 10:55, Luke Dashjr <luke at dashjr.org> wrote:
>> >
>> > The only alternative to a split in the problematic scenarios are 1)
>> concede
>> > centralised miner control over the network,
>>
>> Miners control confirmation, entirely.
>>
>> This is the nature of bitcoin. And merchants control validation,
>> entirely. Anyone can be a miner or a merchant. Neither is inherently
>> “better” than the other. The largest merchants are likely a handful of
>> exchanges, likely at least as centralized as miners are pooled.
>>
>> Splitting does not change this.
>>
>> > and 2) have inconsistent
>> > enforcement of rules by users who don't agree on what the correct rules
>> are,
>>
>> There are no “correct” rules. Whatever rules one enforces determine what
>> network he chooses to participate in.
>>
>> > again leading to centralised miner control over the network.
>>
>> Leading to? Miners control confirmation, always. Whether that is
>> centralized, just as with merchanting, is up to individuals.
>>
>> > In other words, in this context, accepting a split between disagreeing
>> users
>> > is the ONLY way Bitcoin can possibly continue as a decentralised
>> currency.
>>
>> No, it is not. You are proposing splitting as the method of censorship
>> resistance inherent to Bitcoin. Coordinating this split requires
>> coordinated action. The whole point of bitcoin is coordinate that action
>> based on mining (proof of work). Replacing that with a political process is
>> just a reversion to political money.
>>
>> > Making that split as clean and well-defined as possible not only
>> ensures the
>> > best opportunity for both sides of the disagreement,
>>
>> Trivially accomplished, just change a rule. This isn’t about that. It’s
>> about how one gets others to go along with the new coin, or stay with the
>> old. An entirely political process, which is clearly evident from the
>> campaigns around such attempts.
>>
>> > but also minimises the
>> > risk that the split occurs at all (since the "losing" side needs to
>> concede,
>> > rather than passively continue the disagreement ongoing after the
>> attempted
>> > protocol change).
>>
>> Nobody “needs to” concede once a split has occurred, which is evident in
>> existing splits.
>>
>> e
>>
>> > Luke
>> >
>> >
>> >> On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote:
>> >> At least we are now acknowledging that splitting is what it’s about.
>> That’s
>> >> progress.
>> >>
>> >> e
>> >>
>> >>>> On Jun 29, 2021, at 01:32, Jorge Timón <jtimon at jtimon.cc> wrote:
>> >>>
>> >>>
>> >>> I think the option of "permanent failure because miners veto" should
>> >>> actually be abandoned. No, I don't think we should avoid splits when
>> >>> possible, I don't think we should avoid splits at all costs.
>> >>>
>> >>>> On Sun, Jun 27, 2021, 19:12 Billy Tetrud <billy.tetrud at gmail.com>
>> wrote:
>> >>>> @Luke
>> >>>>
>> >>>>> They can still slow it down.
>> >>>>
>> >>>> Absolutely. However I think that the option of permanent failure is
>> >>>> important. It certainly would be ideal to ensure that enough bitcoin
>> >>>> users support the upgrade *before* releasing it, however
>> realistically
>> >>>> this can never be more than an estimate, and estimates can sometimes
>> be
>> >>>> wildly wrong. It would be unfortunate if miners had a substantially
>> >>>> different estimate of user support than the people putting in the
>> work
>> >>>> to release bitcoin upgrades. Even if upgrades are never released
>> before
>> >>>> it becomes clear that a large supermajority of users want the
>> upgrade,
>> >>>> if miners don't agree with the estimate a harmful chain split could
>> >>>> occur. And I agree with Eric that the goal here is to prevent a chain
>> >>>> split during an upgrade when possible. This includes permanent
>> failure
>> >>>> of an upgrade when there is unexpectedly large miner opposition.
>> >>>>
>> >>>> This of course does not prevent a UASF-style deployment to be done
>> after
>> >>>> an initial failure to deploy occurs. My proposal is essentially a
>> >>>> mechanism to improve upon the speedy-trial idea, allowing for even
>> >>>> speedier releases (than speedy trial) without adding additional risk
>> of
>> >>>> undesired chain splits.
>> >>>>
>> >>>>> [BIP8] already has the trinary state you seem to be describing
>> >>>>
>> >>>> It sounds like you're saying the trinary state of BIP8 is A. Follow
>> the
>> >>>> longest chain, B. Follow the upgrade chain, or C. follow the
>> >>>> non-upgraded chain. I agree. However the trinary state in my
>> proposal is
>> >>>> materially different - it is the signaling itself that is trinary,
>> not
>> >>>> just which chain is being followed. This allows others to know and
>> make
>> >>>> programmatic decisions (in software) based on that signaling. I'm
>> sure
>> >>>> you can agree that does not exist in BIP8.
>> >>>>
>> >>>>> No additional bit is needed, as softforks are coordinated between
>> >>>>> users, NOT miners
>> >>>>
>> >>>> And yet there is miner involvement, as you rightly pointed out.
>> Miners
>> >>>> are needed to set the nVersion in the header. So when you say "no
>> >>>> additional bit is needed", could you please be clearer as to what you
>> >>>> mean? Do you mean that signaling of opposition in a block can be done
>> >>>> without any "additional bit"? Or are you just saying that it is
>> >>>> redundant to consider what miners might be opposing an upgrade?
>> >>>>
>> >>>> @Jorge
>> >>>>
>> >>>>> If different users want different incompatible things... there's no
>> >>>>> way to avoid the split
>> >>>>
>> >>>> I agree. This happened with bcash, and that's fine. It was painful,
>> but
>> >>>> there were a significant amount of users that disagreed, and they
>> have
>> >>>> the chain they want now.
>> >>>>
>> >>>> But we generally all want to avoid a chain split when possible.
>> Because
>> >>>> chain splits have a cost, and that cost can be high, its likely that
>> >>>> many users would rather choose the chain with the most support rather
>> >>>> than choosing the chain with their preferred rules.
>> >>>>
>> >>>> However, the question here is: how do we estimate what fraction of
>> users
>> >>>> wants which rules? We don't have a divining rod to determine with
>> >>>> certainty what users want. We can only make polls of various levels
>> of
>> >>>> inaccuracy. The methods bitcoin has been using is community
>> discussion
>> >>>> and social consensus estimation as well as miner signaling during the
>> >>>> actual deployment period. Neither of these are perfect, but they are
>> >>>> both reasonable enough mechanisms. However, because both of these
>> >>>> mechanisms are very rough estimates of user sentiment, we need to
>> >>>> consider the possibility that sometimes the estimate may be
>> >>>> substantially inaccurate when we design deployment procedures. This
>> >>>> inaccuracy is why we need multiple barriers in place for an upgrade,
>> and
>> >>>> why we need to have higher thresholds of success (require larger
>> >>>> supermajorities in both consensus and miner signaling).
>> >>>>
>> >>>> Developers obviously care about bitcoin and have an incentive
>> (personal
>> >>>> and probably financial) to do it right. And miners have both an
>> >>>> incentive to keep the system healthy, as well as an incentive to
>> mine on
>> >>>> the chain that the economic majority of users is using. But measuring
>> >>>> the consensus of the bitcoin community can be extraordinarily
>> difficult
>> >>>> to do with consistent accuracy, and so I think miner signaling as it
>> has
>> >>>> been used as a second barrier to entry for an upgrade is quite
>> >>>> appropriate.
>> >>>>
>> >>>>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil <eric at voskuil.org>
>> wrote:
>> >>>>> I have not objected to anyone splitting. As I said, a split is
>> always
>> >>>>> possible, and of course has been done on a large scale. It is only
>> the
>> >>>>> misleading statements about inherent soft fork “compatibility” and
>> the
>> >>>>> implication that activation without hash power enforcement does not
>> >>>>> create a split that I object to. People who know better should be
>> >>>>> honest about it.
>> >>>>>
>> >>>>> Far too many people have been led to believe there is some sort of
>> >>>>> activation choice with “ensured” equal outcomes (maybe “slowed
>> down”).
>> >>>>> There is only a choice between creating a split and hash power
>> >>>>> enforcement. Soft forks are rule changes, and thereby incompatible -
>> >>>>> unless enforced by majority hash power.
>> >>>>>
>> >>>>> The statements below are grossly misleading and need to be called
>> out
>> >>>>> as such so that people can actually make this decision you speak of.
>> >>>>> This idea that “users” decide the rules is not the question. The
>> >>>>> question is only how to avoid a split. If one does not care he can
>> >>>>> split at any time, no discussion required.
>> >>>>>
>> >>>>> e
>> >>>>>
>> >>>>>> On Jun 27, 2021, at 01:47, Jorge Timón <jtimon at jtimon.cc> wrote:
>> >>>>>>
>> >>>>>> If different users want different incompatible things (enough on
>> >>>>>> each side), there's no way to avoid the split. We shouldn't try to
>> >>>>>> avoid such a split.
>> >>>>>> Users decide the rules, not miners nor developers.
>> >>>>>>
>> >>>>>>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>> >>>>>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>>>>>
>> >>>>>>> Ultimately there is only one answer to this question. Get majority
>> >>>>>>> hash power support.
>> >>>>>>>
>> >>>>>>> Soft fork enforcement is the same act as any other censorship
>> >>>>>>> enforcement, the difference is only a question of what people
>> want.
>> >>>>>>> Given that there is no collective “we”, those wants differ.
>> Bitcoin
>> >>>>>>> resolves this question of conflicting wants, but it is not a
>> >>>>>>> democracy, it’s a market. One votes by trading.
>> >>>>>>>
>> >>>>>>> If one wants to enforce a soft fork (or otherwise censor) this is
>> >>>>>>> accomplished by mining (or paying others to do so). Anyone can
>> mine,
>> >>>>>>> so everyone gets a say. Mining is trading capital now for more
>> >>>>>>> later. If enough people want to do that, they can enforce a soft
>> >>>>>>> fork. It’s time Bitcoiners stop thinking of miners as other
>> people.
>> >>>>>>> Anyone can mine, and that’s your vote.
>> >>>>>>>
>> >>>>>>> Otherwise, as mentioned below, anyone can start a new coin. But
>> it’s
>> >>>>>>> dishonest to imply that one can do this and all others will surely
>> >>>>>>> follow. This cannot be known, it’s merely a gamble. And it’s one
>> >>>>>>> that has been shown to not always pay off.
>> >>>>>>>
>> >>>>>>> e
>> >>>>>>>
>> >>>>>>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric at voskuil.org>
>> wrote:
>> >>>>>>>>
>> >>>>>>>> For some definitions of “block”.
>> >>>>>>>>
>> >>>>>>>> Without majority hash power support, activation simply means you
>> >>>>>>>> are off on a chain split. Anyone can of course split off from a
>> >>>>>>>> chain by changing a rule (soft or otherwise) at any time, so this
>> >>>>>>>> is a bit of an empty claim.
>> >>>>>>>>
>> >>>>>>>> Nobody can stop a person from splitting. The relevant question is
>> >>>>>>>> how to *prevent* a split. And activation without majority hash
>> >>>>>>>> power certainly does not “ensure” this.
>> >>>>>>>>
>> >>>>>>>> e
>> >>>>>>>>
>> >>>>>>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev
>> >>>>>>>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>>>>>>>
>> >>>>>>>>> BIP8 LOT=True just ensures miners cannot block an upgrade
>> >>>>>>>>> entirely. They can still slow it down.
>> >>>>>>>>>
>> >>>>>>>>> It also already has the trinary state you seem to be describing
>> >>>>>>>>> (although perhaps this could be better documented in the BIP):
>> >>>>>>>>> users who oppose the softfork can and should treat the
>> successful
>> >>>>>>>>> signal (whether MASF or UASF) as invalid, thereby ensuring they
>> do
>> >>>>>>>>> not follow a chain with the rules in force.
>> >>>>>>>>>
>> >>>>>>>>> No additional bit is needed, as softforks are coordinated
>> between
>> >>>>>>>>> users, NOT miners (who have no particular say in them, aside
>> from
>> >>>>>>>>> their role as also being users). The miner involvement is only
>> out
>> >>>>>>>>> of necessity (to set the bit in the header, which users
>> coordinate
>> >>>>>>>>> with) and potentially to accelerate activation by protecting
>> >>>>>>>>> upgrade-lagging users.
>> >>>>>>>>>
>> >>>>>>>>> Luke
>> >>>>>>>>>
>> >>>>>>>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> Given the recent controversy over upgrade mechanisms for the
>> >>>>>>>>>> non-controversial taproot upgrade, I have been thinking about
>> >>>>>>>>>> ways to solve the problems that both sides brought up. In
>> short,
>> >>>>>>>>>> BIP8 LOT=true proponents make the point that lazy miners
>> failing
>> >>>>>>>>>> to upgrade in a timely manner slow down releases of bitcoin
>> >>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=false proponents make the point
>> >>>>>>>>>> that LOT=true can lead to undesirable forks that might cause a
>> >>>>>>>>>> lot of chaos. I believe both points are essentially correct and
>> >>>>>>>>>> have created a proposal
>> >>>>>>>>>> <
>> https://github.com/fresheneesz/bip-trinary-version-signaling/blo
>> >>>>>>>>>> b/master/b ip-trinary-version-bits.md> for soft fork upgrades
>> that
>> >>>>>>>>>> solve both problems.
>> >>>>>>>>>>
>> >>>>>>>>>> The proposal uses trinary version signaling rather than binary
>> >>>>>>>>>> signaling. For any particular prospective soft fork upgrade,
>> this
>> >>>>>>>>>> allows for three signaling states:
>> >>>>>>>>>>
>> >>>>>>>>>> * Actively support the change.
>> >>>>>>>>>> * Actively oppose the change.
>> >>>>>>>>>> * Not signaling (neither support or oppose). This is the
>> default
>> >>>>>>>>>> state.
>> >>>>>>>>>>
>> >>>>>>>>>> Using this additional information, we can release
>> non-contentious
>> >>>>>>>>>> upgrades much quicker (with a much lower percent of miners
>> >>>>>>>>>> signaling support). For contentious upgrades, miners who oppose
>> >>>>>>>>>> the change are incentivized to update their software to a
>> version
>> >>>>>>>>>> that can actively signal opposition to the change. The more
>> >>>>>>>>>> opposition there is, the higher the threshold necessary to lock
>> >>>>>>>>>> in the upgrade. With the parameters I currently recommended in
>> >>>>>>>>>> the proposal, this chart shows how much support signaling would
>> >>>>>>>>>> be necessary given a particular amount of active opposition
>> >>>>>>>>>> signaling:
>> >>>>>>>>>>
>> >>>>>>>>>> [image: thresholdChart.png]
>> >>>>>>>>>> If literally no one signals opposition, a 60% threshold should
>> be
>> >>>>>>>>>> relatively safe because it is a supermajority amount that is
>> >>>>>>>>>> unlikely to change significantly very quickly (ie if 60% of
>> >>>>>>>>>> miners support the change today, its unlikely that less than a
>> >>>>>>>>>> majority of miners would support the change a year or two from
>> >>>>>>>>>> now), and if no one is signaling opposition, chances are that
>> the
>> >>>>>>>>>> vast majority of the other 40% would also eventually signal
>> >>>>>>>>>> support.
>> >>>>>>>>>>
>> >>>>>>>>>> This both gives an incentive for "lazy" miners to upgrade if
>> they
>> >>>>>>>>>> actually oppose the change while at the same time allowing
>> these
>> >>>>>>>>>> lazy miners to remain lazy without slowing down the soft fork
>> >>>>>>>>>> activation much.
>> >>>>>>>>>>
>> >>>>>>>>>> I think now is the right time to discuss new soft fork upgrade
>> >>>>>>>>>> mechanisms, when there are no pressing soft fork upgrades ready
>> >>>>>>>>>> to deploy. Waiting until we need to deploy a soft fork to
>> discuss
>> >>>>>>>>>> this will only delay things and cause contention again like it
>> >>>>>>>>>> did with taproot.
>> >>>>>>>>>>
>> >>>>>>>>>> I'm very curious to know what people think of this mechanism. I
>> >>>>>>>>>> would appreciate any comments here, or written as github issues
>> >>>>>>>>>> on the proposal repo itself.
>> >>>>>>>>>>
>> >>>>>>>>>> Thanks,
>> >>>>>>>>>> BT
>> >>>>>>>>>
>> >>>>>>>>> _______________________________________________
>> >>>>>>>>> bitcoin-dev mailing list
>> >>>>>>>>> bitcoin-dev at lists.linuxfoundation.org
>> >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> bitcoin-dev mailing list
>> >>>>>>> bitcoin-dev at lists.linuxfoundation.org
>> >>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210630/9c14659c/attachment-0001.html>

2023-06-07 22:53:25

- reply

📅 Original date posted:2021-05-16
📝 Original message:Hi Michael,
Your proposal won’t save any energy because it does nothing to decrease the
budget available to mine a block (being the block reward).
Even if it were technically possible to find a way for nodes to somehow
reach consensus on a hash that gets generated after 9 minutes, all it
achieves is that miners will be expending the entire budget given to them
in the form of the block reward within a single minute on average.
Also please realize that the energy expenditure of Bitcoin is a fundamental
part of its design. An attacker has no other option than to expend as much
as half of all the miners together do in order for a sustained 51% attack
to be successful, making such attack uneconomical.
Zac
On Sat, 15 May 2021 at 23:57, Michael Fuhrmann via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> Bitcoin should create blocks every 10 minutes in average. So why do
> miners need to mine the 9 minutes after the last block was found? It's
> not necessary.
>
> Problem: How to prevent "pre-mining" in the 9 minutes time window?
>
> Possible ideas for discussion:
>
> - (maybe most difficult) global network timer sending a salted hash time
> code after 9 minutes. this enables validation by nodes.
>
> - (easy attempt) mining jobs before 9 minutes have a 10 (or 100 or just
> high enough) times higher difficulty. so everyone can mine any time but
> before to 9 minutes are up there will be a too high downside. It is more
> efficient to wait then paying high bills. The bitcoin will get a "puls".
>
>
> I dont think I see all problems behind these ideas but if there is a
> working solution to do so then the energy fud will find it's end. Saving
> energy without loosing rosbustness.
>
>
>
> :)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210516/2c39b6a2/attachment.html>

2023-06-07 22:52:46

- reply

📅 Original date posted:2021-05-18
📝 Original message:Hi ZmnSCPxj,
Please note that I am not suggesting VDFs as a means to save energy, but
solely as a means to make the time between blocks more constant.
Zac
On Tue, 18 May 2021 at 12:42, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Zac,
>
> > VDFs might enable more constant block times, for instance by having a
> two-step PoW:
> >
> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being subject to
> difficulty adjustments similar to the as-is). As per the property of VDFs,
> miners are able show proof of work.
> >
> > 2. Use current PoW mechanism with lower difficulty so finding a block
> takes 1 minute on average, again subject to as-is difficulty adjustments.
> >
> > As a result, variation in block times will be greatly reduced.
>
> As I understand it, another weakness of VDFs is that they are not
> inherently progress-free (their sequential nature prevents that; they are
> inherently progress-requiring).
>
> Thus, a miner which focuses on improving the amount of energy that it can
> pump into the VDF circuitry (by overclocking and freezing the circuitry),
> could potentially get into a winner-takes-all situation, possibly leading
> to even *worse* competition and even *more* energy consumption.
> After all, if you can start mining 0.1s faster than the competition, that
> is a 0.1s advantage where *only you* can mine *in the entire world*.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210518/abd8b876/attachment.html>