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

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 c

Re: [bitcoin-dev] Modern Soft Fork Activation

On Mon, Jan 13, 2020 at 08:34:24AM +, Yosef via bitcoin-dev wrote: > tl;dr How about 80% ? The point of having hashpower upgraded is that it means that there's low liklihood of long chains of blocks that are invalid per the new rules, so that if you haven't upgraded your node but wait for a fe

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

Good morning Robin, > > 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 n

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

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

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

Good morning Robin, > 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 > > >

Re: [bitcoin-dev] PSBT Addition (BIP 174) for authenticating source/output PSBT files

On 1/13/20 3:29 PM, Peter D. Gray wrote: > The Signer may be signing a PSBT that was corrupted by the MitM, > but at least later users of the signed PSBT can detect that occured. > At present, they do not know what the input PSBT content was when > it got to the Signer. But the MiTM on the way to

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

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,

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

https://utxos.org/uses/ Yes, you should check out the material at the link above. Specifically non interactive channels solve this problem of one sided opens, where the other party is passive/offline. On Mon, Jan 13, 2020, 12:42 PM Joachim Strömbergson via bitcoin-dev < bitcoin-dev@lists.linuxfo

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

Re: [bitcoin-dev] PSBT Addition (BIP 174) for authenticating source/output PSBT files

> In your proposal, it is the Signer who adds the signature, so it > will receive a PSBT without auth sigs and thus that could be mutated to > trigger those bugs anyways. The Signer may be signing a PSBT that was corrupted by the MitM, but at least later users of the signed PSBT can detect that oc

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

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

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 seem

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 e

Re: [bitcoin-dev] PSBT Addition (BIP 174) for authenticating source/output PSBT files

On 1/13/20 9:28 AM, Peter D. Gray wrote: > I don't have a specific attack in mind, but these signatures, if > adopted by the community at large, will allow detection of-, and > could mitigate damage from-, some broad "bug-classes". > > Consider if the PSBT Signer (hardware wallet) has bugs. Perh

Re: [bitcoin-dev] PSBT Addition (BIP 174) for authenticating source/output PSBT files

Thanks for the useful comments guys. I understand where you are coming from, but my PoV is from the deep embedded side. On Mon, Jan 13, 2020 at 06:39:28AM +, Andrew Chow wrote: > ... In fact, I'm not quite > sure what kind of attack you are trying to defend against with this > proposal. I don

[bitcoin-dev] [Annoucement] Discreet Log Contract Protocol Specification

Hi all, Suredbits and Crypto Garage have begun to work on a specification for using discreet log contracts in a safe, private and interoperable way. We are writing to the mailing list to inform and solicit feedback for the protocol specification so that we can -

[bitcoin-dev] Modern Soft Fork Activation

tl;dr How about 80% ? The fallback to BIP-8 makes sense, but it's not a graceful one and we absolutely prefer BIP-9 to succeed. A failure to reach 95% readiness signalling means 2.5 years delay, 3.5 years in total, not yet counting. 95% can prove difficult to achieve. Some % of negligent miners