Bitcoin Forum
February 25, 2018, 10:22:27 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 ... 199 »
501  Bitcoin / Armory / Re: Using Armory on the BCH chain on: October 02, 2017, 07:23:06 PM
There is no sorting feature atm.
502  Bitcoin / Armory / Re: Using Armory on the BCH chain on: October 02, 2017, 06:57:17 PM
Uncheck the parent section.
503  Bitcoin / Armory / 0.96.4 RC1 on: October 02, 2017, 06:56:22 PM
Binaries:

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.3.99

Changelog:

Quote
== Added ==
   - SegWit lockbox creation.
   - BCH lockbox spending.
   - Coin selection will now limit itself to change outputs when spending to external addresses you've spent to in the past.
   - You will receive a warning about privacy loss if coin selection fails to satisfy the previous condition.
   - Added the following CLI args:
      - Client side:
         --force-enable-segwit: when paired with --offline, allows the creation of SegWit types recipient addresses.
         --force-fcgi: forces the client to use FCGI socketing when connecting to a remote DB IP.
      - Server side:
         --listen-all: FCGI server will listen on :80 instead of 127.0.0.1:80
   
== Fixed ==
   - Fixed ledger based fee bumping.
   - Fixed RBF control dialog spawning.
   - Fixed node sync progress bar.
   - Fixed node status notification flicker during node sync.
   - Fixed fragment ID generation mismatching the fragment on backup when restoring non deterministic fragments. This fix only
     applies to fragments generated with versions 0.96.4 and later.
   - When in offline mode, the default signer option will now pick the proper signer for SegWit transactions.
   - Fixed --ram-usage control. --ram-usage=1 will no longer hang the DB during bootstrap scans.
   - As a result, --ram-usage defaults to 50 no instead of 4.

== Minor ==
   - You can now resize the Transaction Info dialog.

Notes:

SegWit lockboxes use compressed keys as opposed to the legacy ones, therefor they are sensibly smaller while also being a whole lot cheaper. Users looking to try them out should test around on testnet first.

Linux users that were having trouble with older CPUs, try the noasm .deb


504  Bitcoin / Armory / Re: Using Armory on the BCH chain on: October 02, 2017, 05:01:10 PM
how does one correlate block height with blockfile.dat?

Since headers first (Core 0.10), crap shoot.
505  Bitcoin / Armory / Re: Crosscompile Armory for Raspberry PI. on: October 02, 2017, 04:23:17 PM
Your path to the RPi Python includes is off.
506  Bitcoin / Armory / Re: Stuck in scanning on: October 01, 2017, 06:31:04 PM
Looking in my bitcoin.conf I see I have a line "prune=550" will this cause problems?

I don't think the pruning is tanking your node, but it won't work with Armory anyways.
507  Bitcoin / Armory / Re: Looking ahead to the next ill-advised hard fork.... on: October 01, 2017, 05:58:23 AM
... This piece of the puzzle is easy and already well-understood. I had assumed that btc1 was going to insist on it's forking-block being over 4MB in weight, a simple and elegant solution to the wipeout risk.... They couldn't possibly be stupid enough to not do that, could they?

No idea. How can I tell SINCE THERE'S NO TESTNET TO WORK AGAINST?

Quote
I don't understand?  If I have a pre-split UTXO, and I send it back to myself with their magic value in an OP_RETURN the transaction is not valid on the btc1 chain, and the resulting UTXO may be spent freely with no risk of replay, and can also be used to taint other UTXOs [At the expense of privacy]. Once the BTC transaction is confirmed, the same UTXO may be spent freely on btc1 with no risk as the UTXO is already spent on Bitcoin....

1) The OP_RETURN stuff makes the tx non standard, not invalid. In other words, nodes won't propagate it, but angry enough attackers can choose to mine them anyways.

2) With any form of opt-in tainting, the only sane path forward is sending coins back to yourself on both ends until you can verify your UTXO set divergence has confirmed on both sides of the split. Whether you do this with their convenience OP_RETURN method, or through RBF, LockTime, using coinbase transactions or whatever else you can think of, the end result is the same:

You can only demonstrably prove your coins are tainted after you have confirmations of a divergent UTXO on both chains.

Bitcoin transactions are final, replay attacks are a real threat! Therefor, there is no reasonable argument for simply trusting the opt-in protection when you can actually verify its effect.
508  Bitcoin / Armory / Re: Armory 0.96.3 fragment ID during test backup does not match on: October 01, 2017, 12:19:55 AM
I've got it fixed, will be part of 0.96.4
509  Bitcoin / Armory / Re: Looking ahead to the next ill-advised hard fork.... on: September 30, 2017, 09:28:01 PM
Should Armory enforce the opt-in (if it gets added, which I suppose will happen at the last minute), and explicitly require users to opt out?

