[bitcoin-dev] Implementing Blake3 in Bitcoin Script

[Robin Linus via bitcoin-dev]

Good morning mailing list,

We implemented a hash function in Bitcoin Script to verify Merkle inclusion 
proofs in the BitVM. This allows the VM to have sheer infinite memory, which 
doesn't have to get represented in expensive bit commitments.

The following transaction demonstrates on-chain a Blake3 hash lock, which is 
unlocked by providing the preimage in the unlocking script: 
https://blockstream.info/tx/d8a091a7f5ffa4993681b3df688968fd274bc76897b8b3953309ffad6055f4b0?expand
 

 If you're curious, here you can find the source code: 
https://github.com/BitVM/BitVM/blob/main/opcodes/examples/blake3.js 

We chose Blake3 as it seems to be one of the most simple modern hash functions 
in terms of instruction count. We implemented only a single round performed 
over a 64 byte message, because that's sufficient for us to verify Merkle 
paths. Our implementation represents u32 words as 4 separate bytes on the 
stack, because that seemed to be the optimal tradeoff to implement u32 
addition, u32 bitwise XOR, and u32 bitwise rotations, as required for Blake3. 

We used JavaScript as templating language, to assemble complex programs from 
relatively simple opcodes. You can find the implementation of our u32 opcodes 
here: https://github.com/BitVM/BitVM/tree/main/opcodes/u32 
 In particular, for the 
bitwise XOR we used some cool hacks with a lookup table for a helper function: 
https://github.com/BitVM/BitVM/blob/main/opcodes/docs/u8_xor.md 


Furthermore, we added a simple memory management, which allows us to have 
identifiers for variables, which we can read and write, and keep track of them 
while they're moved on the stack. For example, this allows us to implement the 
permutations of the Blake state simply by relabeling the identifiers of 
variables, instead of actually moving them around on the stack.

In total, the script is about 100kB or 25k vBytes. That's fine for now to build 
a toy-version of BitVM, but the actual plan is to split up the Blake code, such 
that verifier and prover can reduce the required onchain data significantly by 
bisecting the execution in a challenge-response game instead of executing it 
fully.


Cheers, 
- Robin




Co-Founder and President

ZeroSync
6300 Zug
Switzerland

https://zerosync.org | https://twitter.com/zerosync_

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BitVM: Compute Anything on Bitcoin

[Robin Linus via bitcoin-dev]

Abstract. BitVM is a computing paradigm to express Turing-complete Bitcoin 
contracts. This requires no changes to the network’s consensus rules. Rather 
than executing computations on Bitcoin, they are merely verified, similarly to 
optimistic rollups. A prover makes a claim that a given function evaluates for 
some particular inputs to some specific output. If that claim is false, then 
the verifier can perform a succinct fraud proof and punish the prover. Using 
this mechanism, any computable function can be verified on Bitcoin. Committing 
to a large program in a Taproot address requires significant amounts of 
off-chain computation and communication, however the resulting on-chain 
footprint is minimal. As long as both parties collaborate, they can perform 
arbitrarily complex, stateful off-chain computation, without leaving any trace 
in the chain. On-chain execution is required only in case of a dispute.

https://bitvm.org/bitvm.pdf
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Some Day Peg: A crazy two-way peg bridging BTC to other chains Raw

[Robin Linus via bitcoin-dev]

Hi all,

Here's an interesting but not-so-serious attempt to implement a two-way peg in 
Bitcoin Script.
https://gist.github.com/RobinLinus/1102fce176f3b5466180addac5d26313 


-Robin


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] ZeroSync: Introducing Validity Proofs to Bitcoin

[Robin Linus via bitcoin-dev]

Hi Weiji,

> Could you please expand more on how you plan to "implement a SNARK verifier 
> on Bitcoin’s base layer"?
First, I should clarify that I see this as a long-term option, which will take 
years. If Simplicity gets activated, we could use it to implement a SNARK 
verifier on Bitcoin's base layer. But for now, we just plan to experiment with 
Simplicity on the Liquid sidechain when it gets activated.


> For your information, I happen to be the one proposing a new opcode OP_ZKP to 
> enable the Bitcoin network to verify zkp proofs. My proposal requires a soft 
> fork. You may find more information from the email archive here: 
> https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg12601.html
>  
> 
I've seen it; however, I suppose it is hard to establish consensus over some 
particular kind of op_snark_verify opcode because there are so many competing 
proof systems with different trade-offs. For example, STARKs are great for a 
chain state proof as they are scalable and allow for processing huge circuits; 
however, I would not favor STARKs for an on-chain verifier because there are 
other proof systems, such as Plonky2, with much smaller proof sizes.

A nice thing about SNARK verifiers is that once we have any verifier, we can 
use it to wrap other proofs. E.g., we could "compress" the size of a STARK by 
verifying it in a Plonky2 proof.
Still, Simplicity offers much more flexibility and allows to update verifiers 
as the research advances.


> We might be tackling similar issues and probably could benefit from each 
> other. 

Sounds good! Please join our Telegram group, if you would like to chat about 
SNARKs on Bitcoin https://t.me/zerosync_chat 



Cheers,
Robin ___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] ZeroSync: Introducing Validity Proofs to Bitcoin

[Robin Linus via bitcoin-dev]

Hi all,

Today we are publishing a summary of our research on "ZeroSync: Introducing 
Validity Proofs to Bitcoin".


Here's the preface:

We introduce ZeroSync, the first-ever proof system addressing Bitcoin’s 
scalability challenges with Succinct Non-Interactive Argument of Knowledge 
(SNARKs). ZeroSync compresses the entire Bitcoin blockchain into a compact 
proof of validity, enabling instant verification and unlocking various 
innovative applications. We discuss our prototype implementation of a chain 
state proof, utilizing the Cairo language, Utreexo, and recursive STARKs. Our 
work enables diverse applications, including quick bootstrapping of full nodes, 
trustless light clients, enhanced Lightning Network privacy, and secure 
cross-chain bridges. Chain state proofs require no consensus changes, which is 
crucial as forks in Bitcoin are challenging to implement and achieve consensus 
for. Despite the existing bottleneck of prover performance, we present a range 
of optimization strategies and demonstrate the practicality of generating a 
complete chain state proof. 
Finally, we introduce zkCoins, a client-side validation protocol combined with 
zeroknowledge SNARKs, drastically improving privacy and throughput of token 
transactions. In combination with future Bitcoin features, such as Simplicity, 
zkCoins also enables private and more scalable BTC transactions. 
The groundbreaking compression capabilities of SNARKs initiated a paradigm 
shift in cryptocurrency design, and ZeroSync is pioneering their application to 
Bitcoin.


You can find the full paper here: https://zerosync.org/zerosync.pdf 

Happy to receive any comments and answer any questions the bitcoin dev 
community may have about the paper!



Best regards,
Robin Linus___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Nondeterministic Programming and Hints in Bitcoin Script

[Robin Linus via bitcoin-dev]

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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[Robin Linus via bitcoin-dev]

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

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[Robin Linus via bitcoin-dev]

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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[Robin Linus via bitcoin-dev]

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

Re: [bitcoin-dev] Compressed block headers

[Robin Linus via bitcoin-dev]

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 
 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 will8cl...@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())` so is redundant, presuming you have the 
> previous header in the chain.
>
> [cols=">,>,>,>"]
> |===
> |Genesis 

Re: [bitcoin-dev] Coins: A trustless sidechain protocol

[Robin Linus via bitcoin-dev]

Goog morning ZmnSCPxj,


> Unless of course you propose to have the sidechain issue its own coin, in 
> which case it is not much more than an altcoin.

Okay, call it an altcoin consensus mechanism. Because sidechains do have to 
issue their own coins.

Still, I am not proposing independent altcoins. Bitcoin is the only unit of 
account. I am proposing bitcoin derivatives only as means of bitcoin transfer. 
Think of gold vs cash.

> Still, the real-world value of the total block rewards for that altcoin 
> will have to match the real-world value of the total block rewards of Bitcoin 
> in order to have security even approaching Bitcoin.

My point is that, assuming equal rewards, PoW and bitcoin-backed PoS do offer 
the same level of security.

So in theory, you are right. In practice, a sidechain does not need to be as 
secure as bitcoin. It requires only a sufficient user base.



Thanks again for your detailed answer,
-Robin
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Coins: A trustless sidechain protocol

[Robin Linus via bitcoin-dev]

lar 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 
>>>>>  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).___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Coins: A trustless sidechain protocol

[Robin Linus via bitcoin-dev]

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


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Coins: A trustless sidechain protocol

[Robin Linus via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Coins: A trustless sidechain protocol

[Robin Linus via bitcoin-dev]

> 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?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Coins: A trustless sidechain protocol

[Robin Linus via bitcoin-dev]

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

Re: [bitcoin-dev] Coins: A trustless sidechain protocol

[Robin Linus via bitcoin-dev]

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

Re: [bitcoin-dev] Coins: A trustless sidechain protocol

[Robin Linus via bitcoin-dev]

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


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Coins: A trustless sidechain protocol

[Robin Linus via bitcoin-dev]

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).___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev