|
From that error message it looks like Armory is unable to verify the signed announcement messages.
Could you post your armory logs?
Also, it would be a good idea to submit a bug report to Armory by going to Help > Submit Bug Report in Armory.
|
|
|
|
Hi all,
I have google searched the topic above and have been led to many discussions that took place before which are irrelevant today.
How are they irrelevant? What I am about to explain to you has been discussed over and over again, and nothing has changed since those discussions happened I have been researching about 0 transaction fee payments recently and found that it doesn't get through anymore. Using an online wallet such as Blockchain.info, these bitcoins are returned after a long waiting time. (days even).
I did a test and sent multiple 0.01 btc to an address and set the transaction fee to 0. They were all stuck and after a long time became available to use again.
Is there a way to unlock these transactions sooner, rather than waiting for the funds to be unlocked? Anyone has had any good or bad experience trying this as well?
Technically they are not locked. There is nothing in the protocol that prevents you from sending another transaction that spends the same input, it is just that wallets do not allow this to prevent double spend attempts. To spend the Bitcoin, you need your wallet to forget about the unconfirmed transactions. This can be done many ways and the methods differ for each client. IIRC blockchain.info doesn't allow this. Since the transactions have 0 fee, you are more likely to be able to double spend since nodes will not have relayed the transaction. There are methods to increase the fee of a transaction. If an output went back to you in the transaction, you can attempt a CPFP (Child pays for parent) transaction where you spend that output and pay the fee for both the unconfirmed transaction and the new transaction in the new transaction's fee. The other method is a RBF (Replace by fee) transaction which allows you to legitimately double spend the transaction. RBF allows new transactions that spend the same inputs of an unconfirmed transaction if the fee on that new transaction is higher. Both of these methods require that nodes and miners have software the support those features. RBF will be included in Bitcoin Core 0.12 but CPFP is currently not supported by many nodes or miners. AFAIK eligius is the only pool that supports mining CPFP transactions. |
|
|
|
|
bump
BTW, the buyer can also choose to send first if escrow is not desired.
|
|
|
|
Something to mull over. For all of those people that say "small blocks are fine, because Lightning Network", check out the following LN matrix:
--snip--
Assumptions and extrapolations
½ of txs are LN opens and closes
½ of LN closes and opens are merged
No non-cooperative closes
3 Channels per user
When indefinite, channels last 6 months
LLvl 1: 150 chan / year, 150 close, 75 open
LLvl 2: 6 chan / year, 6 close 3 open
LLvl 3: 6 chan / year, 6 close 3 open
Even with 32MB blocks and the soft forks needed to make LN most efficient, we only get to around 280M users. That's not exactly tiny but it's also not competing with credit cards anytime soon. Without big blocks, LN just can't scale period.
And how about using sidechains? Or segwit? |
|
|
|
Some people want to do it anonymously i guess, or leave the trace out of their main bank account, or distrust a Centralized exchange since the point of BTC is just that.
I do it in Canada now and it takes at most 24 hours to receive the money in my bank account and buying with interact is instant and cost a flat fee of 1CAD$
Besides anonymity, people have had issues with Coinbase mysteriously closing accounts and preventing people from withdrawing the coins that they bought or deposited. Also, some people are not comfortable with sharing all of their personal info with an exchange. |
|
|
|
There is a web application which creates for each user its own account in wallet. Main problem is the bitcoin daemon with time becomes slow and almost does not load new blocks from network.
I reckon the reason is the huge number of "move" RPC command (which transfer coins from main account to user's account). In these conditions Bitcoin daemon uses more than 50% of CPU and 30% of MEM.
Main problem is how to force daemon to load new blocks. Any suggestions?
Get better hardware that has a faster cpu, faster/more RAM, and a disk with a high read/write speed (e.g. SSD) since a lot of those operations involve the wallet and constantly reading and writing the wallet to and from the disk. |
|
|
|
Yes, there are a few signature campaigns which accept Junior Members. In my opinion, Yobit.net signature campaign is the best one for beginners, because the post are counted by an bot several times a day.
How does the bot make sure the quality of the posts is good? It doesn't, which is partly why there are many yobit sig spammers. It tends to have the worst and most spammers but since hilariousandco began to run the campaign a some time ago, the campaign has been cracking down on spammers. |
|
|
|
Im not spammer.I have written them in the light of my knowledge,i dont even know the size of the transaction is factor in the confirmation,i have not seen it at anywhere.
The size of the transaction does matter since the fee is actually fee per kilobyte (btc/kb). Since you are essentially paying for space in a block, if you have a big transaction, you should pay more for that space so the fee will be higher. |
|
|
|
I'm running 0.11.2, and I've got a peer running XT. I saw this 0.12.0 running for about an hour this morning. There weas also a 0.11.99 which I believe is a test version. Good to see there are some improvements on the way. Does anyone know what they are?
Any satoshi client ending in 99 is a build of the matter branch from the git repo. 0.12 is a build from the 0.12 branch but 0.12 isn't ready for release. |
|
|
|
2016 will be the year where we can expect different Bitcoin implementations in the wild. Until now it was enough to have one Bitcoin reference implementation in form of code but what we need now is a specification of Bitcoin in form of Requests for Comments. The wild west time should end now. Boy's you've had your fun. We were impressed of your egos. Grow up or leave please. Now we need professionalism to continue the success story of Bitcoin! http://www.rfc-editor.orghttp://www.ietf.org/rfc/rfc2223.txtBitcoin related stuff should not be governed by the ietf but rather by a specific group for bitcoiners. Also, there already is an RFC like thing in bitcoin, BIPs. Bitcoin is specified by these BIPs and the bitcoin white paper with the reference implementation to provide exactly that. |
|
|
|
i. Does Purse.io work without Coinbase?
ii. Can I use Purse.io on Amazon.in?
Yes and yes iii. Which rate Purse.io uses for BTC to FIAT coversion? Coinbase rate or their own rate?
The rate is essentially determined by the bitcoin seller. It is what determines the discount. |
|
|
|
|
What does the blockchain have to do with machine learning? It is a distributed ledger, there is no machine learning.
|
|
|
|
What does "staked" mean?
It means that the address was posted for a primary purpose of proving ownership of the account at a later date. The proof of account ownership is a message signed by that staked address. |
|
|
|
I would like to ask how old the signed message was staked or posted by that account? If the account was too old (5 Months+) I would like to bid from the starting bid.
The address was staked about 3 months ago. |
|
|
|
I am auctioning a full member account that has some potential. Full account details (with the usual obfuscation) can be found here: http://www.bctalkaccountpricer.info/?token=ikkkst6dPosts: 120+ Activity: 120+ Trust: Neutral Starting bid: 0.03 BTCMinimum increment: 0.005 BTCBuy It Now: 0.07 BTCAuction will end on January 16th 11:59 PM Forum time. If you buy, you must use an escrow from this list: https://bitcointalk.org/index.php?topic=855778.0 and you must pay the fees, if any. A signed message can be provided upon request. |
|
|
|
Your second transaction (bfee081b32d83ca69703ef3cbf5ef5b68c43df7bd79ff7f41e9e54e015c7ce0c) has a 1 satoshi fee, which is way too small to be a good fee. The first transaction is spending from that unconfirmed transaction. Since it relies on an unconfirmed input, it itself cannot be confirmed until that input is also confirmed, thus it remains unconfirmed. |
|
|
|
Looking at program rules for bitcoind and QT, I could see that there were no restrictions to incoming traffic. I also tried temporarily disabling the firewall. I still get MyIP:8333 is unreachable on bitnodes.21.co. My router is a D-Link DIR-655, Hardware Version: B1, Firmware Version: 2.11NA. After setting up port forwarding in my router for 8333 directly to the computer running Bitcoin core and eliminating my firewall as the problem, I'm not sure what to try next. Is there something else I can check that could be preventing my Bitcoin client from accepting incoming connections from other nodes? There isn't anything else that I can think of. Are you sure that you disabled all of the firewalls, including the OS firewall, Antivirus firewall, etc? Also, it may be possible that your ISP is also blocking connections in which case you can't do anything about it. Another thing is that bitnodes may not be connected to you yet which would explain why they can't see you. If you are willing to share your IP address, I can also try connecting to you and seeing if it works. |
|
|
|
...
Yeah I've figured it out few minutes ago but as I've said in my previous post there's no input value:
...
The link above may have what you are looking for. Ok thanks, I've missed that  UPDATE: it took me few minutes to get it, correct me if I'm wrong -> http://pastebin.com/keYrsW46<?php
require_once("json-rpc.php");
$rpc = new Connector("username", "password", "127.0.0.1", "18333");
$txid = "7f502f28ca8d162300a1bbc8cb7dfa6f38533596ac97c29e1d1de9ca614ae350",
$txinfo = $rpc->getrawtransaction($txid, 1); // get info from received tx
$txinput = $txinfo["vin"][0]["txid"]; // result: fd018b006c8702139d1c230460c1a71f99d364d59c339e26cc8588cf622a5be9
$spent = $txinfo["vout"][0]["value"] + $txinfo["vout"][1]["value"]; // result: 0.73000000 + 10.96563674 = 11.69563674
$txinfo = $rpc->getrawtransaction($txinput, 1); // get info from input tx of received tx
$fee = $txinfo["vout"][1]["value"] - $spent; // result: 11.69569708 - 11.69563674 = 0.00006034
print($fee);
?>
Looks good. |
|
|
|
I'm actually doing it via Bitcoin API and PHP. I tried gettransaction but it doesn't print the fee amount.
gettransaction will not give you the fee if you received the transaction, only if you sent. You should use getrawtransaction. With that command you can retrieve the vout values of all of the outpoints of the inputs and the output. Then just use those the calculate the fee. |
|
|
|
|
Show Posts
