Bitcoin Forum
November 15, 2018, 05:38:24 AM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 »
121  Bitcoin / Bitcoin Discussion / Bitcoin.com almost forks the blockchain with buggy BU on: January 30, 2017, 02:32:33 AM
Bitcoin.com's mining pool, running Bitcoin Unlimited, recently accidentally mined a block greater than 1,000,000 bytes. This block is considered invalid under the current consensus rules and was subsequently rejected. This resulted in Bitcoin.com to lose the ~13.2 BTC block reward of that block and waste their miner's time and electricity.

This invalid block also resulted in many BU nodes being banned by other nodes for relaying an invalid block.

Note that this is different from normal block orphaning as this could have resulted in a consensus split, not just a normal small fork with all full nodes switching to follow the longest chain. The longest chain could have been built off of the invalid block due to BU and SPV miners making up nearly half of the network hashrate.

This block could have resulted in an actual hard fork and chain split due to BU miners and SPV miners. Some BU miners would have considered this block valid and thus mined on top of it. SPV miners would have received the block header and mined on top of that without checking the validity of the actual block itself until later. This could have resulted in a blockchain split similar to the July 2015 fork. Fortunately neither of those happened and there was no chain split.

The reason for this block is that BU changed some important code regulating the size of the block. Specifically, they removed something that reserved space for the coinbase transaction and thus once the transactions had been selected and the coinbase transaction were added, the size was too big. This bug appears to have been introduced here which was also committed directly to the source code with a Pull Request, so it is likely that the change was not reviewed.

See also: Reddit discussion
122  Bitcoin / Bitcoin Technical Support / MOVED: Import A Large Amount Of Private Keys And Check For Their Balances? on: January 29, 2017, 04:50:37 PM
This topic has been moved to Trashcan.

This thread was locked and trashed because it is for the purpose of helping someone steal Bitcoin from other people. Stealing is illegal, not condoned by this forum, and is thus against the forum rules.
123  Economy / Auctions / Advertise on bctalkaccountpricer.info Round 4 on: January 08, 2017, 10:06:29 PM
I am looking for people who would like to advertise on my website, https://www.bctalkaccountpricer.info/

What is the website?

For those of you who don't know what this website is, it is a place to look up various stats about an account, including a price estimation. This site is frequently used by account sellers as well as those who want to find out the potential activity of an account, posting statistics of the account, and all of the addresses previously posted by the account. For more details, see https://bitcointalk.org/index.php?topic=1142314.0.

Stats

The website receives 100-300 impressions per day.

Ad Slots

There are two ad slots currently available, a banner ad on top and a sidebar ad on the right. The banner ad must be 728x90 and the sidebar ads 120x600. The ads will be shown from Monday January 16th at midnight until Sunday January 22nd at 11:59 PM UTC.

The following screenshot shows the ad locations:



Ad restrictions

The ads must either be images with links or an iframe. Any ads related to anything NSFW will not be allowed. I reserve the right to reject bids and ads.

Bidding

When bidding, please indicate which ad slot (banner, left sidebar, right sidebar) you would are bidding for.

Bids for each slot start at 0.005BTC. The minimum bidding increment is 0.001BTC.

Bidding ends on Saturday January 14th at 11:59 PM UTC.

The winners of the auction will be notified once the auction is over. You must either send first or use a reputable escrow.
124  Bitcoin / Bitcoin Technical Support / [READ BEFORE POSTING] Tech Support Help Request Format on: January 06, 2017, 05:06:46 PM
This is a continuation of https://bitcointalk.org/index.php?topic=1282666.0 to actually make the format standard and stickied.



The Format


When creating a new help request in the Tech Support section, please use the following format. It will make it easier for others to help you as this format contains the information that is needed to provide the proper help.

Quote from: Standard Format
Bitcoin Client Software and Version Number:
Operating System:
System Hardware Specs:
Description of Problem:
Any Related Addresses:
Any Related Transaction IDs:
Screenshot of the problem:
Log Files from the Bitcoin Client:



Explanation of each field

Bitcoin Client Software and Version Number: The name of the software you are using and the Version number. We will always need to know this information.

Operating System: The name, version number, and bitness of your operating system. This is not always necessary. It is only needed for issues with your Bitcoin Client.

System Hardware Specs: The CPU, RAM, and Hard drive space of the computer that you are using. This is not always necessary. It is only needed for issues with your Bitcoin Client.

Description of Problem: The description of the problem you are having. This is always necessary. We need to know what is wrong.

Any Related Addresses: Any addresses related to the problem you are having. This is not always necessary. We only need to know this if you are having issues with transactions.

Any Related Transaction IDs: Any transaction IDs related to the problem that you are having. This is not always necessary. We only need to know this if you are having issues with transactions.

Screenshot of the problem: A screenshot of the problem that you are having uploaded to an image hosting service such as https://imgur.com. This is not always necessary. It is only needed for issues with your Bitcoin Client.

Log Files from the Bitcoin Client: A link to the log files created by your client uploaded to paste sites such as https://pastebin.com. This is not always necessary. It is only needed for issues with your Bitcoin Client. Not all software have options for exporting log files. If the log file is too large, just paste as much as you can from the bottom of the file.



Examples

The following are two example reports. The first example is one for a software client issue. The second example is for a transaction issue.

Quote from: Example 1
Bitcoin Client Software and Version Number: Bitcoin Core 0.13.1
Operating System: Windows 10 64-bit
System Hardware Specs: 4.0 GHz Quad Core CPU with 8 GB RAM and 50 GB free hard drive space.
Description of Problem: Bitcoin Core seems to be stuck while synching.
Any Related Addresses: None
Any Related Transaction IDs: None
Screenshot of the problem: https://imgur.com/a/zMnKk
Log Files from the Bitcoin Client: http://pastebin.com/tfqN34DW

Quote from: Example 2
Bitcoin Client Software and Version Number: Electrum 2.6.4
Operating System: Ubuntu 16.10 64-bit
System Hardware Specs: N/A
Description of Problem: I received a transaction several hours ago and it still has not confirmed
Any Related Addresses: 16mT7jrpkjnJBD7a3TM2awyxHub58H6r6Z
Any Related Transaction IDs: 4b54637c43beba0eae0cb0a8e139da3e170a941978d47aa5a37b17ff854939c1
Screenshot of the problem: N/A
Log Files from the Bitcoin Client: N/A



If you have any issues with getting any of these fields, still make your help request post and state that you have issues with getting the information for the fields that you have issues with. Users here will guide you on how to get it.



This format can change and evolve as it is used and other users comment on it.
125  Economy / Auctions / Advertise on bctalkaccountpricer.info Round 3 on: January 05, 2017, 04:02:42 PM
I am looking for people who would like to advertise on my website, https://www.bctalkaccountpricer.info/

What is the website?

For those of you who don't know what this website is, it is a place to look up various stats about an account, including a price estimation. This site is frequently used by account sellers as well as those who want to find out the potential activity of an account, posting statistics of the account, and all of the addresses previously posted by the account. For more details, see https://bitcointalk.org/index.php?topic=1142314.0.

Stats

The website receives 100-300 impressions per day.

Ad Slots

There are two ad slots currently available, a banner ad on top and a sidebar ad on the right. The banner ad must be 728x90 and the sidebar ads 120x600. The ads will be shown from Monday January 9th at midnight until Sunday January 15th at 11:59 PM UTC.

The following screenshot shows the ad locations:



Ad restrictions

The ads must either be images with links or an iframe. Any ads related to anything NSFW will not be allowed. I reserve the right to reject bids and ads.

Bidding

When bidding, please indicate which ad slot (banner, left sidebar, right sidebar) you would are bidding for.

Bids for each slot start at 0.005BTC. The minimum bidding increment is 0.001BTC.

Bidding ends on Saturday January 7th at 11:59 PM UTC.

The winner of the auction will be notified once the auction is over. You must either send first or use a reputable escrow.
126  Economy / Auctions / Advertise on bctalkaccountpricer.info Round 2 on: December 21, 2016, 09:54:20 PM
I am looking for people who would like to advertise on my website, https://www.bctalkaccountpricer.info/

What is the website?

For those of you who don't know what this website is, it is a place to look up various stats about an account, including a price estimation. This site is frequently used by account sellers as well as those who want to find out the potential activity of an account, posting statistics of the account, and all of the addresses previously posted by the account. For more details, see https://bitcointalk.org/index.php?topic=1142314.0.

Stats

The website receives 100-300 impressions per day.

Ad Slots

There are two ad slots currently available, a banner ad on top and a sidebar ad on the right. The banner ad must be 728x90 and the sidebar 120x600. The ads will be shown from Wednesday December 28th at midnight until Tuesday January 3rd at 11:59 PM UTC.

The following screenshot shows the ad locations:



Ad restrictions

The ads must either be images with links or an iframe. Any ads related to anything NSFW will not be allowed. I reserve the right to reject bids and ads.

Bidding

When bidding, please indicate which ad slot (banner or sidebar) you would are bidding for.

Bids for each slot start at 0.005BTC. The minimum bidding increment is 0.001BTC.

Bidding ends on Tuesday December 27th at Midnight UTC.

The winner of the auction will be notified once the auction is over. You must either send first or use a reputable escrow.
127  Economy / Auctions / Advertise on bctalkaccountpricer.info Round 1 on: December 17, 2016, 04:12:27 PM
I am looking for people who would like to advertise on my website, https://www.bctalkaccountpricer.info/

What is the website?

For those of you who don't know what this website is, it is a place to look up various stats about an account, including a price estimation. This site is frequently used by account sellers as well as those who want to find out the potential activity of an account, posting statistics of the account, and all of the addresses previously posted by the account. For more details, see https://bitcointalk.org/index.php?topic=1142314.0.

Stats

The website receives 100-300 impressions per day.

Ad Slots

There are two ad slots currently available, a banner ad on top and a sidebar ad on the right. The banner ad must be 728x90 and the sidebar 120x600. The ads will be shown from Tuesday December 20th at midnight until Monday December 26th at 11:59 PM UTC.

The following screenshot shows the ad locations:



Ad restrictions

The ads must either be images with links or an iframe. Any ads related to anything NSFW will not be allowed. I reserve the right to reject bids and ads.

Bidding

When bidding, please indicate which ad slot (banner or sidebar) you would are bidding for.

Bids for each slot start at 0.005BTC

Bidding ends on December 19th at Midnight UTC.

The winner of the auction will be notified once the auction is over. You must either send first or use a reputable escrow.
128  Bitcoin / Bitcoin Technical Support / MOVED: Transaction is not being processed. on: November 22, 2016, 05:55:24 PM
This topic has been moved to Trashcan.

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

Duplicate thread.
129  Other / Meta / [Unofficial] New Global Moderator Election - [Discussion] on: November 19, 2016, 12:41:11 AM
This thread is for the discussion of ongoing election for a new Global Moderator.

To find out more information about this election and to see and cast votes, please see the following thread - https://bitcointalk.org/index.php?topic=1685557.0

Do not cast votes here.
130  Other / Meta / [Unofficial] New Global Moderator Election - [Voting] on: November 19, 2016, 12:40:28 AM
Due to the large number of single votes, all votes from now on must have at least two votes in order for the preferential voting system to work.



Important Update: I mistakenly forgot HostFat so he has been added to the ballot. If you voted prior to this post: https://bitcointalk.org/index.php?topic=1685557.msg16935051#msg16935051, you may change your vote ONCE and only to include HostFat if you wish to vote for him. If you do change your vote, the time of the edit will be noted and no further edits are allowed.



As many of you may have noticed, moderation and spam control here on Bitcointalk has been lacking. You may have also noticed that there are only three Global Moderators, of which only one is particularly active. To remedy this, I and other staff members, are proposing to theymos a person to promote to Global Moderator. However, we would like for the community to participate in this process as well. Thus I am creating this thread to serve as a poll for everyone to vote on a staff member to promote to Global Moderator.

In order to maintain fairness of voting and vote counting, all of the votes and the entire vote tallying process will be recorded in the Google Sheets document listed below. This document will contain all votes, the scripts, and formulas that we will be using to calculate the final tallies. Anyone can view this document and the scripts so that fairness can be verified.

Votes will be tracked here: https://docs.google.com/spreadsheets/d/1bOitaEjce12xUzddwAwtwXGn9pH7FOpyPKl5Cbeo6ww/edit?usp=sharing
Due to Google Scripts restrictions, the actual script that we are using to automate shifting of votes after eliminations cannot be viewed. A copy of the script is available here: https://script.google.com/d/1TrOY5VBu44hY83FjoFgq28oBlXaqguQCCMzCaZTCnMW50rdYm_q96fr4/edit?usp=sharing

Discussion thread: https://bitcointalk.org/index.php?topic=1685559.0

Voting System
The voting system that we will be using is called Instant-Runoff Voting . In this system, you will rank your top three choices for Global Moderator. Vote counting will work by elimination; candidates with the least number of votes will be eliminated. If your top choice is eliminated, then your vote will go to your second choice, and so on and so forth until only a all votes are exhausted. Once all votes have been tallied and eliminations done, then the candidate with the most votes will be the winner.

