Re: [bitcoin-dev] Chain width expansion
I like the backwards syncing idea. First you provide proof of your best block height via coinbase, then sync backwards. It solves lots of related problems. You know how much you can expect from the given peer. On different note, one of the problems that I haven't seen mentioned here yet is the timewarp attack. It is relevant to some of the proposed solutions. It should be possible, IIRC, for a malicious node to generate much longer chain with superslow timestamp increase (~5 blocks in 1 second) without increasing difficulty (i.e. staying at min. diff.). This could produce chain that is ~2500 times longer than main chain without having multiple branches. I also agree that there is no big difference between hash checkpoints and "min. diff. checkpoints". Joachim Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, October 12, 2019 4:27 PM, Tier Nolan via bitcoin-dev wrote: > On Thu, Oct 10, 2019 at 5:20 PM Braydon Fuller via bitcoin-dev > wrote: > >> It would be interesting to have a succinct chainwork proof >> for all cases. Chainwork being a sum of the total proof-of-work in a >> chain. Such proofs currently only require a few headers for common cases >> and the other cases can be identified. > > I wonder if a "seed" based system would be useful. > > A seed is defined as a header with a very low digest. > > When a new peer connects, you ask him to send you the header with the lowest > digest on his main chain. > > Chains ending at the strongest seeds are kept preferentially when discarding > chains. > > This requires a way to download chains backwards, which the protocol doesn't > support at the moment. > > The most chain work chain is overwhelmingly likely to contain the header with > the strongest digest. > > This means that the honest peer's chain would be kept preferentially. > > It also means that a node that is synced to the main chain can easily discard > noise from dishonest peers. Before downloading, they could ask the peer to > provide a header with at least 1% of the POW of the best header on the main > chain starting at the fork point. If they can't then their fork probably has > less POW than the main chain. > >> A peer could >> broadcast a few low-work header chains, reconnect and repeat ad nauseam. > > I meant connected peer rather than peer. If a peer disconnects and then > reconnects as a new peer, then their allocation of bandwidth/RAM resets to > zero. > > Each peer would be allocated a certain bandwidth per minute for headers as in > a token bucket system. New peers would start with empty buckets. > > If an active (outgoing) peer is building on a header chain, then that chain > is preferentially kept. Essentially, the last chain that each outgoing peer > built on may not be discarded. > > In retrospect, that works out as the same as throttling peer download, just > with a different method for throttling. > > In your system, peers who extend the best chain don't get throttled, but the > other peers do (but with a gradual transition). > > This could be accomplished by adding 80 bytes into the peers bucket if it > extends the main chain. > >> For example, let's assume a case that the initial chain of headers was >> dishonest and with low chainwork. The initial block download retrieves >> the header chain from a single loader peer first. Once recent time is >> reached, header chains are downloaded from all outgoing peers. > > The key it that it must not be possible to prevent a single honest peer from > making progress by flooding with other peers and getting the honest peer's > chain discarded. > > I think parallel downloading would be better than focusing on one peer > initially. Otherwise, a dishonest peer can slowly send their headers to > prevent moving to parallel mode. > > Each connected peer is given a bandwidth and RAM allowance. If a connected > peer forks off their own chain before reaching current time, then the fork is > just discarded. > > The RAM allowance would be sufficient to hold one header per minute since > genesis. > > The header chains are relatively small (50MB), so it is not unreasonable to > expect the honest peer to send the entire chain in one go. > > I wonder if there is a formula that gives the minimum chain work required to > have a particular chain length by now. > > 1 minute per header would mean that the difficulty would increase every > adjustment, so it couldn't be maintained without an exponentially rising > total chain work. > > On Sat, Oct 12, 2019 at 2:41 AM Braydon Fuller via bitcoin-dev > wrote: > >> - Nodes are vulnerable during the initial sync when joining the >> network until the minimum chainwork is achieved. > > Nodes should stay "headers-only" until they have hit the threshold. > > It isn't really any different from a checkpoint anyway. > > Download headers until you hit this header is about the same as download > headers until you
Re: [bitcoin-dev] Chain width expansion
> > [...] First you provide proof of your best block height via coinbase [...] > > So I don't think you can use the height in the coinbase for that > purpose, as it's not possible to validate it without the previous > headers. That's common for more than just the height. You can fake it of course, but it means you are spending money for PoW and I can't see viable attack here. You can commit to either lower height than actual or higher height, if you are malicious. If it is lower, then your chain will look weaker with some heuristic based on PoW of the tip and the chain length. So you are not going to do that. It thus seem it only makes sense to commit to higher than actual height. OK, this could convince me to be interested in your chain over others. So let's say the real chain is 600k blocks, you claim 1m blocks, and you prove 1m height block to me. So I can ask you about 1) 2000 headers from the tip down 2) AND another proof of height for the block at 1m-2000. To be able to provide that you need to have such a chain and you can reuse any real subchain from mainnet. It's still possible that you can deliver that, but not for high difficulty. Now if time warp attack is blocked, you will have pretty hard time to create such a chain that would look strongest in cumulative work. I don't have actual numbers though, so I can't say this would mitigate everything. > > [...] to generate much longer chain with superslow timestamp increase (~5 > > blocks in 1 second) without increasing difficulty (i.e. staying at min. > > diff.). [...] > > In that case, it would take about 7 minutes of block time seconds for > the next retarget period, every 2016 blocks, and the difficulty would > adjust. The difficulty would adjust in that case as if 2 weeks of blocks > had been mined in 7 minutes. For the difficulty to remain the same the > time between blocks needs to be 10 minutes. This calculation does not apply under time warp attack. You can fake timestamps of all blocks except for those relevant to the retarget calculation. Those are only the first and the last block in the 2016 block window. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Chain width expansion
> > > > [...] to generate much longer chain with superslow timestamp increase > > > > (~5 blocks in 1 second) without increasing difficulty (i.e. staying at > > > > min. diff.). [...] > > > > In that case, it would take about 7 minutes of block time seconds for > > > > the next retarget period, every 2016 blocks, and the difficulty would > > > > adjust. The difficulty would adjust in that case as if 2 weeks of blocks > > > > had been mined in 7 minutes. For the difficulty to remain the same the > > > > time between blocks needs to be 10 minutes. > > > > This calculation does not apply under time warp attack. You can fake > > > > timestamps of all blocks except for those relevant to the retarget > > > > calculation. Those are only the first and the last block in the 2016 > > > > block window. > > This must be in reference to the non-overlapping difficulty calculation > and off-by-one bug? Indeed. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Signaling support for addr relay (revision #1)
> Anyway, according to the current considerations I explained in this email, > I’d suggest extending BIP-155 with per-link-direction negotiation, but I’m > interested in the opinion of the community. I don't have a strong opinion here but intuitively, it seems to me that per-link variant makes better sense as I currently can't imagine the future requirement for completely opting out.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution
While I agree on NACKing the proposal as it does not add anything new and
fundamentally misunderstands what scaling is (or is not in this case), I
disagree with the claim that we do not need to deal with block size issue in
the future any more. Segwit increased our possibilities on how to use the space
more efficiently, but so far it did not completely. It's yet to be seen if
advanced offchain constructions such as channel factories are enough. At this
moment to claim that would be very bold and hardly justified.
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐ Original Message ‐‐‐
On Friday, November 8, 2019 2:36 PM, Emil Engler via bitcoin-dev
wrote:
> NACK!
> 1. We have Lightning and SegWit so thankfully we do not need to deal with
> blocksizes anymore really.
> 2. What if a reorg happens? Then it could generate huge problems at the
> validation.
>
> Correct me if I understood it wrong please.
>
> Greetings,
> Emil Engler
>
> Trevor Groves via bitcoin-dev schrieb
> am Fr. 8. Nov. 2019 um 15:26:
>
>> Dynamic MaxBlockSize - 3 Byte Solution
>> "DMBS"
>>
>> If
>> (Last TOTAL Block Trans fees) > (AVG (Last 100 Blocks Trans Fees))
>> AND
>> current MaxBlockSize => 0.99 MB
>> AND
>> MaxBlockSize has not changed in 10 Blocks
>> ** see error catch below
>> Then
>> ON (Current Block # + 9) Set MaxBlockSize = (MaxBlockSize x 1.1)
>> ELSE
>> AT (Current Block # + 9) Set MaxBlockSize = (MaxBlockSize / 1.1)
>> ELSEIF
>> (current MaxBlockSize =< 0.99 or current MaxBlockSize > 6553.5 MB)
>> Null (no action taken)
>> **where 9 above represents the ActivateONBlock (software side) Variable
>> -
>> We add this 3 Byte Variable Factor to the white space in the Current Block.
>>
>> eg. this 3 byte HEX19000A
>> the first bit "1" can be 1,2 or 0
>> 1 = increase future block (9 blocks ahead)
>> 2 decrease future block (9 blocks ahead)
>> 0No Action (rules evaluate to null)
>> **where 9 above represents the ActivateONBlock (software side) Variable
>> --
>> The Second bit is a Global Variable "9" represents a countdown to the set
>> value action, placed to synchronize network forward changes in "x" blocks.
>> software lowers value if evaluates to True a second time and so on.
>> ("Count down" if you will)
>> the last 2 bytes represent the globally accepted "MaxBlockSize" Variable,
>> and is distributed within each block moving forward in this rightmost (2
>> byte) factor. In this case above,
>> The variable portion "000A" (32 Bit value) represents decimal value 10
>> being 1.0 MB block.
>> the decimal place is Always Assumed, and must be hard coded
>> Because this presents a theoretical Max limit of "" or 6553.5 MB, We
>> would
>> have to add a last rule "only as a error catch"
>> ** AND IF MaxBlockSize < 6553.5
>> ---
>> Increasing and decreasing
>> On Every Block mined or distributed, the software can run the above rule
>> set, Change the Variable and Distribute the next block " In Synchronized
>> fashion". The above rules when combined evaluate to a YES or NO, This
>> translates to a market reflection of increased system pressure or decreased
>> market pressure. I think we can agree, at peak periods the system chokes
>> itself off with fees and this is always only temporarily. So we can have
>> the block, analyse system demand dynamically, and adjust on a globally
>> agreed rule dynamically by market driven demand.
>> Considering the ruleset above also Decreases the Block ONLY if its greater
>> than 0.99mb this brings size back to a competitive state /and size once
>> market demand pressures subside, yet achieves the smallest market feasible
>> block size while also maintaining all current rule sets.
>> An attacker would have to affect all block fees over the last 16 hours
>> worth of transactions to affect a 10% max block size increase but then only
>> after waiting 1.5 hours, so long as nothing has changed in the last 1.5
>> hours and only for a limited amount of time. This approach also limits
>> bloat. This safety block window of 9 blocks provides a look forward and look
>> behind value, in turn provides the network time to synchronize.
>> 10 block sync window. This, by design, also limits changes to one change
>> every 3 hours (20 blocks), if there is a market pressure "STATE" occurring.
>> My Question to the community is. Will our current Block accommodate the 3
>> Byte
>> Variable, Is solving the Scaling issue worth using the 3 Bytes of space?
>> I believe it is.
>> --
>> Software, Will need to Evaluate MaxBlockSize Variable, and ActivateONBlock
>> Variable from the most recent distributed blocks DMBS 3 byte value.
>> Run the rules , get the answer set the now known MaxBlockSize Var and
>> Propegate the "DMBS" value.
>>
>> As capacity limits are breached, I think the majority agree "we need to
>> agree".
>>
>> MaxBlockSize would provide a suitable middle ground and address concerns i
Re: [bitcoin-dev] Coins: A trustless sidechain protocol
> Instead of using sidechains, just use channel factories. I am not familiar enough with the latest advancements in this field. Is it possible using LN/channel factories to achieve off-line-like participation user experience without previous registration with any kind of gateway provider? For example, can you go online, join the network [somehow instantly], generate address/invoice and then put it somewhere for others to later use it when you are off-line? Can you also participate while being off-line for very long periods of time without relying on third party providers to secure your channels? If not, is using sidechains really equally replaceable with LN/CF constructions? Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, January 13, 2020 2:33 AM, ZmnSCPxj via bitcoin-dev wrote: > Good morning Robin, > > > Good morning ZmnSCPxj, > > Thank you for your detailed feedback! Two topics: > > Lightning vs Sidechains > > > > Why an either-or-solution, if we can connect sidechains via the LN to get > > the best of both worlds? > > The LN works exceptionally great under the following conditions: > > > > - you're always online > > > > - you have BTC to manage your channels' inbound-capacity > > > > - you can afford BTC transactions > > - in your channel is much more than the minimum on-chain TX fees > > The next Billion users do not fit that category. They are on > > unreliable cell phone connections and do not have any BTC yet. > > And the more popular Bitcoin becomes, the fewer people can afford > > LN channels. Even Eltoo requires your funds to be significantly higher than > > Bitcoin's TX fees, right? > > Already today, more and more services like tippin.me, BlueWallet, > > etc, provide custodial solutions. > > For small amounts, custody is an acceptable workaround. And I love > > their usability. Install it and immediately I can send you $0.01. Yet, > > scaling their approach globally does not lead to desirable outcomes, since > > we'd be back to trusting banks with their Excel sheets. > > So let's make their internal ledgers public and trustless, via > > independent sidechains. Decentralized Blockchains do scale decently up to a > > couple Million UTXOs. So a couple thousand Sidechains is probably > > sufficient for a global medium of exchange. Cross-chain communication > > without requiring cross-chain validation is possible via atomic swaps and > > through Bitcoin's LN. That scales because it separates chain-validators > > from swap-validators. > > Bitcoin's LN acts as the central settlement layer for efficient > > cross-chain transactions between all sidechains. > > So Endusers "living" in sidechains instead of directly in the LN > > has many advantages: > > > > - no bitcoin blockspace required for on-boarding new users > > > > - no need to lock funds to provide inbound-capacity > > > > - no need to stay online or pay watch towers > > > > - no need to store channel histories > > > > - account balances can be much smaller than BTC TX fees > > Those are the exact same reasons why BlueWallet built their LndHub. But > > sidechains can be trustless. Also a generic protocol provides flexibility > > for sidechain innovations with arbitrary digital assets and consensus rules. > > > > Which is why I brought up multiparticipant offchain updateable cryptocurrency > systems. > The "channel factories" concepts does what you are looking for, except with > better trust-minimization than sidechains can achieve. > Just replace "sidechain" with either Decker-Wattenhofer or > Decker-Russell-Osuntokun constructions. > You can even use the Somsen "statechain" mechanism, which rides a > Decker-Wattenhofer/Decker-Russell-Osuntokun construction, though its > trust-minimization is only very very slightly better than federated > sidechains. > > It is helpful to remember that Poon-Dryja, Decker-Wattenhofer, > Decker-Russell-Osuntokun, and all other future such constructions, can host > any contract that its lower layer can support. > So if you ride a Poon-Dryja on top of the Bitcoin blockchain, you can host > HTLCs inside the Poon-Dryja, since the Bitcoin blockchain can host HTLCs. > Similarly, if you ride a Decker-Wattenhofer on top of the Bitcoin blockchain, > you can host a Poon-Dryja inside the Decker-Wattenhofer, since the Bitcoin > blockchain can host Poon-Dryja channels. > This central insight leads one to conclude that anything you can put onchain, > you an generally also put offchain, so why use a chain at all except as an > ultimate anchor to reality? > Poon-Dryja is strictly two-participant, while Decker-Wattenhofer limits the > practical number of updates due to its use of decrementing relative > timelocks: so you put the payment layer in a bunch of Poon-Dryja channels > which support tons of updates each but only two participants per channel, and > create
Re: [bitcoin-dev] Coins: A trustless sidechain protocol
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 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
Hi Robin, inline... ‐‐‐ Original Message ‐‐‐ On Monday, January 13, 2020 7:47 PM, Robin Linus wrote: > Hi Joachim, > > Thank you for your detailed feedback! > > Regarding Reason #1: > This proposal is less like Bitcoin vs. Altcoins and much more like Ethereum > vs. ERC20 tokens, because the derivatives are not in competition with BTC, > but depend on it heavily. You support Bitcoin's growth by supporting such a > sidechain. > Also, they won't work as separate currencies. For endusers you can abstract > away all underlying complexities such that they have to think only in BTC. > Exchanges rates can be hidden in TX fees. The sidechain derivatives would be > nothing but a means of transfer. The unit of account is still BTC. I can't see any difference and advantage over doing the same with say Litecoin. All you need is to create a special wallet which offers atomic swaps LTC-BTC and its unit of account displayed to user is going to be BTC. All you say will work perfectly with this special LTC wallet. Therefore your idea is as good as any other altcoin. In your case, someone else should indeed be able to create such a wallet in which the unit of account will be the new token, thus emulating the current LTC wallets. So the only difference in Litecoin is that the special wallet with BTC as unit is going to be created after the native one, while in your case it is vice versa. I simply can't see why I'd call this construction of yours a Bitcoin sidechain and any other altcoin not. So I'd call both altcoins. > Regarding Reason #2: > In the "Limitations" section I discuss the cost of halting the chain: > > Time value of locked bitcoins might be too cheap to protect the chain. We can > introduce an additional cost and let validators burn bitcoins for every > on-chain vote. This is much more robust because there is an ongoing cost for > halting the system. Proof-of-burn has recently been formally analysed [16]. > The economic implications of burning significant amounts of Bitcoin are > questionable. A level of security comparable to Bitcoin requires the system’s > BTC burn rate to be equal to Bitcoin’s infaltion rate. > > Also remember, time value of Bitcoins is indeed a value. Even without a proof > of burn, I'd consider such sidechains much more secure than those custodial > lightning wallets which become more and more popular to circumvent the > usability hurdles of the LN. Comparison to other models is not relevant to my claim that such construction is insecure for small sidechains. And for big sidechains the reason #1 prefers any other altcoin. Even if you introduce proof of burn, the final attack cost is small for an attacker in absolute numbers, despite the fact that in the relative numbers the cost is huge. > Thanks again, > - Robin > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Monday, January 13, 2020 7:06 PM, Joachim Strömbergson > 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
Re: [bitcoin-dev] Coins: A trustless sidechain protocol
Hi Robin. While your motivation seems reasonable, your solution is not. It is not enough that a problem exists. Although the solution must be technically sound for the proposal to be interesting. So I agree it makes sense to consider Bitcoin sidechains, not sure if with PoS consensus or other, but no one yet proposed a viable solution, other than Federation based sidechains. Your proposal explored a single specific PoS sidechain, which to me does not sound interesting. Maybe you can improve it, maybe not. I also disagree that it is okay if anyone can halt operation of a sidechain with just tiny investment. For me that is critical security flaw of your proposal. By enforcing stakers having to stake per chain you have actually lowered the cost for the attacker to attack each specific chain. Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, January 13, 2020 10:22 PM, Robin Linus 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
Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY
Hello everyone, regarding OP_CTV, I am considering the scaling use case, specifically an exchange (or similar) who wants to batch pay to OP_CTV to many users, and I wonder 1) How do you expect the exchange to communicate the proof of the payment to the user wallets such that they are able to construct the follow up transactions and accept the payment. This is UI question. Do you expect exchanges to provide a certain importable file/blob that the wallet will allow you to entry? 2) Who pays the fees and how for the transaction within the structure that OP_CTVed output is committed to? Say there is a tree structure and I want to get the coin out. Someone needs to send log(N) transactions to the chain in order for me to get access to the final UTXO I am interested in. Who can construct such transaction path and what do they need for it and who pays fees on that (which input)? 3) Depending on 2) above, is it not possible for a malicious entity who is among the many users being paid, but who has very small UTXO there relative to others, to construct this middle transaction and use a very small fee rate in order to DoS other participants. Is it even possible for this attacker to create the middle transaction with RBF disabled? Thank you, Joachim Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, November 26, 2019 1:50 AM, Jeremy via bitcoin-dev wrote: > Bitcoin Developers, > > Pleased to announce refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY > (replaces previous OP_SECURETHEBAG BIP). Primarily: > > 1) Changed the name to something more fitting and acceptable to the community > 2) Changed the opcode specification to use the argument off of the stack with > a primitive constexpr/literal tracker rather than script lookahead > 3) Permits future soft-fork updates to loosen or remove "constexpr" > restrictions > 4) More detailed comparison to alternatives in the BIP, and why > OP_CHECKTEMPLATEVERIFY should be favored even if a future technique may make > it semi-redundant. > > Please see: > BIP:https://github.com/JeremyRubin/bips/blob/ctv/bip-ctv.mediawiki > Reference > Implementation:https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify > > I believe this addresses all outstanding feedback on the design of this > opcode, unless there are any new concerns with these changes. > > I'm also planning to host a review workshop in Q1 2020, most likely in San > Francisco. Please fill out the form here https://forms.gle/pkevHNj2pXH9MGee9 > if you're interested in participating (even if you can't physically attend). > > And as a "but wait, there's more": > > 1) RPC functions are under preliminary development, to aid in testing and > evaluation of OP_CHECKTEMPLATEVERIFY. The new command `sendmanycompacted` > shows one way to use OP_CHECKTEMPLATEVERIFY. See: > https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-rpcs. > `sendmanycompacted` is still under early design. Standard practices for using > OP_CHECKTEMPLATEVERIFY & wallet behaviors may be codified into a separate > BIP. This work generalizes even if an alternative strategy is used to achieve > the scalability techniques of OP_CHECKTEMPLATEVERIFY. > 2) Also under development are improvements to the mempool which will, in > conjunction with improvements like package relay, help make it safe to lift > some of the mempool's restrictions on longchains specifically for > OP_CHECKTEMPLATEVERIFY output trees. See: > https://github.com/bitcoin/bitcoin/pull/17268This work offers an improvement > irrespective of OP_CHECKTEMPLATEVERIFY's fate. > > Neither of these are blockers for proceeding with the BIP, as they are > ergonomics and usability improvements needed once/if the BIP is activated. > > See prior mailing list discussions here: > > * https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.html > * > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/016997.html > > Thanks to the many developers who have provided feedback on iterations of > this design. > > Best, > > Jeremy > -- > [@JeremyRubin](https://twitter.com/JeremyRubin)https://twitter.com/JeremyRubin___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
