text:
Bitcoin protocol: How do I build my block to get the newly generated coins?
I am writing a software to mine bitcoins (in golang) as part of a college project. I'd like to know how is it that I build a block (which would potentially get appended to the end of the block chain) so I can send the 25 newly generated bitcoins to myself. You may assume I already know how to build a basic block header.
An example would be greatly appreciated, any dummy data may be used.
Also, I'd like to know if I would need to insert in the merkle tree any information regarding the transaction that gives the 25 newly generated coins to the miner.
Thanks in advance!

I didn't know the key term to find such answer: coinbase transaction. Sorry for the duplicate question.


text:
Where can I see the code of how the UTXO set is updated in case of a fork in Bitcoin Core?
I am looking for a filename and a line, or multiple ones if necessary. My goal is to maintain an index of addresses to UTXOs.

In the case of a fork, you have to Disconnect the blocks that are on the losing side of the fork, and then Connect the blocks on the winning side of the fork, in order. If you look at the CCoinsViewCache input into the function, you can see how the UTXO set is updated.
Essentially, though, you have to reverse the effects of all of the transactions in the losing blocks and apply the effects of the transactions in the new blocks. Reversing means processing inputs to mark STXOs as UTXOs and removing UTXOs created in the block. Processing new transactions into the UTXO set means, in addition to verifying the transactions are valid, you mark UTXOs spent by the inputs of transactions as STXOs (or remove them, depending on how your system works), and you create new UTXOs for the outputs in the block.
Keep in mind that you have apply these processes for each transaction in the block in order (or reverse order if Disconnecting a block), because transaction B can spend from outputs created in transaction A, where A & B are in the same block.

My goal is to maintain an index of addresses to UTXOs.

If I were you, I would keep an index of the scriptPubKey and then convert an address to the scriptPubKey you need when you need to do a lookup.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
How does serializing in coins.h work?
I'm talking specifically about this:
/** pruned version of CTransaction: only retains metadata and unspent transaction outputs
 *
 * Serialized format:
 * - VARINT(nVersion)
 * - VARINT(nCode)
 * - unspentness bitvector, for vout[2] and further; least significant byte first
 * - the non-spent CTxOuts (via CTxOutCompressor)
 * - VARINT(nHeight)
 *
 * The nCode value consists of:
 * - bit 1: IsCoinBase()
 * - bit 2: vout[0] is not spent
 * - bit 4: vout[1] is not spent
 * - The higher bits encode N, the number of non-zero bytes in the following bitvector.
 *   - In case both bit 2 and bit 4 are unset, they encode N-1, as there must be at
 *     least one non-spent output).
 *
 * Example: 0104835800816115944e077fe7c803cfa57f29b36bf87c1d358bb85e
 *          <><><--------------------------------------------><---->
 *          |  \                  |                             /
 *    version   code             vout[1]                  height
 *
 *    - version = 1
 *    - code = 4 (vout[1] is not spent, and 0 non-zero bytes of bitvector follow)
 *    - unspentness bitvector: as 0 non-zero bytes follow, it has length 0
 *    - vout[1]: 835800816115944e077fe7c803cfa57f29b36bf87c1d35
 *               * 8358: compact amount representation for 60000000000 (600 BTC)
 *               * 00: special txout type pay-to-pubkey-hash
 *               * 816115944e077fe7c803cfa57f29b36bf87c1d35: address uint160
 *    - height = 203998
 *
 *
 * Example: 0109044086ef97d5790061b01caab50f1b8e9c50a5057eb43c2d9563a4eebbd123008c988f1a4a4de2161e0f50aac7f17e7f9555caa486af3b
 *          <><><--><--------------------------------------------------><----------------------------------------------><---->
 *         /  \   \                     |                                                           |                     /
 *  version  code  unspentness       vout[4]                                                     vout[16]           height
 *
 *  - version = 1
 *  - code = 9 (coinbase, neither vout[0] or vout[1] are unspent,
 *                2 (1, +1 because both bit 2 and bit 4 are unset) non-zero bitvector bytes follow)
 *  - unspentness bitvector: bits 2 (0x04) and 14 (0x4000) are set, so vout[2+2] and vout[14+2] are unspent
 *  - vout[4]: 86ef97d5790061b01caab50f1b8e9c50a5057eb43c2d9563a4ee
 *             * 86ef97d579: compact amount representation for 234925952 (2.35 BTC)
 *             * 00: special txout type pay-to-pubkey-hash
 *             * 61b01caab50f1b8e9c50a5057eb43c2d9563a4ee: address uint160
 *  - vout[16]: bbd123008c988f1a4a4de2161e0f50aac7f17e7f9555caa4
 *              * bbd123: compact amount representation for 110397 (0.001 BTC)
 *              * 00: special txout type pay-to-pubkey-hash
 *              * 8c988f1a4a4de2161e0f50aac7f17e7f9555caa4: address uint160
 *  - height = 120891
 */

I don't really understand how nCode works. Let's take the second example:
First bit is set to indicate it's a coinbase transaction. So far nCode = 01.
vout[0] and vout[1] are spent, which means we add 1 because there is at least 1 unspent output. So the bitmask is 0001 0001, which is equal to 0x11.
So already we have a number bigger than 0x09. How the hell is that nCode = 0x09 computed?

(note: I'll be using a different bit numbering from the comment which goes from 0..B instead of 1..2^B, as I find that easier to read myself)
The binary representation of 0x9 separated in functional groups is
bit# ...6543 21 0
        ---------
        0001 00 1

Bit 0 is set because this is a coinbase
Bit 2 and 1 are 0, because vout[0] and vout[1] are spent
Bit 3+ contain just the binary number 1. As bit 1 and 2 are not set, these bits encode N-1. N=(9>>3)+1=2. N here is the number of bytes in the subsequent bit vector.

These two bytes that follow are 04 and 40, encoding the number 0x440, the number with bits 2 (1<<4=0x04) and 14 (1<<14=0x4000) set. As described in the example this means vout[2+2] and vout[14+2] are unspent.
How do you end up at 0x11?

I think my first confusion comes from the numbering, I agree yours is easier to read.

However, I only follow you until you say N=(9>>3)+1=2 Where do you get this from?

(9>>3) extracts bits 3+ from the input nCode using the shift-right operator. This is 1, to which 1 is added to result in 2.

Ok thanks, I get it. But now I don't get the next part. Correct me if I'm wrong, but 2<<4=0x20and 2<<14=0x8000, no?

I still don't see how 0x440 encodes bits 2 and 14. Sorry I'm pretty new at this.

My bad, I skipped the part where it said least significant byte first. Now it makes sense to me.

Sorry, my bad, you need to use 1<<2 and 1<<14. I'll correct my comment.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
what happens if a miner include a transaction already exists in another block?
Suppose that I have a Transaction A. (txA)
I send my txA to bitcoin network and full node validate it and put in Mempool and starts to broadcasting it.
A Miner A connect to a fullnode to create a candidate block and wins the POW. In this block there is my txA
A miners B create another block with all different transactions except to my txA.
If block A and block B have the same previous block Hash it's a fork,and if the chain of block A wins, all transaction of block B return to mempool.
But if B Has the previous block hash of A ?
After create a block there is another check of all transactions?
When TxA is in mempool it's unconfirmed when become confirmed?

It can only exist in one block.  That is why it is safer to wait for 2-6 confirmations before accepting a large transaction.
So to answer the title of your post - a miner can't include a transaction which exists on another block in the same chain since it would not be a valid block.

thanks, who check these blocks for 2-6 confirmations?

@monkeyUser: the anxious recipient

@monkeyUser It's up to the person receiving the Bitcoin to check the number of confirmations.  If you own a Lamborghini dealership an a customer pays with BTC, after 1 confirmation you let the customer drive off.  The chain re-organizes and that BTC is no longer valid, and you don't have the money in your account.  You should have waited for 6 confirmations before letting the customer drive off!

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Sign manually P2WSH native with Openssl
I'm studying the segwit part, and I want to sign P2WSH (native) manually (openssl).
I just read the BIP0143 and I see the new transaction digest.
Double SHA256 of the serialization of:
     1. nVersion of the transaction (4-byte little endian)
     2. hashPrevouts (32-byte hash)
     3. hashSequence (32-byte hash)
     4. outpoint (32-byte hash + 4-byte little endian)
     5. scriptCode of the input (serialized as scripts inside CTxOuts)
     6. value of the output spent by this input (8-byte little endian)
     7. nSequence of the input (4-byte little endian)
     8. hashOutputs (32-byte hash)
     9. nLocktime of the transaction (4-byte little endian)
    10. sighash type of the signature (4-byte little endian

I'm using regtest and I create a transaction from my P2WSH to P2WPKH where I move ~49.999991 bitcoins.
It's my UTXO
   020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0200f2052a01000000220020896386cc04087d76450a506b09e88de6d68bba45f50c4967818e6fd10e6eaade0000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000
{
  "txid": "0237415f2eb789a48e43ed68862ea9db3455f7b21203f4b526cd88b970b1329b",
  "hash": "76069338f9fd11b43901b6b5260e6b279dd26071148643a1b31fc41190dc73f1",
  "version": 2,
  "size": 180,
  "vsize": 153,
  "weight": 612,
  "locktime": 0,
  "vin": [
    {
      "coinbase": "510101",
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 50,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 896386cc04087d76450a506b09e88de6d68bba45f50c4967818e6fd10e6eaade",
        "hex": "0020896386cc04087d76450a506b09e88de6d68bba45f50c4967818e6fd10e6eaade",
        "reqSigs": 1,
        "type": "witness_v0_scripthash",
        "addresses": [
          "bcrt1q393cdnqypp7hv3g22p4sn6ydumtghwj975xyjeup3ehazrnw4t0q7p0v3p"
        ]
      }
    },
    {
      "value": 0,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_RETURN aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9",
        "hex": "6a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9",
        "type": "nulldata"
      }
    }
  ],
  "hex": "020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0200f2052a01000000220020896386cc04087d76450a506b09e88de6d68bba45f50c4967818e6fd10e6eaade0000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000",
  "blockhash": "42f85575b186494c8ac18487a0f21f4645346c6d9740d17f764a8a56e74fa2e3",
  "confirmations": 101,
  "time": 1587537959,
  "blocktime": 1587537959
}

My raw transaction data is:
02000000019b32b170b988cd26b5f40312b2f75534dba92e8668ed438ea489b72e5f4137020000000000ffffffff017cee052a01000000160014f545040775837a55962bb8abfcc341f574d6791700000000

