npub124…xpaq3

Last Notes

2023-06-07 23:17:35 UTC

- reply

📅 Original date posted:2022-12-07
📝 Original message:TL;DR: Bitcoin Script supports a lot more opcodes than previously assumed. We just have to apply nondeterministic programming, which is a concept from ZKP circuit design.
Good morning Mailinglist,
the Taproot update dropped the restrictions for script sizes, so in theory a TX can now have a script with millions of instructions. While exploring the new possibilities I noticed that we can apply to Bitcoin Script a programming concept from zero-knowledge proofs named nondeterministic programming. Whenever possible, the prover computes the result of an expensive operation and then gives that result to the verifier, who only verifies the correctness of the result, which is often much more efficient than computing it.
For example, we can represent integer division efficiently in Bitcoin Script if the result is given to us in the unlocking script. This is because multiplication with a constant is relatively cheap.
Here is a most simple example implementing integer division by 2. We use that multiplication by 2 is simply OP_DUP OP_ADD, which is cheap.
```
# Integer division by 2 with the help of a hint
# In this example, we divide 119 by 2.
# In the unlocking script the prover provides the result
# as a hint 119//2 = 59, which we verify.
btcdeb "[
119 # Some arbitrary input is on the stack
OP_OVER # Copy the hint to the top of the stack
OP_DUP OP_ADD # Multiply the hint by 2
OP_SUB # Subtract that from the 119
# Now the remainder should be on the stack
# We verify that it is exactly 0 or 1
OP_DUP # Make a copy
OP_0NOTEQUAL # Returns 0 if the input is 0. 1 otherwise.
OP_EQUALVERIFY
# ]" 59 # The hint provided is 59 = 119/2
```
Here you can find more complex examples of opcodes using hints:
https://github.com/coins/bitcoin-scripts/blob/master/composite-opcodes.md#op_2div
Here is even a script for a bitwise rotation of a 32-bit word. It requires about 100 instructions. I think that suggests it might be possible to implement something like sha256 in about 200-300k opcodes.
https://github.com/coins/bitcoin-scripts/blob/master/op_rotate.md
Furthermore, I wondered if it might be possible to implement a ZKP verifier in Bitcoin script. However, that would probably need some hack to make multiplications much cheaper.
Maybe others also find it exciting to explore the new solution spaces enabled by the Taproot update and maybe nondeterministic programming inspires some new ways of thinking about Bitcoin Script.
Have a good day everyone!
Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221208/ee09d2fb/attachment.html>

2023-06-07 23:07:19 UTC

- reply

📅 Original date posted:2022-04-21
📝 Original message:Hi Michael,
Sorry, if my critique of your opinions feels too personal to you. This is nothing personal. As you probably know, one of the most effective attack vectors on Bitcoin is to target the social layer by sabotaging the protocol development[1]. Bike shedding is an easy way to cause a lot of harm.
This is why it is hard to distinguish your radical opinions from an (unintended) attack. So, we cannot simply trust you. In particular because you contribute so much time criticising the activation of CTV, while you also refuse to spend any time working on activating covenants. You just want to stall the activation of covenants indefinitely. An attacker would act the same.
Another red flag is that you are trying to downplay how many reputable community members have already signalled their support for CTV https://utxos.org/signals/ . You keep framing it as if there was only that one crazy guy trying to push an immature and risky consensus change. In fact, it is well reviewed and many people support CTV because it is the most conservative step forwards and it is ready for activation now.
You are alarmed by what you call a "contentious" soft fork while actually you are yourself by far the most vocal opponent of this fork. You are even threatening to cause a chain split while you're also warning others that your chain split would become a big issue. Since we're talking about a soft fork here you're basically saying that you want to make your node reject valid blocks. I doubt that anyone opposes CTV as extremely as you do. In particular because your strongest argument is that CTV might not be ideal for all use cases, which is trivially true for every protocol upgrade. An attacker would act the same.
All in all, it is very hard to distinguish your strong desire to stall the development from an attack. This is why we have to question your motives thoroughly. Again, this is nothing personal. It's just that you are very critical of people who support activation of CTV and thus, you should expect others to be just as critical of your opinions. Isn't that fair?
Regards,
Robin
[1] https://twitter.com/peterktodd/status/1495796670440919056
------- Original Message -------
On Thursday, April 21st, 2022 at 12:04 AM, Michael Folkson <michaelfolkson at protonmail.com> wrote:
> Ok last one. Whatever you say and whatever personal attacks you come up with I'm not responding after this one :)
>
>> Where can I see the use cases you have built out in recent years? Do you have a writeup in which you compare CTV to existing covenant enabling proposals? Do you have a strong reason to favour a different proposal? Have you written any code?
>
> You don't seem to quite understand the asymmetry here. I (and the rest of the community excluding Jeremy) am not a full time CTV developer or full time CTV advocate. There are a number of soft fork proposals I am interested in and attempting to follow in addition to all the work that is going around Taproot etc. But if you/Jeremy want to make a change to the consensus rules the onus is on you to get community review and community consensus. I am not demanding the consensus rules be changed. I am quite happy to wait until there is community consensus over a particular soft fork like there was with Taproot.
>
> I have looked into CTV a considerable number of times now. I have asked 5 of the 6 CTV related questions on Bitcoin StackExchange at the time of writing [1], 2 of which I have attempted to answer. Does this mean I understand as much about Jeremy about CTV? Of course not. But if you believe that soft forks should have community consensus it is up to you/Jeremy to address concerns from curious, relatively informed, skeptical people like me. I am not convinced at the time of writing that CTV is the best tool for the job on any of its intended use cases. On this I don't think even Jeremy is convinced as when asked to compare CTV to alternatives he often just says it is ready and other proposals aren't.
>
>> In contrast, Jeremy has been doing exactly what you are proposing. He wrote the BIP, implemented it, explained use cases in detail, spoke at conferences, organised workshops, and built the Sapio framework for the community to experiment with covenants. He even puts his money where his mouth is and offers a bug bounty for any security flaw in the code.
>
> I'm not entirely sure where you are going with this. That because Jeremy has worked really hard on it for a long time we should activate it without community consensus? I'm sorry that's not how consensus changes work or how they should work. Personally I very much doubt I will ever attempt to change the consensus rules with one of my proposals. I struggle to follow all of the work and the proposals others work on and at least for now believe others are much more qualified than me to design and code up consensus code changes. So again there is an asymmetry if you are going down the comparing Jeremy's goals with my own.
>
>> I think by framing his contributions as "immature" you are disrespecting all the work he put into BIP-119.
>
> I think CTV is an immature proposal given what I've said already about it not being at all clear it is the best tool for any of its intended use cases.
>
>> If you are not willing to do what you are suggesting for years why should anybody else do it? Should the entire community stall progress on covenants until somebody else works on what you think is ideal?
>
> Others are currently working on alternative proposals to CTV (CAT, CSFS, TLUV, Simplicity, arguably APO depending on the use case etc). I haven't asked them to, they already are. As far as I know (they can correct me if wrong) those working on alternative proposals don't support an upcoming activation of CTV. You can try to make this personal all you want and write snide comments if it makes you feel better. But I doubt it is the right approach to getting more review of a soft fork proposal.
>
>> Bike shedding is just as big of an issue as "contentious soft forks". Pointless activation drama is a huge issue of bitcoin protocol development because it is so draining. Some of the most respected devs do not participate in activation politics anymore because it harms their health. That's nuts. If you really want to be of service to the Bitcoin community you should work on what you think is the right path forward and not just criticise Jeremy for progressing with his excellent work.
>
> If you have a magic wand to wave away activation drama and create an activation method that the entire community is happy with I'd love to see it. That magic wand would have got a few months of my life back in 2021 that I'll never get back.
>
> As I said no more responses from me. I am going to go back to a transcript on FROST, one of the many exciting things people are working on that is Taproot related and what I believe the focus should be on at least until there is clear community consensus for a future soft fork.
>
> [1]: https://bitcoin.stackexchange.com/questions/tagged/bip119-checktemplateverify
>
> --
> Michael Folkson
> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
> On Wednesday, April 20th, 2022 at 20:46, Robin Linus via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi Michael,
>>
>> Thank you for your reply. You wrote:
>>
>>> I have a better (and safer) way forward which is to continue to build out use cases of CTV, convince the community it is the best tool for the job (whatever use case(s) that is), compare it to other existing covenant enabling proposals on those use cases and then get to a point where the community is confident that it is activating a proposal(s) that will stand the test of time.
>>
>> Where can I see the use cases you have built out in recent years? Do you have a writeup in which you compare CTV to existing covenant enabling proposals? Do you have a strong reason to favour a different proposal? Have you written any code?
>>
>> I've seen pages of text of you complaining about details of CTV activation but nothing tangible that would prove that you are actually interested in real progress on covenants.
>> In contrast, Jeremy has been doing exactly what you are proposing. He wrote the BIP, implemented it, explained use cases in detail, spoke at conferences, organised workshops, and built the Sapio framework for the community to experiment with covenants. He even puts his money where his mouth is and offers a bug bounty for any security flaw in the code.
>>
>>> You may not like that way forward because it requires a lot of work, a lot of time and a lot of patience.
>>
>> A lot of work, a lot of time and a lot of patience is exactly what Jeremy has been investing for years. I think by framing his contributions as "immature" you are disrespecting all the work he put into BIP-119. If you could point me to essays of you thoughtfully comparing various covenant proposals then I could see your point, but you're only ranting on other people's work which requires no real effort and it doesn't contribute much. If you are not willing to do what you are suggesting for years why should anybody else do it? Should the entire community stall progress on covenants until somebody else works on what you think is ideal?
>> Bike shedding is just as big of an issue as "contentious soft forks". Pointless activation drama is a huge issue of bitcoin protocol development because it is so draining. Some of the most respected devs do not participate in activation politics anymore because it harms their health. That's nuts. If you really want to be of service to the Bitcoin community you should work on what you think is the right path forward and not just criticise Jeremy for progressing with his excellent work.
>>
>> Looking forward to check out your contributions!
>>
>> Regards,
>> Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220421/3d61df58/attachment-0001.html>

2023-06-07 23:07:19 UTC

- reply

📅 Original date posted:2022-04-20
📝 Original message:Hi Michael,
Thank you for your reply. You wrote:
> I have a better (and safer) way forward which is to continue to build out use cases of CTV, convince the community it is the best tool for the job (whatever use case(s) that is), compare it to other existing covenant enabling proposals on those use cases and then get to a point where the community is confident that it is activating a proposal(s) that will stand the test of time.
Where can I see the use cases you have built out in recent years? Do you have a writeup in which you compare CTV to existing covenant enabling proposals? Do you have a strong reason to favour a different proposal? Have you written any code?
I've seen pages of text of you complaining about details of CTV activation but nothing tangible that would prove that you are actually interested in real progress on covenants.
In contrast, Jeremy has been doing exactly what you are proposing. He wrote the BIP, implemented it, explained use cases in detail, spoke at conferences, organised workshops, and built the Sapio framework for the community to experiment with covenants. He even puts his money where his mouth is and offers a bug bounty for any security flaw in the code.
> You may not like that way forward because it requires a lot of work, a lot of time and a lot of patience.
A lot of work, a lot of time and a lot of patience is exactly what Jeremy has been investing for years. I think by framing his contributions as "immature" you are disrespecting all the work he put into BIP-119. If you could point me to essays of you thoughtfully comparing various covenant proposals then I could see your point, but you're only ranting on other people's work which requires no real effort and it doesn't contribute much. If you are not willing to do what you are suggesting for years why should anybody else do it? Should the entire community stall progress on covenants until somebody else works on what you think is ideal?
Bike shedding is just as big of an issue as "contentious soft forks". Pointless activation drama is a huge issue of bitcoin protocol development because it is so draining. Some of the most respected devs do not participate in activation politics anymore because it harms their health. That's nuts. If you really want to be of service to the Bitcoin community you should work on what you think is the right path forward and not just criticise Jeremy for progressing with his excellent work.
Looking forward to check out your contributions!
Regards,
Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220420/eb58de32/attachment.html>

2023-06-07 23:07:17 UTC

- reply

📅 Original date posted:2022-04-20
📝 Original message:Dear Michael,
Firstly, I think it is great that you do share enthusiasm for "vaults, eltoo constructions, payment pools etc". Many people see covenants (or covenant-like features) as one of the most important upgrades currently in the pipe line because it enables so many important use cases and interesting areas of research. In particular vaults and scalability solutions.
However, I have tried to figure out why you invest so much time and effort to oppose CTV. Honestly, the reasons you mentioned here [1] do not make much sense to me and it feels like your attitude is not very constructive as you do not suggest a better way forward.
You wrote "This research and experimentation should mature before considering activation" even though you know that BIP-119 has been finalised more than two years ago. Also the implementation has been reviewed extensively and it has matured for years. So, your framing of "experimentation" and "premature activation" just doesn't reflect the truth here. Even your argument is already more than a year old...
Additionally, you do not address that CTV is intentionally designed to be the most simple and conservative upgrade towards full-featured covenants. CTV only enables a feature that is already possible today using a trusted party. Opposing this conservative approach means you are either in favour of activating a more powerful feature or you do not want covenants at all. It's not clear to me what you want because you just keep opposing CTV without trying to make better suggestions. What do you want?
Your other arguments mostly discuss soft forks in general. This is a different topic though. I think it is not a good idea to mix that up. And claiming that CTV implies continuous soft forks is again dishonest framing. It suggests that covenants were just a random idea of Jeremy even though you know that many reputable bitcoin developers have been researching this topic for years. Truth is Jeremy does a great service to the community by facing this draining activation drama to make trustless covenants possible.
Now, in your most recent email your main concern seems to be a potential chain split. This is again a weak argument against CTV because your concerns apply to any upgrade. Furthermore, you are increasing this risk by opposing CTV without trying to find a common way forward to activate covenants. This doesn't serve bitcoin. I think it would be better for everyone if you would invest your time in trying to formulate a better solution. Covenants are too important to just oppose them because of inaccurate framing or because of opposition to soft forks in general.
Regards,
Robin
[1] https://github.com/JeremyRubin/utxos.org/issues/27
------- Original Message -------
On Wednesday, April 20th, 2022 at 3:24 PM, Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> The client has a Speedy trial release similar to Taproots with parameters proposed to be....
>
> As I've said before I was hoping we'd avoid this exercise. Best case, it wastes the time of people who could be working on all sorts of valuable projects for the ecosystem. Worst case, we take a Russian roulette style gamble with a chain split.
>
> But here's a summary of the basic facts:
>
> The latest Bitcoin Core release candidate (23.0) does not contain any new soft fork code, either CTV code or any new activation code. Running Bitcoin Core 23.0 out the box will not signal for any new soft fork and will not enforce any new soft fork rules (CTV or otherwise). Of course it will continue to enforce Taproot rules as Taproot activated last year.
>
> There are a number of individuals who have stated opposition to attempting to activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> Most of those individuals haven't logged their opposition on Jeremy's site:
> https://utxos.org/signals/
>
> Hence their views haven't been included or discussed in Jeremy's latest blog post.
>
> Chain split risk
>
> I can't predict how many full nodes and miners will run Jeremy's client attempting to activate CTV. One would expect that many will continue to run versions of Bitcoin Core that will not enforce CTV rules and will not activate it. But whether Jeremy's client will be a majority, significant minority, insignificant minority of full nodes and miners would be speculation on my part. (Personally I highly doubt those running Jeremy's client will be a majority which leaves a significant minority and insignificant minority as the most likely options).
>
> Jeremy's client is intending to use Speedy Trial presumably with similar parameters to that used for Taproot. That would mean seeking 90 percent of miners to signal for this CTV soft fork activation attempt.
>
> Assuming 90 percent of miners don't signal for it in one of the Speedy Trial windows then the activation attempt will have failed and it will be back in Jeremy's court whether he tries again with a different activation attempt.
>
> Assuming 90 percent of miners do signal for it (unlikely in my opinion but presumably still a possibility) then the CTV soft fork could activate unless full nodes resist it. This resistance would most likely be in the form of a UASF style client which rejects blocks that apply the CTV rules and/or includes transactions that don't meet the CTV rules post activation. We would now be in chain split territory with two different assets and blockchains like we had with BTC and BCH.
>
> If I oppose this activation attempt and the associated chain split risk what should I do?
>
> Firstly, you can register your opposition to this soft fork activation attempt on Jeremy's site: https://utxos.org/signals/
>
> It seems Jeremy will continue this activation attempt regardless but it will be useful for others to see clearly that this a contentious soft fork activation attempt and act accordingly. So far only 3 individuals' opposition is registered on his site.
>
> Secondly, if it is looking like 90 percent (or whatever percentage Jeremy uses) of miners are going to signal for a CTV soft fork then you can consider joining a UASF style effort to resist the soft fork activation attempt. I will certainly seek to participate and will continue to inform this list of efforts in this direction.
>
> The saddest thing is that if Jeremy's soft fork activation attempt causes the uncertainty, confusion and disruption I fear it could it will make future soft forks that do have community consensus orders of magnitude harder to pull off. There are a number of soft fork proposals that I'm personally excited about (enabling covenants, eltoo, Simplicity, CISA etc) that long term we might get with a sensible approach to only activating soft forks that have community consensus. But the more uncertainty, confusion and disruption we create over contentious soft forks the more dangerous any soft fork of any form will appear. The primary focus will need to be resisting soft forks that don't have community consensus and ensuring Bitcoin doesn't splinter into a large number of different assets/blockchains with different combinations of soft forks active.
>
> So if you oppose this soft fork activation attempt please voice your opposition, run full node software that doesn't include CTV and CTV activation code such as Bitcoin Core and if/when necessary and available run full node software that proactively rejects application of the CTV rules.
>
> --
> Michael Folkson
> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
> On Tuesday, April 19th, 2022 at 18:31, Jeremy Rubin via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Devs,
>>
>> In advance of the CTV meeting today, I wanted to share what my next step is in advocating for CTV, as well as 7 theses for why I believe it to be the right course of action to take at this time.
>>
>> Please see the post at https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/.
>>
>> As always, open to hear any and all feedback,
>>
>> Jeremy
>>
>> archived at: https://web.archive.org/web/20220419172825/https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220420/9bfab9c6/attachment-0001.html>

2023-06-07 18:24:34 UTC

- reply

