text:
Can I use the same seed words for two wallets?
I like the security of a local wallet, but at the same time I don't like the limited access. So I'm thinking I'll install the same wallet software on a second computer at my office and use the same seed words. This should get me access to the same private keys both at home and the office. I'll be the only person using the wallets, so accidental double sending won't happen. I don't know if transactions created on one wallet will show on the other, however, but I don't care to much about that.
Are there any potential issues with this that I'm not seeing?

I'll be using Electrum and Coinomi through Bluestacks, both on Windows 7.

Related: Can I use my wallet on different computers? They advise against it, but that's from 2011.

I'm not too familiar with how Electrum handles duplicate seeds. Personally, I start a multi-signature wallet and require only one signer but add two signers (my mobile device & my laptop). You can do this on Copay, Electrum, and most other bitcoin wallets.

Sounds like a good idea. Some assembly required (i.e. I'd have to transfer by bitcoin out of my current wallets.).

Can you expand on or give a source for how to create that kind of wallet?

When creating a wallet on electrum or most wallet applications, there usually is a “multi-signature” option. Also Google can help you out quite well.

It seems to me using the same seed for two wallets will result in those wallets being duplicates of each other.  i.e. all the coins will be spendable by either wallet.  This offers no advantage in my mind, and seems like it weakens security since there would now be two places for an attacker to get your private key.
Interesting idea to use Bluestacks to run multiple wallets.

"will result in those wallets being duplicates of each other." That's exactly the idea. Yes, a slight loss in security, but for added accessibility.

Coinomi is an android only wallet (but I don't want coin on my phone), but can hold all the alt coins I have/want, side by side. But their source is private, so they have less trust. That's where electrum comes in.


text:
A theoretical low cost attack scenario in PoW currencies
The scenario was designed by user:croraf and me in discussing a question of mine yesterday. To make it more clear, I want to present it here again in a stricter design.
To do it in a clear way, first four assumptions:

Transactions are accepted when N blocks confirm them.
We can make contact to the majority of the miners, they are egoistic and barely invested in the PoW currency.
An attack with the majority of mining power is possible. To make it more clear: We assume that rewriting blockchain history with undoing many transactions is so surprising, that we can get our benefits from the attack before the currency goes down.
There is an alt coin, resistant against our following attack scenario, without value correlation to PoW currencies. Mining hardware allows to mine the alt coin as well as the PoW currency.

Now the attack scenario.
We do a transaction with a higher value than mining benefits from N blocks. We wait until N blocks confirm our transaction, so the transaction is accepted by assumption 1. Than we bribe the majority of miners to create a fork to make our transaction undone. The bribe must be only a little bit more than the mining benefits on the "real" chain because they are egoistic and are not interested in keep the currency alive by assumption 2. Only paying the bribe the cost of the attack is very low relative to the promised win! The miners and we get our benefits from the attack before the currency is down by assumption 3. Then the PoW currency maybe goes down, but the bribed miners can go to mine the alt coin without any loss, what is possible by assumation 4.
Where is the fault, in the attack scenario or in the assumptions?
I think the attack scenario is correct and the suggested faults in the assumptions from the discussion yesterday can't convince my.
The most important critics I already know:
Assumption 1: We should only trust transactions with values comparable with mining costs, but this makes the currency inefficient, which was showed here.
Assumption 3: If you don't trust this assumption, so you deny usual attack scenario of PoW currency. If you do so, why shouldn't we do PoW with a very low difficulty and a very small mining power then?
EDIT: I think we can skip assumption 3 by doing the attack with a short position which means we do the high value transaction in the beginning with cryptos we have lended. I seems clear that the currency goes down after such a big attack and so we even profit from the short.

I would make 10 generic, substituting it with N. And remove 3rd assumption from the list.

Hello again, nice to see you. Yes, you are right, 10 is no special number and so a made it generic now. I've done 3rd assumption because this was the main argument in the discussion yesterday by @Briguy37.

what do you mean by "transactions are accepted when N blocks confirm them"? Every node in the network accepts transaction, validates them against a set of rules, and then they go in a mempool, and then will be included by a miner into a block. So if you wait "N blocks", others have processed it already... Independant from this, there are evaluations of mining power (the 51% attack). Probably also with 40%. How do you "bribe" the miners? The software running follows bitcoin rules. If they create a block that differs,  they lose the "intended" benefit (aka coinbase values cannot be spent).

ahh, I see: you want to wait N blocks, and then send your "high value tx" to the net, and convince the majority of miners to do a fork. Nothing easy as this! If you have flawed the net like this, everyone would go away from the currency, and you have made a one-time win?

I first sent the high value transaction, then wait until I can be sure that I get the thing I've payed for and then I bribe miners to accept double spending the money from the transaction, so I do usual majority attack. Different is that the costs are in my opinion in PoW only the costs for bribing the miners and not the costs for holding the mining power. So the attack is much cheaper than supposed.

For cost and risks in best and worst case scenario of my attack see my answer in https://bitcoin.stackexchange.com/questions/1093/how-much-would-it-cost-to-execute-a-51-attack?rq=1

Where is the fault, in the attack scenario or in the assumptions?

The fault lies that you've discounted the opportunity cost it takes for an adversary or a conglomerate of miners to subvert the chain by forking off from some prior block. The key here is that there is inherent cost to forking the blockchain at some arbitrary height and re-creating the blocks. The cost can be formularised as block subsidy + total transaction fees in the number of blocks an adversary wishes to re-produce.
Firstly, honest miners will not be party to this, because they'd have to forgo their prior earnings and do double the work to re-earn the difference in your promised bribe transactions fees, so the conflict transaction you intend to bribe the miner with must be so great that it has to be double (at least) block subsidy + total transaction fees * N. Where N is the total number of blocks you want to re-organise. More importantly, what is it that the attacker seeks to achieve by donating away such a large sum worth of bribes (is it actually incentive-compatible to do so)?
Secondly, Assumption 3. simply does not make much sense as it lacks incentive compatibility. As you have shown, sure a miner can perform a naked short on an exchange before colluding to perform your described attack, there is risk to undertaking such a trade as an exchange out of popular interest can renege or withhold payments to a colluding miner that undertakes such a transaction. Simply put, it is more incentive-compatible for miners to mine transactions in an honest manner.

@sigmabe, i've explained that the shorting has exchange and market risk for an adversary.

Yes, that's clear, we must pay a fee to lend the coins for the short. Maybe the fee is very big and for lending coins worth 10 million $ we must pay 1 million $ fees. All in all we have now the 10 million $ airplain we've bought with our transaction. And the only costs are 1 million $ fees for the short and 1 million $ to bribe the miners.

Maybe there's a misunderstanding: We hold a short position not the miners. Our short is realized by lending coins for 10 million $ for doing the attack.

source: Stack Exchange

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

sort: votes


text:
Unable to make Bitcoind commands
I am attempting to make Bitcoin-RPC commands in the Windows 10 terminal using Bitcoind from the Bitcoin Core. However, whenever I start C:\Program Files\Bitcoin\daemon>bitcoind the terminal hangs and doesn't print anything. I've waited several hours and the terminal keeps loading and doesn't allow any input. I've also tried typing C:\Program Files\Bitcoin\daemon>bitcoind -daemon but -daemon is not valid Windows command.
I've also tried querying Bitcoin-cli with C:\Program Files\Bitcoin\daemon>bitcoin-cli getinfo but I get the error:
C:\Program Files\Bitcoin\daemon>bitcoin-cli getinfo
error: couldn't connect to server: EOF reached (code 1)
(make sure server is running and you are connecting to the correct RPC port)

So, after researching and reading other Stack Overflow questions I decided to check my bitcoin.conf file. I didn't have one, so I created one and placed it in the C:\Users\User\AppData\Roaming\Bitcoin directory. My bitcoin.conf file looks like:
rpcuser=user
rpcpassword=pass
rpcallowip=127.0.0.1
rpcport=8332
rpcthreads=10
server=1

But i'm still getting the same errors. Does anyone have any idea on what i'm doing wrong?

Update:
I typed in tasklist into the windows terminal and bitcoind.exe and Clientcore were running. Then I typed :C:\Program Files\Bitcoin\daemon>bitcoin-cli -rpcuser=user -rpcpassword=pass -rpc
port=8332 getinfo, but got another error:
error code: -28
error message:
Verifying blocks...

Update:
I tried C:\Program Files\Bitcoin\daemon>bitcoin-cli -rpcuser=user -rpcpassword=pass -rpc
port=8332 getinfo again a couple minutes later and it worked.
I opened one terminal and ran bitcoind, and another terminal I make the getinfo command and everything works

try this:
bitcoin-cli -rpcuser=user -rpcpassword=pass -rpcport=8332 getinfo
also make sure bitcoind is running, you can do that by
ps -aux | grep bitcoind

I'm on Windows so instead of ps -aux | grep bitcoind i typed tasklist into the terminal, and bitcoind and ClientCore were running. Then I typed C:\Program Files\Bitcoin\daemon>bitcoin-cli -rpcuser=user -rpcpassword=pass -rpc and got another error?
port=8332 getinfo error code: -28 error message: Verifying blocks...

i tried again a couple minutes later and it worked. Thanks!!!

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


text:
How can a noob understand 'where their money went' when buying from bittylicious?
Complete newbie, trying out bitcoin for the first time (probably like everyone else in the world this morning).
Wanted to spend the maximum allowed for a new user - about 43 pounds.
When the full transaction details came up, I was being offered to buy 2.9 mBTC for this amount - at the bitcoin rate at the time, that was only about 33 dollars' worth of bitcoin - so, about 24 pounds!
On the face of it, the transaction results in me losing half my money!
How can I tell where that money 'goes'? Is it a transaction fee, or am I somehow just paying a strange price?

Can you share the transaction id?

@asterisk https://blockchain.info/tx/5d86a7641a5b729708f27ffe41c195a3ec9beb0f3ee270ed381cc02cd114670d

From the transaction link provided (link)
You can see that fees was just below $2 for this transaction:

So the rest (about 18 pounds) have been taken as a commission/fees for using their interface.
I would suggest you to try some other website to buy BTC, as you are paying a very high fees to buy BTC.


text:
Egoistic miners combined with large transactions destroy PoW?
EDIT
There is a clearer description of some parts of the problem in the link questions.

If there is a transaction value much higher than the payment for mining 10 new blocks, how can you trust this transaction?
To go more in detail. If I am a bad boy and pay with a proof-of-work cryptocurrency a large sum. Large means that the value is much higher than the payment for mining 10 new blocks. After that I wait some time - for example, so long, that 10 new blocks are mined in between - so that everybody thinks the transaction is sure. Than I bribe the miners with half the value of my transaction to create a new chain without my transaction. Because half the value of my transaction is very much and the miners are egoistic, they will create the new chain to get more payment in this way.
Is there any solution for such attacks in the construction of any cryptocurrency working with proof-of-work?
The only solution I see is, that we trust only transactions values which are comparable with mining-costs. But then the cryptocurrency is very inefficient.

How will you bribe miners to create a fork 10 blocks behind the current tip? You will put a large fee on that transaction. Why wouldn't miners include that transaction in the block on top of current tip?

I would bribe the miners in real life not with a large fee that everybody can notice. And part of the bribe is that the miners create the fork.

So you give them 2x reward of 10 blocks if they make 10 blocks you want them to make?

Yes, for example, maybe also much more than 2x.

Good attack. Well yes, it looks like you only trust the transaction that payed X btc only after it has been buried by cumulative block reward of size comparable to X?

But then we need a payment X of mining costs (energy!) somewhere to get trust in a transaction with value X, that seems to be nonsense.

https://chat.stackexchange.com/rooms/69555/room-for-croraf-and-sigmabe

Not a full answer, but here is a relevant paper: https://www.cs.umd.edu/~gasarch/reupapers/bitcoin.pdf

@PieterWuille Yes, there is a similar attack scenario, but calculations there don't help. They say if I bribe majority of miners and they know that  the others are bribed too, the costs to do the attack are greater than 0. \delta=0 in the paper. But this is trivial.

I think what you're describing is a 51% attack, but with a 3rd party that is not a miner, incentivizing the miner's 'bad behaviour'. Even with an off-blockchain bribe, you would need 51%+ of miners to make this attack work (otherwise the 'original chain' would always outrun the 'bribed chain').
So, if an 'egoistic' miner wanted to perform this attack, I think it would make more sense for them to do it for their own transaction, not for someone else. Performing this attack with the involvement of a third party only increases the risk for the miner (what if the third party doesn't pay the bribe? etc). I think it makes more sense for a miner to just perform the attack themselves: send 1000 btc to an exchange, convert to altcoin, withdraw, and then roll back the btc chain to remove the transaction that sent coins to the exchange.
There is a reason this sort of attack hasn't occurred: miners see it as being less profitable in the long run.

But the question stays: Why do "miners see it as being less profitable in the long run."?

Because the miners think they'll make the most profit by continuing to secure the bitcoin network, rather than just take a quick bribe and watch the public confidence in the network drop (ie price drops). Miners expect to make profit off their equipment for a lot longer time than the next ten blocks, the bribe would have to be huge, at least as large as 51% of the mining reward for the next year or more.

That's just a technical argument. Maybe someday (today?) there is an alt-coin resistant against attack scenario, which miners can mine when PoW currencies go down, so bribe is only about mining reward during the attack.

I don't think the existence of an alt-coin with that property would incentivize miners to perform this attack. Technical users may understand well enough to migrate to a 'safer' coin, but the more general public would lose trust in cryptocurrencies, so the 'market cap of the industry' would fall. So again, I don't think miners would choose to perform this attack

Ok, but even if we think hardware is worthless afterwards, we can use a short position and got so high profit and bribe fees that miners aren't interested in. I've done calculation on https://bitcointalk.org/index.php?topic=2512771.0. You should start reading in the block about the calculations.

The more complicated you make the plan, the higher the risk of it not working. What if the exchange you're using to short goes down due to a DOS attack, caused by market panic as people race to exit? The safest play is to mine cooperatively. I posted a similar question that you responded to, in there the rough math has 51% of the yearly mining reward set to ~$3.3billion. Miners would expect their position in the market to continue yielding profits for years to come (as they re-invest in their operations), so I think the bribe would have to be in the 11 digit range to be enticing. Thats a lot!

Let's play this out assuming the block reward plus fees averaged to 15 btc.  This would make 10 blocks worth about 150 btc.
Attack #1 - Single-transaction incentive:

Alice has 600btc in address A
Alice sends all 600btc from address A to Bob's address B
Bob waits 6 blocks and then signs his mansion over to Alice
Alice drives to her hideout and waits till the 10th block
Alice posts a new transaction from address A sending 300btc to address C with mining fees of 300btc
Miners see that transaction rewind the blockchain and set to work to get that fee.
A miner finds that block and awards themselves that fee.
That chain is now 9 blocks behind the original chain with no additional incentive to stay there, so miners jump back to the original chain.

Outcome:  This method of attack will not work as the fork will be abandoned.
Attack #2 - Multi-transaction incentive:

Alice has 6000btc in address A
Alice sends all 6000btc from address A to Bob's address B
Bob waits 6 blocks and then signs his 10 mansions over to Alice
Alice drives to her hideout and waits till the 10th block
Alice posts a new transaction from address A sending 5700btc to address C with mining fees of 300btc
Miners see that transaction rewind the blockchain and set to work to get that fee.
A miner finds that block and awards themselves that fee.
In the 2nd block, Alice sends 5400btc from C to D with a fee of 300btc
In the 3rd block, Alice sends 5100btc from D to E with a fee of 300btc
In the 4th block, Alice sends 4800btc from E to F with a fee of 300btc
In the 5th block, Alice sends 4500btc from F to G with a fee of 300btc
In the 6th block, Alice sends 4200btc from G to H with a fee of 300btc
In the 7th block, Alice sends 3900btc from H to I with a fee of 300btc
In the 8th block, Alice sends 3600btc from I to J with a fee of 300btc
In the 9th block, Alice sends 3300btc from J to K with a fee of 300btc
In the 10th block, Alice sends 3000btc from K to L with a fee of 300btc
In the 11th block, Alice sends 2700btc from L to M with a fee of 300btc
The forked chain is now 1 block ahead of the original chain, so the normal incentive causes miners to stay on the forked chain.

Outcome:  On paper, this method of attack benefits miners and Alice.  However, in practice this attack still falls short for a couple of reasons:

How will miners know on the first block of the fork that Alice will continue to provide the incentive needed to keep that fork alive?  If Alice stops at any time, all would-be profits will disappear when miners go back to the original chain.  One possibility is that Alice pre-publishes all 11 transactions.
Because the blockchains are public knowledge, a successful attack of this magnitude would shake public faith in Bitcoin.  This is because users can no longer trust 6-blocks to be sufficient to know whether a transaction has been accepted or not, since 10-blocks of transactions were rolled back using this attack.  This would undermine the fundamental decentralized trust of Bitcoin, crashing the system that miners are so heavily invested in.  Thus, even though miners would have more bitcoin in the short-term, that bitcoin would be severely devalued.  Further, it will undermine the entire platform they are so heavily invested in, which is against their interests.

Thus, it will not be in miners' long-term best interests to partake in such an attack.
The only way it would possibly work is if a majority of miners want Bitcoin to fail, and in that case Bitcoin has much bigger problems.
Attack #3 - Non Transaction-Fee Bribe:

Alice has 600btc in address A
Alice sends all 600btc from address A to Bob's address B
Bob waits 6 blocks and then signs his mansion over to Alice
Alice drives to her hideout and waits till the 10th block
Alice bribes all miners to move to a forked chain.  If this were on-chain from wallet A, it would look like the following:

For all the miners that earned block rewards and fees in the 10 blocks, she pays them that amount for a total sum of 150btc
For all the miners in the world, she pays them the fraction of the hashing power they have of the remaining 150btc

Miners see that transaction which benefits all of them, rewind the blockchain and set to work to get that transaction.
All miners stay on that chain since it starts them all off with more bitcoin than the original chain, plus it has the same rewards.

This is technically less expensive than attack #2, but requires more than 50% of miners in the world to participate and so the coordination effort is enormous.  This is because all participating miners must coordinate their mining software to be able to play by these rules.  Further, depending on the number of miners/mining pools who don't participate, this will increase the number of blocks that Alice would need to float.  For example, if 30% of miners do not participate, by the time the 10th block on the forked chain rolls around there will be around 13 blocks on the original chain.
This would again have the same scenario where it would be public knowledge that miners rewrote history and undermined (no pun intended) the blockchain.  Even if it Alice's transaction was off-chain, it will still break the core principle that transactions 6-blocks deep are safe and thus devalue Bitcoin.
Again, the only way this would possibly work is if a majority of miners want Bitcoin to fail.

Did you read my comments about? The scenario is to bribe miners in real live and not doing it by fees which is maybe to obvious. And when there are large sums you can bribe miners with so much money that they don't care if bitcoin is maybe down afterwards. Besides, I mean Attack #2.

By the way PoW miners are not "heavily invested" in the system. That's maybe the problem of all. I think the attack isn't possible in a PoW-PoS hybrid, so miners can go there after they crashed the PoW currencies.

@sigmabe Thanks for the clarification, I added a third scenario based on your first comment.

@sigmabe In regards to PoW, I suppose you are right that they aren't necessarily "heavily invested" in Bitcoin.  Instead, they are heavily invested in their mining hardware.  Now that we have alt-chains that their mining hardware will work on, they could escape the Bitcoin massacre by jumping to mine the alt.  However, unless the alt has protection against a similar attack it will undermine the faith there too, so your suggestion of a PoW-PoS hybrid or something else to thwart this is spot-on as a requirement to get this type of attack to work.

Yes, third scenario is better. But I don't see how it solves the problem. Yes, you need the majority of mining power, but it isn't as expensive as thought. You don't have to pay the mining hardware and energy, you only have to pay the money to bribe. And I think you don't need much money to bribe, because miners are egoistic and can go to a better coin afterwards.

Aren't there alt coins which work as PoW-PoS hybrid?

for further discussions https://bitcoin.stackexchange.com/questions/63993/a-theoretical-low-cost-attack-scenario-in-pow-currencies

To profit even more from the "bitcoin massacre" we should do the attack with lended coins, so there's no problem if the currency goes down, because this is what we want.

I think you have a valid point.  Let's say I control 50% of the mining.  How much would I accept to start a new fork from 10 blocks back?
With 50% of the mining, I'd be getting about half of the blocks, or 5 of the 10 blocks just mined.  Asking me to fork from 10 blocks back would mean I'd be giving up these 5 blocks worth of payment.
The question then is how long it would take me to catch up to the real block chain from 10 blocks behind.  At 50% of mining, I'd be flipping a coin to try to get 10 more heads than tails.  On average, that takes some number of flips, say N.  So, I would have to mine an additional N blocks, on average, to catch up to the current chain.
So, if you pay me more than N+5 blocks worth, then it would on average be more profitable for me to start a chain for you than to continue the current chain.
However, this is the average, and the distribution has a long tail, meaning it might take hundreds of blocks until the new chain is longer than the current one.  There are some ways we could deal with this risk:
1) I charge you a per-block fee, and you pay me as long as you want me to mine for you.  There is no promise I will ever catch up to the current chain, but I'll keep trying as long as you keep paying more than I'd make with legitimate mining.
2) I charge you up front and take the risk.  In this case I'm on the hook to catch you up to the existing chain.  I'd probably charge a large premium based on the potential to divert my mining resources for a long time.  Also, it's possible I never will catch up, so I'd probably add a refund clause to cut my losses if it looks hopeless.
The idea that I'd mine legitimately because I want Bitcoin to succeed has some truth, because there is some setup cost to mining and I want a return on this investment, but for the right price I'd probably take the risk of killing Bitcoin.  That risk is captured in the premium I charge you over my normal mining income.
Plugging in some numbers, I'll use Briguy37's assumption of 15 BTC per block mined, and let's assume N is 20 and my premium is 100%.  Then, I'd charge 25*15*2 = 750 BTC to do this fork.
We can argue the exact numbers, but the main point seems to be what you were saying, which is that large transactions are not as trustworthy as smaller ones.
I would take this one step farther and argue that some smaller transactions may not be trustworthy either.  Suppose I agree to pay 100 people 10 BTC each.  That's 1000 BTC from me, but each transaction is only 10 BTC as far as the recipients know.  if I time them all the same, the cost to reverse all of them is the same as if they were a single transaction.


text:
Why are some Bitcoind commands comparatively slow?
For example, running bitcoin-cli getbalance <address> on an arbitrary, watch-only address takes around 6-7 seconds for a response. Is there any way to improve the response time?
How do API services like Blockchain.info return balance details almost instantaneously? Each API call to Blockchain.info takes less than half a second for a balance request. Is there a way for me to do that with bitcoind?

Are you using bitcoind on a vps?

@RutgerVersteegden no, i'm not using a VPS

For example, running bitcoin-cli getbalance <address> on an arbitrary, watch-only address takes around 6-7 seconds for a response. Is there any way to improve this?

Besides the fact that this is not how getbalance works (you don't call it on an address), getbalance is slow here because it must go through the list of transactions for the addresses in your wallet and sum their outputs to get the balance. If your wallet is very large and has lots of transactions or you are running bitcoind on low powered hardware, this could take a long time.

How do API services like Blockchain return balance details almost instantaneously? Each API call to Blockchain takes less than half a second for a balance request. Is there a way for me to do that?

Those API services have several large servers hosting their databases. Their databases are massive and index everything in the blockchain. They store information like the balance of each address (which is technically not in the blockchain) so when you ask for the information, it is pulled from the database very quickly. Bitcoin Core does not do this as such databases are a waste of space and most users will not be affected by the slower functionality.

What do you mean? Am I using getbalance wrong? I’m trying to follow the Bitcoin.org  documentation.

No, you're not using it wrong. Bitcoin Core's getbalance implementation is just slow when many transactions are involved.

The block explorers will use a "proper" database to allow fast queries.  They most likely have some nice hardware behind them too.
You can setup an open source block explorer yourself Example: https://insight.is/
There is a txindex config option for bitcoin that may speed up some commands What are pros and cons of txindex option?

I didn't know about this before. Thanks for the info.


text:
Why don't the miners just take profit from our coins and make the coin worthless?
You own a very valuable thing and you want to go to holiday without it, but there is nobody who you trust and who can look after the thing. So you take somebody unknown to guard it. You pay him a fee hoping he doesn't run away with the valuable think. How much would you pay?
I think you should pay for the fee minimum the value of the valuable thing!
But now to bitcoin. Do the story again:
You own a very valuable coin which is guarded by somebody unknown (the miners). You pay him a fee (mining profit) that is much less than the value of the coin (market cap of bitcoin). Why don't the miners hold short positions on the coin, bring value of the coin down with a large majority attack which destroys any trust in the coin and go with benefit from the destruction?

I asked this fundamental question about bitcoin in a stricter way 2 days before in this question and similar in this question and there is also a bounty for an answer, but there is only less interest and no upvotes and no good answers. I think the question is fundamental, and so I tried to do it in an easy analogy now.

Calling the short positiong "running away with our coins" is highly misleading and confusing answerers. Can you please edit your question to make it absolutely clear that you are talking about markets and shorting and not how miners can actually steal coins?

Do you think I should do this in the caption, in the question or in both cases?

Do it in both. The title is what people see first, if that does not match the content of the question itself, it is confusing.

I hope it's better now, I'm looking forward to have you in the discussion!

Because miners do not actually own/ or have access to the bitcoins which are being spent in a transaction.
They simply choose a number of transactions which have valid signatures, and put them together with the hash they created/solved, thus creating a valid block.
See https://en.bitcoin.it/wiki/Block_hashing_algorithm for more information.
The person that owns the private key owns the bitcoin, which (unless you share it ofcourse) would be something miners, or anyone in general, won't have access to.
EDIT:
There's currently ~12.000.000 TH/S, In order to gain 51% of the hashpower, ( which is needed to always be faster, thus control the bitcoin chain), you would atleast need 12.000.001++ TH/S, lets say we would generate this power with an Antminer S9+, currently the fastest, (i believe?) which has an average speed of 11.5TH/S
12.000.001TH/s / 11.5 = 1043479 Antminers, which would cost a total of
1043479*2000= 2.1 billion$
If you're willing to spend that much money just to short bitcoin, you have to ask yourself if it's going to viable, and profitable.
Even if there's a majority attack, miners still can't decide the protocol rules. See What can an attacker with 51% of hash power do?
as to what is actually possible with a 51% majority of the hashpower.
You could then speculate on the price going down, but then again, it might not, leaving you with extreme losses.
Also, you would probably be able to earn way more by simply mining the majority of the blocks and its fees.. 25 Bitcoin every 10 minutes ( since you have the majority) = 250k$ every 10 minutes. ( At the current exchange rate. )
250.000*6*24=36.000.000$ in blockrewards each day alone.
So, i'm not saying that you can't theorethically making profit shorting it while trying to destroy it with a majority hashpower, but that there are probably better options.

The attack scenario is holding a short option and destroy bitcoin by majority attack. Your answer is completely different.

What exactly do you mean by holding a short option? Like a short as in a stock?

Yes, profiting when the currency goes down.

So the wrong sentence is "bring value of the coin down with a large majority attack which destroys any trust in the coin", because it isn't sure that this happens?

What about an attacker that owns 51% of the full nodes?   All mined blocks have to get approved by full nodes and then be added to the blockchain.. "honest" full nodes decide the difficulty level.. what if tommorow someone gained access to 51% of full nodes and changed the difficulty level back to 1 (a difficulty that can require a couple GHs to solve blocks)?

An attacker would need 100% of full nodes for that (including your own). There is a wide misconception that a majority can decide anything in Bitcoin. This is not true. A full node will not accept any invalid block.or transaction, period. Not with 99% of the rest of world vouching for it. The only place where a majority matters is that 51% of miners can decide the order and timing of otherwise valid transactions, up to and including the ability to delay them indefinitely. But miners are never ever given the authority to make invalid blocks or transactions valid.

At what point in the transaction could the miners "run away with your coins"? I may be wrong, but the miners just take your transaction and put them into the Blockchain for a small fee. They never actually have your coins, a portion of the transaction goes to them. I don't think they could steal your coins if they wanted to.

Did you read the question? It's about holding a short position during destroying the coin. That's completely different from your answer.

I am confused, your question didn't mention anything about a short position or anything. Are you referring to a group of miners? How do you miners 'guard' the BTC?

" Why is there any hope that he doesn't run away with the coins or more formal why don't the miners hold short positions on the coin, destroy the coin and run away with benefit from the destruction?" is part of my question! Miners guard the coins in the sense that they create trust in the coin with their mining power.

Ah okay so say the miner's do short the coin, how do they 'destroy' the coin in someone else's wallet?

They bring the currency down by majority attack and so they profit from the short. They don't steel the coin, but the coin is worthless afterwards.

Ah okay, so in order for that to happen you need a mining group with at least 51% majority. And then, you need to have all 51% agree to do this. Then, you need to make more money than they would have just regularly mining.  It doesn't seem feasible.

Yes, you do majority attack, but profit comes from value of the thing (maket cap) and costs from guarding it (mining costs). The first is much bigger.

Let us continue this discussion in chat.

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


text:
Formula for Bitcoin Difficulity
I'm wondering if anyone knows a formula for how to calculate the mining difficulty based on the current hash rate. For an example, if the BTC network would reach 20 million TH/s.
Thank You!


text:
How does market cap of currency decrease?
According to my knowledge, once a currency is mined, its already released so how does market cap change? Consider if Sathosi (the founder of bitcoin) sells all his 1 million coins, there will be people who would buy it. It would just be a transfer from one person to another. How would it affect the market cap?

The market cap is the product of the total currency supply and its instant exchange rate. If either the exchange or supply goes down, the market cap does too.
The supply generally doesn't decrease, except through things like burning coins (see this answer of mine for more information). The exchange rate of course goes up and down all the time.
Market cap is generally a pointless metric, because it does not in any way reflect the cost or income of selling or buying the entire currency's supply. Only small fractions of the supply are being offered on the market, so selling or buying any significant amount will easily move the price around.

Consider if Sathosi (the founder of bitcoin) sells all his 1 million coins

Just to be clear: how many BTC Bitcoin's creator has is speculation.


text:
What Does "Activation" Actually Mean In Bitcoin?
During the multiple issues with Bitcoin this year with soft and hard forks, and Segwit, I have read as much as I can about how all these changes are "deployed", eg BIP9, BIP91, BIP148, BIP's 141-146.
However I am still not clear about some of the terminology, such as "locking in", "signalling", "activation", "deployment".
I understand Segwit was implemented in v0.13.1 (and above) of Bitcoin Core which was released on 27/10/2016.
So all the Segwit changes have been in the Bitcoin Core software since that date ?
So when "activation" of Segwit occurred - did that mean a flag within the Bitcoin client, say "ACTIVATION_FLAG", became true and then the Segwit functionality thus started to run - because it is contained inside an "if" block :-
if (ACTIVATION_FLAG) {
    do Segwit stuff
}

However Segwit is a complex upgrade to Bitcoin so there must be many places where changes are made to Bitcoin for Segwit - so how many such "if" blocks are there ?
Can someone give me some links to where these "if" blocks are located in the Bitcoin source code?

Related https://bitcoin.stackexchange.com/q/56924/5406

However Segwit is a complex upgrade to Bitcoin so there must be many places where changes are made to Bitcoin for Segwit - so how many such "if" blocks are there ?

As of writing, there are 23 to 34 places where behavior changes based on whether segwit is active, depending on how you count. (e.g. if you pass a boolean to a function, and that function contains an if, and the function return value is passed to another if, is that 1 or 2 if statements?)
If you have a copy of the repository you can find them with the following commands:

grep -RI "SEGWIT" * | grep THRESHOLD_ACTIVE
grep -RI "fPreSegWit" *
grep -RI "IsWitnessEnabled" *
grep -RI "fWitnessEnabled" *
grep -RI "witnessEnabled" *

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


text:
what happens to your funds when wallet provider packs up?
Supposing the company that provide Electrum wallets goes bust and the service/software is withdrawn. Does this mean my fund disappear? If not then how would I recover my funds?
More specifically would the 12 recovery words (provided by Electrum)  have any use if Electrum wallet service was no longer available?

Electrum is an open source project, it is not a company. Even if all the volunteers working on the project right now decided to abandon the project, the wallet is all open source so anyone can pick up where they left off.
It is not possible for "Electrum wallet service" to no longer be available because anyone can run the Electrum server that Electrum requires. The 12 recovery words by itself are sufficient to recover all your funds. You will either need to connect to an Electrum server in order to do so or run you own Electrum server. Even if that's not an option for whatever reason, you could also regenerate all your private keys from the electrum seed and import them into any other wallet.

This is a good answer to the Electrum example, but I assume OP wanted to know what would happen if it was let's say Coinbase that was shutting down.

As Cedric says, Electrum is an example. I simply want to know what steps I have to take to recover my funds should the unthinkable happen. By the way,  if it is possible to recover my funds in a new wallet, does that mean we have a method to transfer for free?

If the wallet provider is not open source, then you will need to trust that the wallet provider is a) secure and b) will act honestly and return your funds when they shut down. There is no blanket answer since there are many wallet providers and the above questions are hard to answer for any single wallet provider.

Just noticed a real case: Mulitbit is no longer supported. I actually have some funds in there! I am now panicking!

Found this guide by Multibit.org people which answered all my questions: https://youtu.be/E-KcY6KUVnY


text:
MultibitHD is No Longer Supported (transfer funds without fee)
I just realized that multibithd is no longer supported. I have some funds there and I try to make 2 transactions, which were not confirmed in blockchain, because I also place them without commission.
If multibithd is supposed to doesn't work. What will happen with that transaction? will it expire? will it be completed? The status in multibit is sending since December 18, 2017.
I already moved my funds to electrum and that transaction does not appear.
Also, I do not understand if the transaction is unconfirmed because it places the commission = 0  or because multibit does not work anymore.
And, what would happen if I make another transaction in electrum?
Thank you and waiting for your answers.

If you had posted the transaction id we could check, but nonetheless it seems likely that the transactions created by MultiBit HD had a way too low transaction fee. That would mean that your outgoing transaction doesn't appear on Electrum, because nobody on the network relayed it to your Electrum wallet after you had reimported the keys there.
If the fee rate on the original transactions was higher than ~1 satoshi per byte, you can and should create a new doublespend transaction from Electrum, to make sure that you invalidate the old transactions that you created on MultiBit HD.

So, the best solution would be to do the transfer in electrum again? What will happen to the previous transaction, expire?

The transaction remains valid and in mempools until it either becomes confirmed or invalidated. It can become invalidated if any of its inputs are used in another transaction (a doublespend). If you repeat your transaction, you should make sure that the old transaction cannot be confirmed anymore by invalidating it.

Thank so much for your help. How do I make that doublespend transaction? Is normal as any transaction by clicking on send and placing the amount, address and commission? Where do I get (any of its inputs)?

Use Electrum's "Send from" feature to pick one of the Unspent Transaction Outputs that your previous transaction also used as an input. Since each UTXO can only be spent once, the old transaction becomes invalid when this one gets confirmed.

Perfect, thank you very much!!. There is a risk that both transactions are confirmed (One of Multibit and one from Electrum) and left with a debit or negative balance?

Let me explain with an allegory. When you're using the same UTXO in two different transactions, this is akin to you having a single 10 dollar bill, but promising the same 10 dollar bill to two different recipients. You can only give it to one of them. What I'm suggesting is that you make your first and second transaction clash in this fashion that thusly only one of them can become valid.

Check the average transaction fee on the blockchain right now, and then look for your transaction on blockchain.info. If your mining fee is significantly lower that average, it will be stuck there for a long time. Eventually your transaction priority will be pushed higher, but there's a backlog of unconfirmed transaction overloading the blockchain right now. If your fee was too low, it will eventually reject the transaction and it will come back to your wallet. You can't do much at the moment right now when your transaction is in a hanging state.

