<unnamed>

Public Key

npub1353dy72duzm2f6r6y898723lczd066zs3etnnqa6dfhw3uuzlu9s3afd05

Profile Code

nprofile1qqsg6gkj09x7pd4yapazrjnl9glupxhadpggu4eeswax5mhg7wp07zcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsdcef7u

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 18:25:17 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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:03 UTC

- 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>