Joachim Strömbergson [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-10-12 to 2020-06-07
💬 Posted a total of 10 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:25:17

- reply

📅 Original date posted:2020-06-07
📝 Original message:Hello everyone,
regarding OP_CTV, I am considering the scaling use case, specifically an exchange (or similar) who wants to batch pay to OP_CTV to many users, and I wonder
1) How do you expect the exchange to communicate the proof of the payment to the user wallets such that they are able to construct the follow up transactions and accept the payment. This is UI question. Do you expect exchanges to provide a certain importable file/blob that the wallet will allow you to entry?
2) Who pays the fees and how for the transaction within the structure that OP_CTVed output is committed to? Say there is a tree structure and I want to get the coin out. Someone needs to send log(N) transactions to the chain in order for me to get access to the final UTXO I am interested in. Who can construct such transaction path and what do they need for it and who pays fees on that (which input)?
3) Depending on 2) above, is it not possible for a malicious entity who is among the many users being paid, but who has very small UTXO there relative to others, to construct this middle transaction and use a very small fee rate in order to DoS other participants. Is it even possible for this attacker to create the middle transaction with RBF disabled?
Thank you,
Joachim
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, November 26, 2019 1:50 AM, Jeremy via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Bitcoin Developers,
>
> Pleased to announce refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY (replaces previous OP_SECURETHEBAG BIP). Primarily:
>
> 1) Changed the name to something more fitting and acceptable to the community
> 2) Changed the opcode specification to use the argument off of the stack with a primitive constexpr/literal tracker rather than script lookahead
> 3) Permits future soft-fork updates to loosen or remove "constexpr" restrictions
> 4) More detailed comparison to alternatives in the BIP, and why OP_CHECKTEMPLATEVERIFY should be favored even if a future technique may make it semi-redundant.
>
> Please see:
> BIP:https://github.com/JeremyRubin/bips/blob/ctv/bip-ctv.mediawiki
> Reference Implementation:https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify
>
> I believe this addresses all outstanding feedback on the design of this opcode, unless there are any new concerns with these changes.
>
> I'm also planning to host a review workshop in Q1 2020, most likely in San Francisco. Please fill out the form here https://forms.gle/pkevHNj2pXH9MGee9 if you're interested in participating (even if you can't physically attend).
>
> And as a "but wait, there's more":
>
> 1) RPC functions are under preliminary development, to aid in testing and evaluation of OP_CHECKTEMPLATEVERIFY. The new command `sendmanycompacted` shows one way to use OP_CHECKTEMPLATEVERIFY. See: https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-rpcs. `sendmanycompacted` is still under early design. Standard practices for using OP_CHECKTEMPLATEVERIFY & wallet behaviors may be codified into a separate BIP. This work generalizes even if an alternative strategy is used to achieve the scalability techniques of OP_CHECKTEMPLATEVERIFY.
> 2) Also under development are improvements to the mempool which will, in conjunction with improvements like package relay, help make it safe to lift some of the mempool's restrictions on longchains specifically for OP_CHECKTEMPLATEVERIFY output trees. See: https://github.com/bitcoin/bitcoin/pull/17268This work offers an improvement irrespective of OP_CHECKTEMPLATEVERIFY's fate.
>
> Neither of these are blockers for proceeding with the BIP, as they are ergonomics and usability improvements needed once/if the BIP is activated.
>
> See prior mailing list discussions here:
>
> * https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.html
> * https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/016997.html
>
> Thanks to the many developers who have provided feedback on iterations of this design.
>
> Best,
>
> Jeremy
> --
> [@JeremyRubin](https://twitter.com/JeremyRubin)https://twitter.com/JeremyRubin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200607/a3fd0b6a/attachment-0001.html>

2023-06-07 18:22:31

- reply

📅 Original date posted:2020-01-14
📝 Original message:Hi Robin.
While your motivation seems reasonable, your solution is not. It is not enough that a problem exists. Although the solution must be technically sound for the proposal to be interesting. So I agree it makes sense to consider Bitcoin sidechains, not sure if with PoS consensus or other, but no one yet proposed a viable solution, other than Federation based sidechains. Your proposal explored a single specific PoS sidechain, which to me does not sound interesting. Maybe you can improve it, maybe not.
I also disagree that it is okay if anyone can halt operation of a sidechain with just tiny investment. For me that is critical security flaw of your proposal. By enforcing stakers having to stake per chain you have actually lowered the cost for the attacker to attack each specific chain.
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 13, 2020 10:22 PM, Robin Linus <robinlinus at protonmail.com> wrote:
> Hi Joachim,
>
>>> Regarding Reason #1:
>>> This proposal is less like Bitcoin vs. Altcoins and much more like Ethereum vs. ERC20 tokens, because the derivatives are not in competition with BTC, but depend on it heavily. You support Bitcoin's growth by supporting such a sidechain.
>>> Also, they won't work as separate currencies. For endusers you can abstract away all underlying complexities such that they have to think only in BTC. Exchanges rates can be hidden in TX fees. The sidechain derivatives would be nothing but a means of transfer. The unit of account is still BTC.
>>
>> I can't see any difference and advantage over doing the same with say Litecoin. All you need is to create a special wallet which offers atomic swaps LTC-BTC and its unit of account displayed to user is going to be BTC. All you say will work perfectly with this special LTC wallet. Therefore your idea is as good as any other altcoin. In your case, someone else should indeed be able to create such a wallet in which the unit of account will be the new token, thus emulating the current LTC wallets. So the only difference in Litecoin is that the special wallet with BTC as unit is going to be created after the native one, while in your case it is vice versa.
>>
>> I simply can't see why I'd call this construction of yours a Bitcoin sidechain and any other altcoin not. So I'd call both altcoins.
>
> Let me try to explain where I am coming from: Whenever I want to onboard a not-so-techy friend to Bitcoin by sending him $5 worth of BTC, I don't have many good options. Usually we end up using BlueWallet. It works great. Though it only works so well because it is fully custodial. That is how they solve all the tough LN problems like inbound-capacity of new users, watchtowers and channel backends. Their service is just an Excel table connect to the LN. Unfortunately, that is the best UX we can currently offer to endusers. To me that's unsatisfying. Is that how we want to enter the emerging markets and on-board the next Billion users? I like that BlueWallet gives me the option to run my own LndHub for my friends. Still, does that scale globally? More importantly, do we want that?
>
> Now let's think about the altcoins argument. We want to serve a billion users. Blockchains do scale well to about a couple Million UTXOs, so we require a network of a couple thousand altcoins to serve our users.
> We know how to build a nice LN for all of our altcoins with a star-shaped topology around Bitcoin as the central settlement layer. Atomic swaps FTW. We can abstract away their native currencies. We display to our users only BTC, hide the exchange rates in the TX fees and we're done. That is actually a scalability solution. So why don't we do that?
> The problem here is, that In the long term, the market of PoW blockchains should be a winner-takes-all market, right? So all PoW chains but Bitcoin will eventually die because they're wasting lots of value on their energy. So actually we don't want a couple thousand altcoins wasting resources on pointlessly weak PoW chains. We want a single PoW chain which is as strong as possible.
>
> That's why I'd argue it makes sense to consider a bitcoin-backed PoS and build a LN of thousands of nameless altcoins.
>
> Regarding sidechain security: Burning BTC is almost equivalent to burning energy. You might argue that people won't burn BTC, but it is hard to argue against the strong theoretical security properties of proof-of-burn.
>
> Furthermore, even without burning BTC, using only proof-of-stake I can guarantee doublespending is impossible. There is a very low incentive to risk your BTC's time value. You can only halt a sidechain. And you can halt the sidechain only for as long as you maintain the staking majority. Once you start an attack, you increase the incentive for others to increase their stake. Staking happens in bitcoin's blockchain, which you can't halt. Once the rational stakers regain 51% you've lost a year of time value of your BTC. Note that you can easily enforce stakers having to stake per chain. This guarantees attackers can use their BTC only to attack one chain per year.
> Thus, the security of such a bitcoin-based PoS is stronger then one might suspect.
>
> Thanks again,
> - Robin
>
>>> Regarding Reason #2:
>>> In the "Limitations" section I discuss the cost of halting the chain:
>>>
>>> Time value of locked bitcoins might be too cheap to protect the chain. We can introduce an additional cost and let validators burn bitcoins for every on-chain vote. This is much more robust because there is an ongoing cost for halting the system. Proof-of-burn has recently been formally analysed [16]. The economic implications of burning significant amounts of Bitcoin are questionable. A level of security comparable to Bitcoin requires the system’s BTC burn rate to be equal to Bitcoin’s infaltion rate.
>>>
>>> Also remember, time value of Bitcoins is indeed a value. Even without a proof of burn, I'd consider such sidechains much more secure than those custodial lightning wallets which become more and more popular to circumvent the usability hurdles of the LN.
>>
>> Comparison to other models is not relevant to my claim that such construction is insecure for small sidechains. And for big sidechains the reason #1 prefers any other altcoin. Even if you introduce proof of burn, the final attack cost is small for an attacker in absolute numbers, despite the fact that in the relative numbers the cost is huge.
>>
>>> Thanks again,
>>> - Robin
>>>
>>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>>
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>> On Monday, January 13, 2020 7:06 PM, Joachim Strömbergson <joachimstr at protonmail.com> wrote:
>>>
>>>> While I haven't rejected sidechains entirely yet, this particular proposal seems uninteresting, especially for two reasons.
>>>>
>>>> One – it introduces a new token for each sidechain and suggests atomic swaps to be used for the exchange of the mainchain token with the sidechain token. Such a model seems nonsensical to me because there seems to be excessive number of blockchain projects that can be used similarly just as the sidechain in this proposal. Pick almost any altcoin out there and you can atomic swap it with Bitcoin. The fact that your sidechain is somehow mathematically bound to Bitcoin seems arbitrary because at the end you have a new token and a new issuance model. Therefore this is not extending Bitcoin economy, which is strictly limited by its convergence to zero inflation. This proposal is inflating the supply with a new token, which goes against what many people consider as a pillar of Bitcoin's value proposal. I think if you implement this proposal, you are going not to be considered as a Bitcoin sidechain, but you will be, from certain point of view, indistinguishable from any other altcoin. At the level of my current understanding, the only interesting sidechain model is the [theoretical] one with a two way peg with Bitcoin, preserving the issuance policy of Bitcoin.
>>>>
>>>> Two – the security of the proposed system seems to be very fragile, unless I have missed something. When I think about sidechains, I expect that it should be possible to create a niche chain which is used by few participants while the security of the chain is somehow guaranteed from its bind to the mainchain. If this was not the case, such a niche sidechain could easily be attacked, even if just stalled/censored for a long period time, with just a small [absolute] investment from an attacker, although this investment might be large if taken relatively to the utility of this niche sidechain. So if we speak concretely about your proposal, you assume honest majority of validators. But in your system the validators come from locking of stake on Bitcoin chain by nodes that are interested in a particular sidechain. If you put this model on a niche chain where only few participants are interested in it, it's trivial for an attacker to be stronger [have more Bitcoin to lock] than all legitimate users together. You should only use honest majority assumption where the scope is global, where it is very hard and very expensive to obtain majority.
>>>>
>>>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>>>
>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>> On Sunday, January 12, 2020 6:54 PM, Robin Linus via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I've been working on a sidechain protocol with no trusted third party. You can find the [whitepaper here](http://coins.github.io/coins.pdf).
>>>>>
>>>>> Abstract. Coins is a Bitcoin extension designed for payments at scale. We propose an efficient solution to the double-spending problem using a bitcoin-backed proof-of-stake. Validators vote on sidechain blocks with one-time signatures, forming a record that cannot be changed without destroying their collateral. Every user can become a validator by locking bitcoins. One-time signatures guarantee that validators loose their stake for publishing conflicting histories. Checkpoints can be additionally secured with a bitcoin-backed proof-of-burn. Assuming a rational majority of validators, the sidechain provides safety and liveness. The sidechain’s footprint within bitcoin’s blockchain is minimal. The protocol is a generic consensus mechanism allowing for arbitrary sidechain assets. Spawning multiple, independent instances scales horizontally.
>>>>>
>>>>> Feedback is highly appreciated!
>>>>>
>>>>> Thank you
>>>>>
>>>>> - Robin
>>>>>
>>>>> PS: [Here on Github you can find further research on scalability and usability](https://github.com/coins/coins.github.io).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200114/72b4fc9b/attachment-0001.html>

2023-06-07 18:22:28

- reply

📅 Original date posted:2020-01-13
📝 Original message:Hi Robin,
inline...
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 13, 2020 7:47 PM, Robin Linus <robinlinus at protonmail.com> wrote:
> Hi Joachim,
>
> Thank you for your detailed feedback!
>
> Regarding Reason #1:
> This proposal is less like Bitcoin vs. Altcoins and much more like Ethereum vs. ERC20 tokens, because the derivatives are not in competition with BTC, but depend on it heavily. You support Bitcoin's growth by supporting such a sidechain.
> Also, they won't work as separate currencies. For endusers you can abstract away all underlying complexities such that they have to think only in BTC. Exchanges rates can be hidden in TX fees. The sidechain derivatives would be nothing but a means of transfer. The unit of account is still BTC.
I can't see any difference and advantage over doing the same with say Litecoin. All you need is to create a special wallet which offers atomic swaps LTC-BTC and its unit of account displayed to user is going to be BTC. All you say will work perfectly with this special LTC wallet. Therefore your idea is as good as any other altcoin. In your case, someone else should indeed be able to create such a wallet in which the unit of account will be the new token, thus emulating the current LTC wallets. So the only difference in Litecoin is that the special wallet with BTC as unit is going to be created after the native one, while in your case it is vice versa.
I simply can't see why I'd call this construction of yours a Bitcoin sidechain and any other altcoin not. So I'd call both altcoins.
> Regarding Reason #2:
> In the "Limitations" section I discuss the cost of halting the chain:
>
> Time value of locked bitcoins might be too cheap to protect the chain. We can introduce an additional cost and let validators burn bitcoins for every on-chain vote. This is much more robust because there is an ongoing cost for halting the system. Proof-of-burn has recently been formally analysed [16]. The economic implications of burning significant amounts of Bitcoin are questionable. A level of security comparable to Bitcoin requires the system’s BTC burn rate to be equal to Bitcoin’s infaltion rate.
>
> Also remember, time value of Bitcoins is indeed a value. Even without a proof of burn, I'd consider such sidechains much more secure than those custodial lightning wallets which become more and more popular to circumvent the usability hurdles of the LN.
Comparison to other models is not relevant to my claim that such construction is insecure for small sidechains. And for big sidechains the reason #1 prefers any other altcoin. Even if you introduce proof of burn, the final attack cost is small for an attacker in absolute numbers, despite the fact that in the relative numbers the cost is huge.
> Thanks again,
> - Robin
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, January 13, 2020 7:06 PM, Joachim Strömbergson <joachimstr at protonmail.com> wrote:
>
>> While I haven't rejected sidechains entirely yet, this particular proposal seems uninteresting, especially for two reasons.
>>
>> One – it introduces a new token for each sidechain and suggests atomic swaps to be used for the exchange of the mainchain token with the sidechain token. Such a model seems nonsensical to me because there seems to be excessive number of blockchain projects that can be used similarly just as the sidechain in this proposal. Pick almost any altcoin out there and you can atomic swap it with Bitcoin. The fact that your sidechain is somehow mathematically bound to Bitcoin seems arbitrary because at the end you have a new token and a new issuance model. Therefore this is not extending Bitcoin economy, which is strictly limited by its convergence to zero inflation. This proposal is inflating the supply with a new token, which goes against what many people consider as a pillar of Bitcoin's value proposal. I think if you implement this proposal, you are going not to be considered as a Bitcoin sidechain, but you will be, from certain point of view, indistinguishable from any other altcoin. At the level of my current understanding, the only interesting sidechain model is the [theoretical] one with a two way peg with Bitcoin, preserving the issuance policy of Bitcoin.
>>
>> Two – the security of the proposed system seems to be very fragile, unless I have missed something. When I think about sidechains, I expect that it should be possible to create a niche chain which is used by few participants while the security of the chain is somehow guaranteed from its bind to the mainchain. If this was not the case, such a niche sidechain could easily be attacked, even if just stalled/censored for a long period time, with just a small [absolute] investment from an attacker, although this investment might be large if taken relatively to the utility of this niche sidechain. So if we speak concretely about your proposal, you assume honest majority of validators. But in your system the validators come from locking of stake on Bitcoin chain by nodes that are interested in a particular sidechain. If you put this model on a niche chain where only few participants are interested in it, it's trivial for an attacker to be stronger [have more Bitcoin to lock] than all legitimate users together. You should only use honest majority assumption where the scope is global, where it is very hard and very expensive to obtain majority.
>>
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Sunday, January 12, 2020 6:54 PM, Robin Linus via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi all,
>>>
>>> I've been working on a sidechain protocol with no trusted third party. You can find the [whitepaper here](http://coins.github.io/coins.pdf).
>>>
>>> Abstract. Coins is a Bitcoin extension designed for payments at scale. We propose an efficient solution to the double-spending problem using a bitcoin-backed proof-of-stake. Validators vote on sidechain blocks with one-time signatures, forming a record that cannot be changed without destroying their collateral. Every user can become a validator by locking bitcoins. One-time signatures guarantee that validators loose their stake for publishing conflicting histories. Checkpoints can be additionally secured with a bitcoin-backed proof-of-burn. Assuming a rational majority of validators, the sidechain provides safety and liveness. The sidechain’s footprint within bitcoin’s blockchain is minimal. The protocol is a generic consensus mechanism allowing for arbitrary sidechain assets. Spawning multiple, independent instances scales horizontally.
>>>
>>> Feedback is highly appreciated!
>>>
>>> Thank you
>>>
>>> - Robin
>>>
>>> PS: [Here on Github you can find further research on scalability and usability](https://github.com/coins/coins.github.io).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200113/88c8c246/attachment-0001.html>

2023-06-07 18:22:27

- reply

📅 Original date posted:2020-01-13
📝 Original message:While I haven't rejected sidechains entirely yet, this particular proposal seems uninteresting, especially for two reasons.
One – it introduces a new token for each sidechain and suggests atomic swaps to be used for the exchange of the mainchain token with the sidechain token. Such a model seems nonsensical to me because there seems to be excessive number of blockchain projects that can be used similarly just as the sidechain in this proposal. Pick almost any altcoin out there and you can atomic swap it with Bitcoin. The fact that your sidechain is somehow mathematically bound to Bitcoin seems arbitrary because at the end you have a new token and a new issuance model. Therefore this is not extending Bitcoin economy, which is strictly limited by its convergence to zero inflation. This proposal is inflating the supply with a new token, which goes against what many people consider as a pillar of Bitcoin's value proposal. I think if you implement this proposal, you are going not to be considered as a Bitcoin sidechain, but you will be, from certain point of view, indistinguishable from any other altcoin. At the level of my current understanding, the only interesting sidechain model is the [theoretical] one with a two way peg with Bitcoin, preserving the issuance policy of Bitcoin.
Two – the security of the proposed system seems to be very fragile, unless I have missed something. When I think about sidechains, I expect that it should be possible to create a niche chain which is used by few participants while the security of the chain is somehow guaranteed from its bind to the mainchain. If this was not the case, such a niche sidechain could easily be attacked, even if just stalled/censored for a long period time, with just a small [absolute] investment from an attacker, although this investment might be large if taken relatively to the utility of this niche sidechain. So if we speak concretely about your proposal, you assume honest majority of validators. But in your system the validators come from locking of stake on Bitcoin chain by nodes that are interested in a particular sidechain. If you put this model on a niche chain where only few participants are interested in it, it's trivial for an attacker to be stronger [have more Bitcoin to lock] than all legitimate users together. You should only use honest majority assumption where the scope is global, where it is very hard and very expensive to obtain majority.
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, January 12, 2020 6:54 PM, Robin Linus via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> I've been working on a sidechain protocol with no trusted third party. You can find the [whitepaper here](http://coins.github.io/coins.pdf).
>
> Abstract. Coins is a Bitcoin extension designed for payments at scale. We propose an efficient solution to the double-spending problem using a bitcoin-backed proof-of-stake. Validators vote on sidechain blocks with one-time signatures, forming a record that cannot be changed without destroying their collateral. Every user can become a validator by locking bitcoins. One-time signatures guarantee that validators loose their stake for publishing conflicting histories. Checkpoints can be additionally secured with a bitcoin-backed proof-of-burn. Assuming a rational majority of validators, the sidechain provides safety and liveness. The sidechain’s footprint within bitcoin’s blockchain is minimal. The protocol is a generic consensus mechanism allowing for arbitrary sidechain assets. Spawning multiple, independent instances scales horizontally.
>
> Feedback is highly appreciated!
>
> Thank you
>
> - Robin
>
> PS: [Here on Github you can find further research on scalability and usability](https://github.com/coins/coins.github.io).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200113/8ec899cc/attachment-0001.html>

2023-06-07 18:22:26

- reply

📅 Original date posted:2020-01-13
📝 Original message:> Instead of using sidechains, just use channel factories.
I am not familiar enough with the latest advancements in this field. Is it possible using LN/channel factories to achieve off-line-like participation user experience without previous registration with any kind of gateway provider? For example, can you go online, join the network [somehow instantly], generate address/invoice and then put it somewhere for others to later use it when you are off-line? Can you also participate while being off-line for very long periods of time without relying on third party providers to secure your channels? If not, is using sidechains really equally replaceable with LN/CF constructions?
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 13, 2020 2:33 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning Robin,
>
> > Good morning ZmnSCPxj,
> > Thank you for your detailed feedback! Two topics:
> > Lightning vs Sidechains
> >
> > Why an either-or-solution, if we can connect sidechains via the LN to get the best of both worlds?
> > The LN works exceptionally great under the following conditions:
> >
> > - you're always online
> >
> > - you have BTC to manage your channels' inbound-capacity
> >
> > - you can afford BTC transactions
> > - in your channel is much more than the minimum on-chain TX fees
> > The next Billion users do not fit that category. They are on unreliable cell phone connections and do not have any BTC yet.
> > And the more popular Bitcoin becomes, the fewer people can afford LN channels. Even Eltoo requires your funds to be significantly higher than Bitcoin's TX fees, right?
> > Already today, more and more services like tippin.me, BlueWallet, etc, provide custodial solutions.
> > For small amounts, custody is an acceptable workaround. And I love their usability. Install it and immediately I can send you $0.01. Yet, scaling their approach globally does not lead to desirable outcomes, since we'd be back to trusting banks with their Excel sheets.
> > So let's make their internal ledgers public and trustless, via independent sidechains. Decentralized Blockchains do scale decently up to a couple Million UTXOs. So a couple thousand Sidechains is probably sufficient for a global medium of exchange. Cross-chain communication without requiring cross-chain validation is possible via atomic swaps and through Bitcoin's LN. That scales because it separates chain-validators from swap-validators.
> > Bitcoin's LN acts as the central settlement layer for efficient cross-chain transactions between all sidechains.
> > So Endusers "living" in sidechains instead of directly in the LN has many advantages:
> >
> > - no bitcoin blockspace required for on-boarding new users
> >
> > - no need to lock funds to provide inbound-capacity
> >
> > - no need to stay online or pay watch towers
> >
> > - no need to store channel histories
> >
> > - account balances can be much smaller than BTC TX fees
> > Those are the exact same reasons why BlueWallet built their LndHub. But sidechains can be trustless. Also a generic protocol provides flexibility for sidechain innovations with arbitrary digital assets and consensus rules.
> >
>
> Which is why I brought up multiparticipant offchain updateable cryptocurrency systems.
> The "channel factories" concepts does what you are looking for, except with better trust-minimization than sidechains can achieve.
> Just replace "sidechain" with either Decker-Wattenhofer or Decker-Russell-Osuntokun constructions.
> You can even use the Somsen "statechain" mechanism, which rides a Decker-Wattenhofer/Decker-Russell-Osuntokun construction, though its trust-minimization is only very very slightly better than federated sidechains.
>
> It is helpful to remember that Poon-Dryja, Decker-Wattenhofer, Decker-Russell-Osuntokun, and all other future such constructions, can host any contract that its lower layer can support.
> So if you ride a Poon-Dryja on top of the Bitcoin blockchain, you can host HTLCs inside the Poon-Dryja, since the Bitcoin blockchain can host HTLCs.
> Similarly, if you ride a Decker-Wattenhofer on top of the Bitcoin blockchain, you can host a Poon-Dryja inside the Decker-Wattenhofer, since the Bitcoin blockchain can host Poon-Dryja channels.
> This central insight leads one to conclude that anything you can put onchain, you an generally also put offchain, so why use a chain at all except as an ultimate anchor to reality?
> Poon-Dryja is strictly two-participant, while Decker-Wattenhofer limits the practical number of updates due to its use of decrementing relative timelocks: so you put the payment layer in a bunch of Poon-Dryja channels which support tons of updates each but only two participants per channel, and create a layer that supports changes to the channel topology (where changes to the channel connectivity are expected to be much rarer than payments) and is multiparticipant so you can actually scale.
>
> Instead of using sidechains, just use channel factories.
> You do not need to broadcast the entire internal ledgers of those services, only their customers need to know those internal ledgers, and sign off on the updates of those ledgers.
>
> Regards,
> ZmnSCPxj
>
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:21:32

- reply

📅 Original date posted:2019-11-08
📝 Original message:While I agree on NACKing the proposal as it does not add anything new and fundamentally misunderstands what scaling is (or is not in this case), I disagree with the claim that we do not need to deal with block size issue in the future any more. Segwit increased our possibilities on how to use the space more efficiently, but so far it did not completely. It's yet to be seen if advanced offchain constructions such as channel factories are enough. At this moment to claim that would be very bold and hardly justified.
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, November 8, 2019 2:36 PM, Emil Engler via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> NACK!
> 1. We have Lightning and SegWit so thankfully we do not need to deal with blocksizes anymore really.
> 2. What if a reorg happens? Then it could generate huge problems at the validation.
>
> Correct me if I understood it wrong please.
>
> Greetings,
> Emil Engler
>
> Trevor Groves via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> schrieb am Fr. 8. Nov. 2019 um 15:26:
>
>> Dynamic MaxBlockSize - 3 Byte Solution
>> "DMBS"
>>
>> If
>> (Last TOTAL Block Trans fees) > (AVG (Last 100 Blocks Trans Fees))
>> AND
>> current MaxBlockSize => 0.99 MB
>> AND
>> MaxBlockSize has not changed in 10 Blocks
>> ** see error catch below
>> Then
>> ON (Current Block # + 9) Set MaxBlockSize = (MaxBlockSize x 1.1)
>> ELSE
>> AT (Current Block # + 9) Set MaxBlockSize = (MaxBlockSize / 1.1)
>> ELSEIF
>> (current MaxBlockSize =< 0.99 or current MaxBlockSize > 6553.5 MB)
>> Null (no action taken)
>> **where 9 above represents the ActivateONBlock (software side) Variable
>> -------------
>> We add this 3 Byte Variable Factor to the white space in the Current Block.
>>
>> eg. this 3 byte HEX 19000A
>> the first bit "1" can be 1,2 or 0
>> 1 = increase future block (9 blocks ahead)
>> 2 decrease future block (9 blocks ahead)
>> 0 No Action (rules evaluate to null)
>> **where 9 above represents the ActivateONBlock (software side) Variable
>> --------------
>> The Second bit is a Global Variable "9" represents a countdown to the set value action, placed to synchronize network forward changes in "x" blocks. software lowers value if evaluates to True a second time and so on.
>> ("Count down" if you will)
>> the last 2 bytes represent the globally accepted "MaxBlockSize" Variable, and is distributed within each block moving forward in this rightmost (2 byte) factor. In this case above,
>> The variable portion "000A" (32 Bit value) represents decimal value 10 being 1.0 MB block.
>> the decimal place is Always Assumed, and must be hard coded
>> Because this presents a theoretical Max limit of "FFFF" or 6553.5 MB, We would
>> have to add a last rule "only as a error catch"
>> ** AND IF MaxBlockSize < 6553.5
>> ---
>> Increasing and decreasing
>> On Every Block mined or distributed, the software can run the above rule set, Change the Variable and Distribute the next block " In Synchronized fashion". The above rules when combined evaluate to a YES or NO, This translates to a market reflection of increased system pressure or decreased market pressure. I think we can agree, at peak periods the system chokes itself off with fees and this is always only temporarily. So we can have the block, analyse system demand dynamically, and adjust on a globally agreed rule dynamically by market driven demand.
>> Considering the ruleset above also Decreases the Block ONLY if its greater than 0.99mb this brings size back to a competitive state /and size once market demand pressures subside, yet achieves the smallest market feasible block size while also maintaining all current rule sets.
>> An attacker would have to affect all block fees over the last 16 hours worth of transactions to affect a 10% max block size increase but then only after waiting 1.5 hours, so long as nothing has changed in the last 1.5 hours and only for a limited amount of time. This approach also limits bloat. This safety block window of 9 blocks provides a look forward and look behind value, in turn provides the network time to synchronize.
>> 10 block sync window. This, by design, also limits changes to one change every 3 hours (20 blocks), if there is a market pressure "STATE" occurring.
>> My Question to the community is. Will our current Block accommodate the 3 Byte
>> Variable, Is solving the Scaling issue worth using the 3 Bytes of space?
>> I believe it is.
>> --
>> Software, Will need to Evaluate MaxBlockSize Variable, and ActivateONBlock Variable from the most recent distributed blocks DMBS 3 byte value.
>> Run the rules , get the answer set the now known MaxBlockSize Var and Propegate the "DMBS" value.
>>
>> As capacity limits are breached, I think the majority agree "we need to agree".
>>
>> MaxBlockSize would provide a suitable middle ground and address concerns in a dynamic fashion, without compromising or changing existing security.
>> Examples reflected in the blockchain 19000A rules has evaluates to true, increase expected in 9 blocks.1.0mb increases to 1.1mb
>> if true for 9 more blocks MaxBlockSize Var becomes 18000A.. 17000A..,16000A ..and so on if still true at 10000A var written becomes
>> 00000B when read from left to right, 0-no change, in 0 blocks current " DMBS" value 000B or 1.1MB and stays that way 00000B until MaxBlockSize evaluates to "True" under a market pressure/ relief situation.
>> I hope this makes sense, I would appreciate some feedback.
>> TG
>> _______________________________________________
>> 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/20191108/d63a8de2/attachment-0001.html>

2023-06-07 18:21:23

- reply

📅 Original date posted:2019-10-24
📝 Original message:> Anyway, according to the current considerations I explained in this email, I’d suggest extending BIP-155 with per-link-direction negotiation, but I’m interested in the opinion of the community.
I don't have a strong opinion here but intuitively, it seems to me that per-link variant makes better sense as I currently can't imagine the future requirement for completely opting out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191024/d08d6f66/attachment.html>

2023-06-07 18:21:04

- reply

📅 Original date posted:2019-10-15
📝 Original message:> > [...] First you provide proof of your best block height via coinbase [...]
>
> So I don't think you can use the height in the coinbase for that
> purpose, as it's not possible to validate it without the previous
> headers. That's common for more than just the height.
You can fake it of course, but it means you are spending money for PoW and I can't see viable attack here. You can commit to either lower height than actual or higher height, if you are malicious. If it is lower, then your chain will look weaker with some heuristic based on PoW of the tip and the chain length. So you are not going to do that. It thus seem it only makes sense to commit to higher than actual height. OK, this could convince me to be interested in your chain over others. So let's say the real chain is 600k blocks, you claim 1m blocks, and you prove 1m height block to me. So I can ask you about
1) 2000 headers from the tip down
2) AND another proof of height for the block at 1m-2000.
To be able to provide that you need to have such a chain and you can reuse any real subchain from mainnet. It's still possible that you can deliver that, but not for high difficulty.
Now if time warp attack is blocked, you will have pretty hard time to create such a chain that would look strongest in cumulative work. I don't have actual numbers though, so I can't say this would mitigate everything.
> > [...] to generate much longer chain with superslow timestamp increase (~5 blocks in 1 second) without increasing difficulty (i.e. staying at min. diff.). [...]
>
> In that case, it would take about 7 minutes of block time seconds for
> the next retarget period, every 2016 blocks, and the difficulty would
> adjust. The difficulty would adjust in that case as if 2 weeks of blocks
> had been mined in 7 minutes. For the difficulty to remain the same the
> time between blocks needs to be 10 minutes.
This calculation does not apply under time warp attack. You can fake timestamps of all blocks except for those relevant to the retarget calculation. Those are only the first and the last block in the 2016 block window.

2023-06-07 18:21:04

- reply

📅 Original date posted:2019-10-15
📝 Original message:> > > > [...] to generate much longer chain with superslow timestamp increase (~5 blocks in 1 second) without increasing difficulty (i.e. staying at min. diff.). [...]
> > > > In that case, it would take about 7 minutes of block time seconds for
> > > > the next retarget period, every 2016 blocks, and the difficulty would
> > > > adjust. The difficulty would adjust in that case as if 2 weeks of blocks
> > > > had been mined in 7 minutes. For the difficulty to remain the same the
> > > > time between blocks needs to be 10 minutes.
> > > > This calculation does not apply under time warp attack. You can fake timestamps of all blocks except for those relevant to the retarget calculation. Those are only the first and the last block in the 2016 block window.
>
> This must be in reference to the non-overlapping difficulty calculation
> and off-by-one bug?
Indeed.

2023-06-07 18:21:03

- reply

📅 Original date posted:2019-10-12
📝 Original message:I like the backwards syncing idea. First you provide proof of your best block height via coinbase, then sync backwards. It solves lots of related problems. You know how much you can expect from the given peer.
On different note, one of the problems that I haven't seen mentioned here yet is the timewarp attack. It is relevant to some of the proposed solutions. It should be possible, IIRC, for a malicious node to generate much longer chain with superslow timestamp increase (~5 blocks in 1 second) without increasing difficulty (i.e. staying at min. diff.). This could produce chain that is ~2500 times longer than main chain without having multiple branches.
I also agree that there is no big difference between hash checkpoints and "min. diff. checkpoints".
Joachim
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, October 12, 2019 4:27 PM, Tier Nolan via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Oct 10, 2019 at 5:20 PM Braydon Fuller via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> It would be interesting to have a succinct chainwork proof
>> for all cases. Chainwork being a sum of the total proof-of-work in a
>> chain. Such proofs currently only require a few headers for common cases
>> and the other cases can be identified.
>
> I wonder if a "seed" based system would be useful.
>
> A seed is defined as a header with a very low digest.
>
> When a new peer connects, you ask him to send you the header with the lowest digest on his main chain.
>
> Chains ending at the strongest seeds are kept preferentially when discarding chains.
>
> This requires a way to download chains backwards, which the protocol doesn't support at the moment.
>
> The most chain work chain is overwhelmingly likely to contain the header with the strongest digest.
>
> This means that the honest peer's chain would be kept preferentially.
>
> It also means that a node that is synced to the main chain can easily discard noise from dishonest peers. Before downloading, they could ask the peer to provide a header with at least 1% of the POW of the best header on the main chain starting at the fork point. If they can't then their fork probably has less POW than the main chain.
>
>> A peer could
>> broadcast a few low-work header chains, reconnect and repeat ad nauseam.
>
> I meant connected peer rather than peer. If a peer disconnects and then reconnects as a new peer, then their allocation of bandwidth/RAM resets to zero.
>
> Each peer would be allocated a certain bandwidth per minute for headers as in a token bucket system. New peers would start with empty buckets.
>
> If an active (outgoing) peer is building on a header chain, then that chain is preferentially kept. Essentially, the last chain that each outgoing peer built on may not be discarded.
>
> In retrospect, that works out as the same as throttling peer download, just with a different method for throttling.
>
> In your system, peers who extend the best chain don't get throttled, but the other peers do (but with a gradual transition).
>
> This could be accomplished by adding 80 bytes into the peers bucket if it extends the main chain.
>
>> For example, let's assume a case that the initial chain of headers was
>> dishonest and with low chainwork. The initial block download retrieves
>> the header chain from a single loader peer first. Once recent time is
>> reached, header chains are downloaded from all outgoing peers.
>
> The key it that it must not be possible to prevent a single honest peer from making progress by flooding with other peers and getting the honest peer's chain discarded.
>
> I think parallel downloading would be better than focusing on one peer initially. Otherwise, a dishonest peer can slowly send their headers to prevent moving to parallel mode.
>
> Each connected peer is given a bandwidth and RAM allowance. If a connected peer forks off their own chain before reaching current time, then the fork is just discarded.
>
> The RAM allowance would be sufficient to hold one header per minute since genesis.
>
> The header chains are relatively small (50MB), so it is not unreasonable to expect the honest peer to send the entire chain in one go.
>
> I wonder if there is a formula that gives the minimum chain work required to have a particular chain length by now.
>
> 1 minute per header would mean that the difficulty would increase every adjustment, so it couldn't be maintained without an exponentially rising total chain work.
>
> On Sat, Oct 12, 2019 at 2:41 AM Braydon Fuller via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> - Nodes are vulnerable during the initial sync when joining the
>> network until the minimum chainwork is achieved.
>
> Nodes should stay "headers-only" until they have hit the threshold.
>
> It isn't really any different from a checkpoint anyway.
>
> Download headers until you hit this header is about the same as download headers until you hit this chain work.
>
> It would be different if header chains were downloaded from the final checkpoint backwards.
>
> You would start at a final checkpoint and work backwards. Each ancestor header is committed to by the final checkpoint, so it would not be possible a dishonest peer to fool the node during IBD.
>
>> This is possible if the
>> loader peer is the attacker. To mitigate this there would need to be a
>> minimum chainwork defined based on the current chainwork. However, such
>> could also be used to prevent nodes from joining the network as it's
>> rejecting rather that throttling.
>
> I think mixing two different concepts makes this problem more complex than needed.
>
> It looks like they are aiming for hard-coding
>
> A) "The main chain has at least C chainwork"
> B) "All blocks after A is satisfied have at least X POW"
>
> To me, this is equivalent to a checkpoint, without it having it be called a checkpoint.
>
> The point about excluding checkpoints is that it means that (in theory) two clients can't end up on incompatible forks due to different checkpoints.
>
> The "checkpoint" is replaced by a statement by the dev team that
>
> "There exists at least one valid chain with C chainwork"
>
> which is equivalent to
>
> "The longest valid chain has at least C chainwork"
>
> Two client making those statements can't cause a permanent incompatibility. If they pick a different C, then eventually, once the main chain has more than the larger chain work, they will agree again.
>
> Checkpoints don't automatically heal.
>
> Adding in a minimum POW requirement could break the requirement for that to happen.
>
> Just because B was met on the original main chain, a fork isn't required to meet it.
>
>> - It's technically a consensus change each time the minimum difficulty
>> or best chainwork is updated. It is a similar consensus change as
>> maintaining the last checkpoint, as it's used to prevent forking prior
>> to the last checkpoint.
>
> I agree on the min difficulty being a consensus change.
>
> The minimum chain work is just the devs making a true statement and then using it to optimize things.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191012/d2a9a41c/attachment-0001.html>