My transaction fee was n/a. What I do not understand is if the transaction is unconfirmed, for the fee = 0 or because multibit no longer works. In electrum I can see my balance and that pending transaction does not appear. What would happen if I make another transaction in electrum?


text:
Coin minable from browser
I was wondering if there is a coin that can be mined in a browser? So I can remove the dreaded ads from my website.

Doing this will significantly increase CPU usage and power consumption on your users' devices, harming battery life if mobile, and generally annoy them. Adblockers will block mining too.

Yes. Mining in your browser means mining with CPU. There are a lot of coins that focus on CPU-mining. Of course, Bitcoin is not one of them as ASIC-mining is much more effizient.
There is a useful list of coins:

The CPU Coin List is a sortable list of Alternate Cryptocurrencies (Altcoins) that can be mined on your CPU

http://cpucoinlist.com/
By the way: Mining in the browser already happens. There is coinhive ( https://coinhive.com/ ) for example. They offer a script you can implement into the sourcecode of your website. If someone visits the site with activated javascript, the mining starts automaticly. The mined cryptocurrency is Monero.

do the coins in the above list have any disadvantage as compared to bitcoin ?
does cpu mining have any cons as compared to asic mining ?

It is possible to set up a Monero miner with a few lines of Javascript. You can check how to do this here. Unless you have a lot of traffic, you are not likely to earn much. You are also harming the battery life of your users and their CPU.

I found the perfect CPU mining coin. It started out as a proof of work coin and now currently deploys a proof of stake system.
Make sure to check out WebDollar.io
Note: WebDollar Wallets are also browser based so make sure to download and save your wallet.
Plus, the coin can be staked in the comfort of your Telegram (5%) or Reddit (6%) accounts


text:
How can I migrate from blockchain wallet to Electrum?
I would appreciate a simple step-by-step guide to migrate from Blockchain wallet (https://play.google.com/store/apps/details?id=piuk.blockchain.android) to Electrum wallet. Presumably I would have to use my blockchain.info wallet seed words to create a new Electrum wallet. Is there a step-by-step guide for this operation?
Thanks
P.S. I am not allowed to use "migration" and also "Blockchain Wallet" tags because I am a newbie

These steps are for new Blockchain.info wallets based of BIP39 seeds.
If you have previously imported private keys to blockchain.info they have to be exported separately, as they are not part of the keys derived from the seed.

Get your blockchain.info seed. Login to your blockchain.info account, click on 'Security Center' then click on 'Backup Phrase'. Be aware that onced the phrase is backed up, you won't be able to access it again on blockchain.info. So note it down carefully.
Start Electrum, choose to restore a standard wallet, then restore from seed, enter your seed, then click options and check the 'BIP39 seed' box. -> Click Ok/Next.
Blockchain.info follows the BIP 44 standard for derivation paths, so the default account has a derivation path m/44'/0'/0'/0
You should now have migrated to Electrum.

Is Blockchain.info Wallet the same as Blockchain Wallet? What I have is the second one. Also after the BIP39 choice there is one final option as described in this video guide https://youtu.be/E-KcY6KUVnY (for Multibit). How should I set the final one in the case of Blockchain Wallet?

Added an extra step.   Blockchain Wallet, you mean like Bitcoin Core? Which software/exchange did you get your wallet from?

Thanks for the extra information. I will try it. My wallet is this: : https://play.google.com/store/apps/details?id=piuk.blockchain.android

I do your tutorial step by step 1-2-3-4 But in electrum wallet, I don't see my coins :/ How long need to wait what coins to show in Electrum? I wait for 1h. Or maybe need to configure Electrum? Thank you!

@Thomas they should show up immediately, maybe you got an old blockchain.info wallet?

@Thomas make sure to set the correct derivation path as you may have multiple wallets. You can also refer to https://blog.blockonomics.co/how-to-restore-blockchain-com-wallet-into-electrum-f593ec79ab3d


text:
Will Bitcoin Transaction Evicted From Mempool Disappear From Blockchain Explorer?
From the question below I can see the circumstances under which a transaction will be removed from the Bitcoin mempool :-
How do transactions leave the memory pool?
Whilst a transaction is still unconfirmed, it shows up in the Blockchain.info Explorer as an 'Unconfirmed Transaction!', within a red colored button. This button then turns to blue with "1 Confirmations" when the transaction is confirmed.
However if the transaction remains unconfirmed for a long time and the button remains at red, and if the transaction is then eventually "evicted" from the mempool, will the Blockchain Explorer then just report "Transaction Not Found" when I search for the transaction's id ?
I would find this behaviour useful as it would allow me to tell when a transaction has effectively been cancelled. If the red button is still showing, I know my transaction may still have a chance of confirmation, and I may be prepared to wait a few days in some cases for non-urgent transfers, especially when fees are at very high levels. If the transaction disappears altogether then I know I would have to submit a new transaction entirely. (I would actually prefer that a wallet did not automatically resubmit a failed transaction, but rather let me know it has failed).
Many thanks

First of all, there is no "the Bitcoin mempool". Each node has its own mempool, so if the transaction is evicted from one node's mempool, there is no guarantee that it has been evicted from other node's mempools.
If most nodes have evicted a transaction, it still may appear on a blockchain explorer because they may have other configuration settings which has them have a larger mempool and hold onto transactions for longer. Generally blockchain explorers have less restrictive mempool configurations than most nodes, so if a transaction disappears from multiple block explorer's mempools, then it is likely that most nodes on the network have evicted the transaction.

So would I be right in saying that after a reasonable time frame (say 4 weeks, ie twice the default transaction expiry time for a node), a transaction that has still not been mined must, with very high likelihood, no longer be visible in any Blockchain Explorer, and not in any node's mempool? And in fact it might less than 4 weeks in most cases?


text:
What are some paid cryptocurrency exchange software?
What are major exchanges are using ?
few of them have similar layout and trading system.
is there readymade crypto trading software available ? even paid.

Yes, ready-made crypto trading software is available. I have been shortlisted some of the crypto trading software provider across the world.
Coinsclone
BitExchange System
Trading Technologies
Draglet
BlockchainAppFactory


text:
Why the nonce is difficult to find in Bitcoin?
I read many articles explain the Bitcoin POW, but every article seems copy form each other. they just indicate find a nonce start from 1, but I still confused why find a nonce number is so difficult? I know the hash value must lower than the target difficulty.
for example the Block #502500, the nonce is 3965324040, so this block hash value lower than the target when the nonce equal 3965324040.
if I start from 1 increasing the nonce to 3965324040, that is mean computer doing the SHA256 3965324040 times, but almost every mining pool already reached PHash/s, so they just need less 1 second to find the nonce?
after 2016 second would go to next difficulty? because they just took 1 second to find a nonce.
did I miss something there?
Block #502500 from Blockchain.info

Miners try many block candidates per second. Every candidate is different in some way, but the nonce is only one of the ways in which they differ. Other ways include the timestamp, and - most importantly - the selection of transactions. In particular, the first transaction in the block is the coinbase transaction, which includes the miner payout, and the extranonce.
In practice, miners at the lowest level just increase nonces, because that's the easiest way to modify a block. However, as you point out, any modern hardware will run through all 232 nonces in less than a millisecond. So to continue searching, they will modify the extranonce inside the coinbase transaction any time they run out of block header nonces. This requires more work, as it means the Merkle tree has to be recomputed.
At the time of writing (January 2018) only one block candidate in 829 quintillion is valid. This means that all network miners combined, every 10 minutes, go through over 1.9 trilllion sets of 232 nonces.


text:
POW based blockchains systems Majority Attack
TL;DR: With only 30% of network power a Majority Attack is possible and profitable. Am I missing anything?

Generally speaking, blockchains based on Proof-of-Work authentications are using amount of work as the weight of one's vote.
I will be talking specifically about bitcoin to simplify the discussion (Although I hate reading people who talks about cryptocurrency here).
A transaction is consider confirmed usually after 6 blocks have been mined above it. Mostly even 2 blocks are considered enough, but let's examine the secure decision of 6 block. Now assume I have 30% of the network power.
Me and the network have the same prefix of blockchain. At this point I'm beging to work and append to it my own blocks, ignoring the rest of the network. The chances I will manage to build a blockchain that is at least as long as longest chain in the network, by the time the transaction is "confirmed" - is roughly 15% (reference below).
That means I can revert my confirmed transactions 15% of the times. Now all I need is to earn more money on a reverted block than I'm paying for the total computing power. This is not impossible. If a "confirmed" block is even half-fulled with my transactions, the total amount of money can easily be 2 million usd (reference below).
Reverting at 15% success rate means at least one block every two hours (one block every ten minutes).
But 2 hours of work only cost me about 140,000 usd.
Or more importantly: playing fair doesn't seem necessarily more profitable.
Playing by the rules for two hours equals today about 1.2 million usd income (If you own 30% of the network power).
It seems profitable to attack the system every now and then, even with 30% of network power.
(Obviously I rather revert a lot of "small" transactions than a huge one, so no one will get susplicious and wait for more confirmations.)
What am I missing?
A few points:
- I rather not address issues such as "an attacker can be easily found". This may, or may not, be true. But it's not relevant for the question: Is it possible and profitable to attack the network with 30% network power.
- If you are stating I'm not mistaken and this is true (which I doubt), please do specify your amount of familirity with the protocol and the security of the system.
Refernces:

Success rate with 30% network power (math here is simple but clumbsy to write down rigorously)
https://pastebin.com/RhnGi04W
A single block carry a few thousand bitcoins (namely, a few million usd)
https://blockchain.info/
Bitcoin value in usd
https://coinmarketcap.com/currencies/bitcoin
Profits and costs of the entire bitcoin network:
https://digiconomist.net/bitcoin-energy-consumption
(I assumed one hour of my working profits roughly: total_bitcoin_mining_income/365/24*0.3
as I own 0.3 of the network power)

Isn't what they call 'selfish mining'?

@OsiasJota: No. The selfish mining attack is a different attack which is detailed in the relevant paper. The selfish mining attack is an attack on chain quality i.e., allows a miner to get more blocks in the blockchain than the honest strategy. It has nothing to do with double spending.

The attack you are describing is correct. This is an attack against the "Common Prefix" property of the blockchain, which roughly states that it should be hard for an adversary to cause two honest parties to adopt two different blockchains at the same time when they have diverged for more than k blocks, where k is a parameter. In your case, you have set k = 6.
In fact, the attack you are describing has been analyzed in Satoshi's original paper. If you look at the last section (11. Calculations), Satoshi calculates the probability of success of the attack you described. Specifically, he examines the probability of adversarial success for various values of the variable he calls q, which indicates the adversarial mining power. For your case, q = 0.3. Then he uses the variable z to indicate the number of blocks one waits prior to accepting a transaction as confirmed, in your case z = 6. In Satoshi's analysis, this follows a Poisson distribution and roughly the probability of adversarial success is indeed p ~= 0.15. In fact, Satoshi precisely calculates the case z = 5 and q = 0.3 and gets p = 0.1773.
In the original paper, there are certain z recommendations for how many blocks one should wait for to achieve an adversarial probability bound of p < 0.1%. For q = 0.3, the minimum z that achieves this is z = 24. So, if you want to be able to withstand a 30% adversary, you must wait for 24 confirmations.
Satoshi's analysis is a bit rough, because it only takes one particular attack into account. Subsequent analyses have allowed us to quantify these probabilities against arbitrary adversaries, even unknown. The primary reference here is the Backbone analysis. In this paper, the Common Prefix property is stated precisely and proven to hold against arbitrary adversaries.
The Backbone analysis is an improvement over Satoshi's for several reasons. I will mention a few:

The probability distributions are specified precisely (as Binomial and Bernoulli distributions) and not approximately (as Poisson distributions).
The adversary is arbitrary and does not necessarily follow a strategy that we have predicted or know about.
The security is proven and not simply intuitively conjectured.
The system is modeled and analyzed precisely using theoretical computer science tools down to interactive Turing machines.

To see the Common Prefix statement precisely, look at Definition 3 (Common Prefix) under section 3.2 (Desired properties of the protocol). The fact that bitcoin has this property is proven in Section 4.2 (Common-Prefix property) under Theorem 15 (Common Prefix). There, a precise formula is given for k, the number of blocks you need to wait to know that the chain cannot be reorg'ed back to that point: k = ηκf. The variables η, κ, f are made precise in Section 4 (Analysis) under Table 1 (The parameters in our analysis). It is difficult to give concrete numbers to these variables, as they depend on the network health and performance as well as mining difficulty. For bitcoin, we have that κ = 256 is the bit length of the (mining) hash function. I estimate round duration to be, optimistically, about 10 seconds (time it takes for a large portion, say 90%, of the network to learn of a newly mined block header) and so since a block is found on average every 10 minutes, we have that f is about 0.0003 for bitcoin. I do not know how to estimate η precisely.
The point is that the Common Prefix theorem is attained for k when "the execution is typical" (typicality is established in Theorem 10), which depends on the parameters ηκ. A prerequisite for typicality is that the sequences of consecutive rounds examined are at least ηκ in length. The assumption that this quantity is large is needed to apply the Chernoff bounds to the Binomial distribution: Typicality is attained with overwhelming probability in this number. If this number is small, the probability is no longer overwhelming, and the security of the system can fail.
Such analyses are typical in cryptographic systems, including digital signatures, encryption schemes, zero-knowledge proofs, and so on. The adversary is capable of succeeding with a probability which is bounded by a function with one free variable: That free variable is the security parameter (ηκ in backbone's case) and the function is negligible in that parameter, meaning that the probability drops off exponentially as the parameter increases. In Bitcoin's case, the probability of double spending drops exponentially as the blockchain size on top increases, but is not negligible for k = 6, especially when the adversary is powerful.
To address your more concrete point that this is economically feasible: You are right that you can transfer $2M in a single bitcoin transaction. However, I find it unlikely that the recipient for such a transaction would consider it safe after k = 6; a value close to k = 25 must be used. It is sensible to accept lower values of k for smaller amounts and require larger values of k for larger amounts. While the exact probability is difficult to calculate, still most exchanges and other automated services accepting cryptocurrency payments apply reasonable bounds and I expect that they increase them for amounts that are in the millions of dollars (typically this is done by requiring human approval of a transaction for extremely high-value transactions, which definitely gives plenty of time for proper proof-of-work on top). The economic cost of forking the chain to cause block abandonment is briefly analyzed in the paper On bitcoin as a public randomness source. Given that analysis, one can balance the cost of forking the blockchain against the potential gains one could earn by performing a successful double spend, multiplied by the adversarial probability of success calculated from Backbone. This can allow a party to precisely determine their desired value of k for various monetary parameters, given precise adversarial bounds such as q = 0.3.
I know this answer was a bit technical and did not give many concrete numbers, but I hope it shed some light into why the attack you're describing is indeed possible even though we still would call it "negligible". Since you asked for my credentials, I am a PhD student in Cryptography focusing on the foundations of blockchain protocols at the Computer Science department of the University of Athens. Aggelos Kiayias, who wrote the Backbone paper, is my advisor (I did not contribute to that paper). As he is my teacher, I am quite familiar with his work, especially because we're using the model developed in backbone for subsequent work. I am a research fellow at IOHK where we are building the foundations of a cryptocurrency we call Cardano and analyzing it from a mathematical point of view. Probabilities of adversarial success in attempts to perform blockchain forks as well as their analysis come up in my own work in which I'm trying to construct sidechains interfacing multiple blockchains. We often prove negligibility bounds in these settings.


text:
Array of individual transactions from blockchain.info
As a little learning/hobby project i'm writing a little c++ program to extract a list of transactions from blockchain.info and show it visually.
I was hoping i could iterate through blocks, taking each TX and then extract into an array a list of transactions. i.e.
Block/transactionID/sending_address/amount/receiving_address etc
Ive connected to blockchain.info and can iterate through each block using jsoncpp. But if i look at an example like this:
https://blockchain.info/block-height/100001?format=json
...and specifically transactions like this:
https://blockchain.info/rawtx/8131ffb0a2c945ecaf9b9063e59558784f9c3a74741ce6ae2a18d0571dac15bb
Will the sum of inputs always match the sum of outputs?  How would i marry up which input sent what amount to each output when there is more than 1 in each?
Many Thanks.

Please do not delete questions once they have been answered, as it causes confusion for future readers with the same kind of problems

nice - but I promise, it will not be a "little" project :-)

Will the sum of inputs always match the sum of outputs?

no! There is a general rule, that whatever is the difference, will be miner fees. To be more precise, the miner is free to take it as fees. So this is a reason why you should have always "return" addresses in your transactions.

How would i marry up which input sent what amount to each output when
  there is more than 1 in each?

The idea of bitcoin transactions is, that they are not linked directly to  addresses, but to previous transactions. And they are not "divisible", but more "additional". I try to explain: funds are transferred from a previous transaction to a new location. Your wallet software might easily handle several addresses. If you send from your wallet to a new target, the wallet might have to take 2 or 3 or 4 previous tx, to send to new address, cause the funds on the single tx where insufficient for the total amount. In this sense, you (your C++ code) can only "match" inputs to outputs (with the derived addresses). Many huge transactions have hundreds of inputs and/or outputs - imagine faucets or exchanges: they create 1 transaction, with many payouts to different owners/users (e.g. https://blockchain.info/de/tx/2062a2717ca2f77c6935ff685d33086aa5db2f554ecd4d5232432cf9cb6a4006).
Taking your example: one can see that 5 inputs were required, to spend 250BTC to 15xif4SjXiFi3NDEsmMZCfTdE9jvvVQrjU and 1mio Satoshis to 1NkKLMgbSjXrT7oHagnGmYFhXAWXjJsKCj. That's nearly all you can say, what happened in this tx. The analogy from Andreas (and his book "Mastering Bitcoin", online readable, highly recommended) is FIAT money. You have maybe 10, 20 and 50 Euro bills in your wallet, but don't know from whom. Now you want to pay 35 Euros. So you give 50, and receive maybe 3 times 5 Euros as change. You still don't know, from whom they came, but just the amount. These "three times 5 Euros" could then be used as 3 inputs for a new 15 Euros transaction.

(1) Not an additional transaction, but an additional output from the same transaction.  (2) Yes.  (3) Yes, when an output is listed as the input of another transaction, that output is marked as spent, and any further transaction listing it as an input will be considered invalid.  So those outputs are shown as "spent" because there has been another transaction showing it as an input.  In the example you linked, output 0 of this transaction was spent as input 4 of transaction 2b62b3c433bda7a845466e4ec100cad9347f8c039bcc6d78d56f52d8ecb7671e.


text:
createrawtransaction and fundrawtransaction
I use createrawtransaction  for create a rawtransaction with [] "zero inputs" and one output.
I use fundrawtransaction for populate rawtrasaction with inputs.

{"method":"createrawtransaction","params":[[],{"mv8sTXT1FSAJENZNNoKb3BAHnersrC9c41":0.1}],"id":"null"}

{"method":"fundrawtransaction","params":["RESPONSE-CREATE-RAW-TRANSACTION",{"feeRate":"0.00031744"}],"id":"null"}

My question is, how many confirmations are the inputs added by fundrawtransaction? Can I configure the confirmations that the inputs will be selected?

There are many more parameters than number of confirmations for input selection.  It mainly depends on the amounts used in the outputs because eventually enough inputs have to be used to cover the costs, which means unconfirmed inputs might be used if that's all what the wallet has.
If you want to control the number of minimum confirmations that an input must have before it's considered available for funding, there are two options:
spendzeroconfchange=0 will tell the wallet never to spend an unconfirmed input (0 disables spending, 1 enables it and is default), and txconfirmtarget=6 which will means that an input must be buried beneath at least 6 blocks.
You can change 6 to be something else.


text:
Is it possible to send BTC out of an exchange account, in order to bypass the private key management system
Inspired by this other question, I wanted to ask a question related to how the private keys are managed by the different exchanges.
The question is: do any of the exchanges allow the sending of bitcoins to external wallet addresses?
(My reason for asking this is that I was thinking it would allow the user to send bitcoins to an address controlled by himself and then get around the enforced private-key management system.)

Yes, all exchanges allow this.  They have to, because this is how you withdraw or spend coins from the account.  It's not any kind of sneaky workaround, just normal behavior.
However, you can only trade using coins (or dollars) that are held on the exchange, so if you do this, you won't be able to sell them on the exchange until you send them back (redeposit).  This incurs another transaction fee and takes time for confirmation, so it's not an option for people who want to be able to trade rapidly or sell their coins quickly when the price moves.
(Decentralized exchanges may be an exception.  I know less about how they work.)

thank you NateEldredge. So the only risk for the exchange then stealing the coins would be before it is sent out to the external address, is that correct?

@coderworks: Yes, that's right.


text:
Can I import wallet words more than once?
I am trying to transfer my electrum wallet, which was imported from
MultiBitHD. I just found out that Electrum is not compatible with other wallets since it doesn't use a BIP39 seed. Can I use my old MultiBitHD wallet words although they have been used for recovery once?

I guess the question would be whether the coins are still in addresses associated with the original seed.  Some wallet software will "sweep" imported wallets by transferring all the coins to a new address generated from the software's own seed.  Or if you have spent coins from those addresses, the change might similarly have been sent to a new address.  I don't know how Electrum handles this, but maybe someone else does.

Yes you can as many times as you like. Electrum does support restoring from bip39. It's just that native electrum seeds don't use bip39. Multibit developers actually created a video advising people to migrate to Electrum using their multibit seed.

If you are sure the old wallet has not been compromised, you can use the old BIP39 seed again. The seed represents the private key that stores your coins so using it once does not make it invalid since the point is to be able to recover your coins with just the seed.
On the other hand, it shouldn't be too hard to generate a new BIP39 seed that you can use and be sure isn't compromised.


text:
How much bitcoin do companies have on their balance sheets?
How much bitcoin do publicly-traded companies currently have on their balance sheets?  Is the information available online?  If so, where can it be found?

my guess is zero. in total.

Are there any updates on this?  Aganju is guessing that companies don't have any bitcoin on their balance sheets while RonJon is saying the bitcoin gets reported as cash.  Is the new International Accounting Standards Board standard mentioned by ApplePie available now?  With all the talk of bitcoin in the news everyday, I'd be surprised if companies don't report their bitcoin to shareholders.

As of Apr 28 2021 it appears Tesla had $2.5 billion of it  - https://www.cnbc.com/2021/04/28/tesla-is-now-sitting-on-2point5-billion-of-bitcoin.html - why can't they specify it as BTC rather than USD..

This website provides the Bitcoin treasuries of companies :
https://bitcointreasuries.net/

If a public company accepts bitcoin, it would be recorded on it's balance sheet as Cash.  You might be able to discover the amount by getting lists of companies that accept Btc and then looking it up in their annual (10-K) and quarterly (8-Q) reports on EDGAR (https://www.sec.gov/edgar/searchedgar/companysearch.html).

accepting bitcoin would be different than owning bitcoin as a capital investment or as use in inventory in a project where the bitcoin is fuel for a computational process, and so would likely be in different places on the sheet if recorded at all.

@CQM correct.  Given it's price volatility, I'm dubious that in Jan 2018 many companies own Btc as a capital investment or as use in inventory in a project.  But they do accept it as payment, acting as Cash in a volatile foreign currency.

"If a public company accepts bitcoin, it would be recorded on it's balance sheet as Cash." Can you give a reference to verify that this is an accepted accounting practice?  For instance, a business could accept chickens in payment, but surely would not list chickens as "cash".

@RonJohn I would definitely like a source on that claim that Bitcoin would be used as cash. The International Accounting Standards Board is working on a project standard on cryptocurrencies but it is not out yet so I am unsure where you obtained this info.

the Association of Chartered Certified Accountants (ACCA) says

cryptocurrencies cannot be considered equivalent to cash (currency) as defined in IAS 7 and IAS 32 because they cannot readily be exchanged for any good or service. Although an increasing number of entities are accepting digital currencies as payment, digital currencies are not yet widely accepted as a medium of exchange and do not represent legal tender.

...

digital currencies do appear to meet the definition of an intangible asset in accordance with IAS 38, Intangible Assets. This standard defines an intangible asset as an identifiable non-monetary asset without physical substance.

...

cryptocurrency is subject to major variations in value and therefore it is non-monetary in nature. Cryptocurrencies are a form of digital money and do not have physical substance. Therefore, the most appropriate classification is as an intangible asset.

Note: I have chopped out a few short quotations from a longer article. If you find anything surprising, you should read the full article for proper context.
So a Bitcoin holding in a business that follows the accounting rules mentioned by ACCA would show up as part of intangible assets in published accounts. It might not be separated out.


text:
Understanding Bitcoin fees
I am thinking about buying some bitcoin. I understand the risks and I am going to use the little money I have left at the end of the month. I have plenty savings as well, so I am not using all of my savings to bet on bitcoin. I just want to invest a very small amount to understand the mechanics of it.
I am trying to understand Etoros' fees as described here: https://www.etoro.com/en/customer-service/fees/. Coinbases' costs seem to be much simpler to understand.
To help me understand Etoros fees. Say I had £250 to buy today and I sold for £250 this time next week. What would the Etoro and Coinbase costs be and when would they be payable?
Also what is a pip? I understand it to be 0.001p but I could be wrong.

It's a bit apples and oranges. At Coinbase you are actually purchasing cryptocurrency that you then own and can move elsewhere if you wish, whereas at eToro you are opening a CFD (contract-for-difference) position, which is similar to trading futures in that you don't actually own any bitcoin but are rather speculating on the price movements of bitcoin.
At Coinbase, you pay a percentage of your total purchase price. You also pay a percentage fee when you sell. (Sidenote: By using their associated trading exchange GDAX, you can avoid paying these fees, but you'll need to learn how to use their interface).
With eToro, you pay a fee each day your position is open. That is why the fees are listed as "OVERNIGHT FEE (PER 10 UNITS)".
The conversion fee listed on eToro (in pips) is for if you are depositing in a different fiat currency than USD and they have to convert it for you; it doesn't have to do with crypto specifically. A pip is the smallest trading unit of the currency in question. For most pairs it is .0001, however Yen-based pairs are only displayed to two decimal places so it is .01 in that case.


text:
Mimble Wimble chain privacy
Does Mimble Wimble automatically perform transaction cut-through, or is one able to retain a record of every single transaction (the entire blockchain) if they choose to?

MimbleWimble itself is just a general approach to building a chain, not a protocol.

Would you call Grin a protocol @PieterWuille?

MimbleWimble isn't fully implemented, so this answer may change as implementations mature and we gain a greater understanding of the design space.
MimbleWimble transactions may be published to the network individually or combined with other transactions before being broadcast. For example, a user may choose to publish a new transaction on its own, or to mix the transaction in an off-chain mixer that will then publish it to the network.
However, it is my understanding that once transactions hit the network, nodes forward them as-is. This means that regardless of whether the particular MimbleWimble implementation allows it, an attacker can watch and record new transactions as they are broadcast. This would allow them to reconstruct a transaction graph, albeit one without addresses or amounts, just randomly distributed elliptic curve points.

What implementation are you talking about?

@PieterWuille Good point, I was talking about grin specifically. I changed it to be more general.

There are some examples of cut-through that could happen before block building, but in general, no, while miners have an incentive to perform this cut-through, there is nothing keeping them from keeping their own record of all transactions in a given block.
Fortunately, the only information they have access to before cut-through are random numbers... no amounts or addresses, and not even IP addresses (thanks to dandelion). This can still create some kind of network graph, but is much more opaque than many other blockchains, and much less reliant on "plausible deniability."


text:
Merkle root vs message digest?
My question is in relation to the operational difference between a merkle root and a plain old message digest.
To calculate a merkle root I need to complete the following steps :

hash each transaction in a block
create a merkle tree from all the hashed transactions
work back up the merkle tree hashing pairs of transactions until I calculate the merkle root

To create a plain old message digest I would do the following :

Take all transactions in a block hash them at the same time to create a message digest

My question is, how is a merkle root more beneficial from an operational standpoint than a plain old message digest?

Initially, they appear the same, only considering that there is a hash included in the block.
A Merkle Tree is more efficient to prove a transaction is included in a block since otherwise, it is necessary to have and hash each transaction to prove a transaction is included using a message digest, so a full node can do this, but an SPV client (and a pruned node looking outside the blocks it has kept) cannot.
There is some more information on how this works in these answers: Merkle Root and Merkle Proofs

So both a message digest and a merkle root provide the same function, but a merkle root is more efficient?

@T-Pane Not completely the same function, only initially. If I have Message Digest I cannot change one single thing, as you understand the same is true for Merkle Tree but, I can walk a Merkle Tree. The technique is given in this answer.


text:
C-lightning lightningd crashing
To run a lightning node I followed the instructions here: https://medium.com/@dougvk/run-your-own-mainnet-lightning-node-2d2eab628a8b except that I downloaded and installed bitcoind and lightningd from source and not in a docker. I can fund my on-chain wallet, connect to peers but when I try to open a channel the daemon crashes, with the following message in crash.log:
+61107.734361005 lightningd(30005):BROKEN: wallet_channel_save: UPDATE channels SET  fundingkey_remote=?,  revocation_basepoint_remote=?,  payment_basepoint_remote=?,  htlc_basepoint_remote=?,  delayed_payment_basepoint_remote=?,  per_commit_remote=?,  old_per_commit_remote=?,  local_feerate_per_kw=?,  remote_feerate_per_kw=?,  channel_config_remote=? WHERE id=?: no such column: local_feerate_per_kw
+61108.166336903 lightningd(30005):BROKEN: FATAL SIGNAL 6 RECEIVED

What does local feerate per kw mean? To set the tx fee of bitcoind I followed the instruction from the blog post:
bitcoin-cli settxfee 0.0004
Thanks!

It appears that the database schema update was not successful. Meaning the database is not in a known good state. I'd suggest closing any open channels, withdrawing all funds from this node into an external wallet, moving the database (or the entire .lightning directory) and then restarting the client to create a fresh database.
This version is also really old, so the issue has most likely been addressed in the meantime.


text:
When was the last time a block was solo-mined?
Was curious about it the other day, what would be the quickest way to check for the last block payout minus the transaction fee to know when the last block was solo mined?
Thanks.

It is impossible to know whether a block which has no identifying characteristics (i.e. the miner did not put some sort of signature text in the coinbase) was solo mined or pools mined.
The payout values have nothing to do with solo mining.

But if a block is pool mined wouldn't it be split between many people as compared to a solo mined block that will only be paid to one address?

The mining pool company get the whole reward (all the 12.5 bitcoins + fees) and AFTER THAT, the pool splits the money and sends it to the pool members (often in $). The rewards + fees are often paid to only one address (the address of the mining pool company).

@Alpha: Well, I think some pools have used the coinbase transaction to pay out to members.  But it may not be common practice anymore.  Conversely, a solo miner could pay out his reward to many different addresses - all belonging to him (to disguise their ownership), or some to other people to whom he owes money.  Either way, it's true that this aspect won't distinguish pools from solo miners with complete accuracy.

@Nate Eldredge, creating a coinbase transaction with [number of miners] outputs wastes a lot of space and you don't get fees for that. I think, they prefer getting more fees by including other transactions nowadays.

@Alpha: Well, you have to pay those miners eventually.  If not in the coinbase, then in an ordinary transaction.  If you put that transaction in your own block, it wastes just as much space.  If you put it in someone else's block, you pay that amount in fees.  Seems to me it all comes out in the wash.

@Nate Eldredge, I aggree. But the other way would be: the mining pool sells the coins in a "1input-1output-transaction", gets dollars and pays the miners in $.


text:
Multisig Who puts second signature into the script?
I know how the script work together, but the Multisig is still confuse me.
input script:
OP_0 [A's signature] [B's or C's signature] [serialized redeem script]
how the transcation being created,
For example, "A" create a transaction, he can put a signature into the script, but where is the B signature from? A's wallet definally no B private key!
Logically, the transaction must send to B, then B put a signature into the script, right?

After "A" signs the transaction hash the hash gets updated to show his signature. "A" will send this partially signed transaction hash to "B" who will then sign that hash which will then return a third hash reflecting two valid signatures. Assuming only 2 signatures are required to spend, this third hash is what gets broadcast to the network.

I mean, how the node B know that the A make an incomplete transaction? broadcast to the network? and the other nodes will help forward incomplete transaction to B?  I just don't see where the B get the transaction because they are two nodes on the Internet, many examples doing manual or making the signature in the same node.

"and the other nodes will help forward incomplete transaction to B?" No. The incomplete transaction hash is sent to "B" through any communication channel they choose, including but not limited to, email, text, in person, or on paper.

Basically @m1xolyd1an answered it, I extend it a bit. So you would have a funding transaction, which send some satoshis into the multisig transaction. Usually to a "type 3" address, which is the hash of the redeemscript, converted into a bitcoin address.
Then you want to spend this transaction, and the conditions are outlined in this redeem script. You provided the script already, the part of the redeemscript would look for a 2-of-3 like this:
52[pk1][pk2][pk3]53ae

You would then create a first tx ("createrawtransaction") to sign it ("signrawtransaction"), and then take the resulting hash to sign with the other private key which increases the length of the tx. And then you'd send it to the network. You can redo this fairly easy example on testnet or on your regtest env, Gavin provided a very good step-by-step example long ago.

Who puts second signature into the script?

This can be yourself, when you use a cold storage concept, this can be a second person, to which you give the hash to get it signed.
Oh, as this is very basic of bitcoin, I recommend also to have a look at Andreas' book "Mastering Bitcoin", in chapter 7 on multisig. The book is online readable.


text:
How do Lightning channels interact with the blockchain?

Does opening a channel mean that a 2-to-2 multisig address (3xxxx) is created? And then both parties put money into the address? What if someone pays money to the address on main chain while the channel is open?
Does closing a channel mean that a transaction is made which splits the money based on agreement:
multisig: signature1,2(preTran) redeemscript
outputscript:  pay to A
               pay to B

Does opening a channel mean that a 2-to-2 multisig address (3xxxx) is created?

Yes. But it's not always a 3... address. Such addresses must be segwit, and there are two types: nested (3... address) and native (bech32 addresses, bc1..).

And then both parties put money into the address?

For now, only one party puts money into the address. But ideally both will be able to in the future. This is only done for simplicity right now.

What if someone pays money to the address on main chain while the channel is open?

It doesn't matter because Bitcoin does not use a balances or accounts system. Spending Bitcoin means that you are spending from a previous transaction output. So the commitment and closing transactions in a channel will refer to a specific transaction output. That output is completely unaffected by additional payments to an address. Likewise such payments will not effect the channel state.

Does closing a channel mean that a transaction is made which splits the money based on agreement

Yes. The money is split according to the most recent channel state, i.e. the balance of each party.


text:
How many transactions will be created in a Lightning Network channel
In a typical Lightning Network channel, how many Bitcoin transactions will be created per state of the channel that may end up on-chain ?

I completely rewrote your question and gave a detailed answer. Hope that's what you meant with your attempted description of the process of a channel.

The number of transaction per Lightning Network channel may change depending on two main
factors:

The type of channel used.
As a protocol in development, the Lightning Network specifications may change. This
includes the specification of the transactions used for each channel state. For instance,
the "Anchor Outputs" proposal which was merged in 2020 included a complete rewrite of the
transaction tree.
The number of payments being currently routed through the channel (HTLCs in flight).

The following description is for a non-"anchor outputs" channel.
Without any in-flight HTLC
The channel begins with:

The funding transaction (onchain)
Two commitment transactions (one for each participant)

So we are at 3 transactions. But there is a quirk (there is always a quirk!), each of
the transaction pays to:

The remote party
The local party after a delay OR the remote party with the revocation key.

Since i want the count to showcase the complexity of the client implementation, i'm going
to include the special transactions in the counter.
Note that the specifications call the "simple outputs" (basic P2WPKH, as an onchain
payment) as being resolved, and the "contract outputs"[*] to not be resolved until a
"special transaction" spending it is confirmed.
It therefore brings us to 7 transactions:

1 revocation transaction per party
1 delayed transaction per party

Now, let's add some real complexity.
Adding the HTLCs
Lightning Network channels are bi-directional, therefore both parties can offer or
receive an HTLC. Intuitively.. HTLCs are translated into outputs than can be in both
these states (offered or received) in both the commitment transactions.
So you can have:

An HTLC offered by the local party
An HTLC received by the local party
An HTLC offered by the remote party
An HTLC received by the remote party

As well as any combination of the above.
For an HTLC offered by the local party, an "offered-htlc" output is added to the local
party's commitment transaction and a "received-htlc" output is added to the remote party's
commitment transaction.
Each of these outputs are the first stage of the onchain HTLC resolution, they are later
finalized in a second-stage pre-signed "HTLC transaction", and finally sweeped by a
"special transaction" (the same kind as those in the first section: delayed or revocation).
An offered HTLC output in the local party's commitment transaction may be spent by:

A "preimage transaction" (to the remote party -- ie "successful-but-quite-long payment")
A revocation transaction (to the remote party -- you need to prevent cheating at each step of the process)
A pre-signed "timeout transaction" which may then be spent by either:

A delayed transaction (to the local party -- ie "cancelled payment")
A revocation transaction (to the remote party -- we can still cheat at this point!)

A received HTLC output in the local party's commitment transaction may be spent by:

A timeout transaction (to the local party -- that's the cltv_delta configuration on your node)
A revocation transaction (to the remote party -- as usual)
A pre-signed "success transaction", which may then be spent by either:

A delayed transaction (to the local party -- ie "successful-but-quite-long payment")
A revocation transaction (to the remote party, -- still to decincentivize cheating)

This brings us to 10 new transactions per commitment transaction for two HTLCs in flight
(one in both direction).
Summing it up
For the example i've showcased above it brings us to:
7 # Nuked channel
+ 10 # htlc offered on one side, received on the other one
+ 10 # htlc received on one side, offered on the other one
= 27

That's for one channel state (the next one will use new keys!) for the common scenario of
being currently forwarding a payment in both directions.
To answer your question precisely, the number of transactions per state may vary between
7 (no HTLC) and 7 + 483 * 5 * 2 = 4837 (maximum number of HTLCs in both directions).
Note that the latter is unrealistic as the maximum number of in-flight HTLCs is currently
bounded on implementations in order to avoid DOS.

More resources:

The BOLTs if you want all the nitty-gritty details:
#5
(onchain) and
#3
(transactions) cover this.
This post by Rusty Russell -- outdated but still
gives the intuition. Touchs also the challenge of managing the keys.

[*] Terminology mine on this one

Yes, however, this created infrastructure you reference has the capacity to support many transactions on LND before the channel is closed, reducing the overall number of transactions on the blockchain probably significantly.

i know they can make thousand of transactions during channel open. the third lock-time transaction in optional or have to? if I don't have lock-time transaction that is mean you could lost your money by unnormal situation

The third and fourth transactions conflict with each other as they spend the same inputs so only one can become confirmed.


text:
bitcoin soft-fork how are the older nodes going to the verify new transaction?
I know soft fork which is compatible with older rules, but how are the older nodes going to the verify new transaction?
for example :
block#100 there is a new rule transaction.
the miner who created block#100, it must be a new rule's miner? and how the older nodes verify new transaction?

You're confusing what happens during a soft fork and a hard fork slightly.
A soft fork is backwards compatible, meaning old nodes will still accept the softfork transactions.
Hard forks are not backwards compatible, meaning old nodes will reject the new hardfork transactions.
Think of it like this: there is a list of consensus rules. If you want to change the rules, there are two fundamental ways to do this: make the rules more strict (no longer allow something that was allowed before), or make the rules less strict (allow something new).
If you make the rules more strict, then all of the old nodes will still accept everything you are doing. This would be a soft fork.
If you make the rules less strict, then all of the old nodes will reject the new things you are doing. This would be a hard fork.


text:
In Zcash, what statements do zkSNARKs prove?
Zcash uses zkSNARKs to hide transaction details. My understanding is that the verifier is anyone that maintains the blockchain. My questions are:

If I decide to send x amount of Zcash to another user, what is the statement that zkSNARKs will hide?
In particular, is the transaction graph still public?

Would you take a look at protocol.pdf, https://github.com/zcash/zips/tree/master/protocol ? In particular "Each transaction has a sequence of JoinSplit descriptions" at 3.5 and "ZKJoinSplit.Proof is the zero-knowledge proof for the JoinSplit statement" at 4.3.

My understanding is that the verifier is anyone that maintains the blockchain.

All nodes that fully-validate transactions will be acting as zk-SNARK verifiers.

In particular, is the transaction graph still public?

The transaction graph for shielded transactions is as private as it is feasible to be.
When a note is created, a commitment cm to the note is made public (effectively a hash of the note). When the note is spent, its nullifier nf is derived (effectively another hash) and made public. To the person spending the note, the local transaction graph looks like this:
(... -> tx1 -> cm)[<--- note --->](nf -> tx2 -> ...)

But to all other nodes on the network, all they see is:
(... -> tx1 -> cm)                (nf -> tx2 -> ...)

That is, they see when some note was created, and when some note was spent, but without knowing the private information (and assuming they can't find pre-images for the hash functions), they can't directly link the two events. They can exclude certain combinations of transactions, however:

A note cannot be spent before it was created, so when a nullifier is published, everyone knows that it corresponds to some commitment that was published previously, but not to any commitment that was published later.
Some nullifiers and commitments can be reasonably excluded based on other revealed information, e.g. if an exchange's records get leaked, or if they are in transactions that also involve transparent inputs and outputs. In particular, if you send funds from a t-address to a z-address and then on to another t-address, you get basically no privacy. See my previous answer about this for more information.

If I decide to send x amount of Zcash to another user, what is the statement that zkSNARKs will hide?

The specific statement (for the Sprout circuit) being proved with the zk-SNARK (and therefore hidden) is given in section 4.9.1 of the Zcash protocol spec. Summarising its parts here:

Nullifier integrity: the published nullifiers correctly correspond to the input notes being spent.
Note commitment integrity: the published commitments correctly correspond to the output notes being created.
Merkle path validity: there is a valid path from the commitments of the input notes to the commitment Merkle tree anchor rt.

This enforces that the notes being spent were previously created.

Balance: The sum of the input note values is equal to the sum of the output note values (plus any funds entering or leaving the transparent pool, e.g. fees).
Spend authority: the provided spending key for each input note correctly corresponds to the public key the note was created for.
And a couple of other correctness requirements.

This is the majority of the consensus rules that get applied to transparent transactions. The only one missing is the double-spend rule, which is still checked outside the circuit (by checking that a nullifier has never been seen before).

The most high level view is that it proves somewhere exists some set of UTXOs and the sum of their values is equal or larger than sum of this transaction outputs. The exact shielded value is encrypted inside the transaction and is never disclosed.
Everyone who runs a full node and has access to the trusted setup data (which you have to download in order to run full node) can validate shielded transaction. Nobody, nevertheless, learns details of which exact UTXO have been used and what their values were.