text:
Is it possible that bitcoin community along with core developers introduce new bitcoins into the system for the good cause?
I want to create a imaginary scenario here to clarify my question.
Let's say, a bitcoin community is thriving at Cuba. Somehow few thousand Cubians manage to relocate at the remote location at Cuba and name the place Cubian bitcoin community city. The only mode of payment is bitcoin, so basically it's a bitcoin community city at Cuba that manage itself without help from Country Government.
Mr Smith from America sees tremendous opportunity to invest on Cubian bitcoin community city and also want to help since government doesn't care much. Mr Smith invested 1000 BTC to build Hospital on Cuban bitcoin community city.
After few months local Country Government raided the Cuban bitcoin community city and destroyed the hospital. Mr Smith loss all his investment.
So my question is in order to encourage investment on high risk countries like Cuba, can bitcoin community along with core developers upon collaboration and investigation generate new bitcoins and give it back to Mr Smith to recover his loss?

How exactly was this money "destroyed"?  That doesn't make sense.

Maybe he means the keys are destroyed/stolen/lost?

I'm saying lost of BTC in the form of investment.
Let say you both invest 20 BTC on Food store. If the food store is destroyed by the government, you will loose your 20 BTC  indirectly since you invested on Food store.

This would require a hard fork.  It would be technically possible if there was community consensus that it was a good idea, but it would probably lead to a loss of confidence in the currency and economic disaster.  As such it is very unlikely that the community would agree to do it.

@sanz, that is simply the case where an investment has gone bad.  When money was paid for the hospital, it didn't disappear.  Real estate developers were paid for the land, architects were paid for the design, suppliers were paid for the materials, and builders were paid for the construction.  A hard fork could nullify those transactions, but don't these people deserve their money?  If they keep their money and a hard fork reimburses the investor, the money supply becomes inflated...which decreases the value of everyone else's bitcoin.  There's no fair way to do what you are asking.

The reward schedule and therefore the amount of bitcoins in circulation are central rules of the Bitcoin system. Changing the rules to create additional bitcoins would be incompatible with the protocol and in contradiction to the social contract the Bitcoin community formed around. Breaching this social contract that is central to Bitcoin would destroy confidence in Bitcoin's value.
So, while it would be technically possible that more bitcoins are created, I am sure that the idea to change the protocol to bail out business ventures would not gain the overwhelming support necessary to implement it. It seems more likely that investors would use contracts or insurances that work on top of Bitcoin to hedge against the risk.

The banks are creating new digital currency on daily basis. In past government has bailed out banks by printing cash. I've yet to witness loss of confidence in US dollar. There are obvious speculations about it that public will loose confidence in it but right now there is no sign of it.
If government can bail out banks in dire situation like financial meltdown, I don't see any problem of generating new Bitcoin to repay back respective Bitcoin investors to cover for their losses due to government attack on Bitcoin community like above imaginary scenario in Cuba . I believe it will create more confidence in the Bitcoin users knowing that whole community is backing and supporting it. It'll truly empower community, a sense of revolution. If repaying is not an option than Bitcoin community has to find some ways to encourage investors to invest in under developed and high risk countries like Cuba.
I want to emphasis on why this Bitcoin investment  is extremely important and powerful concept? Let's say for a while there is a Bitcoin protocol that repay back loss amount to Bitcoin investors or even better remedy system for the ridiculous act by the government to suppress the hopeful and lively self managed Bitcoin community at underdeveloped countries. I along with many Cubans and under developed countries would do the possible following things to take the matter at our own hands and try to change our lives. One could argue about each points for months but let's not focus on that. What I'm trying to highlight is at least there will be hope for change.

Seize and take control of remote government land to start new Bitcoin community along with 4000 to 10000 people for start. Make sized land free to community.
Install the Internet.
Make Bitcoin only accpted currency.
Immediately ask for the investment from the Bitcoin community. Could get help from respected Bitcoin core representative to approve the community. This is crucial point. Without investment, forming a new community is impossible.
At the beginning, community will decided on what to build.
Move 4000 to 10000 people the the location.
Later, develop the software where the invested money is only invested where the community wants through voting without the need for the central decision authority.
Install the community owned Bitcoin mining machine. Profit generated by these machines will be paid to investors.
Develop some sort of agreement or protocol with the newly formed community to repay the invested amount by the generous Bitcoin Community.

Even if this newly formed city is destroyed by the government, investors don't have to worry about the loss since the hypothetical Bitcoin protocol will recover their losses. Community will rise again at new place followed by new investment.
Bitcoin still hasn't yet changed the lives of billions people around the world. I sometimes wounder how it's revolutionary. It has potential to be powerful beyond imagination. If money is source of power for all government than for the first time we have tool at our disposable to fight government money with money and yet it is limited by it's protocol. If technology doesn't enslave us than it's of no use.

To do this, what you need is investors, not radically undermining the properties of the currency. Developers are not the central bank to judge your projects.


text:
bitcoind not using correct directory inspite of datadir argument
I configured a non-pruned bitcoin full node on a RaspberryPi 3 using this tutorial - http://raspnode.com/diyBitcoin.html
I am using a 1TB external HDD to store the blockchain. I synced the full blockchain on my laptop and transferred it to this external HDD.
I am able to mount this external HDD as per the instructions in the above tutorial under the folder ~/bitcoinData and have also setup the automount.
However, even when I run bitcoind using the arguments bitcoind -datadir=/home/pi/bitcoinData -daemon, it still is using the default ~/.bitcoin (on the RPi SD Card) to download the blockchain from scratch even though the full blockchain is available in the mounted drive.
I tried to mount bind the two directories in /etc/fstab/ using /home/pi/bitcoinData    /home/pi/.bitcoin       none    bind    0       0
but still the same issue occurs. Any idea why bitcoind is not using the mounted drive to download the blockchain inspite of the argument datadir=/home/pi/bitcoinData?

The mount command is unclear, perhaps paste your fstab. Normally you mount a device (/dev/sda1) under a directory... Then: is bitcoin.conf in ~/.bitcoin? (and not in ~/bitcoinData). Did you try to give the parameter to bitcoind ("-datadir=/home/pi/bitcoinData")?

That tutorial sucks.
Better seek generic instructions on how to mount external HDD to user's home directory.
Say you're Joe, you'd use sudo to add a user called bitcoin.
Then mount /dev/hda1 (or whatever it is) to /home/bitcoin, configure /etc/fstab, reboot, log in as Joe and make sure it works (df).
Then login as bitcoin user, make sure you're in /home/bitcoin (where you should be), download (or just install) Bitcoin Core, and start it. You don't need any config files (but you can add rpcusername and rpcpassword), as by default everything will be stored under /home/bitcoin/.bitcoin/.
Joe now can use a wallet that connects to Bitcoin Core (executed by bitcoin user).

source: Stack Exchange

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

sort: votes


text:
where can I buy a whole bitcoin?
I want to buy a full bitcoin at the current price. But coinbase only allows me to buy in $250 increments. Where can I go to purchase an entire bitcoin?
I would go to Localbitcoins.com but their fees are usually too high.
So what I need is a low fee way of buying an entire bitcoin.
Thanks

If you are in the US, you can buy it on coinbase.com or https://exchange.gemini.com/
You need to buy some Bitcoins on coinbase, they will automatically increase your limit. I can buy $5000 worth of Bitcoins on Coinbase, and would if I had the money.
Fees of Gemini are low, ie .05 cents for $20 in BTC, or 50 cents for a $200 order.
Or localbitcoins, if you care about anonymity, but they charge a high markup.

Try http://localbitcoins.com.
From the website:

Buy and sell bitcoins near you
  Instant. Secure. Private.
  Trade bitcoins in 14431 cities and 248 countries including United States.

It does appear to require an account to be made, but it appears to be free.

Yeah I have. However their fees are usually too high. What I want is a low cost way of achieving this. I've edited the question to reflect that. Thanks

Yeah it's free. But if you notice the selling price for bitcoin by the sellers on that site is usually a lot higher than the regular price for BTC that you see on somewhere like coinbase. That's why I shy away from it. The markup from the sellers of bitcoin on this site is just too high usually. Still continuing to search. Thanks tho.

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


text:
Bitcoin transaction stuck for more than a week
This transaction is stuck for more than a week, it keep saying in electrum that it is unconfirmed:
https://blockchain.info/tx/622caee53701359b90df448163fcf36f36a5354ada7c01b5f7c1b8f7851080ee
It disappeared from blockchain and other block explorer and it came back with a new date yesterday and today.
I am patient, but seeing that the dates were refreshed is kind of weird.
RBF was not enabled when I sent, and I've put max fees available in my wallet, which is 1 mBTC/KB and it is not enough.
Any idea what I can do?
I tried everything listed here:
Why is my transaction not getting confirmed and what can I do about it?
And nothing can work in my situation.

I used all possible tricks, including deleting the transaction offline in my wallet in the JSON file and trying to manually send it with more fees while offline.


text:
How to convert Satoshi to BTC in Java?
I get the value of money in Satoshi and I would like to have it in BTC. I develop the app in Java/Maven/JSP and use BitcoinJ for the framework. I use the code,
    public Coin getBalance() {

        int fac = (int) Math.pow(10, 8);
        return balance.div(fac);
    }

In the JSP, I use,
<%
    DecimalFormat decimalFormat = new DecimalFormat("#0.00");
%>
<div class="fild_value">
                    <%= decimalFormat.format(model.getBalance().getValue()) %>  BTC
</div>

In this way, I miss the value after the decimal. For example, I get 1.00 BTC when I suppose to get 1.68 BTC. How to convert Satoshi to BTC in Java properly?

value times 100million ?

The balance provides the value in satoshi and the mentioned code in the getBalance method converts it to the BTC. [1 BTC =  10^8 Satoshi]. Now, after converting in the fashion, I was not getting the value after the decimal. How to get the value properly?

Note: int/int = int, so 4/3 =1. I am not aware of the specifics of your problem, but the solution must to convert either the balance in satoshi or fac(10^8) to float and use it for division.

Tried the way suggested and doesn't work for me.

The Coin.valueOf(long) static constructor takes Satoshis as an input. You can use one of the toString/toFriendlyString/toPlainString methods to derive a human readable value string.


