What can xxxCoin do to stop the impending 51% attack? Within the coming weeks both Namecoin and SolidCoin have been threatened with the same attack. What can be done by the users, pool operators and developers of these forks to either;

A. Minimise damage.

B. Stop it altogether.

There are two basic fronts on which they can defend, and they really do have to do both.

First, they need to increase their total hashing power. 51% of a very large number is much harder for an attacker to muster than 51% of a small number. Merged mining is probably the most realistic way for these currencies to accomplish this.

Second, they need to fix specific vulnerabilities in their difficulty adjusting algorithms. Some of these attacks requires less than 51% of the hashing power or do more damage than they should because of specific weaknesses in the difficulty-adjusting algorithm.

Alternative currencies are vulnerable to hash rate decrease attacks. To resist them, they've adjusted their difficulty algorithms so that difficulty can drop rapidly. Unfortunately, these algorithms have been found to have unexpected defects. Because strict timestamp accuracy can't be enforced, an attacker can maliciously inject false timestamps into mined blocks to cause the difficulty to drop very, very quickly. This allows a malicious group of coordinated miners to extract a very large number of coins in a very small period of time with relatively little hashing power.

Effort will be needed to fix these algorithms so that they still provide protection against a hash rate decrease attack but don't create even more serious new vulnerabilities.

It may well be a rocky road these next few weeks. The 51% attack is fundamental to the decentralized nature of these currencies -- the only solution is more hashing power. But the difficulty algorithm attack issues will likely be solved by fixing the algorithms.


Bitcoin Core for ARM-based Macs? Should we expect in the foreseeable future a Bitcoin Core release optimised for ARM-based Macs?

Of course. QT, the GUI framework Bitcoin Core uses, is one of the most portable GUI frameworks. Sooner or later, Apple Silicon support will be added. Meanwhile you can track the progress here: https://bugreports.qt.io/browse/QTBUG-85279
Then Core developers will do the rest: https://github.com/bitcoin/bitcoin/issues/20371


Is it possible to schedule a transaction in the future? Wondering if it's technically possible to set up a transaction to be sent in the future, for example 6 months? Is this related to block timestamps parameters? Transaction timestamps?

Yes, there is tx.nLockTime. A transaction mined before its nLockTime is invalid, so you can send your funds to yourself on some newly created address, then send it back with a locktime and destroy the private key for the newly created address.  Transactions with nLockTime can be amended, but since you destroyed the private key, you actually can't, thus preventing them from being spent before that time has passed.

See here, here, or here.

Note that nLockTime transactions may not be stored/relayed by the network. So you need to keep the transaction in a safe place and broadcast it at the right time.


Best Practice for Using Btc I have recently learned about best practice for storing private keys with hardware wallets. I understand the necessary information including backups from seed phrases, the concept of cold storage, safely storing seed phrases, and having multiple HD wallets incase one goes missing, etc.
Ok. But now, I want to actually use bitcoin in the real world, because what better way to support btc than to actually use it!
So I want to have a wallet, preferably on my phone that I can use for quick and easy payments with friends and merchants in public. I plan to keep $100 or less on this account, similar to my debit account with my usual bank.
But I still want to do my best to be secure, and I don’t understand a lot of the vulnerabilities with my public keys being stored somewhere on my phone. Can someone please perhaps recommend a mobile based platform for btc transactions and outline the vulnerabilities and how I can avoid them? I understand that my hardware wallet is offline, what vulnerabilities come with my phone being online?
Example: I have heard people mention to never connect to public WiFi. How does this make me vulnerable? So when I leave the house should I disable WiFi? Are there any vulnerabilities with using 4g?

There is many wallets outhere, some of them open source that you could even compile and run into your device so you can audit the code if you don't want to trust the manufacturer.
My advice use the one you think or see works good (in my case https://blockstream.com/green/)
With the care you are proposing right now, having only what would spend.
I like to think that it's the same than having cash in our pockets, if you lose it you won't claim to anybody.
So create another separate wallet, feed it with sum funds from your hard wallet and enjoy safely. And remember to ALWAYS keep your private keys out of any connected device (at least the big wallet), never share it , never take a picture and so on.


How to compile Bitcoin-Qt as an .exe on Ubuntu? After struggeling with the dependencies for a while, I finally managed to compile Bitcoin-Qt on my Ubuntu machine. I used the following commandos for compiling:

./autogen.sh
./configure -with-gui
make
sudo make install

Now when I write bitcoin-qt in the terminal, the wallet will succesfully start. However, I am not able to locate bitcoin-qt.exe on my computer. I want to be able to get the .exe and put it on other machines without having to install all the dependencies on them as well. How would I go about creating this .exe?

.exe files are for windows only. Linux systems do not use the same file extension or file type as windows. I assume you just want to create a Linux binary that can be used on all systems without installing all dependencies. To do that, you can use Bitcoin Core's depends system. Instructions are here: https://github.com/bitcoin/bitcoin/tree/master/depends.

Basically, all you need to do is (starting from the source root directory):

cd depends
make
cd ..
./configure --prefix=`pwd`/depends/x86_64-linux-gnu # Actually check what folder is created in depends after you built the dependencies and use that instead
make

Once you do that, the binaries that are produced can be moved to and used on any linux system. The binaries are located at (from the source root dir) src/bitcoind, src/qt/bitcoin-qt, src/bitcoin-cli, and src/bitcoin-tx


manually signing bitcoin transaction I'm trying to create a BTC transaction with one input and two outputs, one for change and one OP_RETURN to anchor data. And I'm doing all of that on my regtest backend. The raw unsigned transaction is

01000000018be9d0e99e74d69d915e105db1328707f713d42a894909b18a78fe68e1d8290c0000000023210340165231215a98e7a32abce9d410ecd09ac505938b25f9451defa051d591ebf8acffffffff0218ee052a010000001976a9143eb52fb0be4be87edc74848b371547f663e26c7e88ac0000000000000000226a408973d6b447bdda5312b1ef1b5509668672296301dd328d4e55317def98f165d200000000

I can then use the bitcoin rpc to sign it and it works, so I'm pretty certain that this part is correct. When I however try to sign it manually I get the error

500: {"result":null,"error":{"code":-26,"message":"16: mandatory-script-verify-flag-failed (Non-canonical DER signature)"},"id":2}

I've followed the steps outlined in How to redeem a basic Tx? as well as Signing a raw transaction with Python ECDSA (or OpenSSL) as well as attempted to use pybitcointools to sign the input without success.

The address and private key I use are

addr: "mmEXEzUGcMmmiLsfxxM8gB8TQSTkuR1drf"
pk:  "cTyF9pebH3kwwzUt5gzaxSDQ1DbqYfx4P1i4d1TyjtSDEeUFgYsk"

and stragely, even though the PK is the one given to me by ./bitcoin-cli -regtest dumpprivkey <addr> does not seem to match the address and I'm not sure why or what it is I need to do to it (it's in WIF format and compressed, i.e. 0x01 appended to the end

The original TX includes the scriptPubKey of the utxo. I then double sha256 the whole raw tx (shown above) and replace the scriptPubKey part with the sigScript | pubkey using the following code:

private_key, compressed_pk = wif_to_private_key(private_key_wif)
tx = bytearray.fromhex(raw_unsigned_transaction) + int(1).to_bytes(4, 'little')

double_sha256_tx = hashlib.sha256(hashlib.sha256(tx).digest()).digest()
signing_key = ecdsa.SigningKey.from_string(bytearray.fromhex(private_key), curve=ecdsa.SECP256k1)
public_key = bytearray.fromhex(privtopub(private_key_wif))
signature = signing_key.sign_digest(double_sha256_tx, sigencode=ecdsa.util.sigencode_der) + int(1).to_bytes(1, 'little')
scriptSig = to_varstr(signature) + to_varstr(public_key)

to_varstr simply prints [len]|[data] and privtopub is the function from pybitcointools as I couldn't figure out how to go from the compressed private key to the address manually. It's worth noting though that the public_key here that privtoaddr from pybitcointools does not return the correct address either which might be the root cause of the issue?

I'd be grateful for any pointers or things to try

cheers
Chris

PS:
another interesting aspect is that the signed transaction I generate is a lot longer than the one generated by the signtransaction rpc call:

rpc:    01000000018be9d0e99e74d69d915e105db1328707f713d42a894909b18a78fe68e1d8290c0000000023210340165231215a98e7a32abce9d410ecd09ac505938b25f9451defa051d591ebf8acffffffff0218ee052a010000001976a9143eb52fb0be4be87edc74848b371547f663e26c7e88ac0000000000000000226a40ac4f0818b683eeeaa1fbf2f508af2fc22cc814e69025152c70d7c414ebbfc30a00000000
manual: 01000000018be9d0e99e74d69d915e105db1328707f713d42a894909b18a78fe68e1d8290c000000006b483045022100d6e538aa819f3162d5c6a0e4d9ee0323395df89e943c769d96ae939baec5c6920220083a311cb35df3c98d7a6bd0bc80d98a71fbdf8e325ba908ea4b721a4eac8bb301210343395a6e84c7f2b1d50c11f96783664a6f04d66b51befb3befcc57334e2a9abcffffffff0218ee052a010000001976a9143eb52fb0be4be87edc74848b371547f663e26c7e88ac0000000000000000226a40ac4f0818b683eeeaa1fbf2f508af2fc22cc814e69025152c70d7c414ebbfc30a00000000

I verified the keys on https://bitcoinpaperwallet.com/bitcoinpaperwallet/generate-wallet.html?design=alt-testnet#, and choose testnet on the first tab, and then the second tab (print front). They match, so good. Then I tried to decompose your line, where you say it is the signtransaction call. This seems to me unsigned:

 TX_IN[0] Script Sig (uchar[])
  210340165231215A98E7A32ABCE9D410ECD09AC505938B25F9451DEFA051D591EBF8AC
  ##################################################################
  ### tcls_in_sig_script.sh: decode SIG_script OPCODES from a TX ###
  ##################################################################
    21: OP_DATA_0x21:     type tag indicating LENGTH
    03: OP_INT_0x03
        40165231215A98E7:A32ABCE9D410ECD0
        9AC505938B25F945:1DEFA051D591EBF8
        AC
    * This terminates the Public Key (X9.63 COMPRESSED form)
    * corresponding bitcoin address is:
   mvVWbgb3sZeEz495eDoaem79Qi876zuG9S

whereas the second line (manual) looks good:

 TX_IN[0] Script Sig (uchar[])
  483045022100D6E538AA819F3162D5C6A0E4D9EE0323395DF89E943C769D96AE939BAEC5C6920220083A311CB35DF3C98D7A6BD0BC80D98A71FBDF8E325BA908EA4B721A4EAC8BB301210343395A6E84C7F2B1D50C11F96783664A6F04D66B51BEFB3BEFCC57334E2A9ABC
  ##################################################################
  ### tcls_in_sig_script.sh: decode SIG_script OPCODES from a TX ###
  ##################################################################
    48: OP_DATA_0x48:     push hex 48 (decimal 72) bytes as data
    30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
    45: OP_LENGTH_0x45:   length of R + S
    02: OP_INT_0x02:      type tag indicating INTEGER
    21: OP_LENGTH_0x21:   this is SIG R
        00D6E538AA819F31:62D5C6A0E4D9EE03
        23395DF89E943C76:9D96AE939BAEC5C6
        92
    02: OP_INT_0x02:      type tag indicating INTEGER
    20: OP_LENGTH_0x20:   this is SIG S
        083A311CB35DF3C9:8D7A6BD0BC80D98A
        71FBDF8E325BA908:EA4B721A4EAC8BB3
    01: OP_SIGHASHALL:    this terminates the ECDSA signature (ASN1-DER structure)
    #########################################################
    ### procedure to strictly check DER-encoded signature ###
    #########################################################
    Minimum and maximum size constraints                        - ok
    scriptsig always starts with 0x30                           - ok
    length 138 chars is less than actual sig length (144 chars) - ok
           (hex 0x45, decimal 69, 138 chars)
    length of R coordinate (66) >= 0                            - ok
    length of S coordinate (64) >= 0                            - ok
    S-Value is within scriptsig boundaries                      - ok
    Make sure the R & S length covers the entire signature      - ok
    S-value must be smaller than N/2                            - ok
    strictly check DER-encoded signature                        - ok
    #########################################################
    21: OP_DATA_0x21:     type tag indicating LENGTH
    03: OP_INT_0x03
        43395A6E84C7F2B1:D50C11F96783664A
        6F04D66B51BEFB3B:EFCC57334E2A9ABC

    * This terminates the Public Key (X9.63 COMPRESSED form)
    * corresponding bitcoin address is:
   mmEXEzUGcMmmiLsfxxM8gB8TQSTkuR1drf

so also all DER checking of the siggnature is ok. However I see the address being different, effectivly it is the output address, isn't it?
Maybe you mixed up some addresses while signing manually?
What is the address you are spending from?


What indexes does a Bitcoin Core node maintain to serve Bloom-filtered requests and SPV peers? The Wiki makes this statement:

  It [getdata message] can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not). [my emphasis]

https://en.bitcoin.it/wiki/Protocol_documentation#getdata

Yet "Connection Bloom filtering" (BIP-37) seems to require just such an index system:

  The filter can be tested against arbitrary pieces of data, to see if that data was inserted by the client. Therefore the question arises of what pieces of data should be inserted/tested.

  To determine if a transaction matches the filter, the following algorithm is used. Once a match is found the algorithm aborts.

An ordered list of criteria is then given.

It appears that a node supporting such a filter would also need to maintain an index (or several), or risk denial of service attacks.

I saw this question:

70% of nodes accept Bloom filters, despite DoS attack vector?

which doesn't appear to answer the question about indexes.

I saw this question:

Is there a way to index transactions so that filterload commands can be answered without iterating through all transactions in a block?

the only answer to which implies, without stating explicitly, that no indexes are created at all.

What indexes does a node create for the sole purpose of supporting Bloom filtering for SPV nodes?

If none are created and transactions are filtered on the fly, how can this statement in the linked question above be true?

  Thus you can easily trigger exactly the same DoS attack by just using regular getdata requests on large blocks over and over. You don't need Bloom filtering. If you don't want to actually download the blocks just don't TCP ACK the packets and then FIN after a few seconds .... the data will all have been loaded and be sitting in the send buffers.

Bitcoin Core maintains an index of blocks and their locations on disk. When someone requests a block, it pulls the block from disk, and if they used BIP 37, it will run the block through the filter. The block index is required for normal node operation; there are no other indexes created. The only "index" like thing is the mempool, and that is maintained solely in memory. That is where transactions come from if they are requested; confirmed transactions will not be in the mempool and cannot be relayed.

For BIP 37, things are only tested against the filter prior to being relayed to a node that had set a filter. The only things that will ever be relayed are unconfirmed transactions and entire blocks.

  If none are created and transactions are filtered on the fly, how can this statement in the linked question above be true?

The statement is true because a node can set a filter and request blocks and unconfirmed transactions from the node. The node will then pass those blocks and transactions through the filter before relaying them.


Does block validation get more difficult as the blockchain grows? I just downloaded Bitcoin 0.5 and started downloading the blockchain from scratch. The process was rather fast early on but slowed down noticeably later. That could of course be related to network conditions (or I could be mistaken altogether), but it got me thinking if the cost of block validation (which apparently is the driving factor in determining how long importing new blocks takes) somehow depends on the length of the chain before it?

Validating hashes and signatures for transactions is the most costly process. So the amount of time it takes for CPU to verify a block depends on number of transactions in the block.

Number of transactions per block tends to increase as bitcoin economy grows, therefore it takes longer to verify more recent blocks.


Who is a first miner that receive a transaction from end-user? This is a First Question.
As you already know, the blockchain like Bitcoin, Ethereum is a software program based on peer to peer network system. so I am wondering that who is a first miner that receive a transaction from end-user that create a transaction such as bitcoin-core program.

This is a Second Question.
I know that SPV node are End-users that use wallet program such as Bitcoin-core.
End-user is a just SPV node that can't verify some transactions and provide information to full-node to quickly find transaction.

Does End-user has full-node list to provide hint of transaction information ?
If answer of above question is yes, how they know full-node? where is source of full-node list?

Sorry for my English.

who is a first miner that receive a transaction

Each full-node ends up sharing information with a small number of other active full-nodes. I believe there is a node discovery process primed by an initial list hardcoded into the node software. The nodes thus form a dynamic self-organising network with multiple hops between distantly connected nodes. Which miner first receives a transaction therefore depends somewhat on where the transaction originated. It is effectively somewhat random, or at least undirected.

  SPV node are End-users that use wallet program such as Bitcoin-core

I believe Bitcoin core is a full-node not SPV. Electrum is an example of an SPV node.

  Does End-user has full-node list

No

Note that an SPV node is a lightweight node which does not have a copy of the full Blockchain, a journal (list) of all transactions. SPV nodes effectively  ask other nodes they know about to verify transactions for them.

Bitcoin nodes do not need a list of all other nodes, only of a few nodes nearby (in a topological sense).

See How do Bitcoin clients find each other?

  how SPV node can provide transaction information to full-node without full-node list

By telling an interesting fact to three friends who each talk to three of their friends who all talk to three of their friends  (and so on), you can start a rumour that spreads across a school, across a city or to millions of people across the planet.


Loading wallet crashes bitcoin core wallet When trying to load a wallet I last used in 2017 December, in bitcoin core wallet 0.21.0 x64, the UI exits abruptly, last few lines in the debug.log shows the following:
2021-02-10T07:20:22Z Using wallet d:\btdata\dijitalparaciklar.dat
2021-02-10T07:20:22Z BerkeleyEnvironment::Open: LogDir=d:\btdata\database ErrorFile=d:\btdata\db.log
2021-02-10T07:20:22Z init message: Loading wallet...
2021-02-10T07:20:23Z [dijitalparaciklar.dat] Wallet File Version = 130000
2021-02-10T07:20:23Z [dijitalparaciklar.dat] Keys: 0 plaintext, 214 encrypted, 214 w/ metadata, 214 total. Unknown wallet records: 0
2021-02-10T07:20:23Z [dijitalparaciklar.dat] Wallet completed loading in 175ms
2021-02-10T07:20:23Z init message: Rescanning...
2021-02-10T07:20:23Z [dijitalparaciklar.dat] Rescanning last 173423 blocks (from block 496540)...
2021-02-10T07:20:23Z [dijitalparaciklar.dat] Rescan started from block 0000000000000000009e546a2183eb90aea183bd153f2d7b3c34f67b4aa6abc5...
2021-02-10T07:20:23Z [dijitalparaciklar.dat] AddToWallet 0f1162a63b3ae14a3bc8907f8edbb57e392fc5dfadfe866de0eb5d470f7504df
2021-02-10T07:20:25Z New outbound peer connected: version: 70015, blocks=669964, peer=2 (full-relay)

Windows records the crash as follows:
Faulting application name: bitcoin-qt.exe, version: 0.21.0.0, time stamp: 0x00000000
Faulting module name: bitcoin-qt.exe, version: 0.21.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x000000000038ca40
Faulting process id: 0x5128
Faulting application start time: 0x01d6ff7aa101f703
Faulting application path: D:\Bitcoin\bitcoin-qt.exe
Faulting module path: D:\Bitcoin\bitcoin-qt.exe
Report Id: 49909fad-f4bd-4f8c-9423-a585cbeaba86
Faulting package full name:
Faulting package-relative application ID:
Any ideas why this could be happening? db.log is empty btw..

Check this file: ErrorFile=d:\btdata\db.log
Errors are logged in there. You are viewing the debug logs which will not print any error.


Why "Open Transactions cannot lie on your receipt"? FellowTraveller claimed here that :

  OT cannot lie on your receipt. It cannot change your balance or forge
  any of your transactions. (Bitcoin also is like this, but it's still
  worth mentioning.) Combined with an auditing protocol, this makes it
  possible to run low-trust servers.

Can anyone elaborate on this? What prevents the operator of an OT server from changing balances and forging transactions?

It is not possible for the OT server to forge your signature because you retain the private key. Sure, it could issue fakes but anyone actually checking the signature would immediately see that it is incorrect and reject the transaction.


How can I start development in Bitcoin? How can I start development in Bitcoin?
I am a software engineer and i am interested in development and programming part of bitcoin. A little guidance would be appreciated.

I think you should start by getting the source code of the official client:

https://github.com/bitcoin/bitcoin

You will find introductory information in the Readme.
Once you will have a clear view of what you want to do, you can play with the code by creating your own branch.

Note that, improvements and other changes in bitcoin are tracked by the BIP system: https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals
Also, you should get familiar with the concept of soft/hard forks.

Refer to the https://bitcoin.org website, where you can find all the basic documentation (e.g. https://bitcoin.org/en/developer-reference)

That said, you will soon find out that many technical details are not well documented (or even not documented at all). The only comprehensive way of understanding how it works is, as with many other complex programs, to read the source code. Also, IMHO, a good understanding of the basic blockchain concepts is strongly recommended.

Other useful docs: https://bitcoin.org/en/developer-documentation


