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 prev

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 > (https://raymo-49157.medium.com/time-to-bo

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

Hi ZmnSCPxj & Raymo, > On Jun 28, 2021, at 8:28 AM, ZmnSCPxj via bitcoin-dev > wrote: > > Good morning Raymo, > >> Hi ZmnSCPxj, >> […] > What prevents the creditor from signing a transaction that is neither a valid > MT nor a GT? > > Nothing. How would the creditor create such a transaction

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

> What you are suggesting, unless I am mistaken, is that new full nodes should > have no way of knowing if an output is spent or even if it exists. Since > large sections of the blockchain will potentially be skipped, the full node > will not have complete knowledge of utxo's just for starters.

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

[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

[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] A DNS-like decentralized mapping for wallet addresses?

Check out Blockstack, they're doing something like that. -- Please do not email me anything that you are not comfortable also sharing with the NSA. > On Nov 30, 2017, at 2:20 PM, mandar mulherkar via bitcoin-dev > > wrote: > > Hello, > > I am new

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

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

> with the NSA. >> >>> On Oct 10, 2017, at 12:50 PM, CryptAxe wrote: >>> >>> Your method would change the number of Bitcoins in existence. Why? >>> >>> On Oct 10, 2017 12:47 PM, "Tao Effect via bitcoin-dev" >>> wrote: &g

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

ence. Why? > >> On Oct 10, 2017 12:47 PM, "Tao Effect via bitcoin-dev" >> wrote: >> Is that what passes for a technical argument these days? Sheesh. >> >> Whereas in Drivechain users are forced to give up their coins to a single >> group for wh

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

gt;>> They work in the exact same manner. >>>> >>>> Cheers, >>>> Greg >>>> >>>> -- >>>> Please do not email me anything that you are not comfortable also sharing >>>> with the NSA. >>>> >>

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

gt; 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-main transfer to >> succeed. >> >> One-way

[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 I'

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

ve strong first-mover disadvantages. > > Paul > > On Oct 9, 2017 9:24 PM, "Tao Effect via bitcoin-dev" > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > Dear list, > > In previous arguments over Drivechain (and Drivechain-like proposals)

[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 I'

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

Dear Paul, > In point of fact, he is wrong, because nodes do the counting. When miners > find a block, they can choose to move the counter up, down, or not at all. > But nodes do the counting. I may very well have confused who counts what, but for this discussion on *theft* it's irrelevant, so

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

Paul, > The confusion below stems from his conflation of several different ideas. I'm right here, are you having a conversation with me or are you on a stage talking to an audience? > FYI that document is nearly two years old, and although it is still > overwhelmingly accurate, new optimizatio

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 cas

Re: [bitcoin-dev] Updating the Scaling Roadmap

ld 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 less &

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 misleading.

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 to

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" con

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

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 ap

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

5 AM, Nick Johnson <mailto:n...@ethereum.org>> wrote: > > On Wed, Jun 7, 2017 at 12:02 AM Gregory Maxwell via bitcoin-dev > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev > <mailto:bitcoin-

[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, th

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 wi

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

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

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

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 unti

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

-- Please do not 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 > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > On Tue, Jun 06, 2017 at 03:39:28PM -0700, Tao Effect via

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

f6d248e9f1f3c6e10b1b8> -- 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 <mailto:l...@dashjr.org>> wrote: > > On Tuesday 06 June 2017 10:39:28 PM Tao Effect via bitcoin-dev wrote: >> I be

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

7, at 4:02 PM, Gregory Maxwell <mailto:g...@xiph.org>> wrote: > > On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: >> I believe the severity of replay attacks is going unvoiced and is not >> unders

[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, th

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

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 Effect via bitcoin-

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

Hard forks should always come in response to some major crisis that all participants can agree is an actual crisis, as per the excellent rational here: http://bitledger.info/why-a-hard-fork-should-be-fought-and-its-not-evil-to-discuss/ And here: http://bitledger.info/hard-fork-risks-and-why-95-

[bitcoin-dev] Crossing the line? [Was: Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!]

Dear list, Mike has made a variety of false and damaging statements about Bitcoin, of which this is but one: > On Sep 30, 2015, at 2:01 PM, Mike Hearn via bitcoin-dev > wrote: > I coined the term SPV so I know exactly what it means, and bitcoinj > implements it, as does BreadWallet (the other