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. 
Topic: Armory 0.95.1 is out - page 7. (Read 12932 times)
So how do we tell senders?
You don't have to tell them anything.
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?
So how do we tell senders?
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?
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?
If the P2SH is a nested SW script, that's the idea.
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?
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.
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?
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?
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
Today I tried to import a paperwallet privkey into 0.94.1. It worked (import, not sweep), but I couldn't spend the funds:
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
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.
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!
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.
Today I tried to import a paperwallet privkey into 0.94.1. It worked (import, not sweep), but I couldn't spend the funds:
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
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
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!
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
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.
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.
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?
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.
will this work in Debian 8.6?
Works on Wheezy, no reason it won't on Jessie.
will this work in Debian 8.6?
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?
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.
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?
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?
Jump to: