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