Rampion
Legendary
Offline
Activity: 1148
Merit: 1018
|
|
December 09, 2016, 11:29:12 AM |
|
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?
|
|
|
|
goatpig (OP)
Moderator
Legendary
Offline
Activity: 3682
Merit: 1347
Armory Developer
|
|
December 09, 2016, 02:24:28 PM |
|
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
Member
Offline
Activity: 178
Merit: 10
|
|
December 14, 2016, 01:56:42 AM |
|
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 (OP)
Moderator
Legendary
Offline
Activity: 3682
Merit: 1347
Armory Developer
|
|
December 14, 2016, 11:56:16 AM |
|
If the P2SH is a nested SW script, that's the idea.
|
|
|
|
alomar
Member
Offline
Activity: 178
Merit: 10
|
|
December 14, 2016, 04:31:10 PM |
|
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
Staff
Legendary
Offline
Activity: 3430
Merit: 6720
Just writing some code
|
|
December 14, 2016, 04:49:41 PM |
|
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
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
December 15, 2016, 10:27:40 AM |
|
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 (OP)
Moderator
Legendary
Offline
Activity: 3682
Merit: 1347
Armory Developer
|
|
December 15, 2016, 01:07:55 PM |
|
So how do we tell senders?
You don't have to tell them anything.
|
|
|
|
achow101
Staff
Legendary
Offline
Activity: 3430
Merit: 6720
Just writing some code
|
|
December 15, 2016, 03:14:05 PM |
|
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
Member
Offline
Activity: 178
Merit: 10
|
|
December 15, 2016, 11:38:05 PM |
|
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
Staff
Legendary
Offline
Activity: 3430
Merit: 6720
Just writing some code
|
|
December 16, 2016, 12:15:02 AM |
|
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 (OP)
Moderator
Legendary
Offline
Activity: 3682
Merit: 1347
Armory Developer
|
|
December 16, 2016, 12:27:27 AM |
|
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
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
December 16, 2016, 11:02:08 AM |
|
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 (OP)
Moderator
Legendary
Offline
Activity: 3682
Merit: 1347
Armory Developer
|
|
December 16, 2016, 12:15:14 PM |
|
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
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
December 16, 2016, 12:16:42 PM |
|
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 (OP)
Moderator
Legendary
Offline
Activity: 3682
Merit: 1347
Armory Developer
|
|
December 16, 2016, 12:20:48 PM |
|
The address has everything he needs. If he uses that addresses, it will result in a nested SW output on the network.
|
|
|
|
h00per_tr00per
Newbie
Offline
Activity: 2
Merit: 0
|
|
December 25, 2016, 11:23:44 PM |
|
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
Staff
Legendary
Offline
Activity: 3430
Merit: 6720
Just writing some code
|
|
December 25, 2016, 11:38:13 PM |
|
|
|
|
|
h00per_tr00per
Newbie
Offline
Activity: 2
Merit: 0
|
|
December 27, 2016, 01:11:23 AM |
|
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/verifyand 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
Legendary
Offline
Activity: 1915
Merit: 2074
|
|
December 27, 2016, 10:28:35 AM |
|
New procedure: $ 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
|
|
|
|
|