|
Who controls bitcoinarmory.com? It appears that the site is back up and different from the old one. It also has the latest versions posted.
Edit: typos
|
|
|
|
I suppose it is more of the threat of a hard fork which cuts out the miner's is what would persuade them to not abuse their power.
I've seen no evidence of miners "abusing their power" - if anything the miners (at least pools) have tried their hardest to not get involved with the politics and just support the future of Bitcoin (which makes sense for them economically). Agreed, I was speaking hypothetically. |
|
|
|
The solution is an emergency hard fork to another mining algorithm which renders so all of the miners' equipment useless. This has been discussed before and it is a solution if miners were to be colluding to the detriment of bitcoin.
I think that is not really going to be such an easy thing. Miners need to turn BTC into fiat in order to do their business (i.e. pay for their electricity and other costs) - but exchanges need the miners to have a steady source of people wanting to exchange. If devs wanted to "cut out the miners" then exchanges would be screwed for income in the short-term at least (as many of them are partnered with mining pools) so I can't see the exchanges actually likely to agree with such a change. I suppose it is more of the threat of a hard fork which cuts out the miner's is what would persuade them to not abuse their power. |
|
|
|
Miners en-masse currently can decide to block transactions. With something like an attachment process this would become impossible as the word was spread about a tx being censored.
I'll just keep bumping this thread every week or so.
They can but they don't en-mass, because if they did this means that bitcoin itself has failed, since we then have a collusion of majority hashing power. For the sake of argument, let's say you're right and that is occurring now. What exactly does the 'word' being spread about censorship actually accomplish? Since the majority of hashing power are colluding, they can do whatever they want, and no amount of social engineering will help that. The solution is an emergency hard fork to another mining algorithm which renders so all of the miners' equipment useless. This has been discussed before and it is a solution if miners were to be colluding to the detriment of bitcoin. Op, the problem is that if people's transactions could be made dependent on another person, they are not acting to their own interests. Buy linking their transactions to the censored one, their own transactions will also not confirm and that is detrimental to their own interests. |
|
|
|
|
Have you compiled the software? There are c++ things that armory uses and those need to be compiled. It looks like you may not have compiled it.
|
|
|
|
Am I OK to update core to 0.12.0 and keep using armory until you release a new version?
Yes. 0.93.3 works fine with bitcoin core 0.12 |
|
|
|
|
Can we add support for compressed keys to the list of things to do?
|
|
|
|
That's what this community need. An escrow service by a user with clean background not others whose accounts are suspected to be bought
Don't get me wrong but charging 0.01 btc at the beginning of your service seems to be big
Well I have heard that escrowing can be difficult and many times people don't tip. The thing is, I want a little reward, but if I started out without a fee and then started charging a fee later, then people wouldn't like it. Instead I will start out with a higher fee and over time I may lower that. Also, I don't want a ton of escrow requests because they take a lot of time so this is a little barrier to keep the load lower. |
|
|
|
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. Why do we need ilbsecp256k1 and what does that have to do with the bootstrap.dat? |
|
|
|
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  It looks like your main problem is slow internet speed, and there really is nothing that can be done to speed it up except get better internet. |
|
|
|
Does the error persist with this version?
Pushed some more changes, make sure you pull from b24dcb2 onwards.
Working well. No problems yet. Edit: I also get the same coin control problem droark mentioned in the other thread. Here is the traceback: (ERROR) Traceback (most recent call last):
File "/home/andy/bitcoin/armory/BitcoinArmory/ui/TxFrames.py", line 785, in createTxAndBroadcast
ustx = self.validateInputsGetUSTX()
File "/home/andy/bitcoin/armory/BitcoinArmory/ui/TxFrames.py", line 602, in validateInputsGetUSTX
utxoList = self.getUsableTxOutList(totalSend)
File "/home/andy/bitcoin/armory/BitcoinArmory/ui/TxFrames.py", line 863, in getUsableTxOutList
utxos = cppAddr.getSpendableTxOutList(IGNOREZC)
File "/home/andy/bitcoin/armory/BitcoinArmory/CppBlockUtils.py", line 1969, in getSpendableTxOutList
def getSpendableTxOutList(self, ignoreZC=True): return _CppBlockUtils.ScrAddrObj_getSpendableTxOutList(self, ignoreZC)
RuntimeError: not implemented
|
|
|
|
That person is a scammer. Make sure that you use the real monbux. Anything that isn't his official thread is not him. |
|
|
|
|
Your transaction spends inputs from an unconfirmed transaction which also spends inputs from an unconfirmed transaction and so on and so forth for quite a few transactions. That unconfirmed transaction chain was probably dropped by blockchain.info as long unconfirmed transaction chains are usually not kept by most nodes.
The only way for your transaction to confirm is if every transaction before it in the chain also confirm.
|
|
|
|
The are two ways to send a transaction. The node can send an 'inv' message with the txid of the transaction. Then the peers respond with a 'getdata' message for that transaction and your node responds with a 'tx' message which contains the transaction. Alternatively the node can simply send 'tx' messages to its peers. Both methods require sending unsolicited messages to the peers.
makes sense. So with 3 nodes, A, B and C. A can simply send a tx message to B and then I wait to see if B sends it to C. If it does, that indicates B was happy with the tx, if not, then rummage through the debug log to see why it rejected it. And this will work even if A is a non-relaying node? Of course B has to be a relaying node. James Actually, if node b rejects your message, it will respond to you with a 'reject' message which will include an error code for the reason of the rejection. |
|
|
|
Everything seems crystal clear now , thank you so much .
One more question now ,you said the node sends it to every peer it is connected to , does it mean that every bitcoin user on the world is connected ? Same thing goes for Lightweight wallets & web wallets ?
Yes. Any node, both full and SPV, are indirectly connected to every other node on the network. |
|
|
|
|
The are two ways to send a transaction. The node can send an 'inv' message with the txid of the transaction. Then the peers respond with a 'getdata' message for that transaction and your node responds with a 'tx' message which contains the transaction. Alternatively the node can simply send 'tx' messages to its peers. Both methods require sending unsolicited messages to the peers.
|
|
|
|
For what comes to the peer-to-peer part , does it when when I make a transaction and it gets added to the blockchain , I will also send it to other people ? just like Windows 10 do updates ? It take the updates from people instead from a centralized Microsoft server ?
When you make a transaction, your node sends it to every peer it is connected to. So yes, your analogy kind of works, except that the updates come from everyone. one more thing , do you have an idea how the password exactly works and what encryption is used ? I mean the password is stored where ? on the wallet.dat and encrypted using what algorithm ? and is it added to the wallet.dat once you setup the password ?
The password is local and client specific. In bitcoin core, the password is hashed and manipulated a couple times to generate an encryption key. The wallet is then encrypted with AES-256 with that encryption key. I don't think any form of the password is actually kept in the wallet. 'm sorry if I'm bothering you with my silly questions btw , just need to know nthis stuff.  No problem. I'm happy to help. |
|
|
|
Looks like you are missing entire parts of the C++ STL. Which compiler are you using? Also, is it C++11 compatible? I am using gcc 5.2.1. It looks like the problem is fixed and now I am running it for testing. Edit: I'm getting an error about invalid varint -DEBUG - 1456328054: (Blockchain.cpp:213) Organizing chain
-INFO - 1456328054: (DatabaseBuilder.cpp:47) updated HEADERS db in 0.311487s
-ERROR - 1456328054: (StoredBlockObj.cpp:1346) invalid varint in SSH data
-ERROR - 1456328054: (BDM_mainthread.cpp:429) BDM thread failed: invalid varint
|
|
|
|
|
Show Posts
