No i am not in control of the wallet at the receiving end.Can you tell me why am i getting *Transaction Does Not Exist* at ViaBTC?
Either you transaction did not propagate to the network well, or the fee is so low that ViaBTC's node has chosen to forget your transaction. You can rebroadcast your transaction with any transaction broadcast service like https://blockchain.info/pushtxThe raw transaction is 0100000004ec18a86c70008704b99f5d5c56a6db37e7a0ca41198524bb26c409bbb0a76715000000006a4730440220283e9eeb5106fe3ca5d21969c73a596aba0c194c2046bba3dda3885e38d2628f02202e3c0b7a4d2468cd3b726a16f0cb01280ee3b5ae9d87c7ae8c5e08f78de0cf280121027011ddd90207a77aef7939acfff17e4d35fe215c26f05dbf0bf60d5824ecccceffffffff8b69afbdd0ae0b4613ce8d1ac569ac6cdd0714f8c9fcd2d343ce503f41dd4a71000000006a473044022054d5b733c3f02037faec5e0e6aa7216b3e5362b99c3876008da6eee0c9d89e7a0220617bd48eee9fc62309c30a0b0c8a2cd31d47041c7abe73ce6f811cda1e73b5d601210207a5729a52d586e2f51f83c3c4ef6442a78e6754ea052672d7b0968c0431f49affffffff9cf45e12a8400c6fc5d19008ed3cd44d16e16d54bd96f4a3ccc059ca95601473000000006b483045022100f24742fb4df58817de0e1d2a23243e89452eb156629015265d08abb5e3c5680902201ba7890e5b2cc3dd78024654b04ffd64e2535647cf62dfdd7f78e692db10d7dd01210340d3481902b6f8e01317114393428290b3cc599ab1222fe259f6e5689f0840edffffffff1edc2afef58857822923facf7ef62f02cfcd4b1b0ef10e834aae7755bd848fe3000000006a47304402201b86ecc3c0167b3296ae8053e2428ea216bf6ee9788f8db6ce340ba5c39aad1b022031f81d06548ebafc6caf68a553cada3f01f8e4f48e8ef7787c5346865c12cf07012102ed60ea9656123466bc3d2b9f135d6bebca7eb7b2e675525590894c7a7a2ce60bffffffff0204040000000000001976a9145f75ae45d42c74192f8e10f77bf20f41914c5c4488acc6b26e00000000001976a9146c57b9ddb152bdca7ede1206021a3cef9642489f88ac00000000 I have rebroadcasted it through my node. ViaBTC's accelerator may be able to find your transaction now. |
|
|
|
This topic has been moved to Trashcan. Link Shortener, spam, off topic |
|
|
|
Both BIPs are proposals for a User Activate Soft Fork. BIP 148 specifies that Starting on August 1st, all blocks must signal for segwit. This is enforced by having a majority of users and miners running BIP 148 nodes so that that rule is enforced. This will mean that segwit will activate by miner signalling per the current BIP 9 deployment. BIP 149 is a renewal of the current segwit deployment system except it uses the BIP 8 deployment system instead of the BIP 9 system. This BIP specifies that segwit will activate on July 4th 2018 if it is not already activated by miner signalling beforehand. |
|
|
|
I have a question. Since segwit requires 95% of miners to upgrade. What if 20% from these are Bitcoin core enemies doesnt want to upgrade to delay the segwit upgrading of Bitcoin core? Are we going to stuck from very slow blockchain forever? Sorry If my question doesnt have any sense  Then we won't get segwit for a while. There are movements such as the UASF (User Activated Soft Fork) movement which aims to get segwit activated without relying entirely upon the miners. Should the UASF be successful, then Segwit will be activated. Don't conflate the blockchain with the speed of which your transactions confirming. The blockchain is not slow. Rather there are more unconfirmed transactions being made than can be included in blocks. |
|
|
|
|
How much RAM do you have in that machine? I suggest lowering the dbcache since I think you are running out of RAM.
|
|
|
|
Will Bitcoin Core need to re-sync or validate the blockchain all over again (which will take 4-5 days)?
No. It will just delete the stuff it doesn't need. |
|
|
|
This topic has been moved to Trashcan. Duplicate thread |
|
|
|
I read everywhere SegWit and 1MB block or SegWit and 2MB block. But these numbers are sort of misleading for traffic estimation since there is also present a witness part?
Yes. Segwit and 1 MB block means that the non-witness space of a block is 1 MB, and witness space is 3 MB, so the entire block is actually 4 MB. Segwit and 2 MB block means that non-witness space of a block is 2 MB and witness space is 6 MB so the entire block is actually 8 MB. |
|
|
|
1. So, on one hand, supposedly OpenSSL was fine for being used?
OpenSSL was fine, but not ideal. Everyone would have had to use OpenSSL's implementation of BER in order to be consistent. However there were certainly multiple implementations prior to BIP 66's activation that did not use OpenSSL but rather other crypto libraries. There could have been chain forks and inconsistency if someone had used a BER signature, but no one ever did. 2. Yet dev wanted to move away from OpenSSL for libsecp256k1 while keeping the ledger prior to libsecp256k1 implementation at the expense of keeping the prior ledger, thus forcing inaccuracy on it?
What is this "inaccuracy"? How does libsecp256k1 force inaccuracy? The Core devs wanted to move away from OpenSSL for multiple reasons. First of all, OpenSSL has been known in the past to have several severe vulnerabilities. Secondly, OpenSSL contained a lot of extra code that Bitcoin does not utilize. And thirdly, libsecp256k1 is far more efficient than OpenSSL and is more resistant to attacks specifically on ECDSA. BIP 66 guaranteed that every single piece of Bitcoin software did not have to rely on the way that OpenSSL decoded BER signatures. It forces all signatures to use strict DER, which has a well defined specification. This means that any software that does ECDSA signing or verification can use any implementation that follows the ECDSA and DER specifications. For example, Armory uses the crypto++ library for all of its cryptography stuff (which includes ECDSA and DER signatures) ever since it was created. 3. ...I'm under the impression that inflation has occurred (sure, there is a max coin limit, but how long until enough trading occurs to resolve the issue with there being multiple prior ledgers to the point that they're ridiculously insignificant if but no longer existent and no one has a pre-libsecp256k1 ledger?
There are not multiple prior ledgers. Why do you think that would be the case? If there were, then any transactions made on those ledgers either also happened on the current Bitcoin blockchain, or are completely invalid on the current Bitcoin blockchain. There is not inflation of Bitcoin as defined by the current blockchain. |
|
|
|
Very interesting. I think I've already answered your questions.
No you did not. You said there was a fork and you think that fork caused inflation. You did not explain in what way that fork causes inflation. You did not explain how previous forks are involved in inflation in any way whatsoever. You have not explained what mechanism causes inflation. Forks by themselves do not cause inflation, they have to change the consensus rules governing the money supply in order to do that. All you have said is that "there were forks and it seems like they caused inflation" but you haven't actually said anything as to how a fork causes inflation. I am inclined to believe that you are trolling given that you fail to understand how Bitcoin, forks, and BIP 66 even work even after I explained it to you. |
|
|
|
|
Your transaction has been confirmed now.
|
|
|
|
|
Your transactions have been confirmed now.
|
|
|
|
|
Get an address from your ledger. Withdraw from Kraken and send the Bitcoin to the address.
|
|
|
|
Different question. Can someone ELI5 me on how to use RBF in armory? I tried to make a tx with RBF enabled, that worked. It shows the tx with the comment *Right click to bump fee*. 0 conf When I right click it a pop up appears but when i press "bump fee" in that nothing happens. When opening "send bitcoins" again and RBF control enabled (it shows description: *RBF subset*) and recreate the same amount to the same address just with a higher fee I get the message "Coin selection failed with error: "Invalid spend value"  2017-05-18 11:11 (ERROR) -- Traceback (most recent call last):
File "ArmoryQt.py", line 3340, in showContextMenuLedger
File "ArmoryQt.py", line 5891, in bumpFee
File "ui\TxFrames.pyc", line 1295, in prefillFromBatch
File "ui\TxFrames.pyc", line 1342, in prefill
KeyError: 'change' Apparently RBF was broken in 0.96 and we didn't notice. Try using 0.96.1-testing build. It should be fixed there. |
|
|
|
I am on about the possibility that there is inflation in the current Bitcoin system. It appears that it has been controlled so far by social contracts and the social cohesion of the miners.
Inflation is controlled by the consensus rules. Inflation in Bitcoin is done through the block subsidy, which follows a strict schedule. If you were to mine a block which does not follow these consensus rules, then everyone else who is following them will reject your block as invalid. Given that everyone is using the same consensus rules, the Bitcoin mined in that block would be completely worthless since you cannot spend it anywhere. I'm talking about prior to BIP66 that there are forks and that after BIP66 implemented libsecp256k1, a hard fork of the blockchain was for sure. I'm now repeating myself, I believe and do not understand why you have said what you have said.
By definition, BIP 66 is a soft fork. It makes something previously valid, invalid. That is the definition of a soft fork. BIP 66 made DER, a subset of BER, the only valid signature format. This does not break anything since prior to BIP 66's activation, DER was still the only signature format that was actually used, even though BER could have been too. Where is this inflation coming from? What caused it to happen? Can you please explain that, because BIP 66 does not change the money supply at all. How did any of the past forks cause more inflation when they don't even touch the block subsidy schedule (which would require a hard fork anyways, and no hard fork has been executed in Bitcoin)? I firmly believe that you have no idea what you are talking about, are spreading FUD, and pumping Ethereum. |
|
|
|
Can you please add a note to include the txid needing confirmation in the initial PM to me? I am receiving an increasing number of PMs asking for help every day, and it is becoming a hassle asking users for the txid in response to a message asking if I can help. This is especially true considering that the time I am able to devote to the forum is declining.
Thanks.
Done. |
|
|
|
|
What are you going on about?
ASN.1 BER is a specification for a way to format ECDSA signatures. DER is a subset of BER which Bitcoin uses. However, prior to BIP 66's activation, signatures could be in the BER signature format, but no signatures actually were. What BIP 66 did was that it required every ECDSA signature following the soft fork's activation to follow the strict DER signature format. There are not multiple Bitcoin blockchains because of this and it does not affect any Bitcoin prior to the soft fork since no signature used the BER format. BIP 66 only removes the vulnerability so that it cannot be exploited.
The OpenSSL dependency is because no known software decoded all BER signatures in the exact same way, so if BER were to be used, then everyone would have to use the same software, which, at the time, was OpenSSL.
There is no "more accurate blockchain" or anything like that. Changing to strict DER signature format only effects the signature format, nothing else. It does not effect the money supply, difficulty, "accuracy" (whatever the hell that means), or whatever. BIP 66 only effects the signature format and enforces that all signatures must follow the format that everyone was already using.
|
|
|
|
Chances are you were short on blocks.
Can you translate this to the common tongue?  Your node or Armory's database did not have a fully synced blockchain. |
|
|
|
I've already synchronized the block with prune=2096 in bitcoin.conf. Can I simply change this to prune=550 and relaunch Bitcoin Core? Will it reduce the block folder down to 550MiB?
Yes. |
|
|
|
What are blockchain reorgs?
Reorgs are short for reorganizations. These happen when there are forks in the blockchain and your node switches from one fork to a different fork. I want to use Bitcoin Core, but I would prefer to store as little of the blockchain as possible. Is there an optimal size for the pruned block folder?
Just use the default prune size of 550. It is the smallest size but still provides sufficient protection against reorgs as it stores ~2 days worth of blocks. |
|
|
|
|
Show Posts
