Bitcoin Forum
July 06, 2024, 12:08:13 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 [257] 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 ... 590 »
5121  Bitcoin / Armory / Re: Armoury 0.95 - "Building database" forever on: October 27, 2016, 10:56:56 PM
No such luck. I even tried reindexing my Bitcoin database and then ran ArmoryDB. ArmoryQT in debug mode spams out...
Code:
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
Armory 0.93.3 and 0.94.1 work fine, but not 0.95.0
That error is due to it being unable to connect to Bitcoin Core's RPC server. What version of Bitcoin Core are you using? What is inside of the bitcoin.conf file?
5122  Bitcoin / Bitcoin Technical Support / Re: no confirmation, want to resend transaction on: October 27, 2016, 10:44:22 PM
abandon trasaction is greyed out, i cant click it

Then start Bitcoin Core with the -zapwallettxes option. See https://achow101.com/2016/07/Bitcoin-Core-Troubleshooting#option-startup for help with that.

With Bitcoin Core, you can right click the transaction in the list and choose "Abandon transaction". Then send your Bitcoin again with a higher fee.

How do you know the new transaction will use the same inputs? If it doesn't use the same inputs then it isn't a double spend.
IIRC Coin selection is fairly deterministic. Given the same set of UTXOs and the same outputs, it should be choosing the same UTXOs as inputs. Increasing the fee should not affect that too much unless dust UTXOs are being spent.
5123  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.13.1 Released on: October 27, 2016, 10:07:50 PM
It might be an idea to mention to MacOS/OSX users: support for 10.7 is dropped in 0.13.1 and 0.13, this has only just been established I think. 10.8 is now the minimum OS version for Macintosh users.
It's right there under "Compatibility". The last paragraph.
5124  Other / Meta / Re: Alert for mentions on the forum on: October 27, 2016, 09:59:12 PM
I'm not sure whether this should be in Meta or Project Development. If it's requested to move, then I'll do so as soon as I can. Anyway!
This should be in meta.

Is there some sort of notification for being mentioned in a post, like if someone had quoted you, or posted your name apart from searching your name?
Nope.

If not, then has anybody made anything [script] to automate the search process and fetch mentions?
AFAIK no such script exists. However one could certainly be made to do so. I think it would not be that hard to do.
5125  Bitcoin / Bitcoin Discussion / Bitcoin Core 0.13.1 Released on: October 27, 2016, 07:02:30 PM
Bitcoin Core version 0.13.1 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.13.1/>
This is a new minor version release, including activation parameters for the
segwit softfork, various bugfixes and performance improvements, as well as
updated translations.

Please report bugs using the issue tracker at github:

  <https://github.com/bitcoin/bitcoin/issues>

To receive security and update notifications, please subscribe to:

  <https://bitcoincore.org/en/list/announcements/join/>

Compatibility

Microsoft ended support for Windows XP on April 8th, 2014,
an OS initially released in 2001. This means that not even critical security
updates will be released anymore. Without security updates, using a bitcoin
wallet on a XP machine is irresponsible at least.

In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
randomly crashing on Windows XP. It is not clear
what the source of these crashes is, but it is likely that upstream
libraries such as Qt are no longer being tested on XP.

We do not have time nor resources to provide support for an OS that is
end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are
suggested to upgrade to a newer version of Windows, or install an alternative OS
that is supported.

No attempt is made to prevent installing or running the software on Windows XP,
you can still do so at your own risk, but do not expect it to work: do not
report issues about Windows XP to the issue tracker.

From 0.13.1 onwards OS X 10.7 is no longer supported. 0.13.0 was intended to work on 10.7+,
but severe issues with the libc++ version on 10.7.x keep it from running reliably.
0.13.1 now requires 10.8+, and will communicate that to 10.7 users, rather than crashing unexpectedly.

Notable changes

Segregated witness soft fork

Segregated witness (segwit) is a soft fork that, if activated, will
allow transaction-producing software to separate (segregate) transaction
signatures (witnesses) from the part of the data in a transaction that is
covered by the txid. This provides several immediate benefits:

  • Elimination of unwanted transaction malleability: Segregating the witness
      allows both existing and upgraded software to calculate the transaction
      identifier (txid) of transactions without referencing the witness, which can
      sometimes be changed by third-parties (such as miners) or by co-signers in a
      multisig spend. This solves all known cases of unwanted transaction
      malleability, which is a problem that makes programming Bitcoin wallet
      software more difficult and which seriously complicates the design of smart
      contracts for Bitcoin.
  • Capacity increase: Segwit transactions contain new fields that are not
      part of the data currently used to calculate the size of a block, which
      allows a block containing segwit transactions to hold more data than allowed
      by the current maximum block size. Estimates based on the transactions
      currently found in blocks indicate that if all wallets switch to using
      segwit, the network will be able to support about 70% more transactions. The
      network will also be able to support more of the advanced-style payments
      (such as multisig) than it can support now because of the different weighting
      given to different parts of a transaction after segwit activates (see the
      following section for details).
  • Weighting data based on how it affects node performance: Some parts of
      each Bitcoin block need to be stored by nodes in order to validate future
      blocks; other parts of a block can be immediately forgotten (pruned) or used
      only for helping other nodes sync their copy of the block chain.  One large
      part of the immediately prunable data are transaction signatures (witnesses),
      and segwit makes it possible to give a different "weight" to segregated
      witnesses to correspond with the lower demands they place on node resources.
      Specifically, each byte of a segregated witness is given a weight of 1, each
      other byte in a block is given a weight of 4, and the maximum allowed weight
      of a block is 4 million.  Weighting the data this way better aligns the most
      profitable strategy for creating blocks with the long-term costs of block
      validation.
  • Signature covers value: A simple improvement in the way signatures are
      generated in segwit simplifies the design of secure signature generators
      (such as hardware wallets), reduces the amount of data the signature
      generator needs to download, and allows the signature generator to operate
      more quickly.  This is made possible by having the generator sign the amount
      of bitcoins they think they are spending, and by having full nodes refuse to
      accept those signatures unless the amount of bitcoins being spent is exactly
      the same as was signed.  For non-segwit transactions, wallets instead had to
      download the complete previous transactions being spent for every payment
      they made, which could be a slow operation on hardware wallets and in other
      situations where bandwidth or computation speed was constrained.
  • Linear scaling of sighash operations: In 2015 a block was produced that
      required about 25 seconds to validate on modern hardware because of the way
      transaction signature hashes are performed.  Other similar blocks, or blocks
      that could take even longer to validate, can still be produced today.  The
      problem that caused this can't be fixed in a soft fork without unwanted
      side-effects, but transactions that opt-in to using segwit will now use a
      different signature method that doesn't suffer from this problem and doesn't
      have any unwanted side-effects.
  • Increased security for multisig: Bitcoin addresses (both P2PKH addresses
      that start with a '1' and P2SH addresses that start with a '3') use a hash
      function known as RIPEMD-160.  For P2PKH addresses, this provides about 160
      bits of security---which is beyond what cryptographers believe can be broken
      today.  But because P2SH is more flexible, only about 80 bits of security is
      provided per address. Although 80 bits is very strong security, it is within
      the realm of possibility that it can be broken by a powerful adversary.
      Segwit allows advanced transactions to use the SHA256 hash function instead,
      which provides about 128 bits of security  (that is 281 trillion times as
      much security as 80 bits and is equivalent to the maximum bits of security
      believed to be provided by Bitcoin's choice of parameters for its Elliptic
      Curve Digital Security Algorithm [ECDSA].)
  • More efficient almost-full-node security Satoshi Nakamoto's original
      Bitcoin paper describes a method for allowing newly-started full nodes to
      skip downloading and validating some data from historic blocks that are
      protected by large amounts of proof of work.  Unfortunately, Nakamoto's
      method can't guarantee that a newly-started node using this method will
      produce an accurate copy of Bitcoin's current ledger (called the UTXO set),
      making the node vulnerable to falling out of consensus with other nodes.
      Although the problems with Nakamoto's method can't be fixed in a soft fork,
      Segwit accomplishes something similar to his original proposal: it makes it
      possible for a node to optionally skip downloading some blockchain data
      (specifically, the segregated witnesses) while still ensuring that the node
      can build an accurate copy of the UTXO set for the block chain with the most
      proof of work.  Segwit enables this capability at the consensus layer, but
      note that Bitcoin Core does not provide an option to use this capability as
      of this 0.13.1 release.
  • Script versioning: Segwit makes it easy for future soft forks to allow
      Bitcoin users to individually opt-in to almost any change in the Bitcoin
      Script language when those users receive new transactions.  Features
      currently being researched by Bitcoin Core contributors that may use this
      capability include support for Schnorr signatures, which can improve the
      privacy and efficiency of multisig transactions (or transactions with
      multiple inputs), and Merklized Abstract Syntax Trees (MAST), which can
      improve the privacy and efficiency of scripts with two or more conditions.
      Other Bitcoin community members are studying several other improvements
      that can be made using script versioning.

