Bitcoin Forum
July 12, 2024, 05:54:24 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 [105] 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 ... 233 »
2081  Bitcoin / Armory / Re: Unable to see Bitcoin after restoring wallet on: March 24, 2017, 04:11:50 PM
First of all, start Armory in offline mode. Make sure the wallet is loaded and has the expected ID. Then go to the wallet's properties dialog and make sure the receiving address is listed. If you get that far, then your issue is just with properly initializing the DB.
2082  Bitcoin / Armory / Re: How to get the xpub key of my armory wallet account? on: March 24, 2017, 03:04:06 PM
Ah, wasn't aware that armoryd uses a different wallet format.

This is the backup format across all iterations of Armory since 0.90.

If you only have 2 lines in your backup, that's a 1.35c. If you have 4, that's a 1.35 and the last 2 lines are your chaincode. The wallet version should be written on the paperback up.
2083  Bitcoin / Armory / Re: How to get the xpub key of my armory wallet account? on: March 24, 2017, 12:19:58 PM
There's no chaincode apparent on 1.35c wallets, since it is derived deterministically from the root private key in that version:

https://github.com/goatpig/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L3489
2084  Bitcoin / Armory / Re: v95.1 raw data does not match expected block hash on: March 23, 2017, 11:40:50 PM
rebuild & rescan
2085  Bitcoin / Armory / Re: Armory 0.95.1 is out on: March 23, 2017, 10:25:47 PM
Known bug, fixed in 0.96. You'll have to broadcast the raw signed tx.
2086  Bitcoin / Armory / Re: Armory 0.95.1 is out on: March 23, 2017, 06:55:43 PM
C:\Users\ITSN\AppData\Roaming\Armory\databases
2087  Bitcoin / Armory / Re: Armory 0.95.1 is out on: March 23, 2017, 05:59:39 PM
1) Delete your DB
2) Start BitcoinQt manually, make sure it is running fine
3) Start ArmoryDB.exe from the command line, let it complete the build (you should see this line: "Enabling zero-conf tracking")
4) Start ArmoryQt.exe, let it scan

At this point you should be good. If it gets stuck at 3) again, post back with your dbLog.txt
2088  Bitcoin / Armory / Re: Armory 0.95.1 is out on: March 23, 2017, 03:51:31 PM
Do a rebuild & rescan.
2089  Bitcoin / Armory / Re: Armory 0.95.1 is out on: March 23, 2017, 03:34:50 PM
Do a rebuild & rescan.
2090  Bitcoin / Armory / Re: "the broadcast process failed unexpectedly" on: March 22, 2017, 09:54:07 PM
What command line arguments are your running Armory with?
2091  Bitcoin / Armory / Re: BTU Hard Fork Inquiry on: March 22, 2017, 11:51:10 AM
1) If you control the private keys, you will have the associated coins on both chains post fork.

If you have IOU at an exchange (or any service provider for that matter), they hold the private keys, hence they get the mirrored coins. At this point there is no knowing if/when the exchange will credit you with coins on the other fork, and which fork they will decide run as their main.

The other issue is the possibility to being exposed to a hasty, untested implementation of the coin split. Coinbase dropped the ball during the ETH/C HF, you can research that event if you want to know more.

Lastly, if BU aggressively attacks the Core chain (mining empty blocks, forcing reorgs), they will effectively hamstring the Core chain's capacity. From your perspective, there is no knowing when your deposits and withdrawals will confirm. From the exchanges' perspective, they will have to use very liberal confirmation count to credit/draw your balance against on chain operations (possibly days).

My position is that it is preferable to move your coins out of exchanges before a fork, let the dust settle, then figure out where you want to trade.

There is a chance you get to pick an exchange that's prepared, has ample coin and let's you trade the forks on day 1. But then again, they risks remain: withdrawal turmoil and running unseasoned code.

Last but not least, BU has no wipeout protection. If the Core chain ever catches up BU in work, the BU fork gets wiped out. This does not happen the other way around, so there is actually quite some liability to list a BU balance, since the underlying coins could disappear the next day. This leads me to believe exchanges won't list BU coins for a while in the event of a fork.

2) I got my coins and want to use them separately on each chain, what do?

There are 2 sides to this coin (see what I did there!):

a) Armory:

The DB builds off of on disk chain data and does not enforce consensus rules. In other words, any client that uses the same block data format and magic word as Core is compatible with Armory. From your perspective, running Armory against the BU chain will show you your BU balance, and vice versa.

Know that Armory (naturally) applies chainwork rules, and that it ignores all data on shorter forks. Again, from your perspective, it means that in the case of a BU fork, running the BU client against your Core block data will make Armory blind to the Core chain.

In practice, this means that to be able to interchange seamlessly between your Core and BU transaction history, you need 2 copies of the chain, one for the Core chain and one for the BU fork. Same goes with the Armory DB, as it is intimately tied to the underlying block data. However, you do not need to rescan the BU chain to get the copy of Core DB to work off of it.

To summarize, you need:

- 1 copy of the chain to run exclusively against the Core client, with the associated Armory dbdir.
- 1 copy of the chain to run exclusively against the BU client, with associated Armory dbdir.

You can swap between the 2 by pointing Armory to the relevant pair of block data folder (--satoshi-datadir) and database folder (--dbdir).

b) Tainting your coins:

---------

If you know what tainting is, you can skip this part.

If a transaction you create on one chain is valid on the other, the recipient of your payment can replay the same transaction on the other chain to pocket your coins there as well. This is called the replay attack.