Get wallet address when creating wallet with blockchain API Using the API endpoint http://localhost:3000/api/v2/create I get this response:

{"guid":"58671a54-7d60-4319-8742-b06fb2a8d060","address":"xpub6CzAMijBVeK5qBxbXc2i4NyGbvr9wLRTJWf58f3mdv7Lb2eeo6Uz9UKq7ntTDdvfDgH6MhuuLJgCAWcto1BX9TA3wpaKU9vomML8MfvdZUD"}

It seems to be returning an extended public key rather than an address, how can I get the wallet address to accept payments?

I've not used this myself, but it does look like the behaviour you're seeing is different to the official documentation and the  documentation on GitHub. You are getting the xpub of an HD Wallet in the response, instead of a standalone address. Which version did you install, and what does the documentation that come with it say? Are you passing any parameters to create that you didn't list in the question?


JavaScript Mining System Design How do I verify a unconfirmed transaction using JavaScript ?

It is not possible to verify just a single transaction, without knowing the state of the network. To know the state of the network, you must verify all of it's historical transactions (aka, run a full node).

So this means it is not possible to just take a single transaction alone, and verify it using some bit of code. Rather, you will need the entire history of transactions, so that you can determine whether the transaction is valid in relation to the current state of the network (ie, does the person who is attempting to spend some coins rightfully own them?).

There are various implementations of a bitcoin node available, written in various languages. You'll want to find one that you can interact with programmatically using javascript.

EDIT: I now see you seem to be asking about building some mining software. My answer above still holds true (you'll need a full node to determine the network state and create block templates), but otherwise I think your question (build mining software) is overly broad.


Is an extraction of the mnemonic string possible if wallet and corresponding passphrase are in possesion? My problem is that I have access to my wallet and I am able to access it with Electrum because I have the passphrase but I somehow misplaced the seed.

Is it possible to decrypt/extract and obtain the wallets mnemonic seed string with said access?

Any time donated towards this issue will be very appreciated.

From your Electrum toolbar click on "Wallet" and then select "Seed". A new window will open asking you to enter your password, do that correctly and you will see your seed words if you wallet has any (meaning if it is a standard HD wallet not an imported one).


0/unconfirmed and now no transactions anymore So recently (2days ago) I made this transaction:

Status: 0/unconfirmed, in memory pool
Date: 20.12.2017 23:30
To: N**** 1LecRzTpKXh9kCgqXbUXtdXfQjE145BR87
Debit: -0.00447735 BTC
Transaction fee: -0.00003840 BTC
Net amount: -0.00451575 BTC
Transaction ID: 850a72da35784c22c7fe1e39ac51cdc639923b26ab8bf7322f3cb7af4ffed263
Transaction total size: 191 bytes
Output index: 0

As you can see, the Bitcoins weren't sent and according to the Transaction ID the transaction wasn't done, as you can see here:
https://live.blockcypher.com/btc/tx/850a72da35784c22c7fe1e39ac51cdc639923b26ab8bf7322f3cb7af4ffed263/

So now I started to look around in different posts to get my coins back.
I found a post with the same problem... it told me to start Bitcoin Core like this:

E:\Programme\Bitcoin\bitcoin-qt.exe -zapwallettxes

but now i dont see my transactions anymore and i have 0 BTC in my balance.

I have no clue what to do now and how I can get my BTCs again.

I have observed from other experts that if you 'abandon transaction' your data will eventually be forgotten by other nodes and return to your account. You can 'abandon transaction' from the GUI console in 'transactions' by right clicking on it and selecting 'abandon'. This might take some time as even one outdated node might re-broadcast it again and it will get picked up by other nodes. Patience is what I have read. From there delete mempool and restart.


replicating in python what the electrum wallet does during (deterministic) wallet creation I am trying to replicate in python what the Electrum wallet does during (deterministic) wallet creation. IMHO the docs are a bit sparse on this one bit maybe because its only performed once for most users, all the tutorials etc. seem to focus on the GUI, and I was unable to work out the python code from the spesmilo github for electrum.

From what I can see, Electrum generates a random Wallet Generation Seed

a 13-word mnemonic(or 12 words plus checksum?)
which is unencrypted This is also the Master Private Key?
Then the user enters a password/passphrase(or not) that encrypts the seed so it can be saved as a wallet(file)
The wallet file can only be decrypted with the password/passphrase
Then a Master Public Key is generated from the wallet [Anybody have more detail on this?].
Then the 25-byte binary Bitcoin Address =
{[MPK>sha256>RIPEMD160]+[MPK>sha256>RIPEMD160>versionByteadd>sha256>sha256>first4bytes]}
which in turn is Base58Check encoded to the Bitcoin Address format

Can someone please check if my assumptions (1 to 7) are okay/correct me?
Also, below is how far I got with python(probably grossly incorrect!):

from electrum import mnemonic
import ecdsa
import hashlib
import base58
import getpass

mnemonicInstance = mnemonic.Mnemonic(lang='en')
randseed = mnemonicInstance.make_seed()
print "this is my 13 word wallet gen seed" + randseed
private_key = mnemonicInstance.mnemonic_to_seed(randseed , getpass.getpass()).encode('hex')
print "this is my private key: " + private_key
#the line of code below failed!:
sk = ecdsa.SigningKey.from_string(private_key.decode("hex"), curve = ecdsa.SECP256k1)
vk = sk.verifying_key
public_key = ('\04' + vk.to_string()).encode("hex")
print "this is my public key: " + public_key
ripemd160 = hashlib.new('ripemd160')
ripemd160.update(hashlib.sha256(public_key.decode('hex')).digest())
middle_man = '\00' + ripemd160.digest()
checksum = hashlib.sha256(hashlib.sha256(middle_man).digest()).digest()[:4]
binary_addr = middle_man + checksum
addr = base58.b58encode(binary_addr)
print "this is my BTC address: " + addr

(some of the above lifted from Shultzi's github) I also consulted Andreas' Mastering Bitcoin but not had much joy with this bit.

Bip32 is the implementation of hierarchical deterministic wallets. This fully describes what you are discussing here. The full text of bip32 can be found https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
The mnemonic maps to specific bits for the encryption, the words themselves are not used. Read the bit about extending the keys it will also explain how the master public key is generated.  It also explains the three derivations that can be made from the public and private keys which are:

Parent private key -> child private key

Parent private key -> child public key

Parent public key -> child public key

It is worth noting the child private key cannot be generated from the parent public key.


Imported Multibit HD wallet into electrum - Bitcoins are gone! I got locked out of my multibit HD wallet and couldn't restore it with the seed phrase (even though it said they're valid) so I installed electrum and used the seed words to import the wallet. It worked but the bitcoins have disappeared. Is there a way I can recover them?

Try restoring again. To do that you have to create a new wallet file via file > new/restore, enter a unique filename and click next. Then be mindful of the following things:

On the seed entry step click on options and check bip39. Pay attention to the message next to the options button in this step. When it says bip39 checksum OK you can proceed to the next step.
In the next step enter a derivation path of m/0' . That’s a zero and a single quote.


I'm digging further into the open Taproot PR. Can you explain the bip340_test_vectors? I'm digging further into the open Taproot PR. I found these bip340_test_vectors.
They have secret keys, public keys, aux_rand (auxiliary randomness), message, signature and whether the signature verifies or not. Can you explain why the signatures that fail are failing?

These bip340_test_vectors are used in two places: the unit tests (src/test/key_tests.cpp) and the functional tests (test/functional/test_framework/key.py).
The Python code for testing the bip340_test_vectors is here.
There are 15 test cases in all but only 4 distinct secret keys, 7 distinct public keys (3 of them don't have secret keys) and 15 distinct signatures.
The public key DFF1D77F2A671C5F36183726DB2341BE58FEAE1DA2DECED843240F7B502BA659 is reused 9 times for example but the distinct signatures are generated using different messages, auxiliary randomness etc.
The first five test cases have valid signatures (a verification result of TRUE) although the fourth test case (index = 3) has a comment of test fails if msg is reduced modulo p or n (I'm not sure what this means)
That leaves the remaining test cases that fail the signature verification:
The elliptic curve that BIP 340 signatures are defined upon is secp256k1 (the same curve that we use for ECDSA) which is:
y2 = x3 + 7 (mod p)
where the field size p = 2256 - 232 - 977 or
p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F in hex and is prime.
The generator point G (on the curve) that we use is (Gx, Gy) where
Gx=0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
Gy=0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
The curve order of secp256k1 is:
n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
(The curve order n is such that nG = point at infinity. Every n times we cycle back to the point at infinity. The point at infinity is defined here. It is not on the curve and is defined by (x,y) + (x,-y) = infinity.)
The public key P (point) associated with a secret (private) key is calculated using:
P = d (mod n).G
where d is the private key (scalar) and G is the generator point (point).
A BIP 340 Schnorr signature is a 64 byte array (Rx , s).
The first 32 bytes is the X coordinate of R.
R = k'⋅G
R is a point (Rx, Ry)
k' is randomness (mod n) as specified by BIP 340
G is the generator point defined earlier
The second 32 bytes is the s that satisfies:
s⋅G = R + H(r | pk | m)⋅P (mod n)
This can be written as s.G = R + e.P where e = H(r | pk | m)
Or alternatively s = k' + e.d where d is the private key (scalar).
G is the generator point defined earlier (point)
R is calculated earlier (point)
H is the hash function (function)
r is the the X coordinate of R, Rx  (scalar)
pk is the X coordinate of the public key P, Px (scalar)
m is the message (scalar). The message in Bitcoin's case is the part of the Bitcoin transaction that needs to be signed according to the SIGHASH flag.
P is the public key (point)
Index 5 has a public key that is not on the secp256k1 curve that Bitcoin uses. The public key is calculated by multiplying the private key (scalar) by the generator point and so it must be on the elliptic curve. If it isn't it is not possible to generate a valid signature. Indeed the secret key is not provided for this public key as there is no secret key that can multiply with the generator point to get the public key.
Index 6 is referring to the BIP 340 design choice to implicitly choose the Y coordinate that is even (each valid X coordinate has two possible Y coordinates, one that is odd and one that is even). If the Y coordinate is odd then it is not following the BIP 340 specification and the signature verification should fail.
Index 7 uses a negated message to verify a signature of an original message. Negated means taking the complement with the group order n. The signature won't be valid if you verify it using the negated message rather than the actual message used in the signature.
-m = n-m (mod n)
Obviously there are no actual "negative" numbers in the ring of integers (mod n).
Index 8 has a negated s value. See Index 7 for the definition of negated. If you validate with a negated s rather than the initial s the signature validation will fail.
Index 9 states R = sG - eP is infinite and that the test fails if has_even_y(inf) is TRUE and x(inf)=0. The point at infinity is not on the curve, has no coordinates at all but implementations need a representation of it. If an implementation uses (0,0) as the point at infinity then this test will fail if has_even_y returns TRUE (which it shouldn't) and x(inf) returns 0.
Index 10 states R = sG - eP is infinite.
Index 11 states sig[0:32] is not an X coordinate on the curve. If the first 32 bytes of the BIP 340 Schnorr signature is not an X coordinate on the elliptic curve then this is not a valid signature.
Index 12 also refers to first 32 bytes of the signature. But this time the 32 bytes are equal to the field size of the curve p. This is not possible under mod p (all values must be between 0 and p-1) so no valid signature is possible here.
Index 13 refers to the second 32 bytes of the 64 byte signature. s can't be equal to the curve order n because it is defined mod n which means it can only take a value between 0 and n-1.
Index 14 has a public key with a X coordinate that exceeds the field size (p = 2^256 - 2^32 - 977). This is not possible under mod p (all values must be between 0 and p-1) so no valid signature is possible here.
(Jimmy Song's Chapter 3 on Elliptic Curve Cryptography of his book Programming Bitcoin is helpful for explaining the secp256k1 curve. It was published before BIP 340 was finalized and so only covers ECDSA signatures, not Schnorr signatures. For an introduction to Schnorr signatures see Elichai Turkel's presentation at Chaincode Labs or this London BitDevs Socratic Seminar on BIP 340)
Thanks to Pieter Wuille and Jonas Nick for suggested edits on the initial post.


What is the smallest possible size of a bid/ask on Mt.Gox? I've successfully done .01 of a bitcoin for both bid and ask, but I'm wondering if someone knows the real limit?

I cant seem to find it in their documentation.

From the (unofficial) MtGox API documentation:

The minimum trade size to buy OR sell is 0.01 BTC


Where can I find some reputable resellers of Casascius.Physical Bitcoins? Casacsius stopped selling physical bitcoins directly on April 1st 2013, and instead refers people to resellers.

Where can I find some reputable resellers?

Casascius has resumed selling individual and rolls of coins on the official website, https://www.casascius.com/. Individual coins will be sold for a limited time only.

It is still possible to save money on individual coins by buying through resellers.


Does it Cost Money to Issue Digital Certificates on the Bitcoin Blockchain? I'm reading through this Github Repo from Blockcerts.org on how to issue digital certificates on the bitcoin blockchain.

What is confusing me is whether or not each issuing each digital certificate in this manner costs money.

On one hand, I've read through the high-level Blockcerts documentation and blogs and haven't seen any reference to financial costs to issuing certificates on the bitcoin blockchain.

On the other hand, in the cert-issuer repo it notes in the "Transaction Structure" of "How Batch Issuing Works", the issuer needs a minimal amount of Bitcoin to create the transaction. At the very least, this is a fixed cost.

Additionally, in the documentation we see:

  Ensure you've transfered a small amount of coin to your issuing
  address. Note that each certificate costs 12750 satoshi

and

  Make sure you have enough BTC in your issuing address. ($0.08 USD)

So, it sounds like each certificate costs about $0.30 to issue? Just want to make sure I understand correctly.

(Please note, I am totally new to blockchain, so apologies if this is a dumb/obvious question).

(I'm a Blockcerts developer)

Andrew is right -- that is simply the transaction fee. That fee is the same no matter the number of certificates in the batch for Blockcerts issuing.

I note that the documentation you're referring to is out of date, so I updated it just now to add more current fee information and to clarify how to determine the transaction fee.

Updates:

Ensure you've transferred sufficient funds to your issuing address to cover the transaction fee.

The transaction fee is the same no matter the number of certificates in the batch.
The default transaction fee used by cert-issuer is 60,000 satoshis (~$1.50 USD, 7/3/2017).
Because the transaction fee is a factor in confirmation time, you may decide to increase or decrease this value in the config file (read more about current transaction fee/latency estimates: https://bitcoinfees.21.co/).


Bitcoin Core software on 2 hard drives with one Wallet The answer to this may already be out there, I just couldn't find it.

The issue: My SSD has a few problems, I got the nasty "Disc Read Error" on boot up and while trying to sort that out, it occurred to me that my Bitcoin software is installed on that drive.

I did have the common sense to locate my Bitcoin wallet on my storage hard drive, so all that info is safe and I was able to boot off a spare drive that I use as a back up.  It doesn't have the Bitcoin Core software installed though.

The question: Can I install Bitcoin Core software onto my spare drive without any hick-ups and then access my wallet, or will I run into some issues? Will I have to go through the whole huge initial download thing again?

I didn't want to try until I asked, just in case there is something to look out for.

Thank you in advance

You should be able to download/install the software on your safe drive, and then specify as needed the locations of the wallet/data directory using the --datadir option (this should point to the repository containing the blocks directory as well as the wallet.dat file).


Bitcoin resistance against forged slow chain I'm implementing a new protocol with a custom blockchain, and I'm trying to figure out what is the correct way to deal with the "slow chain" problem.

In the Bitcoin protocol, nodes constantly gossip the newest block and try to produce a block after it. However, it sometimes happens that concurrent branches emerge, and from time to time nodes have to perform a rollback, 2 or 3 blocks into the past.

As we know, block difficulty depends on the time differences between blocks. A malicious entity can easily forge a chain of arbitrarily many blocks by simply starting from the genesis block and producing blocks with consecutive timestamps differing by more than 10 minutes. This way the difficulty would never increase, and the chain can be produced cheaply.

Of course, as a result of this approach, timestamps in the forged chain would increase much faster than in the real chain. This would cause the forged chain to be discarded by nodes, as legal blocks must have timestamps less than or equal to current timestamp (plus/minus some tolerance).

But the problem is:

Alice controls a bitcoin node, and has 500,000 blocks in storage. Bob advertises that he has 600,000 blocks, but the last common ancestor has number 1000. Bob's chain is a forged slow chain, but Alice does not know it. Alice wants to download Bob's blocks and check if these are correct.

QUESTION: How can Alice detect that Bob's chain is invalid before actually storing it?

Approach 1: A downloads all blocks after the last common ancestor with B, checks if everything is correct, and if all seems to be ok, reverts storage state by undoing block changes till reaching common ancestor, and then applying newly received blocks.

In our case, Alice would start downloading 599,000 blocks and eventually find out that the timestamp is too big. She would need to store the tentative chain in memory (possibly expensive) and check all the conditions. She would waste a lot of time, and every troll can trick her to do so.

Approach 2: A reverts the storage to the a common ancestor advertised by B, then tries to apply the blocks received from B as they come.

In our case, Alice reverts her storage back to block 1000, applies operations received from Bob, eventually discards a block with illegal timestamp, reverts back to common ancestor, and aplies the blocks she had before communicating with Bob. Again, time and resources wasted.

Approach 3: A can only revert a fixed, small number of blocks in the past. This way, B can do minimal damage, and forging a slow chain is very costly.

But in the case of a long-term network partition (split brain), the network parts would diverge and never achieve consensus on which chain is the longest. This situation would require manually removing records from storage.

Approach 4: A stores all the blocks ever observed, (including abandoned branches), and dynamically keeps track of which branch is the longest. This approach, while safe, requires a lot of storage space and is tricky to implement efficiently.

I'm leaning towards the third approach, but I'm wondering how is this being solved in various bitcoin clients.

I've seen that the core client stores only the longest chain and skips the orphaned blocks. The details of leveldb-based storage are described here:

What are the keys used in the blockchain levelDB (ie what are the key:value pairs)?

Thank you very much for your help.

Of course, as a result of this approach, timestamps in the forged chain would increase much faster than in the real chain. This would cause the forged chain to be discarded by nodes, as legal blocks must have timestamps less than or equal to current timestamp (plus/minus some tolerance).

Not always. For example, in a time warp attack, it's possible to go as many blocks as you want without advancing the clock at all. See How could a time warp attack be prevented? (You should probably avoid making the same off-by-one error in your code.)
For that reason, Bitcoin nodes do not compare chains by their height. (Although they used to do this.) They calculate the total work in each chain (nChainWork), and compare by that. This is calculated by looking at the number of attempts it would take, on average, to find each block, and summing it. This answer touches on how that's done: How is a blockchain split resolved?

Alice controls a bitcoin node, and has 500,000 blocks in storage. Bob advertises that he has 600,000 blocks, but the last common ancestor has number 1000. Bob's chain is a forged slow chain, but Alice does not know it. Alice wants to download Bob's blocks and check if these are correct.

Bitcoin nodes do tell each other how many blocks they each have, but they don't trust this automatically. Rather, they download all of the blocks and check how much work each block has. This can be done faster if you only download the headers; you can tell how much work a block has without downloading the entire block.


c-lightning & Lightweight nodes (no local bitcoind) I am trying to take advantage of the new release of c-lightning 0.6 that provide the ability to setup a lightweight node (i.e. No Local bitcoind instance running). But did not found any documentation how to do that yet.

What should I do in order to have a lightning node running a lightweight node? Is there a specific flag to use? or it is just a call from bitcoin-cli with a remote connexion flag setup on it?

Current setup:

Ubuntu 18.04 server
c-lightning 0.6

One lightweight alternative that I use quite often when setting up a Lightning node is spruned. The following will get you up and running:

Install some dependencies:

apt-get install -y git python3 \
                       libleveldb-dev \
                       python3-dev \
                       git \
                       gcc \
                       g++ \
                       python3-pip

Get spruned and its dependencies:

git clone https://github.com/gdassori/spruned.git spruned
cd spruned
git checkout 43e197693278fd551b165c6cfa5de78f853ef554
pip install -r requirements.txt

The third line is currently needed since the master commit is currently broken.

Next you can start the lightweight node with the following:

python3 spruned.py --network bitcoin.mainnet --datadir data --debug --rpcuser=rpcuser --rpcpassword=rpcpassword

Once the node is running you can start c-lightning like this:

lightningd --log-level=debug --network=bitcoin \
           --bitcoin-rpcuser=rpcuser \
           --bitcoin-rpcpassword=rpcpassword


Open source bitcoin projects? Is anyone involved in any open source projects? Anyone know of any? Maybe a nice list of different classes of projects would be good, I'd like to get my hands on some projects.

There are a couple of good resources to find these:

https://en.bitcoin.it/wiki/Category:Open_Source
http://luke.dashjr.org/programs/bitcoin - bitgit

Some of my favorites fall into the following categories:

Address Generation

Brainwallet
Vanitygen

Blockchain exploration

Bitcoin ABE

Mining Pool software

Eloipool

Wallets

Armory
Electrum


I read that Bitcoin addresses are single-use tokens. Is it my responsibility to generate new ones in Electrum? I am quite new to this, and started using Electrum today. I read on the Bitcoin Wiki that "unlike e-mail addresses, people have many different Bitcoin addresses and a unique address should be used for each transaction". Under the "Receive" tab in Electrum, I found a long address. Is that "Receiving address" the one that should be unique for each transaction? If that's the case, does Electrum generate a new one for me after receiving or do I have to do something myself?

Generally you do not need to manage your addresses yourself. Your wallet software will handle that for you and generate new addresses for you when you want to receive Bitcoin. In Electrum, just use the receive tab and get addresses from there. As you use addresses, you should see that the address in the "receiving address" box should change.


Is a cloud mining subscription worth it? I just started investing in Bitcoin and before I actually implement it, I want to verify my strategy / steps.

1) I made a wallet account on blockchain.
2) I want to purchase subscription from Genesis Mining for 1TH/s at $150.

My aim is to run this for a few months and transfer bitcoins to my wallet and see how market behaves.

Is this a good option for beginners to invest or get an idea of how Bitcoin  works?

Keep in mind, at current prices it would take a very long time to get your initial investment back with cloud mining. There have been many reports of cloud mining to be a ponzi pyramid scheme as they have the advantage of "time" on their side. They are basically paying you back what you paid them slowly.

However, if the price of BTC does rise significantly you can make a profit doing cloud mining. You are better off using the $150 to buy $150 worth of btc and holding that vs mining it via the cloud. You would instantly get the BTC to USD value vs waiting.

My advice if you want to get into mining as a "hobby" just get a usb miner you can find on ebay. Or just mine with your computer and join a pool with one of the other profitable coins found here: http://www.coinwarz.com -- bitcoin mining is a losing battle for the soloist.


Displaying price in BTC based on USD exchange rate This is a pretty classic programming question, but I think it is a very common one for the Bitcoin community, and would be helpful to have the code publicly available.

My preference is for a php script.

Bitpay publishes it's exchange rates here: https://bitpay.com/api/rates

If an item is $10 USD, how would I do the following?

1) extract the BTC/USD exchange rate from the array at this URL
2) Define the price, then divide by the exchange rate
3) Display the BTC price in an HTML page?

Save the code to a PHP file in the web directory:

<?php
  $url = "https://bitpay.com/api/rates";

  $json = file_get_contents($url);
  $data = json_decode($json, TRUE);

  $rate = $data[2]["rate"];   //$data[1] is outdated now, they have updated their json order. This new number 2 now fetches USD price.
  $usd_price = 10;     # Let cost of elephant be 10$
  $bitcoin_price = round( $usd_price / $rate , 8 );
?>

Price: <?=$usd_price ?> $ / <?=$bitcoin_price ?> BTC


How does market cap of currency decrease? According to my knowledge, once a currency is mined, its already released so how does market cap change? Consider if Sathosi (the founder of bitcoin) sells all his 1 million coins, there will be people who would buy it. It would just be a transfer from one person to another. How would it affect the market cap?

The market cap is the product of the total currency supply and its instant exchange rate. If either the exchange or supply goes down, the market cap does too.

The supply generally doesn't decrease, except through things like burning coins (see this answer of mine for more information). The exchange rate of course goes up and down all the time.

Market cap is generally a pointless metric, because it does not in any way reflect the cost or income of selling or buying the entire currency's supply. Only small fractions of the supply are being offered on the market, so selling or buying any significant amount will easily move the price around.

  Consider if Sathosi (the founder of bitcoin) sells all his 1 million coins

Just to be clear: how many BTC Bitcoin's creator has is speculation.


How do I prune/clean wallet.dat for old unused addresses Are there any easy way to prune wallet.dat? Like, deleting keys for addresses with no current balance and generated more than a month ago?

Old addresses associated in the wallet will not cause harm.  Is there any specific reason you want to do this other than cleaning up the addresses associated in your wallet?  I would leave them where they are as you will normally always need new addresses for new transactions.

Or are you wanting to prune old addresses imported into a wallet.dat file that are now no longer in use?  In this instance I would be more tempted to find the addresses with funds in the on the wallet and import these into a new wallet.dat file and use this new wallet going forward.

You can use Pywallet to prune old addresses out of the wallet but in the 14.0V of BTC i dont think there is a way.


I plan to buy any FPGA boards, any idea for a good sources of information? and what coin is profitable? Do you guys know any good source for newbie FPGA miners?

https://fpga.guide/en/ is a good place for beginners who want to learn about fpga mining. they also have a calculator page so you can find out which coin is the most profitable


How can I get the block number of given transaction? For a given transaction, I have its incoming transactions and I am trying to get the number of the block of those transactions. This seems like something that cannot achieve directly.

I am working on python with Json RPC and I want to work directly on the block-chain on my computer and not to use online API such as blockchain.info.

How can I get efficiently the block number of a given transaction?

According to the Wiki, the gettransaction <txid> call return a JSON object with the following information

"amount" : total amount of the transaction
"confirmations" : number of confirmations of the transaction
"txid" : the transaction ID
"time" : time associated with the transaction[1].
"details" - An array of objects containing:
"account"
"address"
"category"
"amount"
"fee"

Now just use getblockcount and subtract "confirmations" of the JSON object.


Command line address calculator? I'm looking for a command line address calculator, where I can put in my private exponent and get out a bitcoin address in Base-58 encode. Does anyone know some free software that will allow me to do this? Basically like http://brainwallet.org/ but off line.

Thanks.

I've cached a command line Bitcoin address generator posted a while ago on BitcoinTalk. Note that I've not tested it more than once, but it should at least give you a place to start.


Bitcoin not received from Coinmama to Blockchain Wallet I made a small purchase from Coinmama and transferred it to my Blockchain wallet. It has been over two hours and it hasn't appeared. I'm relatively new to this, but it has never taken this long. Can anyone clue me in?

Depending on amount of bitcoin you sent and fee you opted to pay will determine lenght of time for transaction. Network very busy and sets large transactions and people who pay the higher fees as priority.  It could take a little while. You can check status of transaction by checking blockchain. A few sites allow you to do this using your bitcoin address.


Where can I find a complete list of Bitcoin forks (soft, hard, intentional and unintentional) I was looking to study the history of Bitcoin forks including the 2013 incident that may or may not have been a Hard fork depending on your definition.

There is a paper that provides extensive detail on the history of all kind of forks on Bitocin, Ethereum and Ethereum Classic, you can read it here, Atomically Trading with Roger: Gambling on the success of a hardfork.

Here is the list of Forks so far,

The following content is sourced from the above paper,

  So far, Bitcoin has implemented over six softforks. These softforks
  range from introducing rules to prevent miners creating coinbase
  transactions with duplicated identification hashes, requiring all
  ECDSA signatures to strictly enforce DER coding, and introducing both
  absolute and relative lock times for individual transaction outputs.
  In terms of implementation, this involves storing new information in
  the scriptsig of the coinbase transaction, constraining transaction
  validation rules or re-defining the use of special OP_NOP function. On
  the other hand, Bitcoin has experienced two accidental (and temporary)
  splits (i.e. Fork-1, Fork-2 emerged) that required miner intervention
  to remedy. The first split permitted a user to exploit an integer
  overflow bug and create 184 billion coins. This required miners to
  co-operatively extend a new blockchain without the coin creation
  transaction [6] and to enforce a soft-fork to prevent this exploit.
  The second split involved miners who upgraded to Bitcoin Core 0.8
  accidentally creating blocks that were invalid for Bitcoin Core 0.7.
  Unfortunately, BerkeleyDB’s configuration in Bitcoin Core 0.7 was
  non-deterministic and as a result was not compatible with LevelDB’s
  configuration in Bitcoin Core 0.8. Resolving this fork required miners
  to immediately downgrade to Bitcoin Core 0.7 and abandon the forked
  blockchain. Next, the developers released Bitcoin Core 8.1 that
  enforced the activation of a hardfork12 after a two-month grace period
  for miners and users to upgrade


Three numbers after dash in transaction id In Bitcoin Core the transaction id is appended with a dash and three numbers. They are usually 000. What do those numbers mean?

For example: b75b91ffc4b6f22b779ce45e4b140cf1d29dc894e368e3d8389c42444f870d5d-000

It's the index of the output in the transaction that credits you.

It's a bit of an unused format; typically ':n' is used, rather than '-nnn'.

This is because an entry in the transaction ledger doesn't really corresponding to one transaction, but to one output of it. For example, a transaction could have multiple outputs that all credit you.


Could Hadoop be used as a mining pool architecture? The context is here

I don't know how exactly the new blockchain candidate was calculated in Bitcoin Network, so I guess it was based on a Merkle candidate of (a) bitcoin client/s. Also I presume that is by referring the diff of network, a client hashing the/a (golden) nonce, and then propagate it to the network, if lucky enough other nodes think this nonce is ok (the first), somewhere magic happened you get the coin (please enlighten me about this magic).

Please correct my understanding.

So (if you know Hadoop)

Despite how actually SHA(Midstate(nonce++)) was implemented in a Reduce procedure (hashing/sec/energy), how could I generate new Merkle tree(s) and midstate candidate(s) in Hadoop way (huge number of them simultaneously)?

Thank you for your reading (hard to understand).

Problem (if prior has no big problem)

What I am proposing here is, if all this works, how could a mining pool like this benefit from Hadoop? (if it could)

(If it really works, I'd implement raspberry pi to hook up hundreds of SHA asis of my own in distributed fashion.)

Map Reduce isn't the best idea, because distributed mining is solved and works well.  The magic of mining is described here, and when that is complete that Bitcoin protocol allows for 25 new Bitcoins to be send to any address.  This is encapsulated into a block that is either accepted (and used as the "previous" block), or rejected, for example if the protocol rules are broken.

Your time is best spent running your own mining pool.


Is there an easy way to purchase Bitcoins? I decided to check out bitcoin 3 weeks ago. And I have yet to buy my first bitcoin. It took a week to get a Dwolla account. Now when I go to MtGox to buy I find I need to go through even more hoops. I am starting to think that Bitcoin is just some kind of myth. A great idea but if you can not get the they are useless.

Dwolla imposed a 30-day probationary period for new accounts.  After your first funds have been added to Dwolla from your bank account, you then cannot trade those funds with a Bitcoin exchange for 30 days.

Dwolla did that to prevent hackers or other scammers from getting cash out of an innocent person's bank account before there is time for the individual to notice.

There are a lot of individuals who are not considered bitcoin exchanges who will gladly trade their Mt. Gox USD funds for your Dwolla USD funds:

http://bitcointalk.org/index.php?topic=78512.0

If you want an alternate method, there are numerous.  Since you are using Dwolla, then presumably you are in the U.S.

BitMe accepts cash deposited through Chase:

http://www.BitMe.com

The next fastest and convenient method is BitInstant:

http://www.BitInstant.com

But once you are through the 30-day Dwolla probationary period, then Dwolla works pretty well for moving funds to and from the exchanges.  Camp BX, Intersango, and Mt. Gox all accept Dwolla USDs for their market exhanges.   Bit-Instant accepts Dwolla for direct purchases of bitcoins.

http://en.bitcoin.it/wiki/Buying_bitcoins

If none of those options work well for you, you can also try doing an in-person trade:

http://www.LocalBitcoins.com


How do I list all of my addresses in namecoind? I just created a new address using namecoind getnewaddress and am trying to figure out what command lists them (in case I forget mine).

What is the command to list my addresses (that I have a private key for)?

namecoind listreceivedbyaddress 0 true

0 means to include even transactions with no confirmations, true means to show even "empty" addresses


Does an incorrect preimage cause intermediary nodes to discard a Lightning payment? Consider a multi-hop Lightning payment from Alice via Bob to Charlie. Charlie creates an invoice, Alice finds a route and forwards the payment, now Charlie is expected to redeem the payment by revealing the preimage to Bob. If Charlie tries to redeem the payment using an incorrect preimage, does Bob cancel the payment altogether, or does Charlie get "a second chance" to redeem it?

You will find the answer to your question in BOLT 02 in the section about the update_fulfill_htlc message

from there I quote:

  If the payment_preimage value in update_fulfill_htlc doesn't SHA256 hash to the corresponding HTLC payment_hash [the receiving node] MUST fail the channel.

This goes for every local HTLC so if Charlie sends the wrong payment_preimage Bob will fail the channel with Chralie. If Bob alters the preimage Alice will fail the channel.

Whoever fails the channel should fail the onion as the path does not exist anymore. Reading BOLT 04 I guess it returns

  type: PERM|8 (permanent_channel_failure)

But I did not double check in the implementations


Are sidechains really new? People have been talking a lot about side chains, but I thought this has been around for a while under a different name. Coins like Namecoin, Devcoin, ixcoin, i0coin, groupcoin, etc are all merge mined and have existed long before I ever heard the term "Side Chain".

Am I correct in my assumption that side chains are just a rose by another name (previously merge mined coins)? Or is there something I am missing here?

A side chain is a blockchain that runs parallel to the main bitcoin blockchain and can synchronize with it directly, allowing decentralized value transfer between the two chains. A user is able to essentially lock up a certain amount of coin on the main bitcoin block chain which then frees up an equivalent amount of coin on the side chain. This side chain may be either a sidechain compatible altcoin or just some test ground for new Bitcoin features. The coin that was transferred to the side chain can be returned back to the main bitcoin blockchain at any time. The value transferred back will be the same as the value transferred out.


Does Bitcoin no longer fulfill its original purpose? The Bitcoin whitepaper details "a purely peer-to-peer version of electronic cash", usable for "small casual transactions".
According to BitInfoCharts, the average Bitcoin transaction fee is currently 58 USD.
Is Bitcoin no longer usable for its original purpose of being a peer-to-peer version of electronic cash?

Does Bitcoin no longer fulfill its original purpose?

It does. Original purpose included decentralization and censorship resistance which still exists. I did not start researching about Bitcoin because I found a new way to transact online which is quicker and cheaper than my bank transactions, I started using Bitcoin for different reasons. So I assume things can be different for everyone and one whitepaper cannot include them all. Whitepaper is not a Bible and Bitcoin is not a religion. Bitcoin is a software (protocol for decentralized network in which you don't trust anyone) that is evolving every day.

The Bitcoin whitepaper details "a purely peer-to-peer version of electronic cash", usable for "small casual transactions".

It's still peer to peer if you run full node, it's still electronic. Small casual transactions work better using layer 2 and it's not difficult to understand that things can scale in layers.
There are layers in almost everything we use in computers and this approach is not limited to Bitcoin scaling.
If everything has to be done on-chain and every full node needs to sync it, do you think everyone will be able to run a full node? Did the whitepaper mention that full nodes do not matter and they can be run by few companies in some data centers?
What will you achieve by spending $10 on a coffee with low fees if you can't run your own full node and trust someone else?

Is Bitcoin no longer usable for its original purpose of being a peer-to-peer version of electronic cash?

It is usable and people who have been following Bitcoin development are using layer 2 solutions like Lightning Network.
Recent example: Okex supporting LN for bitcoin deposit/withdrawal


I need Fiat -> BTC merchant service Hello bitcoin community.

I'm running startup and we think how to accept payments. Our customers are far not geeks and they don't know what BTC is. However, I'd prefer to collect BTC on may wallet, not fiat. I've solved all tax issues in my country and I can deliver invoices to my customer where we will use fiat currency they paid in. But I'm looking for some merchant service that automatically turns fiat they pay through Visa/SWIFT or probably even PayPal into BTC using actual exchange rate. Could anyone suggest something?

There used to be a service by coinvoice.com that did exactly what you're asking. Unfortunately, they're no longer operating. I've heard bitpagos.com does that for Latin America. Otherwise, you're looking at setting up something with coinbase or bitpay to transfer fiat right away for bitcoins.

Best of luck with your business!


Unclear on double-hashing previous Transaction when creating a new Transaction I'm having trouble performing the double-sha256 hash of the previous transaction, Step 3 in this explanation.

The previous transaction is:

084fb53458bda42cf906dc2608fe962667188849e51e1dc13cd291cc13c97290

I've input the full transaction I want to perform into coinb.in as shown here, giving me a full transaction of:

01000000019072c913cc91d23cc11d1ee5498818672696fe0826dc06f92ca4bd5834b54f08010000001976a91460077bce1849cc2a41e2ccaa6ec575b3f5b70a9d88acffffffff0120a107000000000017a9144574085e1ef5432a6b09218f3b6ab6128f8eb2a58700000000

From what I understand, the double-sha256 of the previous tx here is:

9072c913cc91d23cc11d1ee5498818672696fe0826dc06f92ca4bd5834b54f08

However when I perform sha256 twice I get something completely different.

Example

Previous transaction:

084fb53458bda42cf906dc2608fe962667188849e51e1dc13cd291cc13c97290

Round one sha256 (with hex as input using anyhash.com):

9bbbb52bff2c553f84942188c87674c5b641b266baeb7ca216bebec8cd6a95bb

Round two sha256 (hex input also):

e5a3d32d306ef94968e0f77e6b0b496bfe9d5cd0fe6246a4ba7fd2fddf11cdf1

This final value does not match the one given by coinb.in's transaction. Am I missing something here? I see that the other question mentions the transaction in reverse order, what exactly does this mean?

I've figured it out.

So in this case (and if you look up a previous transaction on sites like blockchain.info) the transaction ID is already the double-hashed transaction. The input to the new transaction is just the reverse of the transaction ID.

So my previous transaction starts:
90 72 c9 13 ...

and the full transaction created by coinb.in ends in:
... 13 c9 72 90


Effective way for transferring cryptocurrency money from one wallet to other For example, I created a wallet on one trade platform. My friend has some money in some cryptocurrencies (BTC, ETH ...) for example. So here is my flow:

  friend's cryptocurrencies  --(1)--> my wallet on trade platform
  --(2)--> convert to BTC if needed --(3)--> trading here

Base on above flow, my friend can give me by 2 ways:

send me BTC directly. So I don't need to trade again to BTC on trade platform.
send me other cryptocurrencies (i.e: Etherium). Then I convert back to BTC on trade platform with some fee. (normally small)

At step (1), As I see, the fee for bitcoin transaction is too high comparing to other cryptocurrencies. So my question is: is the second way is better. That means receive from my friend's wallet on different cryptocurrencies and then converting back to BTC later on trade platform. (This is doable because he own amount of money on different cryptocurrency)

Thanks

Yes, it is probably cheaper to have your friend send you an altcoin, but if your end goal is to own BTC, then just have him send you BTC. I say this because:

The exchange you're going to send to will have its own fees (trades/withdrawal fees are common)
Storing coins on an exchange is not a good idea, if that exchange closes or gets hacked, then your coins might be gone forever. So you'll want to remove them from the exchange (which will probably incur fees)
Altcoins can be volatile (even more than bitcoin), what happens if while waiting for them to transfer to the exchange the price in btc drops 30%?

Right now the network is congested, so tx fees are higher than normal. Last week I sent a few transactions for less than a dollar, if you can afford to wait a few days btc fees may drop.


"Lost" password to BIP38 encrypted private key, encrypter may be faulty (Bippy) Few years ago I encrypted my Bitcoin private key for cold storage with an offline app called Bippy. Recently I tried to access my wallet by decrypting the private key, but my password was rejected.

I've checked out this Bippy program again, and I'm beginning to suspect it's faulty somehow. It seems that private keys beginning with a '5' - encrypted with Bippy - won't decrypt with the same password. Other prefixes seem to work OK.

Now, this Bippy app is open-source and written in Python, and I got it from here. I've tried, as a test, to encrypt the private key 5Ka1Bv4RpKayZygPhZbBcREejqeYwq2iSRzWPKsg49SPgVRTnpW with password testingOneTwo (it's a fresh pk, no bitcoins there ;)). In Bippy this encrypts to 6PYMN8WT4CW7xLYczLvYfXZCtQWND7XEesk32QbXujMgKhf2v5A2ZQANpL, however, using the above password fails to decrypt it to its original... I've tried several other '5'-private keys and passwords, and the same happens every time.

Luckily the program is open-source; sadly, the project seems abandoned a few years back and my knowledge of Python and encryption is not at a level good enough to pinpoint the bug at play here, and hoping for some help here :)

It turns out Bippy does have a bug in the encryption algorithm where it mixes up the public key compression flag. As pointed out, I posted this problem on reddit as well, and a solution has been posted there:

  Bippy is definitely doing something wrong.

  Technical Explanation

  BIP38 encrypted keys have 4 components (in the simplest case).

  The first two letters of the key, 6P, are a marker that say this is a BIP38 encrypted key.

  The next letter, Y in this case, specify some attributes of the key. In this case it says "This is a simple BIP38 key, and the public key should be compressed."

  The next couple letters (4 bytes in the hex representation) specify a "checksum". We'll get back to this.

  The rest of the key is the real meat of it. It's the encrypted private key. That's what we care most about.

  Now let's get back to that checksum. The checksum is 4 bytes derived from the Bitcoin address associated with the original private key. A big caveat here is that there are actually two Bitcoin addresses associate with a plain Bitcoin private key. One is based off the compressed public key, and the other the uncompressed public key.

  That's why BIP38 encrypted keys specify whether they are using the compressed or uncompressed address.

  In this case, Bippy spit out a Y which means it used the compressed address. In your screenshots it even says as much. BUT here's where the problem is.

  When we check the checksum Bippy spit out, it doesn't match with a compressed address. But if we use the uncompressed address, it matches! So Bippy says it's using the compressed address, but it's actually using the uncompressed address.

  So Bippy definitely has a bug where it's using the uncompressed address, but saying in the resulting BIP38 key that it used the compressed address.

  This isn't too big a deal. I'll discuss this after the non technical explaination.

  Nontechnical Explanation

  Bippy is encrypting correctly, but it's screwing up its encoding of the encrypted key. It's saying it used public key compression when actually it didn't. This isn't a huge deal.

  Solution

  So, the good news is that it looks like, other than that minor bug, Bippy is encrypted the important stuff correctly. It should be possible to take your "lost" Bippy key and recover the private key from it. Assuming your password is correct.

  I should be able hack up my script to take care of that for you. I'll to to work on that and get back to you. (I need to fold in some Base58 encoding/decoding into the script and make it a bit user friendly for ya ;) ). The code will be quite simple Python code, so you can do a cursory glance to be sure it doesn't do anything evil.

A python recovery script has been supplied as well, available on github - all credits to fpgaminer


Can blockchain be used for auditing? It has been argued that with the use of blockchain in auditing, the transaction and the record of the transaction will be the same thing. What does this mean?

the transaction are all available here:

http://www.blockchain.info

or here:

http://www.blockexplorer.com

or if you set up a full node on your own machine.

for a transaction to be valid it needs to appear on that global auditable log


mining of sh256 coins I'm new in mining
I just bought one s9 miner,
Want to know that how can i mine any sh256 coin with s9 miner ?
I was searching about it and different pools,
but everywhere they said like this

Create account.

Register here, or login if you already have account
Create a worker that will be used by the miner to login
2. Download a miner.

Intel/ATI/AMD CGMiner: Download here
Intel/ATI/AMD BFGMiner Linux/Windows: Download here
Fabulous Panda Miner Mac OS X: Download here
Minerd CPU Miner Mac/Linux/Windows: Download here.
3. Configure your miner.

Settings for Stratum:

STRATUM:    stratum+tcp://mine1.mpool.me
PORT (Low hash rates):  4012 (varDiff: 16 - 4096, initial diff: 128)
PORT (High hash rates): 4112 (varDiff: 2048 - 65535, initial diff: 2048)
Username:   Weblogin.Worker
Password:   Worker Password

If your using Linux, Then type the following into the console:

please help me how to configure miner

Thanks in advance

I have previously reviewed the steps for configuring the Antminer S9.

You need to register an account with a pool and add a worker.

The stratum information is what you need to put into the Antminer S9 configuration.

You need to know the IP address of your S9 on the network. If you do not know it, use Advanced IP Scanner (or similar, I do not know if you are running Windows?) and find it.

Open http://x.x.x.x/ (IP of your S9) in your web browser and login. In the Miner Configuration tab, enter your stratum information there.

URL: stratum+tcp://mine1.mpool.me:{PORT} - you have choices for PORT 4012/4112
Worker: {your worker name} - you should have configured this in the pool where it may be called Worker Username.
Password: {your worker password}

Save & Apply.

Your miner will  not start until it registers.

You may enjoy this video (the sound is quiet!):
How to setup Antminer S9, R4 GUI- Set mining pools, ECT

Enjoy mining!


print websocket messages in a textfile I am doing a PhD in economics and I am currently working on bitcoin. I am trying to understand how senders decide how much fee they include in transactions. Since in a couple decades miners will be rewarded mostly with fees, I think this is an important question. It would be great if I could have data on all the unconfirmed transactions. This would enable me to see, for each transaction, how much fee it includes given the available information, that is how many transactions are already in the mempool and how much fee do those include. Of course I can see those transactions on blockchain.info, for instance, but is there a way I could save them on a file?

Thanks to a very clear video on you tube I can receive the transactions on my browser's console log using blockchain.info's websocket but how can I print, let's say a couple hundred thousands of them, in a textfile?

Could anyone help me? Thank you very much!

Simple example, using Python 3 and the websocket-client library.

from websocket import create_connection

ws = create_connection("wss://ws.blockchain.info/inv")
ws.send("""{"op":"unconfirmed_sub"}""")
while True:
    tx = ws.recv()
    print("tx!")
    with open("bitcointx.json", "a") as f:
        f.write(tx + "\n####\n")


Bitcoind walletnotify Does wallet notify performs actions also on old transactions? In case that my node went offline for some reason, Once its back online I will get notifications from wallet notify for the transactions that I missed when it was offline or not?

Tnx in advance!

Yes, It will send a notification once a transaction added to your bitcoin core wallet. so, when you start your node again any transactions belongs to your wallet you should get a notification for.

-walletnotify=<cmd> Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)


How do I set up IRC bouncer to receive messages and follow the discussion while I am offline? I am now set up on IRC and I can attend the Bitcoin Core PR review club sessions. But when I am offline I can't receive messages and I can't follow the discussion which has happened during the time I was offline. How do I set up a IRC bouncer to address these problems?

On some IRC channels such as #bitcoin-core-dev there are third party managed conversation logs so you can follow the conversation from when you were offline without setting up a bouncer. However, I don't think (at the time of writing, September 2020) that there are conversation logs for the #bitcoin-core-pr-reviews channel except for the weekly meeting which is logged on the Bitcoin Core PR review club site. You definitely can't receive messages whilst you are offline.
There are various options to set up a bouncer but in the interests of simplicity I will just outline one assuming you followed the instructions here to install Textual on MacOS.
You will need a virtual private server (VPS) to be running 24/7 to log the discussion and receive messages on your behalf and then you can connect to that server whenever you come back online. This will require a monthly subscription.
So your first step is to choose a VPS provider. One easy to use option is Digital Ocean but there are others that perform the same function and are equivalently priced. (We generally avoid product recommendations on this site so please excuse this counterexample.) You can connect directly to your VPS/Digital Ocean Droplet with SSH using the instructions here. There is a tutorial for setting up SSH keys here.
Once you have set up your VPS you will need to install ZNC on that server. Instructions for doing that are here (deprecated but easier to follow and should still work) or here. The latest ZNC release is available here. You can ssh into your VPS using:
ssh -i /path/to/private/key root@IP_address_of_VPS

Instructions for connecting your Textual client to the ZNC bouncer are here.


How do I configure Bitcoin Core to connect always to a particular node? By reading https://bitcoin.org/en/full-node I've decided that I want to run a FULL node (let's call it 'X'), to contribute to the P2P network.

So, I'll leave its ports open, or have a DMZ zone with a public IP address in it.

But this comes with security risks, so I will not have any funds in this instance of the Bitcoin Core QT client.

Then, I will keep my BTC funds in a different computer (let's call it 'Y') that will not be a full node (but still use bitcoin-core QT main client).

However, how can I configure 'Y' to always connect (in order to broadcast my transactions) to my server 'X' and not a different one?

Thanks

Your private node would still be a fully validating node (i.e. full node). That's a good thing.

As for having the private node connect to your public node, you have two choices:

-addnode=<ip> Add a node to connect to and attempt to keep the connection open
-connect=<ip> Connect only to the specified node(s)

What you were asking for is nr 2, but you might want to consider nr 1 instead because that gives your private node a bit more redundancy in case there's a problem with your public node (hardware problem, disk full, router misconfiguration...). But it will make a few outgoing connections to random internet nodes (slight security problem if you don't trust the bitcoin p2p protocol and it will cause a bit more bandwidth usage).

You might also consider these options:

-listen=0  Don't accept connections from outside (implied by -connect). (although if you don't port forward in your firewall, it doesn't matter.)
-whitebind=<addr>
   Bind to given address and whitelist peers connecting to it. Use
   [host]:port notation for IPv6
-whitelist=<netmask>
   Whitelist peers connecting from the given netmask or IP address. Can be
   specified multiple times. Whitelisted peers cannot be DoS banned and
   their transactions are always relayed, even if they are already in the
   mempool, useful e.g. for a gateway
upnp=0 to disable UPnP. If you're capable of doing your own firewall configuration, you don't want this increased attack surface. (This has/will become the default in recent versions.)

The whitelisting (4 and 5) will prevent your private node from accidentally banning your public node if something weird happens.

Public node configuration

You probably also want to have e.g. -whitelist=192.168.1.0/24 on your public node as well to never ban your private node.

If it's not running a wallet, use the option -disablewallet [Do not load the wallet and disable wallet RPC calls]. Saves some resources and lowers the attack surface.


Difficulty in verifying bitcoin-core signing keys How can I verify bitcoin0.19 signature bwith gpg?
I read I should use gpg --recv-keys signingkey, but I don't understand where is the file signiggkey. I tried to download Bitcoin Core Release Signing Keys v0.11.0+ but what I got is a .asc file, which I don't know how to use

With the .asc file, you can do

gpg --import <asc filename>


Why is the longest block the one that gets accepted by all the nodes? I'm confused about one of the core principles of Bitcoin.  When various nodes are confirming transactions, why does the longest block win out?  That is, why doesn't the system allow whoever confirms a transaction or group of transactions first be the block that all the other nodes accept?  I realize there has to be some logic in the situation where two nodes submit confirmations at the same time, but what problems would get introduced if the node that confirmed a group of transactions first, regardless of the size of the block, win?

The problem here lies in a misunderstanding. It's not the longest block that wins out, but the longest blockchain (read "the blockchain with the most cumulative difficulty"). The length of a single block is hereby irrelevant and in fact usually the node that first confirms a set of transactions wins.


Ubuntu update litecoin-qt wallet software I get this message when i run my litecoin-qt client:

all users must upgrade to litecoin 0.6.9.1 prior to 15 august 2013

so i downloaded the litecoin-0.6.9.2-linux.tar.xz file from litecoin.org and ran through this process: https://forum.litecoin.net/index.php?topic=43.0

Now i have the new litecoin daemon running but the qt client has not upgraded. How do I upgrade the client? I'm using Ubuntu 12.04.

found the instructions:

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

basically just need to run

qmake "USE_UPNP=-"
make

in the main directory to create the litecoin-qt file


How Do Attackers Forge Bitcoin Blocks And How Do You Identify Forge Bitcoin Blocks? I have read that a block contains several bitcoin transactions and an attacker can forge fake blocks.

Does these forged fake bitcoin blocks cost the attackers money for mining or was it just generated for free from the attacker node?

The blockchain is safe from attacks because the blockchain was programmed by Satoshi to validate and keep the longest chain.

So the forge block will disappear from the blockchain network. This is wonderful but what happens if an attacker forge bitcoin blocks?

I even read that some of these forge blocks can have 2 to 3 confirmations. Is this true?

So how do you identify these forge bitcoin blocks immediately?

I assume that when you say an attacker can forge blocks, you mean that a dishonest miner can create invalid blocks.

The answer is no for a very simple reason. When a miner's bitcoin node (the computer which runs the bitcoin software) creates a block, it must follow all of the consensus rules. Let's say, for example, he tries to create a coinbase transaction with 13 bitcoin, plus fees. Note that, at the time of writing this, the block reward is 12.5 bitcoin.

Then it finds Proof of Work and sends the block to the rest of the network. Every node that receives this block will first check if it follows the rules. Since it doesn't, the node will reject that block. Therefore, it will not get included in the blockchain and the miner just lost the reward.

So, every node validates everything on its own. No node trusts information it recieves from other nodes.


Confused about buy/sell definition in trades history I'm looking at some trade history provided by the kraken.com API (formatting mine):

    Price         Volume         Time        Buy/sell Limit/market  Remarks
["7833.00000", "0.17400000", 1559721453.3446,   "s",      "l",        ""],
["7830.00000", "0.04984709", 1559721484.6288,   "b",      "m",        ""]

What I understood about trading so far:

Limit trades go on either side of the order book, at the limit set by the initiator. Buy orders go to the bid side and sell orders to the ask side. When a bid meets an ask a trade gets executed, up to the lowest amount from either side. Any remainder will remain on the order book until matched again.

Marked trades are executed near-instant by emptying the order book on the appropriate side until the order is filled.

As such, a trade is always both a buy and sell in the same time.

My questions: what is the exact definition of a buy/sell indication in the trade history? Is the sum of the volumes the total volume traded? Or should it be divided by 2?

what is the exact definition of a buy/sell indication in the trade history?

A trade whether it will be marked as buy/sell will depend on how the order book is consumed. Assume the last traded price (LTP) is $100 and for simplicity sake assume the order book allows only integer increments in the bid and ask prices. So your order book will have bids starting from $99 all the way down and the asks starting from $101 all the way up. When a user posts an order that consumes the order book from the bid side, it is treated as sell while on the other hand if an order consumes the ask side it is treated as a buy.

  Is it the sum of the volumes the total volume traded?

No. It is the amount consumed from the order book. So going back to our previous example, assume there are 50 ask units at $101 and 50 at $102. When a user places a buy market order for 100 units, the trade book will show:

Price      Volume     Buy/sell   Limit/market  Remarks
["$101",     "50",       "b",        "m",        ""],
["$102",     "50",       "b",        "m",        ""]

Now the LTP is $102. There will be bid orders starting $101 all the way down and ask orders from $103 all the way up. Assume we have 50 units each in bids ranging from $101-$95. Now assume a user wants to sell 100 units and his risk tolerance allows him to sell only at $101. Hence the user will place a limit sell order at $101 for 100 units. But since there are only 50 units at the bid, that will be consumed and the rest 50 units will be added to the ask side of the order book. Now the trade book will be:

Price      Volume     Buy/sell   Limit/market  Remarks
["$101",     "50",       "s",        "l",        ""],


What happens when a miner does not claim all fees/generated coins? Suppose that a miner for some reason has the generation transaction of their blocks not take all the possible coins. This can happen for a variety of reasons, almost all of which are bugs:

An off-by-one error makes them think that their block should generate only 25 BTC when we're still at 50 BTC per block
Some bug prevents them from noticing a transaction fee; perhaps they were mining and updating the block in parallel using non-thread-safe code.
Depending on the answer to this question, they may actually decide to do this on purpose (though I can't think of an answer that would cause this in the vast majority of cases)

I can think of a few possible ways the network would respond, and none really seem ideal.

The block could be rejected, just as it would be if it had too much generated.
The block could be accepted and the extra coins available for whoever mines the next block (in which case, somebody may do this on purpose to encourage others to mine).
The block could be accepted and the extra coins lost.

What actually happens?

The block is accepted, and the coins are lost. Poor miner.

Here is a link to the part of the 0.6.3 source which checks this: https://github.com/bitcoin/bitcoin/blob/v0.6.3/src/main.cpp#L1362

Also, this has effectively happened before; block #124724 claimed one satoshi less it than could have.


Time stamping of Transactions In Bitcoin Blockchain, every block has a time stamp. My question is, Is there any time stamp on an individual transaction, once it is propagated on the network, and once it was included in the Block?

no, a transaction has no time stamp. Details can be found here: https://bitcoin.org/en/developer-guide#transactions


Outrageous miners fees My BRD wallet just charged a 27 dollar miners fee TO SEND 50 dollars worth of bitcoin!! 1/3 of 75 bucks went to a miners fee? 55e7f51a96ecd8d25a1566346bff76e2985a5aed4fe279e44d75f991cf0a993a

Your wallet seems to have wildly inaccurate fee estimation.
Currently, for next block mining, you should be paying around 1/8th of that fee - 1/10th or less for next 2-4 blocks.
Unfortunately, that transaction cannot really be cancelled - you could attempt to double spend it, but the fee is so high that you'd end up spending even more to potentially get a double spend mined, which defeats the purpose.


Forgotten password for wallet. Must a password be entered before spending? I was about to spend some bitcoins but Bitcoin Core required my password, which I don't remember, to complete transaction... The wallet is open but cant use bitcoins.
I would like to know if before ANY transaction, you must ALWAYS enter password. This is the first time I try to send bitcoins so I don't know how this goes...
Thanks.

Learn from other people's past mistakes
Some good advice is at https://bitcoin.org/en/secure-your-wallet#encrypt

Encrypt your wallet
Encrypting your wallet or your smartphone allows you to set a password for anyone trying to withdraw any funds. This helps protect against thieves, though it cannot protect against keylogging hardware or software.
Never forget your password
You should make sure you never forget the password or your funds will be permanently lost. Unlike your bank, there are very limited password recovery options with Bitcoin. In fact, you should be able to remember your password even after many years without using it. In doubt, you might want to keep a paper copy of your password in a safe place like a vault.
Use a strong password
Any password that contains only letters or recognizable words can be considered very weak and easy to break. A strong password must contain letters, numbers, punctuation marks and must be at least 16 characters long. The most secure passwords are those generated by programs designed specifically for that purpose. Strong passwords are usually harder to remember, so you should take care in memorizing it.

Notice that second item.
Once you set a password, which you definitely should, it is important to never forget your password. This is why people use password managers and make backup copies in secure places.

What next?
If you have some idea of what your password might have been, you might try recovery tools such as btcrecover. (not an endorsement, other tools exist, take extreme care choosing tools)
If you care about your money ...

Only download tools from sites you are 100% certain of, Check carefully.
Compile any tools from source code if you can.
Never give any potentially sensitive information to helpers. Treat all helpers as if they were thieves (almost all people offering to help will in fact be confidence tricksters). A genuine helper never needs to know your password or any part of it or anything about it. A genuine helper never needs any kind of access to your PC. A genuine helper never needs to create a wallet for you.
It is better to spend time learning how to do things yourself with no active participation from any helper. A genuine helper needs no more information than is already in your question above.
Don't attempt recovery on any computer that has ever been used or accessed by anyone else in the past.
Don't attempt recovery on any computer or device that is connected to the Internet.


Which exchange rate should I use for calculating Bitcoin exchange rates? I'm using the Blockchain exchange rate API to add a Bitcoin exchange rate calculating function to one of my apps.  I'm not sure which value I should be using.  For each currency type (USD, EUR, etc.) four different rates are returned: "last," "buy," "sell," and "24h."

Most people are interested in the last value or the 24 hour average, it depends on the purpose of the application and the intent of the developer.


Export Xpubkey from Bitcoin Core How do I export my HD wallet's Xpubkey in Bitcoin Core?

Do I construct it using the value of "hdseedid" returned by getwalletinfo?

It does not have one.

Bitcoin Core uses hardened derivation, so there is no way to compute the addresses it will use externally.

Support for that will likely be added in upcoming versions, but likely won't be the default (there are security risks when using non-hardened derivation).


Bitcoind to use static RPC authentication cookie from file? I'm running bitcoind 0.20.1 inside a Docker container and would like to access its RPC interface from another container. I have put an authentication cookie into a Docker secret and mapped it to /run/secrets/rpc_cookie. Now when I use -rpccookiefile=/run/secrets/rpc_cookie bitcoind tries to write to that file and fails. Of course, it's read-only! How can I instruct bitcoind to just use the cookie from the file and be done with it?

You can't. The cookie file is for bitcoind to write it's automatically generated credentials to for other software to read. If you want to set the RPC credentials, you need to do so within the bitcoin.conf file using the rpcauth option (or rpcuser and rpcpassword but these are deprecated). These could also be specified on the command line.


How can someone mine bitcoins at billions or trillions of hashes per second when the nonce is only 2^32 in size? According to another similar question on Bitcoin Stack Exchange, https://en.bitcoin.it/wiki/Block_hashing_algorithm shows how the mining algorithm works for Bitcoin.  The problem is, it shows the nonce as being not larger than 2^32.  When someone has gone through all the values the nonce can have, it seems the time changes and the search for a proper nonce begins anew, as even changing the second by 1 is enough to warrant testing the nonces again in the hashing algorithm.

As it relates to the actual mining algorithm/software, with all this in mind, how can mining hardware provide billions or trillions of hashes per second when each second only provides ~4.3 billion different nonces and requires a new "second of time" to change the time so as to begin anew with the nonces?  It seems as though in the most extreme circumstances, even having the "merkle root" changing due to the addition of a transaction to the block would not occur frequently enough for the most powerful ASICs to always have work to do.

To the extent that it is possible I am seeking a potentially elaborate yet easy to understand answer.

The timestamp in blocks does not need to be set to the actual time of the current hash. So during mining, the timestamp can be moved when the nonce is exhausted even if the actual time is not that timestamp.

There are also other ways to change block headers that do not require changing the timestamp. Miners frequently add a value to the coinbase part of their coinbase transaction which is referred to as an extranonce. Miners will increment that in order to change the merkle root every time they exhaust one set of nonces so as to allow for even more nonce possibilities. Furthermore, other things can be done such as permuting transaction order, selecting new transactions, changing coinbase output scripts, etc. All of these ways of changing the block hash allows for miners to do trillions of hashes per second.