Activation for the segwit soft fork is being managed using BIP9
versionbits.  Segwit's version bit is bit 1, and nodes will begin
tracking which blocks signal support for segwit at the beginning of the
first retarget period after segwit's start date of 15 November 2016.  If
95% of blocks within a 2,016-block retarget period (about two weeks)
signal support for segwit, the soft fork will be locked in.  After
another 2,016 blocks, segwit will activate.

For more information about segwit, please see the segwit FAQ, the
segwit wallet developers guide or BIPs 141, 143,
144, and 145.  If you're a miner or mining pool
operator, please see the versionbits FAQ for information about
signaling support for a soft fork.

Null dummy soft fork

Combined with the segwit soft fork is an additional change that turns a
long-existing network relay policy into a consensus rule. The
OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY opcodes consume an extra
stack element ("dummy element") after signature validation. The dummy
element is not inspected in any manner, and could be replaced by any
value without invalidating the script.

Because any value can be used for this dummy element, it's possible for
a third-party to insert data into other people's transactions, changing
the transaction's txid (called transaction malleability) and possibly
causing other problems.

Since Bitcoin Core 0.10.0, nodes have defaulted to only relaying and
mining transactions whose dummy element was a null value (0x00, also
called OP_0).  The null dummy soft fork turns this relay rule into a
consensus rule both for non-segwit transactions and segwit transactions,
so that this method of mutating transactions is permanently eliminated
from the network.

Signaling for the null dummy soft fork is done by signaling support
for segwit, and the null dummy soft fork will activate at the same time
as segwit.

For more information, please see BIP147.

Low-level RPC changes

  • importprunedfunds only accepts two required arguments. Some versions accept
      an optional third arg, which was always ignored. Make sure to never pass more
      than two arguments.

Linux ARM builds

With the 0.13.0 release, pre-built Linux ARM binaries were added to the set of
uploaded executables. Additional detail on the ARM architecture targeted by each
is provided below.

The following extra files can be found in the download directory or torrent:

  • bitcoin-${VERSION}-arm-linux-gnueabihf.tar.gz: Linux binaries targeting
      the 32-bit ARMv7-A architecture.
  • bitcoin-${VERSION}-aarch64-linux-gnu.tar.gz: Linux binaries targeting
      the 64-bit ARMv8-A architecture.

ARM builds are still experimental. If you have problems on a certain device or
Linux distribution combination please report them on the bug tracker, it may be
possible to resolve them. Note that the device you use must be (backward)
compatible with the architecture targeted by the binary that you use.
For example, a Raspberry Pi 2 Model B or Raspberry Pi 3 Model B (in its 32-bit
execution state) device, can run the 32-bit ARMv7-A targeted binary. However,
no model of Raspberry Pi 1 device can run either binary because they are all
ARMv6 architecture devices that are not compatible with ARMv7-A or ARMv8-A.

Note that Android is not considered ARM Linux in this context. The executables
are not expected to work out of the box on Android.


0.13.1 Change log

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

### Consensus
- #8636 `9dfa0c8` Implement NULLDUMMY softfork (BIP147) (jl2012)
- #8848 `7a34a46` Add NULLDUMMY verify flag in bitcoinconsensus.h (jl2012)
- #8937 `8b66659` Define start and end time for segwit deployment (sipa)

### RPC and other APIs
- #8581 `526d2b0` Drop misleading option in importprunedfunds (MarcoFalke)
- #8699 `a5ec248` Remove createwitnessaddress RPC command (jl2012)
- #8780 `794b007` Deprecate getinfo (MarcoFalke)
- #8832 `83ad563` Throw JSONRPCError when utxo set can not be read (MarcoFalke)
- #8884 `b987348` getblockchaininfo help: pruneheight is the lowest, not highest, block (luke-jr)
- #8858 `3f508ed` rpc: Generate auth cookie in hex instead of base64 (laanwj)
- #8951 `7c2bf4b` RPC/Mining: getblocktemplate: Update and fix formatting of help (luke-jr)

