Bitcoin Forum
January 20, 2020, 09:24:52 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 »
1  Other / Meta / Enable HSTS Preload in bitcointalk.org domain to avoid MITM attacks on: August 18, 2016, 11:25:28 AM
At present, the bitcointalk.org domain sends this header
Strict-Transport-Security: max-age=3000000

This header is also known as HSTS, it tells the browser to only connect using HTTPS for the next 34 days.

The problem appears when the client is visiting bitcointalk.org for the first time (or in incognito mode, or has deleted cache, etc.) The browser does not know that has to use HTTPS to browse to bitcointalk.org so when the user types the domain in his browser he will be connecting to http://bitcointalk.org instead of https://bitcointalk.org. If the network is being attacked he will be downloading malware instead of Bitcoin software.

How to fix it:
Add the includeSubDomains and preload directive to the header sent.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Then just submit bitcointalk.org domain to the HSTS Preload list in Chrome, Firefox and IE. This can be done easily just by clicking this link:
https://hstspreload.appspot.com/?domain=bitcointalk.org

Once submitted the next releases of the browsers will include bitcoin.org in the HSTS Preload list and no one could load bitcointalk.org via HTTP again.

As an example, bitcoin-related websites already using HSTS preloading include Coinbase, Coinapult, Bitgo, Localbitcoins, bitcoin.de, blockchain.info, GDAX and Multibit.
2  Other / New forum software / Take a look at the development of the new forum software on: October 24, 2015, 06:23:34 PM
Estimated time for release: two weeks™  Undecided






Github repo: https://github.com/epochtalk/epochtalk
Github username: https://github.com/epochtalk/

Website: http://epochtalk.org

Features
  • Epochtalk is a single page web application created with AngularJS
  • Web/Mobile ready responsive design using Foundation
  • JavaScript and CSS is bundled and minimized for performance using Browserify and Uglify-js
  • Designed with performance in mind. Epochtalk's backend, core-pg, utilizes Postgres as a database.


Documentation: http://epochtalk.org/docs.html

API: http://epochtalk.org/api.html

Dependencies: node, npm, bower, PostgreSQL, foreman

License: The MIT License (MIT)

Other info: Javascript required to read the forum, it seems to have a heavy javascript usage.

Images:



























3  Bitcoin / Bitcoin Discussion / (Preview) New blockchain.info wallet currently in Private Alpha on: June 05, 2015, 05:36:09 PM


Screenshot: https://i.imgur.com/VU8IPzb.png

Link: https://alpha.blockchain.info (Do not try to login, you will cant)


------------
Update: I have found references to bitcoin, litecoin, dogecoin, viacoin, gamerscoin, zetacoin in the source code.
4  Other / New forum software / Reference: Discourse and Flarum on: December 22, 2014, 05:38:40 PM
Hi,

I only want to point out that this forum software has to be better than this two new forums that are been developed, you can take some ideas from them too.


FLARUM

Website: http://flarum.org
Github: https://github.com/flarum/core
Language: PHP
Demo: not available














DISCOURSE

Website: http://www.discourse.org/
Github: https://github.com/discourse/discourse
Language: Ruby
Demo: https://meta.discourse.org/










5  Other / New forum software / Public Github Repo of the New forum software development on: August 21, 2014, 07:23:10 AM
Hey,
This is the Github repo that Slickage is using to commit al changes to the new forum software.

https://github.com/slickage/epochtalk/


Edit:

This one seems to be more updated:
https://github.com/epochtalk/epochtalk/
6  Bitcoin / Project Development / If you have a Bitcoin website or you are starting one get a FREE SSL (HTTPS) on: July 23, 2014, 10:45:15 PM
In the Bitcoin community we love crypto, that also includes loving https, bitcointalk.org, blockchain.info, bitstamp.net, bitcoin.org, all of them are using HTTPS right now.
Now you can also get a SSL certificate for your website for free (Yes, free as a free beer, forever) going to https://startssl.org

To setup and install it for free I recommend reading this tutorial:



# How To Set Up Apache with a Free Signed SSL Certificate

-> https://www.digitalocean.com/community/tutorials/how-to-set-up-apache-with-a-free-signed-ssl-certificate-on-a-vps

Note: it does not matter your provider, you dont need a server at digitalocean, it works in any Dedicated Server or VPS




Now that you have HTTPS in your website you should redirect http:// to https:// using this code in your .htaccess
Code:
RewriteEngine On
 RewriteCond %{HTTPS} !=on
 RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]



Also if you want enable HSTS to avoid SSLstrip attacks including this code in your .htaccess:
Code:
Header set Strict-Transport-Security "max-age=31536000" env=HTTPS
7  Bitcoin / Development & Technical Discussion / [Idea] Proposal for improving Bitcoin mining decentralization [Avoid 51% attack] on: July 23, 2014, 07:07:18 PM
We all know the recent news, Ghash pool controlling 51% of the hashrate. While some consider it a threat others think that is not harmful.

The thing is that we have to do something to stop this from happening again.

My proposal is to start thinking about miners that join a pool like independent miners and not slave miners, this includes creating a new mining protocol that does not rely on the pool sending the list of transactions to include in a block. Each individual miner has to collect transactions by his own and mine that, this can be achieved by running a full node or by running a SPV like node that ask other nodes for transactions.

Once this protocol is developed and standarised we as a community could require all pools to use it (because its better, because is more trustless...), not by imposing it but by recommending it.

Pool owners could send some instructions using this protocol to the miner about how many transactions to include per block (some pools want small blocks), how many 0 fee transactions to include, how much is the minimum fee per Kb to include transactions and some info about the Coinbase field in the block.

This way is impossible to perform some of the possible 51% attacks:
A pool owner cant mine a new chain (selfish mining) (pool clients have a SPV or full node that has checkpoints and ask other peers about the length of the chain)
A pool owner can't perform double spends or reverse transactions (pool clients know all the transactions relayed to the network, they know if they are already included on a block)
A pool owner cant decide which transactions not to include (but they can configure the minimum fee).
A pool owner cant get all the rewards by avoiding other pools from mining blocks (Because the pool client knows the last block independently that is from his pool or other).

The only thing that a 51% pool owner can do is to shut down his pool and drop the hashrate by 51% because he does not control the miners.

If the pool owner owns all the hardware in the pool my proposal is not valid, if the pool clients dont use this protocol my proposal is not valid.


I want to know if this is possible or its been developed or there is already a working protocol that works like this, also I want to read other people's ways to address this threat, thanks for reading.
8  Bitcoin / Bitcoin Discussion / I remastered a Bitcoin Logo in 4096px to make a T-shirt, download it here on: July 22, 2014, 05:14:00 PM
I wanted a nice design for a T-Shirt, after searching a lot I find that the best image to use was the Coin found in the What is Bitcoin? video but I was unable to obtain the image in full resolution so I remastered it in Photoshop.


View the album here:
https://imgur.com/a/WvxB3







4096x4096 transparent background download:
https://i.imgur.com/lCP7YM1.png

Enjoy.  Grin
9  Bitcoin / Mining / Lets find out who are the pools controlling the unknown hashrate on: July 21, 2014, 07:45:17 AM
Looking at the pools hashrate chart (https://blockchain.info/pools):


Code:
1AcAj9p6zJn4xLXdvmdiuPCtY7YkBPTAJo 6%
1BX5YoLwvqzvVwSrdD4dC32vbouHQn2tuF 4%
Other Unknown 10%
-------------------------------------------
Total unknown hashrate 20%

More than 25 PH remains without been identify, a fifth of the total hashrate.


How we can identify pools?
Looking at the Coinbase or the reward bitcoin address and how the reward is distributed between miners.

Some websites that publish info about pools:
http://organofcorti.blogspot.com.es/
http://bitcoinchain.com/pools
http://blockorigin.pfoe.be/top.php


If you discover a new pool or entity mining you can post it here and commit here https://github.com/blockchain/Blockchain-Known-Pools to update the blockchain.info/pools website.  Wink
10  Other / New forum software / Idea: Bitcoin address field on: June 19, 2014, 08:17:15 PM
The new forum should have a field for a Bitcoin address, this field should check if the address is valid, also for security changing that address should take at least 7 days (avoid fast account hacking), also when the last update date should be shown when displaying the address.

That way you can tip any user without asking for any address.
11  Other / New forum software / Idea: Random user avatars by default on: June 19, 2014, 08:11:33 PM
If the user does not upload any avatar the default one should be a random one (a pattern) generated using his user id as seed so every user gets a unique default avatar (until they upload one).

Also newbies should not be allowed to upload a custom avatar.

12  Bitcoin / Development & Technical Discussion / Proposals for improving Bitcoin mining decentralization on: June 17, 2014, 03:44:37 PM
First of all I apologice due to the possible mistakes in my writing below, I am not a Bitcoin developer but I have some knowledge about it.

----

We all know the recent news, Ghash pool controlling 51% of the hashrate. While some consider it a threat others think that is not harmful.

The thing is that we have to do something to stop this from happening again:

My proposal is to start thinking about miners that join a pool like independent miners and not slave miners, this includes creating a new mining protocol that does not rely on the pool sending the list of transactions to include in a block. Each individual miner has to collect transactions by his own and mine that, this can be achieved by running a full node or by running a SPV like node that ask other nodes for transactions.

Once this protocol is developed and standarised we as a community could require all pools to use it (because its better, because is more trustless...), not by imposing it but by recommending it.

Pool owners could send some instructions using this protocol to the miner about how many transactions to include per block (some pools want small blocks), how many 0 fee transactions to include, how much is the minimum fee per Kb to include transactions and some info about the Coinbase field in the block.

This way is impossible to perform some of the possible 51% attacks:
  • A pool owner cant mine a new chain (selfish mining) (pool clients have a SPV or full node that has checkpoints and ask other peers about the length of the chain)
  • A pool owner can't perform double spends or reverse transactions (pool clients know all the transactions relayed to the network, they know if they are already included on a block)
  • A pool owner cant decide which transactions not to include (but they can configure the minimum fee).
  • A pool owner cant get all the rewards by avoiding other pools from mining blocks (Because the pool client knows the last block independently that is from his pool or other).

The only thing that a 51% pool owner can do is to shut down his pool and drop the hashrate by 51% because he does not control the miners.

If the pool owner owns all the hardware in the pool my proposal is not valid, if the pool clients dont use this protocol my proposal is not valid.


I want to know if this is possible or its been developed or there is already a working protocol that works like this, also I want to read other people's ways to address this threat, thanks for reading.
13  Bitcoin / Bitcoin Discussion / Bitcoin 0.9.0 FINAL is available [Changelog] [Download] on: March 19, 2014, 11:08:47 AM

THIS IS NOT THE LATEST RELEASE OF BITCOIN CORE
NEW RELEASE: 0.9.1 https://bitcointalk.org/index.php?topic=562400.0













The Core Developers of Bitcoin released the 0.9.0 FINAL of Bitcoin Core (aka Bitcoin QT).


DOWNLOAD:
https://bitcoin.org/bin/0.9.0/bitcoin-0.9.0-linux.tar.gz
https://bitcoin.org/bin/0.9.0/bitcoin-0.9.0-macosx.dmg
https://bitcoin.org/bin/0.9.0/bitcoin-0.9.0-win.zip
https://bitcoin.org/bin/0.9.0/bitcoin-0.9.0-win32-setup.exe
https://bitcoin.org/bin/0.9.0/bitcoin-0.9.0-win64-setup.exe


Code:
15616baea0640277c81a8ca4d3e0d963834b8a7d  bitcoin-0.9.0-linux.tar.gz
82b7210587c2037beb5d0b3b9ef2643b7580dfe7  bitcoin-0.9.0-macosx.dmg
5bac25ffc2afa7eaea2bbbd783b787325cf8b537  bitcoin-0.9.0-win.zip
23b315772c86389a8ac05c13bd352f4ec631a659  bitcoin-0.9.0-win32-setup.exe
b404b0ed348be5b15c0704bfdc6b838a732c338e  bitcoin-0.9.0-win64-setup.exe

This is a Final Version, but its the same as 0.9.0rc3

Sources:
https://github.com/bitcoin/bitcoin/releases
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.9.0/
https://bitcoin.org/bin/0.9.0/README.txt


Bitcoin Core version 0.9.0 is now available from:

  https://bitcoin.org/bin/0.9.0/

This is a release candidate for a new major version. A major version brings
both new features and bug fixes.

Please report bugs using the issue tracker at github:

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

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), uninstall all
earlier versions of Bitcoin, then run the installer (on Windows) or just copy
over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).

If you are upgrading from version 0.7.2 or earlier, the first time you run
0.9.0 your blockchain files will be re-indexed, which will take anywhere from
30 minutes to several hours, depending on the speed of your machine.

On Windows, do not forget to uninstall all earlier versions of the Bitcoin
client first, especially if you are switching to the 64-bit version.

Windows 64-bit installer
-------------------------

New in 0.9.0 is the Windows 64-bit version of the client. There have been
frequent reports of users running out of virtual memory on 32-bit systems
during the initial sync. Because of this it is recommended to install the
64-bit version if your system supports it.

NOTE: Release candidate 2 Windows binaries are not code-signed; use PGP
and the SHA256SUMS.asc file to make sure your binaries are correct.
In the final 0.9.0 release, Windows setup.exe binaries will be code-signed.

OSX 10.5 / 32-bit no longer supported
-------------------------------------

0.9.0 drops support for older Macs. The minimum requirements are now:
* A 64-bit-capable CPU (see http://support.apple.com/kb/ht3696);
* Mac OS 10.6 or later (see https://support.apple.com/kb/ht1633).

Downgrading warnings
--------------------

The 'chainstate' for this release is not always compatible with previous
releases, so if you run 0.9 and then decide to switch back to a
0.8.x release you might get a blockchain validation error when starting the
old release (due to 'pruned outputs' being omitted from the index of
unspent transaction outputs).

Running the old release with the -reindex option will rebuild the chainstate
data structures and correct the problem.

Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan
the blockchain for missing spent coins, which will take a long time (tens
of minutes on a typical machine).

Rebranding to Bitcoin Core
---------------------------

To reduce confusion between Bitcoin-the-network and Bitcoin-the-software we
have renamed the reference client to Bitcoin Core.

Autotools build system
-----------------------

For 0.9.0 we switched to an autotools-based build system instead of individual
(q)makefiles.

Using the standard "./autogen.sh; ./configure; make" to build Bitcoin-Qt and
bitcoind makes it easier for experienced open source developers to contribute
to the project.

Be sure to check doc/build-*.md for your platform before building from source.

Bitcoin-cli
-------------

Another change in the 0.9 release is moving away from the bitcoind executable
functioning both as a server and as a RPC client. The RPC client functionality
("tell the running bitcoin daemon to do THIS") was split into a separate
executable, 'bitcoin-cli'. The RPC client code will eventually be removed from
bitcoind, but will be kept for backwards compatibility for a release or two.

`walletpassphrase` RPC
-----------------------

The behavior of the `walletpassphrase` RPC when the wallet is already unlocked
has changed between 0.8 and 0.9.

The 0.8 behavior of `walletpassphrase` is to fail when the wallet is already unlocked:

    > walletpassphrase 1000
    walletunlocktime = now + 1000
    > walletpassphrase 10
    Error: Wallet is already unlocked (old unlock time stays)

The new behavior of `walletpassphrase` is to set a new unlock time overriding
the old one:

    > walletpassphrase 1000
    walletunlocktime = now + 1000
    > walletpassphrase 10
    walletunlocktime = now + 10 (overriding the old unlock time)

Transaction malleability-related fixes
--------------------------------------

This release contains a few fixes for transaction ID (TXID) malleability
issues:

- -nospendzeroconfchange command-line option, to avoid spending
  zero-confirmation change
- IsStandard() transaction rules tightened to prevent relaying and mining of
  mutated transactions
- Additional information in listtransactions/gettransaction output to
  report wallet transactions that conflict with each other because
  they spend the same outputs.
- Bug fixes to the getbalance/listaccounts RPC commands, which would report
  incorrect balances for double-spent (or mutated) transactions.
- New option: -zapwallettxes to rebuild the wallet's transaction information

Transaction Fees
----------------

This release drops the default fee required to relay transactions across the
network and for miners to consider the transaction in their blocks to
0.01mBTC per kilobyte.

Note that getting a transaction relayed across the network does NOT guarantee
that the transaction will be accepted by a miner; by default, miners fill
their blocks with 50 kilobytes of high-priority transactions, and then with
700 kilobytes of the highest-fee-per-kilobyte transactions.

The minimum relay/mining fee-per-kilobyte may be changed with the
minrelaytxfee option. Note that previous releases incorrectly used
the mintxfee setting to determine which low-priority transactions should
be considered for inclusion in blocks.

The wallet code still uses a default fee for low-priority transactions of
0.1mBTC per kilobyte. During periods of heavy transaction volume, even this
fee may not be enough to get transactions confirmed quickly; the mintxfee
option may be used to override the default.

0.9.0 Release notes
=======================

RPC:

- New notion of 'conflicted' transactions, reported as confirmations: -1
- 'listreceivedbyaddress' now provides tx ids
- Add raw transaction hex to 'gettransaction' output
- Updated help and tests for 'getreceivedby(account|address)'
- In 'getblock', accept 2nd 'verbose' parameter, similar to getrawtransaction,
  but defaulting to 1 for backward compatibility
- Add 'verifychain', to verify chain database at runtime
- Add 'dumpwallet' and 'importwallet' RPCs
- 'keypoolrefill' gains optional size parameter
- Add 'getbestblockhash', to return tip of best chain
- Add 'chainwork' (the total work done by all blocks since the genesis block)
  to 'getblock' output
- Make RPC password resistant to timing attacks
- Clarify help messages and add examples
- Add 'getrawchangeaddress' call for raw transaction change destinations
- Reject insanely high fees by default in 'sendrawtransaction'
- Add RPC call 'decodescript' to decode a hex-encoded transaction script
- Make 'validateaddress' provide redeemScript
- Add 'getnetworkhashps' to get the calculated network hashrate
- New RPC 'ping' command to request ping, new 'pingtime' and 'pingwait' fields
  in 'getpeerinfo' output
- Adding new 'addrlocal' field to 'getpeerinfo' output
- Add verbose boolean to 'getrawmempool'
- Add rpc command 'getunconfirmedbalance' to obtain total unconfirmed balance
- Explicitly ensure that wallet is unlocked in `importprivkey`
- Add check for valid keys in `importprivkey`

Command-line options:

- New option: -nospendzeroconfchange to never spend unconfirmed change outputs
- New option: -zapwallettxes to rebuild the wallet's transaction information
- Rename option '-tor' to '-onion' to better reflect what it does
- Add '-disablewallet' mode to let bitcoind run entirely without wallet (when
  built with wallet)
- Update default '-rpcsslciphers' to include TLSv1.2
- make '-logtimestamps' default on and rework help-message
- RPC client option: '-rpcwait', to wait for server start
- Remove '-logtodebugger'
- Allow `-noserver` with bitcoind

Block-chain handling and storage:

- Update leveldb to 1.15
- Check for correct genesis (prevent cases where a datadir from the wrong
  network is accidentally loaded)
- Allow txindex to be removed and add a reindex dialog
- Log aborted block database rebuilds
- Store orphan blocks in serialized form, to save memory
- Limit the number of orphan blocks in memory to 750
- Fix non-standard disconnected transactions causing mempool orphans
- Add a new checkpoint at block 279,000

Wallet:

- Bug fixes and new regression tests to correctly compute
  the balance of wallets containing double-spent (or mutated) transactions
- Store key creation time. Calculate whole-wallet birthday.
- Optimize rescan to skip blocks prior to birthday
- Let user select wallet file with -wallet=foo.dat
- Consider generated coins mature at 101 instead of 120 blocks
- Improve wallet load time
- Don't count txins for priority to encourage sweeping
- Don't create empty transactions when reading a corrupted wallet
- Fix rescan to start from beginning after importprivkey
- Only create signatures with low S values

Mining:

- Increase default -blockmaxsize/prioritysize to 750K/50K
- 'getblocktemplate' does not require a key to create a block template
- Mining code fee policy now matches relay fee policy

Protocol and network:

- Drop the fee required to relay a transaction to 0.01mBTC per kilobyte
- Send tx relay flag with version
- New 'reject' P2P message (BIP 0061, see
  https://gist.github.com/gavinandresen/7079034 for draft)
- Dump addresses every 15 minutes instead of 10 seconds
- Relay OP_RETURN data TxOut as standard transaction type
- Remove CENT-output free transaction rule when relaying
- Lower maximum size for free transaction creation
- Send multiple inv messages if mempool.size > MAX_INV_SZ
- Split MIN_PROTO_VERSION into INIT_PROTO_VERSION and MIN_PEER_PROTO_VERSION
- Do not treat fFromMe transaction differently when broadcasting
- Process received messages one at a time without sleeping between messages
- Improve logging of failed connections
- Bump protocol version to 70002
- Add some additional logging to give extra network insight
- Added new DNS seed from bitcoinstats.com

Validation:

- Log reason for non-standard transaction rejection
- Prune provably-unspendable outputs, and adapt consistency check for it.
- Detect any sufficiently long fork and add a warning
- Call the -alertnotify script when we see a long or invalid fork
- Fix multi-block reorg transaction resurrection
- Reject non-canonically-encoded serialization sizes
- Reject dust amounts during validation
- Accept nLockTime transactions that finalize in the next block

Build system:

- Switch to autotools-based build system
- Build without wallet by passing `--disable-wallet` to configure, this
  removes the BerkeleyDB dependency
- Upgrade gitian dependencies (libpng, libz, libupnpc, boost, openssl) to more
  recent versions
- Windows 64-bit build support
- Solaris compatibility fixes
- Check integrity of gitian input source tarballs
- Enable full GCC Stack-smashing protection for all OSes

GUI:

- Switch to Qt 5.2.0 for Windows build
- Add payment request (BIP 0070) support
- Improve options dialog
- Show transaction fee in new send confirmation dialog
- Add total balance in overview page
- Allow user to choose data directory on first start, when data directory is
  missing, or when the -choosedatadir option is passed
- Save and restore window positions
- Add vout index to transaction id in transactions details dialog
- Add network traffic graph in debug window
- Add open URI dialog
- Add Coin Control Features
- Improve receive coins workflow: make the 'Receive' tab into a form to request
  payments, and move historical address list functionality to File menu.
- Rebrand to `Bitcoin Core`
- Move initialization/shutdown to a thread. This prevents "Not responding"
  messages during startup. Also show a window during shutdown.
- Don't regenerate autostart link on every client startup
- Show and store message of normal bitcoin:URI
- Fix richtext detection hang issue on very old Qt versions
- OS X: Make use of the 10.8+ user notification center to display Growl-like
  notifications
- OS X: Added NSHighResolutionCapable flag to Info.plist for better font
  rendering on Retina displays.
- OS X: Fix bitcoin-qt startup crash when clicking dock icon
- Linux: Fix Gnome bitcoin: URI handler

Miscellaneous:

- Add Linux script (contrib/qos/tc.sh) to limit outgoing bandwidth
- Add '-regtest' mode, similar to testnet but private with instant block
  generation with 'setgenerate' RPC.
- Add 'linearize.py' script to contrib, for creating bootstrap.dat
- Add separate bitcoin-cli client

Credits
--------

Thanks to everyone who contributed to this release:

- Andrey
- Ashley Holman
- b6393ce9-d324-4fe1-996b-acf82dbc3d53
- bitsofproof
- Brandon Dahler
- Calvin Tam
- Christian Decker
- Christian von Roques
- Christopher Latham
- Chuck
- coblee
- constantined
- Cory Fields
- Cozz Lovan
- daniel
- Daniel Larimer
- David Hill
- Dmitry Smirnov
- Drak
- Eric Lombrozo
- fanquake
- fcicq
- Florin
- frewil
- Gavin Andresen
- Gregory Maxwell
- gubatron
- Guillermo Céspedes Tabárez
- Haakon Nilsen
- HaltingState
- Han Lin Yap
- harry
- Ian Kelling
- Jeff Garzik
- Johnathan Corgan
- Jonas Schnelli
- Josh Lehan
- Josh Triplett
- Julian Langschaedel
- Kangmo
- Lake Denman
- Luke Dashjr
- Mark Friedenbach
- Matt Corallo
- Michael Bauer
- Michael Ford
- Michagogo
- Midnight Magic
- Mike Hearn
- Nils Schneider
- Noel Tiernan
- Olivier Langlois
- patrick s
- Patrick Strateman
- paveljanik
- Peter Todd
- phantomcircuit
- phelixbtc
- Philip Kaufmann
- Pieter Wuille
- Rav3nPL
- R E Broadley
- regergregregerrge
- Robert Backhaus
- Roman Mindalev
- Rune K. Svendsen
- Ryan Niebur
- Scott Ellis
- Scott Willeke
- Sergey Kazenyuk
- Shawn Wilkinson
- Sined
- sje
- Subo1978
- super3
- Tamas Blummer
- theuni
- Thomas Holenstein
- Timon Rapp
- Timothy Stranex
- Tom Geller
- Torstein Husebø
- Vaclav Vobornik
- vhf / victor felder
- Vinnie Falco
- Warren Togami
- Wil Bown
- Wladimir J. van der Laan
14  Bitcoin / Development & Technical Discussion / Bitcoin 0.9.0rc2 is available for testing [Changelog] on: March 02, 2014, 09:49:36 AM
15 hours ago the Core Developers of Bitcoin released the 0.9.0 Realase Candidate 2 of Bitcoin Core (aka Bitcoin QT).

This is a Development version so it is not intended for normal use, it is only intended to test, debug and see what is comming.


Sources:
https://github.com/bitcoin/bitcoin/releases
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.9.0/test/
https://bitcoin.org/bin/0.9.0/test/README.txt


Bitcoin Core version 0.9.0rc2 is now available from:

  https://bitcoin.org/bin/0.9.0/test/

This is a release candidate for a new major version. A major version brings
both new features and bug fixes.

Please report bugs using the issue tracker at github:

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

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), uninstall all
earlier versions of Bitcoin, then run the installer (on Windows) or just copy
over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).

If you are upgrading from version 0.7.2 or earlier, the first time you run
0.9.0 your blockchain files will be re-indexed, which will take anywhere from
30 minutes to several hours, depending on the speed of your machine.

On Windows, do not forget to uninstall all earlier versions of the Bitcoin
client first, especially if you are switching to the 64-bit version.

Windows 64-bit installer
-------------------------

New in 0.9.0 is the Windows 64-bit version of the client. There have been
frequent reports of users running out of virtual memory on 32-bit systems
during the initial sync. Because of this it is recommended to install the
64-bit version if your system supports it.

NOTE: Release candidate 2 windows binaries are not code-signed; use pgp
and the SHA256SUMS.asc file to make sure your binaries are correct.
The final 0.9.0 release Windows setup.exe binaries will be code-signed.

OSX 10.5 / 32-bit no longer supported
-------------------------------------

0.9.0 drops support for older Macs. The minimum requirements are now
a 64-bit-capable CPU running OSX 10.6 or later.

Rebranding to Bitcoin Core
---------------------------

To reduce confusion between Bitcoin-the-network and Bitcoin-the-software we
have renamed the reference client to Bitcoin Core.

Autotools build system
-----------------------

For 0.9.0 we switched to an autotools-based build system instead of individual
(q)makefiles.

Using the standard “./autogen.sh; ./configure; make” to build Bitcoin-Qt and
bitcoind makes it easier for experienced open source developers to contribute
to the project.

Be sure to check doc/build-*.md for your platform before building from source.

Bitcoin-cli
-------------

Another change in the 0.9 release is moving away from the bitcoind executable
functioning both as a server and as a RPC client. The RPC client functionality
(“tell the running bitcoin daemon to do THIS”) was split into a separate
executable, 'bitcoin-cli'. The RPC client code will eventually be removed from
bitcoind, but will be kept for backwards compatibility for a release or two.

`walletpassphrase` RPC
-----------------------

The behavior of the `walletpassphrase` RPC when the wallet is already unlocked
has changed between 0.8 and 0.9.

The 0.8 behavior of `walletpassphrase` is to fail when the wallet is already unlocked:

    > walletpassphrase 1000
    walletunlocktime = now + 1000
    > walletpassphrase 10
    Error: Wallet is already unlocked (old unlock time stays)

The new behavior of `walletpassphrase` is to set a new unlock time overriding
the old one:

    > walletpassphrase 1000
    walletunlocktime = now + 1000
    > walletpassphrase 10
    walletunlocktime = now + 10 (overriding the old unlock time)

Transaction malleability-related fixes
--------------------------------------

This release contains a few fixes for transaction id malleability issues:

- -nospendzeroconfchange command-line option, to avoid spending
  zero-confirmation change
- IsStandard() transaction rules tightened to prevent relaying and mining of
  mutated transactions
- Additional information in listtransactions/gettransaction output to
  report wallet transactions that conflict with each other because
  they spend the same outputs.
- Bug fixes to the getbalance/listaccounts RPC commands, which would report
  incorrect balances for double-spent (or mutated) transactions.
- New option: -zapwallettxes to rebuild the wallet's transaction information

Transaction Fees
----------------

This release drops the default fee required to relay transactions across the
network to 0.01mBTC per kilobyte. Note that getting a transaction relayed
across the network does NOT guarantee that the transaction will be
accepted by a miner and included in a block, and the default fee accepted
by miners remains 0.1mBTC per kilobyte.

As in previous releases, the relay fee may be changed with the -minrelaytxfee
command-line option, and miners may change the default minimum fee they accept
with the -mintxfee command-line option.

0.9.0rc2 Release notes
=======================

RPC:

- New notion of 'conflicted' transactions, reported as
  confirmations: -1
- 'listreceivedbyaddress' now provides tx ids
- Add raw transaction hex to 'gettransaction' output
- Updated help and tests for 'getreceivedby(account|address)'
- In 'getblock', accept 2nd 'verbose' parameter, similar to getrawtransaction,
  but defaulting to 1 for backward compatibility
- Add 'verifychain', to verify chain database at runtime
- Add 'dumpwallet' and 'importwallet' RPCs
- 'keypoolrefill' gains optional size parameter
- Add 'getbestblockhash', to return tip of best chain
- Add 'chainwork' (the total work done by all blocks since the genesis block)
  to 'getblock' output
- Make RPC password resistant to timing attacks
- Clarify help messages and add examples
- Add 'getrawchangeaddress' call for raw transaction change destinations
- Reject insanely high fees by default in 'sendrawtransaction'
- Add RPC call 'decodescript' to decode a hex-encoded transaction script
- Make 'validateaddress' provide redeemScript
- Add 'getnetworkhashps' to get the calculated network hashrate
- New RPC 'ping' command to request ping, new 'pingtime' and 'pingwait' fields
  in 'getpeerinfo' output
- Adding new 'addrlocal' field to 'getpeerinfo' output
- Add verbose boolean to 'getrawmempool'
- Add rpc command 'getunconfirmedbalance' to obtain total unconfirmed balance
- Explicitly ensure that wallet is unlocked in `importprivkey`
- Add check for valid keys in `importprivkey`

Command-line options:

- New option: -nospendzeroconfchange to never spend unconfirmed change outputs
- New option: -zapwallettxes to rebuild the wallet's transaction information
- Rename option '-tor' to '-onion' to better reflect what it does
- Add '-disablewallet' mode to let bitcoind run entirely without wallet (when
  built with wallet)
- Update default '-rpcsslciphers' to include TLSv1.2
- make '-logtimestamps' default on and rework help-message
- RPC client option: '-rpcwait', to wait for server start
- Remove '-logtodebugger'
- Allow `-noserver` with bitcoind

Block-chain handling and storage:

- Update leveldb to 1.15
- Check for correct genesis (prevent cases where a datadir from the wrong
  network is accidentally loaded)
- Allow txindex to be removed and add a reindex dialog
- Log aborted block database rebuilds
- Store orphan blocks in serialized form, to save memory
- Limit the number of orphan blocks in memory to 750
- Fix non-standard disconnected transactions causing mempool orphans
- Add a new checkpoint at block 279,000

Wallet:

- Bug fixes and new regression tests to correctly compute
  the balance of wallets containing double-spent (or mutated) transactions
- Store key creation time. Calculate whole-wallet birthday.
- Optimize rescan to skip blocks prior to birthday
- Let user select wallet file with -wallet=foo.dat
- Consider generated coins mature at 101 instead of 120 blocks
- Improve wallet load time
- Don't count txins for priority to encourage sweeping
- Don't create empty transactions when reading a corrupted wallet
- Fix rescan to start from beginning after importprivkey
- Only create signatures with low S values.

Mining:

- Increase default -blockmaxsize/prioritysize to 750K/50K
- 'getblocktemplate' does not require a key to create a block template

Protocol and network:

- Drop the fee required to relay a transaction to 0.01mBTC per kilobyte
- Send tx relay flag with version
- New 'reject' P2P message (BIP 0061, see https://gist.github.com/gavinandresen/7079034 for draft)
- Dump addresses every 15 minutes instead of 10 seconds
- Relay OP_RETURN data TxOut as standard transaction type
- Remove CENT-output free transaction rule when relaying
- Lower maximum size for free transaction creation
- Send multiple inv messages if mempool.size > MAX_INV_SZ
- Split MIN_PROTO_VERSION into INIT_PROTO_VERSION and MIN_PEER_PROTO_VERSION
- Do not treat fFromMe transaction differently when broadcasting
- Process received messages one at a time without sleeping between messages
- Improve logging of failed connections
- Bump protocol version to 70002
- Add some additional logging to give extra network insight
- Added new DNS seed from bitcoinstats.com

Validation:

- Log reason for non-standard transaction rejection
- Prune provably-unspendable outputs, and adapt consistency check for it.
- Detect any sufficiently long fork and add a warning
- Call the -alertnotify script when we see a long or invalid fork
- Fix multi-block reorg transaction resurrection
- Reject non-canonically-encoded serialization sizes
- Reject dust amounts during validation
- Accept nLockTime transactions that finalize in the next block

Build system:

- Switch to autotools-based build system
- Build without wallet by passing `--disable-wallet` to configure, this removes
  the BerkeleyDB dependency
- Upgrade gitian dependencies (libpng, libz, libupnpc, boost, openssl) to more
  recent versions
- Windows 64-bit build support
- Solaris compatibility fixes
- Check integrity of gitian input source tarballs
- Enable full GCC Stack-smashing protection for all OSes

GUI:

- Switch to Qt 5.2.0 for Windows build
- Add payment request (BIP 0070) support
- Improve options dialog
- Show transaction fee in new send confirmation dialog
- Add total balance in overview page
- Allow user to choose data directory on first start, when data directory is
  missing, or when the -choosedatadir option is passed
- Save and restore window positions
- Add vout index to transaction id in transactions details dialog
- Add network traffic graph in debug window
- Add open URI dialog
- Add Coin Control Features
- Improve receive coins workflow: make the 'Receive' tab into a form to request
  payments, and move historical address list functionality to File menu.
- Rebrand to `Bitcoin Core`
- Move initialization/shutdown to a thread. This prevents “Not responding”
  messages during startup. Also show a window during shutdown.
- Don't regenerate autostart link on every client startup
- Show and store message of normal bitcoin:URI
- Fix richtext detection hang issue on very old Qt versions
- osx: Make use of the 10.8+ user notification center to display growl like
       notifications
- osx: Added NSHighResolutionCapable flag to Info.plist for better font
       rendering on Retina displays.
- osx: Fix bitcoin-qt startup crash when clicking dock icon
- linux: Fix Gnome bitcoin: URI handler

Miscellaneous:

- Add Linux script (contrib/qos/tc.sh) to limit outgoing bandwidth
- Add '-regtest' mode, similar to testnet but private with instant block
  generation with 'setgenerate' RPC.
- Add 'linearize.py' script to contrib, for creating bootstrap.dat
- Add separate bitcoin-cli client

Credits
--------

Thanks to everyone who contributed to this release:

- Andrey
- Ashley Holman
- b6393ce9-d324-4fe1-996b-acf82dbc3d53
- bitsofproof
- Brandon Dahler
- Calvin Tam
- Christian Decker
- Christopher Latham
- Chuck
- coblee
- constantined
- Cory Fields
- Cozz Lovan
- Daniel Larimer
- David Hill
- Dmitry Smirnov
- Drak
- Eric Lombrozo
- fanquake
- fcicq
- Florin
- frewil
- Gavin Andresen
- Gregory Maxwell
- gubatron
- Guillermo Céspedes Tabárez
- Haakon Nilsen
- HaltingState
- Han Lin Yap
- harry
- Ian Kelling
- Jeff Garzik
- Johnathan Corgan
- Jonas Schnelli
- Josh Lehan
- Josh Triplett
- Julian Langschaedel
- Kangmo
- Lake Denman
- Luke Dashjr
- Mark Friedenbach
- Matt Corallo
- Michael Bauer
- Michael Ford
- Michagogo
- Midnight Magic
- Mike Hearn
- Nils Schneider
- Noel Tiernan
- Olivier Langlois
- patrick s
- Patrick Strateman
- Peter Todd
- phantomcircuit
- phelixbtc
- Philip Kaufmann
- Pieter Wuille
- Rav3nPL
- regergregregerrge
- Robert Backhaus
- Roman Mindalev
- Rune K. Svendsen
- Ryan Niebur
- Scott Ellis
- Scott Willeke
- Sergey Kazenyuk
- Shawn Wilkinson
- Sined
- sje
- Subo1978
- super3
- Tamas Blummer
- theuni
- Thomas Holenstein
- Timon Rapp
- Timothy Stranex
- Vaclav Vobornik
- vhf / victor felder
- Vinnie Falco
- Warren Togami
- Wil Bown
- Wladimir J. van der Laan
15  Local / Español (Spanish) / nexusakachus - this user has stolen $1400 dollars of bitcoins from me on: January 31, 2014, 06:43:10 AM


Pongo este tema aquí para que leáis un tema que han abierto acerca de nexusakachus, el suele frecuentar este subforo.

https://bitcointalk.org/index.php?topic=288078


16  Economy / Auctions / [WTS] Domain BitcoinFirstbits.com on: January 31, 2014, 06:37:10 AM
BitcoinFirstbits.com



Firstbits refers to the practice of abbreviating a Bitcoin address such that only enough of the initial characters of the address are given so that the full address can be identified from the block chain.

For example, 1Fbits is the FirstBits of 1FbitsRZvASRdGLtfK8Wd8NMdNipxNjdrd

The domain name was used to host a firstbits lookup service but currently the Blockchain.info API is down so it is not working.


The auction starts at 0.05 BTC
Bids can be made in steps of 0.01 BTC

When searching for "firstbits" or "bitcoin firstbits" on google this domain is shown the first.
The domain is currently on namecheap but it can be transferred easily.

What you get:
 - The domain bitcoinfirstbits.com (transferred to your registrar, EPP key)
 - The full code of bitcoinfirstbits.com that uses Blockchain.info API

Auction ends on the 1st of March or sooner if I decide so.

I accept escrow providing that you pay the fees and it is a reputable one.
17  Economy / Digital goods / [MOVED] Domain BitcoinFirstbits.com on: January 25, 2014, 12:40:59 PM
This thread has been moved to https://bitcointalk.org/index.php?topic=441570.0





























18  Bitcoin / Development & Technical Discussion / Idea on the "Blocks are [not] full problem" on: December 02, 2013, 07:22:19 PM
Problem discussed in this thread:
https://bitcointalk.org/index.php?topic=339505.0

Quote
Miners create 250KB or less blocks because they broadcast faster and they have less chances of been orphaned, they include few transactions in them



Here it comes my idea about this issue:

Miners include few transactions in blocks because more transactions equals more probability of orphaned block so lets equal all blocks:

Miners should craft a block normally, so lets imagine they generate a 250KB block. Before they send it to other node they have to concatenate junk bytes (random (?)) to the block data, so all blocks are 1MB.

When a node sees this block, they broadcast it and when they finish they delete this junk bytes and they only the block.

The junk data never gets into the blockchain

Pros:
- All blocks "are" 1MB in terms of relaying them.
- We avoid other more tecnical mecanisms
Cons:
- Bitcoin QT needs some bandwith more because now all blocks are 1MB.


If one day we need to rise the 1MB block limit this process will be the same but all blocks will require to be 10MB (for example). We only need to concatenate junk to them.


How to perform this hard fork?
Bitcoin core developers can release an update that includes this fix but only enforcing it when the blockchain reaches the block 277000 (30 days later) so we give some time for people and miners to update their software.



19  Local / Español (Spanish) / Se necesita ayuda para traducir Bitcoin.org al Español (ES) on: November 29, 2013, 03:06:01 PM
Cito el anuncio que se ha hecho en otra seccion:

Many existing translations need to be updated and new languages are welcome.

Why this is important

The future of Bitcoin is closely related to decentralization. Not just the network, but the jurisdiction of all of its users, miners and businesses. Widespread adoption increases resilience and provides incentives for countries and businesses to compete in a free market. Making sure everyone can benefit from Bitcoin is also important to create a fair and sustainable economy. Yet, most countries don't have as much information available in their own languages. Bitcoin.org can help to make a difference on this level. Bitcoin.org is one of the most visited website in the world, this is an incredible chance and opportunity for the Bitcoin community.

How to help

If you speak a language other than English, or if you know anyone who does and would want to participate, You can go to Transifex : https://www.transifex.com/projects/p/bitcoinorg/ and click to join the team for your language. You can then review / improve existing translations and translate additional texts that are still not translated. New coordinators (with a good level of experience for their respective language) would be helpful for some of these teams.

When a translation is nearly complete, I usually create an editable live preview to help translators to complete their work. A few good quality translation is always worth more than many poor quality translations. All texts need to be translated and reviewed by at least two different persons (peer-reviewed), unless perhaps if you're a professional translator. It's also always welcome to ask for questions if you are unsure about anything, this can help preventing accidental changes in the meaning of some statements.

BTW, there is also many other projects listed on this page which can be translated:
http://bitcoin.org/en/support-bitcoin

Donations / Bounties

Feel free to offer a bounty if you want to incentivize people to work on translations. You can also send some tips to this address ( 112ypbXZSUnJvbAvzMNSoxHV6uJM77LSAk ) and let me know what language you want to support the most. I'll redirect these tips at the most active contributors (I'll do my best to be fair, and also keep some tips for previous most active translators who worked for free). You're also very welcome if you want to pay a professional translator directly (here's one accepting bitcoins http://hyperwyrm.co.uk/) . With the recent rise in the price, there is probably some bit-millionaire who would like to help Bitcoin reaching new horizons?

Edit: 34 mBTC donated so far, thanks!

Some priorities

These languages really need to be updated since a while:

Spanish
Polish
Russian
Chinese (Taiwan)
Persian
Arabic
Indonesian

These languages could be added soon with some help:

Japanese
Portuguese (Brazil)
Korean




Resumen:
Si sabes Ingles y Español (ES) puedes ayudar a traduccir Bitcoin.org registrandote en https://www.transifex.com/projects/p/bitcoinorg/
Una vez registrado unete al proyecto de traducción y empieza a traducir algunas frases.
No se necesita gran nivel de ingles (algunas traducciones son sencillas) pero si que se necesita profesionalidad a la hora de escribir en Español (ortografía correcta, etc).

20  Other / Meta / HSTS implementation to improve HTTPS in bitcointalk on: November 23, 2013, 10:28:19 PM
I know I have suggested this two times but I consider it necessary.



Please enable HSTS to avoid sslstrip or a MITM replacing the http page.
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

With PHP check if the page is been served in HTTP, if so redirect to HTTPS.
In HTTPS set the HSTS header:
Code:
header("strict-transport-security: max-age=31536000");
(Example implementation in PHP).

That tells the browser to only use the HTTPS versión of bitcointalk.org for a year (31536000 seconds).
So, my browser will go directly to https even if I have no internet conection.
Pages: [1] 2 3 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!