Topic: Armory and Segwit2x (Read 1094 times)

You should try to not make any transactions around August 1st. That means both make and receive as you can easily be tricked into thinking you have money when you don't or your transactions may not be confirmed when you think it has been. If you have miners, then read up on what all of the proposals are and point your hashrate towards a pool that mines the proposal that you support.

Please, make it a bit  more explicit. Does it mean I should shut down my miners? Or just try to avoid any send /receive transaction from / to my wallet? And what about activities on  altcoins - btc Exchanges?

That was for the case UASF split would happen. Think thats already history with segwit2.x now.

Seems that segwit2.x will get 90%+ mining support so i wouldn't worry much about other possible chains.

Armory should not be affected at all. Just works on top of the node software you use.
I would not suggest using segwit from the day segwit2.x activates. Could be unsafe if other chains would exists. ( Same for UASF ).

Segwit2.x is a Softfork as well. 3 Months later they want to HF to 2MB. Till that Core/BU/Classic/many other noes should work also ( depending on the software with or without segwit ).

Its a mess right now but most is just FUD and panic creating. Minority chains are unlikely to survive with long confirmation times and huge backlogs ( replay ). Mining support drops fast as the income will drop.
The users able to "double spent" will drop their coins on the minority chains ( if they ever confirm on those chains ).

So im running 0.96. Everything should be fine come a possible hard fork?

I have no idea. I just wanted to point out that there are many more forking possibilities at the end of July/beginning of August.

I read that drivel. I assumed since they are signaling for 2x that this was the usual empty threat. Are they doubling down on this garbage?

There's also Bitmain's UAHF too. That means that there are now a large number of possible chain forks.

That's not enough on its own but the environment is in good condition for tainting. If a given tx has a different priority on the different sides of the fork, you can play that. Create a RBF flagged tx with a fee that's just right so that the probability it will mine on chain #1 is high, and low on chain #2.

Once it mines on #1 but still remains unconfirmed on #2, you have a window to double spend the tx on chain #2 (to another address), which a massive fee. If it mines on #2 (we're assuming one chain is fast while the other is slow cause of the split, so it may take a while to get that confirmation on #2), you have tainted coins on each side of the fork.

In general, whenever a fork results in effective different throughput on different branches, this is a low risk trick to taint your coins yourself. Otherwise you need to get your hands on outputs that descend from coinbase rewards of post split blocks, which aren't even available for the first 100 blocks.


Clowns... why even bother?

Part of Segwit2x is BIP 91. BIP 91 specifies that once it activates (requires 80% signalling on Bit 4 for a period of 336 blocks), all blocks must signal for segwit on Bit 1 so that segwit activates via the current BIP 141 deployment. Then later they will fork to 8 MB block weight (2 MB legacy block size) after block 485218. Of course this can all only be found out by looking at their code and pull requests as they have no documentation to speak of, AFAIK.

No. The only way to avoid replay to have the transaction ids that create your outputs to be different. Transactions that confirm on both chains, regardless of block height, will still have the same txid and thus are still vulnerable to transaction replay.

BIP148 requires that at least some miners support it, but I guess they have enough for a kind-of-viable chain, and hope to attract the rest for economical reasons.

\begin{rant}

What an amateurish mess.  The original argument for inventing SegWit instead of increasing the block size (and fix the malleability issue in the same hardfork) was that it risked creating a split chain.  Now the same people are actively trying to split off a new chain, and so is everybody else apparently.  And this will even create the worst kind of split, where one chain may eliminate the other at some random future time.  And the main priority of all parties seem to be to avoid that the other people's solution will gain support, since the other part of the debate is clearly "wanting to destroy bitcoin" / "just evil" / "controlled by bankers" / NSA / bug-eyed monsters (ok, maybe not).  No wonder some altcoins are gaining traction 

\end{rant}

I advise keeping a low profile around 1. august.  Make sure you control your own keys, i.e. withdraw money from trading accounts and online wallets.  Do not plan to spend your bitcoins until the dust has settled.  And let us hope that only one chain survives, that will be simplest.  If more than one survives then with a bit of luck it will be a matter of replacing the backend (Bitcoin Core) to select which chain Armory is using (yes, I am probably being naive).

Serious off-topic question:  Post chain-split, if I send coins to myself and the transaction is relayed to all chains, then it is very likely that the transactions will confirm in different block numbers on the different chains.  Will that be enough to split the coins so they can be disentangled?

All pre fork coins are available on on both chains. All post fork transactions will most likely be replayed on the other chain unless you taint your coins. I had a thread from around the BU stunt on how to taint your coins during a fork, dig it up if you want detailed instructions.

You can operate on the branch you wish by running Armory against the relevant node.

-----------
As for how this mess will unfold, I haven't really paid attention to it. If the SegWit2x side is actually signaling BIP9 SW activation, then neither BIP148 nor 0.13.1+ Core nodes will fork off come August first. They will fork later when the SW2x side tries to HF the block size however, whenever that is.

-----------
If the SW signaling portio of SW2x is different from BIP9 SW on purpose (they probably want to bake in the 2x HF in the signaling), legacy nodes won't be able to tell the difference for the SW activation part (basically they will never acknowledge SW was activated on the 2x chain), and there will be technically 3 chains:

1) Legacy
2) BIP148
3) SW2x.

Admittedly, we're not back 6 months ago when 40% of miners were not signaling for any proposal, so the legacy branch will die on the spot, leaving the 2 contenders. In this case, you have to be wary of wipeouts.

Basically, SW2x can't wipe out BIP148 because of BIP148's flag day, but if BIP148 catches up in hash rate to SW2x before the 2x HF, their chain will be wiped out.

This scenario also implies users would have to run the SW2x nodes. Considering were are less than a month away from the signaling and I as a wallet dev have no idea how they gonna signal, where and how they plan to maintain the code and who is dealing with this stuff, I'd say their communication is underwhelming and their time frame amateurish (to remain polite).

-----------
I got no idea how long these 2 chains would coexists. The question isn't whether the BIP148 crowd will give up, that basically won't happen. Rather it's a matter of how long miners want to run with the 2x chain.

As I got it  on Aug 1st one more protocol will be activated i.e UASF (BIP148). It meens that the chain will split into two parts,  one of them supporting  SW2x and the other one supporting UASF. What should I expect in this case as the holder of btc  on addresses of  Armory 0.96?

That's supposed to happen, but it should continue with some other stuff and with more block files.

Is Bitcoin Core running? Is it synced? What does ArmoryQt show?

So long as the unsigned transaction format does not change and you don't use any of the new script types and signing requirements don't change, then yes, that is fine.

Just to get it right: If I use an RaPi as a coldwallet to sign tx, that are made with a watch-only hot-wallet on my online pc, just the online-version has to be up-to-date, right? The RaPi can stay 0.93 forever, correct? I guess i cant use the advantages of segwit transactions then, but thats not so important for long-term holdings.

I did that, now the ArmoryDB.exe started again and showing these command lines:



<../DatabaseBuilder.cpp:268> parsed block file #38
<../DatabaseBuilder.cpp:268> parsed block file #40
<../DatabaseBuilder.cpp:268> parsed block file #42


and so on..
It stopped at

<../DatabaseBuilder.cpp:268> parsed block file #48

That error is standard when upgrading from Armory 0.93.3 to anything more recent. Go to the Armory data directory (default on Windows is C:/Users//AppData/Roaming/Armory). In that folder there should be a folder named databases. Either delete it or rename it. Then start Armory.

I do not know where to find dbLog.txt

But a command window opens, directory: C:/Program Files /Armory/ArmoryDB.exe

It says in the last line:


ERROR - <../lmdb_wrapper.cpp:433> DB version mismatch. Use another dbdir!

What is the error? Can you post the dbLog.txt file?

How can I fix the DB error?

You will not be able to use 0.93.3 on with segwit2x. Segwit2x is a hard fork and the clients that support it will be introducing things that are incompatible with Armory 0.93.3, namely segwit. If you want to use Armory after segwit2x activates (or on the segwit2x chain if there is a chain split), you will need to upgrade to at least Armory 0.95.1.