### Block and transaction handling
- #8611 `a9429ca` Reduce default number of blocks to check at startup (sipa)
- #8634 `3e80ab7` Add policy: null signature for failed CHECK(MULTI)SIG (jl2012)
- #8525 `1672225` Do not store witness txn in rejection cache (sipa)
- #8499 `9777fe1` Add several policy limits and disable uncompressed keys for segwit scripts (jl2012)
- #8526 `0027672` Make non-minimal OP_IF/NOTIF argument non-standard for P2WSH (jl2012)
- #8524 `b8c79a0` Precompute sighashes (sipa)
- #8651 `b8c79a0` Predeclare PrecomputedTransactionData as struct (sipa)

### P2P protocol and network code
- #8740 `42ea51a` No longer send local address in addrMe (laanwj)
- #8427 `69d1cd2` Ignore `notfound` P2P messages (laanwj)
- #8573 `4f84082` Set jonasschnellis dns-seeder filter flag (jonasschnelli)
- #8712 `23feab1` Remove maxuploadtargets recommended minimum (jonasschnelli)
- #8862 `7ae6242` Fix a few cases where messages were sent after requested disconnect (theuni)
- #8393 `fe1975a` Support for compact blocks together with segwit (sipa)
- #8282 `2611ad7` Feeler connections to increase online addrs in the tried table (EthanHeilman)
- #8612 `2215c22` Check for compatibility with download in FindNextBlocksToDownload (sipa)
- #8606 `bbf379b` Fix some locks (sipa)
- #8594 `ab295bb` Do not add random inbound peers to addrman (gmaxwell)
- #8940 `5b4192b` Add x9 service bit support to dnsseed.bluematt.me, seed.bitcoinstats.com (TheBlueMatt, cdecker)
- #8944 `685e4c7` Remove bogus assert on number of oubound connections. (TheBlueMatt)
- #8949 `0dbc48a` Be more agressive in getting connections to peers with relevant services (gmaxwell)

### Build system
- #8293 `fa5b249` Allow building libbitcoinconsensus without any univalue (luke-jr)
- #8492 `8b0bdd3` Allow building bench_bitcoin by itself (luke-jr)
- #8563 `147003c` Add configure check for -latomic (ajtowns)
- #8626 `ea51b0f` Berkeley DB v6 compatibility fix (netsafe)
- #8520 `75f2065` Remove check for `openssl/ec.h` (laanwj)

### GUI
- #8481 `d9f0d4e` Fix minimize and close bugs (adlawren)
- #8487 `a37cec5` Persist the datadir after option reset (achow101)
- #8697 `41fd852` Fix op order to append first alert (rodasmith)
- #8678 `8e03382` Fix UI bug that could result in paying unexpected fee (jonasschnelli)
- #8911 `7634d8e` Translate all files, even if wallet disabled (laanwj)
- #8540 `1db3352` Fix random segfault when closing "Choose data directory" dialog (laanwj)
- #7579 `f1c0d78` Show network/chain errors in the GUI (jonasschnelli)

### Wallet
- #8443 `464dedd` Trivial cleanup of HD wallet changes (jonasschnelli)
- #8539 `cb07f19` CDB: fix debug output (crowning-)
- #8664 `091cdeb` Fix segwit-related wallet bug (sdaftuar)
- #8693 `c6a6291` Add witness address to address book (instagibbs)
- #8765 `6288659` Remove "unused" ThreadFlushWalletDB from removeprunedfunds (jonasschnelli)

