goatpig

Legendary



Offline



Activity: 2646

Merit: 1172



Armory Developer







ModeratorLegendaryActivity: 2646Merit: 1172Armory Developer Re: Bitcoin Cash (BCC) and Armory July 24, 2017, 12:02:14 AM #7 Armory does not verify on chain tx. It does not process scripts unless it's for its own signing purposes. No amount of new op codes would make a difference. The only thing that matters is block serialization on disk and the P2P layer. https://btcarmory.com

achow101

Legendary



Offline



Activity: 2254

Merit: 3456





bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl







StaffLegendaryActivity: 2254Merit: 3456bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl Re: Bitcoin Cash (BCC) and Armory July 24, 2017, 03:05:32 AM #9 Quote from: Casimir1904 on July 24, 2017, 01:42:20 AM So Armory should just work with BitcoinABC as node?

Assuming that they don't change the transaction format or make it impossible to make legacy transactions (i.e. transactions that you make now), then Armory should work just fine. It would be very stupid of them to not accept legacy transactions since it would mean breaking all unconfirmed and timelocked transactions at the time of activation.



Quote from: seyola89 on July 23, 2017, 11:29:36 PM I just read on their reddit:

"We are currently considering accepting only such protected transactions (currently it is still possible, by opting for it, to get non-SIGHASH-FORKID transactions relayed and mined).

Interested parties are encouraged to read REQ-6-1 , REQ-6-2 and REQ-6-3 of the UAHF specification."

Considering that they are still trying to figure out what they want to do, I suggest that you wait until after they fork off before figuring out what you can do to avoid transaction replay.



Either way, Armory does have some replay protection built in, in the form of the transaction lock time. Armory will set the transaction's locktime to be that of the block height at the time the transaction is created. This means that the transaction can only be included in blocks which have a height greater than or equal to the specified locktime. When Bitcoin ABC forks, they will almost definitely have a minority hashrate so their blockchain will grow more slowly (although they do have a difficulty adjustment thing), so their blockchain will be at a lower height for a while. So while their blockchain is at a lower height, you can make a transaction on the main chain and it will have a locktime block height greater than that of the ABC's chain height. Once that transaction confirms, you just move to the ABC chain and make the same transaction there, but without the locktime. The second transaction would be a double spend on the main chain, and it should confirm before the first transaction is able to on the ABC chain. Once both transactions are confirmed, your coins are split. Assuming that they don't change the transaction format or make it impossible to make legacy transactions (i.e. transactions that you make now), then Armory should work just fine. It would be very stupid of them to not accept legacy transactions since it would mean breaking all unconfirmed and timelocked transactions at the time of activation.Considering that they are still trying to figure out what they want to do, I suggest that you wait until after they fork off before figuring out what you can do to avoid transaction replay.Either way, Armory does have some replay protection built in, in the form of the transaction lock time. Armory will set the transaction's locktime to be that of the block height at the time the transaction is created. This means that the transaction can only be included in blocks which have a height greater than or equal to the specified locktime. When Bitcoin ABC forks, they will almost definitely have a minority hashrate so their blockchain will grow more slowly (although they do have a difficulty adjustment thing), so their blockchain will be at a lower height for a while. So while their blockchain is at a lower height, you can make a transaction on the main chain and it will have a locktime block height greater than that of the ABC's chain height. Once that transaction confirms, you just move to the ABC chain and make the same transaction there, but without the locktime. The second transaction would be a double spend on the main chain, and it should confirm before the first transaction is able to on the ABC chain. Once both transactions are confirmed, your coins are split. GitHub | GPG Key Fingerprint 0x17565732E08E5E41 Bitcoin Core contributor | Tip Me!: bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl

Casimir1904



Offline



Activity: 209

Merit: 100





Radix-The Decentralized Finance Protocol







Full MemberActivity: 209Merit: 100Radix-The Decentralized Finance Protocol Re: Bitcoin Cash (BCC) and Armory July 24, 2017, 09:55:41 AM #10 Quote from: achow101 on July 24, 2017, 03:05:32 AM Either way, Armory does have some replay protection built in, in the form of the transaction lock time. Armory will set the transaction's locktime to be that of the block height at the time the transaction is created. This means that the transaction can only be included in blocks which have a height greater than or equal to the specified locktime. When Bitcoin ABC forks, they will almost definitely have a minority hashrate so their blockchain will grow more slowly (although they do have a difficulty adjustment thing), so their blockchain will be at a lower height for a while. So while their blockchain is at a lower height, you can make a transaction on the main chain and it will have a locktime block height greater than that of the ABC's chain height. Once that transaction confirms, you just move to the ABC chain and make the same transaction there, but without the locktime. The second transaction would be a double spend on the main chain, and it should confirm before the first transaction is able to on the ABC chain. Once both transactions are confirmed, your coins are split.



Still a risky thing what could need several attempts.

1. TX on the main chain with low fee what would confirm on the main chain but not on the ABC chain.

2. Once TX confirmed on the main chain, double spent on the ABC chain with high fee.



That was my plan for possible splits without replay protection.



Quote from: achow101 on July 24, 2017, 03:05:32 AM Assuming that they don't change the transaction format or make it impossible to make legacy transactions (i.e. transactions that you make now), then Armory should work just fine. It would be very stupid of them to not accept legacy transactions since it would mean breaking all unconfirmed and timelocked transactions at the time of activation.



I would assume that they include transactions made before the split but not accepting new ones with old TX format.

On the other side I think users who care about the split should make sure to not send BTC what wont confirm till the split is done.

I agree that we should wait till the split is done.

Still would be nice to have the TX format with replay protection in Armory then.

I would assume that many armory users want access to the ABC coins as well and if its only to dump them as fast as possible on some exchange. ( Without the need of double spending to split them)



Still a risky thing what could need several attempts.1. TX on the main chain with low fee what would confirm on the main chain but not on the ABC chain.2. Once TX confirmed on the main chain, double spent on the ABC chain with high fee.That was my plan for possible splits without replay protection.I would assume that they include transactions made before the split but not accepting new ones with old TX format.On the other side I think users who care about the split should make sure to not send BTC what wont confirm till the split is done.I agree that we should wait till the split is done.Still would be nice to have the TX format with replay protection in Armory then.I would assume that many armory users want access to the ABC coins as well and if its only to dump them as fast as possible on some exchange. ( Without the need of double spending to split them) ✔▬ R A D I X ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ The Decentralized Finance Protocol

█████████ GET TOKENS █████████ ◥ Facebook ◥ Telegram ◥ Twitter

► The Radix DeFi Protocol is ⚫ SCALABLE ⚫ SECURE ⚫ COMMUNITY DRIVEN

goatpig

Legendary



Offline



Activity: 2646

Merit: 1172



Armory Developer







ModeratorLegendaryActivity: 2646Merit: 1172Armory Developer Re: Bitcoin Cash (BCC) and Armory July 24, 2017, 10:00:42 AM #11 Quote from: Casimir1904 on July 24, 2017, 01:42:20 AM Quote from: goatpig on July 24, 2017, 12:02:14 AM Armory does not verify on chain tx. It does not process scripts unless it's for its own signing purposes. No amount of new op codes would make a difference. The only thing that matters is block serialization on disk and the P2P layer.



So Armory should just work with BitcoinABC as node?

I just read on their reddit:

"We are currently considering accepting only such protected transactions (currently it is still possible, by opting for it, to get non-SIGHASH-FORKID transactions relayed and mined).

Interested parties are encouraged to read REQ-6-1 , REQ-6-2 and REQ-6-3 of the UAHF specification."



Transactions without the SIGHASH-FORKID would be broadcasted also on the Bitcoin chain and would be terrible/impossible/hard to handle.



My plan was to move the BitcoinABC coins after the split but not my Bitcoins.

Another security aspect is that the signed TX would probably be valid for both chains?

That would mean I would need to move my Bitcoins as well when moving on the BitcoinABC chain?



So Armory should just work with BitcoinABC as node?I just read on their reddit:"We are currently considering accepting only such protected transactions (currently it is still possible, by opting for it, to get non-SIGHASH-FORKID transactions relayed and mined).Interested parties are encouraged to read REQ-6-1 , REQ-6-2 and REQ-6-3 of the UAHF specification."Transactions without the SIGHASH-FORKID would be broadcasted also on the Bitcoin chain and would be terrible/impossible/hard to handle.My plan was to move the BitcoinABC coins after the split but not my Bitcoins.Another security aspect is that the signed TX would probably be valid for both chains?That would mean I would need to move my Bitcoins as well when moving on the BitcoinABC chain?

Armory will work the ABC/BCC/whatever node as long as it respects on disk block format and uses the same P2P layer (although that can vary to an extent, Armory uses maybe 30% of the P2P layer messages).



That's for node compatibility. Replay protection is another thing.



The issue with this kind of rushed forks is that their standard has not even congealed in their heads, let alone on paper/code. I'd suggest you ignore their replay protection proposals and just taint the regular way, i.e. get a tx on one chain, double spend the utxo on the other.



The way to do this is to send a utxo back yourself over and over again until you hit the condition to double spend on the other chain. You have 2 ways around this:



1) If the 2 chains have a consistently different block heights:



Achow's LockTime method is the simplest. You would do it like this:



With 0.96.1, Armory conforms to Core's LockTime guidelines, where it set the LockTime of a Tx to the current top block height. This means the tx can't be mined until the chain hits this height (this is originally to prevent aggressive fee stealing orphan attacks between miners). Post split, you want to use this method on the longest fork first. The locktime guarantees the shorter fork can't mine the tx for a while. Once the tx gets on chain A, you can double spend that utxo on chain B, then taint your coins with the resulting output accordingly.



To do this, you need both nodes for both sides of the fork, pick an output with coin selection, spend it on the longest chain, swap back to the other node, create another tx with the utxo and spend it. You don't need to bother with the locktime field, as Armory sets it to the top block on the chain it is being run against. The only thing you really need to pay attention to is making sure you don't mix and match DB's and chain folders or you'll probably nuke your DB, and you're in for a rebuild & rescan.



Once you have the 2 tx (one on each chain) with a different txid, you're good to go. Use the output newly created with the coin selection GUI to taint your other coins as you see fit.



Note: the locktime feature was introduced in 0.96, but a bug in the in legacy txsigcollect message (the blob of text spit out to pass in between online and offline instances) makes it that the locktime is always forced back to 0 by the signer. Therefor, you need 0.96.1 to do this properly (0.96.0.4-testing has the fix). You need to update both signer and online machine for this work.



2) If the 2 chains have a narrow chain length gap but different transaction throughput:



Use my RBF trick: Create a RBF tx that has a fee low enough that it won't get mined anytime soon on the chain with the low throughput, but will get mined quickly on the chain with high throughput. Once it gets mined there, use the RBF GUI to double spend the utxo in another tx, this time with a large fee so that it gets into the low throughput chain quickly (again the goal is to get 2 tx with different txids on each chain).



You need an online 0.96 to RBF, the offline signer can be as old as 0.92.x. If you are using the script types, you'll need to upgrade your signer however.



In both cases, you are just sending coins back to yourself until you get your condition to double spend on the other chain. This is low risk (you're paying fees over and over at worst) and even with very similar chance, you have a good chance of pulling either method off if you persevere. Armory will work the ABC/BCC/whatever node as long as it respects on disk block format and uses the same P2P layer (although that can vary to an extent, Armory uses maybe 30% of the P2P layer messages).That's for node compatibility. Replay protection is another thing.The issue with this kind of rushed forks is that their standard has not even congealed in their heads, let alone on paper/code. I'd suggest you ignore their replay protection proposals and just taint the regular way, i.e. get a tx on one chain, double spend the utxo on the other.The way to do this is to send a utxo back yourself over and over again until you hit the condition to double spend on the other chain. You have 2 ways around this:1) If the 2 chains have a consistently different block heights:Achow's LockTime method is the simplest. You would do it like this:With 0.96.1, Armory conforms to Core's LockTime guidelines, where it set the LockTime of a Tx to the current top block height. This means the tx can't be mined until the chain hits this height (this is originally to prevent aggressive fee stealing orphan attacks between miners). Post split, you want to use this method on the longest fork first. The locktime guarantees the shorter fork can't mine the tx for a while. Once the tx gets on chain A, you can double spend that utxo on chain B, then taint your coins with the resulting output accordingly.To do this, you need both nodes for both sides of the fork, pick an output with coin selection, spend it on the longest chain, swap back to the other node, create another tx with the utxo and spend it. You don't need to bother with the locktime field, as Armory sets it to the top block on the chain it is being run against. The only thing you really need to pay attention to is making sure you don't mix and match DB's and chain folders or you'll probably nuke your DB, and you're in for a rebuild & rescan.Once you have the 2 tx (one on each chain) with a different txid, you're good to go. Use the output newly created with the coin selection GUI to taint your other coins as you see fit.Note: the locktime feature was introduced in 0.96, but a bug in the in legacy txsigcollect message (the blob of text spit out to pass in between online and offline instances) makes it that the locktime is always forced back to 0 by the signer. Therefor, you need 0.96.1 to do this properly (0.96.0.4-testing has the fix). You need to update both signer and online machine for this work.2) If the 2 chains have a narrow chain length gap but different transaction throughput:Use my RBF trick: Create a RBF tx that has a fee low enough that it won't get mined anytime soon on the chain with the low throughput, but will get mined quickly on the chain with high throughput. Once it gets mined there, use the RBF GUI to double spend the utxo in another tx, this time with a large fee so that it gets into the low throughput chain quickly (again the goal is to get 2 tx with different txids on each chain).You need an online 0.96 to RBF, the offline signer can be as old as 0.92.x. If you are using the script types, you'll need to upgrade your signer however.In both cases, you are just sending coins back to yourself until you get your condition to double spend on the other chain. This is low risk (you're paying fees over and over at worst) and even with very similar chance, you have a good chance of pulling either method off if you persevere. https://btcarmory.com

goatpig

Legendary



Offline



Activity: 2646

Merit: 1172



Armory Developer







ModeratorLegendaryActivity: 2646Merit: 1172Armory Developer Re: Bitcoin Cash (BCC) and Armory July 24, 2017, 10:06:31 AM #12 Quote from: Casimir1904 on July 24, 2017, 09:55:41 AM Still would be nice to have the TX format with replay protection in Armory then.



Can't really do that on such a short notice, with no testing. It's just not safe, somehow the HF happy crowd does not realize the world isn't about them and the ecosystem needs time to upgrade. In perspective, consider SW has been in its signaling period for over 9 months and still some service providers have not updated yet.



If their fork survives the first 2 weeks and they finally decide on a sensible way to provide replay protection, then I'd consider adding it. If you want to taint to short, it's on you to be proactive with existing tools to jump on the opportunity. Can't really do that on such a short notice, with no testing. It's just not safe, somehow the HF happy crowd does not realize the world isn't about them and the ecosystem needs time to upgrade. In perspective, consider SW has been in its signaling period for over 9 months and still some service providers have not updated yet.If their fork survives the first 2 weeks and they finally decide on a sensible way to provide replay protection, then I'd consider adding it. If you want to taint to short, it's on you to be proactive with existing tools to jump on the opportunity. https://btcarmory.com

Casimir1904



Offline



Activity: 209

Merit: 100





Radix-The Decentralized Finance Protocol







Full MemberActivity: 209Merit: 100Radix-The Decentralized Finance Protocol Re: Bitcoin Cash (BCC) and Armory July 24, 2017, 01:58:29 PM #13 Quote from: goatpig on July 24, 2017, 10:06:31 AM

Can't really do that on such a short notice, with no testing. It's just not safe, somehow the HF happy crowd does not realize the world isn't about them and the ecosystem needs time to upgrade. In perspective, consider SW has been in its signaling period for over 9 months and still some service providers have not updated yet.



If their fork survives the first 2 weeks and they finally decide on a sensible way to provide replay protection, then I'd consider adding it. If you want to taint to short, it's on you to be proactive with existing tools to jump on the opportunity.



I agree about the rushing part.

Lot work for me as well to make sure users can access their coins on all possible chains.

Atm i run 4 different nodes with armory on top where it seems that only 2 will be needed in the end.

They run on 4 different machines as well so no mixing between data directories.

RBF is removed on ABC...



I think they should have contact the major wallet developers and exchanges with their plans and offer help.

It would be in their interest to have most wallets and services working with the split.



For BTCPOP SW isn't ready either. I'm prepared but didn't spent much time before on it when chances was big it would never happen.

As Legacy transactions on the legacy chain will still work there is also no need to rush things in.

Guess for the split of coins easiest for me would be to create 2 new wallets. One called ABC and one Core.

Send on Core chain coins to the Core wallet. Wait for 1 conf.

Send same inputs to ABC wallet with higher fee. I agree about the rushing part.Lot work for me as well to make sure users can access their coins on all possible chains.Atm i run 4 different nodes with armory on top where it seems that only 2 will be needed in the end.They run on 4 different machines as well so no mixing between data directories.RBF is removed on ABC...I think they should have contact the major wallet developers and exchanges with their plans and offer help.It would be in their interest to have most wallets and services working with the split.For BTCPOP SW isn't ready either. I'm prepared but didn't spent much time before on it when chances was big it would never happen.As Legacy transactions on the legacy chain will still work there is also no need to rush things in.Guess for the split of coins easiest for me would be to create 2 new wallets. One called ABC and one Core.Send on Core chain coins to the Core wallet. Wait for 1 conf.Send same inputs to ABC wallet with higher fee. ✔▬ R A D I X ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ The Decentralized Finance Protocol

