Bitcoin Optech newsletter #257 is here:
- summarizes an idea for preventing the pinning of coinjoin transactions
- describes a proposal for speculatively using hoped-for consensus changes
- includes 'Waiting for confirmation #7: Network Resources' from our series about policies for transaction relay and mempool inclusion
- summarizes popular Q&A from Stack Exchange
- Optech Newsletter #257 Recap on Twitter Spaces
https://bitcoinops.org/en/newsletters/2023/06/28/
Greg Sanders posted to the Bitcoin-Dev mailing list a description for how the proposed v3 transaction relay rules could allow creating a coinjoin-style multiparty transaction that wouldn’t be vulnerable to transaction pinning...
https://bitcoinops.org/en/newsletters/2023/06/28/#preventing-coinjoin-pinning-with-v3-transaction-relay
Robin Linus posted to the Bitcoin-Dev mailing list an idea for spending money to a script fragment that can’t be executed for a long time (such as 20 years). If that script fragment is interpreted under current consensus rules, it will allow miners in 20 years to claim all the funds paid to it...
https://bitcoinops.org/en/newsletters/2023/06/28/#speculatively-using-hoped-for-consensus-changes
Waiting for confirmation #7: Network Resources
A previous post discussed protecting node resources, which may be unique to each node and thus sometimes configurable. We also made our case for why it is best to converge on one policy, but what should be part of that policy? This post will discuss the concept of network-wide resources, critical to things like scalability, upgradeability and accessibility of bootstrapping and maintaining a full node...
https://bitcoinops.org/en/newsletters/2023/06/28/#waiting-for-confirmation-7-network-resources
Selected Q&A from Bitcoin Stack Exchange:
- Why do Bitcoin nodes accept blocks that have so many excluded transactions?
- Why does everyone say that soft forks restrict the existing ruleset?
- Why is the default LN channel limit set to 16777215 sats?
- Why does Bitcoin Core use ancestor score instead of just ancestor fee rate to select transactions?
- How does Lightning multipart payments (MPP) protocol define the amounts per part?
https://bitcoinops.org/en/newsletters/2023/06/28/#selected-qa-from-bitcoin-stack-exchange
Bitcoin Optech will be hosting an audio recap discussion of this newsletter with special guests Gloria Zhao, Greg Sanders, and Robin Linus on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions!
https://twitter.com/i/spaces/1OdJrzVXdEwJX
Bitcoin Optech /
npub1hk…a432p
2023-06-28 10:38:20
Author Public Key
npub1hkuk45c6c6h3y0rks0z4wa0wyyud5ru0qy0rn9x4dgnjwrnfy46s5a432pPublished at
2023-06-28 10:38:20Event JSON
{
"id": "089bd8e140363211a86b3ca494a2a23e9c9c47e52b5efabc30ccb67147dd7e3a",
"pubkey": "bdb96ad31ac6af123c7683c55775ee2138da0f8f011e3994d56a27270e692575",
"created_at": 1687948700,
"kind": 1,
"tags": [
[
"t",
"257"
],
[
"t",
"7"
],
[
"t",
"preventing"
],
[
"t",
"speculatively"
],
[
"t",
"waiting"
],
[
"t",
"selected"
]
],
"content": "Bitcoin Optech newsletter #257 is here:\n\n- summarizes an idea for preventing the pinning of coinjoin transactions\n- describes a proposal for speculatively using hoped-for consensus changes\n- includes 'Waiting for confirmation #7: Network Resources' from our series about policies for transaction relay and mempool inclusion\n- summarizes popular Q\u0026A from Stack Exchange\n- Optech Newsletter #257 Recap on Twitter Spaces\nhttps://bitcoinops.org/en/newsletters/2023/06/28/\n\nGreg Sanders posted to the Bitcoin-Dev mailing list a description for how the proposed v3 transaction relay rules could allow creating a coinjoin-style multiparty transaction that wouldn’t be vulnerable to transaction pinning...\nhttps://bitcoinops.org/en/newsletters/2023/06/28/#preventing-coinjoin-pinning-with-v3-transaction-relay\n\nRobin Linus posted to the Bitcoin-Dev mailing list an idea for spending money to a script fragment that can’t be executed for a long time (such as 20 years). If that script fragment is interpreted under current consensus rules, it will allow miners in 20 years to claim all the funds paid to it...\nhttps://bitcoinops.org/en/newsletters/2023/06/28/#speculatively-using-hoped-for-consensus-changes\n\nWaiting for confirmation #7: Network Resources\n\nA previous post discussed protecting node resources, which may be unique to each node and thus sometimes configurable. We also made our case for why it is best to converge on one policy, but what should be part of that policy? This post will discuss the concept of network-wide resources, critical to things like scalability, upgradeability and accessibility of bootstrapping and maintaining a full node...\nhttps://bitcoinops.org/en/newsletters/2023/06/28/#waiting-for-confirmation-7-network-resources\n\nSelected Q\u0026A from Bitcoin Stack Exchange:\n\n- Why do Bitcoin nodes accept blocks that have so many excluded transactions?\n- Why does everyone say that soft forks restrict the existing ruleset?\n- Why is the default LN channel limit set to 16777215 sats?\n- Why does Bitcoin Core use ancestor score instead of just ancestor fee rate to select transactions?\n- How does Lightning multipart payments (MPP) protocol define the amounts per part?\nhttps://bitcoinops.org/en/newsletters/2023/06/28/#selected-qa-from-bitcoin-stack-exchange\n\nBitcoin Optech will be hosting an audio recap discussion of this newsletter with special guests Gloria Zhao, Greg Sanders, and Robin Linus on Twitter Spaces Thursday at 15:00 UTC. Join us to discuss or ask questions!\nhttps://twitter.com/i/spaces/1OdJrzVXdEwJX",
"sig": "194c5477892c905f05cea44801096e5785caee728c2f05de49a799cecb2bd74f9d94bf2b1867b913770720226e0a4e9c48cae84d53f69aee280e505309a09084"
}