How to vote
First, read the rules below.  Next post your top three choices for Global Moderator from the list of candidates below.
Here is an example vote:
Quote
1. Moderator1
2. Moderator2
3. Moderator3

Rules:
  • This election will finish exactly 7 days after the creation of this post: November 26th at 12:40:28 AM
  • To vote, please reply below with your vote,
  • You may only vote once. If your post with your vote is edited, your vote will be removed and any subsequent votes by you will be disregarded,
  • If you attempt to vote more than once (i.e. post more than one time) your votes will be removed and disregarded,
  • You must be a Full Member or above to vote,
  • If you are not familiar with the forum, the moderators, and the forum rules, do not vote,
  • This thread is for VOTING ONLY. Do not discuss this election here so that tallying of votes can be more easily done. Discuss in the discussion thread,
  • You must not have a negative overall trust rating when your profile is viewed from an account with only DefaultTrust on its trust list at Level 2. Any vote from a member with negative trust will be disregarded.
  • No Electioneering. This means that you cannot campaign for a candidate in order to get more people to vote for him. Any user found to be electioneering will have their vote disregarded. Any candidate who is electioneering will be removed from the ballot.

List of candidates (reverse alphabetical):
(The candidates listed are staff members who have told us that they are willing to become a Global Moderator and have been active recently)


Disclaimer
This is not an official election. The winner is not guaranteed to be promoted to Global Moderator, however he/she will be suggested to theymos to be promoted. This is only to determine who the community wants as a Global Moderator. Theymos may choose to promote the winner of this election, he also may not. He may choose to promote no one, he may choose to promote someone else.

Please note that if your post from this thread is deleted, it is because it violates the above rules and the only people who can delete those posts are the Global Moderators or the Admins, not any of the candidates. If you are a newbie and your post is deleted, then a patroller may have deleted it, but in any case, it does not matter as your vote will not be counted.
131  Bitcoin / Bitcoin Discussion / [ALERT] Alert System Retirement on: November 01, 2016, 02:43:26 PM
For reals this time.

The alert system is being retired. This is the pre-warning warning. Tomorrow the pre-final alert will be sent. Read more at https:/bitcoin.org/alert-retirement. Full text copied below.

Quote
Summary

The network wide Alert system is being retired. No Bitcoins are at risk and this warning may be safely ignored.
Upgrade to the newest version of your wallet software to no longer see the alert.

Reasons for Retirement

The network wide Alert system was created by Satoshi Nakamoto as a means of informing Bitcoin users of any important
information regarding Bitcoin. It has been used in the past to inform users about important network events such as
accidental blockchain forks. However, the Alert system also represents a large source of centralization in Bitcoin.
The holders of the singular Alert Key can at any time send an alert which could affect the entire network. As more
developers join, the Alert Key is given to others, but cannot be taken away from those who have left. This has led
to the Alert Key potentially falling into the hands of malicious actors who could use it to disrupt the network. Because
there is only one Alert key, it is not possible to prevent former developers from sending an alert nor is it possible
to identify who sent an Alert.

In addition, the Alert system is primarily Bitcoin Core specific. Many other wallets have their own systems in place but
still must have handling for the Alert system because it is network wide. Something specific for one software should
not be imposed on the entire network.

The Alert system has also lost its usefulness. It is no longer necessary to use it to inform users about problematic network
events as users can easily get their information from any major Bitcoin news outlet.

The Retirement Plan

Retirement of the Alert system consists of a pre-final alert (this alert) which will warn about the impending retirement, a
final maximum sequence alert which cannot be overridden and displays a static "Alert Key Compromised" message, and the
publishing of the Alert key itself. The final alert will be hard coded into Bitcoin Core 0.14 to ensure that all old nodes
receive the final alert.

ActionDescriptionDate
Pre-final Alert PostsPosts on Bitcoin.org, various forums, and various mailing lists that the Alert system will be retired2016-11-01
Pre-final AlertThe alert itself warning that the Alert system will be retired2016-11-02
Final AlertMax sequence Alert to disable the Alert system2017 (Will coincide with Bitcoin Core 0.14 Release Candidate process)
Alert key releasedThe Alert key will be made publicly available1-2 months after the Final Alert


Software without the Alert system

Most major Bitcoin wallets have already removed the alert system in the most recent releases. The software listed below
are guaranteed to have removed/disabled the Alert system or allow you to disable it.

  • Bitcoin Core 0.13.1, 0.13.0, 0.12.1
  • Bitcoin Core 0.10.3, 0.11.x, and 0.12.x can disable alerts with `-alerts=0`
  • Armory 0.94.1+