### Tests and QA
- #8713 `ae8c7df` create_cache: Delete temp dir when done (MarcoFalke)
- #8716 `e34374e` Check legacy wallet as well (MarcoFalke)
- #8750 `d6ebe13` Refactor RPCTestHandler to prevent TimeoutExpired (MarcoFalke)
- #8652 `63462c2` remove root test directory for RPC tests (yurizhykin)
- #8724 `da94272` walletbackup: Sync blocks inside the loop (MarcoFalke)
- #8400 `bea02dc` enable rpcbind_test (yurizhykin)
- #8417 `f70be14` Add walletdump RPC test (including HD- & encryption-tests) (jonasschnelli)
- #8419 `a7aa3cc` Enable size accounting in mining unit tests (sdaftuar)
- #8442 `8bb1efd` Rework hd wallet dump test (MarcoFalke)
- #8528 `3606b6b` Update p2p-segwit.py to reflect correct behavior (instagibbs)
- #8531 `a27cdd8` abandonconflict: Use assert_equal (MarcoFalke)
- #8667 `6b07362` Fix SIGHASH_SINGLE bug in test_framework SignatureHash (jl2012)
- #8673 `03b0196` Fix obvious assignment/equality error in test (JeremyRubin)
- #8739 `cef633c` Fix broken sendcmpct test in p2p-compactblocks.py (sdaftuar)
- #8418 `ff893aa` Add tests for compact blocks (sdaftuar)
- #8803 `375437c` Ping regularly in p2p-segwit.py to keep connection alive (jl2012)
- #8827 `9bbe66e` Split up slow RPC calls to avoid pruning test timeouts (sdaftuar)
- #8829 `2a8bca4` Add bitcoin-tx JSON tests (jnewbery)
- #8834 `1dd1783` blockstore: Switch to dumb dbm (MarcoFalke)
- #8835 `d87227d` nulldummy.py: Don't run unused code (MarcoFalke)
- #8836 `eb18cc1` bitcoin-util-test.py should fail if the output file is empty (jnewbery)
- #8839 `31ab2f8` Avoid ConnectionResetErrors during RPC tests (laanwj)
- #8840 `cbc3fe5` Explicitly set encoding to utf8 when opening text files (laanwj)
- #8841 `3e4abb5` Fix nulldummy test (jl2012)
- #8854 `624a007` Fix race condition in p2p-compactblocks test (sdaftuar)
- #8857 `1f60d45` mininode: Only allow named args in wait_until (MarcoFalke)
- #8860 `0bee740` util: Move wait_bitcoinds() into stop_nodes() (MarcoFalke)
- #8882 `b73f065` Fix race conditions in p2p-compactblocks.py and sendheaders.py (sdaftuar)
- #8904 `cc6f551` Fix compact block shortids for a test case (dagurval)

### Documentation
- #8754 `0e2c6bd` Target protobuf 2.6 in OS X build notes. (fanquake)
- #8461 `b17a3f9` Document return value of networkhashps for getmininginfo RPC endpoint (jlopp)
- #8512 `156e305` Corrected JSON typo on setban of net.cpp (sevastos)
- #8683 `8a7d7ff` Fix incorrect file name bitcoin.qrc  (bitcoinsSG)
- #8891 `5e0dd9e` Update bips.md for Segregated Witness (fanquake)
- #8545 `863ae74` Update git-subtree-check.sh README (MarcoFalke)
- #8607 `486650a` Fix doxygen off-by-one comments, fix typos (MarcoFalke)
- #8560 `c493f43` Fix two VarInt examples in serialize.h (cbarcenas)
- #8737 `084cae9` UndoReadFromDisk works on undo files (rev), not on block files (paveljanik)
- #8625 `0a35573` Clarify statement about parallel jobs in rpc-tests.py (isle2983)
- #8624 `0e6d753` build: Mention curl (MarcoFalke)
- #8604 `b09e13c` build,doc: Update for 0.13.0+ and OpenBSD 5.9 (laanwj)
- #8939 `06d15fb` Update implemented bips for 0.13.1 (sipa)

### Miscellaneous
- #8742 `d31ac72` Specify Protobuf version 2 in paymentrequest.proto (fanquake)
- #8414,#8558,#8676,#8700,#8701,#8702 Add missing copyright headers (isle2983, kazcw)
- #8899 `4ed2627` Fix wake from sleep issue with Boost 1.59.0 (fanquake)
- #8817 `bcf3806` update bitcoin-tx to output witness data (jnewbery)
- #8513 `4e5fc31` Fix a type error that would not compile on OSX. (JeremyRubin)
- #8392 `30eac2d` Fix several node initialization issues (sipa)
- #8548 `305d8ac` Use `__func__` to get function name for output printing (MarcoFalke)
- #8291 `a987431` [util] CopyrightHolders: Check for untranslated substitution (MarcoFalke)

