This thread serves both as an auction and interest check regarding my signature, personal text & avatar space. I usually make a total above 50 posts/month and under 70 posts/month.

Before talking about auction specifics, some things to consider:

I may reject bids at my discretion.
Adverts shouldn't go against any forum rules.
If you win the auction and whatever you want advertised turns out to be a scam, or is most likely a scam, signature/personal text/avatar will be removed and there will be no refunds.
Auction winner should pay and provide signature code/personal message/avatar up until 48 hours after winning.
If the auction winner doesn't pay within the timeframe, the next best bid becomes the winner.
I accept known escrows, obviously. We can use one of the big 3. You pay the fees, if any.


Keep in mind that your bid price includes the 3 spaces (signature, personal text and avatar). I accept bids either via post or PM. Bids are for 1 month of advertisement, but you can specify how many months you want to have your advert up at that price per month, up to 3 months. I may consider deals for a longer time.

Bidding starts at 0.04 BTC and should go up in 0.002 BTC increments.

Examples:

0.04

Bid for 1 month at 0.04 BTC

0.042 (2 months)

Bid for 2 months, each month at 0.042 BTC (upfront payment of 0.084 BTC)

Auction ends September 20th at 11pm (23:00) forum time. Bidding on the last 15 minutes of the auction will add another 15 minutes.

Bitcoin Core version *0.15.0* is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.15.0/>

and

  <https://bitcoincore.org/bin/bitcoin-core-0.15.0/>

Or through bittorrent:

    magnet:?xt=urn:btih:e17a5823dd84fe5100386c69e91bc0671e4b4ed2&dn=bitcoin-core-0.15.0&tr=udp%3A%2F%2Ftracker.skyts.net%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.safe.moe%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.piratepublic.com%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.pirateparty.gr%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969%2Fannounce

This is a new major version release, including new features, 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/>

How to Upgrade
==============

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

The first time you run version 0.15.0, your chainstate database will be converted to a
new format, which will take anywhere from a few minutes to half an hour,
depending on the speed of your machine.

The file format of `fee_estimates.dat` changed in version 0.15.0. Hence, a
downgrade from version 0.15.0 or upgrade to version 0.15.0 will cause all fee
estimates to be discarded.

Note that the block database format also changed in version 0.8.0 and there is no
automatic upgrade code from before version 0.8 to version 0.15.0. Upgrading
directly from 0.7.x and earlier without redownloading the blockchain is not supported.
However, as usual, old wallet versions are still supported.

Downgrading warning
- -------------------

The chainstate database for this release is not compatible with previous
releases, so if you run 0.15 and then decide to switch back to any
older version, you will need to run the old release with the `-reindex-chainstate`
option to rebuild the chainstate data structures in the old format.

If your node has pruning enabled, this will entail re-downloading and
processing the entire blockchain.

Compatibility
==============

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not supported.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

Notes for 0.15.0
================

Current SegWit support
- ----------------------

Version 0.15.0 supports adding a segregated witness address via the `addwitnessaddress` RPC, but
please note that this is a testing/expert RPC, which does not guarantee recovery from backup. Only use
this RPC if you know what you are doing. More complete wallet support for segregated witness is coming
in a next version.

Rescanning with encrypted wallets
- ---------------------------------

As in previous versions, when using an encrypted HD wallet, the keypool cannot be topped up without unlocking
the wallet. This means that currently, in order to recover from a backup of an encrypted HD wallet, the user
must unlock the wallet with a really long timeout and manually trigger a rescan, otherwise they risk missing
some keys when auto-topup cannot run. Unfortunately there is no `rescan` RPC in this version, that will be
included in a future version, so for now a rescan can be triggered using one of the `import*` commands, using
a dummy address generated by another (trusted) wallet.

Notable changes
===============

Performance Improvements
- ------------------------

Version 0.15 contains a number of significant performance improvements, which make
Initial Block Download, startup, transaction and block validation much faster:

