[bitcoin-dev] Taproot Fields for PSBT
Hi All,
I would like to propose a BIP which defines new fields for Taproot
support in PSBT.
The full text is below, and the rendered file can be found at
https://github.com/achow101/bips/blob/taproot-psbt/bip-taproot-psbt.mediawiki.
Andrew Chow
---
BIP: taproot-psbt
Layer: Applications
Title: Taproot Fields for PSBT
Author: Andrew Chow
Comments-Summary: No comments yet.
Comments-URI:
https://github.com/bitcoin/bips/wiki/Comments:BIP-taproot-psbt
Status: draft
Type: Standards Track
Created: 2021-06-21
License: BSD-2-Clause
==Introduction==
===Abstract===
This document proposes additional fields for BIP 174 PSBTv0 and BIP 370
PSBTv2 that allow for
BIP 340/341/342 Taproot data to be included in a PSBT of any version.
These will be fields for
signatures and scripts that are relevant to the creation of Taproot inputs.
===Copyright===
This BIP is licensed under the 2-clause BSD license.
===Motivation===
BIPs 340, 341, and 342 specify Taproot which provides a wholly new way
to create and spend Bitcoin outputs.
The existing PSBT fields are unable to support Taproot due to the new
signature algorithm and the method
by which scripts are embedded inside of a Taproot output. Therefore new
fields must be defined to allow
PSBTs to carry the information necessary for signing Taproot inputs.
==Specification==
The new per-input types are defined as follows:
{|
! Name
!
!
! Description
!
! Description
! Versions Requiring Inclusion
! Versions Requiring Exclusion
! Versions Allowing Inclusion
|-
| Taproot Key Spend Signature
| PSBT_IN_TAP_KEY_SIG = 0x13
| None
| No key data '''Why is there no key data for
PSBT_IN_TAP_KEY_SIG'''The signature in a key path spend
corresponds directly with the pubkey provided in the output script. Thus
it is not necessary to provide any metadata that attaches the key path
spend signature to a particular pubkey.
|
| The 64 or 65 byte Schnorr signature for key path spending a Taproot
output.
|
|
| 0, 2
|-
| Taproot Script Spend Signature
| PSBT_IN_TAP_SCRIPT_SIG = 0x14
|
| The 32 byte X-only public key concatenated with the 32 byte hash of
the leaf it is part of.
|
| The 64 or 65 byte Schnorr signature for this pubkey and leaf combination.
|
|
| 0, 2
|-
| Taproot Leaf Script
| PSBT_IN_TAP_LEAF_SCRIPT = 0x15
|
| The control block for this leaf as specified in BIP 341. The control
block contains the merkle tree path to this leaf.
|
[bitcoin-dev] Derivation Paths for Single Key Taproot Scripts
Hi All,
I would like to propose a simple derivation path scheme for keys to be
used in single key Taproot scripts. This is based on BIP 44 so it is
basically identical to BIPs 49 and 84. Like with those BIPs, the actual
value to be used in the purpose level will be set to the BIP number,
once assigned.
Note that the keys derived in this method should be for the Taproot
internal key, which should then be tweaked with the hash of itself as
recommended by BIP 341. The keys derived at this path should not be used
directly as the Taproot output pubkey. Additionally, this BIP does not
specify new version bytes for extended key serialization because, with
the advent of descriptors, I think that is unnecessary. In fact, this
BIP feels somewhat unnecessary to me, but it seems like it will be
needed for now in order to drive adoption and implementation of Taproot
into software and hardware wallets.
The text can be viewed below, with the rendered text available at
https://github.com/achow101/bips/blob/taproot-bip44/bip-taproot-bip44.mediawiki
Andrew Chow
---
BIP: bip-taproot-bip44
Layer: Applications
Title: Derivation scheme for P2TR based accounts
Author: Andrew Chow
Comments-Summary: No comments yet.
Comments-URI:
https://github.com/bitcoin/bips/wiki/Comments:BIP-taproot-bip44
Status: Draft
Type: Informational
Created: 2021-06-22
License: BSD-2-Clause
==Abstract==
This document suggests a derivation scheme for HD wallets whose keys are
involved in single key
P2TR ([[bip-0341.mediawiki|BIP 341]]) outputs as the Taproot internal key.
===Copyright===
This BIP is licensed under the 2-clause BSD license.
==Motivation==
With the usage of single key P2TR transactions, it is useful to have a
common derivation scheme so
that HD wallets that only have a backup of the HD seed can be likely to
recover single key Taproot
outputs. Although there are now solutions which obviate the need for
fixed derivation paths for
specific script types, many software wallets and hardware signers still
use seed backups which
lack derivation path and script information. Thus we largely use the
same approach used in BIPs
[[bip-0049.mediawiki|49]] and [[bip-0084.mediawiki|84]] for ease of
implementation.
==Specifications==
This BIP defines the two needed steps to derive multiple deterministic
addresses based on a
[[bip-0032.mediawiki|BIP 32]] master private key.
===Public key derivation===
To derive a public key from the root account, this BIP uses the same
account-structure as
defined in BIPs [[bip-0044.mediawiki|44]], [[bip-0049.mediawiki|49]],
and [[bip-0084.mediawiki|84]],
but with a different purpose value for the script type.
m / purpose' / coin_type' / account' / change / address_index
For the purpose-path level it uses '.
The rest of the levels are used as defined in BIPs 44, 49, and 84.
===Address derivation===
To derive the output key used in the P2TR script from the derived public
key, we use the method
recommended in
[[bip-0341.mediawiki#constructing-and-spending-taproot-outputs|BIP 341]]:
internal_key: lift_x(derived_key)
32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key)))G
In a transaction, the scripts and witnesses are as defined in
[[bip-0341.mediawiki#specification|BIP 341]]:
witness:
scriptSig: (empty)
scriptPubKey: 1 <32_byte_output_key>
(0x5120{32_byte_output_key})
==Backwards Compatibility==
This BIP is not backwards compatible by design.
An incompatible wallet will not discover these accounts at all and the
user will notice that
something is wrong.
However this BIP uses the same method used in BIPs 44, 49, and 84, so it
should not be difficult
to implement.
==Test vectors==
TBD
==Reference==
* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic
Wallets]]
* [[bip-0049.mediawiki|BIP49 - Derivation scheme for
P2WPKH-nested-in-P2SH based accounts]]
* [[bip-0084.mediawiki|BIP84 - Derivation scheme for P2WPKH based accounts]]
* [[bip-0341.mediawiki|BIP341 - Taproot: SegWit version 1 spending rules]]
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support
Hey Billy No, fee sensitive timelocks weren't discussed at any length in the workshop. The workshops are obviously time limited but if they spur future discussion and drafted proposals (whether they need soft forks or not) outside of the workshops that would be great. This idea was raised in the meeting by Ruben Somsen so maybe Ruben has given them some thought. Making timelocks conditional on the current fee rate seems challenging to me (where is the current network fee rate obtained from and how is it fed into the script?) but I haven't sketched out exactly how they would work. A reminder that the second workshop (on package relay and fee bumping) starts at 19:00 UTC today (30 minutes after I've sent this, there may be a delay before it is published to the mailing list). Thanks Michael On Tue, Jun 22, 2021 at 7:02 PM Billy Tetrud wrote: > > Thanks for the Summary Michael! > > It seems like fee-sensitive timelocks weren't discussed too much in the > workshop, unless I'm missing something. I also don't see any downside to it > discussed (other than that it needs a soft-fork). It seems like that would be > a great way to substantially increase the resilience of the LN to temporary > periods of fee congestion, even potentially long-running periods that last > weeks. It might even help in non-temporary fee market increases by giving > participants extra time to use some fee-bumping technique to close or > restructure their channels to compensate for the elevated fee market. > > On Thu, Jun 17, 2021 at 1:16 PM Michael Folkson via bitcoin-dev > wrote: >> >> The workshop was previously announced by ariard on the bitcoin-dev >> mailing list here: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018841.html >> >> A reminder was posted to the bitcoin-dev mailing list here: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019068.html >> >> The conversation log for the workshop is here: >> https://gist.github.com/ariard/5f28dffe82ddad763b346a2344092ba4 >> >> I’ll summarize what was discussed during the meeting but please refer >> to the L2 zoology repo ariard has set up for background context and >> additional notes: https://github.com/ariard/L2-zoology >> >> General considerations >> >> I think it is worth first reiterating the obvious that there will >> never be perfect security guarantees on network transaction fee rates >> or transaction relay. Network fee rates can in theory go up to >> anything (upper limit of infinity) and will always to some degree be >> inherently unpredictable. In addition transaction acceptance can never >> be guaranteed even if you attempt a direct connection to a miner. At >> the same time L2 protocols (e.g. Lightning and DLCs) elevate >> transaction propagation and inclusion in a time sensitive mined block >> to a security assumption from what used to just be a usability >> assumption (BlueMatt). Within those confines these workshops are >> attempting to strengthen that security assumption knowing that >> guaranteeing it is out of reach. >> >> There are considerations that blocked transaction propagation isn’t >> necessarily a problem for the victim if it is also blocked for the >> attacker. In addition some successful attacks present an opportunity >> for the victim to divert their funds to miner fees (e.g. scorched >> earth) ensuring the attacker doesn’t financially benefit from the >> attack (harding). Personally I would argue neither of these present >> much assurance to the victim. Out of conservatism one should assume >> that the attacker has greater resources than the victim (e.g. a direct >> line to a miner) and knowing a victim’s lost funds went to the miner >> instead of the attacker isn’t of much comfort to the victim (other >> than potentially presenting a disincentive for the attack in the first >> place). This is obviously further complicated if the miner is the >> attacker. In addition any incentive for miners to not mine >> transactions to wait for a potential pay-all-to-fee are troubling >> (t-bast). >> >> New(ish) ideas >> >> RubenSomsen brought up the idea of fee sensitive timelocks, they would >> need a soft fork. ariard briefly discussed the idea of a transaction >> relay overlay network. harding stated his opinion that we should be >> leaning more on miners’ profit incentive rather than attempting to >> normalize mempool policy (e.g. >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html). >> t-bast raised the prospect of mining pools exposing public APIs to >> push them transactions directly. >> >> The impact of changes to Bitcoin Core on L2 protocols >> >> Some changes to Core (e.g. some privacy improvements) can conflict >> with the goal of minimizing transaction propagation times. >> Chris_Stewart_5 raised the idea of a nightly bitcoind build to give L2 >> developers a way to write regression tests against the latest builds >> of bitcoind. He added that L2 devs should write auto
Re: [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support
Sure, feel free to continue on this thread for discussion of fee sensitive timelocks. I'll start a new thread for a summary of today's second workshop. On Tue, Jun 22, 2021 at 7:26 PM Billy Tetrud wrote: > > > where is the current network fee rate obtained from and how is it fed into > > the script? > > It could be obtained as something like the median transaction fee rate over a > window of X blocks. Its something any full node could easily keep track of. > And as long as hour-level or day-level granularity is acceptable, I wouldn't > think there'd be any need to incorporate mempool information (if that were > even possible without introducing new attack vectors). Let me know if this > isn't an appropriate thread to discuss this in. > > On Tue, Jun 22, 2021 at 11:21 AM Michael Folkson > wrote: >> >> Hey Billy >> >> No, fee sensitive timelocks weren't discussed at any length in the >> workshop. The workshops are obviously time limited but if they spur >> future discussion and drafted proposals (whether they need soft forks >> or not) outside of the workshops that would be great. This idea was >> raised in the meeting by Ruben Somsen so maybe Ruben has given them >> some thought. Making timelocks conditional on the current fee rate >> seems challenging to me (where is the current network fee rate >> obtained from and how is it fed into the script?) but I haven't >> sketched out exactly how they would work. >> >> A reminder that the second workshop (on package relay and fee bumping) >> starts at 19:00 UTC today (30 minutes after I've sent this, there may >> be a delay before it is published to the mailing list). >> >> Thanks >> Michael >> >> On Tue, Jun 22, 2021 at 7:02 PM Billy Tetrud wrote: >> > >> > Thanks for the Summary Michael! >> > >> > It seems like fee-sensitive timelocks weren't discussed too much in the >> > workshop, unless I'm missing something. I also don't see any downside to >> > it discussed (other than that it needs a soft-fork). It seems like that >> > would be a great way to substantially increase the resilience of the LN to >> > temporary periods of fee congestion, even potentially long-running periods >> > that last weeks. It might even help in non-temporary fee market increases >> > by giving participants extra time to use some fee-bumping technique to >> > close or restructure their channels to compensate for the elevated fee >> > market. >> > >> > On Thu, Jun 17, 2021 at 1:16 PM Michael Folkson via bitcoin-dev >> > wrote: >> >> >> >> The workshop was previously announced by ariard on the bitcoin-dev >> >> mailing list here: >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018841.html >> >> >> >> A reminder was posted to the bitcoin-dev mailing list here: >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019068.html >> >> >> >> The conversation log for the workshop is here: >> >> https://gist.github.com/ariard/5f28dffe82ddad763b346a2344092ba4 >> >> >> >> I’ll summarize what was discussed during the meeting but please refer >> >> to the L2 zoology repo ariard has set up for background context and >> >> additional notes: https://github.com/ariard/L2-zoology >> >> >> >> General considerations >> >> >> >> I think it is worth first reiterating the obvious that there will >> >> never be perfect security guarantees on network transaction fee rates >> >> or transaction relay. Network fee rates can in theory go up to >> >> anything (upper limit of infinity) and will always to some degree be >> >> inherently unpredictable. In addition transaction acceptance can never >> >> be guaranteed even if you attempt a direct connection to a miner. At >> >> the same time L2 protocols (e.g. Lightning and DLCs) elevate >> >> transaction propagation and inclusion in a time sensitive mined block >> >> to a security assumption from what used to just be a usability >> >> assumption (BlueMatt). Within those confines these workshops are >> >> attempting to strengthen that security assumption knowing that >> >> guaranteeing it is out of reach. >> >> >> >> There are considerations that blocked transaction propagation isn’t >> >> necessarily a problem for the victim if it is also blocked for the >> >> attacker. In addition some successful attacks present an opportunity >> >> for the victim to divert their funds to miner fees (e.g. scorched >> >> earth) ensuring the attacker doesn’t financially benefit from the >> >> attack (harding). Personally I would argue neither of these present >> >> much assurance to the victim. Out of conservatism one should assume >> >> that the attacker has greater resources than the victim (e.g. a direct >> >> line to a miner) and knowing a victim’s lost funds went to the miner >> >> instead of the attacker isn’t of much comfort to the victim (other >> >> than potentially presenting a disincentive for the attack in the first >> >> place). This is obviously further complicated if the miner is the >> >> attacker. In addition
Re: [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support
Thanks for the Summary Michael! It seems like fee-sensitive timelocks weren't discussed too much in the workshop, unless I'm missing something. I also don't see any downside to it discussed (other than that it needs a soft-fork). It seems like that would be a great way to substantially increase the resilience of the LN to temporary periods of fee congestion, even potentially long-running periods that last weeks. It might even help in non-temporary fee market increases by giving participants extra time to use some fee-bumping technique to close or restructure their channels to compensate for the elevated fee market. On Thu, Jun 17, 2021 at 1:16 PM Michael Folkson via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The workshop was previously announced by ariard on the bitcoin-dev > mailing list here: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018841.html > > A reminder was posted to the bitcoin-dev mailing list here: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019068.html > > The conversation log for the workshop is here: > https://gist.github.com/ariard/5f28dffe82ddad763b346a2344092ba4 > > I’ll summarize what was discussed during the meeting but please refer > to the L2 zoology repo ariard has set up for background context and > additional notes: https://github.com/ariard/L2-zoology > > General considerations > > I think it is worth first reiterating the obvious that there will > never be perfect security guarantees on network transaction fee rates > or transaction relay. Network fee rates can in theory go up to > anything (upper limit of infinity) and will always to some degree be > inherently unpredictable. In addition transaction acceptance can never > be guaranteed even if you attempt a direct connection to a miner. At > the same time L2 protocols (e.g. Lightning and DLCs) elevate > transaction propagation and inclusion in a time sensitive mined block > to a security assumption from what used to just be a usability > assumption (BlueMatt). Within those confines these workshops are > attempting to strengthen that security assumption knowing that > guaranteeing it is out of reach. > > There are considerations that blocked transaction propagation isn’t > necessarily a problem for the victim if it is also blocked for the > attacker. In addition some successful attacks present an opportunity > for the victim to divert their funds to miner fees (e.g. scorched > earth) ensuring the attacker doesn’t financially benefit from the > attack (harding). Personally I would argue neither of these present > much assurance to the victim. Out of conservatism one should assume > that the attacker has greater resources than the victim (e.g. a direct > line to a miner) and knowing a victim’s lost funds went to the miner > instead of the attacker isn’t of much comfort to the victim (other > than potentially presenting a disincentive for the attack in the first > place). This is obviously further complicated if the miner is the > attacker. In addition any incentive for miners to not mine > transactions to wait for a potential pay-all-to-fee are troubling > (t-bast). > > New(ish) ideas > > RubenSomsen brought up the idea of fee sensitive timelocks, they would > need a soft fork. ariard briefly discussed the idea of a transaction > relay overlay network. harding stated his opinion that we should be > leaning more on miners’ profit incentive rather than attempting to > normalize mempool policy (e.g. > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html > ). > t-bast raised the prospect of mining pools exposing public APIs to > push them transactions directly. > > The impact of changes to Bitcoin Core on L2 protocols > > Some changes to Core (e.g. some privacy improvements) can conflict > with the goal of minimizing transaction propagation times. > Chris_Stewart_5 raised the idea of a nightly bitcoind build to give L2 > developers a way to write regression tests against the latest builds > of bitcoind. He added that L2 devs should write automated regression > test suites against bitcoind exposed RPC commands. t-bast would like a > bitcoind “evicttx” RPC to remove a transaction from the mempool on > regtest. > > Full RBF > > In advance of the workshop ariard posted to the mailing list a > proposal for full RBF in a future version of Bitcoin Core: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html > > Progress in this direction has been attempted in the past (e.g. > https://github.com/bitcoin/bitcoin/pull/10823) BlueMatt pointed out > that even with full RBF it is trivial to create mempool partitions. As > long as RBF has a fee rate increase minimum an attacker can trivially > split the mempool by broadcasting two conflicting transactions with > the same fee. > > ariard plans to contact businesses (e.g. Lightning onboarding services > relying on zero confirmations) to check that this possible eventual
Re: [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support
> where is the current network fee rate obtained from and how is it fed into the script? It could be obtained as something like the median transaction fee rate over a window of X blocks. Its something any full node could easily keep track of. And as long as hour-level or day-level granularity is acceptable, I wouldn't think there'd be any need to incorporate mempool information (if that were even possible without introducing new attack vectors). Let me know if this isn't an appropriate thread to discuss this in. On Tue, Jun 22, 2021 at 11:21 AM Michael Folkson wrote: > Hey Billy > > No, fee sensitive timelocks weren't discussed at any length in the > workshop. The workshops are obviously time limited but if they spur > future discussion and drafted proposals (whether they need soft forks > or not) outside of the workshops that would be great. This idea was > raised in the meeting by Ruben Somsen so maybe Ruben has given them > some thought. Making timelocks conditional on the current fee rate > seems challenging to me (where is the current network fee rate > obtained from and how is it fed into the script?) but I haven't > sketched out exactly how they would work. > > A reminder that the second workshop (on package relay and fee bumping) > starts at 19:00 UTC today (30 minutes after I've sent this, there may > be a delay before it is published to the mailing list). > > Thanks > Michael > > On Tue, Jun 22, 2021 at 7:02 PM Billy Tetrud > wrote: > > > > Thanks for the Summary Michael! > > > > It seems like fee-sensitive timelocks weren't discussed too much in the > workshop, unless I'm missing something. I also don't see any downside to it > discussed (other than that it needs a soft-fork). It seems like that would > be a great way to substantially increase the resilience of the LN to > temporary periods of fee congestion, even potentially long-running periods > that last weeks. It might even help in non-temporary fee market increases > by giving participants extra time to use some fee-bumping technique to > close or restructure their channels to compensate for the elevated fee > market. > > > > On Thu, Jun 17, 2021 at 1:16 PM Michael Folkson via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> > >> The workshop was previously announced by ariard on the bitcoin-dev > >> mailing list here: > >> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018841.html > >> > >> A reminder was posted to the bitcoin-dev mailing list here: > >> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019068.html > >> > >> The conversation log for the workshop is here: > >> https://gist.github.com/ariard/5f28dffe82ddad763b346a2344092ba4 > >> > >> I’ll summarize what was discussed during the meeting but please refer > >> to the L2 zoology repo ariard has set up for background context and > >> additional notes: https://github.com/ariard/L2-zoology > >> > >> General considerations > >> > >> I think it is worth first reiterating the obvious that there will > >> never be perfect security guarantees on network transaction fee rates > >> or transaction relay. Network fee rates can in theory go up to > >> anything (upper limit of infinity) and will always to some degree be > >> inherently unpredictable. In addition transaction acceptance can never > >> be guaranteed even if you attempt a direct connection to a miner. At > >> the same time L2 protocols (e.g. Lightning and DLCs) elevate > >> transaction propagation and inclusion in a time sensitive mined block > >> to a security assumption from what used to just be a usability > >> assumption (BlueMatt). Within those confines these workshops are > >> attempting to strengthen that security assumption knowing that > >> guaranteeing it is out of reach. > >> > >> There are considerations that blocked transaction propagation isn’t > >> necessarily a problem for the victim if it is also blocked for the > >> attacker. In addition some successful attacks present an opportunity > >> for the victim to divert their funds to miner fees (e.g. scorched > >> earth) ensuring the attacker doesn’t financially benefit from the > >> attack (harding). Personally I would argue neither of these present > >> much assurance to the victim. Out of conservatism one should assume > >> that the attacker has greater resources than the victim (e.g. a direct > >> line to a miner) and knowing a victim’s lost funds went to the miner > >> instead of the attacker isn’t of much comfort to the victim (other > >> than potentially presenting a disincentive for the attack in the first > >> place). This is obviously further complicated if the miner is the > >> attacker. In addition any incentive for miners to not mine > >> transactions to wait for a potential pay-all-to-fee are troubling > >> (t-bast). > >> > >> New(ish) ideas > >> > >> RubenSomsen brought up the idea of fee sensitive timelocks, they would > >> need a soft fork. ariard briefly discussed the idea of a transact
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
I would be interested in seeing some more information about the benefits of this approach vs alternatives up front in this write up. Eg how does the security, cost, usability, and privacy compare to the lightning network, which would be the most likely competitor to this idea. It seems clear that there is more counterparty risk here, so it would probably also be very helpful to compare against traditional custodial solutions as well. If you have specific claims on how this system is better than eg lightning in certain contexts, it would be far easier to evaluate the protocol against those claims, and would also be a lot easier for readers to be motivated to read the whole protocol and do a more full analysis. I agree with others that using email is probably not appropriate for a protocol like this. I would highly recommend making your protocol transport-agnostic, allowing users of your protocol to use any transport they want. On Sat, Jun 19, 2021 at 7:00 PM James Hilliard via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I think you're making a number of assumptions about mining that are > not accurate. > > > First of all, how much chance in finding next block the corrupted miners > have? One percent of all Bitcoin hash powers? Or maximum 5 percent or 10? > The cheaters must come up in dividing that 1.2 Bitcoin between. After all > the risk/reward must fit them. They can not be a big mining pool since > there is no benefit, so they will be small miners with low hash rate. If > they solve the puzzle and broadcast the block, no one in the entire Bitcoin > network has block transactions or seen it before in their mempool! > > You're making the assumption that miners won't build on top of a block > with transactions they have not seen before or transactions that may > contain double spends of unconfirmed inputs, this is not how mining > works, as long as the block passes the consensus rules effectively all > miners will mine on top of it by default, this behavior is fundamental > to how mining currently works and is fairly deeply baked into the > current mining infrastructure. > > > Will they accept this block? In theory it is possible and have 0.01 > percent chance but we can eliminate this small possibilities by a simple > BIP for miners. > > What would this BIP look like? I don't see how this could work in a > decentralized way as you would need another way of reaching consensus > on what defines a valid block. Right now the chance is nearly 100 > percent that a miner will mine on top of the latest valid block, many > pools(most last I checked) will even mine on the next block before > they validate the latest block fully(ie validationless mining) to > reduce their orphan rates. > > > We suppose the miners always control transactions with doc-watchers and > avoid accepting transaction with same UTXO but different output. > > Miners have different mempool policy/rules for what transactions they > themselves mine but all miners must mine on the most work chain of > valid blocks otherwise they risk their own blocks being orphaned, any > miner that does not do this is effectively guaranteed to have their > block orphaned right now. > > > Because of high Bitcoin transaction fee, this guarantee transaction will > take place in next block, even if other transaction which are using the > same UTXO as input existed in mempool. > > When a new transaction is broadcast miners do not immediately start > mining on a block template that includes that transaction, the > template won't even be generated immediately when it enters a miners > mempool in practice, for bandwidth/network efficiency reasons mining > pools batch update the stratum templates/jobs they mine against so > there can be significant latency between the time a transaction is > actually broadcast and hits the miners mempool and the time the miners > actually switch to mining on top it, these batched updates are > essentially like point in time snapshots of the mempool and typically > remain valid(as in the pool will accept shares submitted against that > job as valid) until the bitcoin network finds the next block. I don't > think these batch updates are done more often than every 30 seconds > typically, while often it is on the order of multiple minutes > depending on the pool. > > Regards, > James > > On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev > wrote: > > > > Hi, > > I have a proposal for improve Bitcoin TPS and privacy, here is the post. > > > https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180 > > https://bitcointalk.org/index.php?topic=5344020.0 > > Can you please read it and share your idea about it. > > > > Cheers > > Raymo > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _
