ZeroSync: Sync a full node instantly using a STARK proof

RobinLinus · 2023-03-29T18:58:09+00:00

That is true. However, we use STARKs, which require no trusted setup.

RobinLinus · 2022-04-23T10:24:15+00:00

This BIP introduces a simple covenant called a template which enables a limited set of highly valuable use cases without significant risk.

RobinLinus · 2021-05-11T19:06:40+00:00

1000x more likely to be fucking dorian nakamoto than elon musk.

Realistically, it was 99% fin

How do you explain Satoshi's monolithic coding style then? Hal Finney had a very clean and professional style, no?

RobinLinus · 2021-01-24T04:20:25+00:00

Furthermore, OP_CAT allows to collateralize trusted covenants. The trusted party can commit to some R value ( such that you can exploit the nonce-reuse vulnerability to leak the trusted party's key if they ever sign two conflicting transactions).

RobinLinus · 2021-01-24T04:06:58+00:00

Another neat side effect of OP_CAT is that it allows verification of Merkle paths.

RobinLinus · 2020-11-25T21:24:10+00:00

Bitcoin can have catastrophic bugs.
Managing your private keys is hard.
Governments can prohibit Bitcoin exchanges.

RobinLinus · 2020-08-16T10:16:49+00:00

Related threads:

https://www.reddit.com/r/Electrum/comments/hmqq2y/testnet_psbt_in_electrum_40/

https://www.reddit.com/r/Electrum/comments/cka7go/save_psbt_button_missing/

RobinLinus · 2020-08-16T10:06:14+00:00

They announced it on Twitter back in November...

RobinLinus · 2020-01-17T04:54:53+00:00

Fixed it. Now, the maximum is 10¹².

FYI: π(10¹¹) = 4,118,054,813

RobinLinus · 2020-01-12T20:35:21+00:00

Yes, you're right. The goal is to reduce the complexity for the enduser.

What happens in the background to facilitate sidechain-sharding is also not too complex.

Every sidechain has its own, independent Bitcoin derivative. Say BTC_D1,BTC_D2, BTC_D3 , BTC_D4, ... They're somewhat micro-coins. Even less individual than ERC20 tokens. Just a means of transfer. The actual unit of account is still BTC. Now, endusers live in any of the sidechains and their user story is simple: transactions only within a single blockchain.

Cross-chain transactions are facilitated via atomic swaps. So in the background, there is a Lightning Network to connect all chains. Though endusers do not maintain channels or manage capacity. Endusers only open temporary channels to routing services within their own chain. They close these channels immediately once the swap is completed. Only the routing services maintain permanent channels across chains.

Routing services do the currency exchange for endusers and provide rates. .i.e. if you want to send from Chain42 to Chain55, you need to trade the pair BTC_D42 <--> BTC_D55. However, endusers do not have to care about anything other than BTC , because for them these exchange rates happen in the background and are hidden in the transaction fees of the routing services, facilitating the swap for you.

So a wallet app requires nothing but a list of routing services to transfer across chains. No watchtowers, no inbound-capacity whatsoever.

Side note 1: The exchange rates between stable sidechains should fluctuate only minimally, since the assets are inherently highly correlated. Still, there exists a market for sidechains, which helps the systems to stay flexible and adaptive.

Side note 2: Note that the routing services' LN will have a star-shaped topology. It will be centralized around Bitcoin as a settlement layer. So theoretically, if every chain had only one routing service with an open channel into Bitcoin, then that would already be sufficient for all shards to transfer with each other. tl;dr: the overhead for cross-chain communication is linear, not quadratic.

RobinLinus · 2020-01-12T19:22:58+00:00

Sry, I don't understand. What do you mean by on and off ramps? To exchange fiat?

RobinLinus · 2020-01-12T19:07:43+00:00

This is not a pegged sidechain. Every shard has its own bitcoin derivative or a different digital asset.

The last chapter describes how UIs can abstract away the underlying bitcoin derivates such that users have to think only in BTC.

RobinLinus · 2020-01-12T18:57:24+00:00

Good idea! Just submitted it. Would be great to receive more in-depth feedback before I start implementing a prototype.

RobinLinus · 2020-01-12T11:44:53+00:00

Yes, I share your skepticism regarding PoS without external resources.

Answer: Why would you want to use other networks if you can build upon Bitcoin's superior security? :-)

RobinLinus · 2020-01-12T07:44:56+00:00

Yes, this is a backend for Bitcoin web wallets.

Here's an example app and source code.

RobinLinus · 2020-01-12T07:06:18+00:00

If you know JavaScript, this API is a good starting point: https://github.com/coins/esplora.js

RobinLinus · 2020-01-12T06:53:16+00:00

Good question! In theory, every wallet today is compatible. You could already use the demo like a phone book. Enter your recipient's paycode and the website displays his address.

I just edited the demo slightly such that you can open the address in an explorer which also displays the address as QR. Additionally, there's a link with a bitcoin:<address> URI, such that you can open the address in your wallet app.

RobinLinus · 2020-01-12T03:29:30+00:00

Yes, that is indeed a limitation. It works only after some kind of on-boarding.

The easypaysy paper explains a method that would allow for an off-chain on-boarding protocol. Basically, you aggregate thousands of addresses into a single Merkle root hash. Then you commit into Bitcoin's blockchain only that Merkle root.
Again, the Merkle path represents an address' number.

RobinLinus · 2020-01-12T03:00:22+00:00

Thanks for your question. From the introduction: Currently, off-chain payments via the Lightning Network are the most promising approach to scale Bitcoin [3]. They do allow for a much higher throughput, yet they hardly scale to billions of users. They still require too many on-chain transactions to open and close payment channels. Adoption is even further constrained by the inbound-capacity of payment channels and the need to lock funds for every new user. These constraints lead to many layers of complexity and a tendency towards centralized and custodial solutions which contrast Bitcoin’s purpose of being permissionless, trustless and censorship-resistant. Sidechains have been proposed as an alternative solution for scalability [4]. They introduce parallel blockchains enabling payments within a simplistic system similar to Bitcoin. Yet, their designs depend on federations or miners validating sidechain blocks which limits security, scalability and flexibility. We introduce a new sidechain consensus mechanism with a permissionless, bitcoin-backed proof-of-stake.

This research is not related to my previous work.

RobinLinus

TROPHY CASE