Re: [bitcoin-dev] On Hardforks in the Context of SegWit

actions while the limit is still 1MB *is* an emergency worthy of > a hard fork. > > If that's not an emergency, then what is? > > I strongly believe bitcoin has no place in the world if the fee raise > much higher than a few cents per typically-sized transaction. > > On 2/8/16, Tao

Re: [bitcoin-dev] Updating the Scaling Roadmap

Paul, There is a difference between replying to an email, and addressing the issues that were brought up in it. I did read your reply, and I chose not to respond to it because it did not address anything I said. Here's an example: > It would not be accurate to say that miners have "total"

Re: [bitcoin-dev] Updating the Scaling Roadmap

Dear Chris, > I think this is an unfair characterization. You have to opt into using > drivechains. I have heard this nonsense repeated countless times in order to justify adopting Drivechain. This is not how security works. A child can "opt-in" to using a loaded gun, but is it a good idea

Re: [bitcoin-dev] Updating the Scaling Roadmap

> I think Paul has been pretty upfront about the risks of his model. I think he has been rather misleading in his presentation of the risks. He outlines them in a very technical manner, yes, but then goes on to promote them to lay people as if they're no big deal, which is completely

Re: [bitcoin-dev] Updating the Scaling Roadmap

ely used. It would be difficult > to find a single wallet that doesn't support BIP16 I have no idea what you > are talking about. > > On 07/12/2017 12:42 PM, Tao Effect via bitcoin-dev wrote: >> ... >> In the present situation, anyone-can-spend outputs are used by probably

Re: [bitcoin-dev] Updating the Scaling Roadmap

Dear Paul, Drivechain has several issues that you've acknowledged but have not, IMO, adequately (at all really) addressed [1]. I think there are far safer solutions for scaling Bitcoin and integrating it with other chains than DC, which is again, a serious security risk to the whole network,

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

Paul, I'm assuming it's OK with you that I pick up from where we left off in the "Scaling Roadmap" thread [1], so as to be on-topic per your request. (For others reading, part of my reply to the previous email in this thread is here [2]). For reference, I said: > Isn't it different in the

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

ohnson <n...@ethereum.org > <mailto:n...@ethereum.org>> wrote: > > On Wed, Jun 7, 2017 at 12:02 AM Gregory Maxwell via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > On Tue, Jun 6, 2017 at

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

> Please read my email more carefully; the replay threat would be moot because > there would be no alternative chain to replay the TX on, In order to *get to that point*, you need >51%. Not only that, but, if you started out with <51%, then you need >>51% in order to *catch up* and replace the

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

See thread on replay attacks for why activating regardless of threshold is a bad idea [1]. BIP91 OTOH seems perfectly reasonable. 80% instead of 95% makes it more difficult for miners to hold together in opposition to Core. It gives Core more leverage in negotiations. If they don't activate

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

I don't know what you mean by "render the replay threat moot." If you don't have replay protection, replay is always a threat. A very serious one. -- Please do not email me anything that you are not comfortable also sharing with the NSA. > On Jun 6, 2017, at 5:19 PM, Kekcoin

[bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

This is just me putting in my formal objection to BIP148 and BIP149 based on my experience with the ETH/ETC hard fork and involvement in that drama. First, it's important to note that ETC/ETH HF is a very different situation from BIP148 and all other soft-forks. To those on this mailing list,

[bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

This is just me putting in my formal objection to BIP148 and BIP149 based on my experience with the ETH/ETC hard fork and involvement in that drama. First, it's important to note that ETC/ETH HF is a very different situation from BIP148 and all other soft-forks. To those on this mailing list,

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

What is the probability that a 65% threshold is too low and can allow a "surprise miner attack", whereby miners are kept offline before the deadline, and brought online immediately after, creating potential havoc? (Nit: "simple majority" usually refers to >50%, I think, might cause confusion.)

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

gory Maxwell <g...@xiph.org > <mailto:g...@xiph.org>> wrote: > > On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: >> I believe the severity of repl

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

8> -- Please do not email me anything that you are not comfortable also sharing with the NSA. > On Jun 6, 2017, at 4:08 PM, Luke Dashjr <l...@dashjr.org > <mailto:l...@dashjr.org>> wrote: > > On Tuesday 06 June 2017 10:39:28 PM Tao Effect via bitcoin-dev wrote: >&g

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

t email me anything that you are not comfortable also sharing with the NSA. > On Jun 6, 2017, at 4:20 PM, Anthony Towns via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > On Tue, Jun 06, 2017 at 03:39:28PM -0700,

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

> CPFP can be used by an attacker to get your original txn into the 148 chain. *err, my bad that's unlikely to happen, if I remember correctly CPFP can only be done by the person you're sending the coins to. Coin-mixing seems the better option of the two, but shouldn't the BIP148 folks wait

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

> You keep referring to 148 coinbase coins, what is the rationale behind this? > Why would you prefer using 148 coinbases over legacy coinbases for this > purpose? OK, maybe "post-UASF coinbase coins" is a better term? I just wanted to make it clear that this refers to coins that come from

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

In Drivechain, 51% of miners have total control and ownership over all of the sidechain coins. The vision of Drivechain is to have many blockchains "plugged in" to the main chain. Today, well over 51% of miners are under the jurisdiction of a single government. Thus the effect of Drivechain

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

> One-way pegs have strong first-mover disadvantages. > > Paul > > On Oct 9, 2017 9:24 PM, "Tao Effect via bitcoin-dev" > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > Dear list, > > In p

[bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

Dear list, In previous arguments over Drivechain (and Drivechain-like proposals) I promised that better scaling proposals — that do not sacrifice Bitcoin's security — would come along. I planned to do a detailed writeup, but have decided to just send off this email with what I have, because

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

;truthc...@gmail.com >> <mailto:truthc...@gmail.com>> wrote: >> >> That is only a one-way peg, not a two-way. >> >> In fact, that is exactly what drivechain does, if one chooses parameters for >> the drivechain that make it impossible for any side-to

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

comfortable also sharing >>>> with the NSA. >>>> >>>>> On Oct 9, 2017, at 6:39 PM, Paul Sztorc <truthc...@gmail.com> wrote: >>>>> >>>>> That is only a one-way peg, not a two-way. >>>>> >>>>> In

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

udon > >> On Oct 10, 2017, at 13:13, Tao Effect via bitcoin-dev >> <bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> It would not change the number of Bitcoins in existence. >> >> -- >> Sent from my mobile device. >> Please do not email

[bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

Dear list, In previous arguments over Drivechain (and Drivechain-like proposals) I promised that better scaling proposals — that do not sacrifice Bitcoin's security — would come along. I planned to do a detailed writeup, but have decided to just send off this email with what I have, because

Re: [bitcoin-dev] Introducing a POW through a soft-fork

Just going to throw in my support for a POW change, not any particular implementation, but the idea. Bitcoin is technically owned by China now. That's not acceptable. - Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. > On Oct 31, 2017, at 10:48

[bitcoin-dev] The DCS Theorem - theory for understanding blockchain scalability

The DCS Triangle was independently discovered by myself and Trent McConaghy. It is a useful tool for clearing confusion about blockchain scalability and blocksize-related debates. The DCS Theorem is a probability proof of the triangle, and it's now on arXiv: https://arxiv.org/abs/1801.04335

Re: [bitcoin-dev] Some thoughts on removing timestamps in PoW

Real quick (I've received some off-list replies and do plan to respond to those), want to be clear: this thread is not meant to be interpreted as a proposal to modify Bitcoin (it is not a BIP), it is just, exactly as the subject says, some thoughts I had that I hadn't seen expressed elsewhere,

[bitcoin-dev] Some thoughts on removing timestamps in PoW

Copied from: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13 # Blockchain Timestamps Unnecessary In Proof-of-Work? *Author: Greg Slepak ([@taoeffect@mastodon.social

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

Hi Raymo, I personally am excited about what you’re working on, and wish you the best of luck with it! Cheers, Greg > On Jul 17, 2021, at 8:50 AM, raymo via bitcoin-dev > wrote: > > After introducing Sabu protocol as a solution for Bitcoin scaling >

Re: [bitcoin-dev] Future of the bitcoin-dev mailing list

Hi, I also have faced this same problem, and here’s my solution to it: Use the latest version of https://www.simplemachines.org/ . This is the same forum software that powered Bitcointalk, Silk Road, etc. It has many advantages over every other platform out there: 1. It has great anti-spam