text:
Can everybody earn bitcoin?
I am a Bangladeshi. I know little about bitcoin and I have no credit card. Is it essential having bank account to earn bitcoin? How will bitcoin help me? How and where can I start earning bitcoin?

possible duplicate of I am new to Bitcoin, how can I get started?

There are no requirements about your nationality, skills or need to have a credit card to use Bitcoin. The only major requirement is that you have a smart phone or computer and access to the internet. In terms of earning bitcoin, you may earn it any way you might earn Taka or United states dollars, however you might find few employers will pay you in bitcoin.
There are some services to earn small amounts of bitcoin for simple tasks. A quick search turned up coinworker, but it looks like there are other similar sites if you find that doesn't work.
Hope that answers your question Banda!

Where will I purchase things(i.e. books etc.) by bitcoins. If I can't buy anything by bitcoins what is the meaning of earning bitcoins?

By far the easiest way I have seen to realistically use bitcoin is to buy gift cards for a specific retailer using gyft. Although it is more convenient if you find someone that is willing to sell you items for bitcoin.

To improve your knowledge about BTC go to bitcoin.org and en.bitcoin.it (on the latter, Bitcoin Wiki, you can find also Forums & Chats to expand your knowledge).
To know about the current price on Bitcoin exchanges go to bitcoinwisdom.com.
Some corporations sell computer hardware only in a few countries, example:
Dell.com (in USA, UK & Canada), NewEgg.com (in USA & Canada).  Day by day more corporations are willing to accept BTC as payment, ask them if they do it.
To get BTC in your country better try an international exchange site like LocalBitcoins.com, maybe you can find somebody willing to sell BTC and the site provides the info necessary (here's a direct link to their Bangladeshi market).

Hope that this info will give you a quick start into Bitcoin.


text:
Can my bitcoins get stolen?
I posted a question on here about my bitcoins being stuck, they are no longer stuck but someone has taken all of my bitcoins from that wallet and I don't know how

What do you mean stuck , and what do you mean stolen ? What kind of wallet are you using ? How did you conclude they were stolen ? Please update the question before we assume the worst.

Well I posted a question here the other day explaining how they got stuck, the address changed half way through I think, I am using etherum and they were there and then a few transactions came through that were this week but dated April

Please clarify what website, exactly what you did, what you see, and what you expect to seem. As stated, I vote to close the question as unclear.

@CalMO'Gorman-Anderson:  Addresses do not change mid-way in a transaction. Ethereum and bitcoin are two different platforms and are not interchangeable. +1 to close, as i have no idea what is being asked here.

To answer the question , yes. If some one has access to your private keys, then it is easy to steal them and more or less there is no way to get them back.

source: Stack Exchange

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

sort: votes


text:
My bitcoins are stuck I need help please
Ok so I was transfering bitcoins from my wallet on my phone to a friend's computer wallet and I'm pretty sure his address changed halfway through because his address is no longer the same and the bitcoins are lost now and I'm so confused, the transactions are still unconfirmed but I don't know how to get them back or get them to the right address it's using blockexplorer here's the link to the transactions anyway https://blockexplorer.com/tx/eafacd02739a473a454c73502400eed4d77b0fc6ae0a96752cd2503274f87309

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


text:
how to start earnign bitcoin?
I have email id and linux OS(Ubuntu, Fedora). I use internet through ISP.
I am also a CSE student that means I know programming. How can I earn bitcoin and where should I start?
I need short and straightforward step for this?

Replace 'bitcoin' in your question with 'dollars', and the answer will be the same.

How do I get rich without showing any proof of work? This made me down vote. Might be the wrong area to raise such question...
If it is really an honest question, then you might want to start at bitcoin.org, and read the book mastering bitcoin (https://www.transifex.com/bitcoinbook/mastering-bitcoin/) from Andreas.
Then precise your question and come back?

authors: ابراهیم جمالی


text:
Is it possible to get a service provider , which provide stable, not-changeable BTC address.
My new employer prefers Bitcoin as the way of salary payment, but the address keeps changing, is it possible to get a non-changeable on, or is there is any other way to transfer bitcoins from one person without entering new address every time?

With most providers, an address should remain valid indefinitely.  This would certainly be true if you use your own software wallet, instead of relying on an online provider.  If you give your employer one address, they can make transactions to that address as many times as they want, and you'll receive those coins.
It is usually recommended to use fresh addresses for each transaction, because it is better for privacy, and makes it harder for other people to track your activity.  But it isn't required by the Bitcoin protocol.
If your employer (or their payment processor) insists on being given a fresh address for each payment, that is their decision, not a technical requirement of Bitcoin itself; you'd have to take it up with them.


text:
Is it possible to spend bitcoins from private key 0?
In [1]: from bitcoin import *

In [2]: privtoaddr(0)
Out[2]: '16QaFeudRUt8NYy2yzjm3BMvG4xBbAsBFM'

On blockchain.info, there is 0.01 BTC unspent in this address. Is it possible to spend the bitcoins? If not, why?

While 0 is not a valid element to use as a private key, and as such whatever public key that your software generated which was then hashed to the address is also not a valid public key, the address 16QaFeudRUt8NYy2yzjm3BMvG4xBbAsBFM itself might be a hash of some other valid public key.  Since the scriptpubkey for this address only cares for a public key that is hashed to this specific address, and a valid signature for it, there might exist some unknown valid private key that fits for spending the funds sent to the address.
We will probably never know if such a key exist.


text:
Difference between Public Bitcoin Address and Hash 160 Address?
I know the difference Public Key and the Public Bitcoin Address (hashed version) and why.  But I dont understand why there is a Public Bitcoin Address and Hash 160 Address?
I assume the Hash 160 Address is just another hash of the Public Bitcoin Address?
Can you tell me what exactly the Hash 160 Address is and more important, why it is needed?
Thanks!

What you refer to as 'Hash 160 Address' and which appear in this example under the field 'Hash 160' (e.g. the hex number a6c70c4a88205065c1d33b17c156137fa8c736c1) is a 20 bytes hash of the public key (specifically, it is the ripemd160 hash of the sha256 hash of the public key). These 20 bytes are essentially the same thing as what you call the 'Public Bitcoin address' (e.g. 1GCqcweZTwwe1w2RMWwwQMKSFgQzgFZQUb in our example). This bitcoin address is a 25 bytes number (usually displayed in Base58) which is linked to the hash 160 as follows:
address = [Version Byte (1)][Hash 160 (20)][Checksum (4)]

The version byte is simply 0x00 for the main bitcoin network and the 4 checksum bytes are simply the first 4 bytes of the double sha256 hash of the 21 bytes [Version Byte][Hash 160]
I attach a java snippet to illustrate some of the computations:
import org.bitcoinj.core.Address;
import org.bitcoinj.core.NetworkParameters;
import org.bitcoinj.core.Base58;
import org.bitcoinj.core.Sha256Hash;
import org.bitcoinj.params.MainNetParams;

class Test {
  public static void main(String[] args)
  {
    String  str = "1GCqcweZTwwe1w2RMWwwQMKSFgQzgFZQUb";

    NetworkParameters main = MainNetParams.get();

    // The string address is just a number expressed in base 58
    // Let us parse this string and see the bytes of the underlying number
    // 0:
    // -90:-57:12:74:-120:32:80:101:-63:-45:59:23:-63:86:19:127:-88:-57:54:-63:
    // -86:-114:24:124:
    byte[] full = Base58.decode(str);
    for(int i = 0; i < full.length; ++i){
      System.out.print(full[i]+ ":");
    }

    // Let us compute the hash 160 of the address
    //-90:-57:12:74:-120:32:80:101:-63:-45:59:23:-63:86:19:127:-88:-57:54:-63:
    // These are the same 20 bytes as before
    Address addr = Address.fromBase58(main, str);
    System.out.print("\n");
    byte[] hash = addr.getHash160();
    for(int i = 0; i < hash.length; ++i){
      System.out.print(hash[i]+ ":");
    }

    // Let us see the first 21 bytes of the address
    // 0:-90:-57:12:74:-120:32:80:101:-63:-45:59:23:-63:86:19:127:-88:-57:54:-63:
    byte[] decode = Base58.decodeChecked(str);
    System.out.print("\n");
    for(int i = 0; i < decode.length; ++i){
      System.out.print(decode[i]+ ":");
    }

    // Let us compute the double sha256 hash of the first 21 bytes of the address
    // and display the first 4 bytes: -86:-114:24:124:
    // These first 4 bytes are exactly the last 4 bytes of the address above
    byte[] check = Sha256Hash.hashTwice(decode);
    System.out.print("\n");
    for(int i = 0; i < 4; ++i){
      System.out.print(check[i]+ ":");
    }
  }
}

Thanks Sven, that's clear and understand the differences now.
Can you tell me why both are needed?
Also, are both transmitted in the transaction or is one just being calculated and displayed by the website I took the screenshot from?

The two things represent the same number, but they are both useful because on the one hand dealing with a bitcoin address gives us the security of having an embedded 4 bytes checksum (so we don't transfer money by mistake to something that isn't a valid address), and on the other hand, dealing with the Hash 160 only (20 bytes) is more efficient for the purpose of encoding a transaction. If you look at the actual bytes of a transaction encoding (with this address as output), you'll see that the 20 bytes of the hash 160 appear near the end (e.g. bitcoin-cli getrawtransaction <txid>)

Note that the leading version byte added to the address is also useful to prevent someone mistakenly transferring real money while attempting to test functionality on a bitcoin testing network.


text:
Get outpoint for a transaction
I'm trying to get the outpoint for a transaction but I don't find how to.
The pages here and here look like saying that the outpoint must have 36 characters, of what 32 are the TXID and 4 are the vout.
However I can't find any example or further information about how to get/calculate it. I'm trying with bitcoin-cli listunspent and it gave me:
[
    {
        "txid" : "4bbf676731987cce1e4639ec28d1219f065ab2aa5e9deb323c0b56bd0482d499",
        "vout" : 0,
        "address" : "1CfdQ5eHhPmUPemNStYmSG4RTYEq2Hc1a2",
        "account" : "",
        "scriptPubKey" : "76a9147ff792d99c99e5d89b8dbb54a5f962ccaeec404088ac",
        "amount" : 0.00100000,
        "confirmations" : 1866,
        "spendable" : true
    }
]

The txid is 65 characters long, and the vout is 1 character long (should I left-pad it to 4 characters? If yes, what happens after 10.000?)
Or I am not understanding anything? :s In this case, please provide me reliable and complete sources about this matter, as the docs seems to be very superficial about it.
I'm using bitcoin-cli.

The output returned by bitcoin-cli listunspent is correct. As mentioned in document, outpoint is pair of (txid, vout)
txid is 4bbf676731987cce1e4639ec28d1219f065ab2aa5e9deb323c0b56bd0482d499. Its is hexadecimal representation of a binary string and will take 32 bytes, each hex digit is representing 4 bits (or half a byte)
vout is 0 , this is stored as uint32 in the bitcoin block and will take 4 bytes. In other words it stored as an unsigned int binary representation of 32 bits.


text:
Blockchain.info handling gap of 20 unused addresses limit
I am looking for a way to handle the limitation of Blockchain.info, for which it will stop generating public addresses (or at least watching them) after 20 consecutive of them don't have any transaction.
I thought to initially generate many addresses (over the limit of Blockhain, using the gaps_limit parameter) and then reuse them more times, so that after some time there will not longer be gaps. But I am not sure if Blockchain simply can't watch too long gaps or can only watch 20 addresses at a given time.
Any suggestion? I am also open to other solutions.

Related: http://bitcoin.stackexchange.com/questions/48090/how-to-solve-blockchain-20-address-gap-limit-problem


text:
bitcoin wallet error
I have a problem I am unable to start my miners and unable to open my bitcoin wallet. when I try to open wallet I get
Program:C:\program Files\Bitcoin\bitcoin-qt.exe
File:chain.cpp,Line96
Expression: pindxWalk->pprev
Please can anyone help me
Thank you
brenerj

Related github issue: https://github.com/bitcoin/bitcoin/pull/7992 also https://github.com/bitcoin/bitcoin/issues/9170 and https://github.com/bitcoin/bitcoin/issues/9001 IRC log of similar issue: https://botbot.me/freenode/bitcoin-core-dev/2016-06-26/?msg=68636369&page=1

I think a bunch of people have had this problem, and so far nobody's come up with anything better than deleting the blockchain and resyncing.


text:
Why can't mining pools provide fake transactions within the generated blocks?
Suppose Alice wants to add a fake transaction where she receives X ammount of BTC. I understand that in order to add that transaction to the blockchain she would have to compete against all the other miners to generate the next block, which makes it improbable to happen as an individual against them.
Now, if we take a look at the next figure (taken from blockchain.info) which shows the mining pools with highest hash rate at the network:

we see that, for instance, the mining pool BTC.com has 26.4% hash rate of the network, and thus comes my question: Why can't all the miners at this pool make an agreement by adding fake transactions to all the blocks they generate? Differently than the previous case, where Alice was an individual with almost no chance to generate a an altered block, the pool could make it very likely.

Suppose Alice wants to add a fake transaction where she receives X ammount of BTC. I understand that in order to add that transaction to the blockchain she would have to compete against all the other miners to generate the next block, which makes it improbable to happen as an individual against them.

No, that isn't correct.  No matter how much mining power she has, or how many miners she cooperates with, she can't add a fake transaction to the blockchain.
It's a common misconception that miners are solely responsible for determining whether or not a transaction is valid, and if they say it is, then everyone else accepts it.  In fact, anyone who runs a Bitcoin full node (e.g. Bitcoin Core) is automatically checking whether each transaction is valid (spends money from a previous valid and unspent transaction, properly signed, etc).  If a miner attempts to include an invalid transaction in a block, this will be detected and their entire block will be ignored by everybody, effectively meaning that they don't get their mining reward.
With enough mining power, or the cooperation of a pool, Alice could create a block with her fake transaction.  But nobody in the world will consider it as valid or accept it as part of the blockchain.  If she tries to spend the proceeds of that transaction, say by sending those coins to Bob in exchange for some goods, Bob's software will simply ignore it.  He'll think that Alice just hasn't paid at all, and won't send her any goods.  So the whole exercise would be a giant waste of Alice's time and resources, without gaining her anything or harming anyone else.
The only special authority that miners have is this: if there are two or more otherwise valid transactions which are in conflict with one another, then miners get to decide which one (or none) goes into the blockchain, thus confirming it.  But they can't confirm a transaction that was never valid in the first place.
A large amount of mining power, or a pool, could help Alice perform a double spend attack, where a valid and confirmed transaction is later replaced in the blockchain with a different valid transaction.  The first one might have gone to Bob, who would have sent some goods, and the second one could effectively take the money back from Bob and return it from Alice, who now has the money and the goods.  But the second transaction is one that Alice could have created all along (of course she can send her own money to herself); it isn't "fake".

What do you mean by "if there are two or more otherwise valid transactions which are in conflict with one another". Also, i understand it know that the fake transaction would be invalid if they come from another account but, would that apply to altering the reward too? What would be the invalid part of this last transaction?

@jscherman: For example, say Alice has received 1 bitcoin.  She could create a transaction which sends it to Bob (spending the specific unspent output from the transaction sent to her).  Or she could create a transaction that sends it to Charlie.  Either of these by itself would be fine.  She could also create both, but only one of them can go in the blockchain, since the blockchain is forbidden to contain two transactions spending the same output.

If she puts both transactions on the peer-to-peer network, more or less simultaneously, then miners will decide which of the two gets confirmed; whether Bob gets paid or Charlie does.

@jscherman: Re your second question, in the case of a "coinbase" transaction which pays out a miner's rewards, one of the checks done by every full node is that the amount of the reward is appropriate given the reward schedule specified by the protocol.  If not, they consider the block invalid and ignore it.

If you mean to take an existing block and alter who the reward is paid to, this will be noticed because a hash of the transaction is (indirectly) in the block header. And if you change the header then the proof-of-work doesn't match and you'll have to redo the work to mine the block, so you don't gain anything.

This answer seems to reaffirm that btc.com cannot create fake transactions, but it begins with "everybody detects fakes immediately, hence none can be inserted". I think it would be very much improved if the mechanism by which fakes are detectable was explained.

@AnoE: I added some links where you can read more about the exact checks that are done.

What you need to understand is that, fundamentally, miners - and other nodes on the network - can broadcast whatever the heck they want. What matters is not what they broadcast, but what other nodes accept.
Full nodes verify that all transactions on the network are valid according to the protocol rules. And one of those protocol rules is that coins can't materialize arbitrarily. For a tx to be valid, its inputs must total at least as much as the outputs; and the inputs are either unspent outputs of previous transactions, or newly minted coins in the block's coinbase.
If the coins come from previous outputs, the transaction must be signed with the private keys corresponding to the owner public key hash. The miner can include as many "fake transactions" as it wants in the block, but without the appropriate digital signatures, no node will accept the block as valid, and no merchant will recognize that they have received coins for the purposes of offering a service.

One of the concepts that is fundamental to bitcoin is the concept "one-way functions", which allow the creation of a problem for which finding a solution takes massively more resources than checking whether a proposed solution is valid.
It's a bit unclear as to what you mean by "fake transaction". Transactions on the bitcoin network can be categorized into two groups. First, there are "reward" transactions, in which a miner simply declares that they have received a certain amount of bitcoin, out of nowhere, as a reward for completing a block. For this to be accepted by the network, they have to prove that they actually complete a valid block. The only interpretation I can think of for a "fake" reward transaction is for Alice to simply declare that she has been given a reward, without creating a valid block. She can then try to spend that reward by providing it to other people in exchange for goods and services. The recipient will then, presumably, check to see whether the transaction is valid. This is where one-way functions come in: anyone accepting bitcoin can efficiently check whether Alice's reward transaction satisfies bitcoin's validity conditions. Whether Alice's alleged "bitcoins" are worth anything depends on whether she can get anyone to exchange goods and services for them. If she can find someone who isn't bothering to check whether she has valid bitcoin, or is willing to accept whatever validity criterion she is proposing, then she will be able to "spend" her "bitcoin". But that isn't really an issue for the bitcoin network, any more than a casino getting people to accept their casino chips as "money" is an issue for the US dollar. Alice's "bitcoin" will be clearly distinguishable from "real" bitcoin by anyone running standard bitcoin software. What miners say is a valid bitcoin transaction is irrelevant: if you want someone to take your bitcoin, what matters is what they say is valid.
The other type of transaction is where the output a reward transaction is then transferred to another person, (or the output of a chain of transactions is transferred). So let's say Bob has perfectly valid bitcoins, and Alice wants to claim that Bob has transferred them to her. There are two main ways she can do this. One is she can just declare that Bob has done so, without any verification. This then puts her in the same situation as above. The other strategy is to fake the verification. This is where one-way functions come in again. Bob has a secret key that he uses to sign his transactions. Signing a transaction, if you know that key, can be done in polynomial time. Checking that a transaction has been signed can be done in polynomial time. But signing the transaction without the key cannot be done in polynomial time. So Alice is going to have to use an astronomically large amount of resources to fake the transaction. Even if she had all the computing power in the world, the probability of her finding a solution would for all practical purposes will be zero. She would be better off applying that computing power to mining real bitcoin.

Mining in Bitcoin is hard but not NP-complete.  While mining in Bitcoin is indeed a situation where it's easier to check the solution than to find it from scratch, NP-complete has a specific technical meaning, and Bitcoin mining doesn't qualify.

Just one question: say a miner adds a fake transaction between 2 persons. I understand know that the validation of this transaction will fail due it's wrong signature (we are supposing obviously that the sender wasn't the one signing the transaction). When does the validation get triggered? Is it that all nodes validate all transactions within a block when they receive one?

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


text:
PoW 51% attack vs. BFT 1/3 attack?
So from what I understand, Bitcoin's PoW is prone to 51% attack, but as a distributed system it is also prone to BFT's 1/3 attack right? I think it's mathematically proven that in a distributed system, if you have more than 1/3 bad nodes collaborate together, then you cannot safely reach a correct consensus no matter what?
So for Bitcoin, there are two types of possible attack scenarios, one is if a miner node consistently has more than 51% computing power of the whole network then it can double-spend indefinitely and basically has unlimited cash to spend.
The other is if more than 1/3 of the nodes in the whole network are bad guys working together with modified malicious node code then they can potentially stop the correct block being accepted and make it impossible for others to know which is the correct longest chain, thus prevent valid transactions being processed and recorded.
So are my understandings correct?

How would "the bad guys work together with malicious code"? The bitcoin network doesn't have a concept of nodes (no way to identify them), that's why there is proof of work.

JBaczuk, well, maybe they can spread thousands of malicious modified bitcoin client with zombie network or something? It's a P2P network, if you think the term "nodes" are not precise, then maybe "peers"? For example, if currently there are 1 million bitcoin clients running in this world, and 340 thousands of them are running malicious code, that means we will not be able to safely reach a consensus on what's the correct longest chain right? I think the Byzantine General's Problem applies to all distributed systems, bitcoin included, am I correct?

What would stop the other 660 thousand from accepting the longest chain?

BFT = Byzantine fault tolerance

So from what I understand, Bitcoin's PoW is prone to 51% attack, but as a distributed system it is also prone to BFT's 1/3 attack right?

No. Bitcoin is not a "consensus system" by any of the traditional definitions: It never reaches a state from which it can't, at least, theoretically roll back. In theory today's blocks could get undone years from now, but in Bitcoin the computationally difficulty of that increases over time.
As a result the impossibility results for consensus don't generally apply.

The other is if more than 1/3 of the nodes in the whole network are bad guys working together with modified malicious node code then they can potentially stop the correct block being accepted.

Nah. So long as an attacker does not manage to partition the graph of honest nodes, they could control (say) 99% of the nodes and the network would continue to run just fine. There isn't some magic threshold number of nodes where partitioning happens,  you need only have a single honest peer to be completely functional.

PoW and BFT solve different problems. A couple of differences:
BFT assumes the nodes (aka miners) are known in advance. PoW / Nakamoto Consensus allows anyone to become a node (miner).
BFT assumes nodes do not change over time. PoW / Nakamoto Consensus does not make this assumption.
BFT does not allow forks. PoW/NC allows temporary forks under normal situations (no one suddenly accumulates a lot of hash power). PoW/NC even allows someone to rewrite the entire history of Bitcoin back to block 1 if they could amass enough hash power.
It makes it hard to compare the two algorithms - it's like comparing an algorithm to find a number in a sorted list versus an algorithm for an unsorted list.

The Byzantine generals problem states For any m, Algorithm OM(m) reaches consensus if there are more than 3m generals and at most m traitors.
Also, When the majority of the actors which comprise the network decide on a single state, consensus is achieved. See Understanding Blockchain Fundamentals.
Bitcoin solves this with proof of work. The difficulty of the proof of work algorithm is periodically adjusted so that it will take 10 min for the network to finally calculate an acceptable solution.  When this solution is found, it propagates thorough the network, and any participating (non malicious) node will always accept the longest chain (the one with the most work done).
So, if more than 1/3 of the nodes are falsifying transactions, and doing the proof of work, on average the other 69% of computing power will outpace the attackers and always be able to generate a longer chain. It is essentially a race to solve the next block, that is why it takes more than 50% to successfully attack.
I strongly recommend reading Satoshis email and the Bitcoin Whitepaper

what if 1/3 of the nodes are malicious and just don't propagate the solution from their own miners, isn't there a risk that some other non-malicious nodes will never get the solution and get "trapped" in the network controlled by the malicious nodes? I mean, isn't the information propagation itself in a distributed system prone to the Byzantium Generals Problem?

If that happened, then 1/3 of the nodes would not be updated. The other 2/3 would be fine. That doesn't mean the network cannot continue and new nodes would not be able to join. You could still survey the network for the longest chain and find the "accepted truth". I'm not sure if we're talking about the same problem though, I think gmaxwell's answer is helpful, that Bitcoin is not a traditional consensus network.

The other is if more than 1/3 of the nodes in the whole network are bad guys working together with modified malicious node code then they can potentially stop the correct block being accepted and make it impossible for others to know which is the correct longest chain, thus prevent valid transactions being processed and recorded.

Miners on the network are extremely well connected (see: FIBRE relay network), so any number of malicious nodes will not be able to stop the relay of new blocks between miners.
For regular nodes, there could be a risk iff your node is connected to only malicious nodes. There are a couple of safeguards built in to help mitigate this, but it does remain a possibility nonetheless. See bitcoin.it for a good overview of Sybil attack risks and mitigation strategies.
If you are suspicious that you are being Sybil-attacked, you can force your node to connect to a peer of your choice. As an example a miner or well-trusted and publicly known peer may be a good choice. But this circumstance is rare, I’m actually unaware of any case of a user losing funds due to a Sybil attack.

I'm sure not what you mean, you seem to suggest that every miner is connected to every other miner? that means if there are 10000 miners, then each miner is connected to at least 9999 peers? I guess that the Byzantine Generals Problem doesn't apply if you can guarantee some sort of trusty connections between the good guys.

Miners broadcast blocks to each other using the FIBRE fast relay network. In general, individual miners will connect to pools, and those pools will connect to FIBRE. No number of malicious nodes joining this network would affect the already-connected miners. It isn’t a matter of there being enough ‘good guys’, it is simply that the raw number of nodes doesn’t matter, so long as all honest nodes aren’t completely partitioned from eachother.

I guess that's exactly what I'm saying? If there are trusty connections between the good guys, then Byzantine General Problem doesn't really apply. That's what FIBRE is from what you describe?

Generally yes, however FIBRE is only used by miners to relay new blocks info, so I just wanted to point out that for mining nodes it provides good connectivity. Non-mining nodes are also important, and don’t use FIBRE. As G. Maxwell answered above, even if 99% of nodes are malicious, having even just 1 honest peer is sufficient. The usual BFT rules that it seems you’re asking about don’t necessarily apply to the bitcoin system. There is no 1/3 threshold, for example.

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


text:
Any API to estimate the miner fee for a Bitcoin raw transaction?
Coming from the ethereum development scene, I guess I'm kinda spoiled by the availability of the web3 library which has easy access to the eth.gasPrice and eth.estimateGas methods to get the default gas price and gas limit for raw transactions. I'm wondering if there are similar APIs from the bitcoin clients like Bitcoin Core? So that given a particular transaction, there will be a fast and easy way to calculate a suggested miner fee for it? Thanks.

Fees in Bitcoin are actually a bit simpler than ethereum, you don't have to deal with gas costs, just a fee per byte.
Bitcoin Core includes an estimatesmartfee function. You can call it (estimatesmartfee 2, for example) and it will give you an idea of the fee rate you need to be confirmed in n blocks (2 in my example).
You can then check your tx size, which varies by number of inputs and outputs, and just multiply it by the fee rate to get your recommended fee, and subtract that from your change output.


text:
How to setup a Bitcoin private net that can simulate the public net?
I have some experience in Ethereum-related development and it was very easy to set up a private net with Ethereum that simulate the public main net, I just create a custom genesis block json config, then I can use it to set up half a dozen nodes to connect to a single bootnode, and voila I have a completely up and working private net which can perfectly mimic how the public main net works where I can mine ether and send transactions and wait for them to be mined in around 15 seconds, which is perfect for development and testing.
However when it comes to bitcoin it seems there's no easy way to setup a private net in a closed environment? I have searched around and the best I can find is use the regtest mode to connect multiple nodes, but there seems to be no way to simulate the real mining process, or do I really need to download the Bitcoin source and change some hardcoded settings and recompile my own version of (alt) bitcoin to just setup a private net?

What do you mean by "no way to simulate the real mining process"? You can mine on regtest.

@Andrew Chow, well from what I got from google results, it seems you just generate new blocks instantly in regtest mode, not really doing PoW mining to get a new block? Also the block confirmation is 100 blocks which is not the same as the public network. So are those info I see online incorrect?

It is still PoW mining, just the difficulty is extremely low. The difficulty also does not change. Otherwise, everything is the same as the mainnet. There is no such thing as "block confirmation". However there is coinbase maturity which is the number of confirmations for a coinbase transaction to be spendable from, and that is 100 blocks. This is the same for mainnet.

@Andrew Chow, okay I guess the online tutorials that I looked up messed up on the concepts of block maturity and transaction maturity, but still the mining mechanism seems different from mainnet, since it seems I'm not able to mine the regtest nodes with an older version of cgminer that still supports cpu mining?

cgminer relies on getblocktemplate which is not available unless your node is connected to another node. This behavior is the same for mainnet, testnet, and regtest. cgminer should work on regtest if you can connect another node. Of course it is going to mine blocks extremely quickly as the difficulty is extremely low and does not change.

I would recommend using the testnet of your desired client (bitcoin/litecoin etc.) with it's own genesis block and thus it's own blockchain. Configure the testnet parameters in chainparams.cpp to fit your desired outcome, compile it on a couple of nodes on your LAN and configure them to connect to each other in your config file (your/data/dir/.yourcoin) by appending the line connect=IPADDRESS:PORT
You will also want to make sure that you have DNS seeding disabled. Once you have done this you will be able to mine coins on the testnet, grow the chain and eventually depending on how you've set your parameters the network will retarget difficulty and work as if it were on the main network but you will be shielded from the outside world.

yup, I'm aware that I can compile from source to set up my private net, I'm just wondering if there's some easier where I don't need to deal with the source code to do it. If there's no better option then I guess I'll just have to recompile from source.

Yeah unfortunately you'll have to play with the source to get the outcome you desire. Also, don't forget to comment out the hard-coded seed nodes in chainparamsseeds.h and change the "magic number" values in chainparams.cpp under pchMessageStart. Good luck!


text:
Anyone know how to configure pybitcointools to bitcoin testnet?
Anyone know how to configure https://github.com/wizardofozzie/pybitcointools
to bitcoin testnet?
thanks,

There is blockr_fetch(txindex, "testnet") and blockr_push(signedTx, "testnet"). Note the need to use "testnet" as the 2nd parameter.
Reference

thank you Zombie, I will try. Would you please recommend a stable pybitcointools fork. I tried several already, can't find a stable one. or any python bitcoin tool you suggest to use?

you can look into this: https://github.com/petertodd/python-bitcoinlib and https://github.com/alexanderjsingleton/crypto-cuck-coin

@kiwichen also check https://github.com/mcdallas/cryptotools


text:
Is it possible to append new blocks to a block of arbitrary age?
First of all, I'm aware of 51% attacks and how they work.
Though, I was wondering, if Bitcoin and other blockchains allow appending cryptographically valid, new blocks to blocks of arbitrary age (if no age restriction is in place).
For example, could I simply append a new block to the genesis block or are there any other restrictions than just the validity of the block itself?
And if this is the case, would the "Bitcoin network" really accept a completely new blockchain starting from the genesis block, if I really managed to make a blockchain with higher difficulty, than the current chain? (Like a 99,999% attack :) )

For example, could I simply append a new block to the genesis block

Yes, you can. You can actually do this if you start your node offline and begin mining.

or are there any other restrictions than just the validity of the block itself?

There are, but only for legacy reasons. There are a set of checkpoints where, at a specified height, the block must have a specific hash. These were added to provide a performance boost, but have the side effect of locking in the blockchain to specific blocks. The most recent checkpoint is at block 295000. So unless you are able to find blocks that have the same hash at all of the checkpoints, you actually cannot produce an entirely different blockchain and have the Bitcoin network accept it.

And if this is the case, would the "Bitcoin network" really accept a completely new blockchain starting from the genesis block, if I really managed to make a blockchain with higher difficulty, than the current chain? (Like a 99,999% attack :) )

If you were able to produce such a blockchain and produce blocks which have the correct checkpoint block hashes (or if you forked the blockchain after the most recent checkpoint), then yes, the Bitcoin network would accept your alternative blockchain as it has more work.


text:
Hardware-dependent block difficulty?
Is it possible to make block production difficulty not the same for every node, but automatically adjusting to the node's hardware speed?
For example, node A and node B are both trying to solve for their next blocks, node A's hardware speed is twice that of B's. Their client software detect their hardware speeds and adjust the difficulty in such a way that B's next block's difficulty is only half that of A's.
Is this possible?

No, difficulty is a network-wide consensus rule. POW mining helps solve the issue of sybil attacks, whereas your idea opens up mining to sybil attacks:
Your idea would create a level playing field for all devices (regardless of computing power), so if I want to expand my mining operation, I would just want to run thousands of mining nodes. Hardware doesn't matter, so I could just use cheap computers, or better yet, a botnet. The more nodes I can make, the better!
Additionally, how can you be sure nodes aren't lying about the hashrate available to them? How can you be sure a user hasn't rewritten the source code of their client to artificially lower the difficulty? Etc.

Good point. Forgot that POW also guards against Sybil attack by simply requiring energy cost. However, couldn't we try to alleviate Sybil attack through other means? I foresee two possible ways:
a) Requiring every node to have validated a minimal number of transactions before being eligible to mine;
b) Each node must submit coins with a minimal amount of coin days in order to be eligible to mine.

The general idea is to shift he cost from energy consumption to somewhere else, something that is roughly equal for everyone, like real work done, time etc.


text:
Blockchain validation process is linear?
I've read at a few places that the nodes validate transactions in a linear fashion, i.e. after node A validates, then node B, etc. (which is also the reason, as claimed by many, why blockchain suffers from a scalability issue)
But if blockchain is decentralized, how would the nodes know in what global order to validate? It must be the case that several nodes validate on the same block in parallel.

Block validation is linear, transaction validation is not (for unconfirmed transactions).
Block N can only be validated if N-1 has been validated, since each block links back to the previous block, and the updates made to the UTXO set by it.
Transaction validation, for unconfirmed transactions, can be done in any order. However, nodes can only validate transactions if they receive them. Before any given node forwards a transaction to other nodes, it will validate it itself to ensure it is a valid transaction. If it is, it is sent further to its peers, who then repeat the same process before broadcasting it again.
That said, if you perform an out-of-band broadcast to multiple peers, they will all validate the transaction independently of what any other node says.

No, When you transfer token from your address to another then that transaction store in Mempool and from their miner decide to it should validate/process it or not. Like if you have set high Transaction fees then miner will pick your transaction first and put in next block and if transaction fees is very low then it may be take more time for validate.

Validation and confirmations are not the same. You can have outright invalid transactions that would never be mined. You can also have transactions included in a block that were never broadcasted


text:
Block verification time
Does block verification time (by all nodes in the network) takes up a large portion of the total block propagation time?
What is the percentage, on average?

It depends significantly if you're asking about the average, N-th percentile time, or a worst case including the possibility of maliciously constructed blocks.
Nodes use the first copy of a block they receive, obviously. A consequence of this is that block propagation along a slower path will be outpaced by block propagation on a faster path.  As a result, overall propagation time depends mostly on the behavior of fastest paths and there are many optimizations in the Bitcoin network to make the fastest paths usually quite fast.
On the vast majority of blocks >99% of the transactions in the block are known in advance and already validated. With validation already cached the only further validation required are trivial tests such as preventing double-spends within a block and verifying that block time/height are consistent with transaction lock-times.
On blocks consisting of known transactions relay among BIP152 HB-mode peers occurs without most of the validation (only POW and the hash root are checked, which takes under 1ms on a typical fast host). Similarly, fibre forwarding doesn't need to wait for validation (or complete reception, for that matter) even when many transactions aren't known in advance.
As a result on average the amount of time used for validation in propagation in the network today is probably closer to 0% than to 1%. I would expect based on data from matt's relay network that the 99.9th percentile would have a couple percent in validation.
In the worst case, however, no transactions would be known or already validated and, also in the worst case, a block could require minutes of processing to validate.  Fibre would still forward fairly quickly though still several times slower than typical due to the additional data needed.  In such a worst case situation the vast majority of the propagation time would be spent on validation, even where Fibre propagation is used (which doesn't need to wait for validation even when the data is unknown), just due the final receiving node's own validation.
This other answer may be of interest to you: https://bitcoin.stackexchange.com/a/80928/52021
The community has spent a fair amount of effort optimizing the non-malicious block case both because it was clear what needed to be done there and because providing equitable access to very fast propagation is essential to avoiding creating an advantage for larger miners.  Arguably, however, for many concerns the worst case performance is more critical.  Fibre makes some advance on the non-validation related worst case performance, and not making the worst case worse was a major design goal in segwit but the worst case remains a more difficult and somewhat less well addressed problem.

Thanks for this great answer. What is a maliciously constructed block?

A block that instead of processing normal transactions is stuffed full of transactions which are specifically created to be expensive for the network to deal with. For example, by containing transactions which were not previously relayed to eliminate caching gains, expensive script operations, or quadratic sig-hashing.

Maybe one advantage of having an optimal average case is that it makes the adversarial case stand out that much more? Everybody will very quickly know that something is up and take their precautions. There's no hiding in the noise or plausible deniability for the adversary. Even if he's still anonymous.

Great answer.  ">99% of the transactions in the block are known in advance and already validated." You mean they are already known by nodes that received them earlier? But a node that just received the block still need to validate all tx on it, right?  BTW, isn't it often claimed that blockchain scalability issue arises because all nodes need to verify all tx?

Most transactions are relayed on the network, received, and validated on most nodes before they end up in blocks. They don't need to be validated again except for trivial consistency checks. They all have to validate them, but usually they are no longer on the critical path for block validation.  Security depends on the worst case, however, which would be when they are not known in advance, so processing delays are still important but they're important even though on average they don't take any time during propagation.

@G.Maxwell, A rough idea to increase scalability, not sure if it will work: let the number of nodes to verify a tx depend on the number of past transactions between the two addresses within that tx. If the two addresses transacted a lot in the past (all verified transactions), the less number of nodes is required to verify their mutual transactions in the future.

@G.Maxwell, Let's say two addresses transacted a lot in the past, their next tx will only be verified by 20% of the nodes (or, for each node, their probability of verifying the tx is 20%). If this time their tx become malicious, the protocol will ask the 20% verifying nodes (after finding out the tx is indeed malicious) to send msg to the remaining 80% nodes to start verifying on that tx.  They will drop that tx or blocks containing that tx, thus ensuring security.

@G.Maxwell Do you think the idea will work? I think it will and Bitcoin should implement it. If not, I might create a startup doing that. :)

Attacker spins up 1,000,000 'nodes', and as a result any 20% you select will almost always be attacker nodes.  If that sort of thing worked there would be no reason for mining in Bitcoin at all.

@G.Maxwell The PoW mining part still exists and remain the same, only the subsequent process of transaction verification is modified. The problem you mention also exist in other layer-1 scalability solution such as Sharding. It is highly unlikely that ALL 20% is malicious. Even if there is one non-malicious node checking it and found fault it will tell to others to verify it (if they not done it before), spreading throughout the network.

@G.Maxwell Also, if an address is involved in one malicious behaviour the next time they appear in another transaction, the number of nodes required to verify it quickly escalates to, say 95%.


text:
C-Lightning update 0.6 doc
How do you update safely to 0.6 the working C-Lightning node?

Possible duplicate of What is the proper way to update C-Lightning?

You should be able to just stop the old version, download the new binaries, unpack them, and run them. On the first start lightningd will take care of updating the database if necessary and
Alternatively you can also compile the binaries yourself, like you did before the release:
git clone https://github.com/ElementsProject/lightning.git /opt/lightning
cd /opt/lightning
./configure --disable-developer --disable-valgrind
make
sudo make install

Afterwards lightningd and lightning-cli will be in your $PATH and available from everywhere.

thanks for the answer! I would like to keep my existing data/config. Will I keep them following the steps you wrote above?

Yes, the database is migrated to the new version automatically, and you should not have to change anything. The one exception may be if you have --addr in the commandline or addr in the config, that option got split into bind-addr and announce-addr.

thank you!
however a problem has occurred when making the source:
gossipd/gossip.c: In function ‘find_local_update’:
gossipd/gossip.c:1702:7: error: implicit declaration of function ‘structeq’ [-Werror=implicit-function-declaration]
if (structeq(scid, &i->scid))
^~~~~~~~
cc1: all warnings being treated as errors
: recipe for target 'gossipd/gossip.o' failed
make: *** [gossipd/gossip.o] Error 1
what do you think the problem could be?
thank you in advance!

version: GNU Make 4.1

ok so the problem is that structeq was updated 3 days ago and the code was not updated in gossip.c file... actually the header file hasnt even been included


text:
Issue with getrawtransaction txindex and reindex
I am running Bitcoin Core Deamon version v0.16.0.0 on Ubuntu and need to call the getrawtransaction command for some TX.
To use the getrawtransaction I need to run bitcoin core with txindex=1.
But if I am running with txindex=1 it says that I have to run the core with reindex or reindex-chainstate.
So I did run first
bitcoind -reindex-chainstate
and then
bitcoind -txindex=1 and it still says that I have to run with reindex or reindex-chainstate.
So I tried to run
bitcoind -txindex=1 -reindex-chainstate  but still says run it with reindex or reindex-chainstate.
Now I am running bitcoind -txindex=1 -reindex
Is this the correct way? And is it normal that bitcoin-cli getblockcountis stuck on 0?

txindex=1 has to be added in the bitcoin.conf file.
When starting the node, the following command should be issued
bitcoind -reindex=1 -daemon

You can keep checking the debug.log file in the .bitcoin folder to see the progress of blockchain synchronisation
Until you have downloaded the entire blockchain and reindexed, getblockcount will keep returning 0.

Thank you for your answer. Is ist really necessary to add txindex=1in the bitcoin.conf file or is it also sufficient to run bitcoind with txindex=1 parameter?

adding it to conf file makes sure it will reindex everytime it syncs. In case you forgot to add the reindex option while starting bitcoind.


text:
How exactly do transactions work?
When I search for transaction in bitcoin I am able to find explanations which tell me that there are e.g. two persons A and B and A wants to tranfer a number of bitcoin to B. Imagine A wants to pay 2 Bitcoin to B and owns an private key for 1.5 Bitcoin and 1.3 Bitcoin.
First Question: private key for what exactly? What is signed/encrypted with a public key - which system validates that I am a private key owner? (I don't need explanations for public key cryptography RSA, ElGamal and GMR are well known to me)
Now these two amounts of bitcoins are taken by a system X (what is X?) and it will be created an output with amounts 2 Bitcoin (i) and 0.8 Bitcoin (j). Where will the public and private keys for i and j are generated? How and from which holder (after generation) to which (new owner) will they be transmitted? What kind of message do they sign/encrypt (content).

First Question: private key for what exactly?

For the scriptPubKey that locks/encumbers the coins from being able to be spent.

An output contains instructions for sending bitcoins. Value is the number of Satoshi (1 BTC = 100,000,000 Satoshi) that this output will be worth when claimed. ScriptPubKey is the second half of a script (discussed later). There can be more than one output, and they share the combined value of the inputs. Because each output from one transaction can only ever be referenced once by an input of a subsequent transaction, the entire combined input value needs to be sent in an output if you don't want to lose it. If the input is worth 50 BTC but you only want to send 25 BTC, Bitcoin will create two outputs worth 25 BTC: one to the destination, and one back to you (known as "change", though you send it to yourself). Any input bitcoins not redeemed in an output is considered a transaction fee; whoever generates the block can claim it by inserting it into the coinbase transaction of that block.

See https://en.bitcoin.it/wiki/Transaction#Output.

which system validates that I am a private key owner?

When transactions are submitted, nodes on the network validate the signature with the scriptPubKey before including them in their mempool for miners to include in the next block.

Now these two amounts of bitcoins are taken by a system X (what is X?) and it will be created an output with amounts 2 Bitcoin (i) and 0.8 Bitcoin (j).

The transaction is created and signed using wallet software, and the transaction is submitted to the nodes on the network, it is propagated to all nodes (given it passes the validation checks).

Where will the public and private keys for i and j are generated? How and from which holder (after generation) to which (new owner) will they be transmitted? What kind of message do they sign/encrypt (content).

The private keys are generated by the user usually in their wallet software and usually the pubkey and scriptPubKey (which is encoded into an address) are also created by the user for people to send them Bitcoin. The message that is signed is the new transaction data itself.

Okay, let me call "all nodes" "system X" now how does X do it? I know what proof of work is and also know that a number of transactions are included in a block and the block is validated by users/nodes adding further blocks - which leads to the longest chain of blocks...

I just read about ScriptPubKey spk and ScriptSign ss - so spk signs the output and with ss a user can unlock it to spend it - are both created by user A in my example? Is there independently another public key mechanism to show ownership? If yes, what actions does which of the systems take/secure. The ScriptSigns for each output are transmitted directly from one user to the next/the new owner (email/letter...)?

Just updated with more detail about the wallet software, which handles the creation of keys, transactions, and transaction signing. In your example, the coins that user A owns are encumbered by a scriptPubKey that was created by user A and received a transaction previously. Ownership is determined by providing a scriptSig that matches the scriptPubkey (which usually is a cryptographic signature, but doesn't have to be). The scriptsigs are added to the transaction data which is broadcast to the network via nodes.

of course! have fun learning more!


text:
How come Merkle tree is more efficient when tree branches are not stored in blockchain?
Suppose we have 8 transactions in a block X as follows and we know every node's hash value of the whole Merkle tree (that is, including intermediary nodes such as 45). Then if someone claims transaction t exists in X and it's located at 6. To verify this, we only need to look up hash values at 7, 45, 0123 and hash up to the top and compare with Merkle root 01234567.
I assume (based on this) Merkle tree is faster than hashing the concatenation of TXID0 ~ TXID7 directly is because hash algorithm runs faster on small files (even run it ~log(N) times) than on a large file (i.e., concatenation of N TXIDs, N is 8 here) at one time.
But reading this post, it seems that only Merkle root and N TXIDs are stored in a block and we have to recreate tree structure every time we verify a transaction, which would actually run hash functions ~N times instead of ~log(N) times (if I was correct mathematically).

My questions are:

Does hash ~N times  still faster than hash one time on N
  concatenated hash values?
Why is Merkle tree not stored? Is it due to storage consideration?

The speed of the hash is roughly linear in the number of bytes processed: SHA2 processes block of 64 bytes at a time, and the time taken is equal to the number of blocks processed.  Computing a hashtree processes more blocks due to the intermediate levels but almost all the processing can be done in parallel unlike the linear hash which must be done sequentially.
A node only verifies a block once.  For that purpose it doesn't matter much if the hash is a tree or linear though if the parallelism is exploited computing a tree hash is faster.
[And Bitcoin Core uses vector instructions to processes tree hashes in parallel for a several times speedup. It doesn't currently bother using multiple cores for that, though it could.]
A lite client, however, does not validate a whole block, it normally doesn't even fetch a whole block.  Instead, it wants to know if a transaction is in a block.  Here, the hash structure matters a lot. If a linear hash were used the only way to prove that a transaction is in a block to a lite client would be to send it the whole block.  With a tree hash one need only send it log2(n) values and the transaction itself.
The tree isn't stored in current Bitcoin implementations because there is no operation that would really benefit from it being stored in the implementations. Proving a lite client was paid is a relatively infrequent operation and recomputing the hash tree is inexpensive. An implementation could start storing it if it had a reason to do so.  TXIDs aren't stored either as they can just be computed from the transactions themselves.


text:
List All the transactions of an adress - API
I am looking for a way to list all the transactions of an address. For instance, if we use the Blokchain.info API we get:
url='https://blockchain.info/rawaddr/1PFtrRjbq4aLfM7k4tyLZ3ZAuTsgLr6Q8Q'
request=requests.get(url)
addr=request.json()

Total number of transactions that have ever been made:
addr['n_tx']
69990

Now if we want to access to the list of these transactions:
addr['txs']

We get a list of transactions that have been by this address, but when we check the lenght of this list to see how much transactions we got:
len(addr['txs'])

we find 50.
With Blockexplorer API, we can have up to 1000 transactions for an adress.
I have tried some other API like SoChain, still the same issue (only 50 transactions).
Do you know a way to have access to all the transactions given an adress - just the list of their hashes - (in our case it is 69990) ?
I do not want to download the blockchain because I just do not have enough space for it.
Thank you !

All of these APIs allow paginations, so you can get 1 page of 50, then another of 51-100, then 101-150 and so on.

The issue is that the API call rate limit is very strict, so in order to build the list of transactions since the genesis block will take a lot of time..

Yes, but you only need to do it once. Spend a day or so pulling in all that data, then save it locally. Once you have that, you just need to check from the last block you have locally. Also, I don't think they are that strict. 70k txs should be easily retrievable in a few hours.


text:
How does the p2p network monitor the validity of a transaction?
In Bitcoin, in order for a transaction to be added to the pool of valid transactions that will be added to the chain block by the miners, at least 51% of the nodes/peers need to review that transaction and see that the public key issuing it A) has the funds to issue it, and B) has not spent them in another transaction.

Does anyone know how the peers network actually keeps track of that validation evolution?
Does each peer individually review the transaction and then send the result (valid or not) somewhere, and in this somewhere the count is made until reaching 51%?
Or does each validating peer somehow know about the validation result of other peers?
How does the system know when the 51% is reached? Isn't for that required to know the total number of nodes in the network? How can this be if each node is just connected to few peers?

I cannot somehow come up with an answer that does not imply a server knowing ALL the peers in the network...
Thank you very much for your help

in order for a transaction to be added to the pool of valid transactions that will be added to the chain block by the miners, at least 51% of the nodes/peers need to review that transaction and see that the public key issuing it A) has the funds to issue it, and B) has not spent them in another transaction.

This is incorrect, there is no requirement for a certain number or percentage of network peers to review or validate a transaction before it is included in a block. A transaction is either valid, or not.
Validation is done at the scale of each individual node: each node can validate a transaction on its own, and know that it is valid, without relying on any other node to confirm this info for them. An overview of the transaction validity rules can be found here.  Only valid transactions can be included in blocks, so miners will validate transactions before including them in a block they are mining. Including a non-valid transaction would make the block invalid, so miners are incentivized to make sure they only include valid transactions.
In fact, miners can include transactions that were not broadcast to the network first, so that the rest of the network will first hear about the transaction when they receive that miner's new block (assuming the miner finds a valid block, of course). As long as the block is valid (which requires all transactions to be valid), this is just fine, no 51% majority is needed.

To clarify, miners are responsible for finding new blocks. Miners do run nodes, but common terminology is to refer to a non-mining node as a ‘node’, and a mining node as a ‘miner’. Once a miner finds a block, they broadcast it to all other miners and nodes. Each individual in the network will check the validity of the block (and as part of that, its transactions), and then append it to their local copy of the blockchain. Invalid blocks will be dropped from the network, the same goes for invalid transactions.

Thank you very much for your detailed answer, chytrik. If a node takes a particular transaction, packs it into a block and makes it to append the block to the blockchain, then the new blockchain will just be updated in all other ledgers, without actually all those other nodes checking the validity of the transactions within the block? Or will they? In this case, how do we prevent a malicious node to include an illegitimate transaction into the network? Or do actually all other nodes that get the updated Blockchain also check the validity of the transactions in the new added blocks?

Ok Chytrik, thank you very much. Now I got it


text:
Link to Algorithmic behind signatures verification
Does anyone know a good paper where the process of signature verification is explained (message+signature+public key = valid/not_valid) ??? And I mean it at a low level, with the code or pseudo-code of the algorithms doing the verification or similar. All sources I have found explain it with the verification process being pretty much a black box.
I know StackExchange is not the place to ask for references, but I haven't found what I am looking for, so someone might now a good source...
Thank you all in advance. Cheers

Signature generation:
xRandSignPoint, yRandSignPoint = EccMultiply(Gx,Gy,RandNum)
R = xRandSignPoint % N
S = ((HashOfThingToSign + R * privKey) * (modinv(RandNum,N))) % N

Signature verification:
w = modinv(S,N)
xu1, yu1 = EccMultiply(Gx,Gy,(HashOfThingToSign * w)%N)
xu2, yu2 = EccMultiply(xPublicKey,yPublicKey,(R * w)%N)
X,Y = ECadd(xu1,yu1,xu2,yu2)
if R == X:
    print "Signature verified"

EccMultiply – elliptic curve point on scalar multiplication.
ECadd – elliptic curve 2 points addition.
Here is the original source.


text:
Account extended private key vs BIP32 extended private key
I would like to know which is the difference between Account extended private key and BIP32 extended private key. I was creating Mnemonic seeds (https://iancoleman.io/bip39/) and I stopped because I could not find out the difference

Does this answer your question? What can I do with Account Extended Private Key and Account Extended Public Key?

BIP 32 extended private key is a more generic term that refers to any private key that is derived and serialized according to BIP 32.
Account extended private key is the BIP 32 extended private key at a specific derivation path. This is described in BIP 44. For P2PKH Bitcoin addresses, this derivation path is m/44'/0'/0'.

OK, so them, which is the difference between Account extended private key and BIP 32 extended private key in the ian coleman example, in which level will be the BIP32 extended private key?

On the Ian Coleman site, Account Extended Private key is the private key derived at the account derivation path. BIP32 Extended Private Keys are the child private keys that you ultimately use.


text:
Bitcoin peer info
Why when I run in the node bitcoin-cli getpeerinfo the list is an empty array? Do I need to let time to connect other peers?

bitcoind should connect to other nodes within a few minutes. If it is connected to even one node bitcoin-cli getpeerinfo will return an array with connected nodes. If your array is empty, your node likely isn't connected to the internet.


text:
Mixing some concepts with encodings
Is it some difference between psbt hex and transaction hex or both of them are the same? I guess the psbt format is in base58 and the raw transaction and transaction id is in hex format. So before broadcast to the network what a wallet do internally is encode the psbt string to hex format and after broadcast. Is it that correct?

AFAIK, base58check is only used to encode addresses and keys.

So before broadcast to the network what a wallet do internally is encode the psbt string to hex format and after broadcast. Is it that correct?

The network format is binary, not hex.
That means the number twenty could be sent as a single byte not as two bytes of ASCII data showing the hexadecimal representation "14".
Encodings like decimal, hex and base58 are intended for presenting numbers to humans, not for transmission between computers. Though things like XML and JSON may confuse the issue.

Addendum:
Internally the wallet will store the PSBT in some binary structure native to the development language and platform, it will serialize it to a standard network binary serialization and then encode it as Hex to show to you on screen. When transmitting it will serialize the internal binary representation but not encode it as hex, just transmit the network binary serialisation format.

ok, that make sense! So them the final piece that we broadcast is binary but before of that, we have to create a tx. In that creation, the first piece would be PSBT, after that one converted to hexadecimal format for human reability which it calls serialised transaction. Finally, when we broadcast, the wallet (in my case sparrow) will do that conversion to binary.

Internally the wallet will store the PSBT in some binary structure native to the development language and platform, it will serialize it to a standard network binary serialization and then encode it as Hex to show to you on screen. When transmitting it will serialize the internal binary representation but not encode it as hex, just transmit the binary serialisation format.

thanks for your time! now makes sense ;)


text:
Partially signed bitcoin transactions
Is the psbt data format the only way to exchange information about the Bitcoin transaction or is there another way to do it?

The PSBT format is especially used to exchange information about incomplete transactions, e.g. ones that are still being assembled or have only been signed by a subset of the transaction authors. There are a number of other exchange formats that were in use before PSBT was proposed, e.g. created by wallet services and hardware signing device manufacturers to communicate between their hardware devices and their software wallets.
Once a transaction is fully signed, the most common format you’d encounter would likely be the serialized transaction format used in recording transactions on the blockchain.


text:
How to send bitcoins without the bitcoin client in PHP
Is there a way to send bitcoins programmatically without the bitcoin client using PHP?

You will need to connect to a bitcoin node in one way or another to broardcast to the newtork.  There are a number of php and bitcoin open source repos that will do this, have a look here https://github.com/search?q=bitcoind+php&ref=cmdform
Another option if you do not want to run the bitcoin client locally is to connect to an api to broadcast your transaction.
An example I found for php connecting to blockchain.info is as follows
<?php

$guid="GUID_HERE";
$firstpassword="PASSWORD_HERE";
$secondpassword="PASSWORD_HERE";
$amounta = "10000000";
$amountb = "400000";
$addressa = "1A8JiWcwvpY7tAopUkSnGuEYHmzGYfZPiq";
$addressb = "1ExD2je6UNxL5oSu6iPUhn9Ta7UrN8bjBy";
$recipients = urlencode('{
              "'.$addressa.'": '.$amounta.',
              "'.$addressb.'": '.$amountb.'
           }');

$json_url = "http://blockchain.info/merchant/$guid/sendmany?password=$firstpassword&second_password=$secondpassword&recipients=$recipients";

$json_data = file_get_contents($json_url);

$json_feed = json_decode($json_data);

$message = $json_feed->message;
$txid = $json_feed->tx_hash;

?>

Hope this helps
UPDATE: To run requests to the blockchain.info API you need to follow the setup instructions here https://www.blockchain.com/api/blockchain_wallet_api
NOTE To use this API, you will need to run small local service which be responsible for managing your Blockchain Wallet. Your application interacts with this service locally via HTTP API calls. Click here for complete setup instructions on GitHub.

I'm getting NULL as response
And when trying with the url in browser:
blockchain.com/merchant/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx/sendmany?password=xxxxxxx&recipients=1G2muzzGkogHKGCTi5MJeXQVDiArALmjoP+600
I'm getting the error message:
"We can't seem to find the page you're looking for"

It seems that you do need to run a service locally to get the blockchain API up and running https://www.blockchain.com/api/blockchain_wallet_api Need to setup this https://github.com/blockchain/service-my-wallet-v3


text:
What informations are contained in a transaction?
According to the informations that i found here: https://en.bitcoin.it/wiki/Transaction
a bitcoin transaction contains,
FOR EVERY INPUT:

The Hash of the incoming transaction
ScriptSig

FOR EVERY OUTPUT:

Value
ScriptPubKey

Now my question is: what kind of informations are implicitly contained in the ScriptSig? I know that from ScriptPubKey the destination address can be calculated, but i don't see if any other information can be retrieved from the ScriptSig.
Furthermore, if only the hash of the incoming transaction is stored, how does a node look for the incoming transaction on the blockchain, when it needs to validate the new transaction? And how does it know in which block that transaction is included?
If it doesn't know in which block that transaction is, does it have to skim through the whole blockchain just for finding it?

Your last paragraph is a separate question and should go in a separate post.  But it's already been addressed, e.g. at http://bitcoin.stackexchange.com/questions/13731/does-a-bitcoin-node-need-to-scan-through-the-whole-blockchain-in-order-to-be-100 (see also comments to answer). A full node has already indexed all transactions in the block chain by their hash (txid), so it can find any given transaction without rescanning the whole chain.

thank you @NateEldredge. is there a specification on how this indexing is made?

It's an implementation detail of the node client software.  For Bitcoin Core, you can see https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):Data_Storage#The_UTXO_set.28chainstate_leveldb.29

so that means that when a full node indexes the blockchain it also calculate the hash of every transaction?

Yes, that's correct.

What data is in scriptSig
scriptSig in a typical p2pkh scenario, which is the vact majority of bitcoin transactions, only contains the public key of the scriptPubKey hash as well as the signature. This means there's no metadata other than the public key and the signature for authorizing the payment.
For non-p2pkh transactions, such as for example p2sh transactions, more data is included in the scriptSig. For example in p2sh multisig, the multiple public keys capable of authorizing the multisig will be revealed. In even more complicated scripts, the scriptSig may reveal significant information, depending on what the scriptPubKey script is requesting. For example, there are snowflake transactions that require scriptSig to be solutions to certain puzzles. However, these transactions are very rare.
How transactions are validated
There are multiple security models in validating a transaction. Transaction validation is a different notion from transaction confirmation which you are talking about. Transaction validation asks whether a transaction is valid – for example, it is of the right format, it follows Kirchhoff's Law (i.e. sum of outputs is less than sum of inputs), and the outputs it spends have not been double spent. Validating a transaction requires access to the current UTXO.
Transaction confirmation on the other hand validates that a transaction has been buried under a certain amount of proof-of-work, for example k = 6 blocks. Checking the confirmation status of a transaction does not require traversing the whole data in the blockchain. It only requires looking at the blockchain headers.  In the SPV security model, the transaction confirmation status is checked simply by checking that it was included in a block and buried under a certain amount of proof-of-work. This is done quickly without looking at the whole blockchain data (but just all of the blockchain headers) by providing a proof-of-inclusion which consists of Merkle tree path siblings.

ok i understand how merkle tree works. but how does a node, that wants to check if a certain input for a transaction is still unspent, know in which block that transaction was if the only information provided is the hash of the transaction?


text:
solving subset sum for two sets
Some bitcoin transactions (especially CoinJoin transactions) include two or more sub-transactions. for example, consider a transaction with
Inputs = [2, 3, 4] and
Outputs = [4, 5].
In this example, we have two sub-transactions:
(2+3 = 5) & (4 = 4)
so it is a kind of subset sum problem but for 2 sets, inputs and outputs.
I want to know how to solve subset sum for this specific problem. I know it needs a brute force, but don't how to optimize it? I don't know how to run a brute force either.

related: Maurer et al -Anonymous CoinJoin Transactions with Arbitrary Values (PDF)

this article is totally related and here I used its terminology but it didn't explain how to brute force

It does explain and provide pseudocode: Listing 1: Algorithm for finding valid partitions

Resources

Anonymous CoinJoin Transactions with Arbitrary Values
 discusses the optimized and non-optimized version of it. In this reply I will discuss the non-optimized version of it.
CoinJoin Sudoku may also be something to look up.

Tooling
I wrote a small command line tool in .NET Core that anyone can play around with. You can either provide an input and output list to it or a real txid. In case of txid, it will fetch the transaction from SmartBit and analyze that.
Provide inputs or transaction ID! Example: 21,12,36,28.1 or 0f9f3b68f369b3b95779284d4d0607cb8f5051055c2e1b1813848370496e95aa
21,12,36,28.1
Provide outputs! Example: 25,8,50,14.1
25,8,50,14.1

Given 21,12,36,28.1 input list, and 25,8,50,14.1 output list the tool will output 2 sub mappings:
Sub mappings:
21,12,36,28.1 -> 25,8,50,14.1
21,12 -> 25,8 | 36,28.1 -> 50,14.1

The first sub mapping (21,12,36,28.1 -> 25,8,50,14.1) is the transaction as it appears in the blockchain, it is called the non-derived mapping. This is the case if the transaction wasn't a coinjoin to begin with.
The second is a derived mapping (21,12 -> 25,8 | 36,28.1 -> 50,14.1). In this case it was a coinjoin with 2 participants, as 2 sub transaction has been identified.
However there is another important analysis that can be done on this coinjoin. We can tell what is the probability of two inputs or outputs are in the same transaction:
Input match probabilities:
21 - inputs: 12(1) 36(0.5) 28.1(0.5) | outputs: 25(1) 8(1) 50(0.5) 14.1(0.5)
12 - inputs: 21(1) 36(0.5) 28.1(0.5) | outputs: 25(1) 8(1) 50(0.5) 14.1(0.5)
36 - inputs: 21(0.5) 12(0.5) 28.1(1) | outputs: 25(0.5) 8(0.5) 50(1) 14.1(1)
28.1 - inputs: 21(0.5) 12(0.5) 36(1) | outputs: 25(0.5) 8(0.5) 50(1) 14.1(1)

Output match probabilities:
25 - inputs: 8(1) 50(0.5) 14.1(0.5) | outputs: 21(1) 12(1) 36(0.5) 28.1(0.5)
8 - inputs: 25(1) 50(0.5) 14.1(0.5) | outputs: 21(1) 12(1) 36(0.5) 28.1(0.5)
50 - inputs: 25(0.5) 8(0.5) 14.1(1) | outputs: 21(0.5) 12(0.5) 36(1) 28.1(1)
14.1 - inputs: 25(0.5) 8(0.5) 50(1) | outputs: 21(0.5) 12(0.5) 36(1) 28.1(1)

For example input with value 21 and input with value 12, there's 100% chance they are in the same sub-transaction, however input 21 with output 50, there's only 50% chance that they are in the same sub-transaction.
Example 2: Output for 2,3,4->4,5
For completeness here's the output for the numbers that were present in the question.
Sub mappings:
2,3,4 -> 4,5
2,3 -> 5 | 4 -> 4

Input match probabilities:
2 - inputs: 3(1) 4(0.5) | outputs: 4(0.5) 5(1)
3 - inputs: 2(1) 4(0.5) | outputs: 4(0.5) 5(1)
4 - inputs: 2(0.5) 3(0.5) | outputs: 4(1) 5(0.5)

Output match probabilities:
4 - inputs: 5(0.5) | outputs: 2(0.5) 3(0.5) 4(1)
5 - inputs: 4(0.5) | outputs: 2(1) 3(1) 4(0.5)

Background
Our basic building block is partitioning, so in order to understand the algorithm you must understand partitioning first.
While understanding what the Bell Number is, not essential to understand the algorithm, it is essential to understand the limitations of this algorithm.
Definition of Bell Number
The Bell Number is the number of partitions of a set.
Examples
Empty Set
Set:

Partitions:

Bell Number: 1
Set with 1 element
Set:
a

Partitions:
a

Bell Number: 1
Set with 2 elements
Set:
ab

Partitions:
ab
a b

Bell Number: 2
Set with 3 elements
Set:
abc

Partitions:
abc
ab c
ac b
bc a
a b c

Bell Number: 5
All Bell Numbers
1, 1, 2, 5, 15, 52, 203, 877, 4140, 21147, 115975, 678570, 4213597, 27644437, 190899322, 1382958545, 10480142147, 82864869804, 682076806159, 5832742205057, ...

Application to CoinJoin
Given a transaction with 100 inputs, assuming brute forcing, one would need to iterate through Bell Number of 100 elements number of partitions in order to find valid partitions. The Bell Number of 100 elements is 47585391276764833658790768841387207826363669686825611466616334637559114497892442622672724044217756306953557882560751.
Non-Optimized Algorithm
First we need to iterate through all the input and output partitions.
foreach (var inputPartition in inputPartitions)
{
    foreach (var outputPartition in outputPartitions)
    {

Then we need to iterate through all parts of the input partition and find out if we have corresponding output partition part:
foreach (var inputPartitionPart in inputPartition)
{
    var foundValidOutputPartitionPart = remainingOutputPartition.FirstOrDefault(x => x.Sum() == inputPartitionPart.Sum());

If we find such valid output partition part, and we also only find valid parts when comparing the remaining parts, then we found a valid mapping.
The Code
For reference the relevant codeblock looks like this. You may notice I made some optimizations to make it less painfully stupid.
var outputPartitions = Partitioning.GetAllPartitions(outputs.ToArray());
var inputPartitions = Partitioning.GetAllPartitions(inputs.ToArray());

foreach (var inputPartition in inputPartitions)
{
    foreach (var outputPartition in outputPartitions.Where(x => x.Length == inputPartition.Length))
    {
        var remainingOutputPartition = outputPartition;
        var validPartition = true;
        var subSetsBuilder = new List<(IEnumerable<decimal> inputs, IEnumerable<decimal> outputs)>();
        foreach (var inputPartitionPart in inputPartition)
        {
            var foundValidOutputPartitionPart = remainingOutputPartition.FirstOrDefault(x => x.Sum().Almost(inputPartitionPart.Sum(), Precision));
            // https://www.comsys.rwth-aachen.de/fileadmin/papers/2017/2017-maurer-trustcom-coinjoin.pdf
            // input partitions that include a set
            // with a sum that is not a sub sum of the outputs cannot
            // be part of a mapping
            if (foundValidOutputPartitionPart is null)
            {
                validPartition = false;
                break;
            }
            else
            {
                subSetsBuilder.Add((inputPartitionPart, foundValidOutputPartitionPart));
            }
        }

        if (validPartition)
        {
            var mapping = new Mapping(subSetsBuilder, Precision);
            mappings.Add(mapping);
            yield return mapping;
        }
    }
}

Discussion
Notice this approach has a benefit compared to the optimized version, that it does not use recursion.


text:
Why prices are different in different fiat currencies on the same market?
What I noticed is that prices in different fiat currencies on the same market for the same crypto currency are different. But what are the reasons behind that? Does it has anything to do with market volume for the fiat currencies? What variables I need to know to predict the difference in prices?
Few examples:
1) Cexio.
BTC/USD: 6286 USD (~4749 GBP)
BTC/GBP: 4787 GBP (~6336 USD)
Price in GBP tends to be higher (currently it's +0.8%).

2) Kraken.
BTC/USD: 6263 USD (~4732 GBP)
BTC/GBP: 4743 GBP (~6277 USD)
Price in GBP tends to be highter (currently it's +0.2%).

BTC/USD: 6263 USD (703.5k JPY)
BTC/JPY: 697.2k JPY (6206 USD)
Price in JPY tends to be lower (currently it's -0.9%).

BTC/USD: 6269 USD (~5363 EUR)
BTC/EUR: 5373 EUR (~6280 USD)
Currently price is higher in EUR (+0.2%). But it changes from time to time. Sometimes price is higher in USD. Why?

Because they are different markets. Each trading pair is its own market with its own supply and demand. Each has its own set of orders and traders. It is the same reason that different exchanges have Bitcoin at different rates: they are independent of each other.

USD on Kraken is worth more than USD on cex.io, so you don't need quite as many of them to buy a bitcoin.
Suppose you have a choice to have one USD on either Kraken or cex.io. Which would you rather have? There are a lot of factors you would take into account:

How reliable is the exchange? How likely are they to go out of business and not be able to get you your money?

How much do they charge to withdraw your dollars? How quickly do they do it?

What forms of withdrawal do they offer? Is it only stablecoins? Do they do wire transfers or other forms of payment convenient for me?

How many people can access this asset? Is it limited to people in particular countries?

As the answers to these questions will be different for different exchanges, the value of "a dollar" on each exchange will be slightly different. Thus prices in dollars on different exchanges will be different.
There are other factors, but this is (most commonly) the dominant one.

Exchanges have to respect the law, so user base has different limitations that is based on different factors. One of them is geographical location. Some user accounts can operate only in their country’s fiat, causing difference in the asset flow and its pair price. Same way fees can affect different pairs.


text:
Mining on Linux with an USB hard-deive
I want to mine with my AMD gpu. However I don't want to install the amd sdk on my daily driver operating system because that too much dependencies and external debs for me. I have the idea to install Ubuntu 18.04LTS on a USB (not an installation usb, a real installed operating system). Would it make sense or is it not very efficent ?

What are you trying to accomplish? Bitcoin mining isn't done with GPUs anymore. If this is about Monero, try the monery stackexchange.

@PieterWuille Yes it is about Monero, I didn't knew that there is a monero stackexchange

That would probably work fine.  Mining doesn't generally require fast disk access, especially if you are mining in a pool.
Of course, you'll have to reboot into your Ubuntu installation each time you want to start mining, and you won't be able to use your "daily" operating system at the same time as mining.


text:
Why does Bitcoin block 526,591 have a 6.25 (instead of 12.5) block reward?

https://chain.so/block/BTC/0000000000000000002ba5a1fb96f93e6c215d62db4280f1cbd30e82c7c71fba
https://blockchair.com/bitcoin/block/526591

It's an empty block (zero transactions), but the coinbase transaction is 6.25
The blockchain.com explorer shows this as having a -6.25 fee (despite having no transactions) https://www.blockchain.com/btc/block/0000000000000000002ba5a1fb96f93e6c215d62db4280f1cbd30e82c7c71fba

Possible duplicate of Can someone explain this weird mining activity?

While closely related, I think this question is sufficiently different: it's dealing with a different block and someone claiming only half the reward instead of none.

There is a maximum limit on the block reward which is 12.5 BTC but nothing prevents a miner from claiming less than 12.5 BTC. In fact, there have been times when miners forgot to claim any bitcoin at all (claimed 0 BTC), a very expensive mistake. This is probably a mistake from the miner, he could have certainly claimed more bitcoin.
As long as the block is valid, it will be accepted by the network, even if it's unfair for the miner. In practice, this means that the maximum supply of bitcoin is not 21 million BTC but 21 million BTC - unclaimed BTC by miners. People often see this difference by making the difference between sum(number_of_block_i * block_reward_of_block_i) and the total bitcoin counted from the UTXO set.

The block reward was 50 until block 210000, when it dropped to 25. Since block 420000 the reward dropped to 12.5.

related: other blocks where miners claimed less: https://bitcoin.stackexchange.com/questions/38994/will-there-be-21-million-bitcoins-eventually/38998#38998


text:
what is type of wallet with 18 words seed?
1) I have 18 words seed

spray inject... (18 worlds total)

2) And i have some password/secret key or private key

GVzPYhu....... (35 letters total)

What type of wallet and what crypto currency can there be access to?
I have already tried Electrum. Its dont work.
I'm ready to reward someone who will help.

Welcome @entarex11, no need to offer rewards, this site volunteers help for free.

18-word phrase
I believe Coinomi was a wallet which would accept an 18-word seed phrase. There will be many others.
Coinomi lets you choose the length of your seed-phrase from a list of valid lengths: 3 6 9 12 15 18 21 24
35 random letters
Private keys are usually longer
Addresses can be 35 letters long but usually start with a digit or with bc1
See https://en.bitcoin.it/wiki/List_of_address_prefixes
Perhaps this is a passphrase for the seed-phrase - the BIP39 specification allows for an optional passphrase. Some wallets have an "option" button which may allow you to enter a BIP39 passphrase - though they may call it a "seed extension" or something else.

Could be an old blockchain.info recovery mnemonic. You can try to recover access here. You will also need your wallet UUID to login. Look for that in your email archive.

Usually HD wallets like Coinomi are used to take backup of multiple cryptos.  A mnemonic code or sentence is superior for human interaction compared to the handling of raw binary or hexadecimal representations of a wallet seed.
Generating the mnemonic

The mnemonic must encode entropy in a multiple of 32 bits. With more entropy security is improved but the sentence length increases. We refer to the initial entropy length as ENT. The allowed size of ENT is 128-256 bits.
First, an initial entropy of ENT bits is generated. A checksum is generated by taking the first
ENT / 32

bits of its SHA256 hash. This checksum is appended to the end of the initial entropy. Next, these concatenated bits are split into groups of 11 bits, each encoding a number from 0-2047, serving as an index into a wordlist. Finally, we convert these numbers into words and use the joined words as a mnemonic sentence.
The following table describes the relation between the initial entropy length (ENT), the checksum length (CS) and the length of the generated mnemonic sentence (MS) in words.
CS = ENT / 32
MS = (ENT + CS) / 11

|  ENT  | CS | ENT+CS |  MS  |
+-------+----+--------+------+
|  128  |  4 |   132  |  12  |
|  160  |  5 |   165  |  15  |
|  192  |  6 |   198  |  18  |
|  224  |  7 |   231  |  21  |
|  256  |  8 |   264  |  24  |

The question was "what type of wallet uses an 18-word seed". An answer would be a list of the names of wallet software which match that criterion. You seem to have answered a different question


text:
bruteforce 12 words seed
Suppose that someone seized my seed with a phrase of 12 words. I deliberately changed the order of words in a phrase in such a way that the only way to get a real phrase is to go through all the possible combinacies of the current 12 words.
1) How many combinations will it be necessary to go through an attacker in order to find a real seed? How long can it take?
2) Do you find such precaution really effective?

The answer is 12! = 479,001,600 possible mnemonics (less if there are repeated words). Out of these only ~29,937,600 (1 in 16) produce a valid seed. This is definitely brute forceable.

No, if you want to do this use a longer mnemonic (and make sure you permute them in a truly random way).

thank for answer. Im whant to use Electrum. What are my options for enhancing seed phrase backup?
@Mike-D

create a new wallet with 24 words mnemonic (not with electrum, they don't support bip39) and then import it to electrum and move your funds there.

What should I to import to electrum ? I generated 24 seed from https://iancoleman.io/bip39/ , but electrum don't whant to import it.

make sure you tick BIP39 in the options dialog

"every passphrase generates a valid seed" https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#from-mnemonic-to-seed

@JBaczuk that refers to adding an extra word (eg 13th or 25th word) to the mnemonic as a ‘passphrase’. Any such passphrase will generate a valid wallet. The mnemonic itself includes a checksum, so not all permutations of a certain mnemonics’s words will be valid seeds (as the checksum will be invalid).

Permutation(12,12) = 12! = 479,001,600
Vanitygen on GTX 1080 can derive 50 million addresses in one second. 479/50 = ~9.5 thus it'll take 9.5 seconds to derive all addresses and find your private key. As this was a master password instead of a private key, it will take a little longer. Let's say at most 2 minutes.
Not effective at all, except that it might take up to week day for the thief to think of rearranging the words.

thank for answer. Im whant to use Electrum. What are my options for enhancing seed phrase backup?
@MCCCS


text:
How to cleanup mempool
I want to cleanup mempool.
I googled and knew -zapwallettxes might clean up mempool.
But when I do the following command, mempool is still loaded.

./bitcoind -testnet=3 -server -rest -dbcache=4000 -txindex=1 -rpcbind=0.0.0.0 -rpcallowip=0.0.0.0/0 -printtoconsole -zapwallettxs=2 -rescan

In this situation, even if I restart bitcoind, mempool is dumped to .bitcoin/testnet3/mempool.dat and loaded on startup.
how should I clean up mempool?
Any comments and advices are welcomed :)

Have you tried using the option maxmempool=N, where N is the maximum size of your mempool in megabytes?

Why are you doing this?  What do you hope to accomplish by "cleaning up" the mempool?

First of all, clearing your mempool doesn't really do anything if the transactions you're clearing have already propagated through the network. The mempool will sync again when you connect to other peers.
mempool.dat was introduced in 0.14.0 and will persist the mempool on shutdown. In order to clear the mempool you have to:

Shutdown Bitcoin Core $ bitcoin-cli -testnet3 stop
Delete mempool.dat $ rm ~/.bitcoin/testnet3/mempool.dat
Restart the daemon $ bitcoind -testnet -zapwallettxes

Note: You might also need start the daemon with -zapwallettxes so the transactions related to your wallet aren't loaded into the mempool at startup.
Another Note: If you only want to remove transactions related to your wallet, you can skip step 2: https://github.com/bitcoin/bitcoin/pull/10330

-zapwallettxes has been removed from bitcoin-core. Use abandontransaction to clear an orphaned Tx from the wallet.


text:
Destination tag in ripple
how use destination tag in remote in ripple when we make a payment?I tried with destination_tag and dtag in remote block.

What do you mean by "in remote"? What software exactly are you talking to? The usual way is to include a "DestinationTag" entry in the payment transaction.


text:
How can I accept Bitcoin as a payment without a 3rd party gateway
I want to create a website where users can pay with Bitcoin. However I want to create my own payment gateway because I do not want to rely on services like BitPay. I want a unique BTC address for every user where the users can send money to this wallet and then spend the coins on the site.
I heard that it is possible with bitcoin-cli/bitcoind. I also have high skills in PHP and Linux so this isn’t a problem.

You can write your own php software that does RPC calls to your bitcoin node, see https://bitcoincore.org/en/doc/0.18.0/ for more info

I solved it by getting into the Bitcoin Core RPC interface.
I also did a talk about it in German here. My solution is completely independent of any 3rd party software.

@Prayank Not all parts of it, only the wrapper. See the comments section in the video but as I said I only started with a PHP website that has a startpage, a login page and a secured page that only logged in users can view. Keep in mind that the wrapper I used in the video is not 100% complete, nor up-to date. Please use something that is actively maintained. For example Bitcoin.php

There are several solutions out there and currently the most hyped one is probably BTC-Pay. It also supports lightning, so you should be pretty future-ready.

If you're new to Bitcoin, I would advise you to play around btc wallet on testnet you could check mycelium for instance and get some btc via faucet. You need to understand that you don't need any third party for interacting with bitcoins, you just require a wallet. A wallet is a program that handle UTXOs, craft transactions and broadcast them to bitcoind nodes (or other compliant full node implementation), waiting for them to be mine. As you're developper, I highly recommend you to buy Mastering Bitcoin from Andreas M. Antonopoulos.
After than, you will simply design you're backend so that you can accept bitcoin payment, there is many open source project for your needs as btcpayserver or bitcore. I would suggest btcpayserver on your case, but both are "basically" bitcoind wrapper on steroids tailored for enabling applications on top of Bitcoin.

I am not new to Bitcoin. I know that I do not need Bitpay to accept them. However all tutorials I find only rely on Bitpay. I want a more technical answer which explains the steps I need to do to accept Bitcoin

Did you check btcpayserver then ? It describes exactly what you need "Start Accepting Bitcoin Payments With 0% Fees & No Third-party" and this is basically an API you will interact with in PHP. Your goal is to accept bitcoin payment, not building a wallet.


text:
How to get balance for a label
I have lots of addresses organized under a label.
Is there a command to show the total remaining amount available under a label ? (Or address)
I am building a payment gateway and I need get the total remaining amount of an address thats why I cannot use listreceivedbylabel.
I am also not able to rely on some block explorers API.

Use getreceivedbylabel. It takes label and minconf as arguments. label is the label, and minconf is the minimum number of confirmations for a transaction to be considered for inclusion in this value. The default is 1 confirmation.

This only shows the total received amount, not the amount of which is spendabel

Labels cannot be "spent from", so getreceivedbylabel gives you the "balance" of the label. You are trying to use labels like the old accounts system, don't do that.

@AndrewChow But I do want to categorize the bitcoin addresses without redownloading the whole blockchain(which is a side effect to run bitcoind in different fs namespaces). Is there any ways to do that?

@AndrewChow The default getbalances command only supports printing total available balance, which is not that helpful for audits of different labels.

@TJM If you want separation of "accounts", you should use multiple wallet files. Bitcoin Core supports having multiple wallets loaded simultaneously, with dynamic loading and unloading of said wallets. That will give you logical and actual separation of "accounts".