text:
blockChainDownloadLocked ignoring the duplicate request error
I work with a bitcoin wallet app using the Java/BitcoinJ. The app has custom features such as showing balance, transactions, address and sending option. It was running fine and suddenly, I get the blockChainDownloadLocked ignoring the duplicate request error in the app.
org.bitcoinj.core.Peer: 06/19/2017 16:26:28 - blockChainDownloadLocked(00000000b873e79784647a6c82962c70d228557d24a747ea4d1b8bbe878e1206): ignoring duplicated request: 00000000076d710f40120e2f6693371bf6a7c4a9d149fb665664272a91dccf5a
org.bitcoinj.core.Peer: 06/19/2017 16:26:28 - java.lang.Throwable
    at org.bitcoinj.core.Peer.blockChainDownloadLocked(Peer.java:1446)
    at org.bitcoinj.core.Peer.processInv(Peer.java:1247)
    at org.bitcoinj.core.Peer.processMessage(Peer.java:489)
    at org.bitcoinj.core.PeerSocketHandler.receiveBytes(PeerSocketHandler.java:182)
    at org.bitcoinj.net.BlockingClient.runReadLoop(BlockingClient.java:122)
    at org.bitcoinj.net.BlockingClient$1.run(BlockingClient.java:81)

I use IntellIJ and cleared the Cache (Invalidate Cache/ Restart ...) and deleted the target folder to resolve it. It didn't help. Later, on enter in the Cache folder in the Mac OS and deleted everything inside all the folders.
I think rolling back the entire blockchain would be a solution, but, open for better suggestions.
What's the issue here and how to solve?

Are you using PeerGroup or just one Peer? If just one Peer, is it your own node?

How do I suppose to know that?

I assume its PeerGroup

If you're using PeerGroup then it connects to multiple peers simultaneously and will switch to another download peer if one is stuck downloading. I've seen the above problem too but usually it simply recovers by switching peers.
btw. You should know the code you're using.

Its repeating again and again for me. I can connect with main net btw. How to solve this issue?


text:
How many letter tiles does one need to build any 24 word mnemonic?
One of the popular cold storage wallets provides double-sided tiles for users to put in the first four letters of each of their 24 words (96 characters total).
They include ~245 double sided tiles, plus some blanks.
By my math on the BIP39 wordlist, they should need to provide ~485 double sided tiles to provide for every valid 24 word mnemonic.
I simply calculated, for each letter, the worst case 24 word combination, then added up how many of each letter I would need, then divided by 2 since the tiles are double sided.
Is there something I'm missing here?
Thanks!
EDIT  I have found at least one flaw in my reasoning. The last word is a checksum, so not entirely random. But accounting for this only saves us 33 letter tiles!

Perhaps you'd like to explain how you calculated the "worst case" combination - it would be easier to check your calculation than to try and redo it.  There may also be an issue with double sided tiles, since not all combinations can be used together.

But for practical purposes, you don't need to be able to handle all possible mnemonics, so long as you can handle a pretty large percentage (say 99.99%).  I would bet the 245 provided tiles can do that.  If you are unlucky and get one that doesn't work, you can have your wallet generate a different one and send all your coins there.

Worst case combo was calculated by, with the letter A for example, finding the 24 words in the list with the most As in the first four letters (since one only needs to store the first four letters). There are 37 words with 2 As in the first four letters, and none with 3 As, so the worst case for A is 48 As in a seed.

Cutting off the long tails by only providing for some large majority is interesting, but I can't help but think that there is something more I'm missing.

No, I think your logic is fine.  It's clear that 245 tiles can't account for all possible mnemonics.

I have found at least one flaw in my reasoning. The last word is a checksum, so not entirely random. But accounting for this only saves us 33 letter tiles!
(also added as an edit to original post)

Actually the answer is rather simple, Cryptosteel did a letter frequency analysis on the bip39 wordlist and found that you can represent any word in the list using only 4 characters. Therefore, for a 24 word recovery phrase, you take 4x24 or 96 characters.
Edit: Oh oops, I thought the question was that ability to store all combinations instead of the tiles provided. to which my answer is, they probably ran an analysis and decided on that number of tiles based on their data. If it bothers you, you can just use a cold wallet that includes more tiles like simbit that includes 400.

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


text:
How Master seed is generated using Bitcore API?
Can someone please explain how to get Master Seed when a new HD keys is created using Bitcore APIs?
My purpose is to implement wallet service in my application using Bitcore APIs.
Refer this link here

Please elaborate your question. Are you asking to derive HD private keys from a newly generated public key or address? If so, it is not possible. Which specific function in Bitcore API you are referring to?

Hi Abhishek, no. I want to implement HD wallets into my application. According to my understanding there must be a master seed for each new wallet. Each wallet is simply a pair of HD private and public key, right? And we can create more public keys(addresses) using HD private key. My question is how will I get this master seed at first place?

Are you talking about 12 or 24 words mnemonic seed or recovery phrase?

I would really appreciate if you could also mention the difference between them in your answer. I want to give my users master seeds for their wallets so that in future if they lose their wallets they can recover using the master seed they possess.

Give them the mnemonics. That's enough. They can recover their funds in any standard wallet if they have the mnemonics that represent the correct private keys of their wallet.

In case you are talking about mnemonic seed use this -
Install bitcore-mnemonic
npm install bitcore-mnemonic
bower install bitcore-mnemonic

Then use it to generate mnemonic seed -
var Mnemonic = require('bitcore-mnemonic');
var code = new Mnemonic(Mnemonic.Words.ENGLISH);
code.toString();
// army van defense carry jealous true garbage claim echo media make crunch...

var xpriv = code.toHDPrivateKey();

If you just want to generate a private from bitcore api you can use this function -
var bitcore = require('bitcore');
var HDPrivateKey = bitcore.HDPrivateKey;

Please note there is no rule to generate a private key. A private key is just a random string. It could even be your name or a whole article. But you must create a private key that is 'random' in nature. Also never use programming language functions like md5 hash or something to generate a private key because they are not truly random.
Bitcore api, however, provides an easy way to generate a private key using the above method. From there you can proceed as usual.
var bitcore = require('bitcore');
var HDPrivateKey = bitcore.HDPrivateKey;

var hdPrivateKey = new HDPrivateKey();
var retrieved = new HDPrivateKey('xpriv...');
var derived = hdPrivateKey.derive("m/0'");
var derivedByNumber = hdPrivateKey.derive(1).derive(2, true);
var derivedByArgument = hdPrivateKey.derive("m/1/2'");
assert(derivedByNumber.xprivkey === derivedByArgument.xprivkey);

var address = derived.privateKey.toAddress();

// obtain HDPublicKey
var hdPublicKey = hdPrivateKey.hdPublicKey;

Hi Abhishek, thanks for your answer. Can you please also confirm if mnemonic seed is used at the time of recovering wallets when lost?

Yes, you can easily use mnemonics, in fact, in any standard wallet like trezor to recover back your funds. Mnemonics are actually created from private keys itself. You can learn about the process here - https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch05.asciidoc
When you use
var code = new Mnemonic(Mnemonic.Words.ENGLISH);
bitcore api selects the private key for you and generates the mnemonics from it doing all the hard work for you. So you can think these mnemonics represents your private keys and you can use them to recover your funds.

Glad to help you.  If my answer meets your requirement please mark it as the accepted answer. Thanks

Done! Abhishek, I have a quick question for you. Mnemonic Seed will be created after a new wallet is created. Is that right? And if so, does it mean the created mnemonic seed will represent this wallet? Or do I need to do something to link the seed with my wallet??

Because as per my research so far, mnemonic is generated from a random string. So I'm confused how it will represent my wallet.

See the xpriv variable in the above code. It holds a HD private key. From this private key create public keys and addresses. Use only these addresses to transfer funds. So you need to 1. Generate mneomincs 2. Get your private keys from it as shown above. Then once you have HD private keys, generate addresses and HD public keys using the functions scripted in the answer.

Let us continue this discussion in chat.

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


text:
Transactions in Sidechain
Suppose I have my own sidechain and have created a transaction of 100 BTCs from Bitcoin network to my Sidechain. To my understanding, this means 100 BTCs are now locked on Bitcoin Network and 100 pegged BTCs have been created in my sidechain.
Q1. What kind of address will hold these 100 pegged BTCs in my sidechain? Is it an address same as Bitocin wallet address?
Q2. Suppose Alice have 100 pegged BTCs in address A of sidechain, Alice made a transaction of 50 pegged BTCs to Bob which has another address (say address B). We now have 50 pegged BTCs in both address A and address B. How will Bob redeem pegged coins back to real BTCs in Bitcoin Network? Because if we see in Bitcoin's point of view, Alice is the authorized user to spend or redeem her 100 pegged BTCs back to real ones. Whereas Bob does not exist for Bitcoin Network who claims to possess 50 BTCs.

Welcome to Bitcoin.SE! A doozy of a question - I don't think you can do it.

@Willtech You mean transactions are not possible in sidechains?

Hmm make sense. Then what use case sidechains have? What benefits does it brings when pegged to bitcoin network?

because you can build a whole new set of rules for transactions on sidechains. There you can create new logic, which is difficult to implement in bitcoin network, or doesn't need its high level of reputation/security/stability/availability... e.g. buy a coffee for very little tx fees. Or create smart contracts, that extend to the layer of OP-Codes. Or do whatever business logic you can think of. At one point in time the sidechain must make sure, that the right amount of bitcoins (a transaction) comes back to the bitcoin network. Otherwise bitcoin network will reject invalid tx.

See here: https://bitcoin.stackexchange.com/questions/37876/what-is-fed-peg-and-predefined-functionaries-with-sidechains/37885#37885

@pebwindkraft As you said, "the right amount of bitcoins must comes back to the bitcoin network.". Is it necessary to use the same address by which bitcoins first traveled to sidechains at first place? Like Willtech said, Bob can't do this transaction to bitcoin network, and only Alice can do that.

@Willtech forks are not sidechains

@Willtech As per my understanding, all forks are not sidechains but all sidechains are forks. Right?

@OsiasJota can you please verify the above statement?

No sidechains are forks, nor sofware forks, neither chain forks.

Read about the basic definition of sidechains

