Reddit User Account Overview


Redditor Since April 19, 2015 (1,940 days old)
Karma Posts: 5,068 Comments: 108,702 Combined: 113,770
Active in

I thought it would be useful to share this comment from Amaury, It is his view on changing the DAA, replying to me on how to fix it. There are definitively DAA that would perform better on the issue of oscillations. There are no doubts about this. One obvious issue is how well they hold in the face of absurd timestamps. Right there, you lose most of the traditional low pass filter techniques. For instance, a solution that perform better in the face of oscillations is to use exponential decays instead of a moving average. But this solution start producing absurd results in the face of negative timestamps, which definitively happens. So making it viable require to add some mechanism to ensure timestamps are somewhat accurate. Because for all consensus rules, the blockchain itself is the clock, that means it needs to live in the pre/post consensus world - so we are already facing something way bigger than changing the DAA. In addition to that rule, you'd need a consensus rule to prevent negative times between block, but the block headers only have 32 bits to grind, which is very small for ASICs, so in practice, ASICs also grind the lowers bits of the timestamp, which means they will produce negative times once in a while. So, how many ASICs does this break? Does it break them at the hardware level or a firmware update can fix it? These questions are left unanswered, and to be frank, the fact I have to raise them is a red flag to begin with. Another source of concern is selfish mining. Some DAA allow a selfish miner to mine in such a way that gamma pretty much equals 1 (the worst possible case). Today gamma is very close to zero in practice. Do we want to change this? Once again, pre/post consensus can help bringing gamma down even in the face of a vulnerable DAA, but once again, we are talking about something much bigger. The exponential decay solution also has this problem. In addition, the problem statement is very poorly stated. What is the problem? Is it the DAA? Is it switch miners? Is it irregular block times? You might argue that these are the same problems because all of these are causes/consequences of each others, but this is VERY IMPORTANT to actually define the problem you want to solve. Let me go over some ideas as to why. For instance, if we insist that irregular block times are the problem, then we might want to explore the idea of using a real time difficulty adjustment, such as and use preconsensus to adjust differences due to local clock drift. This solution fixes irregular block time, but will not remove switch miners, in fact, it leverages switch miners to make block time more regular. Why not? But see how if you define the problem as being switch miners, then this is not a viable solution. This can work in combination with the current DAA. Great, so what if we define switch miners as the problem? Well in this case, we have options such as bounded mining: . This is a solution that incentivize steady miners, at the expense of switch miners. It would also reduce oscillations, but this time by removing switch miners rather than leveraging them to make block time more regular as in the first options. As you can see, your problem statement dramatically changes the class of solutions you can leverage and these classes are way larger than simply changing the DAA. It is therefore important to not only compare DAA to each others, but to actually define the problem that is being solved and compare a solution such as changing the DAA to the entire class of solutions, including alternatives to change the DAA. To use an analogy, imagine you are an engineer working on a sport car, and you want to increase its acceleration. You have various solutions: - You can use a bigger engine. But your car will now be heavier, which may affect handling. It will also make the car more expensive. - You can use wider tires to increase adherence to the road. This will increase acceleration, but limit top speed. - You can change the engine and aerodynamic configuration of the car. This will also affect handling, fuel efficiency, durability of the engine, probability of breakage, etc... - You can strap rockets on the car. All these solutions are well and good, but present different trade-offs. How do you decide which one you want? Well, if your problem is stated this way, your really cannot. Because your problem isn't acceleration, really, it is getting the best lap time possible. Now you have a metric to judge the different tradeoffs against. For instance, if you pick a solution that decrease fuel efficiency, then you will need to stop refueling more often, and/or will have to put more fuel in the car, making it heavier. You will also use budget for fuel that you could be spending on something else. All this can be measured and compared to pick the best solution. If you decide that you want more acceleration, you cannot. But once you've cross that gap to actually define your problem, you note that new classes of solution appears. For instance, you could decide to change the car in such a way that it now has better handling. You don't need to slow down as much in curves, and therefore don't need to accelerate as much after curves, reducing your acceleration problem without ever changing the acceleration of the car. An engineer who keep beating the "we need a bigger engine" drum without going through the process I described would quickly find him/herself out of a job. Because at the end of the day, the role of an engineer isn't to produce a bigger engine, but to solve problems. And the first step toward solving a problem is knowing what problem you are trying to solve. To loop this back to DAA discussion, this means you can safely dismiss any discussion that: - Do not formulate a clear problem statement and compare proposed solution to the whole class of solutions. This includes bounded mining and RTT. - Ignore the tradeoffs made by the given solution - such as selfish mining or extra constraint on timestamps - possibly breaking ASICs.

posted by /u/Ant-n in /r/btc on April 14, 2020 14:07:31

The topic of cryptocurrencies name confusion come back regularly. It is often presented as a proof that Bitcoin Cash is trying to mislead newbie and steal the “Bitcoin” brand. While I agree currencies sharing similar name can be confusing, the situation is not new and in reality extremely common. It is actually relatively rare to have a currency with unique, non-shared name. Any peoples with only a bit of knowledge should know this situation exist and be prepared for it when trading currencies whatever it is crypto or regular FIAT. If anything crypto have shown so far a remarkable consistency. (Somewhat surprising as crypto are open source project while FIAT currencies are state enforced) Here I collect some examples, the list is pretty exhaustive fell free to let me know if you have other examples I will add them to the list. **Dollars:** US Dollars USD Australian Dollar AUD New Zealand NZD Barbadian dollars BBD Bermudian dollars BMD Brunian dollars BND Bahamian dollars BSD Belizean dollars BZD Canadian dollars CAD Finjian dollars FJD Taiwan new dollars TWD **Pounds:** Britsh pounds GBP Egyptian pounds EGP Falkland island pounds FKP Guerney pounds GGP Gibraltar pounds GIP Isle of man pounds IMP Jersey pounds JEP Lebanese pounds LBP Sudanese pounds SDG Saint Helenian pounds SHP Syrian pounds SYP **Pesos:** Argentinian Pesos ARS Chilan Pesos CLP Combian Pesos COP Cuban Pesos CUC Dominican Pesos DOP Mexican Pesos MXP Philipine Pesos PHP Uruguayan Pesos UYU **Rubles:** Belaruzian rubles BYN Russian rubles RUB **Krona:** Nowegian Krona NOK Swedish Krona SEK Danish Krona DKK Icelandic Krona ISK Croatian Krona HRK Czeck Krona CZK **Francs:** French francs (dead) Swiss francs CHF Francs CFA XOF Burudian francs BIF Congolese francs CDF Djibutian francs DJF Guinean francs GNF Comorian francs KMF Rwanda francs RWF **Dinars:** Bahraini BHD Algerian DZD Iraqi IQD Jordanian JOD Kuwaiti KWD Lybian LYD Serbian RSD Tunisian TND **Shillings:** Kenyan shillings KES Somali shillings SOS Tanzanian shillings TZD Ugandan shillings UGX **Rupee:** Indian rupees INR Sri lankan rupees LKR Mauritian rupees MUR Nepalese rupees NPR Pakistan rupees PKR Seychellois rupees SCR Indonesian rupiahs IPR Please link this post next time you encounter this argument again. I think there is no need wasting energy debating such points. It is a normal characteristics of currencies and while possibly annoying it has to be accepted (and is simply unavoidable).

posted by /u/Ant-n in /r/btc on August 18, 2019 04:48:09

I would like to post this comment and let anyone make his own mind on how likely it is that CSW and Satoshi are the same person: ____ The full thread, for the lulz: >A note. Many like to treat me like Casandra. Well, here is your warning to ignore at your peril. We will win this fast, or we will win this slow, but, we will win this. Others would like this to be "nicer", I would prefer a lesson. I want to have people understand Bitcoin. >If it means we spend a year or more slowly bleeding every satoshi of value one by one from the ABC chain, we will. Without exception. If ABC stays on SHA256d and does not add replay protection, we will hound it. >Not until it is weak, not until it is unlisted on every miner and major and home level exchange globally, but until the last CPU running it anywhere globally burns out If this means chasing a lone dev with a CPU to burn that last vestige of hope, and you think I will not... >Then, you do not know me! But, you will learn. This is not vengeance. It is a lesson. And I intend to burn it into the hearts and souls of all the socialists in ABC so their great grand children do not forget it! Have a nice day The thing that strikes me straight away is how much he sounds like Satoshi Nakamto /s : >I wish you wouldn’t keep talking about me as a mysterious shadowy figure, the press just turns that into a pirate currency angle. Maybe instead make it about the open source project and give more credit to your dev contributors; it helps motivate them.

posted by /u/Ant-n in /r/btc on November 7, 2018 03:31:37

There has been some comment Stating that Segwit increase capacity 1.7x but blocksize 4x was a lie. Some testnet block are used in support, segwit blocks reached 8000tx and 3.7MB. Well this is partially true. Segwit block reached **8800tx** that absolutely true: But the blocksize is **1.7MB.** Now let’s look at the **3.7MB** block: It doesn't containt 8800tx but **400tx!** Why? Because 8800tx is about the maximun a segwit block can containt without going beyond 4MB WU. (and that about 1.7x what it is possible to fit in a legacy block) **Some random calculations to help everyone understand the weight calculation algo:** You will see Blocksize and block weight can vary greatly. Not surprisingly the most critical factor is the witness data size. -------------------------------------------- * Blocksize: **2500kb** * Number of tx: **12500** * Tx average size: **200b** * Basetx: 60b * Witness size per tx: 140b * Ratio witness: 0,7 * Total weight: **4750000** Block not valid * b per unit of weight:0,5263 -------------------------------------------- * Blocksize: **4000kb** * Number of tx: **8000** * Tx average size: **500b** * Basetx: 150b * Witness size per tx: 350b * Ratio witness: 0,7 * Total weight: **7600000** Block not valid * b per unit of weight:0,5263 -------------------------------------------- * Blocksize: **2400kb** * Number of tx: **2000** * Tx average size: **1200b** * Basetx: 240b * Witness size per tx: 960b * Ratio witness: 0,8 * Total weight: **3840000** Block under 4MB WU * b per unit of weight:0,6250 -------------------------------------------- * Blocksize: **3040kb** * Number of tx: **8000** * Tx average size: **380b** * Basetx: 114b * Witness size per tx: 266b * Ratio witness: 0,7 * Total weight: **5776000** Block not valid * b per unit of weight:0,5263 -------------------------------------------- * Blocksize: **1500kb** * Number of tx: **600** * Tx average size: **2500b** * Basetx: 250b * Witness size per tx: 2250b * Ratio witness: 0,9 * Total weight: **1950000** Block under 4MB WU * b per unit of weight:0,7692 -------------------------------------------- * Blocksize: **2400kb** * Number of tx: **600** * Tx average size: **4000b** * Basetx: 400b * Witness size per tx: 3600b * Ratio witness: 0,9 * Total weight: **3120000** Block under 4MB WU * b per unit of weight:0,7692 -------------------------------------------- * Blocksize: **3000kb** * Number of tx: **600** * Tx average size: **5000b** * Basetx: 500b * Witness size per tx: 4500b * Ratio witness: 0,9 * Total weight: **3900000** Block under 4MB WU * b per unit of weight:0,7692 -------------------------------------------- * Blocksize: **1760kb** * Number of tx: **8800** * Tx average size: **200b** * Basetx: 60b * Witness size per tx: 140b * Ratio witness: 0,7 * Total weight: **3344000** Block under 4MB WU * b per unit of weight:0,5263 Edit: format hate me

posted by /u/Ant-n in /r/btc on July 17, 2017 12:04:46

>> How on earth is segwit + 2mb not for the users? >Segwit2x has the x in it because it isn't "+2" but times 2 . It is a 8MB limit HF and a reckless and rushed one at that with a 2-3 month deployment with untested code. >Nodes need to validate under adversarial conditions. Segwit2x is a 8MB limit HF. Use this calculator to see what type of bandwidth impact 8MB blocks have on nodes-- > /u/bitusher Ironically the same that used testnet to show that segwit can lead to 3.7MB to support segwit (beyond 1.7 sewgit allow larger transactions not **more** transactions such block don't bring capacity) now say that x2 is an 8MB block increase... If we get that 2MB block increase after segwit activation this is over we will never get any other block size increase.. the FUD army will be keep scaring everyone with the segwit multiplier effect.. *(And that not wrong block can achieved 8MB after 2x)* **At least they are admitting segwit impact scaling onchain heavily..** Edit: and another one: Somehow now the arguments reversed again, not week ago small blocker kept saying segwit a great scaling improvement..

