Will ASIC miners hold the network "hostage" and demand a fee for their services? I can see a trend coming where miners will likely hold the network "hostage" by mining blocks with no transactions in them... even when the block reward nears zero. This would leave transactions in the perpetual pending state.

The reason I suspect this will happen is so that miners will need to cover the expense of hardware that will never be recuperated otherwise.

This scenario can also happen if the value of BTC drops to a very low value.

I'd like to understand the variables that would cause a miner, a mining pool, or anything that would cause them to demand a transaction fee in order to accept the transaction.

Question

What ratios, statistics, or variables are useful in tracking what the miners will demand the transaction fee to be?

Some ideas would likely include

Quantity of transactions -vs- fee paid  (the higher the fee, the fewer transactions will be conducted... supply/demand)
Network difficulty "beta"  (a beta is a Finance term discussing rate-of-change)
Blocks that accept no-fee-transactions vs blocks without
Transaction delay time (before being included in a block)
average miner investment in hardware

The 'race to the bottom' is still continuing in the mining market and hopefully will continue. If any of the miners tweaks transcation inclusion like you suggest that would make them less competitive in this market.

The miners have pretty much no power to enforce transcation fees while the market is functioning as intended, so your question is somewhat moot.
If the miners do hold the network hostage that would be a sign that a cartel has formed and the mining/fee market has broken down.

If that happens it may well be that the users and developers will augment the protocol such that the miners are once more 'held hostage' by market forces.

The difficulty evolution is often described as 'difficulty follows price', this does not model the cheapening of the hardware but otherwise describes the market forces pretty well (by assuming that block rewards and fees won't change rapidly).


FPGA/ASIC with general SHA-1 and SHA-2 capabilities With the introduction of ASICs and FPGAs, I am looking to upgrade my rig.  However, I use the rig for academic research involving brute-force SHA-1 and SHA-2 cracking (I am working on make passwords more secure for my capstone project, trying to pay for everything by mining BTC during downtime).

What are my options?  GPU's don't seem like they will matter much longer...

You could possibly buy some FPGA miners.  The ASICs can only do Bitcoin's specific hash function, and won't be of any use for your research.


Is there a flag or specific message in a bitcoin pcap to show us our bitcoin transaction is confirmed or not? Assume that I send a specific value from a source wallet to a destination wallet and simultaneously capture the input and output traffic with Wireshark.

I can extract output address and it's value from captured traffic, but how i can detect (from packets of traffic) that my transaction confirmed from miners?

In the other words, when i check out the bitcoin traffic, i see that the specific value which i sent(and it's output address), exists in some packets with different IP addresses, which i don't know which one is a miner. is there a flag or specific message sent to me that help me to understand that my transaction is confirmed?

A transaction is confirmed when it is included in a block, so you will need to watch for a message that alerts your node (or whatever software you are using to watch the P2P gossip traffic) to a new block, that includes the transaction in question. It doesn't matter if a node run by a miner relays your transaction to other nodes on the network, it only matters that the transaction is included in a block that is included in the longest (most work) valid chain.

Note that the relaying of this information has been optimized through various BIPs, so that the network is not naïvely using more bandwidth than required. This means that a message explicitly listing your transaction as confirmed may never be encountered, instead a node can gain this information implicitly, through the use of their mempool, and computational filters included with the new block message. You should take some time to learn about these optimizations if you're working to understand the network's P2P traffic, there are some questions on here that have more info. This one may be a good starting point.


Login Problems with Greenaddress I need help desperately!   I am trying to get to BTC that is locked in a greenaddress wallet.  I can log into the view only. When I put in the mneumonic & password, the system runs through decryption to 100 percent and then it bombs out and says login failed.  I've contacted or tried to contact support for help and they say things like that it's not mapped properly or  the fact that I can get in to see it but just not touch the actual account only proves that one exists!  I have the NLock Times zip file.  Can you please help me?  I don't know at all what to do to try to recover these funds. I have a PC running Windows 10 and don't know anything about code, programming languages or any Unix based systems or how to use or run anything like that.  I can pay someone if they can help retrieve these BTC's from the greenaddress wallet to sweep to just about anywhere else on God's green Earth.  Please please can someone help me?  Thank you so much.

If any of the steps fail, comment below, I'll try to help.

1) Follow the tutorial here to install Ubuntu for Windows

2) Set your Username and Password

3) Type

sudo apt-get update -qq

After commands that start with sudo, it'll ask for your password. You'll need to type it, but it won't be shown on screen for security. Press enter.

4) Type

sudo apt-get install python3-pip python3-dev build-essential python3-virtualenv virtualenv -yqq

5) Now, in Windows, visit https://github.com/greenaddress/garecovery and download it via "Clone or Download -> Zip" Move it to your desktop

6) Go back to the Linux terminal. Type cd with a space after it. Drag & Drop the unzipped folder. Now, press enter.

7) Type and enter

pip uninstall enum34
virtualenv venv
source venv/bin/activate
pip install --require-hashes -r tools/requirements.txt
pip install .

8) You can now continue the final step, which is located here


Can someone explain the pitfalls of NXT Proof of Stake's potential issue of "nothing at stake"? Many people talk about NXT Proof of Stake (PoS) being insecure due to the "nothing at stake" problem. I read up some posts about nothing at stake, but I still do not understand how it works. Can someone explain how the "nothing at stake" works in laymen terms and how it affects Proof of Stake coins like NXT?

Essentially, PoS' nothing at stake problem is that you don't lose anything by mining. In Bitcoin, you lose the money you spent on energy to power your miners. Thus, in bitcoin mining you want to make sure you are mining on the correct chain all the time so that you have the best possible chance of your solved block being accepted by the network. In PoS coins, for the most part, there is no incentive to just mine on one chain. That is, a rational miner will mine on all chains that he/she knows about, because it doesn't cost them anything to mine on them (just a few CPU cycles) and they maximize their profit by mining on multiple branches. But since everyone mines on multiple branches, no one can come to a consensus!


Where can I download BTC historical ticker data? Where can I download historical data for Bitcoin price for mtgox?

In this 2 Year old thread:
Where can I get historic data series of Bitcoin prices?

The described solution is as follows:
download this tool and use it:
https://bitbucket.org/nitrous/bq

The problem is the tool only downloads data until 12.03.2013

Can someone explain to me what I need to do to get the data after this date.
Does someone have this data and could upload it or knows where to download the data?

You can get complete and up-to-date price history here:

http://api.bitcoincharts.com/v1/csv/mtgoxUSD.csv

You can also get subsets of the data.
For details see: http://bitcoincharts.com/about/markets-api/


Is it useful to have miners work on the same block instead of parallel solo mining? While mining with multiple devices GPU, FPGA, etc. at home/work/school, does each device work on its own block or can you combine the resources of each mining device into 1? Say if each device can mine at 1GHash/s, 5 devices for an overall 5GHash/s between all devices. Can you set it up to where that 5GH/s is used on 1 block instead of 5 blocks? As it would reduce the block validation time?

If you can combine the resources of the solo mining operation, I assume setting up a private/solo btc pool is inorder. Would you use long polling in this instance or not?

It doesn't really matter all that much. A set of workers working for the same block or each working for an individual block yields you the same profit on average. The only downside is that in order to mine for blocks you either need to have bitcoind running, or join a pool. If you want to mine a few blocks at once, you will need to be running a couple bitcoind instances. The easier setup is to just have one bitcoind running and have all your miners connect to it.

Well, that's the ideal situation anyway. Realistically, you won't ever mine a block this way. You can check out my mining calculator and plug in your numbers. How long is your time to generate one block? Can you wait 5 times that? Probably not. You ought to join a mining pool to get smaller rewards more often. But do it fast, as soon ASIC miners will go in and make your profits really small.

When you'll be joining a pool, logically you'd have all your workers connected to the same pool. Connecting to multiple pools wouldn't change your profits, perhaps it would smooth out your earnings a bit, but the change would be insignificant if you are using big pools.


why is the growth in the number of bitcoins not convex? If I look at the chart below:
https://blockchain.info/charts/total-bitcoins?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=

and I check the trend for 'All Time', it looks like the rate of growth in the number of bitcoins INCREASED around January 2010.
I thought that the rate of growth (enforced by a computer algorithm) would halve every 4 years and that it would never increase...
Am I missing something?

It is decreasing by half every 4 years, just that graph is just not showing it well for this short timeframe.

The dip up until 2010 was due to there only being one or two miners in the entire network, so the maximum number of Bitcoin wasn't produced in that period. The speed of the entire network couldn't keep up with the minimum of 6 blocks an hour which has lowered the total available Bitcoin in that period, though the number overall is just fine.  You can see the sharp decrease in late 2012 when the block reward halving first occurred, which is the start of the downward trend in block reward production.

Currently the network hashrate is increasing so quickly that it's producing more Bitcoin than expected, we'll probably reach the next halving in a little less than the intended 4 year cycle. That's not a negative effect in itself though, it just means the network is increasingly secure month on month. There's a similar hump between June and July of 2011, when GPU mining was publicly introduced.


Transaction history size I recently installed Bitcoin-Qt on my laptop and it started performing the synchronisation with the network since a couple of weeks. And it's not finished.

Why do the Bitcoin-Qt application have to do so? If I am right, this application is just a Bitcoin client... I mean, it have not to check transaction integrity such as a miner, right?

Also, I would know if according to you, in 10 years (with some imaginations), having a lot of transaction every days, this synchronisation could take some months or even more.

Thanks for your lights!

The main reason to run Bitcoin-Qt is to help the bitcoin network by relaying transactions and blocks as well as verifying the blockchain.  Bitcoin is a distributed protocol and relies on its users for validation.  You can download an initial blockchain so that your client doesn't need to get it from a peer node (your download will be limited by the upload bandwidth of the peer node).  Once synchronized, the network load is around 144 MBytes/day depending on the number of connections and the needs of your peer nodes (your upload bandwidth can be saturated for hours if another node needs to download the blockchain from you).

That said, if you just want to use bitcoins without participating in the network, you should use a light client such as Multibit, Electrum, or Armory.  Check here for more information.


What can happen if/when a node is surrounded by rogue nodes? If a node (V) accepts incoming connections, is he vulnerable to becoming completely surrounded by corrupted nodes? Would an attacker be able to control which transactions are relayed to V and which transactions V is able to broadcast to the network?

I assume for this to happen V would have to, over time, lose connections to honest nodes to have them replaced by the attackers'.

If so, in what circumstances would the Bitcoin client lose connection with an honest node, other than it going offline?

I don't know how frequently this occurs but the Bitcoin.org client (using default settings) will, after some amount of time (in the several minutes range, if I remember correctly), intentionally drop the existing connection and connect to a new peer chosen from the list of peers it knows about.

So the duration available to the attacker to feed the node corrupt (invalid) data is not very long.

If the node will be used to honor payments on 0/unconfirmed, then a race attack is a possibility so the recommendation is to not allow any incoming transactions and to have only outgoing connections and even then only to well-connected nodes.

There is further discussion of the risks here:

http://bitcointalk.org/index.php?topic=4335.msg63432#msg63432
http://codinginmysleep.com/bitcoin-attacks-in-plain-english


how to generate bech32/segwit address from pubkey in golang I am trying to generate bech32/segwit address in golang with the following code:
var pubkey *btcec.PubKey
address, err := btcutil.NewAddressPubKey(pubkey.SerializeCompressed(), chainParams)
if err != nil {
    log.Fatal(err)
}
address.SetFormat(btcutil.PKFCompressed)
bech32Bytes, err := bech32.ConvertBits(address.ScriptAddress(), 8, 5, true)
if err != nil {
    log.Fatal(err)
}
segwitaddr, err := bech32.Encode("tb", bech32Bytes)
if err != nil {
    log.Fatal(err)
}

and also more simply
var e *hdkeychain.ExtendedKey
address, err := e.Address(chainParams)
bech32Bytes, err := bech32.ConvertBits(address.ScriptAddress(), 8, 5, true)
if err != nil {
    log.Fatal(err)
}
segwitaddr, err := bech32.Encode("tb", bech32Bytes)
if err != nil {
    log.Fatal(err)
}

But neither segwitaddr generated match the bip84 address I got from https://iancoleman.io/bip39/. What is wrong with the code above or how to properly get a bech32 address from a pub key?
I have looked into another post on the same question, but could not figure out how to prepare the data needed in golang. More specifically, I am confused in preparing the input []byte to call bech32.Encode() and using bech32.ConvertBits().

I have found the answer thanks to modood/btckeygen.
Here is the relevant code extracted from the repo.
witnessProg := btcutil.Hash160(pubkey.SerializeCompressed())
addressWitnessPubKeyHash, err := btcutil.NewAddressWitnessPubKeyHash(witnessProg, chainParams)
if err != nil {
    panic(err)
}
address := addressWitnessPubKeyHash.EncodeAddress()


Why Do Compact Signatures Need To Start With a Byte 27-35? There's a hard-coded 27 value in Bitcoin's encoding of Compact Signatures that I don't understand:

https://github.com/bitcoin/bitcoin/blob/v0.7.1/src/key.cpp#L333

I get that the need to encode the nRecId to disambiguate the correct recovered key, but I don't understand the 27 (or for that matter why fCompressedPubKey is encoded as a 4).

The decoder requires the first byte be between 27 and 35, but then just subtracts the hard-coded 27 sans explanation.

It this poor man's bitmasking? It there something in the protocol that Compact Signature's can't begin with a 0x00 and this is a weird work-around? Perhaps it's acting as a sort of magic cookie?

Frankly, I just picked a range of numbers whose binary representation wouldn't easily collide with those of addresses (0, 111), secret keys (128, 239), public keys (2-7) or signatures (48). At the time, I didn't really expect it to end up in the message signing feature eventually.


Practical application of Electrum's Encrypt/Decrypt message feature? It's pretty clear how signing a message with a Bitcoin key can be useful in proving ownership of funds.

However, it's far from clear how encrypting a message with a Bitcoin key can do anything useful. This feature is available from Tools/Encrypt/decrypt message, and appears to use ECIES or some variant of it:

https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme

It seems that at least one developer is doubtful about the security of such schemes:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-August/006581.html

Security aside, what practical reason would anyone have to encrypt a message with a Bitcoin key?

Presumably, using a bitcoin public key you could encrypt a message, and only the person who controlled a private key associated with that bitcoin address would be able to read the message.

It's really a question whether you have confidential/private/secret information that you wish to share.

If you're looking for an hypothetical use case, imagine you paid your doctor in cryptocurrency for an embarrassing medical test, the result could be sent back encrypted such that only the person who paid can read it.

Or, Lets say you paid for software license online with cryptocurrency, the software key can be sent back encrypted such that only the person who paid could read the key.


fetching unconfirmed utxos from blockchain.info A few weeks ago, I would retrieve unconfirmed utxos from Blockchain.info doing API call https://blockchain.info/unspent?active=$address.
That enabled me to successfully make a micropayment channel (MPC) for instance.

Since last week however, an API call for an address with unconfirmed utxos only yields:

{
    "notice" :"Some funds are pending confirmation and cannot be spent yet (Value 0.00412834 BTC)",
    "unspent_outputs":[

    ]
}

(I know it s just a matter of time before these utxos are confirmed and the issue is sorted but ... )

which implies my MPC will not work anymore.

Why such a change?
or have I gotten something wrong?

I am considering this address. We can see the unconfirmed balance is not null, but the API returns no (unconfirmed) UTXO.

Thank you

This is most likely something on blockchain.info's end. You have a very similar call available via API to blockcypher.com here:

https://dev.blockcypher.com/#address-endpoint

unspentOnly=true will get you what you want.


Electrum console commands? I need 2 commands for electrum

To create X amount of addresses
to export those addresses to word or just be able to copy them

x=10

for thing in range(0,x): wallet.create_new_address()

listaddresses(True,False,False,False,True)

A guide about console commands is here. Thanks to @RichApodaca for pointing that out.

Another resource is the code itself. For example you can see the function declaration for listaddresses here which tells you what all those boolean args are for. In the above case it only outputs unused addresses in the external (receive) chain.


Capturing IP address of transactions submitted to Bitcoin Dan Kaminsky has pointed out that it would be possible to build a service that tries to infer the source IP address of each Bitcoin transaction.  His idea, which he calls Blitcoin, works by maintaining connections to all nodes in the peer-to-peer network and noting the IP address of the first node to report the transaction.  This won't always be the IP address of the source of the transaction (for instance, there are a number of ways to hide one's IP address), but sometimes it might be.

Has anyone built such a service?  How often does it work, in practice?  Are there any commercially available services that have maintained past archives of this information?

So a node that creates a transaction needs to propagate it. It will connect to other nodes. Usually to some reasonable number like 8 nodes (please see getpeerinfo on your client).

As a mental exercise: If the 8 nodes (that I randomly selected from the network) belong to the same person, that person will have the possibility to capture 100% of my traffic. My IP address will be known, but also there could be a selective attack that prevents my transaction from being broadcasted (i.e. he/she decides to drop it based on my sending bitcoin address).

The more nodes the attacker has, the more chances to have all outgoing connections from the victims plus the possibility to do data analysis. Also more chances of dropping (selected or random) transactions.

I don't know the economics behind an attack of this nature. Buying 5000 VMs to run nodes could cost a lot.

Examples are out there that they ask for bitcoin to set up full nodes, like https://classic-cloud.net/ [1]. as 2016-04-01 they have 810 nodes running. So you can imagine that they could be able to track some transactions to IPaddress.

Edit: [1] as of 2019-05-17 this is not longer a page that has stats about nodes, but rather a blog.


How To Run a Litecoin Node? How To Run Litecoin Node? I want to run my own litecoin node like bitcoin
  I know how to run bitcoin node but there is some issue when i am starting litecoin node

Any Idea? #Creating Litecoin Configuration File (litecoin.conf) and installing dependencies to run litecoin full node

Here is how to install and Launch LiteCoin Core daemon on your machine :-)

A Litecoin full node for building applications and services with Node.js

1. Download Litecoin core from official website https://litecoin.org/
 =>extract that file
2. tar -zxvf litecoin-0.16.0-x86_64-linux-gnu.tar.gz

=>install it
3. sudo install -m 0755 -o root -g root -t /usr/local/bin ~/litecoin-0.16.0/bin/*

=> Create configuration file
4. now create configuration file(~./litecoin/litecoin.conf)

=>now start litecoin node with daemon
5. litecoind


What transactions didn't make it to the Bitcoin blockchain? Bitcoin,I want to transfer some Amount so I broadcast a transaction that is picked up by miners. So if my transaction get's in 2 different currently processing blocks by different miners and one of them is mined into the blockchain, the second miner's block is dropped.

My transaction did, but also some transactions did not make it to
the mined block.

How does the protocol know which transactions made it and which didn't? Another way of asking, how is a transaction "marked" as mined so if it's still floating in the p2p network, miners know that this transaction is already in the blockchain.

How does the protocol know which transactions made it and which didn't?

Once a transaction is mined, all the network knows it's there. No one will keep it in their mem-pool any longer. Only before it's in the canonical chain you don't know who's seen it.


How to recover bitcoins from personal wallet app in android which is uninstalled? I am using a bitcoin Non-deterministic wallet created by a private firm.

In which there are few bitcoins worth 100$

Somehow I clear data of the android App, and Now all the memories related to my wallet is removed from android device.

How can I recover my bitcoins from android wallet app ?

UPDATE

I am not sure but If I have backup the wallet file in either form wallet.dat or wallet.bin

Even then my internal memory data would have get removed as well by Clear app data.

Isn't it?

Without a backup, there is no way to recover the coins.

If this happened very recently, you might be able to enlist a data recovery service to pull the keys off the device. This is likely to cost more than $100 though.

Wallet generation is based on random data, and if you do not backup individual keys, or the mnemonic for HD wallets, you cannot recreate the keys.


Bitcoin migrating to a ASIC resistant mining algorithm like RandomX used on Monero What would need to happen for Bitcoin to fork to a ASIC resistant mining algorithm like RandomX used by Monero for CPU mining only?

The bitcoin community would have to decide that they don't particularly care about having significant security anymore. ASIC-resistance weakens the security of proof of work chains because it eliminates the need to invest in a chain in order to attack it.

Someone who owns lots of expensive ASICs will not want to let them be used to attack the chain they are mining because if they harm that chain, they will significantly reduce the value of their own ASICs. By contrast, if you can mine with commodity hardware, attacking the chain does not significantly reduce the value of your hardware, so you have no real incentive to prevent your hardware being used to attack the chain. Worse, commodity hardware is easy to rent or steal (with malware) to attack a chain.

So the entire bitcoin community without have to change their opinion on how to make a chain secure to a worse opinion.

It's also important to understand the security is a huge limiting factor on price. If the benefit from causing a double spend exceeds the cost of doing a double spend, there will be double spends. Nobody wants that. So market forces will act to keep the benefit of a double spend below the cost of a double spend.

ASIC-resistant algorithms have much lower cost to do double spends (because you don't need to invest in ASICs but can instead rent or hack commodity hardware) so the profit from a double spend must necessarily be much lower. That will mean either waiting for many more confirmations, dropping the price of bitcoin, or some of each. Who wants that?


What percentage of newly created bitcoins have never been moved? As of today, what number of coinbases, what number of coins, and therefore what percentage of the newly created coins have never been moved?

As of block 445550 (december 28, 2016, 19:14 UTC), there are 55450 blocks with unspent coinbase outputs, with a combined value of 1854952.32263065 BTC.


How do I get my BTC back into my exchange without losing my BCC? I put my BTC in a paper wallet before the fork. Now, I'm desperately looking for a way to get my BTC off my paper wallet and back into circulation without losing my BCC. I don't really want to send my BTC to a newly developed BCC-dedicated wallet (because it's a large amount and that makes me nervous), but to my understanding sending my coins back to Gemini will make my lose my BCC.

Just send your BTC where you want to send to. As replay protection is implemented, your BCC will stay at your paper wallet, and you'll be able to spend your BCC.


How do you know your public key from a private key? In my understanding, when you create a public-private key pair, first, you create a pair of complementary keys by using cryptographic software. Then you give one key the name public key, and give the other key the name private key.  You keep the private key for yourself and give your public key to everyone else.

Then I was reading Mastering Bitcoin, I found this sentence:

  Paper wallets are bitcoin private keys printed on paper. Often the
  paper wallet also includes the corresponding bitcoin address for
  convenience, but this is not necessary because it can be derived from
  the private key.

I don’t understand how it is possible to derive the corresponding bitcoin address(the hash of a public key) from the private key.

If the public key can really be derived from the private key, isn’t the opposite true? I mean, we can choose whichever is the private key when we generate them.

If the public key can really be derived from the private key, isn’t the opposite true?

Nope, thats the wonder of asymmetric key cryptography! You can easily derive the public key from the private key, but going the opposite direction is equivalent to brute-force guessing you way through an impossibly large set of numbers (ie, impossible). So the public key and private key are mathematically related, but this relationship is "one-way", so to speak. This is why you can share your public key with other people, but you should never, ever share the private key!
Once someone has a private key, they can use it to derive the public key and bitcoin address easily. But having a public key gives them no knowledge of the private key, since the math doesn't work the same both ways.
In bitcoin, the public key is derived using the Elliptic Curve Digital Signature Algorithm (ECDSA).

Then you give one key the name public key, and give the other key the name private key
...
I mean, we can choose whichever is the private key when we generate them.

I think this is where your misunderstanding comes from, the distinction of 'public' or 'private' is not arbitrarily chosen. One is derived from the other, their relationship is mathematically defined.


Is hashing an optional step to use with public key cryptography for blockchain I am confused by the public key cryptography versions that I've read so far. Are the steps optional, dependable on the types of blockchain or they are referring to different methods?

Version 1 =========

Alice to Bob

Step 1. Content > Hash > Digest > Encrypt with Alice's private key > Digital Signature

Step 2. Digital Signature > Encrypt with Alice's private key + Bob's public key > Digest

Step 3. Send digest to Bob

In the above steps, Alice uses private key TWICE. First to encrypt the content's digest. Second time encrypt together with Bob's public key.

Is hashing optional?

Is the hash generated automatically once it is encrypted with Alice's private key?

Or encrypting with Alice's private key step is optional?

Is step 2 optional too? or are all the above steps automated?

Bob received

Step 1. Digest > Alice's public key > Content

Step 2. Digest > Bob's private key > Content

=

=

Version 2 =========

Alice to Bob

Step1. Alice generates the keys pair

Step2. Alice gives Bob her public key

Step3. Alice encrypts content with her own private key

In the above steps, Alice didn't hash the content first.

Bob received

Step1. Bob decrypts with Alice's public key

What if someone else has Alice's public key, aren't they able to decrypt it too?

=

=

Version 3 =========

Alice to Bob

Step1. Alice encrypts with Bob's public key

Bob received

Step1. Bob decrypts with his own private key

=

=

Questions like this cannot be answered without specifying the digital signature scheme you're using.

In general

In general, a digital signature scheme consists of 3 algorithms:

KeyGen() -> (PrivKey, PubKey): generates a private key and a corresponding public key.
Sign(PrivKey,Message) -> Signature: signs a message with a given private key.
Verify(PubKey,Message,Signature) -> Bool: verifies a signature against a public key and a message.

What the data types involved are depends on the specific scheme.

ECDSA

In ECDSA, the digital signature scheme used in Bitcoin, the private key is a number, the public key is a point on an elliptic curve, the message is a byte array, and the signature is a pair of two numbers.

ECDSA does require a hashing step. In fact, without the hashing step, it is completely broken.

However, nowhere is there any encryption involved. There is simply a signing algorithm, and a verifying algorithm.

RSA

The mistake you're making, calling signing "encrypting with the private key" is a very common one, because it is often how digital signature schemes are explained.

It is true for some specific signature schemes, but not all. Most notably it is true for RSA. The private and public keys are interchangeable there, so indeed, by swapping them, the encryption scheme turns into a signature scheme.


Why do we need two transactions for CommitCoin scheme I am studying BitCoin recently.

I noticed a method called CommitCoin for secure timestamping. It requires two transactions to send coins back with the same randomness so that others can compute the private key.

However, isn't it easier to just reveal the private key yourself? The whole point is to prove that at some time in the past, I knew something. If I send some coins to the address and send the coins back, and later reveal my private key and it matches the public key, shouldn't it be enough to prove that?

Thanks in advance.

We wrote this paper before Bitcoin supported OP_RETURN. Now you would just use OP_RETURN.

In CommitCoin, you can reveal the private key off-blockchain. It might indeed be simpler. Our thinking is having it self-contained on the blockchain, without having to reference anything else or having to have a connection to the publisher was the simpler model.


How much energy will the Bitcoin network eventually consume? A recent Bloomberg article stated that the Bitcoin network currently consumes about half as much energy as the Large Hadron Collider or enough to power 31,000 US homes. Even if the article is way off the mark, it is undeniable that the network's energy consumption (based on hash rate) goes up in direct proportion to the market price of a unit of the Bitcoin currency.

According to blockchain.info, the network is currently consuming 1,203.97 megawatt hours per day.

How much energy is the Bitcoin network expected to consume as the price of a bitcoin goes up from around $100 today to $1,000, $10,000, and so on?

The upper boundary for energy usage can be described with a function of the profit and energy costs. Miners won't ever pay more for energy than they get from profits. The actual energy usage formula will also have to count for the hardware costs.

The formula will look something like this :

max energy usage = (profit - hardware costs) / energy cost per unit
profit = exchange rate * generated btc
generated btc = transaction fees + block creation bonus

As you can see, the energy usage depends on the following factors:

Energy cost per unit (kWh)
Hardware costs
Block creation bonus (currently 25, some day 0)
Transaction fees (currently hardly relevant, some day very important)
Exchange rate

And, of course :

How much money the miners want to keep
Taxes?

[edit]

$10,000 a coin times 52560 (blocks per year) times 25 (coins per block) gives $13,140,000,000 mined USD a year. Yes, that's thirteen billion USD in mining profits. If we divide this by $0.20 per kWh, then the upper boundary for energy use will be 52,560,000,000 kWh (52 TWh), roughly 2/1000 of the total energy consumption of the USA. Of course, if we assume that 90% of the money goes to hardware and not energy, the actual energy usage will be more like 5TWh. (Link to the calculation)


How to get money when using regtest I want to experiment in the regtest network.
But I don't understand how I can get funds to play with.
I did:

bitcoind -regtest -daemon

bitcoin-cli -regtest sendtoaddress 2N3V4PeQXoD6TFM9ZvDMX81kzbuNtc5YPW4 1

and get:

error code: -6
error message:
Insufficient funds

Just generate some blocks.

bitcoin-cli -regtest generate 101

You will have them in your wallet and can use the funds once confirmed. 101 is the number of blocks to create.
You can use any integer that's at least 101 as the number of blocks.
You cannot use a smaller integer than 101 if you want to test transactions, because of the 100 block maturation time.


How is Recipient's Public Key Used When Receiving Coins (if at all)? I understand the above image is dated--I posted here just for reference.

Assume the first tx is for Alice (Owner 1) and the second is for Bob (Owner 2). My previous question (Confused About Hash In Satoshi Nakamoto Diagram) covered that the signature that ends up in the second transaction uses ECDSA and takes the Owner 1's private key and a message as input. The message is the hash of the transaction 1 (less the sig). The sig that gets stored in transaction 2, if verified with Alice's public key, proves that Alice released funds to Bob.

But how does the network know that Alice meant to give these funds to Bob? When Alice "sends" coins to Bob, she first get's Bob's address (let's just keep it simple for now and say that Alice has Bob's public key). After that, it seems to me that the network would encrypt the Alice's signature with Bob's public key so that when Bob wants to verify the sig with the ECDSA verification algorithm, he first would need to successfully decrypt the sig with his private key. Is that correct? The other way I can see it working is if the network creates transaction 2 with Bob's public id in it, and that only Bob can use the funds in that transaction record because to spend those funds, Bob will need the private key.

If neither assumption above is correct, is there anything about the protocol that ensures Alice's transfer of ownership reaches the intended recipient? If she makes a mistake in the recipient public key, is there any way for her to correct her mistake if Bob never receives the coins?

how does the network know that Alice meant to give these funds to Bob?

Transactions have different parts, an input section that specifies which funds are being spent (and proves the spender is authorized to spend them) and an output section that specifies the recipient(s):

Looking at it in a little bit more detail, outputs contain the amount to spend as well as the public key script (scriptPubKey) that will be used to determine whether or not a future spender is authorized to spend the funds.  The input identifies the funds being spent by their hash (the transaction identifier) plus the indexed number of the output in that transaction, and then provide a signature script (scriptSig) containing data that is evaluated in the context of the scriptPubKey to determine whether or not the spender meets the spending conditions.  In a conceptual model, the scriptPubKey is a public key, the scriptSig is a signature, and the signature has to be valid for the public key over all the data in the spending transaction (minus the signature itself).  (That's not exactly how it really works in Bitcoin, but that's the principle.)

  it seems to me that the network would encrypt the Alice's signature with Bob's public key

Bitcoin's consensus protocol doesn't use encryption.  In Alice's transaction, she places an output saying "pay  100 bitcoins"; when Alice signs the whole transaction, she both proves that she's authorized to spend those 100 bitcoins and protects all the data in that output against change by any third party (because they can't create a signature using Alice's private key).  (Assuming Alice has sole possession over her private key, there's no multisig in use, ECDSA hasn't been broken, etc...)

  The other way I can see it working is if the network creates transaction 2 with Bob's public id in it, and that only Bob can use the funds in that transaction record because to spend those funds, Bob will need the private key.

This is conceptually correct.  In practice, the protocol just evaluates scriptPubKeys and ScriptSigs, which can do whatever they want within the limits of the language, rather than having a specific notion of key-based identifiers.

  is there anything about the protocol that ensures Alice's transfer of ownership reaches the intended recipient?

Alice's signature protects her transaction against modification (with the same caveats as listed before).

  If she makes a mistake in the recipient public key, is there any way for her to correct her mistake if Bob never receives the coins?

If the transaction has not been confirmed, Alice can create an alternative version of the transaction, broadcast that, and hope the alternative gets confirmed.  After confirmation, there's nothing Alice can do to change the spending conditions (scriptPubKey).

It is possible for Alice to pay a scriptPubKey that allows her to reclaim the funds if they haven't been spent by Bob within a specified amount of time.  This mechanism is used to prevent denial-of-service attacks in payment channels, but I've never heard of anyone using the mechanism to ensure they paid the correct address.  In typical Bitcoin operation, there's no way to reclaim bitcoins paid to the wrong address.  (Note: for this reason, the common form of Bitcoin addresses starting with a 1, 3, or bc1 all contain checksums that help wallets detect typos (but this detection is not perfect, and if Alice accidentally pays an address that is valid but the wrong address, e.g. she pays Charlie, then there's nothing the wallet can do to help her or Bob).)

Images in this answer are from the Bitcoin.org Developer Guide, MIT licensed, which goes into more detail.


Why do mining pools refuse "spammy" transactions when there are transaction fees already? So I stumbled over a problem with some non relayed transactions. A helpful user was finally able to point out that some services (Satoshi Dice) that accept BTCs are regarded as a nuisance by mining pools, so they flat out reject to relay their transactions.

I can understand the rationale that there is scarcity in resources and all. Surely it takes a toll on the network if lots of small transactions clog up what limited processing power there is - but isn't this exactly why there is such a thing as a transaction fee? Isn't the whole point of such a fee to prevent people spamming the network?

Did I misunderstand how this works or is it really okay in the Bitcoin network to refuse transactions based on personal preference of the operators (aka Miners), in kind of like the censorship style that many proponents of BTC aim to avoid?

So, I don't personally think that the reason your transaction wasn't relayed/mined was because of miners refusing to mine the transaction because it was a Satoshi  Dice transaction. (Although I can't say that I know the real reason, or I would have posted an answer there.) The major mining pools right now deny this "transaction discrimination" (see this bitcointalk thread). And looking through the blockchain seems to verify this: there are lots of transactions getting confirmed for the well known Satoshi Dice addresses.

I think the reasoning for accepting them is the same reason you state: that if the transactions are paying the mining fee, they are essentially paying their own way. Some may (and do) disagree, but I this is certainly one of the reasons that transactions fees are part of the protocol. As long as there is a cost to send a transaction (even if it is a small one) then that does protect the network from spam and DDoS attacks.

As far as the second part of your question  "Is it really okay in the Bitcoin network to refuse transactions based on personal preference of the operators (aka Miners), in kind of like the censorship style that many proponents of BTC aim to avoid?", that is somewhat different.

Yes, it is entirely within the protocol (and I would assert the spirit) of the protocol. Bitcoin to a large extent a democracy (except that it is isn't one vote one person). And if there was an attempt to subvert the system, then it is the miners who collectively protect against that.

For example, the BTC market is now large enough that it is conceivable that someone with a vested interest in the BTC exchange rate might find it worthwhile to flood the network in an attempt to devalue BTC, even if it required paying transaction fees on that flood. Another example, if someone found an exploit (or even simple bug in the Satoshi client) that allowed some sort of malformed transaction to crash clients. In most cases, it is entirely reasonable that the miners (from their own interest in protecting the network) would refuse to mine those transactions.

So, yes, I would say that it is entirely reasonable for miners to refuse to mine transactions based on "personal preference". Because that will only affect the network if the majority (actually it likely would take a significant supermajority) were acting on the same personal preference. Which means that they weren't personal preferences so much as a group consensus about the benefit of the network. And since they would be passing up the opportunity to make money on those transactions it is extremely likely that the supermajority could only be reached in the case of a significant network issue. (A great example of this is the March 2013 fork in the network.) The miners collectively chose to ignore the longest blockchain (the 0.8.1 branch) in favor of keeping compatability with 0.7.


What is the differenct between 13.5TH and 14TH I would like to buy an S9, checking the bitmain site found that they are selling two S9 versions.
- S9i-14TH/s
- S9i-13.5TH/s

Apart from the obvious difference in Hash rate, is there any other differences I should be considering before buying? I can't seem to find the full spec for these miners

I don't have any specific knowledge about this product, but I would guess this is an example of binning.  They're not really different, it's just a matter of how fast those particular units are able to go.

Most likely, both kinds of units are produced with identical parts and processes on the same assembly line.  Due to normal variation, some units will be more robust than others, so they test each unit at various clock speeds to see how fast it can successfully operate.  The 14 TH/s units passed their tests at a higher clock rate, so they set them to operate at that rate and sell them for a higher price.  The 13.5 TH/s probably failed at the higher rate but passed at a lower rate, so they set them to run at a lower rate, advertise them as meeting a lower performance standard, and sell them for cheaper.

So in that sense the 14 TH/s units are probably "better" and perhaps more reliable overall, but then again they cost more.  You'll have to look for product reviews to try to estimate how reliably these units perform as advertised; that's beyond the scope of this site.


Can private keys be securely stored on blockchain? Ok, I know that blockchain is public knowledge. But, than, there are experiments like zcash which encrypt sender receiver and amount information and they still work.

I'm considering whether p2p blockchain arbitration service is possible. For example, you want to exchange ETH for BTC. A blockchain generates 2 addresses, one of which is for BTC, other is for ETH. Once both addresses are funded, funds of both are forwarded to the recipients. To do this via blockchain, there should be a secure way to store and use private keys on blockchain.

Is this completely impossible, or are there any indications that one could do something like that?

There is no encryption involved anywhere in a blockchain. There are no keys to encrypt with, as every node has the same information as all others. Cryptography is involved, but for signing/proving. Not for encrypting.

Even in the zcash case, encryption is not involved. All wallets do is prove to the rest of the network that they had the funds they're spending. The only difference compared to Bitcoin is that it reveals less information in doing so, and as a result, the proofs are much more complex.

blockchains don't generate private keys - that doesn't make sense, as the chain can be seen by everyone.

Wallets do have private keys. They're never shared with anyone. They hand out the corresponding public keys in order to be paid, and use the private key to later prove to others they own certain coins.

The example you're describing with an exchange occurring between two chains is possible using a technique called cross-chain atomic swap. It relies on a hashlocked transaction where the first wallet that moves its money out on one chain reveals a random value that hashes to a value that is known ahead of time. The other party then uses this preimage to unlock funds on the other side.


How to get _integer_ satoshi values from JSON RPC? It seems that RPC calls for getting JSON information on blocks return "value" fields in bitcoins, not in satoshis.
This means that there is a conversion from integer to float somewhere, which is disturbing since it may introduce rounding errors (see context below).
Is there any way to get the integer satoshi amounts directly in the JSON?
Otherwise, is it completely safe to just multiply the float value by 10^8 and take the integer part?
Is there a better way to directly obtain the integer satoshi value?
Thanks!

Let me give some context.
A typical concern is that, for instance, most systems have no float of value (exactly) 0.1; they generally have a (tiny) difference.
On my machine, I obtain:
python3.6 -c 'print("%.20f"%0.1)'
0.10000000000000000555

python3.6 -c 'print(0.1+0.1+0.1==0.3)'
False

This is generally safe, but in my context this raises messy issues, so dealing only with integers is appealing.

bitcoind internally treats all amounts as an integer and only displays the value as a decimal for the RPC. Formatting for display does not introduce any floating point precision issues as it still just does integer conversion with some string formatting to make it look like a decimal. So it is perfectly safe to multiply by 100000000 to get an integer amount of satoshis.


Does Bitcoin Unlimited keep ASICBOOST intact vs going with segwit? In light of the new findings about ASICBOOST from bitmain. Having that segwit disables ASICBOOST, does this mean that Bitcoin Unlimited leaves this ASICBOOST feature intact? Having that segwit disables this ASICBOOST feature, has Bitcoin Unlimited done the same?

How does ASICBoost work

ASICBoost relies on finding multiple block headers that match in the last sixteen bytes. As SHA-256 takes 64 byte chunks of input, this allows to reuse parts of the calculation for the second chunk.

The last sixteen bytes of the block header are composed of the

last four bytes of the Merkle root of the transactions
the time-stamp
the difficulty statement
the nonce.

Thus, the last twelve bytes are arbitrary and the only difficult part is to get four bytes of the Merkle root to match up. This could be done by actually using the same Merkle root, but then (since the hash of the previous block is fixed) the only remaining field in the header to introduce variation is the the version field! Mining blocks with varying version fields is pretty obvious and corresponds to the overt application of ASICBoost.

For a comprehensive explanation of ASICBoost see: Jeremy Rubin's Notes on ASICBoost [PDF]

Covert ASICBoost

On the other hand, the covert application relies on finding multiple Merkle roots that collide in the last four bytes. As we know, the Merkle root derives from forming a Merkle tree on all transactions. A straight forward way of doing this would be to grind the coinbase transaction extra-nonce space. However, each time when you change the coinbase transaction, you have to recalculate the complete left branch of the Merkle tree, which requires an additional 11 to 12 extra hashes for blocks with up to 2048 or 4096 transactions respectively. Obviously, finding a partial collision of the Merkle root would be twelve times faster performed on an empty block.

A more efficient way of finding partial collisions of the Merkle root would be to have a fixed left-side tree, i.e. an unchanging coinbase transaction, and to combine this with various right-sides of the tree. This would then only require a single hash to produce a new Merkle root, and you could immediately check whether you've found the desired collision.

In practice, you could efficiently generate right-side trees by combining several compatible candidate trees a few branches down from the Merkle root in different ways. This is why out-of-order transaction-fees and the absence of dependent transaction pairs could be indicators for the use of covert ASICBoost-usage. This process is highly parallelizable.

How does SegWit influence ASICBoost

This more efficient approach is broken by SegWit and many other BIPs, because it requires in the coinbase transaction a Merkle root commitment which is calculated order-sensitively from all other transactions in the block. This means that whenever any transaction in the block is updated the entire left-branch of the Merkle tree needs to be recalculated due to the updated coinbase transaction.

…and Bitcoin Unlimited?

To come back to your question: AFAIK, Bitcoin Unlimited does not require a commitment in the coinbase, and thus would be compatible with the covert application of ASICBoost.

Many thanks go to David Harding who explained the finer details of the above in chat, from which I've adapted some of the above paragraphs.


send to online wallet ie spend bitcoin from cold paper wallet ,without losing the remainder All the answers I see here are just confusing me. What is a ' client '? Is it me, my computer, my online wallet, the person selling to me or buying my bit coin or what ? I just want to know how to send bitcoin from paper wallet to online, to spend, and what to do to avoid losing the change remaining  in   the paper wallet. I GUESS it is like this...empty the paper wallet to an online wallet. Pay the other party by sending off bitcoin. Then make a new online wallet - must I  ? Put the remainder bitcoin  in there Make a new paper wallet.Send remaining coin back to new paper wallet. Sounds simple? But I have NO IDEA about how to use the private and public keys. Do I have to make a new private key for every step in the above ?

Client normally means the wallet

You don't need to give money to someone to make you a wallet. There are many free wallets like electrum , greenwallet, coinomi which create a address for you and also make you the owner of your private keys

You also don't need to send the money from your paper wallet . If you are able to destroy you paper wallet safely , you can sweep the bitcoin from your paper wallet to coinomi wallet .

No need to make a new private key every time .


Decentralized transactions between two decentralized currencies Currently, bitcoins and namecoins are implemented using the Bitcoin protocol. And there might be several reason for new block chains to appear, but this is not the subject here.

As far as I know, Bitcoin was not designed with ‘cross-currency atomic transactions’ in mind.
For example, as of today, one cannot exchange bitcoins for namecoins using the Bitcoin protocol itself.
A partner might be willing to trade, but some trust is required: who will send their coins first ?

Given that the main interest in Bitcoin comes from its decentralized nature, accepting the need of a third party to arbitrate exchanges between two such decentralized currencies is rather disappointing.

Is there anything to be done to allow ‘decentralized cross-currency transactions’ using the protocol itself (scripts maybe)? or could it be achieved with some simple modifications to the protocol?
Is this theoretically impossible under some specific conditions?

I have actually been working on this exact problem. My motivation is to achieve a slightly different effect than what you're asking about.

I'd like to be able to "move" some Bitcoins to a different hash chain, allow them to be exchanged in that hash chain (as Bitcoins), and then I'd like the final holder to be able to "re-import" the Bitcoins back into the regular hash chain. The goal would be to create "side-chains" with faster block generation times useful for smaller transactions. (They could also 'expire' after a few months and be forgotten, reducing the size of the permanent hash chain.)

But the basic problem is the same. You need the legitimate holder of some Bitcoins to depend on a fact verifiable only outside the Bitcoin hash chain. In both cases, the existence of a transaction in another hash chain. (In my case, a Bitcoin hash chain but not the Bitcoin hash chain. In your case, another currency's hash chain. But the principle is the same.)

The problem is that the Bitcoin design requires every client to be able to validate every transaction, as they must track coins all the way back to their origin to confirm their validity. This means a transaction must be verifiable with only information every client should have -- and that means only information in the Bitcoin block chain.

A third party could put this information into the Bitcoin hash chain. But you'd have to trust that third party, defeating the point.

I have thus concluded that no solution is possible, unless someone has an idea that breaks my assumptions. I hope that will happen, but I am not clever enough to think of it.


When changing transaction data in a block change the hash of previous block? If i only manually change the data on the block without touching/modifing the already calculated hash, then hash on the block its still valid because its already saved and was not touched ... so,

When the blockchain revalidate the hash with the content of the block? ...

In every paper that i read i see that all the security and inmutability of the blockchain its based on the already calculated hash, so, its like its easy to change data without touching hash so block still be valid in all the merkle tree and chain... how this modification its protected?

When a new block is received by a node, it is validated. This validation includes verifying the validity of each individual transaction, constructing the merkle tree and the merkle root, verifying the merkle root against the block header, verifying the PoW in the block header, and finally verifying the hash itself.

After this validation is completed, the block is saved into the node's local chain database.

If you were to go and modify the stored data, it would have little effect - no other nodes will see your modified data, and all you will achieve is a broken local state if you run a reindex or reindex-chainstate.


Is there a way to abort a stuck lightning network payment? I recently had this problem IRL: tried to pay in a coffee shop with LN, but my channel partner was "sleeping", so after a while I paid in cash. Then, 5 min later, the server comes back online, the LN payment went through and I had to go get my cash back.

lightning-wallet.com doesn't seem to have a stop button, but I think this (IMHO important) usage scenario is just not possible in the protocol right now, is it? The BOLTs say: "For simplicity, a node can only remove HTLCs added by the other node. There are four reasons for removing an HTLC: the payment preimage is supplied, it has timed out, it has failed to route, or it is malformed.".

So I guess the question is, why is this not possible today? Just a UI problem, a protocol shortcoming that will be fixed, or is there a deeper reason why it CAN'T be possible?

First of all: it is in fact not possible at this time to sort a stuck payment. The htlcs are a contract in which you agree to fulfill a payment if the routing node provides a preimage within a time window (the timelock). Assume you would be allowed to remove an htlc before the timelock, not only would this be a breach to the contract but it could easily result in a behavior in which you could initiate a payment, the merchant would claim the money, and while the preimage is propagated back to you, you would cancel your htlc causing the routing node to lose money.

Obviously as a protocol extension we could think about making a different onion request "abort routing" which would inform all nodes on the path to abort. This would have to be executed from the recipient back to the sender and would mitigate the above mentioned way of abusive behavior.

However such a new onion request would mean that everyone on the path is responsive to it. If that was the case in the first place the payment would not have been stuck.

It is always hard for mathematicians (like me) to claim something is impossible. But I think in this case we have it by design impossible / undesirable to cancel htlcs from the sender side. (I am happy to be proven wrong and would enjoy a discussion on the lightning dev ml as I think from a UI / UX perspective your request is totally reasonable)

Also keep in mind what removing an htlc currently means. The state of the channel is changed.


Bitcoin transactions with multiple participants from input side Is there any other type of bitcoin transactions with multiple partisipants from the input side except different types of CoinJoin transactions?

Multisig inputs typically have multiple participants. Usually multiple parties are required to sign the transaction.


Where do the dollars go? This question seems to me to be such an obvious question, that it must be answered somewhere.
As I understand it is necessary to buy bitcoins using dollars or some other currency. Where do those dollars etc. go?

When you buy a bottle of soda at the convenience store, where does the money go?

The money goes to the party that sold it to you -- that party owned the bottle before you owned it.  You might be able to trace ownership of that bottle all the way back through the supply chain, to the point at which it was manufactured.   It probably had several prior owners before you got it.

Bitcoins are like a commodity that works the same way.

If you purchase from a market exchange (like Mt. Gox), here's how that works.  Mt. Gox, like most market exchanges, operates using deposit accounts.

To buy $100 USD worth of bitcoins you must have deposited $100 to your account with the exchange.  To sell 10 bitcoins you must have deposited 10 BTC to your account with the exchange.

So when you trade your $100 USD for someone else's 10 BTC, your $100 goes to their account, and their 10 BTC goes to yours (if there were fees, the amounts would be adjusted appropriately to cover fees).

Then when you withdraw your BTCs, the exchange will send that amount of bitcoins from the exchange's wallet to yours.  When the seller withdraws the USDs (or whatever currency the coins were sold for), the exchange will send those funds.  This generally occurs through the banking system, with the funds eventually arriving in the seller's bank account.

There are other types of bitcoin sellers -- direct sellers, who have an inventory of bitcoins that they purchased previously, or will make a trade behind the scenes to be able to deliver your order.  So the dollars from your purchase goes to them in exchange for the bitcoins they owned.

Then there are other types of trades which involve risk.  These include financial derivatives where you may speculate on bitcoins using cash but until you actually withdraw those bitcoins to your own wallet, you only own a claim against those bitcoins (or against a financial position on bitcoins).  But that is an example where there is not a simple buying and selling of bitcions at a certain price.

Now every bitcoin in existence originated from mining.  Mined coins arrive 50 at a time about once every ten minutes.  They are earned by a mining operator (or mining pool and distributed to the mining operators who were mining).  To mine, one must buy expensive hardware, expend the effort to build and operate the equipment, and purchase the electricity expended during mining.  The mining operators can then deposit their bitcoin proceeds to an exchange to sell them and receive cash in exchange.


Ignoring the difficulty set by the pool Scenario:

The pool sends a mining.set_difficulty message with difficulty = 8.
The miner ignores the message and submits shares that qualify at
difficulty = 1.
Most shares will be rejected by the pool with error = high-hash.

Question: what is the cost of submitting shares that get rejected? Are the accepted shares as valuable with an acceptance rate of 5% as if they were submitted with an acceptance rate of 100%?

The pool will typically ignore invalid shares. They should have no effect on shares that are actually accepted.

Some pools might consider excessive submission of invalid shares abusive, especially if done at high rates. The point of an increased difficulty is precisely to avoid this. So you might find you get suspended or disconnected. But most pools would probably just tolerate it unless it actually caused them an operational issue.


Would it be possible to patent Bitcoin? Bitcoin utilizes a proof-of-work mechanism to assure against double-spending, as well as providing an example opensource implementation.  However, some countries allow software patents, which could mean that one person/company has the ability to suddenly prevent the legal use of Satoshi Nakamoto's Bitcoin algorithms.

Are these Bitcoin algorithms complex enough to qualify for being patentable, and if so, in what countries might such patents be granted?  Does this pose a significant legal risk for users of Bitcoin?

To claim a patent you must be able to prove against contest that you invented the device, and have a working example that if built to the specs provided, runs.

As it was this Satoshi who invented bitcoin, and there are prior examples of a digital currency, it would be very hard for any one person to claim a patent so far after the fact. Some one could try, but the patent industry is built to make it hard to write a patent, easy to contest. Admitedly many companies do just that and are good at it, but anyone patenting bitcoin would have a hell of a time proving first invent.


Is Quark as secure as SHA 256? I'm trying to make certain I'm understanding the purpose behind the Quark algorithm.

There are lots of devices that need secure algorithms but have severe power and processing constraints such as RFIDs (the chips found in everything from clothes to cars) - hence Quark (and other algorithms) were developed. Quark seems to be secure and yet lightweight enough that CPUs are more that capable of hashing them without maxing out.

I've read lots of articles and posts that come up with reasons pro and con re Quark. What I'm wondering about is what makes Quark worthy as an algorithm for a currency? One advantage is that it uses multiple algorithms and the chance of multiple hash functions getting cracked at the same time approaches zero. But why would we really care if more or less electricity is being spent in creating a block? Of course I want my electric costs to be less - the same as anyone else. But more important than my electric costs is knowing that the currency is secure. I would also prefer that mining is distributed across the network (as opposed to ASICs) but again what counts first and foremost is that the system is secure.

That being the case how is an algorithm designed for RFID's able to compete with SHA256?

I'm still struggling with these algorithms so I may be missing something very basic.

The biggest problem with Quark (or any other "memory hard" algorithm) as a hashing algorithm is that verification is synchronous. So in order to verify things you have to do a lot of work, compared to the very small amount of work required to verify SHA256. This could lead to a DoS attack where an attacker sends you a whole lot of bad blocks and makes you tie up memory and CPU trying to verify them.


Unexplained Segwit transaction results in wrong balance (mixed address transaction?) I sent 0.005 BTC from my Ledger Nano wallet (Segwit) to my Bitstamp wallet.
When checking my new balance on a public address reader, an additional 0.603 BTC was removed. I then checked the transaction online on blockchain.info and the 0.603 BTC went to an unknown-to-me address (I never authorized nor performed this second transaction).
My Ledger Nano wallet (Segwit) balance on my Ledger Desktop app always showed the correct balance (with only -0.005 BTC) when the other sites all showed the incorrect balance ( -0.603 -0.005 BTC).
I finally transfered the total remaining balance from my Ledger nano to Bitstamp as a test, and I got back the 0.603 BTC missing.
What is interesting is that the total of the transaction (authorized
0.005 + unauthorized 0.603) is equal to a transaction I have done two weeks before (from an exchange to my Ledger Nano).

Can someone explain to me what happened? By not understanding what happened, I am fearful of other unexpected transactions and wonder if I should still use my Segwit address.

Thank you

You just experienced what is called a change address, when you send a transaction from an address, the wallet sends the amount to the address you put and sends the remaining balance to another address in your wallet. this is why you saw the correct balance in your ledger because the address is still in your ledger.


Unable to create raw transaction with json-rpc command I am trying create a coinbase transaction with the command:

{"jsonrpc": "1.0", "id":"jsonrpc", "method":"createrawtransaction", "params":[{"txid":"0000000000000000000000000000000000000000000000000000000000000000","vout":0xFFFFFFFF}] {1Ka3q3DVTBNBo2c4kVGMNzbd32RARV1FbA:25.00} }

but I am getting the following response:

{"result":null,"error":{"code":-32700,"message":"Parse error"},"id":null}

the same happens when I try with:

{"jsonrpc": "1.0", "id":"jsonrpc", "method":"createrawtransaction", "params":[{"txid":0000000000000000000000000000000000000000000000000000000000000000,"vout":0xFFFFFFFF}] {1Ka3q3DVTBNBo2c4kVGMNzbd32RARV1FbA:25.00} }

when I use the Debug window (in the bitcoin-qt application), I get Error: Error parsing JSON:[{txid:0000000000000000000000000000000000000000000000000000000000000000 and Method not found (code -32601) respectively.

Someone can tell what's wrong here?

Here is the correct json:
createrawtransaction '[{"txid":"0000000000000000000000000000000000000000000000000000000000000000","vout":0}]' '{"1Ka3q3DVTBNBo2c4kVGMNzbd32RARV1FbA":12.5}'

I used 0for vout, because it has to be numeric (I don't believe hex is accepted).

help createrawtransaction

createrawtransaction [{"txid":"id","vout":n},...] {"address":amount,"data":"hex",...} ( locktime )

Create a transaction spending the given inputs and creating new outputs.
Outputs can be addresses or data.
Returns hex-encoded raw transaction.
Note that the transaction's inputs are not signed, and
it is not stored in the wallet or transmitted to the network.

Arguments:
1. "inputs"                (array, required) A json array of json objects
     [
       {
         "txid":"id",    (string, required) The transaction id
         "vout":n,         (numeric, required) The output number
         "sequence":n      (numeric, optional) The sequence number
       }
       ,...
     ]
2. "outputs"               (object, required) a json object with outputs
    {
      "address": x.xxx,    (numeric or string, required) The key is the bitcoin address, the numeric value (can be string) is the BTC amount
      "data": "hex"      (string, required) The key is "data", the value is hex encoded data
      ,...
    }
3. locktime                  (numeric, optional, default=0) Raw locktime. Non-0 value also locktime-activates inputs

Result:
"transaction"              (string) hex string of the transaction

Examples:
> bitcoin-cli createrawtransaction "[{\"txid\":\"myid\",\"vout\":0}]" "{\"address\":0.01}"
> bitcoin-cli createrawtransaction "[{\"txid\":\"myid\",\"vout\":0}]" "{\"data\":\"00010203\"}"
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "createrawtransaction", "params": ["[{\"txid\":\"myid\",\"vout\":0}]", "{\"address\":0.01}"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "createrawtransaction", "params": ["[{\"txid\":\"myid\",\"vout\":0}]", "{\"data\":\"00010203\"}"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/


Does full node store all valid forks and "alternative" blocks from blockchain history? Forks are possible when mining the blockchain and happen "all the time" during mining.

This means the nodes monitoring the blockchain have recorded many forks during blockchain's lifetime, with some of non-main branches long several blocks.

Do nodes store all the branches from entire blockchain history?

EDIT: I read another question, and it is logical that the node should return the transactions from the "alternative" branch they were on to the memory pool (or discard them). But does this happen at the very same time when someone "shows" them longer branch, or they still somehow keep the alternative branches?

Do nodes store all the branches from entire blockchain history?

They will store all branches that they know of so long as the block headers of each branch are fully valid.

The way that Bitcoin Core nodes (and all node software based upon Bitcoin Core) work is that they will ask for an receive a block header before asking for the actual block itself. Using the headers, the node builds a headers chain. So if a block header is valid (i.e. it has a valid proof of work and connects to known previous block headers), it will be stored and added to the chainstate. In this way, a node can know of and keep track of all branches of the blockchain without having the block itself.

Even if a headers chain does not have the most work, it will still be kept around forever and kept track of. Although blocks for that headers chain will not be requested, if any peers have that chain as their actual blockchain and the headers are completely valid, it will still be known to a peer and kept track of.

If a headers chain suddenly begins having invalid block headers, the chain of valid headers will still be kept and tracked; the invalid headers extending that won't be.


In CEX.IO Should I include the fee in the sending bitcoin amount? I'm using CEX.IO and I want to do a purchase in usi-tech with bitcoin. In this case I need to send the exact amount that they are asking to usi-tech from CEX.IO. When I'm going to enter the amount to withdraw from CEX.IO do I need to include the transaction fee also into the amount that I'm entering.

i.e If usi-tech asks me to pay 0.015 BTC and since the transaction fee of CEX.IO is 0.001 BTC. Do I need to enter 0.016 BTC to the amount field or just 0.015 BTC for the purchasing site to identify the transaction?

Please ignore the red message in the above image.

When sending a transaction to a recipient, they generally don't care what fees have been paid; they just care how much they've received at their given receiving address.

If you're wanting to send 0.015BTC then you'll need to ensure the fees don't reduce that amount. Given the screenshot, it is reasonably clear that you'd need to enter 0.016BTC to ensure that 0.015BTC arrives at the receiving address.


How is nSequence interpreted with CHECKSEQUENCEVERIFY? I am trying to understand the implementation/specification of OP_CSV with BIP112 and BIP68.
I understand the implication of the op-code and new consensus rules. I just don't understand exactly how the sequence number is represented.

First of all I am not sure what it means when e.g. the type flag of the sequence number is referred to as bit (1 << 22). Does it just mean it is the bit at position 22?

Similarly with the disable flag (1 << 31), is the bit at position 31? And what is its implication? It must be "unset" (=0?) to use the NEW consensus rules for the sequence number? Why is it necessary when the  version field of the transaction > 2 already tells to use the new consensus rule?

I also don't understand this sentence:
"The flag (1<<22) is the highest order bit in a 3-byte signed integer for use in bitcoin scripts as a 3-byte PUSHDATA with OP_CHECKSEQUENCEVERIFY (BIP 112)."
A 3-byte integer has 24 bits, or not? And one bit is used as sign. Then since the flag is the highest order bit, why is it not at position 23?
And why is it represented as a signed integer, when obviously negative block-counts is marked as error by BIP112?

Maybe somebody could give me an example of how exactly the sequence number would look like for the following:

Transaction confirmed with block 400,000 and:
scriptPubKey: "30days" OP_CHECKSEQUENCEVERIFY

Transaction that spends the output:
scriptSig: OP_TRUE
nSequence: ?

Does somebody know how the exact data of "30days" would look like (the bit/byte-wise number represenation with flags and all)?

First of all I am not sure what it means when e.g. the type flag of the sequence number is referred to as bit (1 << 22). Does it just mean it is the bit at position 22?

Yes. It means the bit position that is set in the integer 4194304 (in decimal) or 0x400000 (in hexadecimal).

  Similarly with the disable flag (1 << 31), is the bit at position 31? And what is its implication? It must be "unset" (=0?) to use the NEW consensus rules for the sequence number? Why is it necessary when the version field of the transaction > 2 already tells to use the new consensus rule?

Maybe some day we introduce a version 3 transaction that adds more possibilities. Maybe somebody wants to use one of the new features introduces at that time, but does not want relative locktime. He would be out of luck, as 3 is larger than 2.

  I also don't understand this sentence: "The flag (1<<22) is the highest order bit in a 3-byte signed integer for use in bitcoin scripts as a 3-byte PUSHDATA with OP_CHECKSEQUENCEVERIFY (BIP 112)." A 3-byte integer has 24 bits, or not? And one bit is used as sign. Then since the flag is the highest order bit, why is it not at position 23? And why is it represented as a signed integer, when obviously negative block-counts is marked as error by BIP112?

Integers in Bitcoin Script are always signed, and this is not changed for OP_CHECKSEQUENCEVERIFY, to avoid introducing more specific logic. As a result, the highest bit that is not a sign bit is (1 << 22).

I'll add an example later.


Configure esplora to point to the bitcoind servers ip address I have 2 servers running:

Ubuntu 18.04 running bitcoind daemon (v0.18.1 full blockchain synchronized)
Ubuntu 18.04 running esplora (the local single page website works, but it has no data from the local blockchain)

Both servers are on the same network.

How do I configure esplora to point to the ip address of the bitcoind server?  I would like to use my own full blockchain and explore it with esplora, aka a personal blockchain explorer.

The bitcoind server is already configured and working.  So the only part remaining (I think) is to configure esplora to point to the bitcoind server.  I can't find any clear instructions on how to do that.

esplora is just the web ui frontend, you also need to setup the (forked) electrs backend for indexing and for providing the HTTP API that esplora queries.
electrs can index the bitcoin block chain using two methods: by reading the blk files directly out of disk, or by querying for blocks using the bitcoind rpc. The first method is significantly faster, but requires electrs to have filesystem access to the bitcoin datadir, which would typically mean running them on the same server (you could technically do this remotely but you'll lose most of the performance gain, so not much point in doing that). The second method can work if you have two separate servers, but I wouldn't recommend it (would be painfully slow).
To setup electrs, install Rust and:
$ sudo apt install clang cmake # required for building rust-rocksdb
$ git clone https://github.com/blockstream/electrs && cd electrs
$ git checkout new-index
$ cargo run --release --bin electrs -- -vvv --daemon-dir ~/.bitcoin

If the bitcoin datadir is not at ~/.bitcoin, change --daemon-dir to point to it. It should automatically pick up the rpc credentials from the cookie file. If you want to index from a remote bitcoind node, set --jsonrpc-import --daemon-rpc-addr <addr:port> --cookie <user:pass>.
By default, electrs will bind its HTTP API server on 127.0.0.1:3000. To enable remote access, it is recommended to setup a reverse proxy with tls (like nginx) in front of electrs. You could also set --http-addr <host:ip> to have electrs accept remote connections directly, but you probably shouldn't.
The initial indexing process will take quite some time and disk space (up to 1TB at the peak during the indexing, which then shrinks down to about 450GB after compaction). To test it worked, you can try issuing requests to the electrs HTTP API:
$ curl http://localhost:3000/blocks/tip/height
$ curl http://localhost:3000/address/1EMBaSSyxMQPV2fmUsdB7mMfMoocgfiMNw

Then, to start esplora and point it to your electrs server, install nodejs and:
$ git clone https://github.com/Blockstream/esplora && cd esplora
$ npm install

# needs to be set to the URL where the electrs HTTP API is available for
# requests coming from the user's browser. if you're browsing from the same
# machine running electrs, this should work:
$ export API_URL=http://localhost:3000/

# start a dev server on port 5000 (on-the-fly babel/browserify transpilation, slow, cpu hog)
$ npm run dev-server

# or pre-build the web ui as a static directory with:
$ npm run dist

You will then have the esplora web ui available at http://localhost:5000/. As with electrs, it is recommend to setup a tls-enabled frontend http server for remote access, either reverse proxying the dev server, or (more ideally) directly serving the pre-built static files.
The last thing that you'll need to do is configure electrs to accept cross-origin requests from the esplora web ui. Do to this, add --cors <origin> to the end of the cargo run command. If you're accessing esplora locally, --cors http://localhost:5000 should work. Otherwise, set it to the origin that the esplora web ui is served from. Or just use --cors '*' if you're okay allowing cors requests from all origins.
Alternatively, you could also use the esplora docker image that makes setting up everything (bitcoind+electrs+esplora) much easier, but that doesn't play nicely with an existing bitcoind node.


What would happen to the world if Bitcoin were the only allowed currency? Could a world economy be based solely on Bitcoin? I mean the only mean to pay would be bitcoin.

From the point of view of economy would this be possible or would all the economy collapse?

Could we live only on Bitcoin, to make payments to work and so on, while this currency is so volatile?

It's possible, but with the current block size and lack of lightning network or side chains, no. Most likely people would do what they've done throughout history and use other forms of currency for daily use.


Bitcoin wallet for Symbian operating system? Can I use Bitcoin on my Nokia N97 phone which uses Symbian OS?

I cannot find any Bitcoin wallet applications on Ovi store :-(

I have found a wallet client for the Android operating system but that is hard to install on my N97.

I'm willing to compile a client from sources, but I can't find any. I've tried SourceForge but to no avail. Any suggestions?

CuteCoin might help

There is a project in GitHub that apparently provides a Symbian3 Bitcoin client using InstaWallet. See https://github.com/Matoking/cuteCoin for source code.

There is also some supporting discussion about Symbian on the forums here:
https://bitcointalk.org/index.php?topic=26154.0


Check if a user pays another user for bitcoin website I am creating a bitcoin website. I would rather the bitcoin didn't go through my website to prevent any security issues.

What happens is one user pays another user, and when that happens my website delivers the digital goods instantly.

All I need to do is check if the one user pays the other user. But the problem I can't find a way to do that easily.

I was going to use the blockchain api to check, but if they pay through a website like cryptsy, I can't check because it goes through multiple addresses.

The only solution I've found so far is to make them use the bitcoin wallet, or use an escrow service.

Escrow is my last option, because it always has a fee, and I really want this to be user to user.

I could really use some suggestions!

Thanks!(:

I think what you really need here is to be able to, on demand, get a new address for the receiver that is specific to a new order. So, for example, if the receiver of the coins is to get 1 BTC, then you get a new address for that user, associate it with the order, and as soon as it receives the coins you know that this order has been fulfilled.

It may not be so easy to get the user (receiver of funds) to give you a big list of their addresses ahead of time, though. This is where something like BIP32 wallets may come in handy. With Hierarchical Deterministic wallets, you can get an extended public key and generate addresses for someone else as needed without ever needing to know the private keys for those addresses.

Not all wallets are HD wallets, and probably even fewer support getting an xpub to give out to someone for generating new addresses on the wallets behalf. You'd have to do some digging to find a wallet that would let you do this. Obviously, you wouldn't be able to force the payers to use this type of wallet, but if there are relatively few receivers (merchants) you might be able to get them on board with using a more fully-featured HD wallet to receive their payments.

More info: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki


How do goods & services sellers manage price instability? How do retail outlets manage the massive price instability?

Are they really repricing every second with 25-50% spikes and drops over 24 hours?

How much does it cost to maintain accurate prices?  Most stores I go to have printed prices.

Please only reply with actual accounts of price instability management by sellers.

This isn't an account, but it covers anything an account could.

They update their prices based on how many USD they want for the item and the current BTC/USD ratio. There's even an electronic price tag that does this automatically: http://www.bbc.com/news/technology-26031331.

Online, it's usually handled by some outside payment process company like Coinbase. You set up the website to communicate to Coinbase "I need $x for this guy's order" then they redirect the user to Coinbase's payment page, where Coinbase asks the user for $x worth of BTC at the current price. When Coinbase gets the user's coins, you (the merchant) gets your money. Most merchants never touch the BTC.

In person, without the electronic price tags, it would be impractical (or even impossible) to price items in bitcoin by hand. One way around this would be to price them in USD, then take their total at the register to determine the amount of BTC needed for the purchase. Ie, the customer comes to the register with $x worth of goods, the merchant looks up the price of BTC (which they could do quickly), then asks the customer for $x worth of BTC.

If you mean how do they manage the risks of holding an asset that is volatile, the answer is that they don't hold it. They use Coinbase or similar.


Providing Liquidity in CryptoCurrency Exchange! Can anybody give some idea about the issue of providing liquidity to the users for creating a cryptocurrency exchange ?
Thanks!

The liquidity would be dependant on the amount of available exchangeable cryptocurrencies or fiat currencies. And to answer your question all crypto currencies, ICOs, tokens, and etc. hold some value and they can be exchanged, and that's what solves the liquidity issue.

For example coinbase accepts xyz $ and allows u to change it into xyz crypto currency like ripple or something, the more available currencies higher the liquidity and the ease of transaction increases the liquidity of assets.

This question is to some extent unnecessary. But, hey all of us get confused at times!


What exactly does censorship resistance mean? What features are needed for censorship resistant blockchain? In what situation can you say it's not censorship resistant?

This is a very overarching topic with many answers covering many facets of the Bitcoin / blockchain infrastructure. The network-level is considered by multiple communities to be the enforcer of censorship as it pertains to digital content and transactions.

In Bitcoin we would need to examine the network level and how enforcement of network decisions are made. First code changes are committed and either denied or merged to the actual code base. It is then up to the mining community to upgrade to that newer software version. The network upgrades to new changes when the majority of miners are running that new version.

If the overwhelming majority of mining is consolidated by one actor, or a nation-state, they could effectively censor your transactions by imposing limiting factors on your wallet.

This is only a major issues in Bitcoin and Bitcoin-derived currencies because of the public nature of transactions.


most profitable scrypt mining machine per dollar with unlimited budget and free power? I know The 7950 is the most efficient in (MH/s)/$/watt... but I have contractual access to unlimited free power. I'm already using the power anyway so the marginal cost of the power is actually zero. Is there a machine I could build and turn a profit with at this point? Litecoin is not the most profitable Scrypt coin to mine now, so don't assume I'm mining Litecoin.
The asics coming out "soon" might be a concern, if they actually even come out soon, but its my understanding that they are good for being low wattage, whereas the hash/dollar is similar to GPUs still.
Assuming I could be confident that a Scrypt asic manufacturer is trustworthy enough to buy from, I wouldn't be opposed to doing that, but thats really a pretty big gamble, unlike ordering a bunch of parts from amazon/newegg on cyber monday.
Also I'll be able to resell GPUs, so even if this becomes non-viable after 6 months or so, I'll be able to recover a decent chunk of my investment.
I say "unlimited budget" meaning I can fully saturate a motherboard with GPUs or purchase an asic without an issue, whatever the most efficient is.

There are a few other GPUs that do a bit better according to this list:

https://litecoin.info/Mining_hardware_comparison

I think this is just based on user feedback to the Wiki.  The ones with a lot more khash/s are multi-card setups.

Really if you have free power you should mine with whatever you can afford, then add more cards after you have coins and have sold them.  There are instructions on a cheap multi-card system here:

http://www.coinminingrigs.com/

Unfortunately many of the parts referenced are difficult to find - they sell like hot cakes!  The R9 280X is equivalent to the 7950 and is usually cheaper.

Don't forget that there are dozens of scrypt based currencies and mining the most profitable one over LTC can net you a lot more income.  I can't post any more links here but google multipool or check www.multipool.in for a start.

Also don't forget that if you put in a nice 4 or 6 core processor you can also do CPU mining for PrimeCoin, QuarkCoin or ProtoShares.

Good luck!


reconstruct block template from stratum mining.notify I have a mining notification from a stratum pool. I wish to write a general script to extract the value of the block reward that the pool is taking. That is, reconstruct the block template, or at least the sum of the coinbase transaction outputs / block reward, given the stratum mining.notify JSON. For example, we have the mining.notify JSON for a Digibyte sha256d block template:

{"id":null,"method":"mining.notify","params":["8c6e","4aab33fcf4579faee35bde813ad6f66f8e1c3fed97fb5763ac6de4d02b301277","01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff210472329000048b2c825d08","0d2f6e6f64655374726174756d2f00000000020000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9cd1576270f0000001976a914f54c85705d38622a202c6f97caf7248cc4be001c88ac00000000",[],"20000202","1908ef40","5d822c8b",true]}

Here, the "coinb2" string is:

0d2f6e6f64655374726174756d2f00000000020000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9**cd1576270f000000**1976a914f54c85705d38622a202c6f97caf7248cc4be001c88ac00000000

and this is the important part for the output transactions.

It turns out that in this case the reward is cd1576270f000000, written with bytes reversed, which corresponds to a base 10 integer value of 65086559693. If there is only one output address, we can guess here that the reward is the 8 bytes before the 1976, but what if there are many output addresses?

How can we find the sum of all outputs of the coinbase transaction given the "coinb2" string in the most general case?

If there is only one output address, we can guess here that the reward is the 8 bytes before the 1976,

No, you cannot. the 1976 is the start of the output script and can/will be different depending on the output script (i.e. address) that the pool wants to use.

The stratum protocol says that the hex for the coinbase transaction is coinb1 + hex(extranonce2) + coinb2. extranonce2 is produced by the miner and is of a size specified by the mining pool as the Extranonce2_size from the response to mining.subscribe.

So you can just create bogus extranonce2 of the correct size and concatenate the strings together as described earlier. Then put the result into a raw transaction decoder. Without the full transaction with everything (or placeholder data) in place, you cannot really properly decode the transaction reliably.


How to do sendRawTransaction to bitcoind JSON-RPC using bitcoin-core package in nodejs I am trying to do

sendrawtransaction <transaction_hex>

from nodejs using bitcoin-core package
i did

npm install bitcoin-core --save

i already have latest bitcoind setup and running with rpcusername and rpcpassword are set in bitcoin.conf

my current code looks like this.

const Client = require('bitcoin-core');
const client = new Client({ username: 'adminuser', password : 'adminpassword'});

client.getInfo((error, help) => console.log(help));

i have managed to only get response from getInfo

everything else gives either empty output or undefined or null

so far i have tried many variations like these

tx_hex = "0200000001949e0e3ac02fef76dffa8e2191ee0041f71a90c5ec9bbcba77db5f57e49fe6dd010000006b483045022100d6ac8520a1cfe80f6f3c2fbe6c3f903894203715928382e77c3c7ad0de74112502203c14601e5195dde88c9cc16c45dc273af168bd4fd03b6c045f832b7ba0134f8c012102183e719a510ff322fcb0dbfa279ef2500dd87c0b8c6184480846262e1949fbebfeffffff028bec0900000000001976a9141b0c5cb82d59cb2e07e8d5e343167fda48a9d60e88ace2920f00000000001976a9148108670170211830be2c3c557afe6bc2205d27de88ac864a0700"

client.sendRawTransaction((tx_hex,response) => console.log(response));

client.sendRawTransaction((tx_hex) => console.log());

client.sendRawTransaction((tx_hex), function(){console.log()});

but none of the above gives confirmation, or gives proper output.

what am i missing here ?

i mean if i were to do this using bitcoin-cli on terminal it returns txhash .

e.g.

[root@localhost deploy]# bitcoin-cli sendrawtransaction 0200000001949e0e3ac02fef76dffa8e2191ee0041f71a90c5ec9bbcba77db5f57e49fe6dd010000006b483045022100d6ac8520a1cfe80f6f3c2fbe6c3f903894203715928382e77c3c7ad0de74112502203c14601e5195dde88c9cc16c45dc273af168bd4fd03b6c045f832b7ba0134f8c012102183e719a510ff322fcb0dbfa279ef2500dd87c0b8c6184480846262e1949fbebfeffffff028bec0900000000001976a9141b0c5cb82d59cb2e07e8d5e343167fda48a9d60e88ace2920f00000000001976a9148108670170211830be2c3c557afe6bc2205d27de88ac864a0700
b9ceb300bc4a94dad591d8ecca7e840e7cfafa47c029488424e07666c1e1778b

update1 :

tx_hex = "0200000001949e0e3ac02fef76dffa8e2191ee0041f71a90c5ec9bbcba77db5f57e49fe6dd010000006b483045022100d6ac8520a1cfe80f6f3c2fbe6c3f903894203715928382e77c3c7ad0de74112502203c14601e5195dde88c9cc16c45dc273af168bd4fd03b6c045f832b7ba0134f8c012102183e719a510ff322fcb0dbfa279ef2500dd87c0b8c6184480846262e1949fbebfeffffff028bec0900000000001976a9141b0c5cb82d59cb2e07e8d5e343167fda48a9d60e88ace2920f00000000001976a9148108670170211830be2c3c557afe6bc2205d27de88ac864a0700"

client.sendRawTransaction((tx_hex,response) => console.log(tx_hex + ':' + response));

returns

RpcError: -1 sendrawtransaction "hexstring" ( allowhighfees )

Submits raw transaction (serialized, hex-encoded) to local node and network.

Also see createrawtransaction and signrawtransaction calls.

Arguments:
1. "hexstring"    (string, required) The hex string of the raw transaction)
2. allowhighfees    (boolean, optional, default=false) Allow high fees

Result:
"hex"             (string) The transaction hash in hex

Examples:

Create a transaction
> bitcoin-cli createrawtransaction "[{\"txid\" : \"mytxid\",\"vout\":0}]" "{\"myaddress\":0.01}"
Sign the transaction, and get back the hex
> bitcoin-cli signrawtransaction "myhex"

Send the transaction (signed hex)
> bitcoin-cli sendrawtransaction "signedhex"

As a json rpc call
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "sendrawtransaction", "params": ["signedhex"] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
:undefined

The way you pass parameters is wrong. I use the code below, got the right answer:

const Client = require('bitcoin-core');
const client = new Client({username: 'admin', password: 'password', network: 'testnet'})

const txHex = '0200000001999539009d0d02f2332d257716faa75cc4c9a8318c153ba6a084c719fa33103b000000006a4730440220032470b6b45825fc37d08e1985c7ad2044272edacfa2c76cf49c6b70c09a0dac02202466ede3e660c6d57f65b7ed21f2c1f778116ef92bef9ed2f9b18fcb1881a7b9012103b91ff254ae3bb3861e4a6c16ab356d6c52ccfd2b58bedf0dda84657dfd9d9afcffffffff0130750000000000001976a914ba05ece7632d78336848214b525cfdbd1c4b06a188ac00000000'

client.sendRawTransaction(txHex, (error, response) => {
  if (error) console.log(error);
  console.log(response);
});


Does an OP_RETURN script always need another output within the transaction? I was reading this:
Explanation of what an OP_RETURN transaction looks like
and I wondered if the second output "value" : 0.00200000, was at all necessary. Can I just have a OP_RETURN with a 0 output in the transaction?

If you want to retain any change, yes you will need two outputs to return unspent Bitcoin to yourself. If you are spending for example a 0.0001 BTC output, 0.0001 to fees, then a single 0 BTC OP_RETURN output would be valid.