And I create the new transaction digest like this:
    TX_VERSION: 02000000
    OUTPOINT: 9b32b170b988cd26b5f40312b2f75534dba92e8668ed438ea489b72e5f41370200000000
    HASH_PREV_OUT: b98dd14dcfff442ee1562d70b507402d6ba089dc8af7fe0360f422ff5d60a206
(HASH_PREV_OUT is SHA256 twice of $OUTPOINT)
    SEQUENCE: ffffffff
    HASH_SEQUENCE: 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
(HASH_SEQUENCE is SHA256 twice of $SEQUENCE)
    SCRIPTCODE: 1976a91427275283377b40957701cecd37d2e170c41d387488AC
    AMOUNT: 00f2052a01000000
 (TOTAL AMOUNT - 50 bitcoin )
    OUTPUT: 160014f545040775837a55962bb8abfcc341f574d67917
    OUTPUT_HASH: 9fbf0bcf967eb3f1fcd41f60ce73e69f8b5073185ff81f787d9caac0e5992fd2
(OUTPUT_HASH is SHA256 twice of $AMOUNT$OUTPUT)
    LOCKTIME_PART: 00000000
    SIGHASH: 01000000

Where SCRIPT-CODE is my UTXO witness script (the script is P2PKH)
Then I "merge" all values like this:
$ WITNESS_V0_DIGEST=$TX_VERSION$HASH_PREV_OUT$HASH_SEQUENCE$OUTPOINT$SCRIPTCODE$AMOUNT$SEQUENCE$OUTPUT_HASH$LOCKTIME_PART$SIGHASH
$ echo $WITNESS_V0_DIGEST
02000000b98dd14dcfff442ee1562d70b507402d6ba089dc8af7fe0360f422ff5d60a2063bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e706650449b32b170b988cd26b5f40312b2f75534dba92e8668ed438ea489b72e5f413702000000001976a91427275283377b40957701cecd37d2e170c41d387488AC00f2052a01000000ffffffff9fbf0bcf967eb3f1fcd41f60ce73e69f8b5073185ff81f787d9caac0e5992fd20000000001000000

Then I can do the double SHA56 and sign it:
printf $WITNESS_V0_DIGEST | xxd -r -p | sha256sum -b | xxd -r -p | sha256sum -b | xxd -r -p > WITNESS_V0_DIGEST.txt

SIGNATURE=`openssl pkeyutl -inkey private_key_1.pem -sign -in WITNESS_V0_DIGEST.txt -pkeyopt digest:sha256 | xxd -p -c 256`

SIGNATURE="${SIGNATURE}01"

Now I can create my transaction like this:
020000000001019b32b170b988cd26b5f40312b2f75534dba92e8668ed438ea489b72e5f4137020000000000ffffffff017cee052a01000000160014f545040775837a55962bb8abfcc341f574d679170347304402202d7d72d425e407160554e9c29688164a7e5c2f380c86e26c0595a7c6c8d526df02206ff13970212a77d6febcdcdcc2945db3947f02137324ae7d822b4fa7f81292100121024633c32245c6709e7f756c41e0f163919fa00977798f30245d3498f88c53e8941976a91427275283377b40957701cecd37d2e170c41d387488AC00000000

It's the decoded version
     {
  "txid": "23704afa715351b1d1810f41015fd3bfc33fed75842530ae0c00564eb7f16103",
  "hash": "5f6b1edafdd814d8c9ec85bad6125dbf2efbb245c28017b62ee4aa35ab712789",
  "version": 2,
  "size": 217,
  "vsize": 116,
  "weight": 463,
  "locktime": 0,
  "vin": [
    {
      "txid": "0237415f2eb789a48e43ed68862ea9db3455f7b21203f4b526cd88b970b1329b",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "304402202d7d72d425e407160554e9c29688164a7e5c2f380c86e26c0595a7c6c8d526df02206ff13970212a77d6febcdcdcc2945db3947f02137324ae7d822b4fa7f812921001",
        "024633c32245c6709e7f756c41e0f163919fa00977798f30245d3498f88c53e894",
        "76a91427275283377b40957701cecd37d2e170c41d387488ac"
      ],
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 49.999991,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 f545040775837a55962bb8abfcc341f574d67917",
        "hex": "0014f545040775837a55962bb8abfcc341f574d67917",
        "reqSigs": 1,
        "type": "witness_v0_keyhash",
        "addresses": [
          "bcrt1q74zsgpm4sda9t93thz4les6p746dv7gh4jhqxz"
        ]
      }
    }
  ]
}

But when I try to send it (sendrawtransaction), I get this error:
error code: -26
error message:
non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) (code 64)

Where SCRIPT-CODE is my UTXO scriptpubkey hex (witness version-witness program) Then I "merge" all values like this:

This is your problem. Like P2SH, the scriptCode for P2WSH is not the scriptPubKey. It is the script that that P2WSH output has the hash of. So the scriptCode is the witnessScript in this case, not the scriptPubKey.

thanks for reply. I tried with witness script instead of hash (I'm using p2pkh for script) then my scriptCode become (SCRIPTCODE: 76a914b32be131fb46d9e937f52be3fff9df7e4cca63cf88AC). But I get the same error non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) (code 64) thanks!

Can you edit your question with the results of doing that change?

sure! I updated my question. Thanks

The scriptCode needs to be length prefixed with a compact size unsigned int.

thanks again for your time, I added the scriptcode length (19) but I have the same problem. I updated my question. thanks !

What is the actual UTXO you are spending? I think the next thing that might be incorrect is the amount. It looks like the amount you gave is the output value, That's probably incorrect unless you are intending on paying no transaction fees.

Thanks for your time. the UTXO is the coinbase (genesis block) I use regtest to test my script. I fixed with the total amount (00f2052a01000000 - 50 bitcoin) but I have the same problem. thanks !!!!

Now your hashOutputs is incorrect. You are using the wrong amount in that hash. hashOutputs is the hash of the outputs as they are serialized. For each output, it's its amount followed by the output script, regardless of the amount for the input being signed. What you have done is used the amount for the input being signed. This is incorrect. In hashOutputs, you need to use 49.99.... In the sighash amount field, you need to use 50.

thanks again and again. I (you) resolve it!

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
can not access via RPC to litecoin node
I set up a litecoin full node in AWS. I opened ports 22, 80 and 9332. Also from my laptop I cloned this project https://github.com/janoside/btc-rpc-explorer
I executed on my local but unfortunately I don't reached my litecoin node but instead if I deploy the btc-rpc-explorer in the same litecoin node it works.
The error I got when I executed in local is the following (IP have been obfuscated)
Unhandled Rejection at: Promise Promise {
  <rejected> { Error: connect ECONNREFUSED XX.XXX.XXX.XXX:9332
    at Object.exports._errnoException (util.js:1018:11)
    at exports._exceptionWithHostPort (util.js:1041:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1090:14)
  cause:
   { Error: connect ECONNREFUSED XX.XXX.XXX.XXX:9332
       at Object.exports._errnoException (util.js:1018:11)
       at exports._exceptionWithHostPort (util.js:1041:20)
       at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1090:14)
     code: 'ECONNREFUSED',
     errno: 'ECONNREFUSED',
     syscall: 'connect',
     address: 'XX.XXX.XXX.XXX',
     port: 9332 },
  isOperational: true,
  code: 'ECONNREFUSED',
  errno: 'ECONNREFUSED',
  syscall: 'connect',
  address: 'XX.XXX.XXX.XXX',
  port: 9332 } } reason: { Error: connect ECONNREFUSED XX.XXX.XXX.XXX:9332
    at Object.exports._errnoException (util.js:1018:11)
    at exports._exceptionWithHostPort (util.js:1041:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1090:14)
  cause:
   { Error: connect ECONNREFUSED XX.XXX.XXX.XXX:9332
       at Object.exports._errnoException (util.js:1018:11)
       at exports._exceptionWithHostPort (util.js:1041:20)
       at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1090:14)
     code: 'ECONNREFUSED',
     errno: 'ECONNREFUSED',
     syscall: 'connect',
     address: 'XX.XXX.XXX.XXX',
     port: 9332 },
  isOperational: true,
  code: 'ECONNREFUSED',
  errno: 'ECONNREFUSED',
  syscall: 'connect',
  address: 'XX.XXX.XXX.XXX',
  port: 9332 } stack: Error: connect ECONNREFUSED XX.XXX.XXX.XXX:9332
    at Object.exports._errnoException (util.js:1018:11)
    at exports._exceptionWithHostPort (util.js:1041:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1090:14)
Using exchange rate: 30.3812015012 USD/Litecoin starting at Sun Jan 13 2019 22:54:28 GMT+0100 (CET)

Do you know what I need to do to access the litecoin node from my local computer using this btc-rpc-explorer project? Thanks in advance
UPDATE: command netstat -tnlpu
Return this:
command netstat -tnlup
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp6       0      0 :::22                   :::*                    LISTEN      -
udp        0      0 127.0.0.53:53           0.0.0.0:*                           -
udp        0      0 172.26.6.153:68         0.0.0.0:*                           -
And in the AWS rules I have specified to let connections from ports: 22, 80, 9332. Any idea?

Is the node fully synced? If not, you should wait. Could you post here the listening ports on the node ? # netstat -tnlpu

I finally found how access the node from my laptop I just adding the following to the litecoin.conf file
rpcallowip=0.0.0.0/0
I saw it in this Answer


text:
How can I detect which customer has made a payment using only one receiving address?
How can I detect which customer has made a payment using only one receiving address?
Can I embed a unique special message in the QR code (like a nonce) which I'll match against my database? Does it make any sense or is it too problematic (bitcoin client not embedding the message, unable to read the transaction message from the blockchain, etc..etc..)
If that's not an option, does it make any sense to embed a unique code on the least significant satoshis? (let's say the last 3 satoshis if I expect on average less than 1000 transactions occurring at the same time)

I assume you're asking how to detect which customer has made a payment?

yes exactly, how to detect which customer. I edited the title

If you're going as far as wanting to change the QR code for each customer, why can't you just give each customer a unique address? That's the only guaranteed way.

I don't  have an instance of bitcoind available. maybe a pool of many addresses could be a viable solution

Is there a specific reason why you can't give out more than one address?

I can't create new addresses on the fly

So, perhaps your actual question is "How do I create new addresses on the fly but keep my private keys safe?"? :) Otherwise, if you say no more than 1000 transactions occurring at the same time, you might be able to solve it by having several thousand in the backlog.

I assumed I can't create new addresses while not storing the private key on the website. I'm talking about a php webapp

That assumption is not correct. ;) There are ways to derive any number of public keys from a master public-key. The php library that UTF-8 suggests below can do that.

You said you can't create new addresses on the fly but you also said you're using PHP. It's really easy to do it, just take a look at bitwasp/bitcoin-lib and give out a new address for every purchase. You can also create a functional mapping between a purchase id in your database and a bitcoin address really easily so you don't have to store the address used for each purchase.
Using the least significant digits of a transaction is a really bad idea. Not only because that'll cause a lot of trouble if people don't pay but also because you can't be sure that the wallets of all your customers support sending a very precise amount of BTC. Furthermore you'd have to discourage people from simply rounding up because they're too lazy to type in the exact value (if they have to type that in).

brilliant! so I can create a bitcoin payment processor using php and a cron job (no bitcoind daemon required). I always forgot that an address is not a public key

so basically given a generic transaction id I can deterministically derive the corresponding address (for a specific public key)


text:
Ludicrous transaction fees from Coinbase?
I moved 0.16 BTC from my Coinbase online wallet to another one. I got 0.0017 BTC of transaction fees which looks a little bit too much. I was expecting an order of magnitude less, something like 0.00017 BTC
How Coinbase work out the fees? Is it possible to choose from different fees options?
EDIT:
I just moved a much higher volume of BTC at almost no fees, very weird :-)
Why Coinbase doesn't let the user choose the fees?

There 4% fee is a joke, what alternatives are there?

Coinbase likely calculates the fees dynamically based on the current fees being included in recent blocks. This is to keep your transaction competitive so it makes it into a block. One of the worst feelings is when your transaction is sitting there for days unable to make it into a block because the site you sent from didn't use high enough fees.
Is the fee you're reference the fee you actually paid, like your 0.16BTC ended up only having 0.1583BTC? My guess is your looking at the total batch fee on the transaction your BTC was included in rather than what you personally paid. I haven't seen my bitcoind fees as low as 0.00017 in a long time, 0.0005 is more like it at the moment, but like you say 0.0017 does seem high, especially if it that was paid entirely by you.
Its possible recent blocks contained significantly higher fees that caused Coinbase to jump their tx fees as well. As we know with the 1MB block limit, transactions have been experiencing high competition to get included in a block. But my suspicion is you're looking at the total fee for the tx that Coinbase sent out (which would include other peoples addresses).
From Coinbase: https://support.coinbase.com/customer/en/portal/articles/815435-does-coinbase-pay-bitcoin-miner-fees-?b_id=13521

Yes, Coinbase pays the miner fees (typically 0.0003 BTC) on external
  transactions in order to ensure these transactions propagate
  throughout the bitcoin network quickly. For very small transaction
  amounts you may be prompted to pay the transaction / miner fee.

This claims you shouldn't have paid a fee at all. Is it possible you're just looking at the TX fee that Coinbase paid for your transaction?

the destination wallet has received 0.0017 BTC less than the original amount so I guess I paid for it

@GianlucaGhettini Did they prompt you like they say on their support link? If not I would contact support and ask for a refund. That fee is way too high and you were under the impression they covered the fees based on their website stating they do so.

@Brandon The bottom of your answer is outdated.

Use Gdax from now on. Deposit I to gdax. No fee. Iyts wallet is connected to coinbase. If you respond into gdax. And look on coinbase you will see the money in the wallet.

GDAX today known as Coinbase Pro


text:
Is there any rational economic reason to purchase XRP early?
Deflation is a main economic reason to buy bitcoins earlier. However, is there any rational economic reason to purchase XRP early? As far as I know OpenCoin is not clear on distribution policy. The might be giving away billions of XRP at some point.

1) OpenCoin has been clear on how many XRP they are going to distribute, they have been secretive only about how they are going to do that. And that's fine, since otherwise people might try to game the system before their distribution starts.
2) You might buy a few XRP if you need them, or you can buy a lot of XRP if you want to speculate (i.e. you think their value will rise)


text:
What happens if an exchange's order book has only Market Orders
If a bitcoin exchange offers Market Orders, let's suppose there are X buy orders at market price, and Y sell orders at market price  (no limit orders):
How are these matched and at what price, since there is no "lowest or highest" price currently on the order book?

Then, all trades would be executed at the last trade price. Price remains the same irrespective of trade volume.

@vi.su, I've never seen that documented to occur that way and would argue that is not correct according to the definition of a Market order.

Is this a Bitcoin question?

@StephenGornick, I am not sure. but, per your answer, there would be no trades; yet there are buyers and sellers who are willing to trade at current market price.

Market buy order means buy for whatever is current lowest ask. Market sell order means sell for the current highest bid. Market orders should be executed as long as there is any buyer and seller, but may not be filed for the desired quantity. In the case that there are no limit orders on either side, market maker would establish a spread for profit. In fact, market makers profit from market orders and existing limit orders spread also in ordinary circumstances.

Factual crap. You can not have 2 market orders active at the same time - a market order is executed against whatever is in the book on the other side. THEN then ext order is put in. 2 market orders would NOT define a spread as a spread requires fixed prices. Fail on the basics how exchanges work.

This situation would not exist. True market orders (buy or sell) cannot just "hang" around. If they are not executed immediately against existing limit orders, then they should be cancelled. The case in which they would not be executed would be if there are no orders on the other side. In which case it depends on how the system handles the orders but it should either say it can't fill it and never place the order to begin with.

That pretty much is it. A good exchange processes order requests in sequence. A market order is seen, processed, then ends either filled or in an error condition. A limit order gets entered into the queue. As such, it is not possible to only have market orders. THAT SAID - you may as well have no market order at all. CME does that (not bitcoin, a real exchange). A market order is transformed, internally, into a limit order with the limit on the other side. That stops brutally runaway pricing.

Contractually, the market BUY order had no SELL (ASKs) to trade against.  So that order remains unfilled.
At the same time the market SELL order had no BUY (BIDs) to trade against.  So that order also remains open.
And they remain open until either cancelled or until a limit order arrives.

Uh? No, this doesn't make sense: if they are market orders, and there isn't anything in the order book, they should just be rejected. Market orders shouldn't fallback to limit orders, as this answer seems to imply. AFAIK.

Actually they do on real exchanges. CME has no market order - a market order is internally seen as a limit order with quote some limit. This allows a market maker to pick up the "remaining".


text:
A question about private key
The private key of Bitcoin is a 256 bit binary number or a 64 bit hexadecimal number. Why isn't my 64 bit Bitcoin private key in hexadecimal? It starts with 'G'. How can I obtain the correct private key through this string starting with 'G'? Thanks
To my knowledge, the format of a Bitcoin private key should be a binary number of 256 characters, a hexadecimal number of 64 characters, a string of over 50 characters encoded by BASE, or a string starting with "5" encoded by WIF. However, my private key is a string of 64 characters starting with "G", including uppercase letters and numbers. I don't know what encoding or encryption it is, so I am unable to use it now. If you can help me retrieve Bitcoin, I am willing to give you a portion of Bitcoin
Additionally, I can confirm the authenticity of this private key because it was obtained from an early image that was a screenshot of a software or website and had the words' private key 'on it.

This question is similar to: What are the formats of a private key?. If you believe it’s different, please [edit] the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem.

See also Private key to WIF process


text:
where is located the implementation of getaddressutxos method of litecoin rpc
Hi I have started to play with litecoin node making queries via rpc using litecoin-cli. There are some methods that caught my attention and have something related to "addressindex" these are:
getaddressbalance
getaddressdeltas
getaddressmempool
getaddresstxids
getaddressutxos
I have looked for them in github litecoin-project but I haven't found where is the implementation. Probably I haven't searched in the right place or missed something in the way are called so. Would you help me to find where is the code that implement those methods? Also have you an idea why those methods are not present in Bitcoin? from my perspective are very useful. Thanks in advance
-- UPDATE --
According to this link the methods are already present in Bitcoin. Anyone has an idea at which version they were added? and of course the location

These methods are not present in Bitcoin Core. Bitcore is a separate project which has an (unmaintained) patch to add them.

Finally I have found out that those method are part of the project [link] (https://github.com/litecoin-project/litecore-litecoin) and of course @pieter-wuille was 100% right, that's why those methods doesn`t appear on litecoin and bitcoin core  projects.


text:
Non indexing bitcoin and output lookup
Using bitcoin's RPC and txindex=0 is it possible to tell the difference between an existing output being already spent and a non existing transaction output (or transaction id)? Looking at gettxout it's not enough as it would return empty data in both scenarios.

There’s functionally no distinction between an output which doesn’t exist, and one which hasn’t existed from the perspective of validation. The node never needs to consider this so by default it stores no information about it.


text:
Is there anything preventing Lightning Network from passing embedded data in OP_RETURN?
As long as you pay a BTC fee for all the routing node incentives and the last layer in the onion routing includes a transaction with OP_RETURN, wouldn't that allow using OP_RETURN for various applications?
I realize the current implementations don't do this, but am I missing if there's anything that prevents it fundamentally?
Thanks!
(If the issue is that the local channel at the end won't keep track of OP_RETURN on next update, couldn't the last transaction include virtually opening a channel to the original node (the person who sent it originally) that is OP_RETURN-aware and thus would keep updating it?)

It's not in the current lightning specification to create OP_RETURN outputs but there is nothing that prevents a similar payment channel protocol to include this. The OP_RETURN in subsequent channel states would have to be valid according to your protocol/application. What do you mean with the local channel not keeping up with OP_RETURN and the last transaction opening a channel to the original node?

Not sure if I might miss a point of your question. But to me it seems that what you suggest is conceptionally not possible.
Lightning payments work fundamentally different than Bitcoin transactions. In particular lightning payments themselfes don't have any Bitcoin script inside them. The onion format for the payment is really just an amount, a payment hash and a next hop.
The lightning nodes themselves use the data from the onion to construct htlc outputs in their respective local channels (commitment transactions) this is where Bitcoin transactions are used to fulfill the contracts needed for lightning. The sender however has no influence on the used scripts. So there is no way to squeeze in any OP_CODES

You could design a lightning-like protocol that adds op_return outputs in each commitment tx, all else being equal.

To add to Rene's answer, it is possible to send some additional data with a Lightning payment which does not require any bitcoin script.
A recent update to LND allows additional data to be embedded in an Onion packet in a field called an Extra Onion Blob. The data which can be added is limited by size, and the size depends on the route size used to make the payment. The smaller the route, the more data you can fit in, because the EOB makes use of otherwise unused onion hops in the fixed-size onion packet. In practice this means tens of bytes of data, and perhaps a little bit more than the 80 byte limit of an OP_RETURN. Currently, the EOB is only used for spontaneous payments, but it will support embedding of other kinds data with a type-length-value.
Unlike an OP_RETURN, which is broadcast, the data sent in an EOB will only reach a single destination. If you wish for multiple people to receive it, then you will need to send multiple payments. Lightning supports broadcast type information in its gossip protocol, which can be extended with extra data, but this is really reserved for transferring routing information and clients are free to ignore data beyond what is required, and causing spam over the broadcast network may find you frequently blacklisted.
An obvious next step would be to transfer IPFS handles, or bittorrent magnet links over EOBs, which would enable clients which support these other protocols to receive data of arbitrary length.


text:
How is pool hashrate share name known?
Since it’s not possible to know mining pools nodes addresses, how do we know the that a specific node owing 15% of share belongs to btc.com for example ?

I don't understand your question. Generally it's not known which nodes belong to miners.

@PieterWuille if I understand correctly the hashrate is computed from recent block mined and we known how each block was mined by who through the ɪᴘ of the node used by the mining pool right ? Then how we know that node ɪᴘ belongs to a specific pool ?

The only way to know which pool has mined a particular block is by identifying data that miners include in the coinbase transaction. However care must be taken as this data can be faked. Also many mining pools omits this, which is why there are many blocks that are from "unknown" miners.
Let us take the last block mined by BTC.com, which is #572639. To look at the coinbase data, you will need to look at the first transaction included in the block which is 806e80560f7c87059b9103d8bd4fca7be14810af47940c40464276d971fd2625. After you decode this transaction you will get the following input:
"vin": [
        {
            "coinbase": "03dfbc080479b0bc5c672f4254432e434f4d2ffabe6d6d6b01cdd5d0aa44ffa14f158f90119afef5e5440b5f6ff324e74a988e6db4294d0100000000000000cb2b382f00005a2197460000",
            "sequence": 4294967295
        }

In the coinbase data, pay close attention to the part 5c672f4254432e434f4d2f. This data is included in all blocks mined by BTC.com pool. If you decode this you get '\\g/BTC.com':
>>> pool_data = '5c672f4254432e434f4d2f'
>>> bytes.fromhex(pool_data).decode()
'\\g/BTC.COM/'

The share of hash rate of mining pools which some websites display is an approximation based on who has mined recent blocks, and not an accurate measure of actual hash rate.
When a mining pool constructs a new block template, they can optionally include their name inside the coinbase, which is used in place of the scriptSig on the input of the first transaction in the block, and can include arbitrary data.
The websites displaying pool statistics simply extract this information from each block's coinbase and aggregate it for N preceding blocks. There is no requirement to include the information, which makes up the "unknown" miners, and there is also no obligation for anyone to be honest about who they are, so anybody successfully mining a block could claim to be somebody else.

is an approximation based on who has mined recent blocks that’s the point of the question : how to know who mined a specific block ?


text:
Are there still miners or mining pool which refuse to implement SegWit?
It was well known that initially while SegWit got more than 50% of hashrate after activation that a part of the mining pools refused to implement it.
But are there still blocks being mined by miners which refuse to implement SegWit more than 2 years later ?
For example, is this article or this article still true ?

Hey ! Why the downvote ? The question is only about those who do it.

Don't know why someone downvoted, but here's my question: SegWit2x required 80% of the hashrate signaling readiness to activate and it is reasonable to assume that generally all software that signaled readiness for SegWit2x (e.g. Bitcoin Core or btc1) was actually segwit-capable. IIRC, at activation more than 95% of the blocks were signaling segwit support. So, I'm wondering what you mean when you say "It’s well known that initially while SegWit got more than 50% of hashrate after activation that a large part of the mining pools refused to implement it.".

@Murch ok sorry. Removed the large word. I thought to have read in the news that 30% or 40% of miners in terms of Hashrrate refused the SegWit implementation at activation time but it was still a success.

You could look at the coinbase transactions of the last blocks to get some data: segwit enabled blocks commit to the witness txids by adding an op_return output in the coinbase transaction. (I think they always add that, but it might only be there if there is at least one segwit transaction, i.e. not present on empty blocks).

@Murch You could look at the coinbase transactions of the last blocks the problem is I don’t know how to do this too.

If it's well known then there is no reason to ask a question about it.

@G.Maxwell sorry. But thank you, my point is rather “it was”.

I don't know about any refusal to implement after it was activated.  The only thing like that I know of was bitmain's himming and hawing at first and F2Pool being stuck on a seriously outdated version of Bitcoin because they were on a seriously outdated OS that couldn't handle C++11. Both of those were before activation.

@G.Maxwell As far I’m aware the Bitmain’s Antpool Saga started after a full year of SegWit activation. But we’re in 2019 now, I’m wondering if it’s still the case.

I don't think it was the case even shortly after activation either. Its important to distinguish enforcing SW rules from including the txn... the latter required a bunch of updates to mining infrastructure but isn't relevant to consensus. No one has produced a SW invalid block that I'm aware of which is really the only strong test of enforcing the rules.  But all notable miners include transactions using segwit now (they're be missing a lot of fee income if they weren't).

@G.Maxwell no they wouldn’t be missing fees. If they don’t, they would just process the transactions as anyone can spend. But this isn’t a proof no miners are still refusing SegWit as nodes don’t relay those type of pre‑SegWit transactions anymore.

They can't because that would be a SW invalid block.

@Murch no. And as far I’m aware SegWit is both backward and upward compatible in terms of block generation. The protection is mostly from nodes not relaying transactions to miners.

Segwit transactions are backwards compatible in that they can be stripped off the witness and then appear valid to non-segwit full nodes. However, stripped transactions are incomplete in that they're invalid according to the rules of segwit. Including a stripped segwit transaction would be a breach of the consensus rules. Every segwit enabled full node would recognize that block as invalid and reject it.

@Murch if it was true, then it would means if a miner who refuses to implement SegWit treats a SegWit address as anyone can spend as sender they're would be a hard fork. As far I understand SegWit was designed so that they would be no hard fork either from the side implementing SegWit and the side refusing to do it.

Segwit transactions appear non-standard to non-segwit nodes. They do not propagate them and do not include them into blocks. If a miner did indeed include a stripped Segwit transaction, it would simply cost them the block reward because they mined an invalid block.

@Murch If a miner did indeed include a stripped Segwit transaction, it would simply cost them the block reward because they mined an invalid block. Yes and other miners which don’t implement SegWit would treat the block as valid instead of rejecting it, hence a hard fork (hypothetical as we agree nodes wouldn’t relay such transactions).

Undoing soft fork is always(*) a hard fork.  They'd simply be ignored by everyone else.  Murch's descriptions are (as usual) spot on.   (*undoing doesn't include things like a rule that expires on its own as part of the rule itself).

@G.Maxwell And as far I’m aware, the plan with SegWit was to not have a possible hard fork as result of the change.

That doesn't even make logical sense: No consensus rule change can have the properties you're expecting.   Segwit-- like other softforks-- was designed to not split the consensus and it didn't.  That is accomplished by two main properties: It is a strict increase in restrictiveness (making it backwards compatible-- not a hardfork) and it was triggered by forward compatible encoding (cleanstack rule in segwit's case) making it so that old nodes won't accidentally relay or mine invalid transactions.

Comments are not for extended discussion; this conversation has been moved to chat.

No, in the past year, there were only 15 non-empty-non-segwit blocks mined which account for less than 0.03% of all blocks.
Non-empty blocks without segwit transactions

I've looked up the last twenty blocks that confirmed transactions but did not include any segwit data. The newest of these was mined on 2018-12-18, more than four months ago. The 21st-newest block in that series was mined on 2018-03-13 at height 513,267.

Given that we're currently at height 573,220, there were only 20 non-empty blocks that did not include segwit transactions among the last 59,953 blocks. Or put differently, over a period of time exceeding the past year, there were fewer than 0.034% non-empty-non-segwit blocks mined.
The two known miners that created such blocks without segwit transactions appear not to be doing that now:
Bitcoin Russia's last ten blocks were segwit blocks.

Bitcoin.com's last ten blocks were segwit blocks.

Empty Blocks
I did not count empty blocks (blocks that contain only a coinbase transaction) as the coinbase transaction has no inputs and therefore cannot be a segwit transaction. However, BIP141 specifies that the Witness Commitment is optional if there is no segwit transaction included. Therefore, there is no reliable way to determine whether or not an empty block is segwit or non-segwit.

Images via blockchair.com


text:
How to get the raw signature data of a transaction?
With the use of segwit, signature data is no longer part of transaction body and thus can’t be retrieved from block explorers. So is there a Bitcoin rpc method in order to get it directly without having to extract it from transaction manually?
My aim is to retrieve the public key behind segwit Bitcoin addresses from EC signature which requires the signature along signed data.

With the use of segwit, transaction data is no longer part of transaction body

That's incorrect. It's just not covered by the txid, but it's still an integral part of a transaction. Every updated full node will download the witness data, and if they're storing blocks, also remember the witness data.

and thus can’t be retrieved from block explorers.

That would only be the case of the block explorer doesn't support segwit.
For example, here is a recent segwit transaction (with witness data included) on blockstream.info.

So is there a Bitcoin rpc method in order to get it.

Sure, getrawtransaction will give it to you (it needs the txindex=1 config option, though).

I wanted to mean signature data of course. Not transaction data. Please see my last edit.

I assumed so; signature data is what my answer is about.

but getrawtransaction is for finding the signature manually. Something I don’t know how to do. I just want to perform pay to pubkey transactions wothout asking the pubkey to addresses and as far I understand, recovering the pubkey from EC signature is the only way to do that.

You're confused in multiple ways. 1) You don't need to recover public keys from the signature - they're directly revealed in the witness (scriptSig for non-segwit transactions, witness stack for segwit ones). 2) You'll need getrawtransaction regardless of what you want to learn about a transaction. 3) You absolutely shouldn't be trying to determine the "sender's public key" of a transaction and use it for anything but debugging. Multiple parties can collaborate to construct a transaction, and there is no way (intentionally) of telling who is who. If you need a pubkey, ask them.

this is for figuring the answer to this question https://bitcoin.stackexchange.com/q/98779 myself. About your concerned about who is who, this is of course about used adresses.

I don't really understand what you're trying to do. Why do you need to figure out the public key for a used address, except for debugging purposes? You shouldn't try to reuse keys.

I want things to be tracked easly for accountability. Privacy isn t something I want to use.

Why do you need other people's public keys for accountability?

that s my general rule not specific to the current case. This just means I don t care about privacy.


text:
Does getreceivedbyaddress or listreceivedbyaddress or listunspent shows pay to pubkey and bare mutlisig transactions?
Couldn’t find the answer inside the source code.
If I receive a pay to pubkey transaction to the pubkey of a 1r address, will it shows up using getreceivedbyaddress or listreceivedbyaddress or listunspent? Or will it ignore the coins received that way.
The same question apply when 1-of-n bare multisig.

In the Bitcoin Core wallet, it depends:

For P2PK outputs to a public key that's in your wallet, yes for current wallet versions, but this won't be the case for the new "descriptor" wallets (unless explicitly imported).
For bare multisig, only when explicitly imported. Before PR 13002, bare N-of-N multisig was automatically treated as incoming payment (in case you had all N private keys). Since that PR you need to explicitly import these scripts to watch them.

For other wallet software, things may be different.
In general, you cannot assume that anyone will ever treat an incoming transaction as a valid payment, unless it was sent to an exact address they gave you (or you have some other explicit arrangement). Which scripts/addresses a user considers "theirs" is up to them, depends heavily on the software they use, and not something you can infer.

So do you mean that before the pr that it wasn t enough to be able to spend automatically the outputs in bare multisig and that all of the 3 keys of bare multisig 2 of 3 transaction has to be inside the wallet?

I don't understand your question. If you explicitly import a script, you can watch whatever you want in your wallet. Before that PR, some bare multisigs were automatically watched (N-of-N ones where you had all private keys).

Correct but I m thinking about use cases where everything has to be implicit and automatic. The only thing that has to be done from the receiver end is generating a payment from a new address.

You cannot assume that anyone will ever treat an incoming transaction as a valid payment, unless it was sent to an exact address they gave you (or you have some other explicit arrangement). You can't send to public keys extracted from transactions, you can't even send back to the "sender" addresses in incoming transactions that pay you - the address may be of a joint wallet or website rather than crediting the specific person who sent things to you.

what you describe depends on the address type.

No it does not, sorry.

For an addres to be owned by several parties yes. Otherwise what do you mean by descriptor wallets?

You cannot tell from the address or the address type whether it belongs to a person directly, or whether it belongs to say a web wallet that manages multiple people's funds. Sending to such an address - even a P2PKH 1xxx one - could result in any of the site's users being credited. Transactions can also have multiple inputs, each with their own "previous output's address", who belong to multiple people. Descriptor wallets are new Bitcoin Core wallet version, which is still being developed.

In my case I know it s about a web wallet where each address is linked to only one account.

In that case you should probably ask these questions to the operator of said website, not here. What scripts/addresses they credit is entirely up to them.

One last thing since a wallet.dat supports multiple accounts, when you say all the keys before the patch for multisig, is it per account only or for the wall wallet.dat?

Bitcoin Core's account feature was deprecated in 0.17.0, and removed in 0.18.0. Bare multisig is no longer automatically watched since 0.16.0.

I was meaning before the 2018 patch of course.

It used to be for the entire wallet.dat.

And per my understanding, the current code still  requires to own all the keys if watched, right?

Single-key addresses are automatically watched for private keys you have yourself. Beyond that, anything needs to be watched explicitly (through importmulti, importaddress, ...), but watching doesn't require having keys.

So do you mean that it I m having only non multisig addresses where I own the private keys that this patch doesn t change anything? That the patch change the behavior only for the addresses where I m only having the public key?

Or rephrased, does it means I don t have to watch manually the single key address where I do own the private keys?

You do not have to watch single-key addresses where you have the private key. That would be extremely surprising! It would mean you create a wallet, and then need manual steps before you can see incoming transactions.

I was talking about receiving bare multisig to single key address not about receiving pay to pubkey or pay to to address. Are you sure to understand what I meant?

By single key address I only mean P2PK, P2PKH, P2WPKH, P2SH-P2WPKH. Bare multisig is never automatically watched.

So again, per my understanding, the current code still requires to own all the keys for bare multisig if watched, right?

No it does not. You just need to import the address/script. You only need the private keys for automatic single-key address watching.


text:
Can cryptocurrencies like Bitcoin be turned into a censored payment system under that would be financial regulation framework creating soft forks?
It s well known mining pools as well as hashing power is centralized in countries where electricity is cheap and using mining farms rather belonging to at least medium sized companies than single hand individuals.
In the same time, it s worth noting most countries have their fincen equivalent linked with other agencies preventing payment processors like banks or visa or paypal from accepting some transactions coming from to or from specific individuals or countries under sanctions like North Korea.
So imagine after a round of negociations, an agreement modifying current Bitcoin s consensus rules for preventing a common set of Bitcoin address (changing dynamically) from spending their money is found. Then the following framework can be set (the number of countries reaching the agreement have to represent more than 50% of the global hash power). This means after regulating fiat exchanges, this is mining which becomes regulated. It might even be done through Interpol.

Mining pools as well as miners using them are recognized as playing the role of banks (processing transactions) in the traditional system and therefore are not only required to not mine transactions from specific addresses but also to reject blocks directly containing or reffering past blocks containing such transactions. This would be implemented through soft forks. With the existing laws, in many countries this can be done using a decree.
In order to enforce compliance, a lightweight process is implemented where instead of registering with the related agencies, records of addresses are updated on a website and miners and mining pools need to declare as well as be able to prove which blocks they mined or helped to mine (through mining pools) when filling their tax returns related to mining income.

Of course, that s not to say there s would be a fierce backslash attempt as a result, and that many mining pools would choose to move to safe countries. But ultimately, the rule of markets would apply, and miners having the cheapest cost of mining would choose mining pools complying with the regulations from their countries in order for themselves to comply with their requirements if they don t produce blocks directly.
In order for such scenario to work, the will to stay on a blockchain which was never hard forked would prevail over the will to resist the resulting soft forks much like what happenned with Bitcoin Cash.
Unlike a plain ban where miners don t have any incentive to accept any rules when mining, this would act as a variant of a 51% attack by a state actor which is not only easier to implement but also easier to accept and attract other states at it.
And the longest chain would be the run by complying companies with better access to cash especially for cryptocurrencies using delegated proof of stake. Additionally, if those governments regulated sort forks works (don t accept a transaction after past blocks), any attempts to include such transactions would result in miners stripped from their rewards.
One of the big benefits is this would also apply to things like Dash or Monero on some cases. leaving only cryptocurrencies using ZsNarks (where even the mining pools have no knwolwedge about the address they include in the block they mine but also the potential utxo).
Under those conditions, would such plan work technically?

It seems that this question may be too specific and technical to fit the Worldbuilding SE. Here, we generally do better with questions that are phrased more openly, focused on "How?" and "Why?". I would suggest that you could rephrase your question in such a manner or split it up into multiple questions. Personally, I find the description of a hypothetical scenario in a wall of text and asking "am I right" to be rather uninviting to potential answerers.

Maybe it would be enough to turn the question around: "How can the Bitcoin project prevent governments from turning Bitcoin into a permissioned system by forcing Bitcoin users to register addresses and only allow payments to these whitelisted addresses?"

@Murch you didn t understand. the main banking system used blacklksts, and the same would apply here. Miners don t have to registers addresses but only register the blocks they received money from.

Since you can use new addresses for every payment, I don't see how blacklists could ever precede blocks including the new addresses.

@Murch that s right. It doesn t prevent one from receiving dark money. It only works at preventing from spending addresses known as tainted. And unlike in the main public banking system for frozen bank accounts, the warrent can t be private as the ever changing blacklist needs to be public. The mempool remains uncensored.

So, you're assuming that the reaction time of a multinational body to agree on adding addresses to a blacklist is faster than that money moves, and that the multinational body would agree on which addresses should be forbidden?

@Murch no. But many times the criminal wait several weeks before laundering the money, and as a result, some address are on a blacklist preventing exchanges of some countries from letting use funds received from them. This is the matter of extending such blacklists or sanction lists to the protocol level. A second limitation is the soft fork/blacklist would have to be common to all countries implementing the policy (unlike current sanction lists which are per country) because of the nature of the Bitcoin protocol, but the Interpol wanted/notice list show it s possible.

In order for the rules to be common (and as explained in my question), the list would have to be dynamically fetched so that it doesn t depends on changing  the Bitcoin core version. This would also allows to remove address (making the money spendable again) in the case the person or the network is arrested (so the police can require to recover the money).


text:
How Would This Procedure Be Performed? Transfer to Offline wallet
I've read alot of questions before I posted this... What I want to do is take my wallet from blockchain.info that contains a few bitcoins, and "store" it offline, however I have some specific questions if anyone can help:

I understand creating a paper wallet from blockchain.info's My Wallet. However, if I do this then won't any sensitive data still possibly be saved on their server(s), therefore rendering the paper wallet not completely secure?
In a partial answer to my first question, they have a way to generate and offline bitcoin address and corresponding private key. So would it be best to do that, and then from blockchain.info's My Wallet should I then send all bitcoins to this new bitcoin address, effectively eliminating any wallet that is saved in my account on that site? If that is the case, then:

would I even need a wallet? If my "paper wallet" shows the bitcoin address and its' corresponding private key, then is that all I need to put in a safe? just the bitcoin address that I sent all coins to from my wallet, and then that addresses private key?
should I delete any backups of the previous wallet that originally had the coins that I sent to this newly created offline address?
should I then close/delete my entire account on blockchain.info?

Forgive me if I sound redundant, but I guess I'm wondering if all I need to do is a "transaction" from my online wallet to a newly created 'offline' bitcoin address? In 10 years, in order to access these coins, I ONLY need that new bitcoin address and its private key?

However, if I do this then won't any sensitive data still possibly
  be saved on their server(s), therefore rendering the paper wallet
  not completely secure

That's absolutely correct. They're generating the key for you, and promising that they're not keeping the key for later. In the case of Blockchain.info, I trust them at their word, but you can never be sure that their site hasn't been hacked, or that you're a victim of a man-in-the-middle attack. The safest way to generate keys is to do it yourself on an offline computer, encrypt them immediately, and keep them offline forever (either in printed or electronic form). That said, unless you're dealing with incredibly large sums of Bitcoin, I wouldn't worry about it.

If my "paper wallet" shows the bitcoin address and its corresponding
  private key, then is that all I need to put in a safe?

Yes. In fact, all you need is the private key. To prove this to yourself, make up a test address and visit bitaddress.org. On the Wallet Details tab, paste in the private key. Confirm that the page generates the address from the key. So all you really need is the private key. Nonetheless, it's nice to keep the address handy. You can send more funds to it, and you can easily check its balance, all without regenerating the private key (and in the process putting the private key on a computer where it might be stolen).

should I delete any backups of the previous wallet that originally
  had the coins that I sent to this newly created offline address

I wouldn't. There is only downside. Suppose you delete your wallet and then realize you deleted the wrong one. Or in the process of emptying your trash can, you also deleted your term paper due tomorrow. Or you accidentally send money to one of the addresses in that wallet (which might happen because you put those addresses in your Bitcoin address book, or a friend had that address and tried to settle your $1,000,000 debt by sending Bitcoin to it). If you understand that having a private key is merely the ability to unforgeably sign a transfer from the signing address to another, then you understand that keeping private keys is power you want to have. And in the case where the corresponding addresses have a zero balance, there's no risk to keeping that power -- if someone obtained your old wallet, they'd find no Bitcoin at the addresses to steal.
Just make sure the old wallet is encrypted with a strong passphrase and offline, and there isn't any risk to keeping it.

should I then close/delete my entire account on blockchain.info

See above. If you don't trust them and worry they kept your private keys, then maybe deleting will help. Then again, if you don't trust them, why would they truly delete your account? They'd just hide it from you and claim to have deleted it.

I need to do is a "transaction" from my online wallet to a newly created 'offline' bitcoin address? In 10 years, in order to access these coins, I ONLY need that new bitcoin address and its private key?

Yes.
You can use Blockchain's product or print off an single address page from http://Bitaddress.org. Send a transaction to the public key and safely store that piece of paper until you next need it. Be very careful, though, because if you lose that piece of paper, you will lose the coins associated with that address.


text:
How to estimate/get network fees via blockchain.info API?
I am using blockchain.info API to send payments. but i need to know that what will I be charged by the network. So any way to get the network fee with specific amount to sent.. or how to generate it to show to user.

i need to know that what will I be charged by the network.

The network doesn't charge you, you decide what to pay the miners, and the miners determine if your transaction fee is high enough to include in the next block or not (since they get the transaction fees).
It doesn't look like Blockchain.info has an API for estimating the fee (it is an estimate, since it is primarily based on transaction volume, it varies). But, you can use another api such as earn.com to estimate a fee rate (in satoshi/B):
Get Market Fee Rate
Recommended Transaction Fees
https://bitcoinfees.earn.com/api/v1/fees/recommended
Example response:
{ "fastestFee": 40, "halfHourFee": 20, "hourFee": 10 }

fastestFee: The lowest fee (in satoshis per byte) that will currently result in the fastest transaction confirmations (usually 0 to 1 block delay).
halfHourFee: The lowest fee (in satoshis per byte) that will confirm transactions within half an hour (with 90% probability).
hourFee: The lowest fee (in satoshis per byte) that will confirm transactions within an hour (with 90% probability).
Estimate Fee
Without knowing the transaction size, you might have to guess. Something with 1 input, and 2 outputs (one for change) might be around 250B.
fee = feerate * tx_size
Make Payment
Then, you can set the fee property when you make a payment.
Making Outgoing Payments
Send bitcoin from your wallet to another bitcoin address. All transactions include a 0.0001 BTC miners fee.
All bitcoin values are in Satoshi i.e. divide by 100000000 to get the amount in BTC. The Base URL for all requests: https://blockchain.info/merchant/$guid/. $guid should be replaced with your Blockchain Wallet identifier (found on the login page).
http://localhost:3000/merchant/$guid/payment?password=$main_password&second_password=$second_password&to=$address&amount=$amount&from=$from&fee=$fee

$main_password Your Main Blockchain Wallet password
$second_password Your second Blockchain Wallet password if double encryption is enabled.
$to Recipient Bitcoin Address.
$amount Amount to send in satoshi.
$from Send from a specific Bitcoin Address (Optional)
$fee Transaction fee value in satoshi (Must be greater than default fee) (Optional)

Response: 200 OK, application/json
{ "message" : "Response Message" , "tx_hash": "Transaction Hash", "notice" : "Additional Message" }

{ "message" : "Sent 0.1 BTC to 1A8JiWcwvpY7tAopUkSnGuEYHmzGYfZPiq" , "tx_hash" : "f322d01ad784e5deeb25464a5781c3b20971c1863679ca506e702e3e33c18e9c" , "notice" : "Some funds are pending confirmation and cannot be spent yet (Value 0.001 BTC)" }

but if you send btc from blockchain.info website it charge less than 0.0001 btc depends upon transaction size... so is 0.0001 btc is static size for every transaction?

It is the minimum fee, but you can pay more if your transaction is not getting confirmed.

Blockchain.info offers a fee API: https://api.blockchain.info/mempool/fees
The response looks something like this: {"limits":{"min":1,"max":75},"regular":3,"priority":50}. To calculate the transaction fee multiply either the value for regular or priority by your transaction size.


text:
Betweeness Centrality LND node
How can one calculate betweeness centrality of your node as mentioned in this video. I would like to take into consideration

base_fee_msat
fee_rate

Is there a smart way to figure out what suites your lnd node?

Lnd itself does not provide the betweeness centrality of your or any nodes. However you access the network with the graph api call and compute the centrality yourself. You can either implement it yourself by following the instructions from the Wikipedia article or you can use a graph lib like networkx that does it with one api call after you passed the network to such a lib.
Also please keep in mind that of corse one can model the weights of the lightning network differently (for example by just taking channels as edges with weight 1) or by trying to model in the fees. When one does so the problem is how to model in the dynamic fee_rate together with the static base_fee_msat` as the resulting fee that one pays would depend on the amount that is being transferred. this amount could change and thus the network would change.


text:
Already finished 89 confirmation still not received in my Electrum 2fa wallet
I sent Bitcoin from localbitcoin wallet to my electrum wallet. Now it's 89 confirmation done. But still now it's not arrived in my wallet. Please help. Thank You  Electrum wallet address :- 3FE82ud16Zgts5gWR8zP7CgxHGLaHqxJWr  ... Txid:-5c6527b1a3b1d99a03c140907c00b0953083bdb3af1a3e7587549ddd9a230ac0

I can verify that the transaction is confirmed, so there must be some issue with your wallet syncing to the Bitcoin network. Are you sure it is in sync?

Yes. It is syncing. I changed it's server many time . Now it's in automatic mode. Also I restored wallet with my seed. Still not received bits in my wallet.

Give it time to sync, as long as the seed phrase you have can derive the address you've listed, your coins are safe. You just need a wallet that is properly synced to the network to be able to spend the funds.

I added a photo of my wallet. Do I need to put my wallet online for receive Bitcoin?

You can receive to an address without needing your wallet to be online, but in order for your wallet to then display your updated balance or spend the bitcoin, it will need to go online to sync with the network.


text:
getbalance and listaddressgroupings inconsistent
I imported a private key from my electrum wallet (testnet) to bitcoincore (testnet) as follow:

In my electrum wallet, I copy the private key associated to the address mmUToPM2vBb2F1ZNcR86J12GxqAbUJtFCr (balance of 0.06 BTC)
Then I import it into bitcoincore:

~# bitcoin-cli importprivkey "the 52 characters private key here" "From Electrum Wallet"

Rescan should be automatic but I ask for a reindex and rescan:

~# bitcoind -rescan -reindex
After a while, I can issue:
~# bitcoin-cli listaddressgroupings
And I successfully get:
[
 [
   [
     "mmUToPM2vBb2F1ZNcR86J12GxqAbUJtFCr",
     0.06000000,
     "From Electrum Wallet"
   ]
 ],
 [
   [
     "2MwBERpNv7JJaW4nVUbQncXjFjG1nFKLYEp",
     0.05000000,
     "test"
   ],
   [
     "2N4AMdXitdYhNdjafzHG61uUdrErExSdhKs",
     0.00498305
   ]
 ],
 [
   [
     "2N6xTkaeuKsQSHCortgxiNvsVXj2Gv1Qy85",
     0.05000000,
     "test2"
   ]
 ]
]

But when I ask for the balance, it returns 0:
~# bitcoin-cli getbalance mmUToPM2vBb2F1ZNcR86J12GxqAbUJtFCr
0.00000000
How possible is that, considering that the rescan has been performed and that the balance is correct in listaddressgroupings? As a result, I am not able to spend bitcoins from this address.
Thank you for you input/insight!
My bitcoin.conf:
txindex=1
addrindex=1
listen=1
server=1
daemon=1
testnet=1

There is no addrindex=1 setting in Bitcoin Core, so what software are you asking about?   What does the listunspent output show?

I used addrindex as I was desperate. My listunspent show the two unspent transactions as expected, both are marked spendable, solvable and safe. Output here.

I use bitcoincore 0.16.3 built from source.

You are using getbalance incorrectly. You have specified an account name of the address that you want the balance for. However this is not how getbalance works. Bitcoin does not use accounts and addresses are not accounts. An account here means an account in Bitcoin Core's internal accounts system which has since been removed.
So your command getbalance mmUToPM2vBb2F1ZNcR86J12GxqAbUJtFCr is asking for the balance of the account named mmUToPM2vBb2F1ZNcR86J12GxqAbUJtFCr, but no such account exists. The account that has the address mmUToPM2vBb2F1ZNcR86J12GxqAbUJtFCr is named From Electrum Wallet. Thus the command you should be using is
getbalance "From Electrum Wallet"


text:
Bitcoin optional fees create transaction ordering problems?
I've tried to find a solid answer to this transaction ordering question and the practical and technical issues that do not seem solved.
My understanding is that after I create a transaction, I can choose to add a fee for miners to pick up my transaction. I submit it to the network for propagation. Miners look in the unspent transaction pool and choose which they want to include in a new block. I saw this Tweet which seems to confirm a transaction ordering problem - using the same transaction input for two transactions with the latter being a high fee and that one confirmed first. I don't understand why several responders seem to to believe this isn't a problem.
https://twitter.com/alexbosworth/status/1028031387201236992?lang=en
I am near 2 stores that accept Bitcoin. I spend an input at Costco with no or a little fee. It hangs in the mempool like above. An hour later I am at BestBuy and spend the same input but include a fee -- and that transaction gets picked up and processed first by a happy miner.
1) Even if Costco waited an hour, there is no guarantee that my earlier transaction will be confirmed in a block in 10 minutes or 210 minutes. It's still too long for BestBuy to wait 5 additional confirmations after the first.
2) There is no guarantee that even if that the first Costco transaction was picked up by a miner, that a second miner that picked up the BestBuy transaction a little later couldn't complete a block which would eventually be in the longer chain. In that case too, the first in transaction eventually gets bounced off the chain.

Let’s try this again.

Fundamentally, this is why nobody should be accepting zero confirmations, until the payment has confirmations it’s not really a payment made. This is generally referred to as double spending, as clearly only a single payment can confirm in your scenario. If stores want to accept payments in an unsafe fashion, that’s their risk to bear and insure for.
Technology like Lightning can be used to make instantly confirming transactions safely if this sort of retail experience is desirable, though this comes with its own hurdles.

That's an excellent answer, thanks! But you seem to say that it can happen but risk can be minimized if you're savvy and experienced (trap for the unwary merchant.) (a) even a low fee is no guarantee of timely processing. Knowing the "right" fee to use presents a high barrier to entry for users compared to the standard fees offered by centralized systems like credit cards - costly perhaps but at least everyone can set expectations. (b) Good point about Lightning. But aren't payment channels more useful for recurring transactions with the same parties and limitations like prefunding?


text:
How do you get a mtgox api key?
I can't seem to find where to get my MtGox api key. I've been linked to https://mtgox.com/settings/apps-and-api, but all I get is a blank page in the "Access" section. Do I need to verify my account in order to get API access? Is there any way I can get API access immediately without verifying my account if this is the case?

Once your logged in go to Security Center and then you will see a tab which says Advanced API key Creation click on that and you will see the permission options, a key name field, and a key generation button.


text:
Why is the hash rate pumped near difficulty calculations?
My question concerns Litecoin, but could apply to any other cryptocurrency.
I was inspecting the Litecoin difficulty chart and saw a pattern that seems to occur regularly: a dip in the hash rate just before a retarget, then a large, artifical pump to set the difficulty higher than it "should be". An example:

Why would miners do this? For maximum profitability, shouldn't miners attempt to keep the difficulty as low as possible? Additionally, why the regular dip just before a retarget?

It's more likely either a quirk of the difficulty calculation, or just coincidence. There's no reason, and indeed no way someone would make spikes like that, short of having massive amounts of reserve hashing power for the opportunity. There's no positive or negative of this sort of behaviour, so it's hard to believe anybody would.


text:
Multi Sig Sub Keys
When talking about HD (BIP-32?) wallets, I hear talk of Multi Sig and Key Derivation / Chains. Is it possible to mix these two concepts?
e.g. I want to store the majority of my coins with a 2 of 3 multi sig wallet, but would like to store a small subset of coins in a child key derived from the 2 of 3 wallet such that if I the child key was compromised, I could use the parent 2 of 3 wallet to spend those funds.
Is this possible or am I speaking gibberish?

I think Copay does this.

I donwloaded Copay on my Android device because I heard rumors as well, but could not figure out how.

configure it in multisig mode with several linked wallets

Yes, it's called HDM (Hierarchical-Deterministic-Multisig).
There's no standard, per se, and the main proponent (to the best of my knowledge) is/has been Vitalik Buterin, of Ethereum/Bitcoin Magazine fame.
There's code in the Python pybitcointools library which allows one to implement this on a low level. The functions are called:

bip32_hdm_script and
bip32_hdm_addr

The format is: bip32_hdm_script([xprv1, xprv2, xprv3...], (0, 1..)), where the xprvs are as a list, and the integers proceeding it represent path derivation (NOTE: the ints must be a tuple). So, 0,1 means k/0/1. Use 1+2**31 for 1H. This function returns the multi-sig redeem script, so you'll pipe it into bip32_hdm_addr (which simply returns the p2sh addresses)
Of course you'll also use the script to sign transactions. There's a useful fork of pybitcointools available with added functionality and regular updates, which could be more useful in this endeavor (vs the sporadically updated source library).

A similar question - Clarification of BIP32 hierarchical deterministic multisig scripts - was recently asked and answered by me too

Thank you for the detailed answer... It looks like I have some reading to do. Do you know if there is a wallet that implements this functionality?

Possibly Electrum 2.0

@zanegray In addition to Electrum 2.x (which I can confirm supports HDM), there's also mSIGNA and Armory (although Armory is not hierarchical/BIP-32 yet). The latter two both require a Bitcoin Core node, for better or worse. There are plenty of online multisig wallets which use BIP-32/39 concepts to achieve 2fa, but it doesn't sound like that's what you're looking for....

@zanegray Check out the edit referencing a similar question


text:
How to disassemble a bitcoin script?
There are many explorers which allows to dissamble a transaction back into opcodes.
But what about scripts which aren’t broadcasted yet like this redeem script :512102974ffd58d960908d6f2930fbcc4aa288580d05b35a70869e9a8ada3d080acf392103ef884166c7bd20324fd7f959dc680989a6a8b0d62c348defa900fcd4d31200f152ae ?

If possible, I’d like something which don’t needs to be installed.

For Googlers, if you have a full node and want to dissemble all scripts of a transaction locally, you can use bitcoin-core.cli getrawtransaction 75b431e0a8c4617ca8adefe593ba66aa30907742b6dc8772761bfe7edabd74b4 true., docs: https://bitcoincore.org/en/doc/22.0.0/rpc/rawtransactions/getrawtransaction/ This produces better output than some online tracker disassembles e.g. https://www.blockchain.com/explorer/transactions/btc/75b431e0a8c4617ca8adefe593ba66aa30907742b6dc8772761bfe7edabd74b4 which sometimes fail to show things correctly for non standard transactions.

bitcoind has a decodescript method.
$ bitcoin-cli decodescript "512102974ffd58d960908d6f2930fbcc4aa288580d05b35a70869e9a8ada3d080acf392103ef884166c7bd20324fd7f959dc680989a6a8b0d62c348defa900fcd4d31200f152ae"
{
  "asm": "1 02974ffd58d960908d6f2930fbcc4aa288580d05b35a70869e9a8ada3d080acf39 03ef884166c7bd20324fd7f959dc680989a6a8b0d62c348defa900fcd4d31200f1 2 OP_CHECKMULTISIG",
  "reqSigs": 1,
  "type": "multisig",
  "addresses": [
    "1CmMoanE9uahYETLahBTGZSFZSQGV8ADrR",
    "12z2brRNYFkqJe3zP58uoiGcLqDxfk6J7r"
  ],
  "p2sh": "34EJTjAmEPbPGXAPQWU7sn4beoZyGTTxBw",
  "segwit": {
    "asm": "0 a45407120f912ef91ecd7e66a27cb4dc106f962172470b1b39c1bb5008898277",
    "hex": "0020a45407120f912ef91ecd7e66a27cb4dc106f962172470b1b39c1bb5008898277",
    "reqSigs": 1,
    "type": "witness_v0_scripthash",
    "addresses": [
      "bc1q532qwys0jyh0j8kd0en2yl95msgxl93pwfrskxeecxa4qzyfsfmsfgd3m5"
    ],
    "p2sh-segwit": "32KAK2XxwcYPc5iu3tNoXv3ksu4Gf3NsH3"
  }
}

This particular script is a multisig script, which happens to require 1 of 2 signatures to be valid

So only one of 1CmMoanE9uahYETLahBTGZSFZSQGV8ADrR and 12z2brRNYFkqJe3zP58uoiGcLqDxfk6J7r is required to unlock funds ?

user2284570, yes

Annoying that it can't handle large hex strings since on CLI, "Argument list too long" on Linux.


text:
After being officially canceled, SegWit2x is live. Will transaction replaying be massive ? If yes what does this means?
As you know, segwit2x was officially canceled last week, but some miners decided to still go forward today, and some exchanges like coinbase plan to support the hard fork.
So things will happen like this for double spending one segwit2x exchanges resume deposits and withdrawals (If I understand correctly) :

The frauder installs 2 bitcoin wallet software on his computer : one supporting segwit2x and another one which doesn’t (both using the same wallet format).
He sends non segwit2x bitcoins to his wallet on his computer.
He backup his wallet file.
Frauder then perform a segwit2x transaction through his segwit2x software to an exchange accepting segwit2x. The transaction being larger than 1Mb block size, it is rejected on the original blockchain and he keeps his balance on the original blockchain but not on the second.
He then replay the same transaction by using his backed up walled through his non segwit2x software to an exchange not supporting segwit2x.
Frauder then converts his segwit2x bitcoins to an other cryptocurrency like Doge or Litecoin, and send them to an exchange not supporting segwit2x (which he converts to original bitcoin).
He does the same operation on the exchange were he sent his replayed transaction (and sends the doge/ethereums to the same exchange he sends his ethereum doge converted from segwit2x).
He then repeat the operation by resending his doubled non segwit2x bitcoins to his wallet on his computer.

So, if I understand correctly, the price of the original chain should go down to zero due to the trivial arbitrage operation described above and price of segwit2x chain should explose, correct ?
So I suppose this means I should get out of exchanges implementing the update, isn’t it ?
If I misunderstood, please explains what transaction replay means.

Considering that no block for Segwit2x has been found yet and the client for it requires special configuration to create such a block, it is unlikely that there will even be a Segwit2x chain for any of this to even happen. Furthermore, that client has an off-by-one error which will likely screw up any other segwit2x clients.

@AndrewChow : Of course, I’m talking about scenario 2 described here : https://blog.coinbase.com/bitcoin-segwit2x-update-b69a1c1e5ece. Otherwise, if what I’m describing is impossible, then It’s impossible to perfom a replay attack ? or am I misunderstanding what is lack of replay protection ?

Downvotes ? Why ?

The title is nonsensical, to begin with.

@eponymous : fixed… Then ? Also did you read the first paragraph ? a minority decided to go forward despite cancellation. https://blog.coinbase.com/bitcoin-segwit2x-update-b69a1c1e5ece

"However, despite these developments, a small number of miners may attempt to go forward with a fork.". In practice, no miners did (so far).

Frauder then perform a segwit2x transaction through his segwit2x software to an exchange accepting segwit2x. The transaction being larger than 1Mb block size, it is rejected on the original blockchain and he keeps his balance on the original blockchain but not on the second.

Note: just because a transaction on the 2x chain is in a block larger than 1MB, that only makes the block invalid on the main BTC chain, but the transaction itself can still be replayed on the BTC chain.

Frauder then converts his segwit2x bitcoins to an other cryptocurrency like Doge or Litecoin, and send them to an exchange not supporting segwit2x (which he converts to original bitcoin).
He does the same operation on the exchange were he sent his replayed transaction (and sends the doge/ethereums to the same exchange he sends his ethereum doge converted from segwit2x).

Up til this point, all you have done is sold your S2X and your BTC for Doge or Litecoin, you have gained nothing extra. This is equivalent to selling both your BCH and BTC for Litecoin after the BCH fork.

He then repeat the operation by resending his doubled non segwit2x bitcoins to his wallet on his computer.

Firstly, he would not have doubled the non-S2X bitcoin. Even if there was trading support for S2X, the price would be much lower than the price of bitcoin so you might only gain a small extra percentage from the sale. For example HitBTC price for B2X is currently 0.034 BTC, so in selling your B2X you would only gain 3.4% more BTC than what you started with.
Secondly, after you have purchased post-fork BTC, you would not get the corresponding S2X coins too. You would only get the BTC that you purchased. So you cannot repeat that procedure. All you have done in the method you outlined is sell your S2X coins for a small amount of extra BTC, which is fine. In general, you only get corresponding fork-coins of BTC you hold at the time of the fork, nothing if you bought them after or sold them before the fork occurred. (Unless, due to no replay protection, the coins could not be separated, in which case you wouldn't be able to sell them either).

Ok so please explains how transaction replay is performed. and why it’s a fraud. Because it seems I misunderstood it.

@user2284570 check out https://bitcoin.stackexchange.com/questions/61212/what-is-transaction-replay-and-replay-protection :) And remember to accept the answer here if it helped

In case of seg2wit2x, does segwit2x transactions would be valid on original blockchain or does transaction replaying only affect one way ?

@user2284570 Segwit2X has no replay protection, so transactions are valid on both ways

So why is it a security issue in that case ?

If someone trys to send S2X coins to someone else, they would inadvertently send the same amount of real BTC to them as well, causing many users to lose funds

why other users would loose funds?

Because they did not mean to send BTC, only S2X, but they sent both without realizing it....

So this is a forward compatible update isn’t it ?

@user2284570 what do you mean, all updates are forwards-compatible, it is backwards-compatibility which is the issue but here the issue is replay protection

: if it’s backward compatible, then it’s like Segwit and you basically acquire bitcoins for less. Or is it impossible to send segwit2x to a bitcoin address ?

They would have been separate coins after the fork, each with a different blockchain. Please don't ask further questions as comments, ask them as a new question :)


text:
What did Deepbit to make their inputs special on transactions?
It seems Deepbit uses a strange format for it’s transactions on the addresses it owned. For example, in this transaction all inputs but 3 comes from Deepbit. Even Bitcoin core can’t decode addresses or scripts from transactions launched by Deepbit.
This seems to apply to all transactions
That time it’s not SegWit. It’s not even Pay to Script since they didn’t exists at that time (and it’s about1Vaddresses). How those inputs are specials, and what’s the purpose ?

Those transactions spend Pay-To-Pubkey outputs. These are not special or strange and are actually the very first kind of outputs to ever exist in Bitcoin. These outputs simply do not have an associated address type which is why block explorers do not show an address for them.
Also, just because a block explorer can't show an address type does not mean that Bitcoin Core can't parse it. Block explorers don't just use Bitcoin Core, and Bitcoin Core actually does not display addresses for inputs.

Ah, it’s because they are pay to pubkey input addresses can’t be decoded ?

Yes. P2PK outputs do not have associated addresses.

Thank you, and what’s the second output address of this transaction : https://blockexplorer.com/tx/eb3b82c0884e3efa6d8b0be55b4915eb20be124c9766245bcc7f34fdac32bccb ?

@user2284570 That looks like one of the (test) transactions for BIP17, which was never adopted (BIP16 was instead).

@PieterWuille How did it pass despite being non standard?

Non-standard is still valid. Standardness is a node relay policy, not a consensus rule. Non-standard just means a node will not relay the transaction. However it is still valid and can be included in a block and nodes will accept it.

That's the point. How can it be included without being relayed first?

By mining it yourself, or having an agreement with a miner/pool to include it.

@PieterWuille but if it’s not in the mempool of unconfirmed transactions in first place, then it can’t be mined ? And as far I know there had never been such kind of agreement between a mining pool and someone else to broadcast transactions that would be rejected.

@user2284570 Standardness is a local policy; anyone is free to run modified software with different standardness rules. And several miners historically have offered including nonstandard transactions for payment.

@PieterWuille which miners historically offered this ?

At least eligius did, but if you mine yourself (which may have been the case for the transaction you're referring to), you can put in a block whatever you want.


text:
How to send bitcoins without paying or with extreme low fees and without having to proove my identity?
Of course, I know it’s no longer possible to get a transaction mined without a miner fee since 2011.
It’s for sending from a single address to a single output address. But I have to split the sending in a large amount of transactions.
I only knows about Gdax which pays the transaction fee for the user (thus making sending transaction free), but it requires sending identity document in order to use it.
This question isn’t about doing it… It’s about getting answer that might explain how to do it without knowing an e‑mail address !
Other questions aren’t asking this so that concern cannot be answered on other questions !

This isn’t a service recommendation question because maybe a way in itself exists for solving the problem.

So you expect to find someone who will pay the fee for you, but not ask who you are?

@chytrik : No ! the question is outdated. This question isn’t about doing it… It’s about getting answer that might explain how to do it without knowing an e‑mail address !
Other questions aren’t asking this so that concern cannot be answered on other questions ! **And as explained in my question nt paying transaction fees is possible.

@PieterWuille this is a way to do it which is also the most likely one (I wouldn’t mind using an e‑mail and a password though)… Or an other way would be how to spend less than 0.09 Bitcoins for making something like 1000 transactions or even not paying any fees at all anywhere.

@user2284570 The obvious answer is to pay the fee. You're asking someone to do it for you.

@PieterWuille I have to exchange 1 Bitcoin against bank transfers over the counter : I know several peoples willing to do it… But I don’t trust them nor they do trust me… So I need to perform cent by cent exchanging : this means too much money in transfer fees (on their side bank transfers sending is free for the Bitcoin recipient)… Getting the fee payed by someone else is possible : Gdax is the proof. But remember this might not be the only way. This isn’t money laundering though : The other party would have no problem to accept police questions.

@user2284570 Perhaps you could set up a LN channel with your counterparty, with a capacity equal to the amount of btc you are trying to exchange, and slowly make LN payments to your counterparty as payments are received. There will be a fee to open / close the channel, but that should sum to much less than 0.09 btc.

@chytrik what’s a ʟɴ channel ? Please remember it’s about real Bitcoins (not Bitcoin fork) : the counterparty uses a system where the only thing I can get from him/her is a Bitcoin address and a price (and he/she see an account number). I don’t send any Bitcoins again until I receive the cents matching the satoshis I sent (usually takes a business day for banks).

@chytrik ???????????

@user2284570 sorry for the acronym, LN = Lightning Network. It is a protocol that runs on top of bitcoin, and deals with BTC as the base asset. Your counterparty will need to be able to accept LN transactions in order for this to work. If you search 'lightning network' you can learn more about how it works.

By a paper wallet from someone in person and wipe it with CoPay app.

It can’t be in person… It has to happen over Internet. There are no cryptocurrency users around me living within the range of 1500Km…

Probably not the answer you are looking for, but you can mine ethereum with GPU and exchange it to Bitcoin on Changelly. This is completely anonymous.

False ! Changelly is a recognized service ! It has helped the police in the past… Whereas in my case you’ll have to find all the different guys to be sure it’s about Cryptocurrency.


text:
What is preventing me from simply constructing a hash that's lower than the current target?
I just started learning about Bitcoin, and something I can figure out is why miners have to use a random process (hashing a nonce) to get lower than the target. For example, if the target is
00000000000001ae00000000000000

why not just produce
000000000000000000000000000001

to become the winner? I have no practical experience mining, I'm guessing my ignorance lies in the requirements of how a hash is produced. If so, where can I find about those requirements? Thanks.

EDIT: For clarity, I mean this in the sense of what part of the technology requires me to use a hash function? Rather than in the sense of just constructing something that looks like a valid hash.

Other nodes checking your hash will notice that you are lying: the hash does not match the calculated hash. The only thing you can do to influence weather your hash matches the calculated hash is to change the nonce and try - this is in fact the proof of work algorithm - change nonce, calculate hash, see if it fits the target and try, try again. You are always welcome to voluntarily choose a harder target but statistically that means other people would be able to find a matching hash before you

Also, you have a slight misunderstanding. The process is not hashing the nonce, it is hashing the block. Of course hashing the block will generate a fixed hash value which may never match the target. The solution? Allow miners to add their own garbage/ignored data to the block - the nonce - then hash the whole thing. If the hash don't match the target you need to change the nonce and retry. In this way it is impossible to pre-calculate the hash using a pre-generated nonce because you have no control over the other data in the block

EDIT: For clarity, I mean this in the sense of what part of the technology requires me to use a hash function? As opposed, to just constructing something that looks like a valid hash.

When determining whether or not a block is valid, each and every bitcoin node on the network will take the header of that block, and run it through a hashing algorithm to see what the output is. If the output is lower than the target value, then the block is valid (assuming that the rest of the block is also valid, of course).
Notice something important: the hash value itself is not explicitly stored in the block. So you cannot just append some fabricated value that falls below the target value onto the block in lieu of a valid PoW. To create a valid block, you must construct it such that all other network nodes can independently verify it as being valid, and to do so, they use a hash function.
As Pieter mentioned, hash functions are unpredictable 'one-way' functions. The only way to find a valid output is by trying a huge number of possible inputs, and 'getting lucky', so to speak.

It's not quite that simple. The hash needs to be resistant to pre-image attacks.

@jpmc26 Any useful cryptographic hash function should be.

@jpmc26 A cryptographic hash function is commonly understood to mean indistinguishable from random, which implies preimage and collision resistant. This doesn't hold for non-cryptographic hash functions.

Hash functions are unpredictable.
You can't simply find an input to the hash function that produces such an output. The only way to accomplish that is by trying lots and lots of candidate blocks as input. If the target is 1000 times smaller, it requires 1000 times as many tries.

Deleted comment. Please see edit to question.