posted by /u/Ant-n in /r/btc on June 20, 2017 20:53:12 Interesting read. Some extract: >While the cryptocurrency community’s attention was focused on the Bitcoin scaling debate, **a mysterious new Litecoin developer, shaolinfry,** appeared on the scene. Shaolinfry appears to be deeply familiar with Segwit, and in a short amount of time helped the rest of the LTC development team to finish writing their Segwit implementation. Once he had secured the title of “Litecoin developer,” **he switched his focus to Bitcoin, proposing the “user activated soft fork” (UASF).** After launching his campaign for UASF on Bitcoin, he did the same for Litecoin and piggybacked on the reputation of Charlie Lee to push for the UASF there, too. >I don’t want to guess at the true identity of shaolinfry, but it is very clear that the dispute among Bitcoin developers has spilled over into other cryptocurrencies. This has caused me to start thinking even more deeply about the question: How can a decentralized digital currency resolve development conflicts? So shaolinfry was only a new litecoin Dev, only worked on segwit implementation and immediately when finished proposed UASF on Bitcoin.. *Well if he is on BS payroll that would make a lot of sense, can't wait for a leak from a dragonden chatlog..* :) >Because communication was happening, the community did manage to clear up some other current conflicts: discussing the “fire the miners” rhetoric, Charlie Lee promised that **unless the network is under 51% attack, he will not consider changing the proof-of-work algorithm.** After extending an invitation, Charlie Lee has agreed to travel to China in June to discuss Segwit implementation with the members of the Roundtable. Too bad the level of semantics gymnastic is so high in the community that one can argue that anything is a 51% attack now.. >On April 4th, **Charlie Lee published a statement promising that if Litecoin blocks begin to fill up, the developers will support a hard fork to increase the block size limit,** removing barriers from both sides of the argument supporting these changes. I deeply wish that Bitcoin Core would make a similar statement, or write code to this effect. Doing so would allow both sides to come to an agreement and put an end to years of debate. I still cannot understand why Core is unwilling to do this. That I didn’t know, It make Litecoin more interesting to me even if it is only words and many have changed their mind drastically in past… I would not rely on it so much. >It *(UASF)* has nothing to do with the users, and should be called “DASF” — developer activated soft fork. True. I think the term UASF is very misleading too. >Another negative effect of the DASF is that the “users” are defined by developer preference. It becomes trivial to say those who support the developers are users, and those who disagree with the developers are not users of this currency. If you support Segwit, you are a user. But if you prefer increasing the block size, then you don’t count as a user. If this becomes the case, **all that is necessary to control Bitcoin (or any other currency) is to simply hold influence over the development team.** >On April 11th, another terrible thing happened. The pools not yet supporting Segwit (Antpool, LTC1BTC, and BW) all suffered DDoS attacks. After sustaining an entire night’s DDoS attack, the next day BW began voting for Segwit. This left me astonished. **If Segwit is successfully activated on Litecoin through the use of coercion and attacks, then Litecoin will forever be a pillar of disgrace, making protocol decisions through PoD (proof of DDoS).** I strongly agree with those points here.. Emphasis mine.

posted by /u/Ant-n in /r/btc on April 20, 2017 04:46:30

>**Abstract.** A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. **The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.** UASF is directly against Bitcoin fundamentals. **Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.** It is nowhere writen economic nodes get to decide which chain is the valid, doing so is creating an altcoin. I hope exchanges will take proper disposition to identify clearly Bitcoin UASF tokens from Bitcoin, those ARE two distinct cryptocurrencies.

posted by /u/Ant-n in /r/btc on March 30, 2017 05:11:15

**I oppose SEGWIT because it use a soft fork to go around consensus rules.** Meaning that the whole network will have to follow the chain even if the rules have changed. *(old nodes will simply don't see the new rules, the network characteristic has changed and they will be oblivious to it)* In an HF nodes have to explicitly accept new rules (via upgrades) which is infinitly superior approach if immutability is an important feature for a cryptocurrency.. (which I believe is the case for Bitcoin). Such process undermine the whole concept of cryptocurrency IMO as running a node is not a guarantee to fully audit the blockchain and protect the exist consensus rule. *(To be honest I don't even understand the reason of running a node under such upgrade policy)* To understand how serious the situation for example such a scheme can be used to increase the coin supply and if supported by 51% of the hash rate there would be no way to opt-out. This make cryptocurrency as easy to manipulate as FIAT. **There is a fundamental problem here.** **For those who wonder how you can increase the coin supply with a soft fork, easy: Make the new coin supply invisible to the old node (in a seperate data struture like SEGWIT), make it so that all transaction go to a burn address form the point of view of old nodes. Something like a one-way side chain, all the coin supply can move one transaction at a time to that new data structure where the coin supply can be unlimited (each coin burnt is moved to new data structure). Soft fork, nobody can opt-out.. if block is found by a non compliant miner (a block that would include regular transactions to old style bitcoin address) it will be orphaned. (regular behavior of a soft fork) bitcoin characteristic permanently changed, node would be powerless. edit some clarifications and typos.

posted by /u/Ant-n in /r/btc on March 2, 2017 09:11:28

But the real question is should they teach Indian numeral?

Commented by /u/Ant-n in /r/funny on August 9, 2020 14:28:48

> We’re hitting woosh levels that shouldn’t even be possible Pretty that’s some counter-woosh here, hilarious tho..

Commented by /u/Ant-n in /r/woooosh on August 9, 2020 12:15:58

> I’m ok with a split but not to blacklist an address. The blacklist would have been temporary, just for a single block, to mark the split.

Commented by /u/Ant-n in /r/btc on August 9, 2020 10:23:59

You are correct that would just guve a split..

Commented by /u/Ant-n in /r/btc on August 9, 2020 10:15:30

> But on what new rule would you soft-fork ABC out? I guess we first have to wait ABC code freeze to see but any restrictive rule can do if we soft fork prior to the Nov HF (and the restrictive rules can be temporary).

Commented by /u/Ant-n in /r/btc on August 9, 2020 09:26:44

> So then, why you mention it. Well a conflicting HF is catastrophic, BCHN can avoid that.

Commented by /u/Ant-n in /r/btc on August 9, 2020 09:25:05

> I do not understand you. It is possible to set up the next BCHN upgrade in a way there will be no split, no market confusion and guarantee to keep the ticker (assuming majority hash rate)

Commented by /u/Ant-n in /r/btc on August 9, 2020 09:24:24

> SF or HF, the hash-victor usually does get the ticker eventually. Well in case of soft fork the chain stay the same, no upgrade so exchange have no choice but to keep the ticker.. This is basically how bitcoin core took over BTC, via soft fork. We case use this tool now too.

Commented by /u/Ant-n in /r/btc on August 9, 2020 09:22:53

> The quote is true for whatever side has the majority unless both sides code is compatible. I guess you are suggesting make BCHN code compatible with ABC (put the IFP in BCHN) and add something that stops the donation but does not make their blocks invalid under ABC code rules? No actually I got that wrong, For some reason I thought rejecting the ABC donation adress would make a soft fork but it actually create just a split. I guess will have to wait ABC code freeze to know how the IFP is implemented and see if it can be rejected as a soft fork, if not inly a soft fork prior the Nov HF would work to kick out ABC..

Commented by /u/Ant-n in /r/btc on August 9, 2020 09:21:23

> I do not think so, but whatever We saw that during the BCH/BSV split.. some exchange took months return to the common accepted ticker. Why use the blockchain to resolve that and let no chance for market confusion?

Commented by /u/Ant-n in /r/btc on August 9, 2020 09:07:28

> That’s a plan, if BCHN has huge majority hash. That gives no guarantee to have the ticker and doesn’t solve the market uncertainty.

Commented by /u/Ant-n in /r/btc on August 9, 2020 09:05:41

> By majority of miners I’m talking about the big players. Not the “statement” we got from 1.7% of BCH miners. Statement are meaningless, only miner vote matters.

Commented by /u/Ant-n in /r/btc on August 9, 2020 09:00:39

> The majority of miners will choose a winner. The remaining chain can go wither and die a lone death. There is no winner in case of conflicting HF, you just get two independent chain, market confusion and drop in adoption.

Commented by /u/Ant-n in /r/btc on August 9, 2020 08:59:49

> I’m not sure about that - every time in the past, exchanges let the majority chain carry on the ticker. That only work if all exchange and service cooperate. They finally did that for the BCH/BSV but there is no guarantee it will continue. More likely exchange will come up with new ticker and/or drop BCH service and will have a massive set back in adoption.

Commented by /u/Ant-n in /r/btc on August 9, 2020 08:58:38

> There is no solution to remove the 8% and keep one chain. ABC will keep mining only on top of it’s own chain (the one with 8%), even if minority. Yes there is, soft fork ABC before the IFP implementation. Doing so all services and exchange will be following the chain produced with BCHN blocks, giving the ticker to BCHN (all ABC will be orphaned).

Commented by /u/Ant-n in /r/btc on August 9, 2020 08:56:54

> Yes, that was first on my mind. I do not understand why ppl are creating such drama. I actually I tried to propose a solution that other no split. But I was wrong what I propose cause a split.

Commented by /u/Ant-n in /r/btc on August 9, 2020 08:50:30

> Two hours of close monitoring with _invalidateblock_ at the ready ought to be enough to guarantee a clean split. No blacklisting should be necessary. Actually you are right my proposal is only a clean split. I wanted to soft fork ABC, Wish can only be achieved before the Nov HF.

Commented by /u/Ant-n in /r/btc on August 9, 2020 08:49:39

> that’s what a fork is. For this situation the soft fork is the tool.

Commented by /u/Ant-n in /r/btc on August 9, 2020 08:48:18

> If BCHN have majority hash, ABC will fork off by itself. The problem is if exchange and service run ABC nodes then even with minority hash rate they will keep the ticker..

Commented by /u/Ant-n in /r/btc on August 9, 2020 08:47:41

> not with abc. its got checkpoints remember? you will cause a split. Soft fork orphan block with -1 depth, not -10 The rolling checkpoint will not affect that. > secondly, orphaning their blocks is not «  softforking them off ». the nodes are still on the network, and if they arent you have again effectively caused a split as i pointed out. No as BCHN node will orphan any IFP block (assuming majority hash rate) then it will appear like the blockchain is frozen in time and all their block get rejected. > please tell me, what is it exactly you propose to do, and how, and what is it you want to achieve? Make IFP block invalid, having majority hash power to « soft fork » ABC out. > if they are «  softforked out » its a split. if they are not forked out its not a spit. There is no split in case of soft fork. One chain orphan the other one.

Commented by /u/Ant-n in /r/btc on August 9, 2020 07:56:08

> it would take quite a bit a mental gymnastics to justify last minute code without loosing face. They could also release code early, then make a last-minute «  emergency bug fix ». This would be breaking code freeze and very impractical as miner need all to upgrade on quick notice. And also pointless if hash rate show massive support against IFP. > there could be a new rule that the coinbase transaction can only have one non-zero output. That’s still far from foolproof, but it’s a lot better than changing an unrelated issue like the actual reward amount. Seem better indeed, For some reason I preferred the idea of soft forking ABC out earlier than the HF activation day but detecting IFP block and making then invalid is probably just as good.

Commented by /u/Ant-n in /r/btc on August 9, 2020 07:51:52

> Not when everyone is saying they’ll fork the chain! How you resolve that if ABC decides to continue with the IFP? Miner only choice is to go with it,

Commented by /u/Ant-n in /r/btc on August 9, 2020 07:48:06

> Sounds like an attack designed to harm BCH to me. Split or stay. I think Hash will choose the ticker. Are you thinking you can overrule the mining hash? Higher hash power keep the ticker **only** in case of soft fork. With conflict HF you have zero guaranteed any chain will get tickers.. Actually more likely both chain will get new ticker and it all create a massive market uncertainty.

Commented by /u/Ant-n in /r/btc on August 9, 2020 07:46:59

Is kt not what they proposing?

Commented by /u/Ant-n in /r/btc on August 9, 2020 07:44:48

> Every respectable exchange runs multiple node implementations! What the exchange will do if each implementation chain diverge?

Commented by /u/Ant-n in /r/btc on August 9, 2020 07:42:19

> seriously, I want to get rid of this infighting Making IFP block invalid is a solution to resolve this conflict.

Commented by /u/Ant-n in /r/btc on August 9, 2020 07:33:09

> IF you are a miner, YOU are able to do this for YOUR (mining) node, but this would not prevent other (mining) nodes to transact to this address - so this brings us back to the basics of PoW . The goal is not to blacklist the ABC donation, the goal is to make IFP invalid.

Commented by /u/Ant-n in /r/btc on August 9, 2020 07:29:57

> If they had majority hash, I believe ABC would already be kicked out at the fork How? You need some software behavior for that.. > Attacking their minority chain further sounds very BSV of you, lol. BSV was a frontal HF... what I am offering here is a resolution without split: If BCHN have majority hash power then ABC block will be become invalid and ABC is officially out of BCH.

Commented by /u/Ant-n in /r/btc on August 9, 2020 07:28:59

> But you could convince me of a temporary rule in order to get a clean split with ABC. Like the first couple of blocks after the upgrade must not pay to the ABC address from the coinbase, but the rest can. Sure it can be temporary, all it need is to make IFP block invalid form the point of view of BCHN nodes and ensure resolution without split and the ticker going to BCHN. (It is probably possible to make IFP block invalid without blacklist ABC donation addresses but I am not sure)

Commented by /u/Ant-n in /r/btc on August 9, 2020 07:27:06

> Blacklists? I honestly didn’t think you’d suggest such a thing for Bitcoin Cash. The goal is not to blacklist donation to ABC, the goal is to create a soft frok that make IFP invalid. It would alllow for conflict resolution with split. > I’m glad BCHN is not contemplating such a thing, this post honestly sounds like poor advice given on purpose. I think making IFP block invalid is a great solution to resolve this conflict.

Commented by /u/Ant-n in /r/btc on August 9, 2020 07:25:05

> But, if the miners do decide to NOT go with ABC, it seems that BCHn would have won! How exchange and service will know which node software to run to pass the Nov HF?

Commented by /u/Ant-n in /r/btc on August 9, 2020 07:22:46

> I cannot support any incarnation of Bitcoin that does this. Sound money and permissionlessness means nobody gets to tell anybody else how they spend their money. If (some) miners want to start paying 8% tax and reducing their DARI temporarily to get that set up — let them make that choice, I say. What of miner don’t support IFP? Blacklisting ABC donation addresses would make IFP block invalid and avoid a split. If they support IFP then it will not be possible to blacklist ABC adress anyway. > Also at the moment majority hash is not using the IFP soft-fork — ABC will have forked itself off the network anyway. How you know miner choice? AFIAK there is nothing in place yet to allow them to vote on the matter.

Commented by /u/Ant-n in /r/btc on August 9, 2020 07:21:37

> Censorship is not good, regardless of who does it. You miss the point, That would make block applying IFP invalid and therefore kick the ABC block out. No split and ABC is out. But I guess if blacklisting is too touchy there should be some other deterministic behavior that we can detect to make IFP invalid.

Commented by /u/Ant-n in /r/btc on August 9, 2020 07:18:46

> Yes, looks that way. He has nothing to lose. Either he gets millions or he can get out and go back to 9 - 5 job. My thought too, It look like a all or nothing kind of bet..

Commented by /u/Ant-n in /r/btc on August 9, 2020 07:16:29

> A near unanimous rejection of the ABC codebase could result in something more like a 95%/5% split, 95%/5% split can still be desastrous.. What needed is to set up BCHN in a way that prevent split. Let wait for ABC code freeze and then set up a soft fork to kick ABC out

Commented by /u/Ant-n in /r/btc on August 8, 2020 07:33:19

> I’m 100% going to trust them to be public because of the «  code freeze ». No we shouldn’t trust them nor we should trust anyone, but last minute change are mostly impractical if done short notice before an HF. After held strong in the past on code freeze, it would take quite a bit a mental gymnastics to justify last minute code without loosing face. it would be admitting defeat. Certainly what I propose is not 100% fool proof but it is a path forward without split and kicking out ABC.

Commented by /u/Ant-n in /r/btc on August 7, 2020 15:49:47

> LOL, the automated rolling checkpoints were a big surprise! You are right but wasn’t implemented during a code freeze.

Commented by /u/Ant-n in /r/btc on August 7, 2020 15:35:36

> ABC is known to put big, secret code changes in at the last minute. Not really, afaik they always respected the 6 months code freeze.

Commented by /u/Ant-n in /r/btc on August 7, 2020 14:35:06

> Why would that ensure it would orphan ABC’s blocks? They could just comply and do the same thing, and claim they’re the ones trying to keep the chain unified. Good point, you have to be smart about the restrictive rules choosen. Maybe blacklist the IFP donation adresses so that no block applying the IFP rules will be allowed.

Commented by /u/Ant-n in /r/btc on August 7, 2020 14:06:06

> Why so Well you tell me miner want the tax?

Commented by /u/Ant-n in /r/btc on August 7, 2020 14:01:25

> Actually, BCH Hard Forked before SegWit, so BCH fired Core. At least get your facts straight! We left before we got kicked out. We can fire ABC using normal blockchain rules.

Commented by /u/Ant-n in /r/btc on August 7, 2020 14:00:56

> How would that work though? Just find whatever restrictive rules that would ensure all ABC block are orphaned if it activate. Soft fork is how you take over a chain, soft fork cannot be rejected by nodes, that mean all exchange and service will follow the chain produce by BCHN nodes and all ABC blocks will be orphaned.

Commented by /u/Ant-n in /r/btc on August 7, 2020 13:59:24

> If the miners want to fund the Devs and provide hashrate to back it up, who is going to fork? You and all the reddit trolls that have no hashrate? If the miner the IFP they activate it,

Commented by /u/Ant-n in /r/btc on August 7, 2020 13:57:11

Not true, Miner rejected the IFP, they listen to users. They need to have the choice and be given the tool to kick out ABC.

Commented by /u/Ant-n in /r/btc on August 7, 2020 13:53:23

> Maybe you can’t fire them... You can, it takes a soft fork.

Commented by /u/Ant-n in /r/btc on August 7, 2020 13:52:05

> Recall last split Roger bought the ticker with “borrowed” hash rate. Why would he not do it again. If service/exchange upgrade their node to ABC, not matters the hash rate brought to the table, ANC will keep the ticker.

Commented by /u/Ant-n in /r/btc on August 7, 2020 13:50:57

> So let’s soft fork ABC nodes out of the network I’m curious about the technical details here. For example you can make a soft fork rules that reduce the block reward a bit per block (say 6 BCH instead of 6.25 BCH) for a month and then it return to normal. Such soft fork would make block generate by ABC mining node invalid while block remain block valid for the whole network, node service and exchange. In effect kicking out all ABC mining node and therefore ABC influence. But I guess there are probably some simpler restrictive rules that can be apply, it is just the first that cape to my mind. the new restrictive rules just had to ensure it will orphan ABC block. All that need to happen before the Nov HF happens, so the HF can activate under BCHN rules.

Commented by /u/Ant-n in /r/btc on August 7, 2020 13:49:52

> If the vast majority of BCH hashrate chooses the non-ABC chain, then Amaury is effectively «  fire » ».’I’d say th’t’s very unlikely to happen. Even if somehow BCHN got most of the hashrate in November, I’m sure ABC would get still a big chunk of it. If a majority of miner want the dev tax then split will likely be the only option. But how do you know if you don’t offer them alternative? You already give up?

Commented by /u/Ant-n in /r/btc on August 7, 2020 06:56:27

> Either way, this Nov we will hear the message from the miners. If they want to donate funds, or if they want to «  fire ABC ». Sure. But it possible to build alternative that kick ABC without split.

Commented by /u/Ant-n in /r/btc on August 7, 2020 06:54:24

Spamming messages will get you banned... please don’t

Commented by /u/Ant-n in /r/btc on August 7, 2020 06:53:28

> If miners want to donate, they will run ABC, if they don.t want to donate, they will run an ABC copy or alternative. This is the miners choice. Trolls on reddit have no power over what the miners choose to run or do with their BCH! Welcome to decentralization! It is a consensus rules all mining nodes will have to donate otherwise their block will be rejected.

Commented by /u/Ant-n in /r/btc on August 7, 2020 06:52:51

> Explain how you’re going to soft fork? Set a restrictive rules that apply two weeks before the ABC tax activate. Once that restrictive rule apply, all block produced by a ABC mining node get orphaned yet all the exchange and service node remain compatible with the block produced with the new restrictive rules effectively kicking ABC influence form BCH.

Commented by /u/Ant-n in /r/btc on August 7, 2020 06:51:43

> Soft fork automatically kill the minority chain. yes, but then the noded on the minority chain are not «  softforked ou » » and are still present on the network«  « softforked out » - what does that mean? and in this context? The block produce by the minority chain get automatically orphaned. > no. you initially said they should be forked out. that implies a split Not in case of soft fork. It is rather basic stuff here.

Commented by /u/Ant-n in /r/btc on August 7, 2020 06:48:29

> I don’t get what you’re proposing. The problem is that miners and exchanges run ABC without caring what’s in it. If that true then it is a lie to say that ABC tax proposal is rejected by the community?

Commented by /u/Ant-n in /r/btc on August 7, 2020 06:46:06

> Ugh no. Please. Contact miners instead. In principle i disagreed with the UASF on BTC. Will not support something similar on BCH UASF was an hard fork activated by economic nodes, completely different process. Using a soft fork is similar to what Bitcoin Core did to take over BTC. There is nothing wrong with that it is normal blockchain governance. Here it can be used to eliminate a toxic participant without split. Miner remain in charge if they don’t want to activity the soft fork they can reject and keep ABC. It is fully in accordance with decentralization and Bitcoin « ethical process » (Very different that AUSF that used economic nodes to bend the network characteristics)

Commented by /u/Ant-n in /r/btc on August 7, 2020 06:45:20

> If miners want to donate, they will run ABC, if they don.t want to donate, they will run an ABC copy or alternative. This is the miners choice. Trolls on reddit have no power over what the miners choose to run or do with their BCH! Option 3 miner eliminate ABC form the BCH chain. This what I mean by using a soft fork to eliminate ABC.

Commented by /u/Ant-n in /r/btc on August 7, 2020 06:40:55

> You can only fire Amaury if you’re paying him. Are you? Things are different in blockchain. To fire of get rid of people it takse a soft fork, just lile Bitcoin core fired us with Segwit.

Commented by /u/Ant-n in /r/btc on August 7, 2020 06:39:38

>With the number of signatories countering ABC’s stupid move, I highly doubt any exchange would ever award ABC the ticker and if they do, they’d be committing financial suicide. Why giving them the choice? It tke a soft fork to take over a chain (like Bitcoin core did with Segwit) So let’s soft fork ABC nodes out of the network, that way all service/exchange/pool will give the BCH ticker to BCHN whatever they like it or not,

Commented by /u/Ant-n in /r/btc on August 7, 2020 06:38:20

> That’s literally off-topic and against the rules. What do you expect? It depends on the mods agenda, litecoin discussion was encouraged when it came to push for Segwit activation

Commented by /u/Ant-n in /r/CryptoCurrency on August 6, 2020 22:11:37

It is a cool move to impose it after it being rejected??

Commented by /u/Ant-n in /r/btc on August 6, 2020 21:14:30

Where is option 3? BCHN soft fork the chain before the Nov HF. If you want to take over a chain you use a soft fork.. After all that’s actually how BTC took over Bitcoin with Segwit.. we should use that, if we soft fork ABC out, all exchange and service will reject block produced by ABC miners and BCHN would have taken over the ticker.

Commented by /u/Ant-n in /r/btc on August 6, 2020 21:11:16

> when they discover that Bitcoin exchanges are the gatekeepers of consensus. Correct in case of conflict HF, Not correct if we soft fork ABC.. then all exchange and service will reject ABC node. This is how core took over BTC after all (with Segwit).. If you want to take over a chain you should use a soft fork and that what we should do now.

Commented by /u/Ant-n in /r/btc on August 6, 2020 21:06:46

> I was a fan of BCH over BTC (I hate hate BTC) but this has turned into a royal clusterfuck. Well I fully expected the road to wordwide p2pecash will be hard, And decentralization is messy.. by nature

Commented by /u/Ant-n in /r/btc on August 6, 2020 21:03:51

> Amaury might not be perfect, He is imposing a dev tax rejected by the miner and community few months ago... This is an absolute no-no

Commented by /u/Ant-n in /r/btc on August 6, 2020 21:02:48

IMO the best path forward to kick out ABC is to fork the ABC implementation without the 8% tax and introduce a soft fork that activate before the ABC Nov HF. Now miner will have the choice between two indentical implementation software and one of them don’t tax them and if they activate it, will kick out ABC. If they activate the soft fork all the ABC (with tax) nodes will be kicked out of the network and the ABC dev team will be out. No split and ABC dev out. ABC is taxing miner + creating a split, activating that soft fork will remove the tax and prevent a split. Reasonable miner will activate that soft fork.

Commented by /u/Ant-n in /r/btc on August 6, 2020 21:00:53

> They are busy running their coin agnostic businesses. They don’t care. This kind of infighting distracting them from the rest of their business will make them like BCH LESS THAN BEFORE. Let’s soft fork ABC out.. that way Kraken will have to follow.

Commented by /u/Ant-n in /r/btc on August 6, 2020 20:50:46

> All Bitcoin variants should cancel themselves. Start by the Segwit version one first..

Commented by /u/Ant-n in /r/btc on August 6, 2020 20:49:09

> if you soft fork them out (how?) you have a split per definition. Soft fork automatically kill the minority chain. > and it seems you agree that you shouldnt hardfork now You confuse split and HF.

Commented by /u/Ant-n in /r/btc on August 6, 2020 20:47:02

> How different is that from crony FED agents playing monetary god? ? It is just permissionless system at play, nobody own the chain if miner reject a change.

Commented by /u/Ant-n in /r/btc on August 6, 2020 20:45:44

> this is just abc to me, no new vision What else do you want?

Commented by /u/Ant-n in /r/btc on August 6, 2020 17:49:09

> Glad to hear you say it, old friend There has to be whatever trival soft fork rules that BCHN can activate say a week or two before the ABC Nov HF is planned.. If miner activate that BCHN soft fork then all ABC nodes will be kicked out of the network effectively giving the ticker to BCHN (as all services and exchange will have to follow the soft forked chain). (I kinda hope the ABC team kick out Amaury and retract his proposal.. that would be less disruptive, clearly this is madness here..)

Commented by /u/Ant-n in /r/btc on August 6, 2020 17:47:30

> he want to create a split to prevent a split... Why? Remember Segwit? They use a soft fork to steal the ticker? Let’s to the same to kick out ABC, After that if ABC whant to continue they will have to get a new ticker.

Commented by /u/Ant-n in /r/btc on August 6, 2020 17:40:30

> It’s a bit complicated. This rule is a soft-fork, so if ABC has majority hash, the expectation would be that they’d still control the (unified) chain even if BCHN miners didn’t pay the tax. (Their blocks would just be orphaned.) Let’s soft fork the ABC client out before the IFP activation. > However, BCH does not follow typical Nakamoto Consensus. Lol What is « typical » NC? What is NC? > Also, BCHN or ABC could make the split explicit by changing other rules and implementing replay protection, which would be the most clean solution. No need to split if BCHN soft fork ABC out a week or two before the IFP activation.

Commented by /u/Ant-n in /r/btc on August 6, 2020 17:38:00

> Am I misunderstanding that they decided to give up on Grasbeg and went with ASSERT but also added back in the IFP? Is this real life?

Commented by /u/Ant-n in /r/btc on August 6, 2020 17:32:53

I do agree.. I think he is having a meltdown, Now rest to organize how to kick out ABC.. (Unless ABC kick out AS and his proposal?)

Commented by /u/Ant-n in /r/btc on August 6, 2020 17:31:43

I am not sure there has to be a split.. It should be possible to soft fork ABC nodes out of the network before the Nov HF..

Commented by /u/Ant-n in /r/btc on August 6, 2020 16:59:53

To me it does look like a meltdown/panic attack .. change everything last time it is just bizarre..

Commented by /u/Ant-n in /r/btc on August 6, 2020 16:58:07

IMO best to split well before the the Nov HF. Via soft fork to keep the ticker, once the soft fork activate all exchange and service will follow it.

Commented by /u/Ant-n in /r/btc on August 6, 2020 15:46:44

> What makes you think the miners won’t continue to use ABC? I see a lot of talk about «  the communit » » but to be honest, it doe’n’t mean jack shit if the majority hash uses the ABC client. In that scenario (one that isn’t hard to imagine) BCH becomes ABC coin. Only way to know, release a client that soft fork ABC just before the Nov HF. If miner activate the soft fork all exchange will automatically follow the chain that soft forked and as a result the ABC dies a split into another coin.

Commented by /u/Ant-n in /r/btc on August 6, 2020 15:41:04

> Unfortunately, this means that it’s time for BCH to move on from ABC entirely. Amaury made the choice for us. The problem is how?

Commented by /u/Ant-n in /r/btc on August 6, 2020 15:37:14

Wat? Is that april fool or what?

Commented by /u/Ant-n in /r/btc on August 6, 2020 15:36:32

> I’ve answered that many times Please link

Commented by /u/Ant-n in /r/btc on August 6, 2020 11:36:00

> give up LOL!! Let’s test it: Please define what you mean by Nakamoto consensus? Simple enough, yet you cannot answer:)

Commented by /u/Ant-n in /r/btc on August 6, 2020 11:01:19

Funny your usual strategy when I ask you define your point is to move goalposts, not to give up. Something change:)

Commented by /u/Ant-n in /r/btc on August 6, 2020 08:49:56

AFAIK we are not yet talking about of split? Compromise are still possible I believe the code freeze is the 15th isn’t it?

Commented by /u/Ant-n in /r/btc on August 6, 2020 07:11:32

> But on my original point, I mean, governments want more power, «  just wear a mas » » is a simple command that is easily followed, that establishes a principle by which less simple or more demanding commands can be forced onto a population, thus giving the German government more power. I’m not sure how to explain it more than that. Wearing mask come with a side effect: it makes facial recognition less reliable... and facials recognition is the dream come true of big government total control/surveillance. In a way I glad we have an excuse to wear one in public now:)

Commented by /u/Ant-n in /r/GoldandBlack on August 5, 2020 22:06:05

> I still don’t know what they’re actually protesting. Germany has some really relaxed requirements for the corona pandemic: wear a mask. That’s about it. I work in Germany now I can confirm, rather relax here.

Commented by /u/Ant-n in /r/GoldandBlack on August 5, 2020 22:02:38

> Don’t change the DAA if there isn’t consensus! I agree definitely...

Commented by /u/Ant-n in /r/btc on August 5, 2020 19:46:48

> Pay attention 1: PoS has been in the making all along. What are your evidence for that > Pay attention 2: BCH BAB is utterly DEAD, so they need a drama to gather attention and offload coins, this fork is the opportunity. Wat

Commented by /u/Ant-n in /r/btc on August 5, 2020 19:42:47

Alpha male shill? wtf is that?

Commented by /u/Ant-n in /r/btc on August 5, 2020 19:40:06

> Bullshit, BCH survived BSV fork and both increased in price, both worth more than pre-fork. BCH alone worth similar to months pre-fork. Combine chain PoW is not very meaningful, During the BCH/BSV crisis price went from ~$800 in August18 to $150 at our lowest point(from memory) We recover some of it from that but if we have another conflicting HF we will have some major drop movement.. That mean each chain might drop in the low double digits... not how low we can go before it becomes profitable and/or trivial to attack our chain. > Amaury is just one guy using as hedge against being booted things like Avalanche. Why? Because miners are completely utterly clueless and are desperate to put PoS. I doubt miner prefer PoS, if anything they likely favore PoW a lot more, > Alas, Amaury the king of philosophical misgivings, keeps afloat, even tho he himself doesn’t offer anything other than rehearsed ideas from others with slight changes. Got a Schnorr? Thank Pieter Wuille, not Amaury. I don’t disagree, personally I have no problem with Amaury if the problem he cause can be solved in an orderly manner (like with IFP) In a decentr environment it is unavoidable to have conflict.. and the BCH community hasn’t seem to find an a way to resolve them. I was very excited when the IFP has it give the first sign of decentralized governance and conflict resolution without split. Unfortunately people forget quickly and are already calling for another conflicting HF.. > BCH has a very sizable amount of devs that transparently and honestly want to test and push it forward, ludenberg, nilacTheGrim, etc. You have literally nothing to lose, only to gain. Grow a pair, moon-lambo kid, the team that gives value to this coin is called Electron Cash, it always has been and it still is. . You seem to forget that BCH has a lots of enemies.. They will love to attack the market confusion generated. All that for change that nobody would have noticed on everyday usage of the crypto. Loss of network effect is a killer. Fueling pointless fight only hurt BCH, going for miner can prevent us to split. « Grow a pair » Well chose your fight. Enemies of BCH most be cracking champaign now, (And well also drift correction could have been very dangerous to BTC.. so this conflict is a win-win-win for them)

Commented by /u/Ant-n in /r/btc on August 5, 2020 17:14:48

Ok maybe not as easily as the post suggests but it remain mostly true..

Commented by /u/Ant-n in /r/CryptoCurrency on August 5, 2020 16:06:51

> «  as Covid-19 economic shocks drive mainstream institutional investors’ move to try non-traditional digital assets like bitcoin to hedge their portfolios in these uncertain times » It would be great but I doubt so.. If any such thing were happening now even on a moderate scale price would have skyrocketed.

Commented by /u/Ant-n in /r/CryptoCurrency on August 5, 2020 16:05:25

A rather weak one..

Commented by /u/Ant-n in /r/btc on August 5, 2020 16:03:25

Seem lole a rather weak explaination here..

Commented by /u/Ant-n in /r/btc on August 5, 2020 15:14:38

> Are you here for price or for digital cash? Well a 3x drop from now will start to make sha256 very difficult.

Commented by /u/Ant-n in /r/btc on August 5, 2020 15:14:20

> But ABC’s checkpoints do create a whole new category. I think your example is inapt. My example (it never takes off) is better The problem is BCH took off, the consensus algo worked without any failure for two years now. Not a single time a BCH had to reject a chain because of the reorg protection. BCH is an aircraft that fly and have flown for a long time while remaining less safe. > No, they aren’t, in fact, guaranteed to ever come to consensus in the event of even a short split. This is the minimum any NC node would do. Please link me to a « rejected longest chain » that happened since the reorg protection go introduced? > Therefore ABC’s auto-checkpoints aren’t NC. I actually don’t disagree. That doesn’t make the whole BCH consensus algo non-NC. But hey I have still no idea how you define it. > I’ve made myself crystal clear. You refuse to understand. You gave few satoshi quote.. I still have no idea what you define NC. > LOL! «  Similar t » »!!! That’s just kicking the can. This is an incredibly imprecise definition. Yes I am talking of « category » here. It called « nakamoto consensus » for a reason, it is a consensus algorithm that satoshi implemented. As I said before I would even consider PoS a form of NC that target stake instead of cumulative work. > LOL! We’re done. I’ve embarrassed you too much already. If none of the peer your node connect have the longest chain obviously you will not get it. Re-start to get other peers, or ban the peer that doesn’t have the longest or finally select a known peer that has the longest chain.

Commented by /u/Ant-n in /r/btc on August 5, 2020 15:09:12