She can't 'double spend' between blocks. Technically she could but this is really hard to do as soon as the transaction has a single confirmation. Do you mean unconfirmed transactions? You should not generally accept 0-conf transactions unless the amount is negligible or you trust the other party. There are a few known types of attacks in regards to double spends. This image might also be useful for your general understanding. So if she can't double spend between blocks what is stopping her from doing that? is it the wallet that wont allow her to send more than she has? The double spends are spending inputs that are already spent. It is entirely possible for her to create 10 transactions that spend the same input and send the Bitcoin to 10 different people. However, the consensus rules allow only one of those transactions to be confirmed and thus committed to permanent history. Any transaction that spend off of the other rejected transactions would forever remain unconfirmed and thus susceptible to being impermanent. |
|
|
|
Yes, that was easy, Thank You!!
Anyone know why I do not get the correct WIF with the ./wif
using this hex input?:
0x28, 0x8f, 0x39, 0xbb, 0xfd, 0x36, 0xda, 0x5a,
0x12, 0xd1, 0x62, 0xcb, 0x18, 0x97, 0xc9, 0x02,
0x28, 0x8b, 0x39, 0xbb, 0x36, 0xda, 0x5a, 0x12,
0xd1, 0x62, 0xcb, 0x18, 0x97, 0xc9, 0x02, 0x3d
I get:
cNwYW8cjd5eywJeSzorEpw5uEfEFdRtqEo55MEsiPiizv4Dk4mNr
the coin flip post calculated:
5J89cr5WGdvQWeeekN5ZGzuXVsWREbAYku6MDeUgrJTjX1ZHhCX
That is because it is doing it for testnet. You need to change the line to Also, if you want the uncompressed key, you need to comment out and change to |
|
|
|
I also get the same coin control problem droark mentioned in the other thread
Should be fixed now. Introduced a new feature to rescan balances. Let's you fix balance errors without doing a full rescan, takes less than a minute on average (it's actually <1 sec on my machine). No need to wipe the DB with this commit, just try it as is. They both appear to work now. |
|
|
|
Where can i find info about all future block halving and when they gonna occur?
And how many coins block should contain at thet time.
The block reward halving happens every 210000 blocks. You can see more at https://en.bitcoin.it/wiki/Controlled_supply |
|
|
|
|
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. |
|
|
|
|
Show Posts