See also

Original email proposing retirement
Pull request removing Alert system
Removal discussion on github
Pull request disabling alerts
IRC Discussion
132  Bitcoin / Bitcoin Technical Support / MOVED: Forum Error on: October 31, 2016, 03:47:43 AM
This topic has been moved to Trashcan.

Duplicate of https://bitcointalk.org/index.php?topic=1665601.0
133  Bitcoin / Bitcoin Technical Support / MOVED: Bitcoin Core 0.13.1 NOT STABLE? on: October 30, 2016, 08:02:43 PM
This topic has been moved to Trashcan.

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

Duplicate
134  Bitcoin / Armory / PSA You must use 0.95+ in order to use Bitcoin Core 0.13.1+ after Segwit deploys on: October 27, 2016, 11:00:30 PM
Due to the block serialization changes introduced in Segwit, any version earlier than 0.95.0 will not work with Bitcoin Core 0.13.1+ after Segwit activates.
135  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.
136  Bitcoin / Project Development / [Site closed] Bitcoin Tipping Addresses-New Bitcoin Addresses for every donation on: October 16, 2016, 02:34:14 PM
I have decided to close down the website. The project and this thread remains open for whoever wishes to run their own site.



Today I am announcing another project of mine.

Bitcoin Tipping Addresses lets you enter in a BIP 32 Extended Public Key or a list of addresses and it will give you some code that you can embed on any website, forum, github, or Reddit. This code will always show the next address in the list that has not received any Bitcoin. It lets you not need to reuse addresses for receiving donations.

The website is https://bittipaddress.com


How It Works

You simply enter a BIP 32 Extended Public key or a list of addresses that you want to use. Then you get code that you can embed on any website, forum, github, or reddit. This code links back to the server which will either display the correct address or provide a redirect to the Bitcoin URI of the latest empty address.

You can also change the addresses afterwards if necessary. You will receive an ID and a password which will allow you to edit the parameters of your unit.

Embedded code

There are three codes that you can embed. Here are examples of the three. Currently only HTML will show the actual address. The BBCode and Reddit ones will only show a link to a Bitcoin URI which will open the wallet for the user.

HTML (websites and most Markdowns):
Code:
<iframe src="http://bittipaddress.com/bittipaddr/addressfor/da7ir8dl" style="border:none;" scrolling="no"></iframe>

BBCode (forums):
Code:
[url=http://bittipaddress.com/bittipaddr/addressfor/da7ir8dl?redirect]Tip Me![/url]
Tip Me!

Reddit:
Code:
[Tip Me!](http://bittipaddress.com/bittipaddr/addressfor/da7ir8dl?redirect)

Source Code

This project is open source and available at https://github.com/achow101/bittipaddr. The project is written in Java and uses the Google Web Toolkit, BitcoinJ, Amazon Web Services' DynamoDB, and BlockcCypher's API.

License

This project is available under the MIT License. See the LICENSE file in the GitHub Repo for details. Copyright (c) 2016 Andrew Chow

Donations

Think that this project is helpful? Please Tip Me!
137  Bitcoin / Bitcoin Technical Support / MOVED: How to compile a static binary bitcoind in Ubuntu on: October 16, 2016, 02:13:47 PM
This topic has been moved to Trashcan.

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

Duplicate topic
138  Bitcoin / Bitcoin Technical Support / MOVED: PROBLEMA CON UNA S9 ANTMINER on: October 11, 2016, 03:34:50 PM
This topic has been moved to Trashcan.

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

Duplicate.
139  Bitcoin / Bitcoin Technical Support / [READ] Post Armory, MultiBit, Electrum, or online wallets in the right forum on: September 26, 2016, 10:28:48 PM
This forum is for troubleshooting issues with Bitcoin Core or issues in general with Bitcoin transactions (e.g unconfirmed transactions). If your question is not related to those two categories, please post it in the correct forum, listed below.

For

If your question is about a service that is not a wallet, post in https://bitcointalk.org/index.php?board=85.0.
140  Local / 跳蚤市场 / 幫 Bitcoin Armory 翻译成中文 on: September 12, 2016, 04:10:52 PM
Bitcoin Armory 在找人帮忙翻译成中文. 有興趣請去 https://www.transifex.com/bitcoin-armory/public/
Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 »
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!