- - The chainstate database (which is used for tracking UTXOs) has been changed
  from a per-transaction model to a per-output model (See [PR 10195](https://github.com/bitcoin/bitcoin/pull/10195)). Advantages of this model
  are that it:
    - avoids the CPU overhead of deserializing and serializing the unused outputs;
    - has more predictable memory usage;
    - uses simpler code;
    - is adaptable to various future cache flushing strategies.

  As a result, validating the blockchain during Initial Block Download (IBD) and reindex
  is ~30-40% faster, uses 10-20% less memory, and flushes to disk far less frequently.
  The only downside is that the on-disk database is 15% larger. During the conversion from the previous format
  a few extra gigabytes may be used.
- - Earlier versions experienced a spike in memory usage while flushing UTXO updates to disk.
  As a result, only half of the available memory was actually used as cache, and the other half was
  reserved to accommodate flushing. This is no longer the case (See [PR 10148](https://github.com/bitcoin/bitcoin/pull/10148)), and the entirety of
  the available cache (see `-dbcache`) is now actually used as cache. This reduces the flushing
  frequency by a factor 2 or more.
- - In previous versions, signature validation for transactions has been cached when the
  transaction is accepted to the mempool. Version 0.15 extends this to cache the entire script
  validity (See [PR 10192](https://github.com/bitcoin/bitcoin/pull/10192)). This means that if a transaction in a block has already been accepted to the
  mempool, the scriptSig does not need to be re-evaluated. Empirical tests show that
  this results in new block validation being 40-50% faster.
- - LevelDB has been upgraded to version 1.20 (See [PR 10544](https://github.com/bitcoin/bitcoin/pull/10544)). This version contains hardware acceleration for CRC
  on architectures supporting SSE 4.2. As a result, synchronization and block validation are now faster.
- - SHA256 hashing has been optimized for architectures supporting SSE 4 (See [PR 10821](https://github.com/bitcoin/bitcoin/pull/10821)). SHA256 is around
  50% faster on supported hardware, which results in around 5% faster IBD and block
  validation. In version 0.15, SHA256 hardware optimization is disabled in release builds by
  default, but can be enabled by using `--enable-experimental-asm` when building.
- - Refill of the keypool no longer flushes the wallet between each key which resulted in a ~20x speedup in creating a new wallet. Part of this speedup was used to increase the default keypool to 1000 keys to make recovery more robust. (See [PR 10831](https://github.com/bitcoin/bitcoin/pull/10831)).

Fee Estimation Improvements
- ---------------------------

Fee estimation has been significantly improved in version 0.15, with more accurate fee estimates used by the wallet and a wider range of options for advanced users of the `estimatesmartfee` and `estimaterawfee` RPCs (See [PR 10199](https://github.com/bitcoin/bitcoin/pull/10199)).

### Changes to internal logic and wallet behavior

- - Internally, estimates are now tracked on 3 different time horizons. This allows for longer targets and means estimates adjust more quickly to changes in conditions.
- - Estimates can now be *conservative* or *economical*. *Conservative* estimates use longer time horizons to produce an estimate which is less susceptible to rapid changes in fee conditions. *Economical* estimates use shorter time horizons and will be more affected by short-term changes in fee conditions. Economical estimates may be considerably lower during periods of low transaction activity (for example over weekends), but may result in transactions being unconfirmed if prevailing fees increase rapidly.
- - By default, the wallet will use conservative fee estimates to increase the reliability of transactions being confirmed within the desired target. For transactions that are marked as replaceable, the wallet will use an economical estimate by default, since the fee can be 'bumped' if the fee conditions change rapidly (See [PR 10589](https://github.com/bitcoin/bitcoin/pull/10589)).
- - Estimates can now be made for confirmation targets up to 1008 blocks (one week).
- - More data on historical fee rates is stored, leading to more precise fee estimates.
- - Transactions which leave the mempool due to eviction or other non-confirmed reasons are now taken into account by the fee estimation logic, leading to more accurate fee estimates.
- - The fee estimation logic will make sure enough data has been gathered to return a meaningful estimate. If there is insufficient data, a fallback default fee is used.

### Changes to fee estimate RPCs

- - The `estimatefee` RPC is now deprecated in favor of using only `estimatesmartfee` (which is the implementation used by the GUI)
- - The `estimatesmartfee` RPC interface has been changed (See [PR 10707](https://github.com/bitcoin/bitcoin/pull/10707)):
    - The `nblocks` argument has been renamed to `conf_target` (to be consistent with other RPC methods).
    - An `estimate_mode` argument has been added. This argument takes one of the following strings: `CONSERVATIVE`, `ECONOMICAL` or `UNSET` (which defaults to `CONSERVATIVE`).
    - The RPC return object now contains an `errors` member, which returns errors encountered during processing.
    - If Bitcoin Core has not been running for long enough and has not seen enough blocks or transactions to produce an accurate fee estimation, an error will be returned (previously a value of -1 was used to indicate an error, which could be confused for a feerate).
- - A new `estimaterawfee` RPC is added to provide raw fee data. External clients can query and use this data in their own fee estimation logic.

Multi-wallet support
- --------------------

Bitcoin Core now supports loading multiple, separate wallets (See [PR 8694](https://github.com/bitcoin/bitcoin/pull/8694), [PR 10849](https://github.com/bitcoin/bitcoin/pull/10849)). The wallets are completely separated, with individual balances, keys and received transactions.

Multi-wallet is enabled by using more than one `-wallet` argument when starting Bitcoin, either on the command line or in the Bitcoin config file.

**In Bitcoin-Qt, only the first wallet will be displayed and accessible for creating and signing transactions.** GUI selectable multiple wallets will be supported in a future version. However, even in 0.15 other loaded wallets will remain synchronized to the node's current tip in the background. This can be useful if running a pruned node, since loading a wallet where the most recent sync is beyond the pruned height results in having to download and revalidate the whole blockchain. Continuing to synchronize all wallets in the background avoids this problem.

Bitcoin Core 0.15.0 contains the following changes to the RPC interface and `bitcoin-cli` for multi-wallet:

* When running Bitcoin Core with a single wallet, there are **no** changes to the RPC interface or `bitcoin-cli`. All RPC calls and `bitcoin-cli` commands continue to work as before.
* When running Bitcoin Core with multi-wallet, all *node-level* RPC methods continue to work as before. HTTP RPC requests should be send to the normal `<RPC IP address>:<RPC port>/` endpoint, and `bitcoin-cli` commands should be run as before. A *node-level* RPC method is any method which does not require access to the wallet.
* When running Bitcoin Core with multi-wallet, *wallet-level* RPC methods must specify the wallet for which they're intended in every request. HTTP RPC requests should be send to the `<RPC IP address>:<RPC port>/wallet/<wallet name>/` endpoint, for example `127.0.0.1:8332/wallet/wallet1.dat/`. `bitcoin-cli` commands should be run with a `-rpcwallet` option, for example `bitcoin-cli -rpcwallet=wallet1.dat getbalance`.
* A new *node-level* `listwallets` RPC method is added to display which wallets are currently loaded. The names returned by this method are the same as those used in the HTTP endpoint and for the `rpcwallet` argument.

Note that while multi-wallet is now fully supported, the RPC multi-wallet interface should be considered unstable for version 0.15.0, and there may backwards-incompatible changes in future versions.

Replace-by-fee control in the GUI
- ---------------------------------

Bitcoin Core has supported creating opt-in replace-by-fee (RBF) transactions
since version 0.12.0, and since version 0.14.0 has included a `bumpfee` RPC method to
replace unconfirmed opt-in RBF transactions with a new transaction that pays
a higher fee.

In version 0.15, creating an opt-in RBF transaction and replacing the unconfirmed
transaction with a higher-fee transaction are both supported in the GUI (See [PR 9592](https://github.com/bitcoin/bitcoin/pull/9592)).

Removal of Coin Age Priority
- ----------------------------

In previous versions of Bitcoin Core, a portion of each block could be reserved for transactions based on the age and value of UTXOs they spent. This concept (Coin Age Priority) is a policy choice by miners, and there are no consensus rules around the inclusion of Coin Age Priority transactions in blocks. In practice, only a few miners continue to use Coin Age Priority for transaction selection in blocks. Bitcoin Core 0.15 removes all remaining support for Coin Age Priority (See [PR 9602](https://github.com/bitcoin/bitcoin/pull/9602)). This has the following implications:

- - The concept of *free transactions* has been removed. High Coin Age Priority transactions would previously be allowed to be relayed even if they didn't attach a miner fee. This is no longer possible since there is no concept of Coin Age Priority. The `-limitfreerelay` and `-relaypriority` options which controlled relay of free transactions have therefore been removed.
- - The `-sendfreetransactions` option has been removed, since almost all miners do not include transactions which do not attach a transaction fee.
- - The `-blockprioritysize` option has been removed.
- - The `estimatepriority` and `estimatesmartpriority` RPCs have been removed.
- - The `getmempoolancestors`, `getmempooldescendants`, `getmempoolentry` and `getrawmempool` RPCs no longer return `startingpriority` and `currentpriority`.
- - The `prioritisetransaction` RPC no longer takes a `priority_delta` argument, which is replaced by a `dummy` argument for backwards compatibility with clients using positional arguments. The RPC is still used to change the apparent fee-rate of the transaction by using the `fee_delta` argument.
- - `-minrelaytxfee` can now be set to 0. If `minrelaytxfee` is set, then fees smaller than `minrelaytxfee` (per kB) are rejected from relaying, mining and transaction creation. This defaults to 1000 satoshi/kB.
- - The `-printpriority` option has been updated to only output the fee rate and hash of transactions included in a block by the mining code.

Mempool Persistence Across Restarts
- -----------------------------------

Version 0.14 introduced mempool persistence across restarts (the mempool is saved to a `mempool.dat` file in the data directory prior to shutdown and restores the mempool when the node is restarted). Version 0.15 allows this feature to be switched on or off using the `-persistmempool` command-line option (See [PR 9966](https://github.com/bitcoin/bitcoin/pull/9966)). By default, the option is set to true, and the mempool is saved on shutdown and reloaded on startup. If set to false, the `mempool.dat` file will not be loaded on startup or saved on shutdown.

New RPC methods
- ---------------

Version 0.15 introduces several new RPC methods:

- - `abortrescan` stops current wallet rescan, e.g. when triggered by an `importprivkey` call (See [PR 10208](https://github.com/bitcoin/bitcoin/pull/10208)).
- - `combinerawtransaction` accepts a JSON array of raw transactions and combines them into a single raw transaction (See [PR 10571](https://github.com/bitcoin/bitcoin/pull/10571)).
- - `estimaterawfee` returns raw fee data so that customized logic can be implemented to analyze the data and calculate estimates. See [Fee Estimation Improvements](#fee-estimation-improvements) for full details on changes to the fee estimation logic and interface.
- - `getchaintxstats` returns statistics about the total number and rate of transactions
  in the chain (See [PR 9733](https://github.com/bitcoin/bitcoin/pull/9733)).
- - `listwallets` lists wallets which are currently loaded. See the *Multi-wallet* section
  of these release notes for full details (See [Multi-wallet support](#multi-wallet-support)).
- - `uptime` returns the total runtime of the `bitcoind` server since its last start (See [PR 10400](https://github.com/bitcoin/bitcoin/pull/10400)).

Low-level RPC changes
- ---------------------

- - When using Bitcoin Core in multi-wallet mode, RPC requests for wallet methods must specify
  the wallet that they're intended for. See [Multi-wallet support](#multi-wallet-support) for full details.

- - The new database model no longer stores information about transaction
  versions of unspent outputs (See [Performance improvements](#performance-improvements)). This means that:
  - The `gettxout` RPC no longer has a `version` field in the response.
  - The `gettxoutsetinfo` RPC reports `hash_serialized_2` instead of `hash_serialized`,
    which does not commit to the transaction versions of unspent outputs, but does
    commit to the height and coinbase information.
  - The `getutxos` REST path no longer reports the `txvers` field in JSON format,
    and always reports 0 for transaction versions in the binary format

- - The `estimatefee` RPC is deprecated. Clients should switch to using the `estimatesmartfee` RPC, which returns better fee estimates. See [Fee Estimation Improvements](#fee-estimation-improvements) for full details on changes to the fee estimation logic and interface.

- - The `gettxoutsetinfo` response now contains `disk_size` and `bogosize` instead of
  `bytes_serialized`. The first is a more accurate estimate of actual disk usage, but
  is not deterministic. The second is unrelated to disk usage, but is a
  database-independent metric of UTXO set size: it counts every UTXO entry as 50 + the
  length of its scriptPubKey (See [PR 10426](https://github.com/bitcoin/bitcoin/pull/10426)).

- - `signrawtransaction` can no longer be used to combine multiple transactions into a single transaction. Instead, use the new `combinerawtransaction` RPC (See [PR 10571](https://github.com/bitcoin/bitcoin/pull/10571)).

- - `fundrawtransaction` no longer accepts a `reserveChangeKey` option. This option used to allow RPC users to fund a raw transaction using an key from the keypool for the change address without removing it from the available keys in the keypool. The key could then be re-used for a `getnewaddress` call, which could potentially result in confusing or dangerous behaviour (See [PR 10784](https://github.com/bitcoin/bitcoin/pull/10784)).

- - `estimatepriority` and `estimatesmartpriority` have been removed. See [Removal of Coin Age Priority](#removal-of-coin-age-priority).

- - The `listunspent` RPC now takes a `query_options` argument (see [PR 8952](https://github.com/bitcoin/bitcoin/pull/8952)), which is a JSON object
  containing one or more of the following members:
  - `minimumAmount` - a number specifying the minimum value of each UTXO
  - `maximumAmount` - a number specifying the maximum value of each UTXO
  - `maximumCount` - a number specifying the minimum number of UTXOs
  - `minimumSumAmount` - a number specifying the minimum sum value of all UTXOs

- - The `getmempoolancestors`, `getmempooldescendants`, `getmempoolentry` and `getrawmempool` RPCs no longer return `startingpriority` and `currentpriority`. See [Removal of Coin Age Priority](#removal-of-coin-age-priority).

- - The `dumpwallet` RPC now returns the full absolute path to the dumped wallet. It
  used to return no value, even if successful (See [PR 9740](https://github.com/bitcoin/bitcoin/pull/9740)).

- - In the `getpeerinfo` RPC, the return object for each peer now returns an `addrbind` member, which contains the ip address and port of the connection to the peer. This is in addition to the `addrlocal` member which contains the ip address and port of the local node as reported by the peer (See [PR 10478](https://github.com/bitcoin/bitcoin/pull/10478)).

- - The `disconnectnode` RPC can now disconnect a node specified by node ID (as well as by IP address/port). To disconnect a node based on node ID, call the RPC with the new `nodeid` argument (See [PR 10143](https://github.com/bitcoin/bitcoin/pull/10143)).

- - The second argument in `prioritisetransaction` has been renamed from `priority_delta` to `dummy` since Bitcoin Core no longer has a concept of coin age priority. The `dummy` argument has no functional effect, but is retained for positional argument compatibility. See [Removal of Coin Age Priority](#removal-of-coin-age-priority).

- - The `resendwallettransactions` RPC throws an error if the `-walletbroadcast` option is set to false (See [PR 10995](https://github.com/bitcoin/bitcoin/pull/10995)).

- - The second argument in the `submitblock` RPC argument has been renamed from `parameters` to `dummy`. This argument never had any effect, and the renaming is simply to communicate this fact to the user (See [PR 10191](https://github.com/bitcoin/bitcoin/pull/10191))
  (Clients should, however, use positional arguments for `submitblock` in order to be compatible with BIP 22.)

- - The `verbose` argument of `getblock` has been renamed to `verbosity` and now takes an integer from 0 to 2. Verbose level 0 is equivalent to `verbose=false`. Verbose level 1 is equivalent to `verbose=true`. Verbose level 2 will give the full transaction details of each transaction in the output as given by `getrawtransaction`. The old behavior of using the `verbose` named argument and a boolean value is still maintained for compatibility.

- - Error codes have been updated to be more accurate for the following error cases (See [PR 9853](https://github.com/bitcoin/bitcoin/pull/9853)):
  - `getblock` now returns RPC_MISC_ERROR if the block can't be found on disk (for
  example if the block has been pruned). Previously returned RPC_INTERNAL_ERROR.
  - `pruneblockchain` now returns RPC_MISC_ERROR if the blocks cannot be pruned
  because the node is not in pruned mode. Previously returned RPC_METHOD_NOT_FOUND.
  - `pruneblockchain` now returns RPC_INVALID_PARAMETER if the blocks cannot be pruned
  because the supplied timestamp is too late. Previously returned RPC_INTERNAL_ERROR.
  - `pruneblockchain` now returns RPC_MISC_ERROR if the blocks cannot be pruned
  because the blockchain is too short. Previously returned RPC_INTERNAL_ERROR.
  - `setban` now returns RPC_CLIENT_INVALID_IP_OR_SUBNET if the supplied IP address
  or subnet is invalid. Previously returned RPC_CLIENT_NODE_ALREADY_ADDED.
  - `setban` now returns RPC_CLIENT_INVALID_IP_OR_SUBNET if the user tries to unban
  a node that has not previously been banned. Previously returned RPC_MISC_ERROR.
  - `removeprunedfunds` now returns RPC_WALLET_ERROR if `bitcoind` is unable to remove
  the transaction. Previously returned RPC_INTERNAL_ERROR.
  - `removeprunedfunds` now returns RPC_INVALID_PARAMETER if the transaction does not
  exist in the wallet. Previously returned RPC_INTERNAL_ERROR.
  - `fundrawtransaction` now returns RPC_INVALID_ADDRESS_OR_KEY if an invalid change
  address is provided. Previously returned RPC_INVALID_PARAMETER.
  - `fundrawtransaction` now returns RPC_WALLET_ERROR if `bitcoind` is unable to create
  the transaction. The error message provides further details. Previously returned
  RPC_INTERNAL_ERROR.
  - `bumpfee` now returns RPC_INVALID_PARAMETER if the provided transaction has
  descendants in the wallet. Previously returned RPC_MISC_ERROR.
  - `bumpfee` now returns RPC_INVALID_PARAMETER if the provided transaction has
  descendants in the mempool. Previously returned RPC_MISC_ERROR.
  - `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has
  has been mined or conflicts with a mined transaction. Previously returned
  RPC_INVALID_ADDRESS_OR_KEY.
  - `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction is not
  BIP 125 replaceable. Previously returned RPC_INVALID_ADDRESS_OR_KEY.
  - `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has already
  been bumped by a different transaction. Previously returned RPC_INVALID_REQUEST.
  - `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction contains
  inputs which don't belong to this wallet. Previously returned RPC_INVALID_ADDRESS_OR_KEY.
  - `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has multiple change
  outputs. Previously returned RPC_MISC_ERROR.
  - `bumpfee` now returns RPC_WALLET_ERROR if the provided transaction has no change
  output. Previously returned RPC_MISC_ERROR.
  - `bumpfee` now returns RPC_WALLET_ERROR if the fee is too high. Previously returned
  RPC_MISC_ERROR.
  - `bumpfee` now returns RPC_WALLET_ERROR if the fee is too low. Previously returned
  RPC_MISC_ERROR.
  - `bumpfee` now returns RPC_WALLET_ERROR if the change output is too small to bump the
  fee. Previously returned RPC_MISC_ERROR.

Detailed changelog and thank you's here

Selling my Gunbot Poloniex License for 0.08 BTC, OBO. You can post or PM your offers.

We can deal through escrow or directly, whatever you prefer. If you choose escrow, I'm fine with one of the big 3. Buyer pays the fees, if any.

As soon as the deal is completed I'll be PM'ing Gunthar to transfer the license to you ASAP.

SegWit2x is starting to be discussed on the mailing list and a BIP containing it is being proposed... Sure gives for an interesting read.

I think it's very important for people behind Core and other Bitcoin devs or people who are simply knowledgeable in what regards Bitcoin client coding discuss every proposal... What do you all think?

Friendly reminder to withdraw your funds from exchanges. BTC-e might have their account database compromised. However, nothing indicates that their wallets have been compromised.

See here and here

I am currently available for translation jobs. I can do English to Portuguese (PT-PT) translations and Portuguese to English too. If needed, I can also proofread texts in both languages. I might also be interested in audio transcription jobs and article writing.

Over the past few years I've been involved with Bitcoin I've already translated announcement threads in the forums, some news articles and websites related to cryptocurrencies and/or exchanges.

Please send me a PM if interested. Rates can then be discussed.

The news section states the following:

News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.

What is this next phase? Is everything ready for migration?

Suddenly my watchlist is 51 pages long (usually 1/2 pages) and it lists threads which had the last reply in 2014, and others I've obviously already read all replies to... What happened to the watchlist? Is anyone else experiencing the same?

Not that it bothers me, just curious about what's happening.

[what is the correct size for a mempool given the computer's total RAM?]

After setting up a few nodes, on different hosts/connections and on virtual and physical machines, there's a question about setting them up that I still haven't solved: what is the correct size for a mempool given the computer's total RAM?

I've tried searching for this and I didn't find any answers or benchmarks for this, neither have I found any kind of user feedback. I've setup nodes on machines from 1 to 6GB of RAM, most of them running only basic OS services and bitcoind, and on all machines bitcoind eventually crashes without any evident reason depicted on the debug file. The client just shuts down and the logs just stop where they were... When I turn it back on sometimes it asks for a reindex, and sometimes it doesn't. I've posted a debug.log of mine on the forums a few months back and the answers I got referred the mempool, but without certainty or any real data.

I'm running some tests on a 1GB machine I currently have serving as a node and I'll report back. meanwhile, it would be nice to make a table, with user input/feedback, regarding what kind of mempool size should bitcoind be launched with.

http://www.engadget.com/2016/03/13/microsoft-store-stops-taking-bitcoin/

Microsoft's grand experiment in accepting Bitcoins as payment hasn't panned out, it seems. The company has quietly updated an FAQ to reveal that it no longer accepts the digital currency in the Microsoft Store on Windows 10 devices.

Quite unfortunate I wonder why they left Bitcoin...

Looks like we have been accepted for the next revision of Unicode! Unfortunately there doesn't seem to be news or a thread about this... Only a twitter announcement, but I bet this will be discussed a lot in the next few hours

What do you all think? I think this is great news!

I've set up a node recently (and have been improving it gradually, from time to time). But in the last few weeks, the node has been crashing on a 1 week interval, more or less...

I've been seeing debug logs for the last two or three crashes and I haven't been seeing anything unusual. I'm running the node on a VM with 4GB RAM + 4GB vSWAP. I've tried raising/changing swap size, but it seems it's impossible with the host I'm using. I thought this would be enough to run a node, but apparently it is not, or the problem isn't RAM/SWAP, or I'm missing something.

I've been seeing a temporary cover up solution to this, but I've been unsuccessful thus far trying to find something that monitors if the node is running or not and restarts it with the correct parameters...

Here's a bit of the last crash debug:

Code:

2015-09-10 15:04:01 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-09-10 15:04:47 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-09-10 15:04:53 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-09-10 15:04:57 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=*****************, peerid=13394
2015-09-10 15:04:58 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-09-10 15:05:07 UpdateTip: new best=000000000000000004467163bbb85f7a043f7ec3ea641c429efb6668c569574d  height=373885  log2_work=83.327898  tx=83074047  date=2015-09-10 15:03:44 progress=0.999999  cache=0.5MiB(0tx)
2015-09-10 15:05:12 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-09-10 15:05:15 receive version message: /getaddr.bitnodes.io:0.1/: version 70002, blocks=373884, us=*************, peerid=13395
2015-09-10 15:05:42 receive version message: /Snoopy:0.1/: version 60001, blocks=0, us=*************, peerid=13396
2015-09-10 15:06:02 ping timeout: 1200.013952s
2015-09-10 15:07:01 socket send error Connection timed out (110)
2015-09-10 15:07:18 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=***************, peerid=13397
2015-09-10 15:07:29 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=***************, peerid=13398
2015-09-10 15:07:33 receive version message: /Satoshi:0.9.3/: version 70002, blocks=373885, us=*******************, peerid=13399

Any clues? Anything bad on the Debug.log? I can provide more of the file if needed.

Here's the user: https://bitcointalk.org/index.php?action=trust;u=341745

Reporting all I can. Also gave him negative trust.

The New York State Department of Financial Services (NYDFS) has revealed that it has so far received 22 applications from firms seeking to engage in virtual currency business activity in the US state.

Honestly wasn't expecting so many companies seeking BitLicense applications...

Full news here

Another spammer from the usual sites

I'll report what I can...

I'm switching the machine controlling my Offline wallets, and this time I'm setting up Armory on Windows. I'll start off by saying that I've never setup Armory on Windows, so something really trivial might be escaping me.

I've installed everything without any issue, added a wallet, pointed Armory to my Bitcoin Core install and to my blockchain files as usual... But it simply doesn't get out of offline mode. I've tried using Armory 0.93.2 and Bitcoin Core 0.10 and Bitcoin Core 0.10.2.

I'll copy what I think are the relevant lines on the logfile

Code:

2015-07-28 19:40 (INFO) -- ArmoryQt.py:2508 - Setting satoshi datadir = D:\Bitcoin
2015-07-28 19:40 (INFO) -- SDM.pyc:282 - Total size of files in D:\Bitcoin\blocks is 38.5 GB
2015-07-28 19:40 (INFO) -- SDM.pyc:321 - Found bitcoind in the following places:
2015-07-28 19:40 (INFO) -- SDM.pyc:323 -    C:\Program Files\Bitcoin\daemon\bitcoind.exe
2015-07-28 19:40 (INFO) -- SDM.pyc:325 - Using: C:\Program Files\Bitcoin\daemon\bitcoind.exe
2015-07-28 19:40 (INFO) -- SDM.pyc:496 - Reading bitcoin.conf file
2015-07-28 19:40 (INFO) -- SDM.pyc:515 - Setting permissions on bitcoin.conf
2015-07-28 19:40 (INFO) -- SDM.pyc:524 - Setting permissions on bitcoin.conf
2015-07-28 19:40 (INFO) -- ArmoryUtils.pyc:600 - Executing popen: [u'icacls', u'D:\\Bitcoin\\bitcoin.conf', u'/inheritance:r', u'/grant:r', u'*******:F']
2015-07-28 19:40 (ERROR) -- ArmoryQt.py:2476 - Failed to setup SDM
Traceback (most recent call last):
  File "ArmoryQt.py", line 2471, in startBitcoindIfNecessary
  File "SDM.pyc", line 359, in setupSDM
  File "SDM.pyc", line 529, in readBitcoinConf
  File "armoryengine\ArmoryUtils.pyc", line 668, in subprocess_check_output
CalledProcessError: Command '[u'icacls', u'D:\\Bitcoin\\bitcoin.conf', u'/inheritance:r', u'/grant:r', u'*******:F']' returned non-zero exit status 5

Is it anything on Armory or this simply happens because Armory and Windows 10 still don't get along? I'm also posting this as a heads up for folks migrating tomorrow... There might be issues.

http://cointelegraph.com/news/114874/european-union-bitcoin-is-exempt-from-vat

The most popular Swedish news site, Dn.se, has reported the European Court of Justice as stating, “Bitcoin is a means of payment and that the exchange should therefore be exempted VAT obligations.”

Three years ago, Swedish software developer David Hedqvist and moderator of Bitcoin.se asked the European Union if Bitcoin transactions are exempt from VAT. According to the findings of the court:

“Bitcoins also constitute a currency. Their ownership has no other point other than the ability to use them again as currency at some future point. Therefore they are to be treated just like legal currencies as far as VAT is concerned.”

However, the Swedish Tax Agency argued against the Board of EU directives, and said that they have mistakenly interpreted the matter. The Agency appealed to the Supreme Administrative Court and urged it to proceed with a preliminary ruling, the final determination in law by EU courts that can be initiated by any EU member state.

A legal expert at the Swedish Tax Agency announced, "We disagreed with the Board's reasoning. Then we thought it was also important to get a clear understanding about Bitcoin and VAT.”

Due to the Swedish Tax Agency’s actions, Hedqvist took the matter into his own hands and declared arguments against them. For this, Hedqvist is working with Stockholm’s most prestigious corporate law firms and all of his costs are covered by companies in Bitcoinbranschen, because the companies believe that the tax exemption decision would greatly benefit them.

Hedqvist explained:

“It is important for them because it applies to their commission as shifting business to be subject to VAT. It is also important for bitcoin from a broader perspective, if there is to be equated with other currencies. It is also important that the new technology is not stopped by laws and regulations that are lagging behind.”

EU

Several European Countries already Exempt from VAT

The General Directorate of Taxes (DGT) announced in April that Bitcoin is exempt from value-added tax (VAT) in Spain, United Kingdom and Germany. The DGT stated that Bitcoin is considered as a medium of payment or a financial instrument, and thus is classified as a financial service rather than a simple good or commodity.

Paragraph (h) of article 20.18 of the VAT Act states, “Transactions regarding transfers, money orders, check, promissory notes, bills of exchange, debit or credit cards and other payment orders."

If the preliminary ruling becomes final, many European countries will be exempted from VAT, Including Germany, the United Kingdom, France, Finland and Belgium.

Regulators regulating something that they cannot regulate... At least they're not forbidding it

Created a gift card with Bitcoin on eGifter just now for a flash sale, but when I got there the item was already gone... So I have no use for the gift card anymore. It expires on Sun Jul 13 22:59:59 UTC 2025, just at it says on eGifter website.

Selling it for 0.032 BTC, negotiable.

Hurry up if you want it, because it expires quickly!

https://github.com/gavinandresen/bitcoinxt/commit/821e223ccc4c8ab967399371761718f1015c766b

Finally some movement! Can't wait to see this out on Bitcoin XT's production release!!

https://epicenterbitcoin.com/podcast/082/

From 51:02 onwards... Now we're talking! They're finally stepping up and applying the change on Bitcoin XT. And then we vote

Quite a nice interview with some information... Also good for those around the forum that still have questions or doubts about making a change in Bitcoin