I'm not adding GUI elements to hand hold if that's what you're referring to. The opt-out is simple enough to use: send coins back to yourself until you're sure you have correctly tainted, regardless of the tainting method.

If a users lack the patience to execute this, or the knowledge to understand what he is doing, he will need to take time to educate himself on the matter. I'll put out a guide as with BCH.

What I could do, since 2x insists upon the lack of 2 way replay protection, could be to detect the fork by its fork point and issue a message box warning whenever someone is trying to spend a UTXO that predates the fork point. However, not knowing if 2x has wipeout protection, detection may get a whole lot harder than just hardcoding a header hash and checking against it.

Quote
The two proposals I've seen are a magic OP_RETURN value [which is not supported by most wallets, but is supported by Armory], or an output to a magic P2SH address [Much more bloat, and it bloats the UTXO-set too], which can be done with any existing wallet.

Both are shit. The bare minimum requirements for a clean HF are (in descending order):

1) wipeout protection
2) 2-way mandatory replay protection
3) make testnet available about a year before the HF (you should FF then)
4) change script hash prefixes to reflect the new mainnet and testnet, and change network ports

I don't even know if 2X is trying to get 1) right.

As for the details, the second method is sensibly worst than the first since it naturally suggests a UTXO consolidation strategy that will result in a massive privacy leak. Fungibility be damned!

Both methods fail anyways, since they do not provide a strong guarantee of replay protection to begin with. Therefor you are left with spending coins back to yourself until you get lots of confirmations on an actual taint. Therefor, these methods, whichever they end up going with, are basically pointless shortcuts that do not significantly impact the complexity of a "raw" tainting procedure.
510  Bitcoin / Armory / Re: Using Armory on the BCH chain on: September 30, 2017, 08:48:07 PM
This is what you need to know to treat your private key exports properly: you can reveal the private root of an Armory wallet with:

1) A chain of public keys tracing back to the public root.
2) The chaincode (that's treated the same as public keys).
3) Any corresponding private key on that public chain.

The most conservative position is to consider the entire wallet compromised if you export even a single private key, and that's the position I hold both personally and officially.
511  Bitcoin / Armory / Re: Bech32 new address format and Armory on: September 30, 2017, 04:18:11 PM
AFAIK bech32 is only for v0 native SW scripts. I'll get it in there at some point.
bech32 works for all segwit versions. It encodes the witness version number.

I meant it as a way to distinguish from nested segwit scripts.
512  Bitcoin / Armory / Re: Armory 0.96.3 occasionally crash on: September 30, 2017, 03:05:54 PM
Ah, 0.96...

Update man.
513  Bitcoin / Armory / Re: Bech32 new address format and Armory on: September 30, 2017, 11:54:20 AM
Good to hear, thanks.
Would you recommend creating new wallets for this? And/or will this coincide with the migration to the new wallet format?

Ente

Most likely I'll add support for this in mirror wallets before the new wallets are out.
514  Bitcoin / Armory / Re: Bech32 new address format and Armory on: September 30, 2017, 10:57:25 AM
AFAIK bech32 is only for v0 native SW scripts. I'll get it in there at some point.
515  Bitcoin / Armory / Re: Looking ahead to the next ill-advised hard fork.... on: September 30, 2017, 10:56:16 AM
I believe it's some sort of OP_RETURN output. You can create those in Armory if you are set to expert mode.
516  Bitcoin / Armory / Re: Using Armory on the BCH chain on: September 30, 2017, 05:41:28 AM
is it true that i can simply scan a BCH encumbered private key into a BCH enabled wallet, like Electron Cash, to claim my BCH even after i've sent the BTC away?

if true, wouldn't that be a simpler method to claim BCH than fiddling with all the truncated blockchain tricks?

If you export private keys, you have to consider the wallet compromised and cycle it. That means your backups are done for too. Choose accordingly.
517  Bitcoin / Armory / Re: Armory 0.96.3 occasionally crash on: September 29, 2017, 04:24:19 PM
Nothing in there that's really helpful, sorry
518  Bitcoin / Armory / Re: Armory closes when creating a new wallet on: September 28, 2017, 08:50:24 PM
I could look at the armorylog.txt, even that's most likely false positives or just verbose for the sake of verbose. As for the compiler warnings, that's kinda hard not to get any without raising the warning threshold.
519  Bitcoin / Armory / Re: Armory closes when creating a new wallet on: September 28, 2017, 07:39:54 PM
That fixed the issue?
520  Bitcoin / Armory / Re: Armory 0.96.3 released on: September 28, 2017, 05:53:40 PM
What is the new memory usage limit for wallet decryption?

Was never changed.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 ... 199 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!