Reddit User Account Overview

/u/

/u/cryptocached
Redditor Since August 1, 2018 (740 days old)
Karma Posts: 677 Comments: 12,392 Combined: 13,069
Active in


https://www.reddit.com/r/bsv/comments/cwbx3z/lets_be_very_clear_kleiman_v_wright_is_not_over/

A lot of misinformation and poorly sourced headlines going around. The case is not over. The only thing awarded at this point is reasonable expenses incurred while litigating the relevant motions. So what does Reinhart's latest Order mean for the case? It establishes facts _for purpose of this action (the lawsuit)_: 1. Dr. Wright and David Kleiman entered into a 50/50 partnership to develop Bitcoin intellectual property and to mine bitcoin; 2. any Bitcoin-related intellectual property developed by Dr. Wright prior to David Kleiman’s death was property of the partnership, 3. all bitcoin mined by Dr. Wright prior to David Kleiman’s death (“the partnership’s bitcoin”) was property of the partnership when mined; and 4. Plaintiffs presently retain an ownership interest in the partnership’s bitcoin, and any assets traceable to them. This means that Plaintiff has no burden to prove any of the above. Defendant cannot make arguments which contradict the facts so established. Consequently, the Court has struck many of Wright's affirmative defenses: - Third Affirmative Defense (Good Faith) - Fourth Affirmative Defense (Accord and Satisfaction) - Fifth Affirmative Defense (Release) - Sixth Affirmative Defense (Payment) - Seventh Affirmative Defense (Set-off) - Eighth Affirmative Defense (Failure to Mitigate Damages) - Seventh [sic] Affirmative Defense (Waiver) - Tenth Affirmative Defense (Statute of Frauds) Litigation continues, with Wright's defense severely handicapped. If Plantiff proves the charges of conversion and fraud, the damages will be calculated using the highest market value of the coins while they were unaccessible to the rightful owner. Not today's value, not the the value at the time Dave died. The highest market value since Wright took control of them until the judgement is issued. On top of that, the Court may award treble (3x) damages. An appropriate judgement would award monetary damages, meaing Wright would need to pay in dollars, not by returning stolen bitcoin.

posted by /u/cryptocached in /r/bsv on August 27, 2019 18:45:52

https://www.reddit.com/r/bsv/comments/c844j9/all_of_wrights_bitcoin_had_been_transferred_to/