At the same time, BU has made it clear they don't intent to implement replay protection, and have no plan to change their P2P port from Core's, so these transaction will be present in both mempools to begin with (as they will propagate to both chains, since the P2P networks overlap).

The solution at the user level is to "taint" your coins, i.e. you want to get a transaction on one chain that isn't valid on the other. Once you have that, you can mix all of your remaining coins with the "tainted" output to the same effect. At this point none of your utxos on the one chain are valid on the other, which guarantees your txs aren't replayable.

---------

Tainting on BU is actually fairly easy. They want to increase the block size limit and reduce tx fees. At the same time, the departure of hash power from the main chain will result in slower Core blocks (i.e. less capacity, thus higher fees).

Hence, the simplest way to taint on BU is this:

Code:
- Create a transaction sending coins back to yourself, with a fee low enough such that it will quickly mine on BU but has no real chance of mining on Core.

- Once the tx is mined on BU, RBF the underlying output on the Core chain with a nice fee. This tx can only mine on Core now since it is invalid on BU (to which it appears as a double spend).

- Once your RBF gets a good confirmation cushion on the Core side (possibly a day or 2 if BU decides to attack the chain), you have a utxo exlusive to the BU chain and one exclusive the Core chain. You are now safe to taint the rest of your stash on each chain, keeping in mind that untainted coins remain valid on both chains.

In preparation for this event, I'm adding RBF for 0.96, so you should be covered on the tainting side if anything. Of course, keeping coins on an exchange will give you that "taint" once the exchange lists both forks. That's the easy way out, with the associated risk.

There is essentially no risk to tainting your coins on your own, at worst you are just sending your coins back to yourself on both chains. The only risk is to not wait for enough confirmations on the Core chain in case of a BU mining attack.

3) I tainted my coins, I want to trade them now!

You have 2 ways around this.

a) The simplest and most convenient way is to wait for an exchange to list both coins and do your business there.

How is this different from just keeping your coins on an exchange you ask? In that scenario, you are the mercy of the exchange you left your coins on pre fork. If they never list the 2 coins and/or don't let you withdraw post fork, there is nothing you can do about it.

If you taint your coins yourself, you not only manage the risk (you are only have to move coins on the chain you dont support in order to dump), you also get your pick of the exchanges, which means you can evaluate the different services before going all in with one.

b) Find someone on the other side of the fence willing to trade you and use a cross chain swap scheme.

I don't know if any of these schemes are publicly available. I've developed one for a partner of mine in the past. If things drag along, I'll ask for permission to make the scheme public, but I expect the community will deliver a solution faster than I if it comes down to this.

Keep in mind that in both cases, this play is risky as long as the Core chain is under a BU miner attack. Under these circumstances, a swap on a custodial exchange (as opposed to whatever on chain swap scheme, through an exchange or not) has a marginally higher chance of success. You can swap, ride out the attack and withdraw at the first sign of clearing, assuming the exchange doesn't screw you over (but that's a constant risk with exchanges to begin with).
2092  Bitcoin / Armory / Re: Restore Wallet - Merge, Overwrite Failure on: March 21, 2017, 09:43:39 PM
If you know how to build the code, go ahead and run 0.96 off of the dev branch. Otherwise, wait for 0.96 testing binaries, coming soon (TM)
2093  Bitcoin / Armory / Re: Armory not sending... on: March 21, 2017, 02:40:35 PM
Any insight was to why, however, my bitcoin-cli commands no longer appear working?

Check your bitcoin.conf:

1) It should have server=1

2) Remove rpclogin and rpcpassword if you have that, and try again. I expect bitcoin-cli relies on the cookie file after that has been introduced. rpclog/pass block that.

Since you are running your node manually, consider using bitcoin-qt with disablewallet=1, that gives you a tab to run rpc commands from the GUI.
2094  Bitcoin / Armory / Re: Armory not sending... on: March 20, 2017, 10:29:22 PM
Turn off auto bitcoind and start bitcoinqt manually. Then start Armory and take it from there.
2095  Bitcoin / Armory / Re: 0.95.1 the broadcast process failed unexpectedly/tx broadcast timed out on: March 20, 2017, 09:05:20 PM
Completing RBF and ill put out the first testing build.
2096  Bitcoin / Armory / Re: Broadcast process failed unexpectedly on: March 20, 2017, 08:47:16 PM
http://imgur.com/a/gpdMF
2097  Bitcoin / Armory / Re: Armory 0.95 is out on: March 20, 2017, 03:20:42 PM
Quote
gpg: Good signature from "goatpig (Offline signing key for Armory releases) <moothecowlord@gmail.com>" [unknown] <--Take it as OK ! ?

Yes, good sig means the key (mine in this case) properly signed the data inside the "----- PGP SIGNED MESSAGE-----" encapsulation.
2098  Bitcoin / Armory / Re: Armory 0.95 is out on: March 20, 2017, 02:57:34 PM
Just do

Code:
sha256sum armory_0.95.1_amd64.deb

This give you the hash for the package. Compare that with the hash in the signed file. If they match, check the signature on the hash file. If the sig is good, you got the right files.
2099  Bitcoin / Armory / Re: 0.95.1 the broadcast process failed unexpectedly/tx broadcast timed out on: March 19, 2017, 06:19:07 PM
That stuff should be fixed in 0.96
2100  Bitcoin / Armory / Re: 0.95.1 the broadcast process failed unexpectedly/tx broadcast timed out on: March 19, 2017, 02:42:29 PM
In the transaction review dialog, there's an option on the right side to copy as raw hex.
Pages: « 1 ... 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 [105] 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 ... 233 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!