█████████ GET TOKENS █████████ ◥ Facebook ◥ Telegram ◥ Twitter

► The Radix DeFi Protocol is ⚫ SCALABLE ⚫ SECURE ⚫ COMMUNITY DRIVEN

goatpig

Legendary



Offline



Activity: 2646

Merit: 1172



Armory Developer







ModeratorLegendaryActivity: 2646Merit: 1172Armory Developer Re: Bitcoin Cash (BCC) and Armory July 24, 2017, 08:21:34 PM #14 Quote from: Casimir1904 on July 24, 2017, 01:58:29 PM RBF is removed on ABC...



Somehow not surprised about this. No matter, RBF still works to taint. Either anything but a 0xFFFFFFFF input sequence is invalid on their chain and you are guaranteed to create unreplayable tx on the main chain by virtue of that change, or they simply made RBF non standard (just won't broadcast the double spend), which makes the move even easier, as you can double spend the tx on the main chain without waiting for a conf on the split! This change basically guarantees a taint in a single hop with RBF.



Quote I think they should have contact the major wallet developers and exchanges with their plans and offer help.

It would be in their interest to have most wallets and services working with the split.



I wish they did, but they have not been in touch with me at all, nor other people that have approached me about this. Not to make myself seem important but Armory is one of the few fullnode wallets out there, therefor one of the easiest to support a split with. You'd imagine they at least approach me for support, since it is infinitely less work for me to implement support than it is for the likes of Coinbase (who outright turned them down) or Electrum.



Quote For BTCPOP SW isn't ready either. I'm prepared but didn't spent much time before on it when chances was big it would never happen.

As Legacy transactions on the legacy chain will still work there is also no need to rush things in.



That wasn't a criticism of any one service in particular, rather making a case that a 1 year activation period is actually sane and desirable for an opt in feature, let alone a HF. But naaaah, changing a 1 to a 2 is so simple, what could go wrong?



Quote Guess for the split of coins easiest for me would be to create 2 new wallets. One called ABC and one Core.

Send on Core chain coins to the Core wallet. Wait for 1 conf.

Send same inputs to ABC wallet with higher fee.



I would still push on ABC first then Core. If ABC gets miners, it will be hashing power lost from the main chain which will slow down, whereas ABC intents on retargeting the difficulty manually for their HF. With that, their 2 MB block size (plus the 8MB default EB lmao) and the most likely meek adoption, fees on the split should be dirt cheap whereas they will spike on the main chain at least until the next retarget.



And if they effectively don't support RBF (I'm guessing they using the BU change that won't broadcast the 2nd RBF), then it's painfully easy to taint with that, regardless of fee rate or throughput. Somehow not surprised about this. No matter, RBF still works to taint. Either anything but a 0xFFFFFFFF input sequence is invalid on their chain and you are guaranteed to create unreplayable tx on the main chain by virtue of that change, or they simply made RBF non standard (just won't broadcast the double spend), which makes the move even easier, as you can double spend the tx on the main chain without waiting for a conf on the split! This change basically guarantees a taint in a single hop with RBF.I wish they did, but they have not been in touch with me at all, nor other people that have approached me about this. Not to make myself seem important but Armory is one of the few fullnode wallets out there, therefor one of the easiest to support a split with. You'd imagine they at least approach me for support, since it is infinitely less work for me to implement support than it is for the likes of Coinbase (who outright turned them down) or Electrum.That wasn't a criticism of any one service in particular, rather making a case that a 1 year activation period is actually sane and desirable for an opt in feature, let alone a HF. But naaaah, changing a 1 to a 2 is so simple, what could go wrong?I would still push on ABC first then Core. If ABC gets miners, it will be hashing power lost from the main chain which will slow down, whereas ABC intents on retargeting the difficulty manually for their HF. With that, their 2 MB block size (plus the 8MB default EB lmao) and the most likely meek adoption, fees on the split should be dirt cheap whereas they will spike on the main chain at least until the next retarget.And if they effectively don't support RBF (I'm guessing they using the BU change that won't broadcast the 2nd RBF), then it's painfully easy to taint with that, regardless of fee rate or throughput. https://btcarmory.com