Gold collapsing. Bitcoin UP.

sickpig

Active Member
Aug 28, 2015
926
2,541
If we'd forked SV code from BU or XT instead of ABC this would be a non issue. In fact we could sit questioning why ABC made a code change to remove ARP.
Why did you fork frm ABC rather than from BU/XT then?

ABC did not remove ARP. The commit made by @Mengerian it's just part of the normnl APR code maintainace.

Namely, for a client that support current set of rules and that implement the next upgrade rules and activation code, APR trigger need to be moved to the date/time of the next next upgrade. This what mengerian did.

Having said that, the SV commit which remove ARP was not as thorough as it should have been in fact it just change an "if" statement in interpreter.cpp rather than remove all the machinery that comes with APR, e.g. isReplayProtectionEnabled and Friends. Why you chose to do it that way?

You really are stretching here @sickpig .
Could really well be that I'm stretching, not my intention thou. Feel free to ignore my posts.
 
Feb 27, 2018
30
94
@shadders What is the plan with replay protection going forward? Is SV going to restore the satoshi sighash algorithm or stick with the Segwit-like sighash digest system that it's using right now?

I heard there was some plan to restore original Satoshi mechanisms but it's not clear to me how far that goes...
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
i thought he said he was going to stick with it b/c it solves the sighash attack vector?
 

Peter R

Well-Known Member
Aug 28, 2015
1,398
5,595
@cypherdoc:

Other people in the BSV camp disagree that quadratic hashing is a bug or an attack vector.

Quadratic hashing means that it takes a lot more time to validate very large non-standard transactions with lots and lots of inputs. Some people see this as a good thing, because miners will thus have to charge higher fees for such transactions to offset the added orphaning risk, thereby discouraging their use. Transactions with lots and lots of inputs are less "cash like" than normal transactions with only a few inputs and so discouraging their use is a good thing. Removing quadratic hashing the way BCH did is thus a subsidy to the people who use these huge non-cash-like transactions, in the same way that DSV is a subsidy.

If you think the slowness of the old sighash is an "attack vector," then is not the slowness of using script to implement DSV also an "attack vector"? In both cases, we're talking about transactions that have a high validation cost. The BSV supporters argue that DSV ought to have a high validation cost because such transactions are less "cash like" than normal bitcoin transactions. By the same logic, non-standard transactions spending huge amounts of inputs are also less "cash like" than normal bitcoin transactions and ought to have a high validation cost too (according to the BSV logic).

I don't completely agree with the above logic, but I don't completely disagree either. But I hope that we can at least try to be consistent in our arguments.
 
  • Like
Reactions: majamalu

Richy_T

Well-Known Member
Dec 27, 2015
1,085
2,741
Why do people with thousands or tens of thousands of followers protect their twitter account? It's not like they can personally know all of their followers who they deem trustworthy enough to view their tweets. First JVP and now CSW. I don't use twitter for posting but I used to read what those guys tweeted.

Makes the "inner circle" feel special, perhaps?
 
  • Like
Reactions: majamalu

majamalu

Active Member
Aug 28, 2015
144
775
I'd rather lose wealth making the choice I believe in than profit off the opposing side winning, especially when the battle is fought with money like it at least partly is here and so my betting on the opposing side is actually harmful to my own cause.

On the other hand: maybe I'm just overly optimistic and that's why I act so decisively. And I take the point about keeping powder for another battle, which I do, but not to a large enough extent. It's impatience maybe.
Yeah, it's a delicate balance.

My btc holdings have been gradually decreasing. Every time the price gap widened significantly, I sold some btc in exchange for bch. I have not finished yet.

I would have preferred an instant flippening, of course, but I deemed it extremely unlikely because of inertia, the power and determination of the usurpers, and the cluelesness of the new horde of "investors".

I have a similar plan for bsv: I will continue to sell gradually in exchange for bch, perhaps at a faster pace. But I will never let my holdings fall below 50% (btc or bsv).

That said, I wish the best to the Bagatells of Cryptoland. I am aware of the importance of their role:

https://honest.cash/Moeb/about-forks-selection-mechanisms-and-benfords-law-of-controversy-525
 

Peter R

Well-Known Member
Aug 28, 2015
1,398
5,595
I think the important point in the "replay protection" discussion is the following:

The fact that BSV modified the source code to remove the replay protection shows that they intended to make the transactions replayable (probably because they thought there would only be a single chain).
 

shadders

Member
Jul 20, 2017
54
344
Or perhaps it showed that we didn't want to make every single wallet and application that signs transactions incompatible during a time where there was already plenty of uncertainty... Use some common sense Peter.

Who has said we want to reintroduce quadratic hashing?

Maybe we should also put back the original op code bugs that allowed minting billions of new coins as well?

@sickpig I guess we just did nominal Apr code maintenance also. Honestly it's not hard to work out the answers to these questions if you stop looking for demons and just use a bit of common sense.
 
  • Like
Reactions: Windowly and Norway

nivexous

New Member
Apr 13, 2018
2
4
github.com
@cypherdoc:

Other people in the BSV camp disagree that quadratic hashing is a bug or an attack vector.

Quadratic hashing means that it takes a lot more time to validate very large non-standard transactions with lots and lots of inputs. Some people see this as a good thing, because miners will thus have to charge higher fees for such transactions to offset the added orphaning risk, thereby discouraging their use. Transactions with lots and lots of inputs are less "cash like" than normal transactions with only a few inputs and so discouraging their use is a good thing. Removing quadratic hashing the way BCH did is thus a subsidy to the people who use these huge non-cash-like transactions, in the same way that DSV is a subsidy.

If you think the slowness of the old sighash is an "attack vector," then is not the slowness of using script to implement DSV also an "attack vector"? In both cases, we're talking about transactions that have a high validation cost. The BSV supporters argue that DSV ought to have a high validation cost because such transactions are less "cash like" than normal bitcoin transactions. By the same logic, non-standard transactions spending huge amounts of inputs are also less "cash like" than normal bitcoin transactions and ought to have a high validation cost too (according to the BSV logic).

I don't completely agree with the above logic, but I don't completely disagree either. But I hope that we can at least try to be consistent in our arguments.
This is literary the first time I've seen this argument Peter, and it doesn't resonate with anything I've heard in BSV. I would disagree with it too. Transactions that consolidate lots of inputs should be very cheap if not free. You and sickpick were the first ones I recall to suggest BSV revert to the original sighash and it looked pretty passive-aggressive at the time. Who else argued for it?
 
  • Like
Reactions: AdrianX and bitsko

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
Other people in the BSV camp disagree that quadratic hashing is a bug or an attack vector.
i was talking about keeping the segwit fix in terms of fixing the quad hash attack vector. i think SV should retain it. before the fix, this attack was a major concern for the BTC community. i'm not sure it was entirely rational as it was stimulated be the f2pool 1MB single non std 25s validation block from 2015. it seems they were only reducing their UTXO set and perhaps harvesting dust brainwallets. no harm done and not apparently malicious. but if one is routinely going to send high #input tx's then yes they should be charged accordingly.
 

Zarathustra

Well-Known Member
Aug 28, 2015
1,439
3,797

r/btc degraded into an echo chamber. As soon as you post opinions of intelligent people of 'the other side', the Judean People's Front downvotes it immediately and makes it invisible.
I'm now forced to go to the twitter shit media to enjoy interesting discussions of the people who got ostracized from Roger's echo chamber. Our Bitco.in forum should also gain traction now. Welcome @nivexous!
 

sickpig

Active Member
Aug 28, 2015
926
2,541
@sickpig I guess we just did nominal Apr code maintenance also
You would had just changed the time trigger then, but this is not what happened.

WRT the signature scheme: I've heard multiple time from CSW that Bitcoin should go back to ver 0.1.0 and then freeze the protocol.

You have a point in saying that of course that SV has no interest in re-introducing the bugs that were fixed along the way. This is pretty obvious.

Regardless, I think that @Peter R raised a valid point, previous to your post above it wasn't clear to me if the quadratic hashing behavior was something SV considered a feature rather than a bug.

Thanks for clarifying.

Or perhaps it showed that we didn't want to make every single wallet and application that signs transactions incompatible during a time where there was already plenty of uncertainty... Use some common sense Peter.
Again @Peter R it's not the one proposing to SV to add reply protection if memory serves Calvin Ayre proposed it. Quoting from this CoinGeek article http://archive.is/b5aR6

Calvin Ayre circa 25 of November 2018 said:
“One aspect of stability is replay protection. Since ABC has not made this stability a priority, Bitcoin SV will do so in order to restore confidence to users and businesses on both chains. This change will require the Bitcoin SV team to work with the Bitcoin ecosystem, and the timeline will be announced when there is adequate ecosystem readiness.”
Wisely enough Calvin said that this kind of change has to be coordinated with all the ecosystem and that time is needed. What I find weird is that this seems not to be the plan anymore, at least according to latest Calvin's tweets, namely:

http://archive.is/rAqJ6
Calvin's tweet 1 said:
this is not over until the perpetrators (ABC conspirators) remerge the chains or enact replay protection to permanently split them. Roger, do the right thing now that its clear that you were part of causing this mess. You break it you own it.
http://archive.is/jl2tR
Calvin's tweet 2 said:
Someone just tweeted that this hash war has to stop...actually, it never should have been started by ABC conspirators and ABC now need to enact replay protection ASAP and all exchanges need to force this or delist them as its now clear this mess was entirely of their making.
Lastly,

Honestly it's not hard to work out the answers to these questions if you stop looking for demons and just use a bit of common sense.
I'm not looking for demons and probably I don't have enough common sense. So I could use some help in responding my questions. They were no rhetorical.
 

Norway

Well-Known Member
Sep 29, 2015
2,424
6,410
@sickpig
[doublepost=1544453484,1544452838][/doublepost]Like I have said on twitter, it took me 10 seconds to solve this doublespend attack after I read about it on friday.

The attack is based on asymmetrical information about which nodes are closest to mining. All the doublespend alert system needs to do, is to obtain the same information to be able to give doublespend alerts.

I get the impression that developers from BU and XT want doublespends to be a problem so they can fix it by changing the communication between nodes.

The quick and swift fix from HandCash show that these problems are better solved by incentivized parties.
 

Members online

No members online now.