Qortal/altcoinj
1
0
Fork 1
mirror of https://github.com/Qortal/altcoinj.git synced 2025-11-01 21:17:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

Replace documentation references to "Satoshi/official/reference client/implementation" by "Bitcoin Core".

Browse Source 
No code is changed.
This commit is contained in:
Andreas Schildbach
2015-11-29 13:36:03 +01:00
parent b031d65d7d
commit 7cb7fecb22
29 changed files with 74 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
core/src/main/java/org/bitcoinj/core/AbstractBlockChain.java
View File

@@ -51,8 +51,8 @@ import static com.google.common.base.Preconditions.*;
* <p>There are two subclasses of AbstractBlockChain that are useful: {@link BlockChain}, which is the simplest
* class and implements <i>simplified payment verification</i>. This is a lightweight and efficient mode that does
* not verify the contents of blocks, just their headers. A {@link FullPrunedBlockChain} paired with a
* {@link org.bitcoinj.store.H2FullPrunedBlockStore} implements full verification, which is equivalent to the
* original Satoshi client. To learn more about the alternative security models, please consult the articles on the
* {@link org.bitcoinj.store.H2FullPrunedBlockStore} implements full verification, which is equivalent to
* Bitcoin Core. To learn more about the alternative security models, please consult the articles on the
* website.</p>
*
* <b>Theory</b>

10
core/src/main/java/org/bitcoinj/core/AlertMessage.java
View File

@@ -169,8 +169,8 @@ public class AlertMessage extends Message {
}
/**
* The inclusive lower bound on software versions that are considered for the purposes of this alert. The Satoshi
* client compares this against a protocol version field, but as long as the subVer field is used to restrict it your
* The inclusive lower bound on software versions that are considered for the purposes of this alert. Bitcoin Core
* compares this against a protocol version field, but as long as the subVer field is used to restrict it your
* alerts could use any version numbers.
* @return uint32
*/
@@ -183,8 +183,8 @@ public class AlertMessage extends Message {
}
/**
* The inclusive upper bound on software versions considered for the purposes of this alert. The Satoshi
* client compares this against a protocol version field, but as long as the subVer field is used to restrict it your
* The inclusive upper bound on software versions considered for the purposes of this alert. Bitcoin Core
* compares this against a protocol version field, but as long as the subVer field is used to restrict it your
* alerts could use any version numbers.
*/
public long getMaxVer() {
@@ -220,7 +220,7 @@ public class AlertMessage extends Message {
}
/**
* A string that is intended to display in the status bar of the official GUI client. It contains the user-visible
* A string that is intended to display in the status bar of Bitcoin Core's GUI client. It contains the user-visible
* message. English only.
*/
public String getStatusBar() {

2
core/src/main/java/org/bitcoinj/core/BitcoinSerializer.java
View File

@@ -138,7 +138,7 @@ public class BitcoinSerializer extends MessageSerializer {
// The checksum is the first 4 bytes of a SHA256 hash of the message payload. It isn't
// present for all messages, notably, the first one on a connection.
//
// Satoshi's implementation ignores garbage before the magic header bytes. We have to do the same because
// Bitcoin Core ignores garbage before the magic header bytes. We have to do the same because
// sometimes it sends us stuff that isn't part of any message.
seekPastMagicBytes(in);
BitcoinPacketHeader header = new BitcoinPacketHeader(in);

2
core/src/main/java/org/bitcoinj/core/Block.java
View File

@@ -56,7 +56,7 @@ public class Block extends Message {
/** How many bytes are required to represent a block header WITHOUT the trailing 00 length byte. */
public static final int HEADER_SIZE = 80;
static final long ALLOWED_TIME_DRIFT = 2 * 60 * 60; // Same value as official client.
static final long ALLOWED_TIME_DRIFT = 2 * 60 * 60; // Same value as Bitcoin Core.
/**
* A constant shared by the entire network: how large in bytes a block is allowed to be. One day we may have to

2
core/src/main/java/org/bitcoinj/core/BloomFilter.java
View File

@@ -56,7 +56,7 @@ public class BloomFilter extends Message {
private long nTweak;
private byte nFlags;
// Same value as the reference client
// Same value as Bitcoin Core
// A filter of 20,000 items and a false positive rate of 0.1% or one of 10,000 items and 0.0001% is just under 36,000 bytes
private static final long MAX_FILTER_SIZE = 36000;
// There is little reason to ever have more hash functions than 50 given a limit of 36,000 bytes

10
core/src/main/java/org/bitcoinj/core/ECKey.java
View File

@@ -231,8 +231,8 @@ public class ECKey implements EncryptableItem {
}
/**
* Construct an ECKey from an ASN.1 encoded private key. These are produced by OpenSSL and stored by the Bitcoin
* reference implementation in its wallet. Note that this is slow because it requires an EC point multiply.
* Construct an ECKey from an ASN.1 encoded private key. These are produced by OpenSSL and stored by Bitcoin
* Core in its wallet. Note that this is slow because it requires an EC point multiply.
*/
public static ECKey fromASN1(byte[] asn1privkey) {
return extractKeyFromASN1(asn1privkey);
@@ -414,8 +414,8 @@ public class ECKey implements EncryptableItem {
}
/**
* Output this ECKey as an ASN.1 encoded private key, as understood by OpenSSL or used by the Bitcoin reference
* implementation in its wallet storage format.
* Output this ECKey as an ASN.1 encoded private key, as understood by OpenSSL or used by Bitcoin Core
* in its wallet storage format.
* @throws org.bitcoinj.core.ECKey.MissingPrivateKeyException if the private key is missing or encrypted.
*/
public byte[] toASN1() {
@@ -1001,7 +1001,7 @@ public class ECKey implements EncryptableItem {
}
/**
* Exports the private key in the form used by the Satoshi client "dumpprivkey" and "importprivkey" commands. Use
* Exports the private key in the form used by Bitcoin Core's "dumpprivkey" and "importprivkey" commands. Use
* the {@link org.bitcoinj.core.DumpedPrivateKey#toString()} method to get the string.
*
* @param params The network this key is intended for use on.

6
core/src/main/java/org/bitcoinj/core/FullPrunedBlockChain.java
View File

@@ -40,8 +40,8 @@ import static com.google.common.base.Preconditions.checkState;
* Bitcoin system, with the downside being a large cost in system resources. Fully verifying means all unspent
* transaction outputs are stored. Once a transaction output is spent and that spend is buried deep enough, the data
* related to it is deleted to ensure disk space usage doesn't grow forever. For this reason a pruning node cannot
* serve the full block chain to other clients, but it nevertheless provides the same security guarantees as a regular
* Satoshi client does.</p>
* serve the full block chain to other clients, but it nevertheless provides the same security guarantees as Bitcoin
* Core does.</p>
*/
public class FullPrunedBlockChain extends AbstractBlockChain {
private static final Logger log = LoggerFactory.getLogger(FullPrunedBlockChain.class);
@@ -265,7 +265,7 @@ public class FullPrunedBlockChain extends AbstractBlockChain {
throw new VerificationException("Tried to spend coinbase at depth " + (height - prevOut.getHeight()));
}
}
// TODO: Check we're not spending the genesis transaction here. Satoshis code won't allow it.
// TODO: Check we're not spending the genesis transaction here. Bitcoin Core won't allow it.
valueIn = valueIn.add(prevOut.getValue());
if (verifyFlags.contains(VerifyFlag.P2SH)) {
if (prevOut.getScript().isPayToScriptHash())

4
core/src/main/java/org/bitcoinj/core/Peer.java
View File

@@ -1152,9 +1152,9 @@ public class Peer extends PeerSocketHandler {
// requesting a subset of what we already requested, which can lead to parallel chain downloads
// and other nastyness. So we just do a quick removal of redundant getdatas here too.
//
// Note that as of June 2012 the Satoshi client won't actually ever interleave blocks pushed as
// Note that as of June 2012 Bitcoin Core won't actually ever interleave blocks pushed as
// part of chain download with newly announced blocks, so it should always be taken care of by
// the duplicate check in blockChainDownloadLocked(). But the satoshi client may change in future so
// the duplicate check in blockChainDownloadLocked(). But Bitcoin Core may change in future so
// it's better to be safe here.
if (!pendingBlockDownloads.contains(item.hash)) {
if (vPeerVersionMessage.isBloomFilteringSupported() && useFilteredBlocks) {

2
core/src/main/java/org/bitcoinj/core/RejectMessage.java
View File

@@ -41,7 +41,7 @@ public class RejectMessage extends Message {
DUPLICATE((byte) 0x12),
/**
* The message described an object was not standard and was thus not accepted.
* The reference client has a concept of standard transaction forms, which describe scripts and encodings which
* Bitcoin Core has a concept of standard transaction forms, which describe scripts and encodings which
* it is willing to relay further. Other transactions are neither relayed nor mined, though they are considered
* valid if they appear in a block.
*/

16
core/src/main/java/org/bitcoinj/core/Transaction.java
View File

@@ -92,7 +92,7 @@ public class Transaction extends ChildMessage {
public static final int MAX_STANDARD_TX_SIZE = 100000;
/**
* If fee is lower than this value (in satoshis), a default reference client will treat it as if there were no fee.
* If fee is lower than this value (in satoshis), Bitcoin Core will treat it as if there were no fee.
* Currently this is 1000 satoshis.
*/
public static final Coin REFERENCE_DEFAULT_MIN_TX_FEE = Coin.valueOf(1000);
@@ -493,8 +493,8 @@ public class Transaction extends ChildMessage {
* These constants are a part of a scriptSig signature on the inputs. They define the details of how a
* transaction can be redeemed, specifically, they control how the hash of the transaction is calculated.
* <p/>
* In the official client, this enum also has another flag, SIGHASH_ANYONECANPAY. In this implementation,
* that's kept separate. Only SIGHASH_ALL is actually used in the official client today. The other flags
* In Bitcoin Core, this enum also has another flag, SIGHASH_ANYONECANPAY. In this implementation,
* that's kept separate. Only SIGHASH_ALL is actually used in Bitcoin Core today. The other flags
* exist to allow for distributed contracts.
*/
public enum SigHash {
@@ -963,7 +963,7 @@ public class Transaction extends ChildMessage {
inputs.get(i).setScriptBytes(TransactionInput.EMPTY_ARRAY);
}
// This step has no purpose beyond being synchronized with the reference clients bugs. OP_CODESEPARATOR
// This step has no purpose beyond being synchronized with Bitcoin Core's bugs. OP_CODESEPARATOR
// is a legacy holdover from a previous, broken design of executing scripts that shipped in Bitcoin 0.1.
// It was seriously flawed and would have let anyone take anyone elses money. Later versions switched to
// the design we use today where scripts are executed independently but share a stack. This left the
@@ -972,7 +972,7 @@ public class Transaction extends ChildMessage {
// do it, we could split off the main chain.
connectedScript = Script.removeAllInstancesOfOp(connectedScript, ScriptOpCodes.OP_CODESEPARATOR);
// Set the input to the script of its output. Satoshi does this but the step has no obvious purpose as
// Set the input to the script of its output. Bitcoin Core does this but the step has no obvious purpose as
// the signature covers the hash of the prevout transaction which obviously includes the output script
// already. Perhaps it felt safer to him in some way, or is another leftover from how the code was written.
TransactionInput input = inputs.get(inputIndex);
@@ -990,7 +990,7 @@ public class Transaction extends ChildMessage {
// SIGHASH_SINGLE means only sign the output at the same index as the input (ie, my output).
if (inputIndex >= this.outputs.size()) {
// The input index is beyond the number of outputs, it's a buggy signature made by a broken
// Bitcoin implementation. The reference client also contains a bug in handling this case:
// Bitcoin implementation. Bitcoin Core also contains a bug in handling this case:
// any transaction output that is signed in this case will result in both the signed output
// and any future outputs to this public key being steal-able by anyone who has
// the resulting signature and the public key (both of which are part of the signed tx input).
@@ -1002,7 +1002,7 @@ public class Transaction extends ChildMessage {
inputs.get(i).setSequenceNumber(inputSequenceNumbers[i]);
}
this.outputs = outputs;
// Satoshis bug is that SignatureHash was supposed to return a hash and on this codepath it
// Bitcoin Core's bug is that SignatureHash was supposed to return a hash and on this codepath it
// actually returns the constant "1" to indicate an error, which is never checked for. Oops.
return Sha256Hash.wrap("0100000000000000000000000000000000000000000000000000000000000000");
}
@@ -1297,7 +1297,7 @@ public class Transaction extends ChildMessage {
* This is useful in certain types of <a href="http://en.bitcoin.it/wiki/Contracts">contracts</a>, such as
* micropayment channels.</p>
*
* <p>Note that currently the replacement feature is disabled in the Satoshi client and will need to be
* <p>Note that currently the replacement feature is disabled in Bitcoin Core and will need to be
* re-activated before this functionality is useful.</p>
*/
public boolean isFinal(int height, long blockTimeSeconds) {

4
core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java
View File

@@ -132,11 +132,11 @@ public class TransactionBroadcast {
// Only bother with this if we might actually hear back:
if (minConnections > 1)
tx.getConfidence().addEventListener(new ConfidenceChange());
// Satoshis code sends an inv in this case and then lets the peer request the tx data. We just
// Bitcoin Core sends an inv in this case and then lets the peer request the tx data. We just
// blast out the TX here for a couple of reasons. Firstly it's simpler: in the case where we have
// just a single connection we don't have to wait for getdata to be received and handled before
// completing the future in the code immediately below. Secondly, it's faster. The reason the
// Satoshi client sends an inv is privacy - it means you can't tell if the peer originated the
// Bitcoin Core sends an inv is privacy - it means you can't tell if the peer originated the
// transaction or not. However, we are not a fully validating node and this is advertised in
// our version message, as SPV nodes cannot relay it doesn't give away any additional information
// to skip the inv here - we wouldn't send invs anyway.

4
core/src/main/java/org/bitcoinj/core/TransactionConfidence.java
View File

@@ -355,8 +355,8 @@ public class TransactionConfidence {
/**
* <p>Depth in the chain is an approximation of how much time has elapsed since the transaction has been confirmed.
* On average there is supposed to be a new block every 10 minutes, but the actual rate may vary. The reference
* (Satoshi) implementation considers a transaction impractical to reverse after 6 blocks, but as of EOY 2011 network
* On average there is supposed to be a new block every 10 minutes, but the actual rate may vary. Bitcoin Core
* considers a transaction impractical to reverse after 6 blocks, but as of EOY 2011 network
* security is high enough that often only one block is considered enough even for high value transactions. For low
* value transactions like songs, or other cheap items, no blocks at all may be necessary.</p>
*

10
core/src/main/java/org/bitcoinj/core/TransactionOutput.java
View File

@@ -204,8 +204,8 @@ public class TransactionOutput extends ChildMessage {
}
/**
* <p>Gets the minimum value for a txout of this size to be considered non-dust by a reference client
* (and thus relayed). See: CTxOut::IsDust() in the reference client. The assumption is that any output that would
* <p>Gets the minimum value for a txout of this size to be considered non-dust by Bitcoin Core
* (and thus relayed). See: CTxOut::IsDust() in Bitcoin Core. The assumption is that any output that would
* consume more than a third of its value in fees is not something the Bitcoin system wants to deal with right now,
* so we call them "dust outputs" and they're made non standard. The choice of one third is somewhat arbitrary and
* may change in future.</p>
@@ -213,14 +213,14 @@ public class TransactionOutput extends ChildMessage {
* <p>You probably should use {@link org.bitcoinj.core.TransactionOutput#getMinNonDustValue()} which uses
* a safe fee-per-kb by default.</p>
*
* @param feePerKbRequired The fee required per kilobyte. Note that this is the same as the reference client's -minrelaytxfee * 3
* @param feePerKbRequired The fee required per kilobyte. Note that this is the same as Bitcoin Core's -minrelaytxfee * 3
* If you want a safe default, use {@link Transaction#REFERENCE_DEFAULT_MIN_TX_FEE}*3
*/
public Coin getMinNonDustValue(Coin feePerKbRequired) {
// A typical output is 33 bytes (pubkey hash + opcodes) and requires an input of 148 bytes to spend so we add
// that together to find out the total amount of data used to transfer this amount of value. Note that this
// formula is wrong for anything that's not a pay-to-address output, unfortunately, we must follow the reference
// clients wrongness in order to ensure we're considered standard. A better formula would either estimate the
// formula is wrong for anything that's not a pay-to-address output, unfortunately, we must follow Bitcoin Core's
// wrongness in order to ensure we're considered standard. A better formula would either estimate the
// size of data needed to satisfy all different script types, or just hard code 33 below.
final long size = this.bitcoinSerialize().length + 148;
Coin[] nonDustAndRemainder = feePerKbRequired.multiply(size).divideAndRemainder(1000);

2
core/src/main/java/org/bitcoinj/core/TxConfidenceTable.java
View File

@@ -33,7 +33,7 @@ import static com.google.common.base.Preconditions.checkNotNull;
* announce the transaction within a reasonable time, it may be that the TX is not valid. Alternatively, an attacker
* may control your entire internet connection: in this scenario counting broadcasting peers does not help you.</p>
*
* <p>It is <b>not</b> at this time directly equivalent to the Satoshi clients memory pool, which tracks
* <p>It is <b>not</b> at this time directly equivalent to the Bitcoin Core memory pool, which tracks
* all transactions not currently included in the best chain - it's simply a cache.</p>
*/
public class TxConfidenceTable {

4
core/src/main/java/org/bitcoinj/core/VersionMessage.java
View File

@@ -61,7 +61,7 @@ public class VersionMessage extends Message {
public PeerAddress theirAddr;
/**
* User-Agent as defined in <a href="https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki">BIP 14</a>.
* The official client sets it to something like "/Satoshi:0.9.1/".
* Bitcoin Core sets it to something like "/Satoshi:0.9.1/".
*/
public String subVer;
/**
@@ -92,7 +92,7 @@ public class VersionMessage extends Message {
clientVersion = params.getProtocolVersionNum(NetworkParameters.ProtocolVersion.CURRENT);
localServices = 0;
time = System.currentTimeMillis() / 1000;
// Note that the official client doesn't do anything with these, and finding out your own external IP address
// Note that the Bitcoin Core doesn't do anything with these, and finding out your own external IP address
// is kind of tricky anyway, so we just put nonsense here for now.
try {
// We hard-code the IPv4 localhost address here rather than use InetAddress.getLocalHost() because some

14
core/src/main/java/org/bitcoinj/core/Wallet.java
View File

@@ -114,8 +114,8 @@ public class Wallet extends BaseTaggableObject
// Spent: Transactions that appeared in the best chain but don't have any spendable outputs. They're stored here
// for history browsing/auditing reasons only and in future will probably be flushed out to some other
// kind of cold storage or just removed.
// Dead: Transactions that we believe will never confirm get moved here, out of pending. Note that the Satoshi
// client has no notion of dead-ness: the assumption is that double spends won't happen so there's no
// Dead: Transactions that we believe will never confirm get moved here, out of pending. Note that Bitcoin
// Core has no notion of dead-ness: the assumption is that double spends won't happen so there's no
// need to notify the user about them. We take a more pessimistic approach and try to track the fact that
// transactions have been double spent so applications can do something intelligent (cancel orders, show
// to the user in the UI, etc). A transaction can leave dead and move into spent/unspent if there is a
@@ -3506,7 +3506,7 @@ public class Wallet extends BaseTaggableObject
* attacks expensive.</p>
*
* <p>This is a constant fee (in satoshis) which will be added to the transaction. It is recommended that it be
* at least {@link Transaction#REFERENCE_DEFAULT_MIN_TX_FEE} if it is set, as default reference clients will
* at least {@link Transaction#REFERENCE_DEFAULT_MIN_TX_FEE} if it is set, as default Bitcoin Core will
* otherwise simply treat the transaction as if there were no fee at all.</p>
*
* <p>You might also consider adding a {@link SendRequest#feePerKb} to set the fee per kb of transaction size
@@ -3523,8 +3523,8 @@ public class Wallet extends BaseTaggableObject
*
* <p>This is a dynamic fee (in satoshis) which will be added to the transaction for each kilobyte in size
* including the first. This is useful as as miners usually sort pending transactions by their fee per unit size
* when choosing which transactions to add to a block. Note that, to keep this equivalent to the reference
* client definition, a kilobyte is defined as 1000 bytes, not 1024.</p>
* when choosing which transactions to add to a block. Note that, to keep this equivalent to Bitcoin Core
* definition, a kilobyte is defined as 1000 bytes, not 1024.</p>
*
* <p>You might also consider using a {@link SendRequest#fee} to set the fee added for the first kb of size.</p>
*/
@@ -3537,7 +3537,7 @@ public class Wallet extends BaseTaggableObject
public static Coin DEFAULT_FEE_PER_KB = Transaction.REFERENCE_DEFAULT_MIN_TX_FEE;
/**
* <p>Requires that there be enough fee for a default reference client to at least relay the transaction.
* <p>Requires that there be enough fee for a default Bitcoin Core to at least relay the transaction.
* (ie ensure the transaction will not be outright rejected by the network). Defaults to true, you should
* only set this to false if you know what you're doing.</p>
*
@@ -4396,7 +4396,7 @@ public class Wallet extends BaseTaggableObject
//
// This could be recursive, although of course because we don't have the full transaction
// graph we can never reliably kill all transactions we might have that were rooted in
// this coinbase tx. Some can just go pending forever, like the Satoshi client. However we
// this coinbase tx. Some can just go pending forever, like the Bitcoin Core. However we
// can do our best.
log.warn("Coinbase killed by re-org: {}", tx.getHashAsString());
killTxns(ImmutableSet.of(tx), null);

6
core/src/main/java/org/bitcoinj/crypto/TransactionSignature.java
View File

@@ -32,7 +32,7 @@ public class TransactionSignature extends ECKey.ECDSASignature {
/**
* A byte that controls which parts of a transaction are signed. This is exposed because signatures
* parsed off the wire may have sighash flags that aren't "normal" serializations of the enum values.
* Because Satoshi's code works via bit testing, we must not lose the exact value when round-tripping
* Because Bitcoin Core works via bit testing, we must not lose the exact value when round-tripping
* otherwise we'll fail to verify signature hashes.
*/
public final int sighashFlags;
@@ -75,14 +75,14 @@ public class TransactionSignature extends ECKey.ECDSASignature {
/**
* Returns true if the given signature is has canonical encoding, and will thus be accepted as standard by
* the reference client. DER and the SIGHASH encoding allow for quite some flexibility in how the same structures
* Bitcoin Core. DER and the SIGHASH encoding allow for quite some flexibility in how the same structures
* are encoded, and this can open up novel attacks in which a man in the middle takes a transaction and then
* changes its signature such that the transaction hash is different but it's still valid. This can confuse wallets
* and generally violates people's mental model of how Bitcoin should work, thus, non-canonical signatures are now
* not relayed by default.
*/
public static boolean isEncodingCanonical(byte[] signature) {
// See reference client's IsCanonicalSignature, https://bitcointalk.org/index.php?topic=8392.msg127623#msg127623
// See Bitcoin Core's IsCanonicalSignature, https://bitcointalk.org/index.php?topic=8392.msg127623#msg127623
// A canonical signature exists of: <30> <total len> <02> <len R> <R> <02> <len S> <S> <hashtype>
// Where R and S are not negative (their first byte has its highest bit not set), and not
// excessively padded (do not start with a 0 byte, unless an otherwise negative number follows,

10
core/src/main/java/org/bitcoinj/script/Script.java
View File

@@ -141,7 +141,7 @@ public class Script {
/** Returns the serialized program as a newly created byte array. */
public byte[] getProgram() {
try {
// Don't round-trip as Satoshi's code doesn't and it would introduce a mismatch.
// Don't round-trip as Bitcoin Core doesn't and it would introduce a mismatch.
if (program != null)
return Arrays.copyOf(program, program.length);
ByteArrayOutputStream bos = new ByteArrayOutputStream();
@@ -174,7 +174,7 @@ public class Script {
* <p>The reason for this split, instead of just interpreting directly, is to make it easier
* to reach into a programs structure and pull out bits of data without having to run it.
* This is necessary to render the to/from addresses of transactions in a user interface.
* The official client does something similar.</p>
* Bitcoin Core does something similar.</p>
*/
private void parse(byte[] program) throws ScriptException {
chunks = new ArrayList<ScriptChunk>(5); // Common size.
@@ -640,7 +640,7 @@ public class Script {
* <p>Whether or not this is a scriptPubKey representing a pay-to-script-hash output. In such outputs, the logic that
* controls reclamation is not actually in the output at all. Instead there's just a hash, and it's up to the
* spending input to provide a program matching that hash. This rule is "soft enforced" by the network as it does
* not exist in Satoshis original implementation. It means blocks containing P2SH transactions that don't match
* not exist in Bitcoin Core. It means blocks containing P2SH transactions that don't match
* correctly are considered valid, but won't be mined upon, so they'll be rapidly re-orgd out of the chain. This
* logic is defined by <a href="https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki">BIP 16</a>.</p>
*
@@ -746,7 +746,7 @@ public class Script {
private static boolean castToBool(byte[] data) {
for (int i = 0; i < data.length; i++)
{
// "Can be negative zero" -reference client (see OpenSSL's BN_bn2mpi)
// "Can be negative zero" - Bitcoin Core (see OpenSSL's BN_bn2mpi)
if (data[i] != 0)
return !(i == data.length - 1 && (data[i] & 0xFF) == 0x80);
}
@@ -1492,7 +1492,7 @@ public class Script {
}
}
// We uselessly remove a stack object to emulate a reference client bug.
// We uselessly remove a stack object to emulate a Bitcoin Core bug.
byte[] nullDummy = stack.pollLast();
if (verifyFlags.contains(VerifyFlag.NULLDUMMY) && nullDummy.length > 0)
throw new ScriptException("OP_CHECKMULTISIG(VERIFY) with non-null nulldummy: " + Arrays.toString(nullDummy));

2
core/src/main/java/org/bitcoinj/store/DatabaseFullPrunedBlockStore.java
View File

@@ -562,7 +562,7 @@ public abstract class DatabaseFullPrunedBlockStore implements FullPrunedBlockSto
// Set up the genesis block. When we start out fresh, it is by
// definition the top of the chain.
StoredBlock storedGenesisHeader = new StoredBlock(params.getGenesisBlock().cloneAsHeader(), params.getGenesisBlock().getWork(), 0);
// The coinbase in the genesis block is not spendable. This is because of how the reference client inits
// The coinbase in the genesis block is not spendable. This is because of how Bitcoin Core inits
// its database - the genesis transaction isn't actually in the db so its spent flags can never be updated.
List<Transaction> genesisTransactions = Lists.newLinkedList();
StoredUndoableBlock storedGenesis = new StoredUndoableBlock(params.getGenesisBlock().getHash(), genesisTransactions);

6
core/src/main/java/org/bitcoinj/utils/BlockFileLoader.java
View File

@@ -31,14 +31,14 @@ import java.util.List;
import java.util.NoSuchElementException;
/**
* <p>This class reads block files stored in the reference/Satoshi client format. This is simply a way to concatenate
* <p>This class reads block files stored in the Bitcoin Core format. This is simply a way to concatenate
* blocks together. Importing block data with this tool can be a lot faster than syncing over the network, if you
* have the files available.</p>
*
* <p>In order to comply with Iterator&lt;Block>, this class swallows a lot of IOExceptions, which may result in a few
* blocks being missed followed by a huge set of orphan blocks.</p>
*
* <p>To blindly import all files which can be found in a reference client (version >= 0.8) datadir automatically,
* <p>To blindly import all files which can be found in Bitcoin Core (version >= 0.8) datadir automatically,
* try this code fragment:<br>
* BlockFileLoader loader = new BlockFileLoader(BlockFileLoader.getReferenceClientBlockFileList());<br>
* for (Block block : loader) {<br>
@@ -47,7 +47,7 @@ import java.util.NoSuchElementException;
*/
public class BlockFileLoader implements Iterable<Block>, Iterator<Block> {
/**
* Gets the list of files which contain blocks from the Satoshi client.
* Gets the list of files which contain blocks from Bitcoin Core.
*/
public static List<File> getReferenceClientBlockFileList() {
String defaultDataDir;

2
core/src/main/java/org/bitcoinj/wallet/DefaultRiskAnalysis.java
View File

@@ -120,7 +120,7 @@ public class DefaultRiskAnalysis implements RiskAnalysis {
}
/**
* <p>Checks if a transaction is considered "standard" by the reference client's IsStandardTx and AreInputsStandard
* <p>Checks if a transaction is considered "standard" by Bitcoin Core's IsStandardTx and AreInputsStandard
* functions.</p>
*
* <p>Note that this method currently only implements a minimum of checks. More to be added later.</p>

2
core/src/test/java/org/bitcoinj/core/AlertMessageTest.java
View File

@@ -42,7 +42,7 @@ public class AlertMessageTest {
@Test
public void deserialize() throws Exception {
// A CAlert taken from the reference implementation.
// A CAlert taken from Bitcoin Core.
// TODO: This does not check the subVer or set fields. Support proper version matching.
final byte[] payload = HEX.decode("5c010000004544eb4e000000004192ec4e00000000eb030000e9030000000000000048ee00000088130000002f43416c6572742073797374656d20746573743a2020202020202020207665722e302e352e3120617661696c61626c6500473045022100ec799908c008b272d5e5cd5a824abaaac53d210cc1fa517d8e22a701ecdb9e7002206fa1e7e7c251d5ba0d7c1fe428fc1870662f2927531d1cad8d4581b45bc4f8a7");
AlertMessage alert = new AlertMessage(params, payload);

2
core/src/test/java/org/bitcoinj/core/BlockTest.java
View File

@@ -56,7 +56,7 @@ public class BlockTest {
@Test
public void testWork() throws Exception {
BigInteger work = params.getGenesisBlock().getWork();
// This number is printed by the official client at startup as the calculated value of chainWork on testnet:
// This number is printed by Bitcoin Core at startup as the calculated value of chainWork on testnet:
//
// SetBestChain: new best=00000007199508e34a9f height=0 work=536879104
assertEquals(BigInteger.valueOf(536879104L), work);

6
core/src/test/java/org/bitcoinj/core/BloomFilterTest.java
View File

@@ -42,7 +42,7 @@ public class BloomFilterTest {
filter.insert(HEX.decode("b9300670b4c5366e95b2699e8b18bc75e5f729c5"));
assertTrue(filter.contains(HEX.decode("b9300670b4c5366e95b2699e8b18bc75e5f729c5")));
// Value generated by the reference client
// Value generated by Bitcoin Core
assertTrue(Arrays.equals(HEX.decode("03614e9b050000000000000001"), filter.bitcoinSerialize()));
}
@@ -61,7 +61,7 @@ public class BloomFilterTest {
filter.insert(HEX.decode("b9300670b4c5366e95b2699e8b18bc75e5f729c5"));
assertTrue(filter.contains(HEX.decode("b9300670b4c5366e95b2699e8b18bc75e5f729c5")));
// Value generated by the reference client
// Value generated by Bitcoin Core
assertTrue(Arrays.equals(HEX.decode("03ce4299050000000100008002"), filter.bitcoinSerialize()));
}
@@ -86,7 +86,7 @@ public class BloomFilterTest {
BloomFilter filter = wallet.getBloomFilter(wallet.getBloomFilterElementCount(), 0.001, 0);
// Value generated by the reference client
// Value generated by Bitcoin Core
assertTrue(Arrays.equals(HEX.decode("082ae5edc8e51d4a03080000000000000002"), filter.bitcoinSerialize()));
}
}

4
core/src/test/java/org/bitcoinj/core/ECKeyTest.java
View File

@@ -388,7 +388,7 @@ public class ECKeyTest {
@Test
public void testCanonicalSigs() throws Exception {
// Tests the canonical sigs from the reference client unit tests
// Tests the canonical sigs from Bitcoin Core unit tests
InputStream in = getClass().getResourceAsStream("sig_canonical.json");
// Poor man's JSON parser (because pulling in a lib for this is overkill)
@@ -409,7 +409,7 @@ public class ECKeyTest {
@Test
public void testNonCanonicalSigs() throws Exception {
// Tests the noncanonical sigs from the reference client unit tests
// Tests the noncanonical sigs from Bitcoin Core unit tests
InputStream in = getClass().getResourceAsStream("sig_noncanonical.json");
// Poor man's JSON parser (because pulling in a lib for this is overkill)

2
core/src/test/java/org/bitcoinj/core/FilteredBlockAndPartialMerkleTreeTests.java
View File

File diff suppressed because one or more lines are too long

4
core/src/test/java/org/bitcoinj/core/PeerGroupTest.java
View File

@@ -726,9 +726,9 @@ public class PeerGroupTest extends TestWithPeerGroup {
@Test
public void preferLocalPeer() throws IOException {
// Because we are using the same port (8333 or 18333) that is used by Satoshi client
// Because we are using the same port (8333 or 18333) that is used by Bitcoin Core
// We have to consider 2 cases:
// 1. Test are executed on the same machine that is running full node / Satoshi client
// 1. Test are executed on the same machine that is running a full node
// 2. Test are executed without any full node running locally
// We have to avoid to connecting to real and external services in unit tests
// So we skip this test in case we have already something running on port params.getPort()

4
core/src/test/java/org/bitcoinj/core/WalletTest.java
View File

@@ -549,7 +549,7 @@ public class WalletTest extends TestWithWallet {
}
// Intuitively you'd expect to be able to create a transaction with identical inputs and outputs and get an
// identical result to the official client. However the signatures are not deterministic - signing the same data
// identical result to Bitcoin Core. However the signatures are not deterministic - signing the same data
// with the same key twice gives two different outputs. So we cannot prove bit-for-bit compatibility in this test
// suite.
@@ -611,7 +611,7 @@ public class WalletTest extends TestWithWallet {
assertEquals(Coin.valueOf(0, 90), bigints[3]);
// And we do it again after the catchup.
Transaction send2 = wallet.createSend(new ECKey().toAddress(params), valueOf(0, 10));
// What we'd really like to do is prove the official client would accept it .... no such luck unfortunately.
// What we'd really like to do is prove Bitcoin Core would accept it .... no such luck unfortunately.
wallet.commitTx(send2);
sendMoneyToWallet(send2, AbstractBlockChain.NewBlockType.BEST_CHAIN);
assertEquals(Coin.valueOf(0, 80), wallet.getBalance());

2
core/src/test/java/org/bitcoinj/script/ScriptTest.java
View File

@@ -381,7 +381,7 @@ public class ScriptTest {
valid = false;
}
// The reference client checks this case in CheckTransaction, but we leave it to
// Bitcoin Core checks this case in CheckTransaction, but we leave it to
// later where we will see an attempt to double-spend, so we explicitly check here
HashSet<TransactionOutPoint> set = new HashSet<TransactionOutPoint>();
for (TransactionInput input : transaction.getInputs()) {