@user16961 It seems that I was not correct and there are in fact experimental sidechains already running on Etherium. I will do some more reading and remove a couple of my comments to avoid confusion.

Sidechain is a blockchain that runs in parallel to the main blockchain which extends functionality through interoperable blockchain networks allowing a decentralized way of transferring/synchronizing your tokens between the two chains. pegged sidechains whitepaper

Also, see the excellent Q/A and article linked in the post linked above by @pebwindkraft - note that I have not yet read that the coins can be moved back onto the Bitcoin mainchain.

Q1: It depends on the sidechain. Every sidechain can implement their own rule to create and represent/encode adresses.
Q2: This is an active area of research. Some people propose implementing sidechains via Zero-Knowledge proofs or other ideas that either require Bitcoin rules to change or mining cooperation or both. Some sidechains already deployed, like RKS, propose there are a set of nodes you trust to hold custody of bitcoins transferred to the sidechain, much like a bank.


text:
The BTC shows 10^8 times more than what is received in the account
I work with Java/Maven/JSP app with BitcoinJ and I have transfer about 0.0048 BTC from a testnet faucet. However, after receiving, I see that my account has balance of 480000.00  BTC.

This is the method I have used to get the Satoshi Coin.
public Coin getBalance() {
        return balance;
    }

I have checked the code and at least my backend part looks normal to me. How to approach to this problem?

Apparently the app shows the amount as Satoshi (the smallest unit) instead of BTC. For internal calculations that's ok because it avoids rounding errors, but for input and output you should scale by an appropriate factor (10^8 for BTC, or 10^5 for mBTC).

Yes, and in bitcoinj there are actually two classes for formatting Coin values for humans: MonetaryFormat and BtcFormat. I strongly suggest using one of the two.
Here's an example:
Wallet wallet = <initialize wallet here>
String friendlyFormat = BtcFormat.getInstance().format(wallet.getBalance());

How to convert Satoshies to BTC in Java?

What does the wallet.getBalance() returns? I have tried with several ways and none actually works for me. The method I use to get the Satoshi Coin is
public Coin getBalance() {         return balance;     }
How can I get the correct value in BTC? I have also tried with balance.leftShift(8)


text:
transacton fees for raw transactions
I'm building a merchant system for a client that will accept payments in bitcoin and send all coins to a cold storage wallet once a week (or month). The system is using a deterministic wallet to create one wallet for each client and it is very unlikely that one "receiving" wallet will have more than 2 inputs.
This system will run on a vps and the client does not want a bitcoin client running so I will create and relay all transactions through Push TX at blockr.io
This should work fine, but I'm having some problems with the size of the transaction and the transaction fee.

According to this answer if the value I'm trying to send is bigger than 1BTC I don't need a fee

A fee may not be required at all, if the priority of the transaction is high enough. Generally 1 BTC, one day old, is enough age and balance that you can send without a fee.
If any of the individual payments are below 0.01 BTC, a minimum fee will always be required.
The minimum fee, when required, is 0.0005 BTC per 1000 bytes of total transaction.
The contribution of each input and each output to the total size is somewhat consistent, it only varies largely if there are compressed keys (standard for newly generated addresses on a recent client version)

According to this answer the value will increase a lot based on the size of transaction

0.01 BTC fee per kilobyte of transaction, but: If the blocksize (size of all transactions currently waiting to be included in a block) is less than 27 kB, transactions are free. If the blocksize is more than 250 kB, transactions get increasingly more expensive as the blocksize approaches the limit of 500 kB. Sending a transaction when the blocksize is 400 kB will cost 5 times the normal amount; sending when it's 499 kB will cost 500x, etc.

According to bitcoinfees.21.co I should use their api to get the best transaction fee dynamically
{ "fastestFee": 40, "halfHourFee": 20, "hourFee": 10 }

So my questions here are:

What is the best way to calculate the transaction fee? Given that I will be doing calculations by hand (script) and not using a bitcoin client
What is the maximum number of inputs that can I send on a transaction?
What can I do if the transaction gets stuck because of small transaction fee?

1 and 2 are from very old answers which do not apply in the current market.  You will have to look at the real-time "going rate" for transactions as suggested in 3.

Also, you're asking three different questions at the end; Stack Exchange works best when you ask one question per post.  But the other two have already been asked and answered: see maximum inputs/outputs and unconfirmed transactions.

Number 2 just to see if you are interpreting it correctly, means if all pending transactions combined is less than 27kb then there are no fees. So it would be during least active times of day if at all.


text:
On-chain scaling still required with Lightning Network?
I'm wondering if/how Lightning Network relieves us of on-chain scaling on the road towards mass-level adoption. As I understand, payment broadcasts are deferred to the point in which the channel is closed, whereupon they are bundled and settled via consensus. Seems to me that although funds can be transferred hand to hand instantaneously, if we achieve global adoption, Lightning Network spends may still congest the mempool when they are finally broadcasted.
Discussion on page 52 of the Lightning Network whitepaper DRAFT Version 0.5.9.2 (after this was answered):

If we presume that a decentralized payment network exists and one user
  will make 3 blockchain transactions per year on average, Bitcoin will
  be able to support over 35 million users with 1MB blocks in ideal
  circumstances (assuming 2000 transactions/MB, or 500 bytes/Tx). This
  is quite limited, and an increase of the block size may be necessary
  to support everyone in the world using Bitcoin. A simple increase of
  the block size would be a hard fork, meaning all nodes will need to
  update their wallets if they wish to participate in the network with
  the larger blocks.
While it may appear as though this system will mitigate the block size
  increases in the short term, if it achieves global scale, it will
  necessitate a block size increase in the long term. Creating a
  credible tool to help prevent blockchain spam designed to encourage
  transactions to timeout becomes imperative.

Yes, it would require on-chain capacity increases if there were a lot of channels being opened and closed as well as normal on-chain transactions. This need is directly referenced in the Lightning Network paper itself.


text:
Bitcoin transaction unconfirmed, while way past expected processing time

I have started a transaction from "wallet A" at 2017-06-14 11:51:40 with

Fees 0.00066328 BTC,
  Fee per byte 293.487 sat/B

Which is not yet confirmed over 8 hours later.
I have a second transaction from "wallet B" at 2017-06-14 18:08:25 with

Fees 0.000599 BTC,
  Fee per byte 265.044 sat/B

Which was started almost 8 hours later than the first, with less Satoshi per byte and was confirmed within approx 1 hour.

How can the first transaction, with a higher fee not be processed, while the second one is? I know I didn't choose the highest fee, but the selected fee should have processed the transaction within 3 blocks, which was supposed to be within 60 minutes according to https://bitcoinfees.21.co/.
Edit:
I do have a past unconfirmed transaction, for which I put a way too low transaction fee, on that wallet. If there is a previous unconfirmed transaction, does that mean the next transactions will wait for the unconfirmed transaction to complete? This will never happen...

That's correct, a transaction cannot be confirmed until all its inputs (and all of their inputs, and so on) have confirmed.  (It is allowed for the transaction to go in the same block as its inputs, so that they confirm simultaneously.)
You may be able to remedy the situation by creating a third transaction that spends the second (7da9), with a large enough fee such that the overall average fee of all three transactions is at or above market rate.  Miners may be smart enough to realize that they can earn a good overall fee by confirming all three.  This is the idea of the child-pays-for-parent scheme, though it's usually used to have a transaction pay for its immediate inputs; I don't know whether the software used by most miners would detect longer chains like this one.
You can also wait for a while until other nodes have forgotten the low-fee a762 transaction, and then try to replace it with a higher-fee transaction (a double spend).  The details of doing this depend on your wallet; often it involves "zapping transactions" or "resetting blockchain" so that the wallet forgets what transactions it created, and scans the blockchain to find only those which are confirmed.  If other nodes have also forgotten the unconfirmed transaction, then it's as if they never happened and you can start again.

Thanks for the answer Nate! I woke up this morning, finding that my latest transaction had gone through, after reading your reply, which surprised me. Now I see that also the previous transaction, which was stuck for about 2 weeks also was confirmed. The transaction fees of both transactions combined, must have been sufficient to be processed, but as the average fee was a bit low, it was probably delayed like that. Luckily a third transaction was not required to push the others trough.


text:
Why does bitcoin core has to reindex the chainstate directory in some cases?
I was reading that some people were able to migrate their old index directories to a new machine and not needing to reindex.
But for me it acts as if the chainstate directory is "corrupt", even though those files were working just fine on the old node. I suspect that it's not really corrupt, but that bitcoin core isn't reading it correctly.
The exact message I see in the logs:
Using obfuscation key for /data/.bitcoin/chainstate

and then it would reload bitcoind and show this message again, in a loop, and never actually complete starting bitcoind.
What makes this migration process not work for some people, like myself?
I copied the following 4 dirs from the source node to the target node, exactly as they were with no extra or missing files.
bitcoin/blocks/
bitcoin/blocks/index/
bitcoin/chainstate/
bitcoin/indexes/

And using reindex-chainstate=1 in the config file takes a long time (already been 3 days and it's still not halfway done).
There's probably something that needs to be set for the chainstate directory to be compatible on the new node with bitcoind.

From which version to which version are you upgrading? Bitcoin Core should support upgrading from any maintained version without reindex.

27.0 on both machines

Can you elaborate on how you get this "corrupt" message? What is the exact error you get? Is there anything in the debug.log file?

Did you copy them while your Bitcoin Core was running?

Bitcoin service was stopped on both machines before copying. And to be exact the last line was "Using obfuscation key for /data/.bitcoin/chainstate" and then it would restart bitcoind and show this message again, in a loop

What exactly is the "corrupted" error message?

It doesn't say "corrupted" I just figured it is because of how bitcoind start process behaved. I edited my question accordingly. What could be causing it to fail to start, right after checking the chainstate dir? Maybe some missing config I could add?

Bitcoin Core doesn't restart itself; something must be restarting it. Is there some system service running? Perhaps that has logs? Is it possible to run it manually, outside of this service, perhaps with -nodaemon -printtoconsole=1 on the command line, so you see fatal errors.


text:
How is it possible, that nobody can track anyone on the bitcoin network?
Is it possible that a person on the bitcoin network cannot be tracked?

Yes, this is true. Because one person can generate new public and private key for each transaction. Bitcoin coin Blockchain provides anonymity.
However, it's just possible if we are working proactively. Means Don't share confidential information regarding transactions or accounts with people. Moreover, as I already said, generate new addresses for each transaction. In addition, there are enormous best ways of being proactive on the bitcoin network. This article would be helpful regarding learning the best ways.

Thanks for editing your answer, the updated version is much better!


text:
What's the difference between sats/byte and BTC/kB?
Bitcoin Core displays the fee in a unit of BTC per kilobyte, at least for now. However, block explorers are showing the fee in sats/byte. How do I convert between the two units?

A transaction’s feerate is a quantity derived from transaction fee over transaction weight. The fee is simply an amount of bitcoin, while the weight indicates the amount of blockspace a transaction takes for confirmation. The transaction weight is usually expressed in vbytes in the context of feerates to align the magnitude of the values with feerates before the activation of segwit.
Feerates in the reference client were original specified in bitcoins per kilobyte [₿/kB]. Since then, the value of Bitcoin has dramatically appreciated and segwit activated replacing the block size limit with a block weight limit. Feerates are commonly expressed as satoshi per vbyte [sat/vB] today. Many Bitcoin Core RPCs use satoshi per kilovbyte for feerates to allow for a three decimal precision while only operating with whole numbers.
The three common feerate units can be easily converted, e.g. to go from [sat/vB] to [₿/kvB], you would calculate:

1 sat/vB
= 1 sat/vB × 1000 vB/kvB
= 1000 sat/kvB × 1/100'000'000 ₿/sat
= 103 × 10-8 ₿/kvB
= 10-5 ₿/kvB
= 1 / 100'000 ₿/kvB

The following table gives the factor to convert from row entry to column entry:

↓ from \ → to
sat/vB
sat/kvB
₿/kvB

sat/vB
—
 103
 10-5

sat/kvB
10–3
—
10-8

₿/kvB
105
108
—

The following table gives the operations to convert from row entry to column entry:

↓ from \ → to
sat/vB
sat/kvB
₿/kvB

sat/vB
—
 × 1000
 / 100'000

sat/kvB
/ 1000
—
/ 100'000'000

₿/kvB
× 100'000
 × 100'000'000
—

Sats/byte means satoshis per byte and it was the canonical unit for writing transaction fees for a long time. When Segwit was deployed, its transactions used a new fee called sats/vbyte. This answer explains how to convert between bytes and vbytes.
Bitcoin Core uses BTC/kB, also called bitcoins per kilobyte, as a unit in some places. However, some parameters such as minrelaytxfee internally store the fee in sats/kB. To get the sats/kB fee rate, you can just divide the sats/byte value by 1000. One Kilobyte has 1000 bytes (there are other units that measure bytes in powers of 1024, but they are not used by Bitcoin clients).
Similarly, the above procedure can be used to convert sats/vbyte, also known as sats per virtual byte, to sats/vkB - sats per virtual kilobyte.
In order to get the rate in BTC/kB (BTC per kilobyte) from sats/byte, you need to divide the sats/byte value by 100000 (one hundred thousand), because one sat/byte is equal to 0.00001 BTC/kB according to this reddit post.


text:
How to pay no fees?
Is there any API where I can create some addresses and making a transaction beetween them just once a month without paying fees?
Or if you can recommend me somewhere with a fee under 5000 satoshis it would be great.

So you want to automate / schedule a periodic transaction?

Yes, but with a fixed percentage, not a fixed amount.

It is possible. However, such a NO FEE transaction with small amount of Bitcoin involved could delay your transaction. Your transaction might stay unconfirmed for a long time.
Here is basic idea to make a no-fee transaction:
Split your one of your unspent_transaction_output into two part. UTXO_1 and UTXO_2
 Send UTXO_1 to receiver's address; send UTXO_2 to your own address
 Make sure that UTXO_1 + UTXO_2 == your unspent_transaction_output
Follow this link to make a no-fee transaction.
https://bitcoin.org/en/developer-examples#simple-spending

The Blockcypher Microtransaction API is free, they eat the transaction fee's for you if you're looking to send small and free transactions.
http://dev.blockcypher.com/

You could setup a cronjob to run createrawtransaction, sendrawtransaction, etc. commands monthly. Cf. "Creating, Signing, and Submitting Transactions Based on Unspent Outputs" of Mastering Bitcoin.


text:
How does a Bitcoin node connect to more than 65536 other nodes?
I found on the internet that Bitcoin uses TCP to communicate with other nodes, connecting to them and sending messages. But a computer cannot bind more than 65536 sockets (because of TCP ports), so how can a node connect to more than 65536 nodes?

Does this answer your question? How does one attain 1,000+ connections like blockchain.info?

Why would you want/need to?

@MCCCS Um, the answers to that question say that a Bitcoin node will not open more than 8 connections. So, as I understand it, for a block to be spread to several nodes, one node passes to another, which passes to another, and so on. Right? And if the answer is yes, wouldn't that be bad and would you need one node to trust the other nodes in the network?

@chytrik I am trying to learn and understand Bitcoin protocol.

This does not seem related to Bitcoin, but is a generic question about TCP/IP network stacks. The relevant part on this SE site is simple: Bitcoin nodes only make a few outbound connections (usually in the range 4-10). The generic part is asked and answered here: https://serverfault.com/questions/160996/more-than-65536-tcp-connections-on-linux

@PieterWuille But isn't bad that a node needs to trust that other nodes will broadcast its transaction or block?

That seems like an independent question. In short: for transactions, perhaps, but you can always connect to miners directly, and there isn't much that can be done about it (the network would rapidly run out of sockets if everyone connected to everyone; most nodes can't even be connected to at all). For blocks, nodes have an incentive to relay blocks (to help the network converge to their own view of the chain), and you will detect when you're partitioned off. Related reading: https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-heilman.pdf


text:
Isn't it safer to only encrypt the wallet, then back it up, and NOT save the seed?
If you use the seed, and it gets compromised, then you immediately lost all your coins.
But if you only save the password safely, and backup the wallet file in several locations, then you gain a form of multi-factor authentication, because if the password gets compromised - the wallet file is still needed, and vice versa.
The seed may be useful for portability of the wallet, but it's a major security risk compared to just using the password and wallet file.
Am I missing something here?

Backing up the encrypted wallet file and saving the password elsewhere is basically equivalent to encrypting the seed itself and saving the encrypted seed in a different location to the encryption key. But indeed, that would require both parts to be used so would be more secure than just backing up an unencrypted seed itself

Then shouldn't we stop suggesting people to use the seed for securing their coins? All major wallets tend to suggest using it even though it's significantly less secure compared to the simple encrypted wallet file with a password method.

They do normally suggest backing up the seed in a secure place, and a paper copy of it in a safe place in your house should be pretty secure even if it's not encrypted

If the cleaning lady stumbles upon this safe place then the wallet is gone.. Think 5-10 years from now when people will be actively looking for those 12 words everywhere they look. It will become common knowledge that if you see a piece of paper with 12 random words on it, you found gold. We should go back to the method of 2 step authentication that exists when encrypting and backing up the wallet file. Just need to create a strong password that can't be brute forced.


text:
Bitcoin Gold Ledger Derivation path
What derivation path for creating addresses is used in Ledger for BTG? Generated address from the device doesn't correspond the address from the path m/44'/0'/0'/0/0 that is shown for BTG in BIP39 for the first key.
UPDATE 1: (to clear up) I had following (test) mnemonic generated from ledger:
hurry essay possible egg idea outer poverty doctor sense lab guess gate arrow supreme cave grape sunny deposit erode lemon couch wild fantasy equal
When I derived key using m/44'/0'/0'/0/0 path (that is shown in BIP39), I got GTUDDiUvkFJtL24f3Bq3pGyTwULuyzMSV1 address (same as on the site), but Ledger expected GX1FXv2PrRSARyctabywsi5X58teAjYFU4.

Finally I found the answer: the path is m/44'/156'/0'/0/0, it gave me expected GX1FXv2PrRSARyctabywsi5X58teAjYFU4 address.
Address header should be 38, dumpedPrivateKeyHeader same as in BTC (=128).
For those, who is seeking parameters for different bitcoin-like altcoins: I found many of them in the Coinomi repository.
UPDATE1: As it was mentioned by @john-doe, if you want to reproduce the address this way, you should switch to BIP32 tab and enter the path without the last segment (it would be added automatically for generated addresses).

If anyone needs it, here's the proof of 156: https://github.com/LedgerHQ/ledgerjs/blob/master/packages/currencies/src/coinTypeToIconName.js#L7

Sovan, your path didn't work with my iancoleman.io/bip39 page. Almost exactly as your

m/44'/156'/0'/0/0

but without the last 2 characters m/44'/156'/0'/0; it makes no sense to me but it makes a world of difference. Thanks for your help.
ps.for the noob like me, may I add, pick BIP32 tab under derivation path otherwise you can't enter this data on the page.

m/44'/156'/0'/0/0 represents the path for the first address (you can see it to the left of the produced address in the list). As the last segment is added by the site, you should enter only m/44'/156'/0'/0 (as you did) to get the resulting m/44'/156'/0'/0/0 path.

The exact key path for BTG is "156'"


text:
Number of Trials Required For Brute Force Attack To Have x% Of Success?
I'm making an informational video about how unlikely it is for an attacker to successfully brute force a specific bitcoin address. Obviously, it will deal with impossibly huge numbers ("not in earth's lifetime with today's technology"), but I would like to include the number of trials required for an attacker to gain 1%, 50% and 90% confidence of success.
Normally I can get away with using Excel for statistical problems. However, Excel doesn't do really big numbers so I'm unable to calculate.
If I were to use Excel, I would use the below formula that tells me the chance of getting 0 successes in ???? trials. I would subtract the result from 1 and that % represents the possibility of success.
=1-BINOM.DIST(0,????,2^-160,TRUE)
For a simplified example of what I'm looking for: If I were to play a game with a 1% chance of winning, I would have about a 90% chance of 1 or more successful efforts after 250 trials, 50% chance after 70 trials, and 1% chance after 1 trial.
91.89%=1-BINOM.DIST(0,250,0.01,TRUE)
50.52%=1-BINOM.DIST(0,70,0.01,TRUE)
1.00%=1-BINOM.DIST(0,1,0.01,TRUE)
Can anyone calculate how many trials would be needed for 90%, 50%, and 1% possibility of success against a single bitcoin address? The possibility of landing the address correctly is 1 out of 2^160.
Kudos if you can do the math in your head.

Since nobody replied, I posted this on the Math Stack Exchange and quickly got an answer.
For anyone that's interested, using a formula from R we get the following values:
pbinom(0,3.365231884e48,2^(-160), FALSE)   = 0.9000000000339017
pbinom(0,1.0130357393e48,2^(-160), FALSE)  = 0.5000000000001161
pbinom(0,1.46885823057e46,2^(-160), FALSE) = 0.01000000000005571


text:
How can one read the value of a wallet from the blockchain?
It seems like the blockchain transactions only stores the number of coins moving from one wallet to the other, but does not have the total amounts for each wallet.
Therefore it seems like if you want to get the value of any given wallet you would have to read every transaction in the ledger from the very beginning.
Is this correct or am I missing something?
Fyi, my goal is to understand the format of the blockchain better

Assuming you don't trust anyone, you need to read the entire blockchain history once to generate your own set of unspent transactions (UTXOs). You won't need then to read again the full history every time you want to see your balance. Unspent Transactions are enough to do so.
Your balance is the sum of the values of the unspent transactions your wallet has. Unspent means here that you didn't "spend" the previously received amounts on outgoing transactions.
Example:

Alice sends you 1 BTC. you now have an unspent transaction of 1 BTC. Your balance is the sum of unspent transactions, i.e. 1 BTC
Then Bob decides to send you 2 BTC. You have now two unspent transactions associated to your wallet, for a total balance of 3 BTC.
Let's assume now you want to send 1 BTC to Charlie. After checking that you have at least 1 unspent BTC (which is the case), your transaction would be processed and the amount that you spend would be removed from your "unspent" transaction. In that case, the transaction received from Alice would be now marked as spent and would be removed from your list of unspent transactions.
Your balance is still the sum of unspent transactions, i.e. 2 BTC (from Bob)

In order to figure out what the unspent outputs are, you still need to read the entire blockchain history.

If it is your 'wallet' and you have the private keys then you can import them into a wallet application. The wallet, with some work, is able to decipher which addresses are yours, scan the transactions on the blockchain and, update the balances.

I mean to ask how would one write software to do this? I'm trying to understand the format of the blockchain

Therefore it seems like if you want to get the value of any given wallet you would have to read every transaction in the ledger from the very beginning.

Yes, basically.  If you were sent 1 BTC in 2010 and never spent it, and 1 BTC in 2018 (also unspent), you have 2 BTC, but without going through the entire history of the ledger, you wouldn't be able to see both in your wallet without scanning the entire history.
It would be nice to be able to bootstrap a node with just the UTXO (unspent coins) at some point, but then to do this you'd have to trust the person generating the bootstrap, and you could not trace the true history of any of the coins (such as what IOTA do when they take a snapshot).


text:
How do wallets (like jaxx) pair with each other using the mnemonic seed phrase?
I'm a bit puzzled on how a wallet pairing process works.
I know you can restore you parent private key from a mnemonic seed phrase. This will give you a parent private key. Using this private key how does a wallet figure out the private/public keys you have derived from this parent key?
Thanks!

You've got everything right. The last step (the one you are referring to) is done by brute force. The wallets just try out many many possibilities until they think they've guessed all the derived privKeys that you actually used. For each possible privKey, the wallet calculates the address and checks whether this address exists on the blockchain ( = there are or were coins on this address).
If you use the same wallet for recovering that also created all the addresses, then the derivation process is obviously the same and the wallet knows exactly how to derive the privKeys, to be sure to "guess" all of them.
There are also standards for how to derive the privKeys:

https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki

Note: the wallet software does not ‘guess all of them’, as a BIP32 seed phrase could generate infinite child keys if needed. Most wallet software will simply follow some logic like ’look ahead 50 addresses, stop if no funded addresses are found. Check another 50 if a funded address is found’. Wallets also need to follow the same derivation path, or else the wallet may not check the right derivation path.

Thanks guys for your answers! Now I think I understand how it works :-)


text:
How to Connect already running bitcoind in AWS to Insight API in different AWS Server
Need to create a bitcoin explorer using bitcoind. I am using bitcore and insight API for this purpose.
Currently running bitcoind in AWS Server with all port open. Need to connect this running bitcoind with bitcore and use insight-api and UI in different server.
This my bitcore-node.json file:
    var configuration = {
 datadir: '/home/.bitcoin',
 network: 'testnet',
 services: [
   {
     name: 'bitcoind',
     module: Bitcoin,
     config: {
       spawn: {
         datadir: '/home/.bitcoin',
         exec: '/home/Downloads/bitcoin-0.16.1/bin/bitcoind'
       }
     }
   },
   {
       name: 'web',
       module: Web,
       config: {
           port: 4001
       }
   }
 ]
};

This is my bitcoin.conf
server=1
testnet=1
whitelist=127.0.0.1
txindex=1
addressindex=1
timestampindex=1
spentindex=1
zmqpubrawtx=tcp://127.0.0.1:28332
zmqpubhashblock=tcp://127.0.0.1:28332
rpcallowip=127.0.0.1
uacomment=bitcore

Need to Connect the Insight API to in the A server to Bitcoin in B server.

what is your question?

How to connect the two servers ?

You don't need bitcoind and bitcore, bitcore is already a node.

@JBaczuk : Referring the following link [Source] (https://bitcoin.stackexchange.com/questions/62929/connect-already-running-bitcoind-with-bitcore-for-bitcoin-explorer). How to proceed with the Connecting the Insight API with the Bitcoin Node.

Follow the instructions on this README. It should install bitcore (the bitcoin full node implementation by Bitpay), insight-api, and insight-ui. The instructions are:
npm install -g bitcore@latest
bitcore create mynode
cd mynode
bitcore install insight-api
bitcore install insight-ui
bitcore start

If that doesn't sync with the bitcoin network and start showing blocks, then please share some logs/errors and we can help you further.


text:
How to solve error: Incorrect or no genesis block found. Wrong datadir for network?
I am making my own alt-coin, and I have mined the first genesis block hash(after some time), Merkle hash, nnonce and time. I am running on Ubuntu14.04.
But when I run ./bitcoind I get this error

Error: Incorrect or no genesis block found. Wrong datadir for network?

What does it mean? how do I fix it?
Here is debug.log shows:

2018-04-02 18:33:04 Booducoin version v0.8.7.4-gc1e46ab3a90b-beta ()
2018-04-02 18:33:04 Using OpenSSL version OpenSSL 1.0.1f 6 Jan 2014
2018-04-02 18:33:04 Default data directory /home/boodu/.booducoin
2018-04-02 18:33:04 Using data directory /home/boodu/.booducoin
2018-04-02 18:33:04 Using at most 125 connections (1024 file descriptors available)
2018-04-02 18:33:04 init message: Verifying wallet...
2018-04-02 18:33:04 dbenv.open LogDir=/home/boodu/.booducoin/database ErrorFile=/home/boodu/.booducoin/db.log
2018-04-02 18:33:04 Bound to [::]:9333
2018-04-02 18:33:04 Bound to 0.0.0.0:9333
2018-04-02 18:33:04 init message: Loading block index...
2018-04-02 18:33:04 Opening LevelDB in /home/boodu/.booducoin/blocks/index
2018-04-02 18:33:04 Opened LevelDB successfully
2018-04-02 18:33:04 Opening LevelDB in /home/boodu/.booducoin/chainstate
2018-04-02 18:33:04 Opened LevelDB successfully
2018-04-02 18:33:04 LoadBlockIndexDB(): last block file = 0
2018-04-02 18:33:04 LoadBlockIndexDB(): last block file info: CBlockFileInfo(blocks=1, size=241, heights=0...0, time=2018-04-01...2018-04-01)
2018-04-02 18:33:04 LoadBlockIndexDB(): transaction index disabled
2018-04-02 18:33:04 LoadBlockIndexDB(): hashBestChain=5e55391ddfe7258c5d1dc5ebf2c8ce9bdec72edf482f171a6cb04416c53be9b8  height=0 date=2018-04-0$
2018-04-02 18:33:04 Error: Incorrect or no genesis block found. Wrong datadir for network?
2018-04-02 18:33:04 Shutdown : In progress...
2018-04-02 18:33:04 StopNode()
2018-04-02 18:33:04 Flushed 0 addresses to peers.dat  3ms
2018-04-02 18:33:04 Committing 0 changed transactions to coin database...
2018-04-02 18:33:04 Shutdown : done

@Cluster2k  Please check the debug.log

@Cluster2k Yes, it's working after I delete /home/boodu/.booducoin folder. Thank you so much!

@Cluster2k Can you help me in another error of forming gitian build


text:
How do I get rid of an unconfirmed transaction on Bitcoin Core 0.14.1?
Can somebody please help me? I have been trying to send .045 Bitcoins (approx $120 USD)
I am using Bitcoin Core.
I have tried to get rid of the unconfirmed transaction by using -zapwallettxes  However.. when I re-boot Bitcoin Core v0.14.1 (64-bit)   without the zapwallet command.. it still shows as unconfirmed and now it appears to be stuck. I am afraid it is a duplicate transaction and I'll never get my Bitcoins back before now I am at 0 after reboot.. and even worse the address keeps telling me they haven't received anything...
What do I do?

Since 0.14.0 the mempool is stored on disk when Bitcoin Core is closed. To apply -zapwallettxes to remove a transaction you also have to delete the mempool.dat as the transaction is otherwise reintroduced into the wallet when the mempool is imported.
To remove an unconfirmed transaction with 0.14.0 you have to:

Shut down Bitcoin Core.
Find your Bitcoin directory
Delete mempool.dat in the Bitcoin directory
Start Bitcoin Core with -zapwallettxes

Previous versions didn't persist the mempool to disk, so step 1. and 4. are sufficient to remove an unconfirmed transaction.
The interaction of -zapwallettxes and the persisted mempool was fixed with Bitcoin Core 0.15.0, so it is sufficient to set -zapwallettxes after that again.

Thank you so much Murch, But how do I delete mempool.dat      ?

I don't have a mempool.dat!

@Owl: And I don't have a Lambo. What's your point? ;) You might need to elaborate a bit what your question is, or if it exceeds what is sensibly treated in a comment section, ask another question and link it here. :)

Hi Murch, you are correct, it wasn't a helpful comment, i've solved the problem and added an answer explaining how i solved it on older clients. It should work for newer clients also. I think i've also found out why the transactions stay in the mempool for much longer than 72 hours too.

Murch's answer is correct, but to save additional searches: please note that older bitcoin qt clients don't have a mempool.dat file. Please note also that bitcoin-qt - as i understand it is the old name for Bitcoin Core.
For example the latest bitcoin-qt client for gentoo even after a sync is v0.13.1.0, which is really old. I'm a bit apprehensive about compiling from non repository sources because the wallet has access to my private keys and there are several versions of bitcoin-qt source code on github, and i'm paranoid about running a compromised one. Gentoo maintainers: please update your bitcoin-qt client!!
It is possible to check whether the transaction is stuck in the memory pool by right clicking on the transaction and clicking on "Show transaction details". If it's showing the transaction as in the memory pool with no confirmations, then proceed. If you have any confirmations, then stop now because it's already been sent.
Initially, I restarted bitcoin-qt -zapwallettxes. This removed my transaction out of the memory pool, however it was just re-added to the mempool when the client was restarted. So that's not the correct solution to the problem for older clients.
To stop the transaction from re-entering the mempool, i restarted bitcoin-qt from CLI with the option: bitcoin-qt -mempoolexpiry=1
What this option does, is it sets the transactions in the mempool to expire after 1 hour rather than the default 72 hours. Note that I had to keep bitcoin-qt running for over an hour to get the mempool to expire. If you restart the bitcoin-qt client within this time, it appears that the countdown resets and you have to wait another whole hour. Perhaps this explains why some people find that their transactions have been stuck in their mempool for weeks - they've for whatever reason restarted their bitcoin-qt client before the 72 hour countdown has finished. This certainly was the case for me.
After an hour, the transaction was still unconfirmed, but right clicking on the transaction then allowed me to abandon the transaction - this button was previously grayed out.
As soon as I clicked that my bitcoin balance was updated, a dustbin icon appeared next to the transaction and I've had no further issues.
Remember to set your -mempoolexpiry option back to the default 72 hours...
...or something more sane.

Now I understand your comment much better. ;)
BTW, newer versions of Bitcoin Core will keep transactions for 14 days in their mempool instead of 72h, so it may be readded to your mempool by being broadcast from another node even after 72h have passed.

Thanks for the information. This is quite a scary problem when you first come across it.


text:
Does a blockchain need a distributed hash table?
In this question on StackOverflow, the OP is asking if there is a difference between distributed hash tables and blockchain. The answer to that question seems to indicate that there is no point of overlap between the two as they are for completely different purposes. However, I would like to clarify this point.
To the best of my knowledge, blockchain is a peer-to-peer implementation, which means that the entire blockchain is stored in every peer. However, if there is a need to broadcast consensus of a particular transaction, there is still a need to look up the other peers in some kind of table of addresses. Am I correct? (My underlying question is: In a blockchain, would all nodes or peers get the information about successful transactions simultaneously? It doesn't seem likely to me, and I'm trying to understand the protocol for doing this broadcast in a simultaneous, or near simultaneous manner).

No. Peer discovery does not use a distributed hash table and cannot use a DHT. Once you are connected to the network, there is no need for you to find more peers to connect to (and most nodes have a limit of 8 anyways as that is Core's outbound connection limit).
The broadcasting of transactions and blocks themselves does not rely on the broadcaster to find all peers and send the data to each peer. Rather it simply sends the transaction or block to the peers it is connected to, and then those peers check the block and transaction, and if it is valid, they will send the block or transaction to their peers, and so on and so forth.

Sorry, I wasn't referring to "peer discovery". What I meant was "broadcasting consensus of transactions to other peers". I believe that the broadcast would have to go out from one peer to the second, and then to connections of that second peer, and so on. This seems to require some kind of table of addresses of peers. I will clarify this in my question.

I have edited my answer to address transaction and block relay

A blockchain needs a distributed hash table like a fish needs a bicycle.
The standard distributed hash table constructions achieve little to no particular robustness to attack for any actually useful definition of security, as a result they are not particularly useful for our applications.  Really, DHT just became a buzzword for "distributed" used most frequently by people who know only enough to be dangerous... until "blockchain" became a more popular buzzword for distributed.
What systems like Bitcoin do is distribute all the data to everyone. There is no need to look up routes or destinations, the system is a great big broadcast.  When a transaction comes in to a node, it offers it to each of its peers and if they don't already have it they'll request it.
It would be possible to do some other things-- though not generally the things in existent DHT systems because they don't generally achieve useful strong security properties-- but since validation in the Bitcoin style design requires everyone sees all the data it isn't particularly useful to avoid broadcasting it to all of them because they'll eventually need to see it all.

Bitcoin nodes still need a "seed" ip to connect to the first time. A few backup ips are hardcoded into the bitcoin core software in case you don't know any yourself. From then, the node will get and maintain a list of working peers.
The magic of the bitcoin protocol was to be trully decentralized. Meaning there is no central point of failure, not even a distributed common list.
But... How to achieve consensus in such situation would you ask ?
With the "proof of work". (for Bitcoin, but other cryptos are experiencing other things)
To push a bloc of transactions on-chain and be rewarded, a miner needs to first check the said transactions, and then be the first one to find a valid answer to an equation involving the block, solvable only by brute-forcing it but easy to check (more on that later). Once done, it spreads the block and the associated solution to his peers, that will stop trying to "solve", re-check the bloc you gave them and add it in order to start trying solving the next one. The difficulty of the problem is (slowly) auto-adjusting to have a bloc every 10 minutes, no matter the power of the network. The resulting difficulty level is a snapshot of the power of the network at work on the chain.
When 2 nodes are peering, they "handshake" each other, they basically tell one another "I'm at bloc number 456, my last block has this fingerprint".
If they disagree, the "longest chain" wins. But it's not really about size, longest means power speaking. Knowing the "difficulty level" of each block, you can do the math and know how much computational power was behind this version so far.
If it happens that the other node as a more followed truth, you start retrieving his blocks, one by one, from where you disagree, and you check them one by one, transaction by transaction, while checking that every proof of work is a valid one. At the end, you have another truth, but as you checked everything yourself and there is more PoW, you know it's a better truth. It's why it's better to wait a few blocs before saying that a transaction is unalterable, time for the consensus to take place, time for a "longest chain" to take over.
But this is really theoretical, as with the current hashrate and level of interconnection between nodes, a "longest chain fight" as infinitesimal chances to last more than 2 blocks.
The miner is allowed by the protocol to add one transaction to the block, his reward, from thin air. So if his block achieves consensus, he will be paid. Otherwise, it will have never happened.
This is how bitcoin achieve consensus.
You can't mine blocs with invalid transactions, as every node re-checks them, and as every node will check it too, you must have a valid proof of work. Then, if you want to delete a transaction from a bloc, it will change the equation to solve, so you need to find a new solution for this bloc, and if you want to win the longest chain war (as this bloc was already mined), you need to be the first one to close the next block.
So, to be able to change the chain, you need to be "in average" faster that the rest of the network to compute proofs, and raise your own version of the chain aside until you succeed in making it bigger, PoW speaking, than the main one. The famous 51% problem.
Now bonus: the bitcoin proof equation
Depending of the average block time, the protocol sets a difficulty level to keep it in the 10 minutes/bloc range.
Do you know SHA256 ? SHA is a hashing algorithm. It produce a 256bits "fingerprint" for a content. As close as you can study the output with different stuff, it will look like totally uncorrelated to it in any way, looks completely random. You change a single bit in the input, totally different output. But, and this is the attribute we are playing with, feed it with the same input, anytime anywhere, same output.
Each bloc has a header, a part including the hash (SHA) of the previous block and info about this one. The game is to find a number (called nonce), which added to the block header outputs a fingerprint starting by a certain amount of zeros. Yes, difficulty 14 means that a miner has to find a nonce that allows the output of a fingerprint starting by 14 zeros.
And as SHA is random-like, the only thing you can do is try a gazillion stuff, one by one, brute force.
Once you have a solution, it fits this specific bloc, as your nonce as to be fed through SHA with this specific header to outputs a valid answer, Both are linked for life. And as the header also includes the hash of the previous block, changing any block involves changing the upper ones.
So a proof is hard to compute with no shortcut other than brute-force, and checking just require to run SHA once by block. As long as the zeros are there, the power was. And here you go.

Strategy Network Consensus Storage Clock-free
Bitcoin [1] Broadcast PoW Full Yes
BitCoin-NG [11] Broadcast PoW Full No
NEM [12] Broadcast PoS Full No
Snow White [13] Broadcast PoS Full Yes
Ouroboros [14] Broadcast PoS Full No
PPCoin [15] Broadcast PoW-PoS Full No
PoA-Bitcoin [16] Broadcast PoW-PoS Full Yes
NEO [17] Broadcast dBFT Full No
Ontology [18] Broadcast VBFT Full Yes
Elastico [19] Broadcast BFT Full No
Ripple [48] Broadcast BFT Full No
Tendermint [49] Gossiping BFT Full No
Hyperledger[27, 28] Gossiping BFT Full No
Omniledger [20] Gossiping BFT Full No
Avalanche [21] Gossiping Snowflake Full No
Skipchain [22] Gossiping BFT Full Yes
PeerCesus [23] Flooding PoW-PoS Full No
Rollerchain [24] Flooding PoW Distributed Yes
Trustchain [25] Gossiping PoW Distributed No
Rapidchain [26] Gossiping BFT Distributed No
BigChainDB [5] Broadcast Paxos Distributed No
LightChain DHT PoV Distributed Yes


text:
My first bitcoin transaction with core and coldcard
I use coldcard and bitcoin core 0.20.1. I have checked how to do it with HWI at https://github.com/bitcoin-core/HWI/blob/master/docs/bitcoin-core-usage.md.
It appears more complex than needed.
With the core's GUI, I can create a PSBT, save it, and then sign it with an SD card and coldcard. The latter will create a TXN file with the finalized transaction, that I can just broadcast with core.
No need for HWI and only 1 console command (sendrawtransaction) needed.
I am afraid: am I missing something?
Thank you for any suggestion.

That is a viable method for using a Coldcard with Bitcoin Core. HWI is intended for the case where the hardware wallet is plugged into the machine running your wallet software. For the Coldcard, it is just an alternate way to use it. However for other hardware wallets, the MicroSD card method is not available so HWI provides a way to use them with Core.

Thank you Andrew, that make sense and I better understand now the context of HWI. I did it the easy way and it worked for me. I will document below my experience.

From the coldcard site there is a link (above) for using coldcard with bitcoin Core. The first sentence is the following: "As of Bitcoin Core v0.19.0+ the setup can be done fully airgapped, but spending needs a USB connection and additional software such as HWI."
In the sense of Andrew's reply this make sense, however it is also possible to spend airgapped funds without an USB connection and without HWI. I will record my experience, I hope it helps those with my configuration (Core 20.1, Coldcard Firmware 3.1.9).

Create a watch only walled in Core as in the link above
Press "Send" in the Core toolbar
Enter your transaction in the Core GUI
Press the "Create Unsigned" button
Paste the PSBT in your favorite text editor and save it on a MicroSD card as a file with a PSBT extension
Insert the MicroSD in your Coldcard and hit "Ready To Sign". The Coldcard will sign the PSBT and create 2 files on the MicroSD card, a PSBT and a TXN file.
Open the TXN, copy the content in the clipboard
In the Core console hit "sendrawtransaction" and paste the copied TXN
Hit enter, and your transaction will be broadcasted.


text:
DDOS attack via BRC-20 & ordinals on Bitcoin

Do we currently see a DDoS attack on Bitcoin as the mempool is flooded with low value transactions incl. BRC-20, ordinals etc. (where the transaction fee exceeds the transferred value)?

What can / should be done to stop that or is that against the Bitcoin censorship resistance ethos?

Does a congested BTC mempool and a high fee environment negatively impact the  viability of lightning/layer 2? You need to be able to close channels for far less than what's in the channel, otherwise the game theory around punishments doesn't play out, right?

Do we currently see a DDOS attack on Bitcoin as the mempool is flooded with low value Transactions incl. BRC-20, ordinals etc. (where the transaction fee exceeds the transferred value)?

I get why some people don't like it as it is driving up transaction fees for a use case that many of us see as antithetical to Bitcoin. But it is only driving up transaction fees and filling up blocks, it isn't preventing full nodes from operating or knocking them offline. Hence I personally wouldn't call it a DDOS attack.

What can / should be done to stop that or is that against the bitcoin censorship resistance ethos?

There are theoretically two options: a consensus change or a policy change. A consensus change disallowing a certain kind of transaction that is acceptable under current consensus rules would need a soft fork and hence would be extremely difficult to pull off assuming that it was a considered a good idea by the broader community. Embedding arbitrary data in transactions would still be possible after this hypothetical soft fork and so its effectiveness would be limited. A default policy change (or custom policy option) would attempt to prevent a certain kind of transaction from propagating across the network without needing a consensus change. However, it would still be possible to submit these kinds of consensus compatible transactions directly to miners bypassing the P2P network.
Hence in summary I don't think anything will or should be done. Andrew Poelstra also came to a similar conclusion in this bitcoin-dev mailing list post (January 2023). It was expected that transaction fees would rise eventually through normal onchain transactions and Lightning channel opens and closes. This kind of usage is just driving transaction fees higher prematurely.

Does a congested BTC mempool and a high fee environment negatively impact the viability of lightning/layer 2? You need to be able to close channels for far less than what's in the channel, otherwise the game theory around punishments doesn't play out, right?

The micropayment use case (and smaller channels) on Lightning were always going to be exposed to fee spikes. Lightning cannot control the onchain transaction fee to open and close channels. Larger channels with capacities above the current transaction fees can still close, just more expensively. As I said earlier this was always going to happen at some point. It is happening earlier than it otherwise would because of this use case but it was inevitable eventually.

Re the policy change, they would simply slightly change the script they use i guess instead of going for miners: if most of the network bans FALSE IF, just start using FALSE IFDUP IF for instance. It's not tractable to prevent them from doing this.

@AntoinePoinsot: Right, at the very least a never ending game of whack-a-mole. Change default policy, transaction template is changed to meet new rules, change default policy, transaction template is changed to meet new rules etc.

Not only that but it's also ineffective: one does not simply change network policy. It's a slow process to get most (or a significant share of) nodes to run a new version of bitcoind. Ordinal users will most likely be quicker to shift templates, resulting in no actual disruption for them. And the network would be in a worse state overall with various nodes running incompatible policies.

Its worth noting that you asserted this is not an attack while also asserting that we would have to change policy and or consensus in order to counter it, maybe lets call it a vulnerability then? That is being exploited? Therefore an ATTACK. Its weird to see people so complacent when one of the most important things on earth is being attacked.

@Poseidon: I don't like this use case. But they are transactions that meet the consensus rules, policy rules and exceed the market fee rate. From the standpoint of protocol developers there isn't a solution to whatever problem is presented here. I'm not going to call a use case I don't like an attack. Maybe a social attack that is addressed by trying to persuade people that it isn't a good use case. But that isn't a code or running software solution.

I disagree, we can choose to stop relaying their transactions if we feel they are a dishonest attempt at raising the minimum fee rate beyond the capabilities of the average end user (Bitcoin l1 completely unusable for 2nd world countries at this point). You can remain complacent if you want but just know that if we lose major market adoption and need to teach another generation about PoW PoR NYKNYC etc... that will be at the hands of said complacency.

@Poseidon: Your node can stop relaying their transactions, sure. But as the answer and the conversation with Antoine states a default policy change isn't a good idea for a number of reasons including the fact that transactions can be submitted directly to miners bypassing the P2P network. If you've looked at all the possible solutions and they are worse or ineffective compared to the status quo you don't do anything.

The status quo right now is that people are PISSED that Udi and the Taproot Wizards have managed to make it unreasonable for anyone to broadcast normal transactions. A small group of people has made it unmanageable for the majority of Bitcoin users to transact properly. That status quo will run the improved software which STOPS RELAYING SPAM and then we will have a network that is not affected by the vulnerability. If you don't think lessening spam on the network is a good thing I consider you a bad actor.

Thoughts on #3?

The increased fee environment has caused a noticeable impact on lightning channels according to users, there is an increased amount of channel closes due to fees for htlcs making routing fail constantly. The channel close fees are also higher than they should be, people are effectively seeing their lightning related transactions be dumped for spammy ones.

Not to mention the core principal behind ANY off chain scaling solution so far is atomic multi-path payments, currently these are being fixed to a timelock scheme, but if you are in a channel with someone who has a lot more money than you they can submit a force close with the full amount from the last commitment and effectively steal your sats by being able to out spend you on the fees.

Philosophically, Bitcoin supposedly relies on Nash's game theory to balance usage within capacity. Nash assumes rational players in his games. The BRC20 transaction flood exists outside this. Specifically, when transaction volume exceeds capacity, confirmation delays inhibit new transactions, and a feedback loop of increasing fees accentuates the situation
But BRC20 is a marketplace of pump-and-dump sociopaths external to Bitcoin. While that market returns profits which are greater than the Bitcoin fees paid to inscribe the BRC20 tokens on Bitcoin's blockchain, those sociopaths are not deterred by high Bitcoin fees
We've seen these speculative tokens booming and crashing on Ethereum for 6 years. The Ordinals protocol is an innovation which allows non-fungible tagging without an ETH contract. Combine this with the long-running high-fee problem on ETH. BRC20 allows the creation of new tokens with 90% less effort compared to the ETH equivalent
But the easier they are to create, the faster they should crash. There are signs that this speculative market has already crashed. All the panic is pointless
Technically, these "inscriptions" were enabled by an innovation external to Bitcoin. Ordinals is a development which assigns a unique reference number to every Satoshi ever mined. This allows for non-fungible tagging of Bitcoin transactions. The other part (inscriptions) has always been possible in Bitcoin, due to Bitcoin txinputs being scripts. Bitcoin has had this feature since launch in January 2009
There have been knee-jerk demands for filtering "non-standard" scripts. These suggestions are foolish. Bitcoin Script is a function-rich programming language. If there is one way to inscribe arbitrary data, there are trillions of ways. They can not all be blocked

Do we currently see a DDoS attack on Bitcoin as the mempool is flooded
with low value transactions incl. BRC-20, ordinals etc. (where the
transaction fee exceeds the transferred value)?

No. Mike has some good criteria outlining why. Mainly that this currently does not prevent people from running full nodes. With that said, this can change if the behavior of the arbitrary data becomes more socially objectionable, or technical issues arise that cause full nodes to misbehave as a result (CPU DoS on mainnet for example).
Therefore, hoping for the best and preparing for the worst is probably a good strategy for everyone involved.

What can / should be done to stop that or is that against the Bitcoin
censorship resistance ethos?

There is a lot of precedent surrounding the issue of arbitrary data.
Changing standardness rules to increase the cost of this unwanted behavior has been done before, it can be done again.
In the extreme a softfork to increase the cost even more could be done, though would likely be contentious and unpopular. (though packaging it with some other features like APO or some other fancy stuff may get it over the line).
But arbitrary data will probably always be possible on Bitcoin. The question of, at what cost, may be up for grabs.
Currently that cost is evidently low.
Individuals can also choose to run Bitcoin consensus affirming full nodes that have differing standardness policies that may punish/filter/increase the costs for these kinds of transactions.
The current angle for this is simple mempool filtering of these transactions with something like the ordinaldisrespecter patch. But there may be more in the pipeline.

Does a congested BTC mempool and a high fee environment negatively
impact the viability of lightning/layer 2?

Probably not, if anything it may super charge it. Keep in mind this activity is coming in waves. the mempool does clear or nearly clear on a semi regular basis, giving people more opportunity to open and close channels.

You need to be able to
close channels for far less than what's in the channel, otherwise the
game theory around punishments doesn't play out, right?

This may be beyond my scope. But I'm not really sure what you mean by this last part? punishment game theory still works with or without high on chain fees? unless you are talking about very low value channels, in which case you may be right!

if we forget about backward compatibility and the impact of other types of transactions, then the following two options would be possible:
a) allocate only up to 10% of the space in the block for non-standard transactions - then all senders of non-standard transactions will compete with each other and it's only 10% with other types of transactions. In the absence of non-standard transactions, all space of the block will be given to standard ones. And in the absence of standard transactions - all space of the block will be given to non-standard ones. If bitcoin-chain was created primarily for standard transactions, then such a model will have to be supported by the majority.
b) change the architecture in such a way that the onchain ordinals transaction became much more expensive, which would force them to go to their own type of the LN - this would be a kind of justice, like the displacement of small transactions from the onchain to the LN happening already now

Notice that there is no way for us to coerce miners to follow this scheme: the escape ahtch of allowing non-standard txs to exceed 10% means we'd have to prove that there were non-standard txs in flight to invalidate a block for which the miner had picked the higher fee non-standard txs, which we can't do, since that's the whole point of blocks (reaching consensus about the existence of transactions at a certain point in time).


text:
Transaction fees above Transaction Value - Unsustainable long-term?

Does Bitcoin Core support that transaction fees are higher than the transaction value itself? If so, why is that?

Should there be a dust limit to cap transaction fees (I.e. max transaction value)? Would that require a (soft) fork?

The dust limit is something that restricts output sizes. Transaction fees are collected into the block reward, they don’t create separate outputs. Regarding the ratio of fees to sent amount, are you asking why the protocol doesn’t disallow this or why the wallet creates such transactions?

Yes, why does the protocol not restrict low value transactions where the fee is much higher than the transaction value. Would solve spamming potentially or am I missing something…


text:
I have forgotten my Blockchain account password and 12 word recovery. I have the wallet id and password to the wallet. Can i get my funds back?
I have forgotten my Blockchain bitcoin account password and 12 word recovery(possibly didn't even create one). However I do have my wallet id and the password to the wallet. Is there a way to get the funds? I read about some stuff of brute forcing the password or using something like a dust attack to get the funds out. Would this work? Thanks for any help

Related: I have lost my wallet, what can I do?

If you have a custodial account with Exchange.blockchain.com, you must contact them for help. They own the money, not you ("Not your keys -- not your bitcoin").
If you have a non-custodial wallet downloaded from Blockchain.com, you should normally recover control over your money by restoring the wallet from a backup or from a safely stored record of either the recovery-phrase or the private-key. If you have none of these, you have lost control of the money.

References

Blockchain.com custodial account
Blockchain.com non-custodial wallet

Write Down Your Backup Phrase
Your backup phrase is the most important of all security measures. It is the key to ensuring your access to your funds if you forget your password or Blockchain is unavailable.


text:
can not access bitcoin in an address that belongs to a discontinued wallet, although i have the 12 word phrase?
I am still a Rookie regarding bitcoins and therefore apologize beforehand if I might use some words wrong.
I started a bitcoin wallet through a provider some years ago and bought some bitcoin. The wallets they provided were in the cloud and the didn't want to continue with that solution after some time so they discontinued their wallets. At that time I transferred my bitcoin to a new wallet.
This week I transferred the bitcoins back from the new wallet to the old wallet as I still had the old address written down and I thought that I could sell the bitcoin through my old provider (had forgotten about that they discontinued their wallets). I can see the public key or address which contains the bitcoin.
I have the 12 word recovery phrases for both wallets. I tried to recover my wallet with the 12 word phrase but the balance is 0. When I log on to the blockchain app i can see the old address under "imported addresses" but it says "not payable".
Is there any way to access these bitcoin on the old address or are they burnt?
I tried the steps in I have my 12 word seed from @Abdussamad, even with different import methods but unfortunately it can't see the balance.
Really appreciate your help.
br

Is the "old provider" still in business (e.g. some non-wallet business)? If so have you contacted them about this? Do you know if their 12-word seed is a normal BIP39 seed and do you know the derivation path used by the old wallet (assuming it was an HD wallet)?

They are still in business. I have contacted them and they say that they can not do anything. When trying to recover in Electrum I need to check the BIP39 checkbox to be able to continue. Does that mean that it is a normal BIP39 seed?
Unfortunately I don’t know the derivation path.

See answer regarding derivation paths

If you have a 12 word recovery phrase for the old wallet, if the phrase is a BIP-39 recovery phrase and if you can find the derivation path, you should be able to recover control over your money using a standalone wallet that supports BIP-39 and which allows you to specify the derivation path.
You could use a list of popular derivation paths as a starting point for your own larger list and systematically work through them.
It would be easier if the original business could tell you the derivation path used in their discontinued wallet.

Thanks a lot! I have contacted the business and wait for their answer. Can you recommend any standalone wallet that supports BIP-39 and which allows you to specify the derivation path? Again thanks a lot!!!

@BitcoinNoob. In electrum, when you first run it, you can create a new wallet, ->  standard wallet - I already have a seed you can then select address type and enter a derivation path. See https://bitcoinelectrum.com/restoring-your-standard-wallet-from-seed/

I got an answer now:      The wallet was provided by blockchain's API and the opportunity to retrieve private keys and also log in to the wallet on blockchain was offered.      Does that mean that I should use blockchains derivation path m/44'/0'/0'?

Just a comment that might help: via the blockchain app I have a wallet where I can see the imported address where my bitcoins are. It says I would need to scan my private key in order to be able to spend the coins there. When I try to pair my app with the web wallet, I can't find the imported address anywhere.

I started to create new wallets in electrum. I assume that I have to go m/44'/0'/0', m/44'/0'/1', m/44'/0'/2' and so on. Is there a upper limit?

@BitcoinNoob: You shouldn't have to enumerate all the values, the wallet should do that. There is an initial upper limit to the number of values iterated by the wallet. This limit is called the gap limit. You should just set the initial pattern and let the wallet generate a set of addresses and let it find out if those addresses have any unspent amounts in the blockchain. You can extend the gap limit but that shouldn't be necessary unless you originally generated a lot of receive addresses that you didnt use

So, I tried to recover the wallet and increased the gap limit. Quite a lot but still no luck with recovering access to the right address where the coins are. Luckily the original business contacted me and tried to help me. Turns out that they had a different wallet which was probably the one used for buying the coins and probably also the one which is connected to the address where the coins are. They combined their own password with my password to access the wallet (on blockchain) with my mail address. We tried that but that didn't work now to access this other wallet. Any ideas?


text:
Can the 51% attack be made to become 81% attack or 91% attack?
Since the 51% attack happens if there are more than 50% of nodes that fake the data on the blockchain, can it be actually 81% or 91% that is needed to fake the data, because it would be much harder if more than 80% of the nodes are "bad guys".
So what I mean is, can it be the case that even 79% cannot be an attack, but need to be a higher number, such as 81% or 91%.
It may appear if the verification of data can reach a 50% level, reaching out to 1 more node of those 50% can make it become 80% to 100% easily, so one extra step is all it takes?

This question is based on false assumptions. The node network does not vote. It exists as a social consensus. The consensus relies on node operators to choose to follow the same rules. In some discussions this is referred to as "supermajority", which is accurate. It is completely inaccurate to believe nodes can vote, or that nodes can be reliably counted. All Bitcoin nodes are independent
The so-called 51% attack scenario is derived from the Satoshi white paper, under the heading "Calculations". This warns that a miner with more than 50% of the hash power can overtake all the other miners and mine blocks containing his own fraudulent transactions. The scenario is a consequence of the "longest chain" principle in the design. When there is a tied mining race, the node network will have a temporary chain tip fork, which is usually resolve din the next block, in favor of the longest chain. Nodes with the shorter chain will perform a chain tip reorg, to resynchronize. A 51% miner can simulate a tied mining race with hash power
Satoshi's scenario describes an attack which replaces one block at a time. The white paper includes some mathematical projections which display that it becomes exponentially more difficult to force chain tip forks more than one block long
It is now known that 51% hash power is not necessary, and that an attacker who shadow-mines a chain tip of multiple blocks secretly, in parallel with the regular mining network can create a chain tip fork of arbitrary length, just by winning one block more quickly than the regular mining network
Shadow mining scenario: acquire at least 15% of the hash rate. Mine in secret, in parallel, for an hour or a few hours. Eventually, the 15% hash power means a 15% chance of winning a block. Do not broadcast the winning block. Keep mining for 10 more blocks, and then broadcast the 11-block tip. The "longest chain" logic in the node software will recognize the attacker's 11 blocks as longer than the regular mining network, and will automatically reorg the chain tip
Attacks like this have been seen several times on Bitcoin Gold and Bitcoin Cash SV

The 51 percent attack isn't necessarily "faking the data". It is generally referred to say including a double spend in a block that would normally be rejected by the network but the honest part of the network struggles to reject that block and the chain built on top of it because it has a minority of hashpower. The point being that proof of work is still completed, it isn't "faked". But in answer to your question, of course a 81 percent attack or 91 percent attack would be even more concerning than a 51 percent attack. It is called 51 percent because that is the minimum needed to pull off the attack.
There is nothing that can be done to increase the minimum of 51 percent needed to pull off the attack to say 81 percent in a proof of work context, it is the nature of the system. Of course, in reality the network may choose to follow the chain with reduced proof of work but without the double spend transaction in it. It would be disruptive, extremely expensive for the attacker and could (likely) fail.

I'm not sure I understand the question fully, but I'll try to answer anyways.
First, what a 51% attack is, is when a single miner controls over half of the hashpower on the network. If an attacker who had 51% of the hashpower wanted to attack the network, they would simply continue to mine their own blocks, and refuse to build off of blocks of any other miner, and because they control over half of the hashpower, their version of the blockchain, consisting entirely of their own blocks, will be the longest. The remaining 49% of miners won't be able to outrace them, and because Bitcoin considers the longest version of the blockchain to be the valid one, the blocks of the remaining 49% will become orphaned.
Because they can prevent any other miner's blocks from being accepted, they will be able to include only transactions they want in their own blocks, censor transactions they don't like, etc. since they control all new blocks.
As such, it's not exactly that the Bitcoin network is reaching out to nodes to validate transactions. Other miners simply can't catch up to the new blocks of the attacker, and so the attacker's version of the blockchain is accepted as "truth".