Pages:
Author

Topic: Armory 0.95.1 is out - page 7. (Read 12835 times)

staff
Activity: 3374
Merit: 6530
Just writing some code
December 15, 2016, 11:14:05 AM
#69
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.
legendary
Activity: 3640
Merit: 1345
Armory Developer
December 15, 2016, 09:07:55 AM
#68
So how do we tell senders?

You don't have to tell them anything.
legendary
Activity: 2912
Merit: 1060
December 15, 2016, 06:27:40 AM
#67
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?
staff
Activity: 3374
Merit: 6530
Just writing some code
December 14, 2016, 12:49:41 PM
#66
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.
member
Activity: 178
Merit: 10
December 14, 2016, 12:31:10 PM
#65
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?
legendary
Activity: 3640
Merit: 1345
Armory Developer
December 14, 2016, 07:56:16 AM
#64
If the P2SH is a nested SW script, that's the idea.
member
Activity: 178
Merit: 10
December 13, 2016, 09:56:42 PM
#63
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?
legendary
Activity: 3640
Merit: 1345
Armory Developer
December 09, 2016, 10:24:28 AM
#62
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.
legendary
Activity: 1148
Merit: 1018
December 09, 2016, 07:29:12 AM
#61
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?
legendary
Activity: 2126
Merit: 1001
December 01, 2016, 06:27:00 AM
#60

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BlockUtils.cpp#L1109

Basically this:

Code:
testPath(blkFileLocation_, 4);

Should be:

Code:
testPath(blkFileLocation_, 2);

However, if you chmod your symlink to 777 and it still doesn't work, it may be that access(2) doesn't play well with symlinks altogether. You have a few solutions to try.

First, you should set the 4 to a 2, build and try again.

That symlink was already at 777.
Changing "4" to "2" solved it!
Thank you, Goatpig! :-)

I'll set up that client-server-mode on the weekend, aww yeah!

Ente
legendary
Activity: 3640
Merit: 1345
Armory Developer
December 01, 2016, 03:13:28 AM
#59
Today I tried to import a paperwallet privkey into 0.94.1. It worked (import, not sweep), but I couldn't spend the funds:

Code:
  File "/opt/BitcoinArmory/armoryengine/Transaction.py", line 1054, in __init__
    raise KeyDataError('Must give pubkey map for singlesig USTXI!')
armoryengine.ArmoryUtils.KeyDataError: Must give pubkey map for singlesig USTXI!

So I upgraded to 0.95.1.
Which I can't get to start up.
Even with an empty armory user folder, it complains about
Code:
(ERROR) BDM.py:184 - DB error: /home/user/.bitcoin/blocks is not a valid path
My .bitcoin folder is a softlink to a folder on another harddisk, as I ran out of space for the bitcoind blockchain. I set all data to my user and 777 again (before, bitcoind ran on its own user with more strict permissions).
Still, I get the same error.

Is this a known problem?
If it takes too much effort to fix, I'll set up the client-server mode on separated machines right away instead.

Apparently I messed up.

Here is the code checking the folder attributes:

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BlockUtils.cpp#L1109

and here is the underlying call:

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/DBUtils.cpp#L285

Basically this:

Code:
testPath(blkFileLocation_, 4);

Should be:

Code:
testPath(blkFileLocation_, 2);

However, if you chmod your symlink to 777 and it still doesn't work, it may be that access(2) doesn't play well with symlinks altogether. You have a few solutions to try.

First, you should set the 4 to a 2, build and try again. If that fails, comment out the path test line entirely and try again. This is just the code testing that the folder exists, for sanity checks. Lastly, if that still fails, try to point the DB directly to that HDD's path.

legendary
Activity: 2126
Merit: 1001
November 30, 2016, 07:44:29 PM
#58
Today I tried to import a paperwallet privkey into 0.94.1. It worked (import, not sweep), but I couldn't spend the funds:

Code:
  File "/opt/BitcoinArmory/armoryengine/Transaction.py", line 1054, in __init__
    raise KeyDataError('Must give pubkey map for singlesig USTXI!')
armoryengine.ArmoryUtils.KeyDataError: Must give pubkey map for singlesig USTXI!

So I upgraded to 0.95.1.
Which I can't get to start up.
Even with an empty armory user folder, it complains about
Code:
(ERROR) BDM.py:184 - DB error: /home/user/.bitcoin/blocks is not a valid path
My .bitcoin folder is a softlink to a folder on another harddisk, as I ran out of space for the bitcoind blockchain. I set all data to my user and 777 again (before, bitcoind ran on its own user with more strict permissions).
Still, I get the same error.

Is this a known problem?
If it takes too much effort to fix, I'll set up the client-server mode on separated machines right away instead.

Also, goatpig, I will need to hug you just for this client-server mode alone! Most awesome softwarefeature of the year! :-)

Ente
legendary
Activity: 1915
Merit: 2074
November 28, 2016, 02:12:14 PM
#57
will this work in Debian 8.6?

Works on Wheezy, no reason it won't on Jessie.

sorry for the edge case conditions, but will Armory work with Bitcoin Unlimited?

Armory 0.94.1 + Bitcoin Unlimited 0.12.1 + Ubuntu 14.10 64 bit is working for me.
legendary
Activity: 3640
Merit: 1345
Armory Developer
November 28, 2016, 01:13:52 PM
#56
sorry for the edge case conditions, but will Armory work with Bitcoin Unlimited?

I'm not aware of any changes in BU that would break compatibility with Armory atm, although I don't follow its development.
member
Activity: 178
Merit: 10
November 28, 2016, 11:42:48 AM
#55
will this work in Debian 8.6?

Works on Wheezy, no reason it won't on Jessie.

sorry for the edge case conditions, but will Armory work with Bitcoin Unlimited?
legendary
Activity: 3430
Merit: 3071
November 28, 2016, 07:18:49 AM
#54
will this work in Debian 8.6?

I can confirm it's working for me in Debian 8.6, albeit in a Xen based Virtual Machine.
legendary
Activity: 3640
Merit: 1345
Armory Developer
November 28, 2016, 02:22:27 AM
#53
will this work in Debian 8.6?

Works on Wheezy, no reason it won't on Jessie.
member
Activity: 178
Merit: 10
November 28, 2016, 01:34:45 AM
#52
will this work in Debian 8.6?
legendary
Activity: 3640
Merit: 1345
Armory Developer
November 26, 2016, 07:21:01 AM
#51
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.
hero member
Activity: 1358
Merit: 635
November 26, 2016, 06:35:27 AM
#50
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?
Pages:
Jump to: