Topic: Moving forward with Armory - page 3. (Read 18563 times)
Can we add support for compressed keys to the list of things to do?
ugh ill get on it.
Why do we need ilbsecp256k1 and what does that have to do with the bootstrap.dat?
Gaaaaaah. I think I misread goatpig's post. Nevermind.
That said, there probably should be a switch at some point. Crypto++ is just outgunned for this kind of work. That and there may be certain features (e.g., Schnorr signatures) coming eventually that Crypto++ doesn't support.On a different note, the latest build fixed my balance issues.
Am able to send coins too. Coin control doesn't work, though. Here's what I see when i try to choose specific UTXOs.Code:
Traceback (most recent call last):
File "/Users/droark/Projects/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/ui/TxFrames.py", line 785, in createTxAndBroadcast
ustx = self.validateInputsGetUSTX()
File "/Users/droark/Projects/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/ui/TxFrames.py", line 602, in validateInputsGetUSTX
utxoList = self.getUsableTxOutList(totalSend)
File "/Users/droark/Projects/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/ui/TxFrames.py", line 863, in getUsableTxOutList
utxos = cppAddr.getSpendableTxOutList(IGNOREZC)
File "/Users/droark/Projects/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/CppBlockUtils.py", line 1969, in getSpendableTxOutList
def getSpendableTxOutList(self, ignoreZC=True): return _CppBlockUtils.ScrAddrObj_getSpendableTxOutList(self, ignoreZC)
RuntimeError: not implemented
We should also probably remove the bootstrap torrent stuff. I don't think it actually helps with the new versions of Bitcoin Core.
It was Alan's intention to remove that feature once sipa's EC library was turned on for sig verification. Now is the time then.
Strictly speaking, it's probably best to wait for an officially tagged version of libsecp256k1. That being said, I suppose a reasonable workaround would be to create a link on Git (can't remember how offhand but I should have it written down) that lets you do a symlink of sorts to code posted elsewhere. The code in 0.12 could be used and manually updated as needed.
We should also probably remove the bootstrap torrent stuff. I don't think it actually helps with the new versions of Bitcoin Core.
It was Alan's intention to remove that feature once sipa's EC library was turned on for sig verification. Now is the time then.
Strictly speaking, it's probably best to wait for an officially tagged version of libsecp256k1. That being said, I suppose a reasonable workaround would be to create a link on Git (can't remember how offhand but I should have it written down) that lets you do a symlink of sorts to code posted elsewhere. The code in 0.12 could be used and manually updated as needed.
We should also probably remove the bootstrap torrent stuff. I don't think it actually helps with the new versions of Bitcoin Core.
It was Alan's intention to remove that feature once sipa's EC library was turned on for sig verification. Now is the time then.
ATI shutdown their website, torrents seedboxes included.
We should also probably remove the bootstrap torrent stuff. I don't think it actually helps with the new versions of Bitcoin Core.You should update to Core 0.12 (I believe they update the block checkpoints) and download the chain straight from that. Once it is sync'd, back up a copy of yours bitcoin datadir folder for the good measure.
They did not update the checkpoints because apparently the checkpoints don't actually help. Those checkpoints haven't been updated since 2011.I know you have a lot on your mind at present.
For the last month, I've been trying to update my
blockchain with no luck. I'm on a slow DSL connection
of around 34-35kb.
Armory has hung at 65-70% blockchain download
3 different times. I've had to go under the hood each
time to delete everything except my wallet.
The newly updated Armory/Bitcoin will not make
a connection using torrent...which would probably
shorten the download days...so have had to switch
back to bitcoin-qt.
Any idea why kept hanging at 65-70% download,
and why torrent won't connect ?
Is there any way to speed up complete update ?
Any suggestions will be appreciated.
bitprospector
ATI shutdown their website, torrents seedboxes included.
You should update to Core 0.12 (I believe they update the block checkpoints) and download the chain straight from that. Once it is sync'd, back up a copy of yours bitcoin datadir folder for the good measure.
You should update to Core 0.12 (I believe they update the block checkpoints) and download the chain straight from that. Once it is sync'd, back up a copy of yours bitcoin datadir folder for the good measure.
I know you have a lot on your mind at present.
For the last month, I've been trying to update my
blockchain with no luck. I'm on a slow DSL connection
of around 34-35kb.
Armory has hung at 65-70% blockchain download
3 different times. I've had to go under the hood each
time to delete everything except my wallet.
The newly updated Armory/Bitcoin will not make
a connection using torrent...which would probably
shorten the download days...so have had to switch
back to bitcoin-qt.
Any idea why kept hanging at 65-70% download,
and why torrent won't connect ?
Is there any way to speed up complete update ?
Any suggestions will be appreciated.
bitprospector
is there a link for the last stable version i can download ?
the main site seems to be still down .....
the main site seems to be still down .....
Should I add those files in too or leave as is?
I'll compare yours to what is in there already and take a decision. Only need one instruction file per OS, the rest I'll delete.
how it's the most easy way to install armory to recover my btc?
i cannot access to bitcoinarmory.com
thanks
Get the downloads from https://github.com/goatpig/BitcoinArmory/releases i cannot access to bitcoinarmory.com
thanks
how it's the most easy way to install armory to recover my btc?
i cannot access to bitcoinarmory.com
thanks
i cannot access to bitcoinarmory.com
thanks
Honestly, while the PRs look pretty large, the code isn't that difficult to port over. A lot of the files are taken from elsewhere and can basically be reused as-is. It's the files Joseph & I (mostly Joseph, granted) wrote where you need to be careful. Keep in mind that a lot of the complexity comes from trying to do this stuff in a robust manner. My goal was to have a first delivery that wasn't necessarily perfect but was robust enough that cross-compiling and such, including Windows/MinGW, would be reasonably easy. To that end, we actually had some internal test builds made to prove that everything worked. It was a lot of work but it was worthwhile, IMO. I'd recommend that anybody who starts from scratch use the notes in the PRs as guides and go from there. Even if you don't necessarily support anything other than specific Linux builds out the door, try not to hard-code anything that'll make it difficult to support other builds later.
Just my $.02. Do as you please. I'm just saying that a little pain upfront will save you lots of pain later.
Just my $.02. Do as you please. I'm just saying that a little pain upfront will save you lots of pain later.
I won't accept a PR that has anything to do with Joseph's work for ATI until I can clear that with the shareholders first. Do not keep your hopes up. Use Joseph's work as reference as much as you'd like though.
For people interested in adding deterministic build support for Armory, please focus on a single Linux distro at first (ideally Debian 7 or 8 ).
For people interested in adding deterministic build support for Armory, please focus on a single Linux distro at first (ideally Debian 7 or 8 ).
There is for RPi. Otherwise, no. The master plan, seen via some PRs up on the old Github, was to introduce Gitian and move towards a Core-like cross-build system once the Py3/Qt5 upgrade occurred.
Are we allowed to (from a licensing/legal standpoint) take those PRs from the old one and use them in the new one? Or would it be better to ask the users who submitted those PRs to resubmit them to the new one. (e.g. this one: https://github.com/etotheipi/BitcoinArmory/pull/312)They were submitted by a former Armory intern. My personal guess is that, if it came down to a court case, the PRs would be acceptable. IANAL, obviously, and all attempts I've made to get any sort of answers haven't gotten anywhere. So, I don't think the code would be accepted if you tried to port it. If you want to be absolutely safe, you'll have to do a "clean room" implementation. You might be best off reading the PRs and going through the Core codebase. (Alas, Autotools is impossible to fully understand. You basically make it work by failing 'til you're no longer failing.) Cory Fields might be willing to answer some questions, although it sometimes took him weeks to answer any questions we had.
Again, my understanding is that using the code as-is may not be safe from a legal standpoint. Who knows, maybe that branch would be safe since it apparently never got pulled. If others want to merge it in and goatpig wants to accept the merge, go for it. I'm not doing it.
I'm happy to contribute elsewhere but I'm not touching this stuff until there's more clarity regarding the situation. There is for RPi. Otherwise, no. The master plan, seen via some PRs up on the old Github, was to introduce Gitian and move towards a Core-like cross-build system once the Py3/Qt5 upgrade occurred.
Are we allowed to (from a licensing/legal standpoint) take those PRs from the old one and use them in the new one? Or would it be better to ask the users who submitted those PRs to resubmit them to the new one. (e.g. this one: https://github.com/etotheipi/BitcoinArmory/pull/312)They were submitted by a former Armory intern. My personal guess is that, if it came down to a court case, the PRs would be acceptable. IANAL, obviously, and all attempts I've made to get any sort of answers haven't gotten anywhere. So, I don't think the code would be accepted if you tried to port it. If you want to be absolutely safe, you'll have to do a "clean room" implementation. You might be best off reading the PRs and going through the Core codebase. (Alas, Autotools is impossible to fully understand. You basically make it work by failing 'til you're no longer failing.) Cory Fields might be willing to answer some questions, although it sometimes took him weeks to answer any questions we had.
There is for RPi. Otherwise, no. The master plan, seen via some PRs up on the old Github, was to introduce Gitian and move towards a Core-like cross-build system once the Py3/Qt5 upgrade occurred.
Are we allowed to (from a licensing/legal standpoint) take those PRs from the old one and use them in the new one? Or would it be better to ask the users who submitted those PRs to resubmit them to the new one. (e.g. this one: https://github.com/etotheipi/BitcoinArmory/pull/312)They were submitted by a former Armory intern. My personal guess is that, if it came down to a court case, the PRs would be acceptable. IANAL, obviously, and all attempts I've made to get any sort of answers haven't gotten anywhere. So, I don't think the code would be accepted if you tried to port it. If you want to be absolutely safe, you'll have to do a "clean room" implementation. You might be best off reading the PRs and going through the Core codebase. (Alas, Autotools is impossible to fully understand. You basically make it work by failing 'til you're no longer failing.) Cory Fields might be willing to answer some questions, although it sometimes took him weeks to answer any questions we had.
There is for RPi. Otherwise, no. The master plan, seen via some PRs up on the old Github, was to introduce Gitian and move towards a Core-like cross-build system once the Py3/Qt5 upgrade occurred.
Are we allowed to (from a licensing/legal standpoint) take those PRs from the old one and use them in the new one? Or would it be better to ask the users who submitted those PRs to resubmit them to the new one. (e.g. this one: https://github.com/etotheipi/BitcoinArmory/pull/312) Jump to: