online tool to play around with ECDSA public keys, message signature verification? I realize that this question may be borderline bannable because it's asking for suggestions on tools, but it will really help newbies. This online tool allowed me to play around with hashes and to really understand them at a deeper level: http://www.fileformat.info/tool/hash.htm

I can't find a similar tool (that works) for ECDSA cryptography where I can play around with public and private keys, and do digital signatures on messages, and test signature verification.

I've found these 2 sites that claim to do this but didn't work for me:

http://dbis.rwth-aachen.de/~renzel/mobsos/lib/js/jsrsasign/sample-ecdsa.html
http://extranet.cryptomathic.com/ecc/index

Thoughts? Suggestions?

UPDATE: Great suggestions below. Some tools I found:

for hashing:
http://www.fileformat.info/tool/hash.htm

generating public private key pairs and decrypting ciphers:
https://8gwifi.org/rsafunctions.jsp

Generating EC public private key pairs and signing Verifying the Message
https://8gwifi.org/ecsignverify.jsp

generating public private key pairs and testing signing:
https://kjur.github.io/jsrsasign/sample/sample-ecdsa.html

Here are a few I'd recommend:

https://bitcore.io/playground/#/address (private key - public key)
https://brainwalletx.github.io/#generator (signing and verifying but bitcoin specific)

Or play with pybitcointools at the command line (not online):

$ git clone https://github.com/vbuterin/pybitcointools.git
$ cd pybitcointools
$ python
>>> from bitcoin import *
>>> sk = random_key()  # Generate a private key
>>> vk = privtopub(sk) # Generate a public key
>>> msg = 'hello world' # Create a simple message
>>> sig = ecdsa_sign(msg, sk) # Sign the message using your private key
>>> print sig
GxXGAt...2L/eJk=
>>> print ecdsa_verify(msg, sig, vk) # Use sig and public key to verify
True
>>> msg = 'hello mars' # Change the message
>>> print ecdsa_verify(msg, sig, vk) # Changing the msg invalidates sig
False

http://showterm.io/203b168061b0156c4d1dd

HD Wallet stuff:

https://iancoleman.github.io/bip39/
http://bip32.org/

If you're looking to learn more about ECDSA suggest checking out: https://jeremykun.com/2014/02/08/introducing-elliptic-curves/


Loading Wallet error vWhen I open the bitcoin-qt (v0.8.5 beta) app on my MacBook Pro 10.7.5 it says - loading block index, verifying blocks, loading wallet - then immediately crashes on loading wallet to give message "bit coin-qt unexpectedly quit". I know the address of my wallet, but not the private key. How can I solve this problem ??

Find Windows PC (friends, work, family)

Install fresh bitcoin-qt for Windows and run it once and then quit
Open folder: %UserProfile%\AppData\Roaming\Bitcoin\ and replace wallet.dat file from Your Mac (overwrite)
Open bitcoin-qt again and if it start OK generate private key: Help > Debug window > Console > dumpprivkey your_wallet_address


Has anyone patched the code to experiment with the currency supply model? Since the supply model of a currency is a key factor in it's economic properties, I think it would be interesting to experiment with supply models that could be changed easily.

It could perhaps then be linked to some other external factor which could be objectively ascertained with the resilience of the p2p structure like for example, available fresh water, carbon or population.

Have there been any efforts in this direction?

There have been various experiments in this regard. The Alternate Cryptocurrnecies sub-forum is full of them. If I recall, Tenebrix and/or GeistGeld removed the halving block sizes, resulting in a coin without a cap on the number of coins.

Also, there is EnCoin, and alt whose price is supposed to be based on the cost of electricity.


Trading crypto currencies with dollars After I have bought a crypto currency at an exchange like Binance can I sell for dollars if it is going down. Basically if I have a profit from a currency what can I do with it to protect it?

Yes, cashing out is profit protection but, it is also a stop gain. Follow the exchange user guide for instructions on how to sell or contact their support team, the details of how you do this are exchange specific.


Teslacoin sync error - No Suitable Inputs Found Not sure this is the right forum for this, but I thought I'd ask out of desperation.

I have the following error when trying to sync my teslacoin wallet.

I managed to sunc about 6 weeks ago, however haven't been able to sync since then. I left it running overnight and get the error "No Suitable Inputs Found". I'm connected to the tesla network (I think, because I have 8 active connections).

My teslacoin version is v3.2.0.0
The QT version it uses is 5.3.2

Hope that's enough information, if there's anything else required, please let me know and excuse my limited knowledge on crypto, still getting my head around it :)

Thanks

Norrinrad

Updated wallet to v3.3 and re-ran synch :)


Better or worse to mine multiple workers on one machine? I use cgminer on Ubuntu 12.10 to mine bitcoins in the 50BTC pool. I have three workers set up. If I run multiple instances of cgminer, each targeted at their respective workers (1, 2, and 3), would this increase profits or just waste power?
I notice this because cgminer only uses about 80-90% of my GPU (Radeon HD 6570) anyway.

You ought to test the setup on the machine you will be using. Generally the mining software should efficiently use the entire GPU, but it might happen that it will not and actually running two instances at the same time will allow you to tap into more computing power. But again, check your speed while running one or more instances and see which one gives you more total speed.


c-lightning determine channel capacity I'm using c-lightning to experiment with sending micropayments backwards and forwards between 2 separate nodes.

One area I am experiencing great difficulty with is being able to generate an invoice and receiving this warning:

  "warning_capacity": "No channels have sufficient incoming capacity"

The command that received the warning above was:

$ lightning-cli invoice 1 l1 d1

The peer hash a single connection and a single channel:

$ lightning-cli listpeers
 {
  "peers": [
    {
      "id": "03eb6cac804699e4d941d4d170d088e37e67abc27b39e483fc5b68c423135cc3d4",
      "connected": true,
      "netaddr": [
        "192.168.1.11:9735"
      ],
      "global_features": "",
      "local_features": "8a",
      "globalfeatures": "",
      "localfeatures": "8a",
      "channels": [
        {
          "state": "CHANNELD_NORMAL",
          "scratch_txid": "7c621a81ed27b5e05a3e55acb5928e74f9c111bfa26f7a07660af6613e1a4453",
          "owner": "lightning_channeld",
          "short_channel_id": "1446307:37:0",
          "channel_id": "eb6227c6ff872c09b55897f49d3394dbd129b8839d05a32f6d5f93c510c3199f",
          "funding_txid": "9f19c310c5935f6d2fa3059d83b829d1db94339df49758b5092c87ffc62762eb",
          "msatoshi_to_us": 1599884,
          "msatoshi_to_us_min": 1599884,
          "msatoshi_to_us_max": 1600000,
          "msatoshi_total": 1600000,
          "dust_limit_satoshis": 546,
          "max_htlc_value_in_flight_msat": 18446744073709551615,
          "their_channel_reserve_satoshis": 546,
          "our_channel_reserve_satoshis": 546,
          "spendable_msatoshi": 1053884,
          "htlc_minimum_msat": 0,
          "their_to_self_delay": 6,
          "our_to_self_delay": 6,
          "max_accepted_htlcs": 483,
          "status": [
            "CHANNELD_NORMAL:Reconnected, and reestablished.",
            "CHANNELD_NORMAL:Funding transaction locked. Channel announced."
          ],
          "in_payments_offered": 0,
          "in_msatoshi_offered": 0,
          "in_payments_fulfilled": 0,
          "in_msatoshi_fulfilled": 0,
          "out_payments_offered": 4,
          "out_msatoshi_offered": 116,
          "out_payments_fulfilled": 4,
          "out_msatoshi_fulfilled": 116,
          "htlcs": [
          ]
        }
      ]
    }
  ]

My question is how can I determine what a channel's capacity is? I have made payments of 116 msatoshi from this node. Doesn't that mean I should now have that much incoming capacity to receive payments? Is the maximum incoming capacity of the channel msatoshi_total - msatoshi_to_us?

OK, the three figures you care about here are:

"msatoshi_total": 1600000,
"msatoshi_to_us": 1599884,
"their_channel_reserve_satoshis": 546,

They have 1600000 - 1599884 millisatoshis, ie 116.  But they need to keep at least 546 satoshis reserve, ie. 546,000.  Until they do, we won't let them spend any.

Hence the warning when you created an invoice: there's no way someone can pay it with the current channel configuration!


How do miners determine if a wallet has sufficient funds I have ready about 10 posts that are similar and none of them seem to answer my question so any help is appreciated.

My question is how to miners technically determine if a "wallets" has the "balance" to complete the transaction. Before you say this is a duplicate let me elaborate:

User A has private key A and Public key A.1 and A.2
User B has private key B and Public key B.1 and B.2

Transaction 1 A-> B.1 by User B sending B.1 to A and A signs the transaction (0.5 BTC for illustration) with that private Key.
Transaction 2 A-> B.2  by user B sending B.2 to A and A signs the transaction (0.5 BTC) with that same private key.

Now private Key B has 1 BTC. But sense No one knows that B.1 a and B.2 belong to B because those are derived dynamically from B how can you know how much A has? Further suppose you loose track of you public keys, so B.1 and B.2 have been forgotten. How are you able to figure out the bitcoins that B has access to?

The blockchain does not see wallets at all.  It only sees spent and unspent transaction outputs (txouts).  A txout is either completely spent or completely unspent - it cannot be "partially" spent and so there is no notion of balance.  (If you want to spend less than the full value of a transaction, you create a change output.)

In your example, there are now two txouts that B can spend.  The "private key" B would actually be a master private key - each "derived" key is really a keypair consisting of a private key B.1.priv and a public key B.1.pub.  So in order to spend the txout that was paid to B.1, user B must sign a transaction using the private key B.1.priv.  If B wants to spend the entire 1 BTC, she can create a transaction with two inputs and signed by both B.1.priv and B.2.priv.

It is true that nobody except B (and maybe A) knows that both txouts are spendable by the same person.  That is fine - they don't need to know.  This is considered a desirable privacy feature.

If B should lose B.1.pub, no problem - it can be regenerated from B.1.priv. This is part of how ECDSA works.   If she should lose B.1.priv, it can be regenerated from the master private key B.  If she loses the master private key, she is out of luck and cannot spend her coins.


Transactions confirmed on Blockchain but nothing received to my Blockchain wallet I need some info/help. I have sent some Bitcoins to my Blockchain wallet. They have all be confirmed and done with. But it has been 2 days now and nothing has shown on my wallet.
This is the transaction on Blockchain,

https://blockchain.info/address/14kQfsxstFMjhL1RJAngoiEU13BaVUVjbS

The final balance and total received sit at:

  Final Balance  $ 395.48

So I assume you haven't been able to access the coins yet. What wallet are you using? Is it possible that you have multiple addresses in your wallet and you need to manually find the privatekey/balance of 14kQfsxstFMjhL1RJAngoiEU13BaVUVjbS? Because from the Blockchain everything seems fine.


What is the math behind popular Bitcoin graphs? I want to graph Namecoin (or similar *coin) technologies? How can I create graphs similar to http://bitcoin.sipa.be, and blockchain.info for Namecoin?

For example this thread discusses how to analyze difficulty over time and provides this  equation and correlation covering 4 difficulty adjustments.

I'd like to understand the math required to create such graphs so I can port the trending to other *coin usages. (which invariably have different values)

The math behind those graphs is pretty simple, the main problem is crawling through the data and creating readable images automatically.

Difficulty (red line) can always be read from the generated Blocks, no problem there.

1/3/7/14/whatever-window estimates I assume are calculated by counting how many Blocks were generated in a given time period and at what difficulty. In general I guess it should be:

Estimate = (Difficulty * MeasurementTime) / (10 minutes * BlockCount)


Fee Paid vs Confirmation Time I there a graph correlating fee size and confirmation time?

A graph where I can see the fee paid by transactions which got confirmed in less than 20 minutes. Is there a graph like that?


Why didn't Bitcoin implement segwit in the first place? Why didn't Bitcoin implement segwit in the first place?

Why and how does non-segwit Bitcoin enable a miner to change a transaction's txid?

From Mastering Bitcoin ch. 7 § "Transaction identifiers":

  Before segwit, transactions could have their signatures subtly modified by third parties, changing their transaction ID (hash) without changing any fundamental properties (inputs, outputs, amounts).

Why didn't Bitcoin implement segwit in the first place?

The reason Bitcoin didn't initially have SegWit is up to interpretation, I would say that it simply was not thought of prior to transaction malleability. Although that is not its only goal. Segregated Witness was an idea proposed in BIP 141 as a soft-fork, meaning it did not require an entire network upgrade. Due to the nature of a soft-fork, it is backwards compatible with previous versions of the Bitcoin software. Over time, it has been gradually adopted.

  Why and how does non-segwit Bitcoin enable a miner to change a transaction's txid?

Mastering Bitcoin is referring to something called transaction malleability. Traditionally, the txid was a hash of ALL the data in the transaction including the signatures. Transaction malleability meant a signature could be slightly modified such that the txid would be changed entirely while the signature still remained valid.

As David has mentioned in his own answer:

  changing even a single byte in the transaction completely changes the transaction ID.

This created an opportunity for a "Denial-of-Service" attack where while the transaction was still valid, and every part of the transaction would have the same inputs/outputs, nodes could reject modified transactions and prevent them from confirming. With SegWit, the signatures (as implied by the name "Segregated Witness") are no longer part of this hash. Eliminating the issue entirely.

I recommend reading this article for more information on how exactly it is done in practice.


Should I mine bitcoins or litecoins? I don't pay for my own power, but I have two problems mining. I am CPU mining at 250 mhash/s because my AMD Radeon HD 7800 series graphics card will only produce 4.0 mhash/s (the other problem I'm having that I don't understand) but my main question is- what is more profitable to me? litecoin mining or bitcoin mining?

Litecoin mining is currently more profitable for likely all GPUs.

From the bitcoin and litecoin hardware wikis, you'd get 300-400MH/s for bitcoin mining and 340-470kH/s for litecoin mining if you set it up properly (and there is something VERY fishy about you getting 250MH/s with your CPU, I'd guess it is using your GPU though you don't know it...).

For bitcoin, the current difficulty is about 6,500TH/s.  Thus, you'd own about 300/6,500,000,000 of the network.  At 25 bitcoins per block, 6*24 blocks per day, and $800 per bitcoin, you'd make about $0.13/day.  There is specifically-designed hardware for mining Bitcoins, which is way more powerful than GPUs, so unless you can buy a dedicated mining ASIC, your energy bill would overcome your revenue.

For litecoin, the current difficulty is about 90GH/s.  Thus, you'd own about 340/90,000,000 of the network.  At 4*6*24 blocks per day, 50 litecoins per block, and $25 per litecoin, you'd make about $2.72/day.  It uses a different algorithm (called Scrypt) than Bitcoin. FPGAs and ASICs can't be optimized for this algorithm as much as they can be optimized for Bitcoins' algorithm, so Litecoins are mined exclusively with GPUs. This means that you can still be comptetitive, and you should mine those.


Can the Large Bitcoin Collider project 'break' into offline hardware wallets like the Nano Ledger S? Let's say the Large Bitcoin Collider manages to guess the private key of a particular Nano Ledger S. Can they then 'spend' or 'steal' the Bitcoins on the Nano or 'send' them to another wallet?

If LBC is somehow able to guess anyone's private key, regardless of how the private key is normally stored and generated, then yes, they can just spend the coins. All you need is the private key, it does not matter how the key was obtained.

Of course this is impossible to do in practice with today's technology. The range of possible private keys is incredibly large, much larger than a human can imagine. If the private keys were generated with sufficient randomness (which Ledger Nano S's do as they have a True Random Number Generator), then the probability of generating a private key that is in use is so small that it is effectively zero.


Using Bitcoin contracts to run a betting site without the need for deposits? There are a couple of bitcoin betting sites, but they all seem to require making a deposit with them. Is it possible to somehow use the Bitcoin contract system to establish a distributed betting pool? Once the bet is decided one way or the other, the transactions would become active.

The problem of course is who decides which side won. That could be the betting site operator. This way, you still have to trust them enough to make a fair judgement call, but at least they cannot just take everyone's deposits and run. The worst they can do is declare the wrong side of the pool the winner. Or maybe stay inactive, thereby locking funds (though this could be fixed by a decision deadline in the original contract).

Or this could be distributed as well. Maybe a majority of pool members gets to decide by some kind of voting process (requires fair losers). Or the block chain miners get to decide by including one of the two possible transactions into the block, just like they decide on double-spending right now?

Does any of this seem feasible (and meaningful)?

Giving the operator the power to control the identity of the recipient won't work, since he can participate himself and declare himself the winner. A majority vote also isn't too good because an attacker can make multiple entries, which is cheap to do if he knows he can guarantee a win.

It is necessary that the winner will be decided according to public data (such as the hash of a future block), and that the operator (or majority) will not be able to secure funds before sending payment to the agreed winner.

The only way I can think of is burn-escrow. Each participant sends a tentative payment to the operator which cannot be reversed, it can either be carried through or burned (with a deposit that incentivizes carrying through). Then the operator sends to the winner using his own funds. Then every participant forwards the payment. If the operator does not send to the winner, participants burn the payment and refuse to do business with the operator again.

There is some risk that the operator will be honest but participants will neglect to forward payments, or that the operator will be fraudulent but participants forward payments anyway to get the deposit. But with a properly calibrated deposit, these risks can be mitigated and entered into the pricing.


Transaction malleability I have been reading about transaction malleability a lot still doesn't make sense to me.
Is there a script I can use to test it out ?
If the transaction that is malleable is changed by the attack, how is it possible that the two transaction are still in the blockchain and the miners still pick the attackers TXID over the legitimate one?
Why our legitimate transaction not seen by the miners?

The transaction that you submitted and the transaction that was malleated in-flight or by a miner are both legitimate (valid) transactions. Transaction malleability means that a valid transaction can be modified in-flight, without invalidating it and without access to the relevant private keys. Even if changing the components of the transaction doesn't make it invalid, it changes the txid of the transaction. So if you plan on creating two transactions together, where the second spends the outputs of the first transaction, then you can be a victim of transaction malleability. This is especially important in Lightning Network where you create commitment transaction prior to signing the funding transaction.

  Is there a script I can use to test it out?

The easiest one to try out is ECDSA signatures as ECDSA signatures are by themselves malleable. You can just change the S component of the signature to -S and it will still produce a valid signature verification check. This was fixed by SegWit by moving the signatures from scriptSig to a separate witness component. Although the signatures are still malleable, the txid calculation does not include hashing the witness component (wtxid includes the witness component and hence is malleable).

  If the transaction that is malleable is changed by the attack, how is it possible that the two transaction are still in the blockchain and the miners still pick the attackers TXID over the legitimate one? Why our legitimate transaction not seen by the miners?

Many miners still follow a first seen policy which means they will use the transaction that they see first. Bitcoin operates a gossip network with best effort basis. If you broadcast your transaction to nodes directly connected with you then it might possible that one of them malleates your transaction and is able to send that directly to a miner before the honest nodes are able to do it. Thus the miner will keep the first transaction received and discard the second transaction as a double spend. The miner has no way of knowing which transaction was the one that was directly relayed by you. Only one of them will enter the blockchain, not both after the miner mines the block. It might also be the case that it is the miner you malleates your transaction.


How can I prove that I destroyed some bit coins? If I wanted to destroy bitcoins, and prove that it was done (with relative certainty), what would I need to do?

If you just want to make it clear that you no longer own them you can just send yourself 1 santoshi and put the rest up as a fee. If you want to destroy them there are a couple decent address to send them to in What is the Bitcoin equivalent of /dev/null?

EDIT: there are better answers here: How to generate a valid bitcoin address for destroying bitcoins?


Run bitcoinCash on same server with bitcoin I followed the great answer here how to install bitcoin legacy and bitcoin cash on the same ubuntu server?

and installed bitcoinCash client to my ubuntu server.

Now I have both binaries available but they both work on same configs and same blockchains as I see.

There supposed be a way how to tell bitcoinCash client to download its own chain and use its own keys, but I cant figure out where those setup files for bitcoinCash are located and how to change them.

Could anyone help pls?

You can create a new username for Bitcoin cash or change default directory.

adduser BitcoinCashUser

su BitcoinCashUser

BitcoinCashd -daemon

Now make sure it has own directory

cd ~/.bitcoin

You should find the files in here.

Change Bitcoin Directory

Follow these instructions on here

Note: kill bitcoin-cash before start it again.

ps ax | grep bitcoinCashd
kill -9 <Process ID>


Bitcoin Wallet: Will 2 payments within 10 minutes cause double spending I'm using a bitcoin wallet for managing all my transactions. For example, If I have bitcoin 2, 3 and 5. Firstly, I buy a product with price 5. Bitcoin wallet will create a transaction from 2 and 3. When my first payment haven't verified yet, I make second payment by a product with same price is 5. This time will bitcoin wallet choose 2 and 3 or bitcoin 5 for my second payment ? I ask this because first payment haven't confirmed yet.

If you have enough Bitcoin in your balance it will be all good. Double-spend transactions should only really be made maliciously by reusing the same inputs. If you are using a known wallet you should not have any issues.


Is there any way to listen to all transactions using bitcoind api? I understand that using json-rpc to listen for all transactions is a bad idea due to performance, but bitcoinj is able to do it. In reality bitcoind is parsing all transactions under the hood when it forwards them. Is there any way for bitcoind to notify me when it sees a new transaction (not paying to an address in the wallet)?

Surely its is able to notify other peers, so why not me?

One solution I am thinking of is running connecting a bitcoinj node to my bitcoind and then using that to listen to transactions.

Another solution is to just listen for blocks and lose the ability to see zero conf payments.

Yes by default newer versions of bitcoin core should have zeromq enabled by default. Check here -> https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md

If you're using java you can use the code snippet there (using https://github.com/zeromq/jeromq ) -> How do i parse the zeroMQ messages in java?


POS Receipt payment identification Lets have a scenario where POS software wants to support bitcoin payments with zero risk. Ideal is to store Merchant's Bitcoin address in POS settings.

The intention here is to uniquelly bind receipt in local POS Database with transaction hash on Blockchain, in order to know whether the receipt was already paid or not.

This is the scenario where Merchant generates QR Payment request with BTC price and recipient address. Some applications also pass a message but that is stored in internal memory and does not go to Blockchain.

I have came up with two possible algorithms.

Reserve last several satoshis for temporary ID. e.g. 0.00000065

As most of direct (F2F) payments takes less then 2 minutes. It would be possible to generate shorterm ID and then check the Merchant's address for latest transaction, once the temp ID was found POS would mark the receipt as paid and remember the tx hash. This would prevent
Possibility to handle the case where the payment comes from multiple inputs by adding together the inputs for merchant address.
1 BTC would have to be atleast $100000 in order to break this.
Tipping would break this.

HD wallet Generating from Bitcoin address

Generate new address for each Receipt paid in bitcoin.
I don't think this could be technically possible, as it is neccessary to derivate child key from master private key.
How to achieve this with knowing only the Bitcoin address of merchant?

Encode some message in ScriptPubKey OPRETURN

customer side (depends on wallet they run).

Is there any other - better possibility that is still unknown for me?

You should use a new address for each transaction, likely generated from an BIP32 extended public key (your #2).

  I don't think this could be technically possible, as it is neccessary to derivate child key from master private key.

Extended public keys can be derived from a parent public key if the Chain Code (256 bits) for that parent extended public key is known. Merchants should give you an extended public key and chain code, and then you can generate a new address for them each time. Note that your system wouldn't have any risk of exposing private keys, as you would only be using BIP32 extended public keys.

For technical information on BIP32, visit https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki.


Importing a private key (paper wallet) to Bitcoin Core client, while offline, is not actually importing Trying to import a paper wallet to bitcoin core, while not having a fully synced node.
I've used: importprivkey 1Lblablablablabla "MyLabel" false
It returns "null", which I understand means successful import.
But then when I use dumpprivkey with the associated public address, it says there is no private key associated with the address.
I also look in the GUI and can't find any clue as to where that private key has been imported.
So basically the wallet is not giving me errors of failed import, but also not actually importing the private key.
What should I do?

You can use dumpwallet to examine the wallet's contents after importing the private key.
(for completeness, since comments are disposable)


import btc electrum wallet into coinomi can I import btc electrum wallet into my coinomi mulit-currency wallet app?

They both use electrum servers and they both have seeds so it looks like they are a similar kind of wallet.

In electrum I have the option

File/Save Copy

This looks like it saves a file with no extension next to

/home/username/.electrum/wallets/default_wallet

Could I import this into Coinomi via

(Coinomi app) /Settings/Restore Wallet/RESTORE A WALLET

enter my electrum seed / recovery phrase and password...

Without loosing my coins?

Unfortunately the electrum seed is not compatible with BIP32/BIP44, which is essentially what Coinomi implements, so the answer to your question is no, you cannot import your electrum seed into coinomi at the moment, although this might be possible in the future.


What's the formula giving the % of succesfully maliciously messing the blockchain? With the recent (early 2014) GHash.io concerns about that particular mining pool getting too big, many people have talk about what a powerful miner could do if it wanted to "harm" bitcoin or double-spend, etc.

At one point someone pointed on that if you have 40% of the mining power, you have a 50% chance of reverting 6 blocks.

I'd have expected it to be (0.4 exp 7) (6 blocks + the next one) or something like that and not 50%.

What is the formula to use to compute the "harm" that a malicious miner could do and how many blocks he could revert?

EDIT

Here's a page containing the formula:

https://people.xiph.org/~greg/attack_success.html

Don't put too many blocks otherwise the code will have a numeric overflow.

But normally it's using the formula in the bitcoin paper and that page has been written by the person who came up with the concept of deterministic wallets (if I'm not mistaken). So I tend to think he knows what he's talking about.

The formula is directly from the original paper by Satoshi Nakamoto. Check pages 6-8. The paper has C code to easily compute the values, and that page you linked to is just that C code converted to javascript.


Can a Wallet Generated by Linux Multibit Client be Used with Windows Multibit client? Probably a stupid question.

I am planning to create cold storage using Multibit on Ubuntu LiveCD, get the wallet file out of it and store it securely.

In future if I use a Windows PC with Multibit and use the cold storage wallet file with it, should it work fine? Or the wallet file structure are different for Linux and Windows Multibit clients?

Thanks.

Absolutely, if it didn't it would be a bug anyways. Linux and Windows Multibit should work properly on the same backup.


How does the computational cost of verifying transactions scale with the number of total transactions? As more transactions are added to the block chain, does each individual transaction (ie. I send a bitcoin to a friend) get more expensive (in terms of FLOPS) to verify and commit to the chain? If each new transaction cost does change the difficulty of verifying subsequent transactions, how does this scale?

I'd appreciate any answers, links or even location in the code where this happens. Thanks.

Reference: bitcoin wiki on confirmations

As more transactions are added to the block chain, does each individual transaction (ie. I send a bitcoin to a friend) get more expensive (in terms of FLOPS) to verify and commit to the chain?

No, it does not get more expensive in terms of anything. It especially does not get more expensive in terms of FLOPS because there are no floating point operations in Bitcoin.

The only cost of verifying a transaction is that it may cause the UTXO set as a whole to become larger, and as the UTXO set becomes larger, it becomes slightly harder to pull the necessary information from it to verify transactions. It does become harder to sync the blockchain as the UTXO set grows. Otherwise there is no compounding cost of verifying transactions as more transactions are added to the blockchain.


How many non-web wallets discard private-keys? or How common are non-deterministic wallets? I'm concerned about non-web wallets that discard private keys after use.

Web wallets - share addresses between users, so the user can consider all private keys to be immediately discarded.
Deterministic wallets - All receiving addresses can be regenerated at any time and so it's impossible to lose funds that are transferred to previous addresses even ancient ones.
Paper wallets - are essentially permanent addresses, so no issue there beyond user-error.

So this just leaves me with the question of how many non-deterministic wallets discard previous addresses (including change addresses)?

It has been stated that "the BIP 0032 standard for Hierarchical Deterministic Wallets is used by all good wallets as of 2019.".  Should I take that assessment literally with regard to non-web wallets, that non-deterministic wallets are uncommon even on mobile?

None. No wallet that exists discards private keys. That would be superbly idiotic to do because that means that money could be thrown away permanently. No wallet would intentionally do that.


What does it mean to have -1 confirmations? I have -1 confirmations for an inbound transaction on my Electrum wallet. What does is it mean to have -1 confirmations?

It is a known bug, just restart the client and/or switch to another server in the Network window (green dot in the bottom right).

If this doesn't fix the 'Unverified -1 confirmation error' try deleting the block_headers folder on your Electrum directory -> https://bitcointalk.org/index.php?topic=330626.msg5292794#msg5292794


transferring bitcoin among friends and taxes I gave my friend btc (ie sent it to their address) to trade together with their btc last week. I'm suddenly worried about taxes (in the US). If right now, they give me back exactly as much btc as I gave them, are there tax ramifications? Can I sell the btc after > a year and pay the 15% capital gains tax or whatever, or is there some short-term hold complication, and do I have to pay more?

They will most likely see any BTC credit in your account as "income" and you are taxable for it, unless you can prove it otherwise. This is a matter of when the IRS will start cracking down on these exchanges and request them to provide a 1099 for every user. I do not do trading via fiat because of this. The end-game is to acquire more Bitcoins, not fiat.

When its time to sell your Bitcoin for fiat, you won't have to because everyone will be willing to take it. -- See this: http://imgur.com/gE8hDnY


What is the exact difference between a Bitcoin and Bitcoin Cash raw transaction to address sighash_forkid? Bitcoin Cash apparently uses sighash_forkid, such that if you don't implement that into your raw transactions, the bitcoin cash network won't accept it.  How would one need to alter (what to add and how to get it) a transaction made to bitcoin tx specifications, to make it work on the Bitcoin cash chain?

It has been suggested that in an answer to this question:

  The SIGHASH_FORKID is an addition to the sighash type and simply means that the sighash type must have bit 6 set.

What is it to "have bit 6 set"?  And set to what?  What is an example of it being "set" and not being "set"?  Instead of "01" can I just type ĹéêŤ or does it need to be a "01" or a "02" or what can it be or not be?

Bitcoin Cash changes the sighash preimage to the one that is used by segwit. This is specified in BIP 143. OP_CHECKSIG on the Bitcoin Cash chain must use this new sighash preimage creation algorithm, but OP_CHECKSIG on Bitcoin uses a different sighash preimage creation algorithm (the original one), so they are incompatible with each other.

The SIGHASH_FORKID is an addition to the sighash type and simply means that the sighash type must have bit 6 set.


How to determine if a cryptocurrency has a promising future? This may be a very subjective question. I've watched this video where Lark states that some coins (Monero, ZCash, DASH, etc) have a promising future and others don't.

What's the criteria to make this kind of predicion?

Is it possible to speculate the future of coins that are on their early stages (with little value and not much information about them in the community)?

Whenever I am looking into an ICO, there are some things I generally take into consideration.

1. Team

-Make sure the team is real, and verifiable. Check linkedin, or other sites to verify the teams identity.

2. Token allocation and funding

-Check their practices and see if they are common. Pundix’s ICO is a great example. Removing total investments as soon as an ICO’s coin reaches an exchange is a widely practiced strategy. Lately, more ICO’s are looking for ways to ensure the token is held for longer terms.

3. Token or coin supply

-Check to see the burn policy, and the % of coins going to the public vs the investors.

4. Purchase cap per person

-Some ICO's have bonuses for early investors with huge capital. Make sure there isn't 1 person holding a majority of the coin.

5. Know the Market Caps

-Try to guesstimate and speculate a realistic market cap for an idea. If the market cap is low based on the fundraising, but something that could potentially become huge, there’s a lot of potential.

6. Project idea

-What is the value proposition? Does it really need blockchain? Or is it just riding the hype? Make sure that Blockchain is necessary.

7. Likely to end up on exchanges

-To cash out easily, it must hit an exchange. The more likely, the easier it is to get your profit.

8. Working MVP or product

-Are you investing in a product or an idea that has to be proven and validated? The more developed the product is, the safer it would be to hold long term.

9. Activity among fans/investors

-Check telegram and other sites to see the feedback/hype from other investors.


Generate bitcoin address from public key file Is there a way to generate a bitcoin address from public key with openssl command line ?

Thanks

Which kind of address do you want?

Assuming that you have compressed public key(compressed_public_key.txt), to generate P2PKH you can use these commands (hash160 and encoding with base58)

  ADDR_RIPEMD160=$(printf $(cat compressed_public_key.txt | xxd -r -p | openssl sha256| sed 's/^.* //') |xxd -r -p | openssl ripemd160 | sed 's/^.* //')
  ADDR=`printf $VERSION_PREFIX_ADDRESS$ADDR_RIPEMD160 | xxd -p -r | base58 -c`
  echo $ADDR

Where $VERSION_PREFIX_ADDRESS for P2PKH addresss are 0x00 for mainnet or 0x6F for testnet (https://en.bitcoin.it/wiki/List_of_address_prefixes)


Does 4 byte Nonce enough to proof of work? Is it always possible to find an hash value of a block, smaller than the current difficulty, just using 4 byte (Nonce) ? How can we be sure about it ?

No, it is not enough.

There is extra-nonce field. The scriptSig of coinbase transaction.


Getting BTC-E historical prices Is there a way to get BTC-E older ticks?
On their api docs I only found how to get the current Tick.

Not from Btc-e though you can probably get them from bitcoin charts or start keeping your own and then just query that (thats what I did.) Btc-e's API sucks, but heres a project that makes several API calls not in their official documentation.


Pricing TradeHill compared to MTGox I've just launched a trading app that trades on MTGox and TradeHill.

I'm noticing something strange on TradeHill though. Basically I get my quote and place an order directly after. The order never gets filled as the price has already moved. I don't notice this on MTGox which is a surprise because there are higher volumes there and one would think that the price would move quicker there. Also, if I log on to TradeHill myself and fill the order form manually using the quoted price my order has been filled by the time my browser reloads the page?

Have any of you guys noticed this? These orders are being made when there is an arbitrage opporunity between MTGox and TradeHill.. Could this be the reason for the momentary volatility.. i.e. lot's of bots place orders to exploit the difference?

Any ideas on this appreciated.

Thanks :)

P.S. I forgot to mention that there is often a pretty large spread between bids/asks on TradeHill.

EDIT:
I'm using the ticker API to grab buy/sell quotes. I will then place an order for 1BTC to buy/sell at the quoted price. I'm not currently looking at market depth. I have planned on looking at it later to figure out the max volume I could use any given time.

Also, yes, that was silly of me high volume = low volatility.

The problem might be that TradeHill adds orders to the Orderbook before processing them.
For example, this happened today:

Around 18h10 UTC, the highest bid was 4.842524 and the lowest ask was 4.840000
Around 22h00 UTC, the highest bid was 4.820000 and the lowest ask was 4.819900

I have also detected similar situations at ExchangeBitcoins.com.  CampBX  and MtGox seem to be matching orders before displaying them so you shouldn't have these problems there.

If you don't want to risk putting an order that will never go through, you should detect situations like this in your code and wait for the orders to solve. If the lowest ask is lower than the highest bid, something is not right.


Buying 100 kilobitcoins This is a hypothetical question. Assuming that the price of bitcoin is $8,250 (as of current writing) and I had 25 billion dollars at my disposal, what would happen to the price of bitcoin if I successfully bought 100,000 bitcoins? Would I have enough money? If so, how much would it cost? I am curious about this because of the digital scarcity aspect of doing so.

While I agree with chytrik I would want to suggest a concrete method of approaching this.

Have a look at the combined order book https://data.bitcoinity.org/markets/books/USD you can see that you currently would move the price by 10 % if you baught roughly 10k BTC. Usually after such moves people get alerted and are willing to sell at higher prices so you could wait a little until the order book fills and repeat the process.

Assuming there are always 10k fresh floating BTC available with leads to a 10% price increase. (With regular trading many of the btc on the order books are going to free float afterwards so that assumption is pretty strong) you would have 10 = 100000/10000 price increases of 10 % each resulting at a price of 8250*1.1^10 = 21398 per btc.

You would have to pay roughly 1.4 bn usd which is 8250*10000*(1.1^1+1.1^2+....+1.1^10)

Obviously this is just a simple model build on strong assumptions. Also you would try to buy that much btc otc because you would not want to move the price but obviously you would have to convince holders to sell


Unable to install Bitcoin Core on my MacOS High Sierra I'm trying to install Bitcoin Core (downloaded from bitcoin.org/en/download) on my MacOS High Sierra. But, I'm repeatedly getting the error The document "Bitcoin-Core" could not be opened. Finder cannot open files in the "volume" format.

Tried to google about it. But, didn't get any information about this error. Need some help to install this on my machine.

Currently using MacOS High Sierra(10.13.6).

Dammit, what was happening I don't know as a bit new to this MacOS thing. But, rather than double clicking on that stupid drive icon of "Bitcoin-Core" in desktop... I clicked on the drive icon from left-hand side pan from "Devices" section on Finder window & it opened without any error. It's working fine now. Problem fixes guys. What a waste of time. -.-


Bitcoin core make error I am new to bitcoin core development.  I have created a clone using bitcoin core on a mac os mojave 10.14.3. I am have installed all dependencies and am able to run the autogen.sh and configure with no errors. However, when I run make I am getting the following error.

/opt/local/bin/ranlib: object: libbitcoin_server.a(libbitcoin_server_a-addrdb.o) malformed object (unknown load command 1)
/opt/local/bin/ar: internal ranlib command failed
make[2]: *** [libbitcoin_server.a] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

Kindly help.

macOS Mojave changes how the header is serialized in the beginning of the executables. Maybe you could tell us how you installed the dependencies (using brew?) and the version of the compiler?


claim bitcoin cash with bitcoin qt wallet I need to claim my bitcoin cash I held my coins in the bitcoin qt wallet from the spring on 2013 to the middle of aug. Can anyone point me in the right direction to get this done?
Thanks

First of all, move your bitcoin to a new wallet. So it stays safe and secure.

Then download Electron Cash Wallet, create a new wallet and sweep the private key(s) of your old bitcoin-qt wallet.


How can I access a bitcoind instance from another device with wallet functionality? I'm running bitcoind 7x24 on a linux host on my network so it is always in synch.

Options like:

  -rpcuser=<user>        Username for JSON-RPC connections
  -rpcpassword=<pw>      Password for JSON-RPC connections

suggest it is possible to have a wallet client on my Windows PC access that server and operate the wallet.dat on the Linux PC.

But my attempts have not met with success.  Can you suggest a solution or at least help me understand why this is not possible.

I have seen selfmade PHP frontends. May check google, forums, github or other sources. (want to avoid to post links there).

To answer the question properly: You can access the bitcoind instance through the RPC and do all kind of things. This indeed allows to use existing or selfmade frontends.

For reference on bitocin RPC check the popular forums or google up "bitcoin rpc commands"

If you intend a connection between a private server and you home server you could secure the copnnection additionally with a VPN for example.


Why there are blocks with single transaction in blockchain? Just opened blockchain.info and found two blocks with single transaction on the main page:

292942
292947

Isn't it strange?
More than this, block 292941 was issued just minute before 292942 and has 128 transactions.
Block 292946 was issued just minute before 292947 and has 238 transactions in it.

So the question is: why there are such empty blocks in blockchain even if there are some transactions to be included? Is this some kind of misuse?

UPD:
Using this little script

for b in {292000..292999} ; do
  curl -s https://blockchain.info/block-height/$b?format=json \
    | jq -c -r '.blocks[] | "echo `date +%FT%T -d @\(.time)` \(.n_tx)"' \
    | bash
done

I found 10 empty blocks. It does not looks like a coincidence. Seems like someone thinks that this is more profitable to mine for empty block. If this is the case, it will ruin bitcoin.

No, it isn't any kind of abuse. You don't have to worry (well perhaps a bit) about 'transaction starvation' (i.e. transactions that get never included because miners refuse to include them), as it is unlikely that one person (or more cooperating) will obtain 51% of the hash power. And even when they obtain 51%, they will be basically cutting themselves from the potential fees involved (and huge investment is required in something that could become worthless after abusing the system, because as a result the trust in bitcoin and therefore its price will fall). Only very large organisations like governments or international banks could potentially pull such trick to bring bitcoin in discredit and recover the loss. To counter this, several solutions have been proposed, such as proof of stake (in contrast to bitcoin's proof of work).

As for why these particular blocks do not contain any transaction at all: I don't know. I don't think there is any special reason for it, but I could imagine that by chance some of these blocks have less or no transactions (don't think that's the case here) or that some independent miner simply did not bother to include any transaction because of the low fees involved.


Can someone please explain how Lightning paths are working and what effect large centralized hubs have? Can someone please explain how Lightning paths are working and what effect large centralized hubs have?

Dear community,

I have read some stuff about lightning and i am really interested to understand these questions, hope someone can help:

1)  this interesting article here https://hackernoon.com/them-lightning-network-nodes-sure-do-look-centralized-to-me-what-gives-ee39c9b12ac0

basically it says that lightning wont be so "centralized" in the future.

Now, i am struggling with that conclusion.  If you want to route a lightning payment via your node, your channel(s) must hold at least a balance of the to-be-routed amount, right?  If not, your node by definition cannot be chosen as a potential routing path.

So, in the future, when we dream about mass adoption: in the financial markets space, where many large amounts will be transacted: Only a few "big" corporate nodes with large balances in their channels, can be chosen for routing  of large amounts, right?

Or is there an algorithm in place, where an amount of for example 100million could still be routed via a list of channels held by multiple nodes (sort of "hopping" through multiple channels until you arrive at 100million - for example 10+10+10+10+10+10+10+10+10+10)

Or is the lightning putting you always to a direct path to the ONE single channel that has the 100million available as balance?

Oh dear, I realize how messy my question is. Hope you understand what I want to know:)

2)  Second, I would like to know how the lightning algorithm is deciding via which channels/nodes to route payments?  Because many articles say that like 0.6% of all Lightning nodes are routing like about 85% of the overall lightning payments. And those 0.6% happen to be the ones with highest "capacity"

Why is that? Why not more evenly distributed?  And what is the meaning of "capacity"

I refer to this article, the table at the very end:
https://medium.com/coinmonks/bitcoin-lightning-network-run-your-node-at-home-for-fun-and-no-profit-da5b61be2ba9

3) What roles play WatchTowers in the future? And what influence could they have regarding (de)centralization of lightning?

4) Is there some sort of "penalty" in place when a node withholds a payment or does not route a payment? Or are these technically  non-valid scenarios?

5) Censorship:  How is transaction censoring possible in lightning ecosystem?
What are the scenarios here, and any preventing mechanisms planned/already in place?

An article in https://news.bitcoin.com/lightning-network-centralization-leads-economic-censorship/  writes:

""
A large miner (or even a majority cartel of miners) cannot effectively censor your transactions, because ANY miner can include your transaction in a block.
But the same is not true for LN hubs. They can effectively censor your transactions, because NOT any hub can route your payment.

Example: Megabank “A”, “B”, and “C” all decide to become Lightning Hubs. They all acquire customers and have channels open between the 3 banks. This allows customers from any of the banks to send money to other customers of those 3 banks.

You, being a freedom-loving individual, decide to open a channel with an anonymous hub known only as T35G7. Guess what. Megabanks A, B, and C don’t want to open a channel with T35G7. So you can’t send to any of their customers since there’s no available route.
""

6)  Finally, at the end of the day, my basic desire is to understand in what extent , within what ramifications, CAN Lightning become a highly centralized ecosystem, instead of a highly decentralized one.

Thanks so much for any helpful explanation:)

If you want to route a lightning payment via your node, your channel(s) must hold at least a balance of the to-be-routed amount, right?  If not, your node by definition cannot be chosen as a potential routing path.

yes this is true. If you don't have enough bitcoin to forward you cannot forward a payment.

  So, in the future, when we dream about mass adoption: in the financial markets space, where many large amounts will be transacted: Only a few "big" corporate nodes with large balances in their channels, can be chosen for routing  of large amounts, right?

I believe that the many large amounts is a strong assumption. I believe the amounts of financial transactions should be Zipf distributed with the vast majority of transactions being small and only a few transactions being large.
In the latter case (which is the one you ask about): if you want to transact a large value just open a new payment channel to the recipient (which with wumbo channels will be possible in the future). It is useful as they can spend the amount then. Also you could do it offchain but no need to.

  Or is there an algorithm in place, where an amount of for example 100million could still be routed via a list of channels held by multiple nodes (sort of "hopping" through multiple channels until you arrive at 100million - for example 10+10+10+10+10+10+10+10+10+10)

Also note that in the future AMP (atomic multi-path) routing will be implemented so that large payments can be split into various small payments. It is well known how to implement AMP and it is part of the BOLT 1.1.

  Or is the lightning putting you always to a direct path to the ONE single channel that has the 100million available as balance?

Path selection is not part of the lightning network protocol. It really depends on the implementation or even on you as the user as you are allowed to specify a path.

  Second, I would like to know how the lightning algorithm is deciding via which channels/nodes to route payments?

see above. Generally people try to find shortest paths that are likely to have enough liquidity.

  Because many articles say that like 0.6% of all Lightning nodes are routing like about 85% of the overall lightning payments. And those 0.6% happen to be the ones with highest "capacity"

Many articles?

The last statement doesn't seem provable to me. Since onion routing makes payments private, we would only know for our own node which routes we have taken and how many payments we have forwarded. While it is likely that most routes go through high capacity nodes the exact numbers are pure speculation. Could be more could be less.

  Why is that? Why not more evenly distributed?

I'd say because currently only a few people have been #reckless enough to provide large liquidity to this cutting edge technology in which due to potential software bugs one still could lose funds.

  And what is the meaning of "capacity"

Capacity is the amount of bitcoin sent to the 2-2 multi-sig wallet that is used to anchor a payment channel. This should not be confused with the balance which are the two outputs in the secret commitment transaction from that 2-2 address. The balance is sometimes referred to as inbound and outbound capacity but it is only known to the channel owners.

  3) What roles play WatchTowers in the future? And what influence could they have regarding (de)centralization of lightning?

Watchtowers have been proposed as a service in which a third party monitors your channel state and helps you to make sure that your channel partner does not try to steal BTC from your channel by publishing an old state. In general it makes the lightning network safer to use. If that incentivises high capacity nodes to provide more liquidity or low capacity nodes to provide more liquidity we cannot say and is pure speculation.

btw, please be specific what you mean when you talk about "centrality". My feeling is that you mean nodes having high liquidity. I would much more prefer to talk about betweenness centrality.

Also keep in mind that the bigger issue with watch towers is that they might gather so much information about ongoing payments that the privacy of the lightning network is at risk.

  4) Is there some sort of "penalty" in place when a node withholds a payment or does not route a payment? Or are these technically non-valid scenarios?

Short answer: Not really.

However, holding a payment up to the maximum CLTV_delta means that you cannot use that liquidity in your HTLC output to route other payments. Which means the node will earn less fees. So, economically a node is incentivised to route a payment as quickly as possible.

However, if a node wants to act in a delaying way to disturb the network it can do so. It is up to the nodes who are connected to that node to track such behavior and close their channels or to the sender nodes to not select this particular node for routing.

Also, keep in might that a node can at max hold 483 HTLCs per payment channel. So, you could only delay a small amount of transactions if you want to delay them for a long time.

  5) Censorship:  How is transaction censoring possible in lightning ecosystem?
  What are the scenarios here, and any preventing mechanisms planned/already in place? An article in https://news.bitcoin.com/lightning-network-centralization-leads-economic-censorship/  writes: "" A large miner (or even a majority cartel of miners) cannot effectively censor your transactions, because ANY miner can include your transaction in a block. But the same is not true for LN hubs. They can effectively censor your transactions, because NOT any hub can route your payment. Example: Megabank “A”, “B”, and “C” all decide to become Lightning Hubs. They all acquire customers and have channels open between the 3 banks. This allows customers from any of the banks to send money to other customers of those 3 banks. You, being a freedom-loving individual, decide to open a channel with an anonymous hub known only as T35G7. Guess what. Megabanks A, B, and C don’t want to open a channel with T35G7. So you can’t send to any of their customers since there’s no available route.
  ""

No, this is not true. While Megabank A, B and C could decide not to route a payment that you initiate to T35G7 this will be hard in practice. First, every single "Megabank" does not know that this is a payment from you to this node unless the route looks like this You--> A --> B --> C --> T35G7 AND the Megabanks share all their information. In that case, you could see the banks as one node and the path looks like that You--> MEGABANK --> T35G7. In that case, yes, MEGABANK could refuse to forward a payment but it does not even know that You wanted to pay T35G7 because the route could actually look like this: some sender --> .... --> You --> MEGABANK --> T35G7 --> ... --> some receiver.

Also, what those described megabanks certainly cannot do is to prevent you from opening a direct channel with T35G7 which is the thing you should do anyway if you can't find a route on the network.

BTW the absurdity of the described scenario could also be transferred to Bitcoin mining if you have a cartel of bitcoin miners. Because that cartel could just agree to not mine on top of the blocks from other miners which includes such a transaction. If the cartel is a real cartel with more than 51% of the mining power, they can effectively censor any transaction...

  6)  Finally, at the end of the day, my basic desire is to understand in what extent, within what ramifications, CAN Lightning become a highly centralized ecosystem, instead of a highly decentralized one.

The lightning network is a protocol on top of bitcoin. It is a well-known set of rules for people that consent to use Bitcoin in a certain way. In that sense, it is totally optional and always boils down to Bitcoin. Payment channels really are just 2-2 multi-sig wallets in which your funds are not locked as they can (under good circumstances) be moved around without the necessity to wait for Bitcoin miners or the blockchain or and empty mempool.

I always compare the lightning network with the world wide web. It is an open permissionless standard that anyone can participate. Might there be some "megabanks" providing high liquidity and utility which become dangerous. Certainly. The same happened with the Web and the emergence of huge Web companies that have integrated extremely deeply into our everyday live. However, it is always the choice of the user to use such actors. The lightning network itself like the Web is a decentralized technology. This does not prevent central services to emerge but as said they don't have to be used and certainly don't control the technology or the protocol.

So, I really hope I could bring some light to all the paranoia that is being spread by some people...


Bitcoin purchases by country I'm interested in getting data on bitcoin adoption by country. Is there a way of mapping bitcoin addresses to countries of origination?

Nate is right.  But there is this tool:

http://fiatleak.com/

which can help you see a particular currency's exchanges in and out of Bitcoin.

Euro, USD and Yuan are usually the most predominant.

It could be somewhat helpful, it is open and javascript based so you can see how it works.

That could possibly give you additional ideas on solving your problem.


Does bitcoind not support txindex=1 option in regtest mode? Is it possible to specify txindex=1 option in bitcoin.conf or elsewhere?
It doesn't seem to work. Whenever I run bitcoind -daemon, it stops.

If I remove txindex=1 from the conf file, it works.

I am using regtest mode.

Here is the conf file:

rpcuser=abc
rpcpassword=secret
regtest=1
rpcport=8332
txindex=1

If bitcoind stops, them you should have a look in your debug.log file.
Enabling -txindex with an already initialised blockchain (not your first regtest start) requires a reindex.

Either you start with -reindex-chainstate or you delete your <bitcoin-data-dir>/regtest folder


Does bitcoin core 0.18 support bip44,bip39 (HD wallet) I am new to bitcoin. Struggling to implement HD wallet. goggled for the same but did not get satisfied answer. Can we create multiple seed in single bitcoin core server?

If yes, then how we can manage the private key of each generated seed.
   If no, then how we can create custom derivation path.

Note: I am using json-rpc protocol to communicate with bitcoin core.

You seem to have confused a couple of things.

Firstly, HD wallets is specified by BIP 32, not BIPs 39 or 44.

Secondly, being able to set your own seed is completely unrelated to setting a custom derivation path. They are two different things that have no effect on each other.

Note that BIP 39 specifies a menmonic scheme, not a seed. When I say mnemonic, I will be referring to BIP 39 mnemonics. When I say seed, I refer to BIP 32 seeds. They are two different things.

Bitcoin Core has had BIP 32 HD wallet support since 0.13. Since 0.17, it has had a sethdseed RPC which allows you to replace a wallet's BIP 32 seed with a custom one or a newly generated one. Note  that this does not allow you to have multiple active seeds in one wallet.

While you can set a HD seed with sethdseed, you cannot set a BIP 39 mnemonic. BIP 39 mnemonics and the seeds that they produce are incompatible with Bitcoin Core.

Lastly, while you can set a new HD seed, you cannot change the derivation paths that are used to derive keys. Bitcoin Core does not follow BIP 44's derivation path specification. Instead it uses m/0'/0'/i' as the derivation path for receiving addresses, and m/0'/1'/i' for change addresses.


Are bitcoins (or fractions of bitcoins) labeled with IDs? Many sources describe the double spending problem by saying something like "people cannot be able to spend the same bitcoin twice." [1][2][3] So are bitcoins, or the smallest allowable bitcoin fractions, distinctly labeled entities? My understanding was that they are not, and that the blockchain only records information on the amount of bitcoins each user has.

Also, if I am correct, what would double spending actually look like in the bitcoin system? If I send a transaction to one miner saying "I pay user X 1 bitcoin" and another transaction to a different miner saying "I pay user Y 1 bitcoin", then it seems like I haven't double-spent, but rather just paid two bitcoins in total, one to each user. Right?

So are bitcoins, or the smallest allowable bitcoin fractions, distinctly labeled entities?

They are unspent amounts (outputs of prior transactions) associated with addresses. Unspent transaction outputs are abbreviated UTXO.

Bitcoins or fractions (millibits, Satoshis etc) don't exist as entities in computers running Bitcoin software. The computers just keep track of the movement of amounts, they keep track of UTXOs, transactions, addresses and so on. Those are the identified entities.

  what would double spending actually look like in the bitcoin system?

Two transactions with the same input UTXOs.

The first one to be mined and "confirmed" will be valid, the second one will be regarded as invalid. There can be a period in which the outcome is uncertain until a consensus emerges.

See also Replace By Fee (RBF)


Is there a difference between "In" and "Out" peer connections? On bitcoin-qt, some peers are called "Out" and some are "In". Is there any difference besides who initiated the connection?

No, connection directionality doesn't affect peer behavior in Bitcoin P2P at all. The same rules for relaying inventory, and punishments for misbehavior apply to both. The software will avoid making outgoing connections to peers in close proximity in the IP address space to one another, but this does not apply to incoming connections where many connections from even the same IP address are allowed.


Is it possible for a decentralized currency to have untraceable transactions? I have been reading a bit about Bitcoin recently and am fascinated with the project and think it has great potential.

However, one thing I think it needs in order to gain mass popularity is to make it so if you give someone your address they can't just go and see all of your previous transactions.

I know in Bitcoin one is supposed to create a new key for every transaction, but not many people will be willing to do that. I don't think most people care about having complete anonymity for every transaction they make - but in the case of Bitcoin if you don't care about that then the person can see your entire transaction log.

Would there be a way to have both? I am no expert in Crypto (obviously) but could you perhaps have one address (say your email address) and every time you use it the system generates a new hash-address automatically and sends that. So then if someone just knew your email address that you give people to pay you they could not see the transactions you made because your hash-adress that is in the blockchain is not directly linked to it.

This likely will not work but I am wondering if anyone else has thought about this? I think it is what is needed.

Any comments would be awesome!

You are quite right that there are some drawbacks to reusing a bitcoin address, while at the same time it can be inconvenient to generate a new address each time.

I think you'll find its not possible to make an untraceable payment system where the money supply is limited. If money creation is controlled (as with bitcoin), nodes need a way to trace the money back to a valid origin.

As for the limitations of bitcoin, read on.

You might be interested in BIP 21 (Bitcoin Improvement Proposal 21), which is an official URI extension which bitcoin clients or wallets can use to make payments easier. Basically a seller can present a bitcoin URI (i.e. a link) to the buyer, and if the buyer's bitcoin client is compatible, the bitcoin client shows a payment screen saying e.g., "Would you like to send Bob 20 bitcoins?". What you should note is the seller can put any bitcoin address in the URI, meaning if most bitcoin clients + sellers supported this scheme, many transactions could easily use one-off bitcoin addresses, which helps achieve the privacy you're after.

Note there is still the problem that in can be tricky to send bitcoins to e.g. a friend, and that like you said, being able to 'discover' someones bitcoin address by using e.g. their email address would be handy. I have a side project Bitcoin Payment Service which attempts to solve that problem. Basically its an open-source web app that allows anyone to initiate a bitcoin payment to the web site's owner. You can check out a demo of BPS.


How does a node decide whether a block is valid? I'm a software developer, and I've been trying to figure out how a node decides whether a block is valid,
I do understand the hashes in bitcoin, the merkle root, and all those aspects
but my question is:

If someone edits a block, how does the network know that "X" node modified a block? are the nodes constantly in communication sending some sort of fingerprint that changes if information gets modified (or sending the whole blockchain)?

If a node (A) detects that Block #XHeight from Node (b) is not valid, how does the network know who is right and who is not, since The block is valid for Node B but not for node A, how do they solve such argument? does the network goes into an election process, and the network decides which hash is the valid one? : how does two nodes certify that one of them is actually the valid one? is there some sort of "democracy" system where nodes vote in favor or against one specific hash in order to decide who's right between node A and Node B?

I'd like to get technical answers, since I'm trying to understand blockchain and bitcoin at a code level.

Blocks cannot be modified because the next block contains a hash of the previous block's header. Any change to a block would result in a change to the header, and thus, change its hash, requiring all blocks which succeed it to also be modified because their hashes would no longer be valid. It isn't possible to rebuild all of the blocks because it requires work to compute valid hashes (they must have nBits leading zeroes in their merkle root).

Blocks are correct only if they are in the longest known chain with the most accumulated proof-of-work. Meaning any chain with less work than the longest known chain is invalid.

If a node sees a valid block X but then later, receives a new block Y, where YHeight > XHeight, and the chain of blocks up to #YHeight does not contain the block X, then X is discarded. Only the blocks in the longest chain are treated as valid blocks.

This is also true in a tie. If two blocks are mined by different miners at the same time, each participant assumes that the first block they received is the valid one, and they continue the Proof-of-Work process from this valid block. The next miner to create a valid block ends the tie by creating the longer chain, and any miner who was working on a block other than the one referred to in the new block's header will discard the work they have done so far on the shorter chain, and continue working on the longer chain.


Does electrum use static fees? I use electrum as a bit wallet and curious to find out if it's uses static or dynamic fees as I never set the option, and the fees seem to be 0.00001 B

The most recent versions of Electrum use dynamic fees. It has been like this for several versions, although for some versions you needed to enable it in your preferences. Check your preferences and see if there is a dynamic fees option. You can also just upgrade to using the latest version of Electrum.


Micro-payments definition and ideal platform Have developers come close to reaching a consensus on either:

The definition of micro payments?
Whether micro-payments ideally belong on the main chain or side chains?

I do not think there is anything to reach consensus on.

very small payments (in relation to the transaction fees)
they belong to neither (some developers will create a micro-payment solution on the main chain and other on side chains); both are viable and it depends on the application


Looking for a tiny go/golang snippet to connect to bitcoin core json rpc I've done it previously in C++ and I'm currently learning go/golang
I'd rather do it "from scratch" rather than trust a third party's library
Just a call from golang for a json-rpc call to getrpcinfo would be enough to get me moving!
My search so far has only led to entire libraries and applications

Ah... got there myself taking things from multiple sources!
Here's the code snippet:

package main

import (
    "fmt"
    "io/ioutil"
    "net/http"
    "strings"
)

func main() {
    testRequest := `{"jsonrpc": "1.0", "id":"", "method": "getrpcinfo", "params": []}`

    req, _ := http.NewRequest("POST", "http://127.0.0.1:8332/", strings.NewReader(testRequest))
    req.SetBasicAuth("", "notmypassword")
    req.Header.Add("content-type", "text/plain;")

    res, e := http.DefaultClient.Do(req)
    if e != nil {
        fmt.Println(e)
    } else {
        defer res.Body.Close()
        body, _ := ioutil.ReadAll(res.Body)
        fmt.Println(string(body))
    }
}


See the balance without load the transaction history Let's say I have a wallet.dat with several transactions, is there a way to see only my current balance without load all transactions in the wallet.dat?
I would like to achieve something like this because that would be lighter to load on my computer.

Sure, if you know the addresses of your wallet, you can look it up in a Bitcoin block explorer, and find the current balance of each address. There are also wallets, like Electrum, that will use third party nodes to track your balance, but cryptographically verify everything to ensure the third party node cannot lie to you.


How can vulnerabilites in bitcoin be responsibly reported? I am wondering if someone discovers a bug/exploit in Bitcoin software or protocol, who should it be disclosed to? Who is the authority? What would happen if the bug went public? Has it occurred in the past?

Information on current (ie, not past/public/resolved) security issues should be sent to the private bitcoin-security@lists.sourceforge.net mailing list.


Problem with data redundancy in block chain Since the copy of same data is storedon each node in network. Does it use storage space to store same data on each node?

If yes then how the data is decentralised. It is just a large network of centralised database.

Any help would be appreciated.

Since the copy of same data is stored on each node in network. Does it use storage space to store same data on each node?

Yes, but what matters is the validation of the data. Therefore you can use pruning to validate the block chain data without the storage overhead.

If yes then how the data is decentralised. It is just a large network of centralised database.

What can be called decentralisation in the case of Bitcoin is the ability of being able to retrieve the current state of the network without having to trust a central source of validation (/truth). This is accomplished through the validation of the block chain.


How to generate a payment request [BIP70] with specified fees I am working on an bitcoin payment system that generates invoices, because the invoice is time sensitive we like to control the fees our users pay as much as possible.

Is it possible to create a BIP70 payment request that specifies the fee the payee is expected to pay (either per output to be summed up, or in total for the transaction)? We can do our own validation, this question is just about the creation of the payment request (if the bip70 spec allows for the specifying of fees).

BIP 70 does not allow the merchant to specify the transaction fees to be used.


What is the difference between the bitcoind command line options "addnode" and "connect"? As seen here: https://en.bitcoin.it/wiki/Running_Bitcoin#Command-line_arguments

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

Both of those explanations seem to say the same thing to me.

Can anyone explain them in more detail?

addnode add a node to the list of nodes to connect.
connect only connect to THIS node.

For example, if you are currently connected to the nodes {A, B, C} and then issue…

addnode=D: you'll be connected to {A, B, C, D}
connect=D: you'll be connected to {D}


Do all of the records in the same block share the same hash? From what I have read, when a transaction is settled, the record is added to a block among with other records. The block is given a new hash as well as a hash from previous block.
So does that means that all the records in the same block share the same hash? Why isn't this significant at all?

There are transactions, and blocks. Both have their own unique identifiers, which are calculated as a hash of all the data in it.
When a transaction is included in a block, its hash (txid) doesn't change. It just becomes part of a block. That block also has a hash, which depends on the hash of the parent block, as well as on the hash of all transactions included in it.
So no, not all transactions share the same hash. Their hash is simply the hash of their data, and once created and signed, that hash cannot change without invalidating the signatures. Including it in a block doesn't change that.


Cgminer not working on windows with Nvidia graphics card When I try to start cgminer on windows it throws the following error:

Command:
cgminer –-scrypt -o http://netcodepool.org:8337 -u usernmae -p mypass –-thread-concurrency 8192 -I 10 -g 1 -w 256

:687: error: no matching overload found for arguments of type 'unsigned int  __attribute__((ext_vector_type(
        4))), unsigned int'
                        B[i+4] = EndianSwap(tmp[i]);
                                 ^~~~~~~~~~
        :700: error: no matching overload found for arguments of type 'unsigned in [2013-05-25 07:10:52] Failed to i
        nit GPU thread 0, disabling device 0
         [2013-05-25 07:10:52] Restarting the GPU from the menu will not fix this.
         [2013-05-25 07:10:52] Try restarting cgminer.
        Press enter to continue:

If you using a Nvidia card you should use cudaMiner since you will get better hash rates for it. https://bitcointalk.org/index.php?topic=167229.0


How can someone verify the signature of a Bitcoin ECDSA signature without knowing the signer's public key? I understand how ECDSA exactly works and for verification of a signature, the public key of the signer is required. But in Bitcoin, public key is double hashed and the only information the receiver knows is the sender's address.
Then my question is that how the receiver can verify the senders signature without knowing his public key?

Simple, the sender shows the pubkey when spending from whatever address the bitcoins are in. As part of the verification, the receiver (actually, every node in the network), can verify that the pubkey hashes to the address given and then and only then verifies the signature.


Get transaction that spent a transaction id The blockchain.info API allows for querying information about a particular Transaction by its ID. But if you want to follow the coins to the next transaction, I'm not seeing what the next query should be.

Each "out" of the transaction has an address associated with it, and you can query for details about a address' recent transactions. But if you're exploring deep in the past, the most recent 50 transactions for a given address won't have the spend for that particular "out".

So is there another API out there that allows you to query Transaction details based on "has transaction N as an 'in'"? Or do I need to go through the blockchain and make my own cache?

Edit: Blockchain.info clearly has the link to the transaction that spends a given output in their database, since the HTML view of a transaction now has "spent" tags after outputs that have been spent, which are links to the next transaction. However, that particular bit of data is not in the API view of the same transaction.

The raw transaction info includes the Unspent Transaction Out (UTXO) which is the link to each of the components of the spend:

http://blockchain.info/rawtx/$tx_index


Why hasn't my bitcoin transaction gone through? So about 3hrs from now I made a transaction to a different wallet of mine and the money didnt come through in 20mins I checked the blockchain and the number of confirmations kept rising and its up to 13, why is that? How long it can take?

You've sent Bitcoins like so:

WALLET1 ==> mixer ==> WALLET2

The problem here is that you can't be certain the middle part will work, be it for technical reasons, or more likely, they've been lost or "lost". By nature, mixers are run for clientele operating in the "very dark grey area". So it's extremely unlikely you've got any recourse, other than contacting their tech support. I'm sure you know all this.

Fundamentally, mixers in charge of your funds cannot be trusted. Theoretically, the only way I can see around this would be for a service to pre-mix the required amount, and then for you to withdraw it after you know it's safe, which would likely need to use BIP65 and/or BIP16, or perhaps a combination therein with message signing, to prove address ownership. I don't know there's any mixers like this, because quite frankly, I believe their profits come moreso from scamming or selectively scamming.

Because mixers are out, your options are either CoinJoin or DarkWallet, but I have not got experience with either of them.

This probably isn't the answer you're looking for, but unfortunately this is where it stands. Good luck.


How do on-line wallet or bitcoin exchanges usually secure their private keys? I suppose they're kept encrypted as not to do so would be the equivalent as saving plaintext passwords. I heard most of them keep a percentage of the funds in cold storage, but then isn't it inconvenient for the users in case a lot of them want to withdraw funds? how to manage those conflicting interests? Also how is the actual key being generated? where does the source of randomness come from?

To support timely settlement services outside an exchange's platform, around 1/12 to 1/16 value of an exchange's cryptocurrency value will probably need to be placed in hot storage. The rest will be in cold storage. Conceptually, fractional hot to cold storage ratios are analogous to fractional reserve banking and PBX trunk sizing.

The cybersecurity ante for the "state-of-the-practice" for exchanges and payment processors business as usual needs to be upped.  Don't even think about just a bunch of keys (JBOK) management. Hierarchical Deterministic (HD) technology is really the only viable approach to minimize key management complexity that can eat you alive. Insider threats will be one of the largest attack surfaces for exchanges. Employee background checks will be inadequate. Multisig support is critical to ensure internal separation of duties to prevent conflicts of interests.

For concise Dash examples about how to apply BIP 32/38/44 to altcoin key synthesis, and address generation (for both public and private extended keys) see answer URLs reference by BIP 38 Implementions for Altcoins?, in particular see this recent Wiki Posting.

Supporting multisig signature capability will be critical for minimizing the exposure of an exchange's cold and hot wallet assets. Suspect the libbitcoin multisig transaction composition interface will work for numerous altcoins, since I've tested it for BTC and TEST coins a few months back. However, still need to validate that bx multisig interface works with the newly supported altcoin "version" interface.  Extra validation work is required to ascertain which altcoins bx can successfully create version 1 text formatted multisignature transactions, and which altcoin network consensus mechanisms no kidding truly support multisig blockchain capabilities.

Multisig technologies alone do not prevent out-of-band multisig workflow spoofing attacks... ask BitP++. Suspect exchanges and payment services practicing "due diligence" and "due care" will eventually learn they must also deploy expensive to design/deploy/sustain controlled interface CDS technologies.


bitcoin-cli very slow to respond to RPC calls (Raspberry Pi) Running Bitcoin 0.11 on Raspberry Pi 2 (Quad core 900MHz 1GB RAM, 128GB Flash Drive for blockchain, 8GB SD Card for OS and software).

Blockchain is fully synced, 13 connections.
In htop, I see I'm around 700/862MB RAM, 1/99MB Swap. 1 processor is up around 90% but the other 3 are down in the <5% range.

I SSH into the pi (running bitcoind, no GUI) and some commands take forever to get a response. Sometimes getinfo or getpeerinfo will take 30-60 seconds to print out. gettxoutsetinfo takes way longer: almost ten minutes!! I don't see any resources being maxed out in htop during this time.

I know this is a low-power machine, maybe the UTXO set hash in the gettxoutsetingo command is what's specifically taking so long in that case.

Can I adjust any settings either in the RPi OS or bitcoin.conf to get snappier performance? Ideally I would like to run a few python scripts that use RPC, triggered by bitcoin's blocknotify=...

I have the same set up and getinfo for me takes about 10-20s initially but then takes ~5s there after. (I need to restart the daemon periodically as it crashes for some reason). I'm running 0.11.1 and haven't made any special tweaks. gettxoutsetinfo takes around 12 minutes. CPU, RAM and Swap comparable with what you have as well.

Hardware is probably the most obvious limitation. You could overclock the Pi CPU but I doubt it will drastically reduce the response time though.


Is there any way to revoke or update private key? Suppose my private key corresponding to an address is stolen.
Is there any way to revoke private key or update the private key?

Generate a new private key, calculate its public key, derive an address from the pubKeyScript and forward your funds protected with your old,  compromised private key to the new address protected by your new private key.

--

Simplified:

Send your funds to a new address generated in a secure environment (HWW, cold storage, etc.)


How are malicious forks resolved? I understand that forks are resolved by opting in for the eventual longest chain, preferring the chain with the longest POW. But everything I read on this suggests it's just random chance or that the next block is really "alone" on some nodes due to delays in propagating, so "tough luck".
But let's imagine the scenario where a miner changes the last block with incorrect information for his own benefit, creating block A which should be rejected by the network. Another miner creates block B with the correct data.
We now have a fork, with block A and B being at the end of the chain.
The next miner needs to choose one of the blocks, hopefully not validating the bad intentions of the first miner. How does this gets resolved, how does block A get proven wrong?

It's valid but it's a miner writing wrong data, e.g. changing a transaction address to his own or changing a 3 btc transaction to 30 (while the wallet holds 50). The hashes are correct but the miner is using his position as miner to benefit himself or others

Miners can't change that data in a transaction because that data is secured by the transaction-author's digital signature. Any change in the data will cause a signature check to fail.
Nobody cares about other people's balances, no one ever needs to know another person's balance. Bitcoin keeps track of coins not balances. In this case a coin means an unspent transaction output (UTXO). These UTXOs can only be spent by someone who knows the secret number (private-key) that can be used in a mathematical proof of right to spend.


Is an unencrypted wallet secure if bitcoind is not accepting RPC calls? I'm interested in setting up a P2Pool node (which requires running bitcoind) to run a little mining pool for myself. Before you ask, nope I'm not even trying to break even, I know I'll lose money on this. Just want to play around and get a feel for how these things work.

My question is: I hear over and over again that it's important to take security precautions with bitcoind and wallets, but I've had trouble teasing out exactly what those security precautions are. If I have bitcoind not accepting RPC calls (as is the default), is there any danger to using the out-of-the-box unencrypted wallet?

If the information helps, I'll probably run the node in EC2, and have a cron job that frequently transfers any bitcoins earned through mining into an account in an exchange so I can play around with that side of things as well (so I'm not worried about large sums of bitcoin building up in my bitcoind wallet).

Turning off RPC will prevent that particular attack vector, but if the coins are on a machine connected to the internet, that's a lot of vulnerabilities and attack vectors to consider.

That said, if you're running a node on EC2, you're not going to generate enough bitcoins to be worth stealing. If the point is to figure out how everything works, I wouldn't worry about the bitcoins you'll be mining since it'll be so little (at most $10 per year).


What can be changed in signed bitcoin transaction? What can be changed in signed bitcoin transaction?
I mean how is possible to modify transaction to change its hash, but keep transaction valid, without need to have sign private keys?

Here is the list of known sources of malleability from BIP62 (which has been withdrawn, and is no longer up to date, but does give some insight):

DER encoded ECDSA signatures Right now, the Bitcoin reference client uses OpenSSL to validate signatures. As OpenSSL accepts more than serializations that strictly adhere to the DER standard, this is a source of malleability. Since v0.8.0, non-DER signatures are no longer relayed already.
Non-push operations in scriptSig Any sequence of script operations in scriptSig that results in the intended data pushes, but is not just a push of that data, results in an alternative transaction with the same validity.
Push operations in scriptSig of non-standard size type The Bitcoin scripting language has several push operators (OP_0, single-byte pushes, data pushes of up to 75 bytes, OP_PUSHDATA1, OP_PUSHDATA2, OP_PUSHDATA4). As the later ones have the same result as the former ones, they result in additional possibilities.
Zero-padded number pushes In cases where scriptPubKey opcodes use inputs that are interpreted as numbers, they can be zero padded.
Inherent ECDSA signature malleability ECDSA signatures themselves are already malleable: taking the negative of the number S inside (modulo the curve order) does not invalidate it.
Superfluous scriptSig operations Adding extra data pushes at the start of scripts, which are not consumed by the corresponding scriptPubKey, is also a source of malleability.
Inputs ignored by scripts If a scriptPubKey starts with an OP_DROP, for example, the last data push of the corresponding scriptSig will always be ignored.
Sighash flags based masking Sighash flags can be used to ignore certain parts of a script when signing.

(1) has been fixed for all transactions by BIP66, and (2)-(6) are prevented by standardness rules in recent Bitcoin Core releases. A specific case of (7) is proposed to be fixed by BIP147.

Segregated Witness (BIP141) proposes fix all of them, but only for transactions that spend  solely from segwit outputs. It does this by moving the scriptSig data to a new field (the witness) which does not influence the txid.


Is a bitcoin address collision possible if generating 90 million addresses every 4 hours? I am running a test to see if I can obtain a successful bitcoin address collision after generating billions of addresses. I am not entirely sure how I would check them yet. Basically I have an extra 10TB hard drive and am running supervanitygen on my 32-core, 128gb ram linux work computer. It seems to be generating about 90,000,000 (90 million) addresses (address + private key pair) every 4 hours.

Do you think it's possible or likely to run into an address collision this way? Or perhaps if everyone in the world did the same thing? Or what if I waited 10-20 years, and then checked the addresses?

This is all just a test to see if the bitcoin system is secure enough for big investment decision.

Because of the Birthday paradox, you only need 280 addresses (despite there existing 2160 different address combinations) before a collision becomes probable.

Thankfully, that is still an enormous number. At 90 million addresses per 4 hours, it will take about 445 times the age of the universe to reach that number.

It's also irrelevant. Even if anyone - or everyone - generates 90 million addresses per 4 hours, there aren't that many addresses receiving funds. Thus only actually used addresses matter.


Does OP_EQUALVERIFY have a return value? The Bitcoin wiki has a page that summarizes OP_EQUAL and OP_EQUALVERIFY:

OP_EQUAL

Opcode (Hex): 135 (0x87)
Input: x1 x2
Output: True / false
Summary: Returns 1 if the inputs are exactly equal, 0 otherwise.

OP_EQUALVERIFY

Opcode (Hex): 136 (0x88)
Input: x1 x2
Output: True / false
Summary: Same as OP_EQUAL, but runs OP_VERIFY afterward.

OP_EQUALVERIFY is listed as having a return code, when it doesn't seem like it should. (OP_EQUAL OP_VERIFY wouldn't leave anything on the stack.)

If the execution of OP_EQUAL gives true, then it does not leave true/false on the stack. If it is false then it leaves false on top of the stack and stops executing.

Bstack.push_back(fEqual ? vchTrue : vchFalse);
if (opcode == OP_EQUALVERIFY)
{
if (fEqual)
    popstack(stack);
else
    return set_error(serror, SCRIPT_ERR_EQUALVERIFY);
}

Source


As the number of Public keys available in BlockChain increases, does it cause extra risks for private key's security? Any bitcoin address eventually use its public key when spending its BTC. And as we all know, bitcoin address is produced from a public key by utilizing one way function. What is advantage of using bitcoin address ?
Does it make any address anonymous till spending BTCs ?
While the block-chain size increases over the time, there are lots of public keys available, and some fraudulent person maybe try to estimate private key by enabling brute-force method.
Does it make any disadvantage or cause extra risks the whole system ?

Any bitcoin address eventually use its public key when spending its BTC. And as we all know, bitcoin address is produced from a public key by utilizing one way function. What is advantage of using bitcoin address ?

A bitcoin address is not technically broadcast and included in the blockchain database until it is funded. So spending is irrellevant, because it would become public the moment it is funded.

Simply put, it's not "live" until it is funded. It's just a place card, if you have the private key, any funds sent to that account can be later spent, and upon funding, it would be public, regardless of whether there have been outbound transaction.

Does it make any address anonymous till spending BTCs ?

Spending, or Receiving, broadcasts the address with any transaction made through nodes, which confirm the transaction as valid and not duplicate. For each block that is found where the transaction you made is included, given you have included a fee which the nodes accept as "fair", is called a confirmation.

While the block-chain size increases over the time, there are lots of public keys available, and some fraudulent person maybe try to estimate private key by enabling brute-force method. Does it make any disadvantage or cause extra risks the whole system ?

No. There is no way, currently, for anyone to brute-force an address's private key. There are statistics and charts, but if you used the worlds fastest super computer, you would need millions, millions of years. It simply, is not feasible. Quantum computing could change that, but the reality is, quantum computing is not even yet in its infancy. (Not that we know of). It is way off in the distance, if ever.

That said. The reason cracking a private key from a public key is "impossible", is this:

Think of your Private Key as the Question.

Your Public Key, is the Answer.

It is not the other way around.

So if your public key is 100 (Shortened for this example) you know the answer. That is public.

To crack, you need to now figure out the question.

Is the question What is 10x10?  Or 1x100? Or 101-1?

Simply, there are far too many possibilities, in terms of questions, to any "answer". Cracking, brute-force, I don't think so.


0.00603581 is in my bit coin wallet how much do I own? If I have 0.00603581 in my bitcoin wallet who much do I accually own ?

You own every bit of it. Assuming you have the private key for the wallet. As far as the blockchain network is concerned, anyone with the private key is the "owner" and will transfer those funds if the correct private key is provided in the transaction request.

As long as your private key remains private and you know what it is, you own it.

Now, to send that Bitcoin somewhere else, you'll have to pay a fee. That's why miners mine the blocks. So while you (assuming above conditions are satisfied) "own" every Satoshi inside that wallet, you'll need to pay to move it somewhere else.

Note: Nuances, subjective considerations and opinions have all been crushed for the sake of brevity.


How to get all potential routes in c-lightning? I'm trying to write some services on top of c-lightning and I need to check if certain payments hit certain nodes.

  lightning-cli getroute nodeid amount riskfactor

This gives me a randomly selected single route out of potential two routes.

Is it possible for me to get all potential routes and decide for myself?

if you invest some programming time you can use the listchannels command to retrieve all channels of the lightning network from the gossip store. No you could store them in the networkx lib

import networkx as nx
network = ln.listchannels()
nx.Graph()
for channel in network:
    G.add_edge(channel["source"],
               channel["destination"],
               **channel)

and then you could use this algorithm from the networkx library to get a generator for all paths between a source and a destination rout. Since the lightning network will most likely have cycles you need to define a cutoff. While 20 is to long from a computational point of view it is also the the maximum path length an onion packet supports according to BOLT 04.

  Length: the maximum route length is limited to 20 hops.


Where is the default lnddir? Looking for my macaroon files which should be at this location:

lnddir/data/chain/bitcoin/mainnet

However, I can't figure out where my default lnddir location is. I don't want to set a new lnddir. I'm working on macOS, however information for all major operation systems should be included.

For macOS: /Users/arshbot/Library/Application\ Support/Lnd/