📅 Original date posted:2020-05-11
📝 Original message:Hi,
not sure if headergolf was mentioned yet. It's about very similar ideas: https://github.com/alecalve/headergolf
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, May 8, 2020 2:31 PM, Will Clark via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello list,
>
> I would like to propose a compressed block header scheme for IBD and block announcements. This proposal is derivative of previous proposals found on this list (see links in spec below) with some modifications and clarifications.
>
> The below specification (also found at https://github.com/willcl-ark/compressed-block-headers/blob/v1.0/compressed-block-headers.adoc ) details the compression recommended along with the generated bandwidth savings in the best-case scenario.
>
> I look forward to any feedback anyone has to offer on the specification itself, as well as any additions or objections to the motivation.
>
> Cheers,
> Will
>
> = Compressed block headers
> Will Clark will8clark at gmail.com
> v1.0, May 2020:
> :toc: preamble
> :toclevels: 4
>
> This work is a derivation of these mailing list posts:
>
> 1. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014876.html[bitcoin-dev: "Compressed" headers stream - 2017] (with resurrection https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015385.html[here])
> 2. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015851.html[bitcoin-dev: Optimized Header Sync]
>
> '''
>
> == Motivation
>
> Block headers as exchanged by nodes over the p2p network are currently 81 bytes each.
>
> For low bandwidth nodes who are doing a headers-only sync, reducing the size of the headers can provide a significant bandwidth saving. Also, nodes can support more header-only peers for IBD and protection against eclipse attacks if header bandwidth is reduced.
>
> === Background
>
> Currently headers are sent over the p2p network as a vector of `block_headers`, which are composed of the following sized fields:
>
> [cols="<,>"]
>
>
> |===
> |Field |Size
>
> |Version |4 bytes
> |Previous block hash |32 bytes
> |Merkle root hash |32 bytes
> |Time |4 bytes
> |nBits |4 bytes
> |nonce |4 bytes
> |txn_count |1 byte
> |Total |81 bytes
> |===
>
> Some fields can be removed completely, others can be compressed under certain conditions.
>
> == Proposed specification
>
> === block_header2 data type
>
> The following table illustrates the proposed `block_header2` data type specification.
>
> [cols="<,>,>"]
> |===
> |Field |Size |Compressed
>
> |Bitfield |1 byte | 1 byte
> |Version |4 bytes |0 \| 4 bytes
> |Previous block hash |32 bytes |0 \| 32 bytes
> |Merkle root hash |32 bytes |32 bytes
> |Time |4 bytes |2 \| 4 bytes
> |nBits |4 bytes |0 \| 4 bytes
> |nonce |4 bytes |4 bytes
> |Total |81 bytes |range: 39 - 81 bytes
> |===
>
> This compression results in a maximum reduction from an 81 byte header to best-case 39 byte header. With 629,474 blocks in the current blockchain, a continuous header sync from genesis (requiring a single full 81 byte header followed by only compressed `block_header2`) has been tested to have its required bandwidth reduced from 50.98MB down to 25.86MB, a saving of 49%.
>
> ==== Bitfield
>
> To make parsing of header messages easier and further increase header compression, a single byte bitfield was suggested by gmaxwell footnote:[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015397.html]. We propose the following amended bitfield meanings (bits re-ordered to match `headers2` field order):
>
> [cols="<,<"]
> |===
> |Bit |Meaning + field size to read
>
> |0 +
> 1 +
> 2 |version: same as the last distinct value 1st ... 7th (0 byte field) or a new 32bit distinct value (4 byte field).
> |3 |prev_block_hash: is omitted (0 byte field) or included (32 byte field)
> |4 |timestamp: as small offset (2 byte field) or full (4 byte field).
> |5 |nbits: same as last header (0 byte field) or new (4 byte field).
> |6 |possibly to signal "more headers follow" to make the encoding self-delimiting.
> |7 |currently undefined
> |===
>
> This bitfield adds 1 byte for every block in the chain, for a current total increase of 629,474B.
>
> ==== Version
>
> In most cases the Version field will be identical to one referenced in one of the previous 7 unique versions, as indicated by bits 0,1,2 of the Bitfield.
>
> To block 629,474 there were 616,137 blocks whose version was in the previous 7 distinct versions, and only 13,338 blocks whose version was not, this includes any version bit manipulation done via overt ASIC boost.
>
> [cols=">,>,>,>"]
> |===
> |Genesis to block |Current (B) |Compressed (B) |Saving (%)
>
> |629,474 |2,517,896 |53,352 |98
> |===
>
> ==== Previous block hash
>
> The previous block hash will always be the
> `SHA256(SHA256(<previous_header>))` so is redundant, presuming you have the previous header in the chain.
>
> [cols=">,>,>,>"]
> |===
> |Genesis to block |Current (B) |Compressed (B) |Saving (%)
>
> |629,474 |20,143,168 |0 |100
> |===
>
> ==== Time
>
> The timestamp (in seconds) is consensus bound, based both on the time in the previous
> header: `MAX_FUTURE_BLOCK_TIME = 2 * 60 * 60 = 7200`, and being greater than the `MedianTimePast` of the previous 11 blocks. Therefore this can be safely represented as an offset from the previous headers' timestamp using a 2 byte `signed short int`.
>
> [cols=">,>,>,>"]
> |===
> |Genesis to block |Current (B) |Compressed (B) |Saving (%)
>
> |629,474 |2,517,896 |1,258,952 |50
> |===
>
> ==== nBits
>
> nBits currently changes once every 2016 blocks. It could be entirely calculated by the client from the timestamps of the previous 2015 blocks footnote:[2015 blocks are used in the adjustment calculation due to an off-by-one error: https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772"].
>
> To simplify 'light' client implementations which would otherwise require consensus-valid calculation of the adjustments, we propose to transmit this according to the <<Bitfield>> specification above.
>
> To block 629,474 there have been 298 nBits adjustments (vs an expected 311 -- there was none before block 32,256).
>
> [cols=">,>,>,>"]
> |===
> |Genesis to block |Current (B) |Compressed (B) |Saving (%)
>
> |629,474 |2,517,896 |1,196 |99.6
> |===
>
> ==== txn_count
>
> txn_count is included to make parsing of these messages compatible with parsing of `block` messages footnote:[https://bitcoin.stackexchange.com/questions/2104/why-is-the-block-header-txn-count-field-always-zero]. Therefore this field and its associated byte can be removed for transmission of compact headers.
>
> [cols=">,>,>,>"]
> |===
> |Genesis to block |Current (B) |Compressed (B) |Saving (%)
>
> |629,474 |629,474 |0 |100
> |===
>
> === Service Bit
>
> A new service bit would be required so that the nodes can advertise their ability to supply compact headers.
>
> === P2P Messages
>
> Three new messages would be used by nodes that enable compact block header support, two query messages: `getheaders2` and `sendheaders2` and one response: `headers2`.
>
> ==== `getheaders2` -- Requesting compact headers
>
> The new p2p message required to request compact block headers would require the same fields as the current `getheaders` message:
>
> [cols=">,<,<,<"]
> |===
> |Field Size |Description |Data type |Comments
>
> |4 |version |uint32_t |the protocol version
> |1+ |hash count |var_int |number of block locator hash entries
> |32+ |block locator hashes |char[32] |block locator object; newest back to genesis block (dense to start, but then sparse)
> |32 |hash_stop |char[32] |hash of the last desired block header; set to zero to get as many blocks as possible (2000)
> |===
>
> ==== `sendheaders2` -- Request compact header announcements
>
> Since https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki[BIP-130], nodes have been able to request to receive new headers directly in `headers` messages, rather than via an `inv` of the new block hash and subsequent `getheader` request and `headers` response (followed by a final `getdata` to get the tip block itself, if desired). This is requested by transmitting an empty `sendheaders` message after the version handshake is complete.]
>
> Upon receipt of this message, the node is permitted, but not required, to preemptively announce new headers with the `headers2` message (instead of `inv`). Preemptive header announcement is supported by the protocol version ≥ 70012 | Bitcoin Core version ≥ 0.12.0.
>
> For the motivational use-case it makes sense to also update this mechanism to support sending header updates using compact headers using a new message.
>
> ==== `headers2` -- Receiving compact headers
>
> A `headers2` message is returned in response to `getheaders2` or at new header announcement following a `sendheaders2` request. It contains both `length` and `headers` fields. The `headers` field contains a variable length vector of `block_header2`:
>
> |===
> |Field Size |Description |Data type |Comments
>
> |1+ |length |var_int |Length of `headers`
> |39-81x? |headers |block_header2[] |Compressed block headers in <<block_header2 data type>> format
> |===
>
> === Implementation
>
> - The first header in the first `block_header2[]` vector to a newly-connected client MUST contain the full nBits`,`timestamp`,`version`and`prev_block_hash`fields, along with a correctly populated`bitfield` byte.
>
> - Subsequent headers in a contiguous vector SHOULD follow the compressed <<block_header2 data type>> format.
>
> - Subsequent compressed headers supplied to an already-connected client (requesting compressed headers), SHOULD follow the compressed <<block_header2 data type>> format.
>
>
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:22:32 UTC

- reply

📅 Original date posted:2020-01-14
📝 Original message:Good morning everybody!
Thanks again for your detailed feedback.
Maybe you're right and my solution is just crap :) So back to the drafting table!
It seems to be a good idea to separate problem definition and solution. Here I tried to nail down LN's usability issue:
https://github.com/coins/coins.github.io/blob/master/notes/lightning-network.md
Would be great to hear your thoughts on that. Do we generally agree that Bitcoin has to work well on mobiles? Where do your opinions differ?
If you are open to sidechains in general, we are discussing mostly consensus mechanisms.
The consensus mechanism of custodial LN services is some trusted server somewhere, with a single hot key and no public auditability.
That's state of the art LN experience on mobile. And it's worse than fiat banks.
Yes, Liquid's trusted federation is much better than such custodial services. Still, how does it scale globally? Lots of trusted federations?
Probably, we all favor a more trust-minimized sidechain consensus mechanism.
Most likely, it is impossible to produce decentralized consensus without consuming an external resource.
Furthermore, decentralized consensus requires an honest majority. Thus, fragmenting the consumption of the available resources over multiple chains weakens every chain proportionally. Therefore, whatever consensus mechanism we choose, the number of sidechains should be as small as possible. By implication, sidechains have to be as large as possible.
The market simply has no capacity to secure thousands of chains, if they don't have millions of users each.
Consensus resource consumption is a winner takes all market, until a sidechain becomes so full, that a further chain becomes profitable. Secure and profitable sidechains require strong network effects. Otherwise, there's a downwards spiral of no users which leads to no stakers and vice versa. Needless sidechains die off quickly.
Regarding proof-of-burn: In theory, you could build a pure proof-of-burn sidechain which is literally as secure as Bitcoin's consensus. If you burn about 12.5 BTC for every sidechain block, then the sidechain is exactly as costly to produce as Bitcoins blockchain. So regardless of the practicality, the theoretical security argument of PoB is very sound, or am I missing something?
If it is, then can't we build some PoS / PoB construction to secure sidechains?
Regarding 2-way peg and "a new asset for every chain is bad". Let's look at my real world bank account. There are no real dollars in it. No legal tender.
It's just my bank's derivative of the Dollar, representing their promise to give me my Dollars whenever I want.
Note that my bank's altcoin is not pegged 1:1 to the legal tender issued by the central bank. In the background they're balancing their books.
All that is hidden from me as a customer. They know, I just want to facilitate payments in USD. As a customer I do not care about their underlying financial instruments. That's why I'd assume, that sidechain assets can be used as an instrument of BTC value transfer, without a 1:1-peg to BTC.
The only thing that really matters, is liquidity for atomic swaps to pay LN invoices denominated in BTC. That again, is a matter of network effects of a sidechain.
Thanks again,
-Robin
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, January 14, 2020 4:26 PM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> As well I would like to point out that in order to receive funds, something has to be online to get the message that receives the data.
> In the blockchain layer this is diffused among all fullnodes.
>
> At the Lightning layer, your direct peer could hold off on failing an incoming payment while you are offline.
> Instead, it could simply stall until the outgoing HTLC would reach its timelock anyway.
> Then you can come online and then the peer can send the HTLC to you and you can claim it.
> This remains noncustodial as the direct peer cannot steal the funds from you.
> I believe there was some discussion regarding this on lightning-dev in the past few months.
> However, it does require that the peer know that you are the final recipient (if not, it would be unable to fail the HTLC as quickly as possible), thus a privacy leak.
>
> In any case some node has to be online in order for anyone to receive funds, whether onchain or not: it is simply that a widespread blcokchain is very very likely to have some online node capable of storing the payment until you can come online to process it.
> What you propose splits up the fullnodes into many tiny sidechains, such that a sidechain may get stalled and you would be unable to receive a payment anyway while you are offline, because there are far fewer nodes per sidechain in order for such mass sidechains to start beating the raw scaling Lightning brings.
>
> Regards,
> ZmnSCPxj
>
> > 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 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 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 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 thewhitepaper here.
> > > > > > > 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.

2023-06-07 18:22:30 UTC

- reply

📅 Original date posted:2020-01-14
📝 Original message:Good morning ZmnSCPxj,
> > > because all users must process all transactions within the blockchain
> >
> > Reality shows, that's wrong. Bitcoin's security doesn't require verification to scale quadratically with users. Since the whitepaper, Satoshi was explicit about that phenomena. We can discuss nuances, yet it's overall plausible and empirically it's true: Only a tiny minority of users ever verifies the blockchain, still bitcoin works perfectly well. An honest economic majority is sufficient.
> > Yes, if you can, run your own node. Let's lower the barriers and let's help others to run their own nodes. Let's keep the blocks small and bitcoin's UTXOs set verifiable with consumer hardware. That's the core of decentralized security.
> > But let's face it: most people on this planet will never run a bitcoin full node. And it is not required.
> > Bitcoin-backed PoS-sidechains scale in terms of verification and storage just like any other blockchain. However, security is strictly better because double-spends are impossible. A single honest validating user guarantees that attackers cannot do more harm than halting a sidechain. Thus, endusers won't have to validate all of each others' transactions at all.
> > For most endusers such sidechains' security is strictly superior to today's LN experience.
> > Let's face it: The most popular LN apps are fully custodial.
> > They have to be custodial because there is no way to make LN usable for regular users on unreliable phones.
> > Any payment channel which requires you to be always online excludes 99% of the world's population.
> > Any payment channel which potentially requires you to be able to pay high on-chain fees excludes most people, too. And on-chain fees keep rising.
> > Thus, no matter what Channel Factory constructions we build, they will not match most people's requirements. We will keep falling back to custodial solutions.
> > Excel tables connected to the LN. The LN is awesome as a settlement layer. In particular for anything like bitcoin banks that have been discussed since the beginning.
> > But why 1000 trusted Excel tables if we can have 1000 trustless sidechains?
>
> First:
>
> > A single honest validating user guarantees that attackers cannot do more harm than halting a sidechain.
>
> Is not compatible with:
>
> > 1000 trustless sidechains
>
> You are *tr\sting that there exists at least one honest user per sidechain.
> Thus it is not a trustless solution, but a tr\*sted one.
> Replacing 1000 tr\*sted Excel tables with 1000 tr\*sted blockchains is the same class of error as replacing the banking system with centralized large-scale blockchains: you gain the drawbacks of blockchains without gaining its benefits.
Agreed. Still, let's discuss a solution that meets the requirements of billions of average users with unreliable mobile devices.
Endusers payment experience should be insanely simple.
The LN currently offers regular users mostly custodial services. Is there a foreseeable roadmap to meet endusers' simplicity requirements with non-custodial constructions?
Bitcoin-backed PoS sidechains are strictly superior to custodial hubs. They provide all hub features such as being able to pay merchants in BTC, plus many clear advantages such as better security including public auditability and decentralized data storage. And they do not require any consensus changes.
> The security, integrity, and censorship-resistance of Bitcoin is dependent on there existing some sophisticated actors ("persons") who are willing to take on the risk of running fullnodes and providing hashpower.
> This is the Risk-Sharing principle, by which the risk of keeping Bitcoin running is spread out among many persons who are willing to keep Bitcoin alive.
> The existence of such actors cannot be assured, but it seems to me that fragmenting the entire community of such limited number of actors would not give good risk-sharing within a sidechain.
Indeed, a highly fragmented market would be inefficient and insecure. However, I'd assume a free market of sidechains is intelligent enough to use its resources efficiently.
Thanks again for your detailed feedback,
-Robin

2023-06-07 18:22:30 UTC

- reply

📅 Original date posted:2020-01-14
📝 Original message:> because all users must process all transactions within the blockchain
Reality shows, that's wrong. Bitcoin's security doesn't require verification to scale quadratically with users. Since the whitepaper, Satoshi was explicit about that phenomena. We can discuss nuances, yet it's overall plausible and empirically it's true: Only a tiny minority of users ever verifies the blockchain, still bitcoin works perfectly well. An honest economic majority is sufficient.
Yes, if you can, run your own node. Let's lower the barriers and let's help others to run their own nodes. Let's keep the blocks small and bitcoin's UTXOs set verifiable with consumer hardware. That's the core of decentralized security.
But let's face it: most people on this planet will never run a bitcoin full node. And it is not required.
Bitcoin-backed PoS-sidechains scale in terms of verification and storage just like any other blockchain. However, security is strictly better because double-spends are impossible. A single honest validating user guarantees that attackers cannot do more harm than halting a sidechain. Thus, endusers won't have to validate all of each others' transactions at all.
For most endusers such sidechains' security is strictly superior to today's LN experience.
Let's face it: The most popular LN apps are fully custodial.
They have to be custodial because there is no way to make LN usable for regular users on unreliable phones.
Any payment channel which requires you to be always online excludes 99% of the world's population.
Any payment channel which potentially requires you to be able to pay high on-chain fees excludes most people, too. And on-chain fees keep rising.
Thus, no matter what Channel Factory constructions we build, they will not match most people's requirements. We will keep falling back to custodial solutions.
Excel tables connected to the LN. The LN is awesome as a settlement layer. In particular for anything like bitcoin banks that have been discussed since the beginning.
But why 1000 trusted Excel tables if we can have 1000 trustless sidechains?

2023-06-07 18:22:29 UTC

- reply

📅 Original date posted:2020-01-13
📝 Original message: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/20200113/aeed17c9/attachment-0001.html>

2023-06-07 18:22:28 UTC

- reply

📅 Original date posted:2020-01-13
📝 Original message: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.
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.
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/b82d6658/attachment.html>

2023-06-07 18:22:26 UTC

- reply

📅 Original date posted:2020-01-13
📝 Original message: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.
## Collateral Contract
Thanks for mentioning that! I like the simplicity of your variant! It's better than my workarounds. I'll add it to the paper. However, in the long term, the cleanest solution is to destroy the funds. Giving it to miners assumes Alice does not control much Hash power, which is harder to reason about.
Regards,
robin
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 13, 2020 1:21 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Robin,
>
> The reason why I stopped considering sidechains for scaling and have since moved to Lightning Network development was that, on reflection, I realized sidechains still do not scale, even with stakes anchored on the mainchain.
> The issue is that sidechains, like any blockchain, still require that everyone interested in it to propagate all their transaction to everyone else interested in it.
> Contrast this with Lightning Network, where you select only a tiny handful of nodes to inform about your payment, even if you have a gigantic Lightning Network.
>
> Or, more blithely: Let me get this straight, you already know blockchains cannot scale, so your scaling proposal involves making more blockchains?
>
> You might point to the use of large numbers of sidechains with limited userbase, and the use of cross-chain atomic swaps to convert between sidecoins.
> I would then point out that Lightning Network channel are cryptocurrency systems with two users (with significantly better security than a 2-user sidechain would have), and that Lightning Network payment routing is just the use of cross-channel atomic swaps to convert between channelcoins.
> Indeed, with a multiparticipant offchain updateable cryptocurrency system mechanism, like Decker-Wattenhofer or Decker-Russell-Osuntokun ("eltoo"), you could entirely replace sidechains with a mechanism that does not give custody to your funds to anyone else, since you can always insist on using n-of-n signing with you included in the signer set to prevent state changes that do not have your approval.
>
>
>
> Regards,
> ZmnSCPxj

2023-06-07 18:22:25 UTC

- reply

📅 Original date posted:2020-01-12
📝 Original message: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/20200112/10bc934c/attachment.html>