Credits
=======

Thanks to everyone who directly contributed to this release:

- adlawren
- Alexey Vesnin
- Anders Øyvind Urke-Sætre
- Andrew Chow
- Anthony Towns
- BtcDrak
- Chris Stewart
- Christian Barcenas
- Christian Decker
- Cory Fields
- crowning-
- Dagur Valberg Johannsson
- David A. Harding
- Eric Lombrozo
- Ethan Heilman
- fanquake
- Gaurav Rana
- Gregory Maxwell
- instagibbs
- isle2983
- Jameson Lopp
- Jeremy Rubin
- jnewbery
- Johnson Lau
- Jonas Schnelli
- jonnynewbs
- Justin Camarena
- Kaz Wesley
- leijurv
- Luke Dashjr
- MarcoFalke
- Marty Jones
- Matt Corallo
- Micha
- Michael Ford
- mruddy
- Pavel Janík
- Pieter Wuille
- rodasmith
- Sev
- Suhas Daftuar
- whythat
- Wladimir J. van der Laan

As well as everyone that helped translating on Transifex.
5126  Bitcoin / Bitcoin Technical Support / Re: Can someone explain where a transaction size comes from? on: October 27, 2016, 06:00:49 PM
This gets very technical and is kind of hard to explain.

So Bitcoin works by having transaction outputs (txo), not actually addresses. Addresses are just abstractions for a specific type of transaction output.

When you receive Bitcoin, a new txo is created. When you spend Bitcoin, you spend from a txo. Each txo becomes one input in the transaction. So, if you are sending a transaction which spends from a lot of txos, it will have a lot of inputs. Inputs have a size in bytes. Thus having a lot of inputs from spending from a lot of txos will make your transaction have a lot of bytes.

But if I now sent one transaction to you for 0.01BTC does the size still stay the same from now on? Wouldn't it just get bugger and bigger if I kept sending that same 0.01BTC over and over again?
No. There is no such thing as an object called a "bitcoin". Rather the Bitcoin are simply values associated with each TXO. When you spend a TXO, you create a new TXO that has at most the value of all of the input TXOs.
5127  Bitcoin / Bitcoin Technical Support / Re: no confirmation, want to resend transaction on: October 27, 2016, 04:14:34 PM
With Bitcoin Core, you can right click the transaction in the list and choose "Abandon transaction". Then send your Bitcoin again with a higher fee.
5128  Bitcoin / Bitcoin Technical Support / Re: Can someone explain where a transaction size comes from? on: October 27, 2016, 03:51:44 PM
This gets very technical and is kind of hard to explain.

So Bitcoin works by having transaction outputs (txo), not actually addresses. Addresses are just abstractions for a specific type of transaction output.

When you receive Bitcoin, a new txo is created. When you spend Bitcoin, you spend from a txo. Each txo becomes one input in the transaction. So, if you are sending a transaction which spends from a lot of txos, it will have a lot of inputs. Inputs have a size in bytes. Thus having a lot of inputs from spending from a lot of txos will make your transaction have a lot of bytes.
5129  Other / Meta / Re: What priviledges await me as a soon to be jr. Member. on: October 27, 2016, 03:38:05 PM
Firstly, you won't be a "big shot". Next, read the stickies in Meta, especially this one: https://bitcointalk.org/index.php?topic=178608.0
5130  Bitcoin / Bitcoin Technical Support / Re: No confirmation for almost 2 days? on: October 27, 2016, 12:48:20 PM
The fee is too low, only 10 satoshis/byte. According to http://bitcoinfees.21.co/ the current recommended fee for fastest confirmations is 100 satoshis/byte.
5131  Bitcoin / Bitcoin Technical Support / Re: What can I do to fix the tx is unspendable error? on: October 27, 2016, 12:28:51 PM
What wallet? Screenshot please?
5132  Bitcoin / Electrum / Re: Transaction not confirming for more than 12 hours now.... on: October 27, 2016, 12:28:34 PM
Strange things continuing to happen. My electrum transaction of 0.0034 btc has already 17 confirmations now although the fee were lower and priority medium while my Ledger HW.1 wallet which had high priority and better fee although not the recommended is still unconfirmed now. What can be the problem except lower fees ?
Miners can choose whatever transactions they want to include in a block, and apparently most pools have not been choosing the optimal transactions to include to maximize their fees. So you just got lucky.
5133  Bitcoin / Development & Technical Discussion / Re: Cant Bitcoins block time be made configurable ? on: October 27, 2016, 01:49:15 AM
No. It would require a hard fork and a dynamic block time will cause issues with the difficulty retarget.
5134  Economy / Service Discussion / Re: bitcoin never arrived... please help! on: October 26, 2016, 10:23:23 PM
Contact their support users here cannot help you.
5135  Other / Meta / Re: Now people with a lower rank that Full Member can have an avatar ? on: October 26, 2016, 08:13:38 PM
I've just saw some guy that has a rank lower than Full Member. That's not the first time, but it's happening more and more. Has this funtion been enabled for everyone ?
No. Users who had avatars before the avatar restriction went into affect were allowed to keep their avatars. Thus there are still a number of Newbies, Jr. Members, and Members who still have avatars because they set them before the avatar restriction.
5136  Bitcoin / Electrum / Re: Electrum stuck at Unconfirmed for a day now on: October 26, 2016, 06:41:02 PM
Hey guys, I tried to send money from Electrum and it's normally pretty quick but right now it's at unconfirmed with zero confirmations.  It's over 100 bucks so I'm a bit worried.  What should I do?

