Armory 0.95.1 is out

[Rampion]

Hi.

Is 0.93 capable to sign off line transaction generated by 0.95 or I need to install new version on my off-line machine?

You are fine. You will need to upgrade when 0.96 comes out if you want sign SW transactions. If you do not create try to spend SW outputs, you won't need to upgrade.

Is there an easy way to avoid to create SW transactions using an updated (+0.13.1) Bitcoin Core once SW is activated?

[1714951880]

1714951880

[1714951880]

1714951880

[1714951880]

1714951880

[1714951880]

1714951880

[goatpig]

You have to give payers a SegWit address for them to pay you in that fashion. 0.95 can't create SW outputs. 0.96 let's you choose.

[alomar]

You have to give payers a SegWit address for them to pay you in that fashion. 0.95 can't create SW outputs. 0.96 let's you choose.

if you give them a p2sh address can they send you SW outputs?

[goatpig]

If the P2SH is a nested SW script, that's the idea.

[alomar]

If the P2SH is a nested SW script, that's the idea.

but if the p2sh address you supply to a sender is standard and doesn't involve a nested SW script, sender could still inadvertently (or intentionally) send you SW outputs since the 3* address is essentially just a hash, no?

[achow101]

If the P2SH is a nested SW script, that's the idea.

but if the p2sh address you supply to a sender is standard and doesn't involve a nested SW script, sender could still inadvertently (or intentionally) send you SW outputs since the 3* address is essentially just a hash, no?

No, that is not how segwit works. The sender does not know whether a p2sh address is for a nested segwit output, a multisig, or some other script. Whatever that is, it does not matter. They will create a normal p2sh output. The receiver must know how to spend from that p2sh output. The p2sh output cannot become a p2wsh (basically segwit p2sh). The sender should not assume that any address that they get should be used as a segwit output and not the normal output format for that type of address.

[bitpop]

If the P2SH is a nested SW script, that's the idea.

but if the p2sh address you supply to a sender is standard and doesn't involve a nested SW script, sender could still inadvertently (or intentionally) send you SW outputs since the 3* address is essentially just a hash, no?

No, that is not how segwit works. The sender does not know whether a p2sh address is for a nested segwit output, a multisig, or some other script. Whatever that is, it does not matter. They will create a normal p2sh output. The receiver must know how to spend from that p2sh output. The p2sh output cannot become a p2wsh (basically segwit p2sh). The sender should not assume that any address that they get should be used as a segwit output and not the normal output format for that type of address.

So how do we tell senders?

[goatpig]

So how do we tell senders?

You don't have to tell them anything.

[achow101]

So how do we tell senders?

You give the sender your p2sh address. That p2sh address will have as its "redeemscript" the segwit script. But the sender does not need to know, nor should they care, what the script of that p2sh address. For all they know, it could be a normal multisig; it does not matter to them. All the sender needs to know is that they are sending to a p2sh address and should send to it as normally done with p2sh addresses.

[alomar]

So how do we tell senders?

You give the sender your p2sh address. That p2sh address will have as its "redeemscript" the segwit script. But the sender does not need to know, nor should they care, what the script of that p2sh address. For all they know, it could be a normal multisig; it does not matter to them. All the sender needs to know is that they are sending to a p2sh address and should send to it as normally done with p2sh addresses.

how does the sender know whether to send std outputs or SW outputs to that p2sh address?

[achow101]

how does the sender know whether to send std outputs or SW outputs to that p2sh address?

A p2sh address specifies that it must always send normal p2sh outputs. There is no need to send a segwit output (and in fact impossible to with p2sh) to a p2sh address. The segwit output is nested as the script of the p2sh address and that is for the receiver to deal with.

[goatpig]

how does the sender know whether to send std outputs or SW outputs to that p2sh address?

You need to understand how bitcoin outputs are constructed and how they are redeemed, particularly P2SH. The whole point of P2SH is to let the recipient determine the redeem script.

[bitpop]

how does the sender know whether to send std outputs or SW outputs to that p2sh address?

A p2sh address specifies that it must always send normal p2sh outputs. There is no need to send a segwit output (and in fact impossible to with p2sh) to a p2sh address. The segwit output is nested as the script of the p2sh address and that is for the receiver to deal with.

But what if he does send segwit and receiver isn't expecting it? Will you have to redeem it with another wallet to recover it?

[goatpig]

But what if he does send segwit and receiver isn't expecting it?

How would he be doing this?

You at least need to know the public keys of your recipient to craft the output yourself. Neither P2PKH nor P2SH output scripts give you that information. Same with the native SW outputs. The only way you got to do this is by lifting the public keys of your recipients known addresses from the blockchain.

There is no mechanic in the bitcoin protocol to prevent someone from spending coins to whatever script they want, but that's basically the same as black-holing coins at this point. If you are afraid your wallet will do this with your coins, that's not how it's supposed to work at all.

[bitpop]

But what if he does send segwit and receiver isn't expecting it?

How would he be doing this?

You at least need to know the public keys of your recipient to craft the output yourself. Neither P2PKH nor P2SH output scripts give you that information. Same with the native SW outputs. The only way you got to do this is by lifting the public keys of your recipients known addresses from the blockchain.

There is no mechanic in the bitcoin protocol to prevent someone from spending coins to whatever script they want, but that's basically the same as black-holing coins at this point. If you are afraid your wallet will do this with your coins, that's not how it's supposed to work at all.

Oh ok, then how would he send a segwit? Do I need to give him other info than a 3* address?

[goatpig]

The address has everything he needs. If he uses that addresses, it will result in a nested SW output on the network.

[h00per_tr00per]

Just tried to verify signatures for this new build on Debian (downloaded from main Armory site), and no dice.  I wondered if I had screwed something up, so I downloaded 93.3 from the same place and verified that without difficulty.  Both .deb files are in the same directory.  Here's the output of how I did it:


h00per@debian-vm:~/Downloads$ dpkg-sig --verify *.deb
Processing armory_0.93.3_ubuntu-64bit.deb...
GOODSIG _gpgbuilder 821F122936BDD565366AC36A4AB16AEA98832223 1447278319
Processing armory_0.95.1_amd64.deb...
h00per@debian-vm:~/Downloads$


Is .95.1 signed in the same way as the other versions?  If not, how do I verify the integrity of this file?

Thanks.

[achow101]

Do you have the right key imported? You need to have goatpig's key, found at https://github.com/goatpig/BitcoinArmory/blob/master/PublicKeys/goatpig-signing-key.asc

[h00per_tr00per]

Do you have the right key imported? You need to have goatpig's key, found at https://github.com/goatpig/BitcoinArmory/blob/master/PublicKeys/goatpig-signing-key.asc

Thanks for the tip -- I didn't realize that goatpig had taken over when I posted my original thing.  But since then, I followed the directions on this page:

https://btcarmory.com/docs/verify

and even after importing the new key it doesn't work -- it appears the .95.1 binary is unsigned.  Here's the output now:


h00per@debian-vm:~/Downloads$ sha256sum -c sha256sum.asc armory_0.95.1_amd64.deb
armory_0.95.1_amd64.deb: OK
sha256sum: armory_0.95.1_osx.tar.gz: No such file or directory
armory_0.95.1_osx.tar.gz: FAILED open or read
sha256sum: armory_0.95.1_win64.exe: No such file or directory
armory_0.95.1_win64.exe: FAILED open or read
sha256sum: WARNING: 20 lines are improperly formatted
sha256sum: WARNING: 2 listed files could not be read
sha256sum: armory_0.95.1_amd64.deb: no properly formatted SHA256 checksum lines found


The earlier lines are reasonable -- I didn't download the files for those other versions.  But what's up with the .95.1 file?

[arulbero]

New procedure:

Code:

$ head -4 sha256sum.asc.txt | tail -1 | sha256sum -c     or    sha256sum  -c sha256sum.asc.txt armory_0.94.1_amd64.deb 2>&1 | grep OK

$ wget https://raw.githubusercontent.com/goatpig/BitcoinArmory/master/PublicKeys/goatpig-signing-key.asc

$ gpg --import goatpig-signing-key.asc

$ gpg --verify sha256sum.asc.txt
gpg: Firma eseguita dom 22 nov 2015 07:34:46 CET
gpg:                con RSA chiave 8C5211764922589A
gpg: Firma valida da "goatpig (Offline signing key for Armory releases) <moothecowlord@gmail.com>" [sconosciuto]
gpg: ATTENZIONE: questa chiave non è certificata con una firma fidata.
gpg:          Non ci sono indicazioni che la firma appartenga al proprietario.
Impronta digitale chiave primaria: 745D 707F BA53 968B DF63  AA8D 8C52 1176 4922 589A

or just take a look at:   https://btcarmory.com/docs/verify