The BSV crowd is still trying to find some way to square Wright's perjurious inconsistency between sworn statements about what his fantastical trust holds and with the conflicting claims to have signed with private keys he swears he does not have. The latest attempt in the censored shill factory lays out a common misleading claim: [The first 70 blocks mines by Dr Craig are not in Tulip Trust I](https://www.reddit.com/r/bitcoincashSV/comments/c83nsk/the_first_70_blocks_mined_by_dr_craig_are_not_in/). **This claim is incompatible with Wright's sworn statements.** [Wright asserts that as of December 31, 2013, all of his coins have been placed in the trust.](https://www.courtlistener.com/docket/6309656/184/kleiman-v-wright/) >In 2011, Dr. Wright transferred ownership of all of his Bitcoin into a blind trust. Dr. Wright is not a trustee or a beneficiary of the blind trust. Nor does Dr. Wright know any of the public addresses which hold any of the bitcoin in the blind trust. > >First, as of December 31, 2013, all of Dr. Wright's bitcoin had been transferred to the blind trust, and therefore are owned by the trusts, not by Dr. Wright Something to note in the previously referenced document is the assertion that Wright is neither a trustee nor beneficiary of the trust. [Turns out this was a lie.](https://www.courtlistener.com/docket/6309656/222/kleiman-v-wright/] >In June of 2011, I took steps to consolidate the Bitcoin that I mined with Bitcoin that I acquired and other assets. In October 2012, a formal trust document was executed, creating a trust whose corpus included the Bitcoin that I mined, acquired and would acquire in the future. The names of that trust is Tulip Trust. It was formed in the Seycelles, I refer to this trust below as Tulip Trust I. >7. The trustees for Tulip Trust I are: >... >c. Craig Steven Wright; >... >13. The beneficiaries of Tulip Trust are Wright International Investments Ltd. Tulip Trading Ltd >14. 1 am the contact person for both beneficiaries, I can be contacted through my counsel Rivero Mestre LLP,

posted by /u/cryptocached in /r/bsv on July 1, 2019 23:19:34

https://www.reddit.com/r/bsv/comments/c705vn/next_court_date_in_kleiman_v_wright_july_10/

Unfortunately, the yesterday's show cause hearing didn't have sufficient time to get through all the testimony Wright wants to present in defence of his wonton disregard for Court's orders. The date for continuing that hearing is not yet set, but while the Court works out that tangential process, the main litigation continues to move forward. Next up: [Hearing on Wright's Motion for Judgment on the Pleadings for Lack of Subject-Matter Jurisdiction](https://www.courtlistener.com/docket/6309656/206/kleiman-v-wright/). Although Wright has not been ordered to attend this hearing in person, it is a very interesting one worth following. The motion under adjudication is Wright's latest attempt to get the case thrown out, claiming that the US District Court does not have jurisdiction over the matter due to a legal principle called _complete diversity_. In short, Wright asserts that Dave Kleiman is not the sole member of W&K and that the nationality of other purported members means the matter should be referred to the Florida State Courts. If you've been following the case, this motion may be familiar to you as [the one in which Wright included a forged email as an exhibit supporting his claim that Dave Kleiman appointed Uyen Nguyen as a member of W&K](https://www.reddit.com/r/btc/comments/bistqw/fraudulent_email_was_produced_by_wright_in/). Yep, that's the same document that Wright _threw from the witness stand_ in yesterday's hearing, earning him a head-spinning rebuke from Judge Reinhart. Wright has since withdrawn that particular peice of evidence, which severely undermines a central argument of his motion. Even so, given Wright's infantile temper tantrum at the show cause hearing and blatant projection - insisting _the plaintiff_ of misleading the Court by presenting a document originally introduced himself - it stands to reason that Judge Bloom might be interested in hearing more about how this document found its way into Wright's motion. Maybe she'll even order Wright's personal appearance to hear his excuses from his own lips.

posted by /u/cryptocached in /r/bsv on June 29, 2019 11:21:24

https://www.reddit.com/r/bsv/comments/c6vt1e/censored_shillhole_manages_to_get_every_single/

https://www.reddit.com/r/bitcoincashSV/comments/c6uiqo/june_28_kleiman_vs_craig_court_facts_and_key/ >Fact 1: US Judge asked Dr. Craig to confirm that "he is Satoshi and wrote the Bitcoin White Paper", Dr. Craig confirmed that and Ira's lawyer did not oppose it This line of question came from Wright's attorneys, not Judge Reinhart. Why would the Plaintiff object? These BSV commentators do not seem to have the slightest grasp of how court works. >Fact 2: All parts of Tulip Trust Key may or may not be returned to Dr. Craig in 2020. All parts will be returned only if Dave Kleiman followed the Tulip Trust protocol. This is not a fact, it is an unsubstantiated claim. It conflicts with Wright's prior claims to have signed with keys supposedly controlled by the ficticious trust. >Fact 3: Ira's lawyer showed a pdf and email document about W&K Info Defense. Craig has said it is fake and it is from a hacked server but Ira's lawyer says it is real The plaintiff has asserted the document presented is a forgery since **Wright** first entered it into evidence as an exhibit to a motion. At that time Wright claimed that the document was real and supported an argument that Dave Kleiman was not the only member of W&K. >Fact 4: Dr. Craig got angry because of Ira's lawyer pdf document and threw it. The Judge were not happy with that and would handcuff him if he did it again - Dr. Craig is able to go home and the next step is to prove the Ira' lawyer pdf document is fake Got close on this one. Wright's infantile temper tantrum on the stand did earn him Judicial chastisement. His lawyers were instructed to curb their client over a recess, too. That's not a good look for the defendant in a hearing to determine if he should be held in contempt or otherwise sanctioned. Which brings us to the big lie in this "fact" - the next step is the same as today, Wright was ordered to show cause why he should not be held in contempt. That's all this hearing is about, it is entirely tangential to the lawsuit.

posted by /u/cryptocached in /r/bsv on June 29, 2019 03:04:20

https://www.reddit.com/r/bsv/comments/bwaxjh/paymail_making_bitcoin_as_secure_as_email_in_1982/

[In a relatively uncommon display of questioning the social media consensus](https://np.reddit.com/r/bitcoincashSV/comments/bw1o4r/paymail_specs/epuab17) (at least the BSV cheerleading corner of social media), u/jim-btc has expressed some concern regarding the security of the newly announced paymail protocol. Unsurprisingly he's faced the same silence that [my own questioning on Twitter](https://twitter.com/cryptocached/status/1135357919535542275) has received. I think it's useful to encourage that kind of discussion and since I'm banned from responding in r/bitcoincachsv I figure it would be better than nothing to respond over here in r/bsv. >I've only glanced over the spec and will no doubt in a few weeks set something up on my domain. Would appreciate some info on how security works regarding the DNS records. If this is implemented using regular DNS is it possible for a MiTM attack to spoof the DNS server/lookup and thus ultimately spoof the address that receives funds? >If one uses DNSSEC are all these potential issues fixed? Are they issues at all? u/jim-btc hits on one of two major security shortcomings of the paymail design: service discovery via DNS. The design relies on a DNS record which points to an endpoint from which paymail addresses for the domain can be queried. Of course, as u/jim-btc points out, DNS is an insecure protocol which can be tampered with in a number of ways including but not limited to MitM attacks, race attacks, and cache poisoning. While DNSSEC would certainly be an improvement, that is a solution which needs to be supported by both the domain owner as well as the end user. It is not widely enabled on domains - when I checked the other day, none of the major BSV wallet providers had DNSSEC records - and even less common for the average user. Similarly to TLS in browsers, DNSSEC is reliant on a chain of trusted third parties providing validation of the records, another point if vulnerability even with this solution. The second major security shortcoming of the paymail protocol is that, like email, the addresses and identities they represent are fully controlled by the domain owner. Paymail identity providers can redirect new payments to any address at anytime. Users' identities can be reclaimed, reassigned, or held for ransom by malicious or compromised providers. The protocol does not even require the provider to authenticate their responses, leaving little means to hold them accountable for misbehavior. Overall, the paymail protocol released for BSV is a laughably insecure mess. It relies on incredibly insecure network protocols and completely foregoes any sensible authentication methods that might help minimize the resulting risk. In other words, it's exactly the kind of thing you'd expect Ryan X Charles to release and for Wright's merry band of sycophants to endorse.

posted by /u/cryptocached in /r/bsv on June 3, 2019 09:56:14

https://www.reddit.com/r/btc/comments/brjzer/how_thoroughly_are_claims_in_copyright/

Let's consult [The Compendium of U.S. Copyright Office Practices, Chapter 300](https://www.copyright.gov/comp3/chap300/ch300-copyrightable-authorship.pdf): >As a general rule, the Office will accept the applicant’s representation that the work was independently created by the author(s) named in the application >The U.S. Copyright Office generally will accept the facts stated in the application and other registration materials >Ordinarily, the Office will not conduct its own factual investigation to confirm the truth of the statements made in the application >As a general rule, the registration specialist will not search the U.S. Copyright Office’s records to determine if the work has been registered before >Likewise, the specialist generally will not compare the deposit copy(ies) with other works to determine whether the applicant is attempting to register a work that is substantially similar to another work of authorship >the existence of similar or identical works will not preclude a claim in a work that was independently created" More can be known about any questions the examiner may have had for the claimant. [Applications, certificates of registration, and related correspondence are all publicly accessible upon request](https://www.copyright.gov/rrc/) - and payment of a few hundred dollars in fees.

posted by /u/cryptocached in /r/btc on May 21, 2019 23:46:28

https://www.reddit.com/r/btc/comments/bkfjvp/looks_like_the_court_is_fed_up_with_wrights_tulip/

https://www.courtlistener.com/docket/6309656/166/kleiman-v-wright/ >The Court has already found that tracing Dr. Wright’s bitcoin holdings is relevant to the Plaintiffs’ theft claims. The order to produce a list of bitcoin holdings as of December 31, 2013, was a compromise; it was the Court’s attempt to provide Plaintiffs with relevant and material evidence without unduly burdening Dr. Wright. That Dr. Wright now argues it is not feasible for him to identify the bitcoin he held on December 31, 2013, does not diminish Plaintiffs’ entitlement to the pertinent evidence. That evidence can be obtained through other means, which the Court will authorize Plaintiffs to use. That last bit is a little ominous... In addition to producing a list of addresses, the Court has further instructed Wright to provide substantial information and documentation about the trust, and swear to what he submits. He's not given much time to do so, either. >3. On or before May 8, 2019, at 5:00 p.m. Eastern time, Dr. Wright shall provide to Plaintiffs a sworn declaration identifying the name and location of the blind trust, the name and contact information for the current trustee and any past trustees, and the names and contact information of any current or past beneficiaries. >4. On or before May 9, 2019, at 5:00 p.m. Eastern time, Dr. Wright shall produce to Plaintiffs a copy of any and all documents relating to the formation, administration, and operation of the blind trust. The production shall be accompanied by a sworn declaration of authenticity. >5. On or before May 15, 2019, at 5:00 p.m. Eastern time, Dr. Wright shall produce all transactional records of the blind trust, including but not limited to any records reflecting the transfer of bitcoin into the blind trust in or about 2011. The production shall be accompanied by a sworn declaration of authenticity. >6. Dr. Wright shall execute any and all documents, or other legal process, necessary to effectuate the release of documents in the possession, custody, or control of the Trustee.

posted by /u/cryptocached in /r/btc on May 3, 2019 20:33:08

https://www.reddit.com/r/btc/comments/b2dd9m/the_bitcoin_white_paper_describes_the_system/

>I actually did this kind of backwards. I had to write all the code before I could convince myself that I could solve every problem, then I wrote the paper. --[Satoshi Nakamoto](http://www.metzdowd.com/pipermail/cryptography/2008-November/014832.html) Satoshi's white paper describes the system he coded. Those who argue that the paper describes something other than what Satoshi built either misunderstand the white paper, misunderstand how and why Bitcoin works, or most likely both. This misunderstanding has lead to the rise of arguments for altering the protocol to support ways of "punishing" miners who act to maximize their self-interest in accordance with the rules and incentives of the system. In every case so far proposed, these changes would introduce new attack vectors that radically alter the security assumptions of Bitcoin; assumptions so integral and fundamental that most users do not recognize they exist to be at risk. When these risks are pointed out, the response is often denial, misrepresentation, and accusations that those calling attention to the problems are _enemies of Bitcoin_. Rational voices are drowned out by the roar of technically illiterate sycophants. Much like the proposed "solutions" increase the likelihood of network splits, the accompanying dialog seeks to splinter community support. Divide and conquer on multiple levels. If Satoshi accidentally described a better system than the one he implemented, that system should be built from scratch. There is no discernable reason why Bitcoin as it exists today, as it has existed since the genesis block, as Satoshi intended it to function, should be co-opted and mutated to fit the misinterpretation of anyone else. Let them prove the superiority of their grand ideas without destroying the system so many have fought to preserve.

posted by /u/cryptocached in /r/btc on March 17, 2019 22:39:37

https://www.reddit.com/r/btc/comments/b0g1ls/a_rule_to_punish_miners_for_accepting_wrong/

**A rule to punish miners for accepting "wrong" versions of conflicting transactions is unnecessary and would be detrimental to Bitcoin Cash.** The thesis is a generalized response to a contrary opinion advocated by many in the BCH community and stated by u/jessquit as: >It is needed to have a rule to punish dishonest miners who accept bribes for hiding and mining double spending transactions. My primary supporting arguments are as follows: 1. Bitcoin was designed specifically as a solution to the double-spending problem. That is its primary function and it is highly effective at that task. If the relative validity of conflicting transactions can be known before confirmation, the double-spending problem would no longer apply and Bitcoin would be an unnecessary and expensive duplication of effort. Bitcoin's structure of incentives would be radically impacted by the devaluation of its primary function. 2. There is no natural, objective metric to assess relative validity between sets of conflicting, unconfirmed transactions. The assessment is fundamentally and inescapably subjective. The intrinsic necessity of participant autonomy in a permissionless system guarantees that subjectivity cannot be avoided. 3. Bitcoin succeeds in its capacity as a solution to the double-spending problem in large part, if not primarily, because it treats any property which cannot be objectively determined within the context of a distributed system as arbitrary and inconsequential to validity. No attempt is made to ensure the "correctness" of subjective properties while confirming transactions. Bitcoin cannot provide a reliable and secure solution for the double-spending problem if a majority of miners judge relative validity of conflicting transactions based on subjective properties. Change my mind.

posted by /u/cryptocached in /r/btc on March 12, 2019 21:28:17

https://www.reddit.com/r/u_cryptocached/comments/b0g0b1/a_rule_to_punish_miners_for_accepting_wrong/

The thesis is a generalized response to a contrary opinion advocated by many in the BCH community and stated by u/jessquit as: >It is needed to have a rule to punish dishonest miners who accept bribes for hiding and mining double spending transactions. My primary supporting arguments are as follows: 1. Bitcoin was designed specifically as a solution to the double-spending problem. That is its primary function and it is highly effective at that task. If the relative validity of conflicting transactions can be known before confirmation, the double-spending problem would no longer apply and Bitcoin would be an unnecessary and expensive duplication of effort. Bitcoin's structure of incentives would be radically impacted by the devaluation of its primary function. 2. There is no natural, objective metric to assess relative validity between sets of conflicting, unconfirmed transactions. The assessment is fundamentally and inescapably subjective. The intrinsic necessity of participant autonomy in a permissionless system guarantees that subjectivity cannot be avoided. 3. Bitcoin succeeds in its capacity as a solution to the double-spending problem in large part, if not primarily, because it treats any property which cannot be objectively determined within the context of a distributed system as arbitrary and inconsequential to validity. No attempt is made to ensure the "correctness" of subjective properties while confirming transactions. Bitcoin cannot provide a reliable and secure solution for the double-spending problem if a majority of miners judge relative validity of conflicting transactions based on subjective properties.

posted by /u/cryptocached in /r/u_cryptocached on March 12, 2019 21:24:33

https://www.reddit.com/r/btc/comments/aweqpp/slow_burn_fragmentation_attack/

The combination of BCH's rapid difficulty adjustment algorithm and Bitcoin ABC's rolling checkpoints introduces a novel fragmentation attack strategy. By generating a low-PoW alternate chain from a chosen point in the BCH block chain, an attacker can rapidly reduce the difficulty to extend it. No node which has observed the legitimate chain at higher difficulty will accept the attacker's chain, however, under a temporary eclipse attack new nodes could be led to follow it. Normally, this attack could only be sustained while the targets remain eclipsed from the legitimate network. Rolling checkpoints provide a window of opportunity during which the attacker can rapidly extend their alternate chain, triggering finalization. Should a target observe the legitimate chain after that point it will be regarded as an excessive reorg and treated as invalid. The scope of this attack is limited by a number of factors: 1. The attacker must perform enough work on their chain to discover blocks at rate which will eventually cause the difficulty to drop. They must then sustain that chain with minimal PoW to keep the network time within a usable range. 2. Targets must be susceptible to an eclipse attack. 3. Fork/release-based checkpoints will eventually invalidate the attacker's alternate chain. These are certainly steep obstacles for the attacker, however, the most expensive issue (1) can benefit from reuse of work. Only one attack chain needs to be created that reduces the difficulty, after which any number of additional branches can be spawned from that parent. These branches can be kept up to date using minimal work to prevent the difficulty from rising before application in an attack. Issue (3) somewhat mitigates the efficiency gain through rework. As the attacker's chains conflict with new release-based checkpoints, another difficulty-lowering chain would need to be created to attack new client versions. Overall the practicality and potential impact of this strategy is low, but it is within reach of a moderately funded attacker. It is an example of attacks that clients may be exposed to when defecting from the "honest" strategy of accepting the longest observed chain.

posted by /u/cryptocached in /r/btc on March 2, 2019 01:16:08

https://www.reddit.com/r/btc/comments/9yj5gg/bch_is_better_off_without_handcash/

I've poking around in the decompiled source of the Handcash Android app and noticed some questionable handling of private keys. From what I've been able to dig into so far, it appears the wallet uses SSSS to split the private key into at least three shares, two of which are sent off the device to the handcash backend and businesses with whom the user establishes Cashport connections with. While I haven't had a chance to confirm it for myself, Handcash developer(?) u/apagut has responded to dispel my suspicions that the Hashcash backend could use these shares to sign transactions on a wallet user's behalf. However, when pressed for an explanation of why split key shares are ever given to entities that are never expected to reassemble it, the follow up response was less than informative. [You can read the brief exchange for yourself.](https://www.reddit.com/r/btc/comments/9y6ncs/handcash_app_is_owned_by_nchain_team_craig_wright/e9yvh3d) I don't have enough information yet to say exactly what is happening with private keys in Hashcash, but there is enough smoke to suspect a fire under the surface. Since Handcash appear beholden to nChain patents according to u/apagut, it's reasonable to assume they'll be dropping BCH support in favor of BSV. Perhaps this is no great loss; it might even be a dodged bullet.

posted by /u/cryptocached in /r/btc on November 19, 2018 13:00:18

https://www.reddit.com/r/btc/comments/9uk7sp/are_nchainbsvstyle_bitwise_shifts_good_engineering/

It appears the nChain/BSV proposal for modified OP_LSHIFT and OP_RSHIFT opcodes is [still on the ABC roadmap for May 2019](https://www.reddit.com/r/btc/comments/9tocc4/does_bitcoin_abc_roadmap_for_may_2019_update/). Since these changes remain in play even as BSV and its absurd mandate to arbitrarily limit available opcode count lose relevance, it is worth while to give them proper consideration. A quick review of the alterations. Originally, OP_LSHIFT and OP_RSHIFT were _arithmetic_ operations. That means they operated on numeric values and preserved sign (positive or negative). Under the BSV-inspired implementation, they now operate against arbitrary byte vectors, with no notion or respect for numeric values. [I've brought this issue up several times](https://www.reddit.com/r/btc/comments/9ce492/bsvs_new_op_lshift_and_op_rshift_are_not/), usually in the context of how it diverges from BSV's stated goal of "restoring the v0.1 protocol and locking it down." However, BSV's desires and goals are the same as ABC's or the rest of the BCH ecosystem. Let us then consider the proposed changes on their own technical merits. Is the proposed implementation sound engineering? At first pass, it appears to be a trivial matter. OP_LSHIFT and OP_RSHIFT are logical shifts vs the original arithmetic shifts. Not a big deal if we can also add new arithmetic shift operators should the need arise. But there is a second alteration in the proposal that makes it not so clear cut - the new opcodes operate on arbitrary byte vectors, not numeric values. This is actually a big deal. In most languages and systems, bitwise shift operations generally use the numeric value of an input, regardless of how the value is physically stored in memory. This happens for both the arithmetic and logical forms. However, Bitcoin script encodes its numeric values in little endian and the proposed opcodes act on their operands essentially as if they were big endian. On most platforms which store numeric values in little endian, the BSV-proposed implementation would be considered erroneous behavior. Although bitwise operations are performed against the binary expression of their inputs, they are generally considered mathematical operations and are performed against the _binary expression of the value_ rather than the raw memory representation of an input. The nChain/BSV proposed implementations of OP_LSHIFT and OP_RSHIFT violate basic expectations of mathematical operations by making them endian-sensitive and opposite to the platform's native numeric representation. This poor design is certain to lead to confusion and Script developer error if implemented in BCH.

posted by /u/cryptocached in /r/btc on November 5, 2018 21:15:40

https://www.reddit.com/r/btc/comments/9p4vv8/bsv_subsidizes_new_logical_shift_operations_at/

Acknowledging the replacement Bitcoin's original arithmetic OP_LSHIFT and OP_RSHIFT opcodes with new truncated logical operations, BSV developer u/danconnolly had this to say: > For the LSHIFT and RSHIFT opcodes, these opcodes were updated to be bitwise operators which means that they operate on byte sequences, not numeric values. This means that they do not have special treatment for the sign bit and they don’t overflow or underflow. They operate on all sizes of byte sequences, from zero-length up to the maximum element size (520 bytes). > > Previously, the LSHIFT and RSHIFT operated on numeric values. This same functionality can be achieved through the use of script, possibly including the bitwise LSHIFT and RSHIFT opcodes. https://www.reddit.com/r/btc/comments/9ce492/bsvs_new_op_lshift_and_op_rshift_are_not/e5b9vpe He goes on to provide an example of Script that could be used to simulate Satoshi's intended functionality. This plainly requires many times more steps to perform what was meant to be a simple operation, inflating the size and complexity of scripts making use of Satoshi's original design, not to mention the cost to perform these basic operations. Just as arithmetic shifts can be performed using complex chunks of Script in place of the designatrd opcode, logical shifts can be performed using other basic operations. In fact, logical shifts are much easier to simulate as they are nothing more than multiplication or division by a power of 2. Furthermore, BSV eliminated the OP_2MUL and OP_2DIV opcodes which are identical to the special case of logically shifting left or right by one, respectively. If logical shifts are of such vital functionality that they require subsidized and dedicated opcodes, there is no reason the deprecated opcodes could not have been repurposed as logical shift operators while retaining the arithmetic counterparts. Not only does BSV alter Satoshi's original protocol by introducing these novel operations, it does so as a centrally planned economic change. In the guise of "achiev[ing] balance between minimizing the number of opcodes and providing the functionality" BSV diverges from Satoshi's vision as implemented in his original client, applying a disproportionate penality on performing the intended functionality while BSV's preferred operations benefit from a subsidy.

posted by /u/cryptocached in /r/btc on October 17, 2018 21:54:40

https://www.reddit.com/r/btc/comments/9crpxj/patentability_of_wrights_inventions/

I wonder if the uptick in Wright fanaticism is compensation for the failure rate of his patent applications to pass muster with the International Search Authority. Below are a just a few examples of Written Opinions from patent examiners on the patentability of Wright's many "inventions". While participating regional patent authorities are not required to follow or even consider the opinions of the ISA, they serve as a pretty good baseline for what one might expect when filing with those bodies. That's gotta be a pretty big hit to Wright's narcissistic ego. ​ ([WO2018078584](https://patentscope.wipo.int/search/en/detail.jsf?docId=WO2018078584)) Systems And Methods For Implementing Deterministic Finite Automata (DFAS) Via A Blockchain [Written Opinion of the International Search Authority](http://docdro.id/Xrmieqf) ​ ([WO2018020372](https://patentscope.wipo.int/search/en/detail.jsf?docId=WO2018020372)) Blockchain-implemented System And Method \[for the secure transfer (and/or exchange) of an asset between parties\] [Written Opinion of the International Search Authority](http://docdro.id/M8TADVf) ​ ([WO2017187396](https://patentscope.wipo.int/search/en/detail.jsf?docId=WO2017187396)) Implementing Logic Gate Functionality Using A Blockchain [Written Opinion of the International Search Authority](http://docdro.id/RhI3heQ) ​ ([WO2017187395](https://patentscope.wipo.int/search/en/detail.jsf?docId=WO2017187395)) A Method And System For Controlling The Performance Of A Contract Using A Distributed Hash Table And A Peer-to-peer Distributed Ledger [Written Opinion of the International Search Authority](http://docdro.id/tEh10QA) ​ ([WO2017187399](https://patentscope.wipo.int/search/en/detail.jsf?docId=WO2017187399)) Implementing Logic Gate Functionality Using A Blockchain [Written Opinion of the International Search Authority](http://docdro.id/4rB3KRR) ​ ([WO2017187397](https://patentscope.wipo.int/search/en/detail.jsf?docId=WO2017187397)) Operating System For Blockchain IOT Devices [Written Opinion of the International Search Authority](http://docdro.id/KvacYcX) ​ ([WO2017178955](https://patentscope.wipo.int/search/en/detail.jsf?docId=WO2017178955)) Computer-implemented Methods And Systems For Validating Tokens For Blockchain-based Cryptocurrencies [Written Opinion of the International Search Authority](http://docdro.id/qWk1sMt) ​ ([WO2017145006](https://patentscope.wipo.int/search/en/detail.jsf?docId=WO2017145006)) Agent-based Turing Complete Transactions Integrating Feedback Within A Blockchain System [Written Opinion of the International Search Authority](http://docdro.id/YqhtJMw) ​ ([WO2017145021](https://patentscope.wipo.int/search/en/detail.jsf?docId=WO2017145021)) Method And System For Efficient Transfer Of Cryptocurrency Associated With A Payroll On A Blockchain That Leads To An Automated Payroll Method And System Based On Smart Contracts [Written Opinion of the International Search Authority](http://docdro.id/D6joRLs) ​

posted by /u/cryptocached in /r/btc on September 3, 2018 22:42:21
Top
/r/btc/comments/i6nb3j/was_there_ever_an_explanation_for_the_grasberg/g0xuvsd/

I didn't pick the name. I'm just curious what the intention behind it was. Does seem like a loaded choice, though, no? >I am working on a more permanent solution to your advanced shilling shenanigans. Stay tuned. The suspense is killing me.

Commented by /u/cryptocached in /r/btc on August 9, 2020 19:18:53
/r/btc/comments/i699po/what_to_learn_from_todays_disagreement_in_the_bch/g0xidyy/

>you accuse CSW of lying and incompetence when he said there will be no split I justified Wright's incompetence in stating there would be no split despite the mutually incompatible changes by acknowledging that he is a liar and a fraud. I did not call him a liar for making the untruthful claim.

Commented by /u/cryptocached in /r/btc on August 9, 2020 17:25:50
/r/btc/comments/i699po/what_to_learn_from_todays_disagreement_in_the_bch/g0x45zr/

>CSW even thought there would be no fork Well Wright is liar and a fraud, so his technical incompetence in failing to realize that mutually incompatible changes would result in a fork is understandable. What's your excuse?

Commented by /u/cryptocached in /r/btc on August 9, 2020 15:21:35
/r/btc/comments/i699po/what_to_learn_from_todays_disagreement_in_the_bch/g0x2zj1/

>nChain tried to negotiate but the owners of the BCH protocol forked them off That was a mutual fork. Both clients included mutually incompatible, hard forking changes.

Commented by /u/cryptocached in /r/btc on August 9, 2020 15:11:16
/r/btc/comments/i69qkh/amaury_sechet_walking_out_from_daa_meeting_3_clip/g0x2s6r/

Oh, Wright is a whole wheelbarrow full of problems.

Commented by /u/cryptocached in /r/btc on August 9, 2020 15:09:30
/r/btc/comments/i66pmk/bitcoin_cash_is_making_history_right_now_with/g0w3cp6/

>never gets 51%'ed Could be wrong, but my understanding is that 50% is the maximum **potential** BFT threshold the Avalanche protocol can achieve. In practice it is lower; I think the whitepaper assumed 15%.

Commented by /u/cryptocached in /r/btc on August 9, 2020 09:45:48
/r/btc/comments/i60zac/any_foundation_whose_funding_comes_from_a/g0usc07/

>People can learn. _A person_ can learn. People are fucking stupid.

Commented by /u/cryptocached in /r/btc on August 8, 2020 22:53:04
/r/btc/comments/i61uum/this_is_amaurys_resignation_letter_to_the_bch/g0tg4ek/

>he can get out and go back to 9 - 5 job [He got an offer from Ava Labs several months ago.](https://www.reddit.com/r/btc/comments/fmp7if/so_is_bchavalanche_dead/fl7g6gr) >And now with the chances of the IFP passing near 0 I doubt he'll be working on anything BCH related for too much longer. We'll be happy to pay him at Ava Labs though if he's interested in continuing working on Avalanche. Heck, if this is his resignation maybe he already took them up on it. Wouldn't be the first time a disgruntled developer fucked the codebase and stirred shit before departing a project. Might even earn him a hiring bonus.

Commented by /u/cryptocached in /r/btc on August 8, 2020 15:31:17
/r/btc/comments/i60zac/any_foundation_whose_funding_comes_from_a/g0tf1zw/

If I'm not mistaken, you have Gavin to thank for that.

Commented by /u/cryptocached in /r/btc on August 8, 2020 15:22:53
/r/btc/comments/i60zac/any_foundation_whose_funding_comes_from_a/g0t62t0/

>It appears Github is Bitcoin's weak link FWIW Satoshi used Subversion, hosted on SourceForge. If anything, moving to Git facilitated independent development and forking.

Commented by /u/cryptocached in /r/btc on August 8, 2020 14:07:35
/r/btc/comments/i5xjng/abc_pay2play_p2p_electronic_cash/g0swnp6/

Not in total, those had some **major** flaws. I have enjoyed observing how they've evolved down the various experimental paths, though. Some paths I find more interesting than others.

Commented by /u/cryptocached in /r/btc on August 8, 2020 12:45:02
/r/btc/comments/i5xjng/abc_pay2play_p2p_electronic_cash/g0svepq/

I wouldn't say I'm fan of any specific software implementation or development group. I'm more into the protocol specifications.

Commented by /u/cryptocached in /r/btc on August 8, 2020 12:33:42
/r/btc/comments/i5s33u/abc_is_acting_like_a_ineffective_mad_dictator_of/g0sh7c9/

>The first major red flag was the IFP, an attempt to directly pay ABC from the block reward, changing the underlying economics of BCH. There were red flags before that. The dogged pursuit of preconsensus, especially Avalanche-based proposals, was a huge indicator that ABC was intending to meddle with the incentives. Makes me wonder if this is a connected play. For example, could use the IFP as a sort of premined colored coin for Avalanche staking. It could even be a multiplier: sell those coins above market value to bootstrap the PoS system ABC seeks to impose on their coin.

Commented by /u/cryptocached in /r/btc on August 8, 2020 10:18:27
/r/btc/comments/i5qpil/avalanche_might_be_useless/g0s3jra/

>through proof of work Proof of work is too slow for Avalanche.

Commented by /u/cryptocached in /r/btc on August 8, 2020 07:26:22
/r/btc/comments/i4xfku/cryptophyl_we_support_an_open_inclusive_and/g0r8ypm/

>There are many code rules that must be followed for a block to be valid. Sure are. And when one of those rules are "you must pay 8% to a specific address" it becomes permissioned. The existence of rules does not make a system permissioned. Not all rules are equal.

Commented by /u/cryptocached in /r/btc on August 7, 2020 23:50:49
/r/btc/comments/i5c0cj/joint_statement_from_bch_miners_regarding_bitcoin/g0r8ii7/

>Simply relying on BCHN inevitably having majority hashrate seems like a bad idea. That's how Avalanche post-consensus is supposed to work. Can't see how that could go wrong.

Commented by /u/cryptocached in /r/btc on August 7, 2020 23:45:55
/r/btc/comments/i5h2j0/relay_protection_paradox/g0pms65/

Changing the DAA is already a hard fork - if two coins emerge from this split, **both** will be forks of what came before.

Commented by /u/cryptocached in /r/btc on August 7, 2020 15:13:47
/r/btc/comments/i5jbj8/amaury_can_bribe_miners_and_refund_them_8_of_his/g0pjxd4/

Even better for pool operators to keep their support reserved, not to raise the specter of being bribed. Then they can keep the kickback for themselves.

Commented by /u/cryptocached in /r/btc on August 7, 2020 14:51:06
/r/btc/comments/i5hk7v/abc_was_the_reason_i_joined_bsv_after_the_fork/g0pi80q/

That's not even close to true. But you go ahead and believe that if you'd like.

Commented by /u/cryptocached in /r/btc on August 7, 2020 14:37:26
/r/btc/comments/i5hk7v/abc_was_the_reason_i_joined_bsv_after_the_fork/g0phqs8/

So it's not going to restore v0.1 protocol after all?

Commented by /u/cryptocached in /r/btc on August 7, 2020 14:33:41
/r/btc/comments/i5hsl2/why_does_everyone_hate_governance_by_miners/g0ph5tc/

>Why cant we let the miners do what they want? More than happy for miners to participate in a permissioned chain if that's what they want to do. Not the type of soft-money I'm particularly interested in, but that's no concern of theirs.

Commented by /u/cryptocached in /r/btc on August 7, 2020 14:29:21
/r/btc/comments/i4xfku/cryptophyl_we_support_an_open_inclusive_and/g0n5k6p/

>Then go do something about it! There is nothing to be done about it. If the IFP chain is defined as that which requires the tax then that chain is by definition not permissionless. Nothing can change that fact within that definition. I can go mine permissionlessly on another chain, but I can't change the defining properties of the IFP chain. The IFP chain, as implemented by ABC, is not a permissionless system.

Commented by /u/cryptocached in /r/btc on August 7, 2020 00:31:37
/r/btc/comments/i4xfku/cryptophyl_we_support_an_open_inclusive_and/g0n2cc8/

>The platform is permission less. It's not very permissionless if you're required to pay a specific entity in order to mine a valid block. That's the opposite of permissionless.

Commented by /u/cryptocached in /r/btc on August 6, 2020 23:56:34
/r/btc/comments/i4z09d/does_anyone_know_if_amaury_is_safe/g0mdo7a/

Warrant canaries work best as a dead man's switch. A simple example: Each week a signed, time-stamped message is posted at a known location. If the message is not updated, the canary is considered dead.

Commented by /u/cryptocached in /r/btc on August 6, 2020 19:54:04
/r/btc/comments/i4wpop/so_abc_needs_ifp_funding_so_they_can_code_things/g0mbrez/

It's been a while, but yes I have. As I recall, as with most of these discussions, I had.concerns with many of his assumptions.

Commented by /u/cryptocached in /r/btc on August 6, 2020 19:35:30
/r/btc/comments/i4wpop/so_abc_needs_ifp_funding_so_they_can_code_things/g0mb4ij/

>But 99% is good enough for most things. Let's leave this as a rhetorical question: how can you calculate the percentage of currently active hash rate working to confirm a transaction you don't know exists?

Commented by /u/cryptocached in /r/btc on August 6, 2020 19:29:31
/r/btc/comments/i4wpop/so_abc_needs_ifp_funding_so_they_can_code_things/g0ma8sj/

>You're talking about miner colaboration wrt. DS. I'm not. At least not only. **Any** assumption that you can reliably detect the attempt before a block is produced is a false sense of security.

Commented by /u/cryptocached in /r/btc on August 6, 2020 19:21:11
/r/btc/comments/i510i5/unpopular_opinion_bitcoin_abcs_plan_for_upgrade/g0m1mb2/

Trust me, I'm always prepared for the dumbest fucking answer. I'm never disappointed and rarely surprised.

Commented by /u/cryptocached in /r/btc on August 6, 2020 18:04:52
/r/btc/comments/i4wpop/so_abc_needs_ifp_funding_so_they_can_code_things/g0m1g23/

>Do you know of any good way to ensure a higher safety margin for 0-conf txs? Not without compromising PoW-based Nakamoto consensus. There is a minimum risk implicit in the design of the system. A double spend of an unconfirmed transaction can be mined with a rate of success equal to the percentage of hash power attempting to do so. There is no requirement that the double spend ever be made public before it is mined. Any assumption that you can reliably detect the attempt before a block is produced is a false sense of security.

Commented by /u/cryptocached in /r/btc on August 6, 2020 18:03:22
/r/btc/comments/i510i5/unpopular_opinion_bitcoin_abcs_plan_for_upgrade/g0m0noz/

>IFP will secure the network because it will link the interest of the blockchain's maintainers to the success of the blockchain. Who are the blockchain's maintainers? Can you be more specific about who's interests are being served?

Commented by /u/cryptocached in /r/btc on August 6, 2020 17:56:33
/r/btc/comments/i4wpop/so_abc_needs_ifp_funding_so_they_can_code_things/g0m0aqn/

>What about Avalanche as a sort of a very effective Double-Spend (DS) detector? I don't believe it is very efficient at that, nor particularly effective for that matter. Willing to be proven wrong, but afaik this is just some shower thought that no one has put significant technical research in to. >Also, couldn't it also still be effective in syncing mempools without actually weakining POW? Same deal. Transactions already get broadcast to the network. Avalanche is a consensus protocol. Bitcoin is a consensus protocol. At best, using both just makes one or the other redundant.

Commented by /u/cryptocached in /r/btc on August 6, 2020 17:53:30
/r/btc/comments/i4wpop/so_abc_needs_ifp_funding_so_they_can_code_things/g0lxu9b/

The Avalanche protocol is plenty interesting. Using it for pre-/post-consensus on BCH is shit. All the various proposals for implementing it have had major weaknesses that leave the combined system vulnerable to capture or other abuses. Quite frankly this likely applies to any pre-/post-consensus, at least any that attempt to influence PoW consensus. The simple fact is, if nodes can achieve consensus using Avalanche, expensive PoW is redundant. If the consensus they can achieve with Avalanche (or other PPC) is insufficient then relying on it only weakens PoW consensus.

Commented by /u/cryptocached in /r/btc on August 6, 2020 17:32:54
/r/btc/comments/i4tnqr/question_about_8_funding_and_forks/g0lpi58/

No proof that can convince anyone else, anyway.

Commented by /u/cryptocached in /r/btc on August 6, 2020 16:26:57
/r/btc/comments/i4tnqr/question_about_8_funding_and_forks/g0lpb5u/

Ugh... Why don't you go back to murdering babies.

Commented by /u/cryptocached in /r/btc on August 6, 2020 16:25:26
/r/btc/comments/i4tnqr/question_about_8_funding_and_forks/g0lodbr/

This kind of IFP doesn't need any work. Miners are already free to assign the coinbase outputs how they like. If they want to give ABC 8% of all their new coins, they can already choose to do that.

Commented by /u/cryptocached in /r/btc on August 6, 2020 16:18:06
/r/btc/comments/i4qwmf/amaurys_endgame_run_his_own_coin_and_do_whatever/g0lnzix/

Mafioso Forks. _Nice chain you got there. It would be a shame if someone tried to split._

Commented by /u/cryptocached in /r/btc on August 6, 2020 16:15:10
/r/btc/comments/i4vgqq/bitcoin_abcs_8_miner_tax_will_go_only_to_amaury/g0lgfi2/

Like any help is needed

Commented by /u/cryptocached in /r/btc on August 6, 2020 15:17:59
/r/btc/comments/i4wpop/so_abc_needs_ifp_funding_so_they_can_code_things/g0lg0g3/

Never did, just didn't realize it. Avalanche PPC _sounds_ good, but the truth is it was always shit.

Commented by /u/cryptocached in /r/btc on August 6, 2020 15:14:55
/r/btc/comments/i4tnqr/question_about_8_funding_and_forks/g0laj6b/

It is to be a soft fork. Other clients are compatible with the announced ABC changes, but the blocks they produce will not be accepted by the ABC client - unless they also pay the 8% tax.

Commented by /u/cryptocached in /r/btc on August 6, 2020 14:36:24
/r/btc/comments/i4tnqr/question_about_8_funding_and_forks/g0kpvn3/

According to the ABC announcement: >The Coinbase Rule improvement is as follows: All newly mined blocks must contain an output assigning 8% of the newly mined coins to a specified address. Rules generally refer to consensus-level rules, otherwise it is an unenforced node policy. Pretty clear that ABC intends to reject blocks that do not pay the 8% tax.

Commented by /u/cryptocached in /r/btc on August 6, 2020 12:06:27
/r/btc/comments/i4tnqr/question_about_8_funding_and_forks/g0kjqla/

>Not that they want to, but could you have a functioning chain where blocks found running ABC divert 8% to address A, and blocks found running BCHN divert 3% to address B, and blocks found using Bitcoin Unlimited divert no funds. Short answer: yes. The fork is not caused by the payment occuring; that already happens in the coinbase transaction of every block. The fork is caused by rejecting blocks that don't pay to the preferred address.

Commented by /u/cryptocached in /r/btc on August 6, 2020 11:22:56
/r/btc/comments/i4rtd2/what_is_bchns_roadmap_is_it_the_same_as/g0kjaap/

>Abc would implement it tomorrow if they could. If they had a formal proposal of how it would be implemented the sham would be exposed. Avalanche PPC only works as a vapid promise of future greatness.

Commented by /u/cryptocached in /r/btc on August 6, 2020 11:19:37
/r/btc/comments/i4rtd2/what_is_bchns_roadmap_is_it_the_same_as/g0kcd56/

>We want an overview of strenghts and weaknesses of all preconsensus possibilities before committing to anything Well, I've got concerns with preconsensus in general, but am open to debating proposals as they come. Avalanche PPC is pretty clearly bullshit, so I hope that one can go in the trash bin of history. It will serve as a good example of the types of challenges any other preconsensus system would face.

Commented by /u/cryptocached in /r/btc on August 6, 2020 10:30:30
/r/btc/comments/i4rtd2/what_is_bchns_roadmap_is_it_the_same_as/g0k9mp7/

Avalanche PPC is vaporware. Smoke being blown up the asses of everyone who can't see past the rhetoric. If it ever were implemented it would not have the professed properties.

Commented by /u/cryptocached in /r/btc on August 6, 2020 10:10:58
/r/btc/comments/i4625d/bitcoin_cash_bch_november_2020_upgrade_statement/g0k98ju/

I've been waiting for over two years. Poking obvious holes in all the _it's not a proposal_ the whole time. Avalanche PPC is vaporware. Smoke being blown up the asses of everyone who can't see past the rhetoric. If it ever gets past vaporware stage it will not have the professed properties.

Commented by /u/cryptocached in /r/btc on August 6, 2020 10:07:56
/r/btc/comments/i4q3di/abc_in_november_two_improvements_will_be_made_to/g0k5zxc/

>Word is Amaury will not use Avalanche, but Snowflake. LOL. Although, with the required tax to a chosen address, sounds more like he wants his own Slush fund.

Commented by /u/cryptocached in /r/btc on August 6, 2020 09:44:15
/r/btc/comments/i4rtd2/what_is_bchns_roadmap_is_it_the_same_as/g0k4svu/

Hopefully they at least remove that Avalanche Preconsensus abomination.

Commented by /u/cryptocached in /r/btc on August 6, 2020 09:35:34
/r/btc/comments/i4625d/bitcoin_cash_bch_november_2020_upgrade_statement/g0k4ag2/

>Avalanche has no Sybil resistance on its own, so it still relies on PoW It is well accepted that Avalanche PPC **can not** use proof of work for sybil resistance. The early proposals that _claimed_ to do so were in fact using _prior proof of work_. This exposes the combined system to trivial capture strategies. >Avalanche pre-consensus won’t affect consensus. If Avalanche PPC won't affect consensus then it is impotent.

Commented by /u/cryptocached in /r/btc on August 6, 2020 09:31:51
/r/btc/comments/i4q7zz/abc_officially_forking_all_newly_mined_blocks/g0k1t08/

>BCHN would have to specifically add code to blacklist the ABC address. Or delay the DAA change.

Commented by /u/cryptocached in /r/btc on August 6, 2020 09:12:31
/r/btc/comments/i4qwmf/amaurys_endgame_run_his_own_coin_and_do_whatever/g0k05d0/

Interesting strategy that has some parallels to a discussion I had with u/tcrypt regarding forks with Avalanche PPC. https://www.reddit.com/r/btc/comments/i3uyxl/the_time_to_split_away_from_abc_control_is_right/g0emtil Focing the IFP creates an added disincentive post-fork for the non-IFP side to 51% attack the other. This approach eliminates the defensive strategy of preemptively rejecting Avalanche PPC.

Commented by /u/cryptocached in /r/btc on August 6, 2020 08:59:05
/r/btc/comments/i4625d/bitcoin_cash_bch_november_2020_upgrade_statement/g0it4zq/

>so long as it doesn't interfere with the PoW consensus mechanism So, yeah, about that... It either interferes with the PoW consensus mechanism or it doesn't do much of anything. >I'd need to see the details of how they intend to design it for implementation in BCH. Shouldn't that happen before it's on the roadmap?

Commented by /u/cryptocached in /r/btc on August 5, 2020 23:33:55
/r/btc/comments/i4625d/bitcoin_cash_bch_november_2020_upgrade_statement/g0ipb48/

>I don't think there's huge contention with the roadmap ABC put forward That Avalanche preconsensus thing is pretty shady.

Commented by /u/cryptocached in /r/btc on August 5, 2020 22:56:15
/r/btc/comments/i4625d/bitcoin_cash_bch_november_2020_upgrade_statement/g0ioc3m/

>At least the blocksize debate have pretty clear/easy to understand sides This one is pretty clear, too. Intentionally slow down block production for an arbitrarily defined period of time thereby reducing mining profitability and slowing confirmation times (ABC) or don't do that (everybody else).

Commented by /u/cryptocached in /r/btc on August 5, 2020 22:47:10
/r/btc/comments/i4buka/starting_gun_on_a_split_has_been_fired_splitting/g0iedhw/

>Do you just enjoy embarrassing yourself on this sub? Nah, he likes embarrassing himself in US Federal Court, too.

Commented by /u/cryptocached in /r/btc on August 5, 2020 21:16:36
/r/btc/comments/i4d5d7/after_the_november_upgrade_is_over_i_predict_that/g0i18x1/

Sounds like a buying opportunity, no?

Commented by /u/cryptocached in /r/btc on August 5, 2020 19:19:29
/r/btc/comments/i3o2re/do_supporters_of_the_grasberg_daa_also_have_a_way/g0hq57j/

It's ok. I'm feeding on his temporal force.

Commented by /u/cryptocached in /r/btc on August 5, 2020 17:45:55
/r/btc/comments/i4665s/bch_using_avalanche_not_possible_according_to/g0ho4re/

u/Contrarian__, I served with Vizzini. I knew Vizzini. Vizzini was a friend of mine. u/Contrarian__, you're no Vizzini.

Commented by /u/cryptocached in /r/btc on August 5, 2020 17:29:31
/r/btc/comments/i4665s/bch_using_avalanche_not_possible_according_to/g0hnjb8/

Aww, don't hate on u/Contrarian__ too much. I mean, sure he's a total dick. And he stirs so much shit he's beginning to pick up the stench. And he sometimes deletes posts to support the appearance of being a u/nullc sock. And his mother was a hamster. But besides all that, and a host of other negative qualities, he's not so bad. Like, I've never actually seen him murder a baby or anything.

Commented by /u/cryptocached in /r/btc on August 5, 2020 17:24:45
/r/btc/comments/i4665s/bch_using_avalanche_not_possible_according_to/g0hlimw/

We all know you have no peer.

Commented by /u/cryptocached in /r/btc on August 5, 2020 17:08:30
/r/btc/comments/i4665s/bch_using_avalanche_not_possible_according_to/g0hl56p/

>In BCH, the proposal is to use both proof of work and the Avalanche protocol. This doesn't make BCH better, it makes Avalanche worse. It is pointless and dangerous to have multiple consensus mechanisms resolving the same conflicts. One must take precedence over the other. Either PoW rules and Avalanche PPC does fuck all to secure zero-conf or Avalanche rules and expensive PoW is made redundant.

Commented by /u/cryptocached in /r/btc on August 5, 2020 17:05:28
/r/btc/comments/i4665s/bch_using_avalanche_not_possible_according_to/g0hjsbx/

>Further, the analysis was confirmed by the Avalanche process. It has been finalized. I would like to see the objective evidence of that.

Commented by /u/cryptocached in /r/btc on August 5, 2020 16:54:51
/r/btc/comments/i4d5d7/after_the_november_upgrade_is_over_i_predict_that/g0hjlkx/

>Currently all this talk of a split is stopping some investors from buying more Bitcoin Cash. Why would it stop them from buying more Bitcoin Cash? If there is a split they'd get coins from each side for every BCH they hold before the split.

Commented by /u/cryptocached in /r/btc on August 5, 2020 16:53:24
/r/btc/comments/i4665s/bch_using_avalanche_not_possible_according_to/g0hiic8/

_Some_ think I'm a Greg Maxwell sock puppet. Others think I'm [one of the more knowledgeable and technically competent contributors to this forum](https://www.reddit.com/r/btc/comments/f7mtlf/whatever_happens_in_all_this_amaury_should_be/fiief94). I suppose it isn't strictly necessary that those be mutually exclusive. u/500239, you'll need to make up your own mind on that.

Commented by /u/cryptocached in /r/btc on August 5, 2020 16:45:01
/r/btc/comments/i4665s/bch_using_avalanche_not_possible_according_to/g0he6ck/

An entirely different coin. It uses only the Avalanche protocol for consensus; no miners, no proof of work, no Nakamoto consensus. The problems I'm detailing are specific to shoehorning the Avalanche protocol for pre- and post-consensus on a PoW-based Nakamoto consensus system like BCH.

Commented by /u/cryptocached in /r/btc on August 5, 2020 16:12:10
/r/btc/comments/i4665s/bch_using_avalanche_not_possible_according_to/g0hdhwb/

>So long as your node is still connected to the network it should be notified within < 10 seconds of a double spend. Only if that conflicting transaction has been made public (and the other nodes aren't conspiring to hide it from you).

Commented by /u/cryptocached in /r/btc on August 5, 2020 16:07:16
/r/btc/comments/i4665s/bch_using_avalanche_not_possible_according_to/g0hd202/

>If you have some authoritative proposal then link me. **There is no authoritative proposal.** Avalanche PPC is vaporware. Smoke being blown up the asses of everyone who can't see past the rhetoric.

Commented by /u/cryptocached in /r/btc on August 5, 2020 16:04:00
/r/btc/comments/i4665s/bch_using_avalanche_not_possible_according_to/g0hcaf5/

>What would miners vote in for a transactions where a double spend does not exist? How do they know if a double spend has occurred? Let's explore this a little. If a miner only sees one of the transactions, they never even know to query the Avalanche network about it. They include the transaction in a block. Their block is rejected because the Avalanche network has actually voted in favor of a conflicting transaction, even though this miner never saw it. The block that they just spent all that work on is invalid according to Avalanche preconsensus since it contains a double-spend transaction. Was the preconsensus formed before the block was discovered? Impossible to objectively discern. This is before we even get to malicious actors intentionally messing with the preconsensus process. So what's a miner to do, query on every transaction and only mine those that are accepted by the preconsensus? Well that certainly introduces some new issues. Now the system is reliant on the Avalanche network reaching consensus on every transaction. If it fails to do so, no transactions can be mined. That's _one_ way you end up at empty blocks. Any cartel with voting power exceeding the BFT threshold can prevent the network from reaching consensus, forcing this state. Starting to see the problems here? This is still just scratching the surface.

Commented by /u/cryptocached in /r/btc on August 5, 2020 15:58:26
/r/btc/comments/i3nxag/amaury_if_you_are_intel_and_you_can_make_the/g0ha2r0/

More like a working hypothesis than an explanation.

Commented by /u/cryptocached in /r/btc on August 5, 2020 15:42:19
/r/btc/comments/i4665s/bch_using_avalanche_not_possible_according_to/g0h8kpz/

>My understanding is that avalanche is not even applied to every transaction, just on transactions that have found a double spend. There is no formal proposal on how to apply Avalanche PPC on BCH. What you describe is one way to implement it. It is broken. There have been other suggestions. They too are broken in similar though slightly different ways. In particular, Pacia's example of prior proof of work for sybil resistance is trivially vulnerable to capture by a temporary PoW majority. This approach has been pretty soundly rejected. >Lets clear up confusion on this part alone, since it's a fundamental rule. Is Avalanche applied to all transactions or just double spends? Who knows? That hasn't been decided yet. >I don't see how Obviously. If you're referencing Pacia's blog post as some sort of authoritative proposal you need to do a lot more research.

Commented by /u/cryptocached in /r/btc on August 5, 2020 15:31:25
/r/btc/comments/i4665s/bch_using_avalanche_not_possible_according_to/g0h6s3j/

>it makes 0 financial sense for majority of miners to mine empty blocks and get nothing from them. They defeat themselves. You don't understand this at all. Captured Avalanche PPC can make it so the _only choice_ honest miners have is to mine empty blocks. Well, that or stop mining the chain altogether. >Not to mention that for this attack to work they'd need to be majority and this case that would mean PoW has failed too. The Avalanche attacker only needs to exceed the BFT threshold. The cost to do that is finite and determined by yet-to-be defined parameters. >It's immune to random actors randomly flipping their consent around It is not immune to a concerted effort by a cartel that exceeds the BFT threshold. >Can I ask what's your background and if you're involved in developing for any crypto not just BCH? I'm a sock with googly eyes.

Commented by /u/cryptocached in /r/btc on August 5, 2020 15:18:23
/r/btc/comments/i460ds/the_1st_priority_should_be_to_not_hand_over_the/g0h54qi/

Are you here for price or for digital cash?

Commented by /u/cryptocached in /r/btc on August 5, 2020 15:05:51
/r/btc/comments/i3nxag/amaury_if_you_are_intel_and_you_can_make_the/g0h4vo8/

ABC wants to be the "good" guys.

Commented by /u/cryptocached in /r/btc on August 5, 2020 15:03:52
/r/btc/comments/i4665s/bch_using_avalanche_not_possible_according_to/g0h4onw/

>None of the above breaks any existing Bitcoin PoW rules. It undermines PoW. https://www.reddit.com/r/btc/comments/aazqec/question_about_avalanche/ecwbzuk With PoW you can demonstrate that one chain has accumulated more work than any other, objectively determining the state of consensus. One of the problems faced with Avalanche PPC is that you cannot objectively prove the state of the network. Furthermore, the Avalanche consensus process can be captured for a finite cost. Although you may _believe_ you have reached consensus with the rest of the network in step 2 above, once mined in a block, a captured Avalanche network can retroactivity alter the consensus, invalidating the work you've done to discover that block.

Commented by /u/cryptocached in /r/btc on August 5, 2020 15:02:17
/r/btc/comments/i3nxag/amaury_if_you_are_intel_and_you_can_make_the/g0h2yxe/

10% plus whatever is lost in a split over Grasberg.

Commented by /u/cryptocached in /r/btc on August 5, 2020 14:48:55
/r/btc/comments/i4665s/bch_using_avalanche_not_possible_according_to/g0h2ure/

If the miners can come to consensus on which of competing transactions is the double spend then there is no need for PoW.

Commented by /u/cryptocached in /r/btc on August 5, 2020 14:48:00
/r/btc/comments/i4665s/bch_using_avalanche_not_possible_according_to/g0guxrp/

>AFAIK I don't see any technical limitations that prevent Avalanche from working on BCH, nor has anyone provided any against. It would undermine PoW. You can't run competing consensus systems. One must take precedence.

Commented by /u/cryptocached in /r/btc on August 5, 2020 13:45:04
/r/btc/comments/i3nxag/amaury_if_you_are_intel_and_you_can_make_the/g0gu7q2/

I'm talking about BCH. https://medium.com/@Mengerian/avalanche-post-consensus-making-bitcoin-cash-indestructible-2464b1ae0382

Commented by /u/cryptocached in /r/btc on August 5, 2020 13:39:22
/r/btc/comments/i3nxag/amaury_if_you_are_intel_and_you_can_make_the/g0gsi5s/

>Avalanche is pre-consensus.. There is talk of Avalanche post-consensus, too. >It is meant to resolve double spend conflict.. meaning that it will be very rarely active while PoW is a permanent to advance the chain. That depends on how it is eventually implemented. >Weakening the chain does nothing to make Avalanche more « important » or « critical » for BCH.. Of course it does.

Commented by /u/cryptocached in /r/btc on August 5, 2020 13:26:39
/r/btc/comments/i3o2re/do_supporters_of_the_grasberg_daa_also_have_a_way/g0fmeib/

Really dangerous: yes. Gregory Maxwell: no. I'm a weapon of mass discussion.

Commented by /u/cryptocached in /r/btc on August 5, 2020 07:39:01
/r/btc/comments/i3uyxl/the_time_to_split_away_from_abc_control_is_right/g0euf2f/

Fair enough. Thanks for talking it out. Haven't considered this aspect much before.

Commented by /u/cryptocached in /r/btc on August 5, 2020 00:28:11
/r/btc/comments/i3uyxl/the_time_to_split_away_from_abc_control_is_right/g0eu5uw/

Not quite. In the event of a AvaPPC split, that ability to resist makes attacks against the Ava-minority less expensive (at least in terms of risk). But the Ava-majority side can deny that protection to the Ava-minority. Whereas in a "pure" NC split, neither side has that advantage. Diverting hash to a 51% attack leaves the attacker vulnerable. If I suspect I might end up on the Ava-minority side of some future split, it would be in my interest to reject AvaPPC.

Commented by /u/cryptocached in /r/btc on August 5, 2020 00:25:06
/r/btc/comments/i3uyxl/the_time_to_split_away_from_abc_control_is_right/g0etbha/

>So if you are concerned about such attacks, investing in a strong Avalanche PC would be wise. Only if you're always going to be on the Ava-majority side of any future split.

Commented by /u/cryptocached in /r/btc on August 5, 2020 00:15:16
/r/btc/comments/i3uyxl/the_time_to_split_away_from_abc_control_is_right/g0esgp6/

This gives an advantage to the Ava-majority side of the split. They can afford to divert more hash to attack the Ava-minority side since they're at less risk from a reciprocal attack. How is the Ava-minority side not worse off?

Commented by /u/cryptocached in /r/btc on August 5, 2020 00:05:33
/r/btc/comments/i3uyxl/the_time_to_split_away_from_abc_control_is_right/g0erjjs/

Isn't Avalanche PPC supposed to help in the event of a 51% attack?

Commented by /u/cryptocached in /r/btc on August 4, 2020 23:55:12
/r/btc/comments/i3qjhl/if_bch_wasnt_valuable_no_one_would_fight_over_it/g0erfz2/

I knew it, I'm surrounded by Assholes.

Commented by /u/cryptocached in /r/btc on August 4, 2020 23:54:04
/r/btc/comments/i3uyxl/the_time_to_split_away_from_abc_control_is_right/g0eqvhk/

They could do both and totally screw the minority side.

Commented by /u/cryptocached in /r/btc on August 4, 2020 23:47:41
/r/btc/comments/i3uyxl/the_time_to_split_away_from_abc_control_is_right/g0eq6mr/

>There's no "veto"ing, if an attack prevents Avalanche from finalizing then txs just go back to taking 10 minutes. That's vetoing the minority side's ability to use Avalanche. You made the point that mining a block on BCH doesn't affect BTC users' choices on their preferred network. It appears Avalanche PPC would allow for some degree of post-split control.

Commented by /u/cryptocached in /r/btc on August 4, 2020 23:40:07
/r/btc/comments/i3qjhl/if_bch_wasnt_valuable_no_one_would_fight_over_it/g0epvi6/

Oh, look at that, you fell for that too! I can't believe it, man!

Commented by /u/cryptocached in /r/btc on August 4, 2020 23:36:48
/r/btc/comments/i3nptc/does_amaury_insist_on_including_historical_drift/g0epsg0/

>Satoshi accomplished this as much as possible. Obviously not. He made a pretty straightforward DAA which offered a "best effort" that was good enough. >Satoshi meant for the coin emission to be predictable. It is predicable, within fixed margin of error.

Commented by /u/cryptocached in /r/btc on August 4, 2020 23:35:51
/r/btc/comments/i3uyxl/the_time_to_split_away_from_abc_control_is_right/g0epep1/

>If such an attack were to happen and succeed then the network would gracefully degrade to work as things do now. So, if I'm getting this right, when sufficiently unbalanced the majority side of the split can effectively prevent the minority from utilizing Avalanche PPC. At least until the minority reconstitutes their Avalanche network by excluding pre-split stakeholders. Sounds like that gives the majority side veto over some things on the minority side, if not a positive vote.

Commented by /u/cryptocached in /r/btc on August 4, 2020 23:31:43
/r/btc/comments/i3uyxl/the_time_to_split_away_from_abc_control_is_right/g0enfyt/

>If the network splits then the Avalanche network splits. And participants staked in before the split can vote in both networks? >Avalanche nodes don't vote on rules they vote on order of txs that are valid under that node's rules. If a sufficient number of pre-split participants favor one side over the other, could they mess with the ability of the disfavored side's Avalanche network to reach consensus?

Commented by /u/cryptocached in /r/btc on August 4, 2020 23:11:17
/r/btc/comments/i3uyxl/the_time_to_split_away_from_abc_control_is_right/g0emtil/

So what happens to Avalanche PPC when these types of incompatible splits occur?

Commented by /u/cryptocached in /r/btc on August 4, 2020 23:04:54
/r/btc/comments/i3uyxl/the_time_to_split_away_from_abc_control_is_right/g0em6hx/

>In the "bch is Bitcoin" sense? That's right.

Commented by /u/cryptocached in /r/btc on August 4, 2020 22:58:23
/r/btc/comments/i3nxag/amaury_if_you_are_intel_and_you_can_make_the/g0elqbz/

>how Avalanche is related to PoS The problems with using prior proof of work for Avalanche sybil resistance are too evident to sweep under the rug. Coin age or other PoS mechanisms are now being proposed. >I don’t see how deift correction lead to PoS Increased average block times and the resulting reduction to mining profitability and hash power work to push the narrative that Avalanche PPC is vital to the survival of BCH. See above how Avalanche PPC is related to PoS.

Commented by /u/cryptocached in /r/btc on August 4, 2020 22:53:53
/r/btc/comments/i3uyxl/the_time_to_split_away_from_abc_control_is_right/g0ekw8n/

Mining a BCH block is voting for Bitcoin users to accept big blocks.

Commented by /u/cryptocached in /r/btc on August 4, 2020 22:45:32
/r/btc/comments/i3uyxl/the_time_to_split_away_from_abc_control_is_right/g0ek5zh/

If you're voting on current state, isn't that effectively voting on changes to state mutation rules?

Commented by /u/cryptocached in /r/btc on August 4, 2020 22:38:04
/r/btc/comments/i3uyxl/the_time_to_split_away_from_abc_control_is_right/g0ejnrp/

>I'm not advocating for any sort of voting at all. Except within Avalanche PPC.

Commented by /u/cryptocached in /r/btc on August 4, 2020 22:32:59
/r/btc/comments/i3g6eq/the_story_of_how_bchs_daa_came_to_be/g0eix87/

>Amaury pushing through his idea against better proposals, though. It's cool. Craig Wright signed off on it. High confidence.

Commented by /u/cryptocached in /r/btc on August 4, 2020 22:25:30
Top