Here's the Blockchain page https://blockchain.info/tx/fa0ed169a670495cf1a24afa8578fbb247b993dc51922d3f33c7883dc0eba60b

Don't worry, your bitcoins won't be lost and the transaction will confirm eventually.
If you don't want this to happen again, use the dynamic fee feature in electrum (enable it from Wallet > Preferences > Use dynamic fee) and move the slider to the right to set a higher fee.

WHEW that's a relief, thanks guys!!  So is there anything I can do for it right now, or am I at its mercy for now?  Could I just add the adequate fee to speed up the process?
There is a hack-ish way to get the transaction removed from your wallet by switching Electrum servers. After you get the transaction removed from the wallet, you can resend it with a higher fee.
5137  Bitcoin / Electrum / Re: Transaction not confirming for more than 12 hours now.... on: October 26, 2016, 06:37:58 PM
Should be some problem with the network as I send a transaction of only 0.0009 and paid the fee 0.0001 as per 0.0005 btc per kb. Transaction is only 192 bytes so I think I did everything right this time and it's still unconfirmed after 1 hour almost.

I don't use coinbase as that's the most stupid choice anyone can make, why should I choose a third party to hold coins for me, I am using Ledger HW.1 hardware wallet and electrum desktop wallet.
IIRC You should be able to get rid of the transaction by changing the server you connect to a few times and restart Electrum each time. It should disappear from your wallet and then you can send the Bitcoin again.
5138  Bitcoin / Development & Technical Discussion / Re: RAM drive or SSD to hold blockchain. on: October 26, 2016, 02:00:38 PM
Well a RAM drive would make shutting down the computer a major pain since the entire blockchain would have to be dumped to the disk, unless you want to resync the whole thing every time you start the computers.

An SSD is usually enough. I think one of the bigger bottlenecks is in the CPU.
5139  Bitcoin / Bitcoin Technical Support / Re: My transaction this morning until its pending.. on: October 26, 2016, 01:14:59 PM
The fee is a little low. You are paying 50 satoshis/byte. According to http://bitcoinfees.21.co/, the current recommended fee is ~100 satoshis/byte.

I saw Block: 435904 What does it mean?
This means that the transaction cannot be confirmed until block 435904 has been mined. This is irrelevant now as the current block height is 435989
5140  Other / Meta / Re: Why is "viewing all members" disabled? on: October 26, 2016, 01:10:55 PM
Like I said, you can do basically the same thing by searching "e". Is it just to restrict users from accessing it every time they click on the page and not when they actually want to do it?
AFAICT, yes. Because getting all the users is very resource intensive, doing it every time someone went to the "Members" page would put a lot of load on the server. However doing it only when someone actually searches for every user will reduce the load on the server because the number of people making those requests is much smaller than the number of people who are actually searching for all users.
Pages: « 1 ... 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 [257] 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 ... 590 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!