Ok, I thought maybe I made a mistake when moving the thread last time.
just out of curiosity - I am not a techy at all - is there any urgent need to get rid of transaction malleability in Peercoin? Is a fix needed for Peerassets?
If there is no urgent need, we could simply postpone the decision whether to use Segwit or not as a malleability fix for another several years, and watch the ecosystem evolve.
As a backbone currency, we should be very conservative, and better choose no path at all than the wrong one.
3 Likes
The issue is two fold:
-
Lightning Network and other industry standards rely on segwit. Whether we adopt or not, we will make a statement either way. Adopting makes the statement that ‘Peercoin is ready to modernize and be on the cutting edge again’. Not adopting makes the statement that ‘Peercoin does not support the questionable tech development that is segwit and we will find and follow alternative solutions’. Because we need updates like HD wallet UI, not choosing is not an option. We must either pull from currently existing code or make our own. To not choose is to stagnate and deprive Peercoin users of unquestionably desirable updates (like HD wallet).
-
Segwit is becoming an integrated part of Bitcoin core protocol. If we choose not to support it, we will need to follow an alternative implementation like BitcoinABC. If our chosen project doesn’t survive, it puts Peercoin in a bad position. So the question of which implementation and developer group is the most long term stable becomes important to the discussion. This of course becomes a political debate.
Ultimately, we cannot afford to not chose. Projects are taking sides, and we lose our edge the longer we stagnate. We are at a crossroads and choosing neither means we sit idle as the world passes us by. Peercoin has always pulled from Bitcoin core to update, so the default is to adopt segwit. The question is if we have hit a point where we need to consider pulling from a different project.
8 Likes
Excellent summary.
1 Like
This thread been open since November should have decided by now I agree with nagalim
To be fair, we’ve been discussing segwit since around 2016. Here it is in June 2016, where @peerchemist took the ‘wait and see’ perspective.
1 Like
Also, I’d like to point out that the question seems to have changed since @hrobeers proposed it. It used to be a question of what tech we adopt. It has evolved (devolved?) into a question of what dev team to follow. Over all, this question is a very nuanced one and cannot be answered in a succinct fashion for all time. Instead, we must struggle with this general question until we take our own reins on the tech, which is unlikely as long as compatible, open-source projects like Bitcoin are still doing the heavy lifting. There is no universal answer to this question of leadership, but there must be an immediate answer to the question of segwit.
I’m in favour of Segwit
I’m glad for this original post by hrobeers. I’ve never seen the malfix options laid out so clearly.
As a developer, generally i think simpler is better, where possible. Simple Mal Fix would work on all transactions with hard fork. The change is with the txid calculation.
SegWit and the FlexTrans solutions only provide malfix for the new tx types.
Does anyone know of a *coin which has implemented the “Simple Malleability Fix” in production? I know bitcoin cash/bitcoin-abc hasn’t. It would be a tech and marketing win if Peercoin was able to do it, but i don’t think we have those dev resources.
So SegWit is the only one significant in the wild / in production now on Bitcoin core, Litecoin and others. Maybe this is a case where the technology has to stay on DC power for a generation before going to AC power infrastructure.
2 Likes
I have moved some posts out of this thread as they were off-topic. Let’s stay on topic please.
Here is a discussion of Simple Malleability Fix vs. FlexTrans in /r/btc which includes the devs
1 Like
I don’t know, at the end of this review, i feel like all the different fixes have some technical merits. But the only one tested in production is the SegWit code.
1 Like
Technically, i changed my mind after reviewing more on FlexTrans - it may be more simple that “Simple Malleability Fix” because it only changes the transaction format. It doesn’t add a second txid/utxid like SegWit and Simple Mal Fix, which would complicate node and client code in a different way.
Simple MalFix is not complete with the current code (see Tom Zander comment):
This introduction of a second ID for transactions seems to have a wide ranging set of effects, from your commit messages it seems that this means a node can no longer accept transactions it does not have the parents of, because it becomes impossible to ask the sending node for them like Bitcoin does today.
Basically the decision is to use 2 txids (txid + wtxid|utxid) (SegWit and Simple MalFix), or use a single txid + tx version (FlexTrans v4).
However, nothing uses it except Tom Zander’s abandoned Bitcoin Classic testnet code. That goes against the Peercoin objective to be a drop-in Bitcoin replacement.
I can see why Bitcoin Cash still hasn’t implemented Simple MalFix. Its weird cause i think they changed signatures already but no malfix.
I was happy that Peercoin is going to implement RFC #0004 Remove Transaction Timestamp, because the raw tx format would now match Bitcoin’s (as well as simplifying and fixing the code). The only wrinkle is that Peercoin uses 1e6 “satoshis” per coin vs. Bitcoin’s 1e8 satoshis per coin, which affects serialization of the raw tx outputs (by client apps, not so much the nodes).
Original Bitcoin raw tx format:
nVersion|txins|txouts|nLockTime
Original Peercoin raw tx format:
nVersion|txTimestamp|txins|txouts|nLockTime
SegWit raw tx format:
nVersion|marker|flag|txins|txouts|witness|nLockTime
Simple Mal Fix Bitcoin raw tx format (replaces inputs txid with utxid):
nVersion|txins|txouts|nLockTime
FlexTrans format with CMF (main sections, but token order is flexible)
Transaction|Signatures|TxEnd
Possible CMF Tokens (could be easily extended later):
TxEnd,TxInPrevHash,TxPrevIndex,TxInputStackItem,TxInputStackItemContinued,TxOutValue,TxOutScript,TxRelativeBlockLock,TxRelativeTimeLock,CoinbaseMessage,NOP_1x
I don’t know why i went into all this, i just wanted to dig deeper and document on the technical stuff, which was part of the original post point. We are in a decentralized network space, things are not just engineering matters, consensus matters, and people vote with their feet.
3 Likes
FlexTrans was our first choice as well, however it got abandoned.
Segregated Witness Removes One of Bitcoin’s Data Integrity Checks
Is it possible to follow a non-segwit based project and then change later?
One of the strengths of not being the first-mover is we can wait until a lot of these “ifs” go away.
We started the discussion of segwit 2 years ago, with the ‘wait and see’ attitude that you are describing. The issue is that the farther we go down a path the more momentum we build against reverting. This is especially true for segwit, or a hardfork, but it is also true for any code change. If we follow one project for a while, then revert and follow the other, it triples the work over just following one path. 1. The initial work to follow the non-segwit project. 2. The work to revert back to the forking conditions. 3. The work to follow the segwit project. This is a highly inefficient use of our developers’ time. Almost no matter how you look at it, the crypto community is at a fork over segwit, and you either have to choose a direction and stick with it or flounder, stagnate, and disappear.
As a point of curiosity, would you be able to come up with any abstract criteria for when would be a better time to make this decision?
1 Like
Well, as you point out not making a decision is kind of decision in itself. If this was not the case I would say the right time would be to see whether BCH or BTC becomes the market leader and which layer 2 solution gets adoption.
At this point I would say that Bitcoin Cash will probably going to win and LN is not going to be useful for a numbers of years if ever.