text:
Do larger blocks make it harder for smaller miners to compete? Why?
During the discussion of Bitcoin’s scalability, I’ve read the statement that

"Large miners benefit from larger block sizes, because it makes it more difficult for small miners to compete." [1]

In the linked comment this is used as fact without explanation, but it isn’t obviously true at first glance. Please explain: Do larger blocks make it harder for smaller miners to compete? Why?

I’m aware that this may produce answers that are opinion based, yet believe that answers well supported by explanation could add progress to the community’s discussion. Answers without explanation will be removed.

Yes. There are reasons at multiple different levels.

Propagation related.

It takes time for a new found block to propagate around the world to all other miners. Bandwidth, network latency and validation times play a roll. It's also important to keep not just worst case numbers in mind, but even adversarial case. The average case isn't very relevant.
So assume propagation takes 1 minute (bit extreme but not unheard of), that means that miners that hear about the block 1 minute after it was created, have just wasted 1 minute of hashing work on the wrong block.
Assuming all else equal this will happen to large and small miners. However a 30% large miner will NOT have that problem for 30% of the blocks (their own blocks). Small miners will only NOT have it for their own 1%.
Similar logic applies to orphan blocks: 2 new blocks found by different miners at the same time. A 30% miner has a good chance of finding another block on top of their own, while for a smaller miner (all else equal) that chance is negligible. Meaning smaller miners will have a higher orphan rate.

Economies of scale related.

Almost by definition economies of scale are favouring larger players.
All kinds of discounts and better deals you can make when buying in bulk: equipment, electricity, accommodation, staff, security, DDOS protection, fast redundant internet connections... Pretty much everything you can get faster (latest technology) and cheaper when you're bigger.
Economies of scale are sort of naturally limited by diminishing returns though. At some point electricity doesn't become cheaper anymore if you buy more and at some point fixed overhead costs become insignificant anyway. It's hard to say when the combined benefits to growing further will stop being significant. But it can certainly push small miners out of business and make it that much harder and riskier to start a new mining company.
One economy of scale that sort of works as a disadvantage to larger miners is heat dissipation: it's a easier to get rid of waste heat (or even to use the heat productively) at small to medium scale. Large concentrated miners need special equipment to get rid of heat or it prevents them from operating in hot climates.

Larger blocks take longer to propagate. However, when you have solved a block yourself, there is no delay (regardless of the size), because you already have all of the block data and have already checked it.
So, let's say a miner has 40% of the network hashing power. They solve 40% of the blocks. That means 40% of the time, they have essentially NO latency in starting to work on the next block, regardless of block size. Smaller miners who might mine 1% of the blocks have to wait for the latest block to be propagated to them 99% of the time. So the larger miner will be affected by block propagation delays 60% of the time, whereas the smaller miner is affected by block propagation delays 99% of the time.
Since mining operations with a smaller portion of the hash power are disadvantaged in this way, it can lead to decreased profits and encourages centralization into a few large pools.


text:
How can I get Signet coins?
We had several requests for Signet coins (on Signet, the default signet¹) in the past week. This question is meant as a lightning rod to answer how to go about and where to direct a request for signet coins instead of asking for signet coins here on Bitcoin Stack Exchange.

¹ If you are looking for just any sort of testing environment, rather than coins on the default Signet, check out Is there a sandbox in bitcoin for testing?

Get Signet coins
Since Signet is centrally controlled, you only option is to get it from a faucet or ask for coins in the bitcoin-signet IRC channel. But depending on what is your goal, there are other great alternatives to signet which are easier to mine or test with.
Alternative testnets
Testnet
Testnet has a special rule, which makes it easy to mine in particular circumstances. If there are no blocks found for more than 20 minutes, the difficulty drops and you can easily mine a testnet block with a normal CPU. Obviously your luck depends on if other powerful miners are mining or not. I use this primitive bash miner script to mine and I found 6 blocks in less than 2.5 months.
Regtest
In many cases you don't need to test on a public blockchain, so why not run a local testnet? It works just like the Bitcoin network, but external connections are disabled and the mining difficulty is set to 0. This allows you to mine as many blocks as you want, making testing faster and easier.

Signet coins are worthless. They are used for testing Bitcoin software before deploying it on mainnet and protocol development experiments. The signet may be reset occasionally if any projects start to rely on signet for non-testing use-cases.
You can find faucets for small amounts on

signetfaucet.com
Pick an amount up to 0.01 s₿, be sure to follow the instructions under the request box.
alt.signetfaucet.com or signet.bublina.eu.org
Sent me 949 sṩ, when I tried again a bit later, told me to slow down. Both URLs lead to the same service.

Alternatively, you can try to send yourself some s₿ from ajtowns’s experimental "Proof-of-work based signet faucet". You can find the script to collect them in AJ’s GitHub repository GitHub.com/ajtowns/powcoins, and a long-form explanation of what’s going on on Delving Bitcoin: "Proof-of-work based signet faucet", or a short overview on Bitcoinops.org
If you need a larger amount, legitimate developers are encouraged to ask in the #bitcoin-signet IRC channel on Libera.chat. I suggest that you include your address in your request message and provide a bit of background for a higher chance to receive some coins.

I wonder why nobody mentioned that you can (and probably should) deploy your own signet: https://en.bitcoin.it/wiki/Signet#Custom_Signet

Starting your own Signet helps with having a test environment, but doesn’t put you on the Signet other projects may be testing on. Also see: https://bitcoin.stackexchange.com/q/17553/5406

There is a new signet that was set up recently, maybe you can contact the maintainer get MORE sBTC. Some useful information was here:
https://bitcointalk.org/index.php?topic=5501712.0

While this may be a good solution for some use cases, it should perhaps be pointed out that getting coins on one signet will not transfer to another signet, i.e. acquiring coins on this new signet will e.g. not able you to interact with users on the main signet.

source: Stack Exchange

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

sort: votes


text:
Where can I find a testnet or signet explorer?
We have several questions that boil down to "where can I find a testnet explorer?". Unfortunately, most of the answers on those questions are outdated.
I’ve started this community wiki to keep one up-to-date list of testnet and signet explorers in a single place. Please help to collect information from answers on prior topics and close those as a duplicate to this community wiki. Please mark any updates with a date.

Please update the date when you check every entry, otherwise add a new block with the current date.
Testnet 4 explorers
Last checked 2024-08-22:

mempool.space/testnet4

Signet explorers
Last checked 2024-08-22:

mempool.space/signet
explorer.bc-2.jp

Testnet 3 explorers
Last checked 2024-08-22:

mempool.space/testnet
blockchair.com/bitcoin/testnet
blockstream.info/testnet
live.blockcypher.com/btc-testnet
tbtc.bitaps.com

Defunct Testnet explorers
Last updated: 2023-12-19:

testnet.blockchain.info
testnet.btclook.com
tbtc.blockr.io
blocktrail.com/v1/tbtc
explorer.btc.com/tbtc
blockexplorer.com/l/en-US/testnet
test-insight.bitpay.com
testnet.coinprism.info/
biteasy.com/testnet
testnet.smartbit.com.au

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


text:
Why do standardness rules limit transaction weight?
What are the reasons and arguments for and against limiting the weight of transactions per standardness rules or even consensus rules?

The maximum standard transaction size was introduced in PR 2273. In this PR, the rationale is given as

Extremely large transactions with lots of inputs can cost the network
almost as much to process as they cost the sender in fees.

A similarly worded comment lives in the codebase today above the code that performs the check.
This limit was introduced at 100 KB; when segwit was introduced, it was changed to be a weight limit changed to 400000 weight which results in an equivalent 100 KB non-witness size limit.

While this provides the stated reason why the limit was introduced, I was hoping to get a broader overview of the arguments why (and perhaps why not) transactions should be limited in weight.

IT is a mystery why there is so little conversation on this subject, in the PR he mentioned.  To bad he didn't link from the PR to the broader discussion area.

Larger transactions would permit slightly more efficient, bigger consolidation or batched payment transactions as well as non-payment application such as e.g. novel second layer protocols that make use of large proofs. If economic demand for such transactions were established, the current standardness weight limit could prove fragile and easily be circumvented via direct submission to miners or private mempools. This could quickly lead to the standardness limit being obsoleted and transactions of any consensus-valid weight being accepted to mempools.
Reasoning about transaction relay, incentive compatibility and validation are significantly easier with smaller transactions, e.g. pinning, the quadratic hashing problem, dependencies in the mempool, etc.
But the biggest issue with larger transaction sizes is how it affects block template creation. Building the block that collects the maximum sum of fees is a variant of the knapsack problem and therefore NP-hard. Good solutions can be approximated with greedy algorithms, even better solutions can be computed e.g. with linear programming approaches per significantly more computational effort.
A greedy approach can provide an optimal solution up to the point where the tail-end of the block is reached. Once some selection options no longer fit into the block, the available selection options begin to depend on prior choices and finding selections that significantly increase the block reward may require traversing an exponentially growing count of combinations.
As the block subsidy is exponentially shrinking, block rewards are expected to be increasingly dominated by fees as time passes. As long as most transactions are significantly smaller than the block space limit, greedy approaches will be able to produce sufficiently close to optimal solutions for miners to not gain a significant advantage by throwing more computing power at finding better block templates.
If investing more computing power results in drastically higher block rewards, mining operations will have yet another efficiency of scale that makes mining less fair for smaller miners.
Large transactions significantly increase the portion of the block that can no longer be populated close to optimally with a greedy approach and therefore represent mining centralization pressure. It would also incentivize the emergence of centralized block template creators, undermining censorship resistance.


text:
How do I fix a stuck low-feerate transaction that was sweeping the wallet?
My friend is using BlueWallet. They created a 1-input-1-output transaction that sends all their funds, but used a feerate of 1.7 s/vB. The transaction has been subsequently stuck for a couple weeks, because no blocks have been including any transactions with feerates of less than 2 s/vB. I’m trying to advise them, but not intimately familiar with BlueWallet.
We considered using the RBF feature, but it doesn’t show up for this transaction. (Maybe because no other funds are left?)
I read that there is a "Cancel Transaction" feature, which I think will create a RBF transaction that sends the funds back to their own wallet. I guess that it should work, but they’ll have to pay two higher transaction fees in that case. I also considered sending a small payment to the wallet to provide funds for RBFing the original transaction, but then I’ll pay additional fees and they probably would not end up with an empty wallet. We do not control the receiving end, so we cannot CPFP the transaction.
The optimal mitigation would simply replace the original transaction with another 1-input-1-output sweep transaction that pays a sufficiently higher feerate.
Is there maybe a way to just "forget" a transaction with BlueWallet in order for them to be able to make a higher feerate sweep transaction? Is there some special-casing for transactions that empty a wallet that can be found in some advanced options menu? Would resyncing the wallet perhaps make the wallet software forget about this transaction? Do you have any other suggestions how to easily and/or cost-effectively create the replacement tranasaction or otherwise get out of this situation?


text:
How can a lightweight client make sure output has not been spent yet?
It's simple to prove the creation of a UTXO: You just need to provide the transaction data, the Merkle branch, and block of the creating transaction.
Then, as a full-node, it is simple to check whether the output hasn't been spent yet: You're keeping track of the UTXO yourself, and if it hasn't been removed from your UTXO set, it's still unspent.
As a lightweight client doesn't have the full UTXO set at hand, how could it make sure that an output is still unspent? I see that BIP0064 introduced a getutxo message, but can't seem to find more about it. Is such an interface still in effect? Is there an option beyond polling a number of different nodes for a particular UTXO, or running a full-node?

Clarification of what I'm interested in: I've recently read the paper Sybil-Resistant Pseudonymization and Pseudonym Change without Trusted Third Parties. The proposed system BitNym manages pseudonyms by storing them in transaction outputs. A pseudonym stays valid until the anchoring output is spent. It is therefore of interest to check whether an output is still in the UTXO set.

There are currently 115 or so nodes which will answer the getutxos message.  This is as good a source of this information as calling a 3rd party API.  The problem with both of these sources is that they do not provide cryptographic proof.
It's not actually possible to prove an output unspent, for the simple reason that it may have been spent in a block found an instant after the proof was produced.
The idea of UTXO commitments would have miners publish a digest of the entire UTXO set in every block, which could be referenced to prove that a specific UTXO was unspent as of the lastest one, but you're probably also interested in any unconfirmed spends that are floating around out there.
It may be a better idea to ask your peers to try to prove that an output is already spent.  Only confirmation should build your confidence in an incoming payment, but a spend proof in the form of a conflicting transaction (+ merkle branch, if found in the chain) can instantly lower your confidence to zero.

UTXO commitments seems to be exactly what I was looking for, thank you. The nodes are the XT nodes, right? I've edited the question to clarify what I am exactly interested in knowing.

As a lightweight client doesn't have the full UTXO set at hand

I assume you're right and in addition to your second message, I suppose the only way to check UTXO without BIP64 is to call a full node.
Here is a simple exemple to do that :
curl "https://bitcoin.toshi.io/api/v0/addresses/12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX/unspent_outputs"

from https://toshi.io/docs/#get-address-unspent-outputs

I don't think an SPV node can know for sure for 0-conf transactions.
However, once the transaction is in a block, the full node will provide you with a Merkle path proving that this transaction is part of that block. So then you're sure and if you also keep track of the PoW and subsequent blocks you can count how many confirmations the transactions has.

Yeah, the proof of the contrary is trivial, no question. I am however actually wondering about the stated problem: How can a lightweight node be reasonable sure about an output not being spent yet?

Ah you mean the question as "without waiting for a confirmation". Another way would be to trace back the input of the transaction all the way back to the coinbase transaction(s). Downloading only the (parts of the) blocks that are relevant along that graph. That could add up to serious amounts of data (worst case the whole blockchain I guess). However, if UTXO commitments ever become a thing, a light client might do the above tracing only until it has a UTXO commitment. Or depending on how the UTXO commitments will work, no tracing at all: every block contains a delta to update the UTXO set.

No, I mean, that it is still in the UTXO set.

I've edited my question to clarify my interest.

It appears that BIP64 was reverted soon after it was merged, and only lived on in BitcoinXT as Mike Hearn originally introduced it for his Lighthouse application. The getutxo message is also not part of Bitcoin Classic, as Classic was forked from Core, and not from XT.
Therefore, it seems to me that being sure an output is still unspent is only practical by running your own full-node to query with gettxout.
Please feel free to correct me, if the above is not accurate.

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


text:
What is the memory usage for checking transaction inputs?
Whenever a transaction is received by a node, the node verifies its validity. To that end, it checks for each transaction input whether that input is part of the UTXO set. It is my understanding that the UTXO set is stored in the chainstate database, which is held in a LevelDB structure.
I previously thought that he UTXO set was kept available in memory, but since I've learned that it is currently about 1.2GiB in size that seems unlikely.
So, I assume the chainstate-db is stored on disk, but accessed multiple times per second to check transaction inputs. What amount of memory usage does this induce on a node?

It needs to be stored on disk to preserve it when closing and then opening the application. However most (or on systems with enough memory: all) of it is also in RAM. Every time it needs to scan through the UTXO set, it will load the used chunks into memory and keep them there as long as possible. I imagine after a few scans most of it will be in memory. If it does not fit in memory, it will quickly increase the disk I/O and slow everything down.

You are right UTXO set is stored on disk on .bitcoin/chainstate directory using leveldb. It is stored in compressed state and the current size is around 1.5GB
To speed up access bitcoind uses an in memory cache which can be configured using -dbcache option.

So, I assume the chainstate-db is stored on disk, but accessed
  multiple times per second to check transaction inputs. What amount of
  memory usage does this induce on a node?

Accessing the leveldb database itself is like accessing any other nosql database. You basically lookup the key which is the utxo and get a value as output which you need to deserialize and store in a memory variable

So, essentially, it'll fill -dbcache amount of memory long term with some spikes whenever I access the db?

Yes, there is also memory taken by mempool which can be controlled by maxmempoolsize.  Also there are some minor caches maintained by leveldb and other parts of code which I am not aware of. These are memory cache options documented for configuration in bitcoin

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


text:
How does Bitcoin Cash implement replay protection?
Bitcoin Cash says that they are providing replay protection for their fork. How does this replay protection work?

Bitcoin Cash (aka Bitcoin ABC aka UAHF) provides two methods of replay protection, both of which are opt in. If you do not create transactions which use these features, then your transactions are vulnerable to replay.
The first method is a redefined sighashing algorithm which is basically the same as the one specified by BIP 143. This sighash algorithm is only used when the sighash flag has bit 6 set. These transactions would be invalid on the non-UAHF chain as the different sighashing algorithm will result in invalid transactions. This means that in order to use this, you will need to transact on the UAHF chain first and then on the non-UAHF chain second.
The second method uses an OP_RETURN output which has the exact string:
Bitcoin: A Peer-to-Peer Electronic Cash System

as the data of the OP_RETURN. Any transaction which contains this string will be considered invalid by UAHF nodes until block 530,000. This means that prior to block 530,000, you can split your coins by transacting on the non-UAHF chain first with the OP_RETURN output, and then transacting on the UAHF chain second.
Update: They Bitcoin Cash specification now requires that all transaction use the redefined sighashing algorithm as explained for the first method. This means that there is now two way transaction replay protection; transactions made on the Bitcoin ABC chain will be invalid on the non-ABC chain and vice versa.

2 questions: does the UPDATE portion of your answer mean that replay protection is not opt-in anymore? and second: you seem to be speaking in a very theoretical way (referencing to the spec), but do the implementations, as of now, respect this spec?

Replay protection is mandatory now and will be enforced by BCC wallets and nodes. 2. BCC wallets have probably implemented all of this now since they have forked off of the Bitcoin network. At the time this was written, many BCC wallets were not complete nor was their spec complete.

in other words, replay protection is not opt-in anymore, right?

Yes, replay protection is not opt-in. Although they have still kept the OP_RETURN thing in for some reason.

Ok two more questions: by this logic, it's not opt-out either, right? And last but not least: does the 530,000 magic number still hold? AFAIU the first exclusive (or divergent, let's say) block of BitCash is 478,559 so do we have to wait to use this automatic replay protection?

No, it is not opt out either. The replay protection with the sighash thing is mandatory. The 530,000 block wait is unrelated to this mandatory replay protection. That only applied to the opt in one with OP_RETURN

@AndrewChow Just confirming "Mandatory" implies that the protocol will reject those or is it just a "recommendation"? Sometimes the two terms are mixed in specs.

It is mandatory in that any transaction that does not use the redefined sighashing algorithm will be considered invalid and rejected. All transactions must use that sighashing algorithm.


text:
Are there drawbacks to the Thin Block patch?
Mike Hearn talked about a patch he applied to BitcoinXT recently in his AMA:

I posted a patch last week that makes XT download blocks as lists of hashes instead of duplicating the transaction data, so a full 1mb block would drop to about ~70 kilobytes, in theory, if you were online for the whole time since the last block. However, the patch needs more work and testing before it can be shipped to users.

If I understand correctly:

Blocks themselves would stay exactly the same.
Transactions only need to be downloaded once (instead of once or twice)
Each node reassembles the block from this "ingredient list"
Missing transactions can be requested from peers by transaction hash.

This would reduce the total traffic to transfer a full block roughly from 2MB to 1.07MB. This seems like an obvious improvement of the current status quo which could be introduced cheaply, especially reducing the network load during the peak demand right after a block is found.
Are there any drawbacks that I'm missing?

I think the primary drawback is that it makes it harder to build another client from the ground up, because more state needs to be kept in memory when accepting and processing a newly mined block. Otherwise the concept is functionally equivalent to the existing system.

@Nayuki: Not sure I understand what you mean. From what I understand regular block propagation would continue to work as before, running the thinblock patch would be optional.

Compact Blocks in Bitcoin Core provides similar functionality (see BIP 152 for spec). The main improvement is in the way it gets rid of bloom filters, as those add a DoS attack risk.
There's a bit more in commentary from nullc (Gregory Maxwell) in this thread on Reddit


text:
How does the Lightning network work in simple terms?

Could you please describe how the Lightning network is supposed to work?
How does it scale better than pure blockchain transactions?
What are the advantages and disadvantages of Lightning Network and blockchain transactions?

People need to understand that graphic visualization and "scenes" are the best way to describe sequential processing and depdencies.. rather than looking at a wall of text

@neaumusic: It was on my todo list for a while, but I finally came through!

The Lightning Network is a collection of payment channels between pairs of nodes. To create a payment channel, two users commit funds to a UTXO under shared control. The shared funds allow the users to pay each other by changing how much they will pay out to each eventually.  The state of the payment channel is stored in presigned Bitcoin transactions that spends the shared funds back to the individual users. As long as neither broadcasts the final state of the channel to the Bitcoin network, you can think of the funds in the channel like beads on an abacus—they can only go from one side to the other, but cannot leave the channel. By having multiple channels, users can forward payments from one peer to another, allowing payments between peers that don’t have direct connections. The Lightning Network allows for instant payments with a significantly compressed blockchain footprint.
Let’s say that you and I want to open a payment channel.
1. Putting funds into Lightning
We negotiate to each send 0.05 BTC into a shared 2-of-2 multisig output, the channel funding output.¹ This will require a transaction on the Bitcoin blockchain.

As a “balance sheet” and escape hatch, we negotiate a 2-of-2 multisig transaction that pays out 0.05 BTC to you and 0.05 BTC to me. We call this the commitment transaction.

The commitment transaction comes actually in two variants. I sign your commitment transaction and give it to you. If you want to put it in effect, you need only add your own signature and broadcast it to the Bitcoin network. Vice versa, you sign and give me my copy of the commitment transaction. The commitment transactions are future transactions for the Bitcoin network, they're just not valid yet because we have not actually created the channel funding output yet, and because they are each missing one signature. The commitment transaction comes in two variants because the copy you and I hold are asymmetric: your commitment transaction puts a timelock on your Settlement Output, and mine locks my Settlement Output. We’ll see below why we need that.

The commitment transaction guarantees that either of us can close the channel and return the funds to our respective controls by themselves. Now that we are confident to be able to to get back our funds, we can sign and broadcast the funding transaction:

We are later going to use the following shorthand to represent a channel and its current balances:
2. Payment
Now, I want to pay you 0.01 BTC. We each create a new commitment transaction ("balance sheet") as before, but this one says that you get 0.06 BTC and I get 0.04 BTC. Each of us gets a new commitment transaction signed by the other to that effect as before.

To make sure that neither of us can use the old commitment transaction the other signed previously, we each create a justice transaction to prevent cheating. The justice transaction allows the channel partner to spend our timelocked output from our first commitment transaction to the themselves if we use the outdated commitment. If we use the correct commitment, the funds go to ourselves after the timelock passes, until then the counterparty can take the funds if we cheated.
I.e. when I try to activate the (now obsolete) 0.05 - 0.05 BTC balance sheet, my paid-out funds are locked for a number of blocks. This gives you time to broadcast the justice transaction in which I signed off on my 0.05 BTC output being sent to you.

It's safe for me to give you your justice transaction, or really to anyone, because the justice transaction will only be valid as a response to the fraudulent use of the old commitment transaction.²
With the setup as described above, I'd have to come online before the timelock expires to catch an attempt at cheating, but obviously it wouldn't be safe for me to keep payment channels open if I might be offline for extended periods. Luckily, there are watchtower services that take a small payment to monitor for cheating and can broadcast the justice transaction on your behalf when they detect it.
3. Network payment
Alright, now you and I can send money back and forth thousands of times, with almost instant effect (depending only on how fast we can communicate with each other) without adding any additional transaction to the Bitcoin blockchain. Yet, on the other hand, if one of us ever tried to defraud the other, they would be instantly taken to court by having the dispute resolved on the blockchain to their own detriment. Pretty spiffy, but not terribly useful yet.
By the theory of six degrees of separation, everyone is connected to any other participant via only a few hops.
Let's say you are getting some coffee from Bob the Barista. You do not have a payment channel with Bob, but you have the channel with me, and both Bob and me each have a payment channel with Alice. Let's assume that each payment channel has 100 m₿ in it, split equally.
Our "network" now looks like this:

Now, since you don't have a direct payment channel to Bob (and it would be very inefficient if you had to create a payment channel with every business partner you ever meet), you route your payment through the network. Instead of only writing an update of the balance between Bob and you as I described above, this becomes a concerted effort: Your wallet finds a route from you to Bob that has a) sufficient liquidity, b) least fees, and c) fewest hops. To make a payment, each involved payment channel updates its balances. With a payment of 1 m₿ for the coffee, this updates our network to:

As you can see, the balances at the ends have shifted appropriately from you to Bob, but the other participants have the same balance (although shifted to other payment channels). It's important to realize, that the payment can only go through completely or not at all. Either we all update the balances, or no one does.
Now, imagine that you don't have only the one payment channel with me, but you have maybe a half a dozen payment channels with other users! :)

4. Cooperative channel closing
Other than in the above case where one side closes the channel unilaterally, one of us can request to cooperatively close a channel from the other. When we agree, we collaborate to create a final payout transaction that doesn't lock any funds and allows immediate spending after confirmation. We could even use this transaction to spend some of our balance directly to a third party on the blockchain, or to create another different payment channel. Let’s say I want to pay Carol on-chain when we close the channel after the second commitment transactions have been exchanged.

5. Trade-offs

You cannot receive more money through the Lightning Network in one payment than the sum of your channel counterparties’ balances.
Sender and receiver have to be online for a payment to be conducted.
Your Lightning Network payments don't get recorded on the blockchain for eternity, (i.e. better payment privacy), but your Lightning node has a permanent identity and your announced channels’ funding outputs are publicly associated with your node’s identity (observers may guess how much funds you have deployed to the Lightning Network), or which outputs went to you when channels get closed.
Instant payments! But your funds are tied up in payment channels. If you need those funds for an on-chain payment, you need to close the channel or splice out a payment with the assistance of your channel partner.
Lower fees! Payments on Lightning don't require an on-chain transaction fee, but if you route payments through others payment channels, they will charge a proportional fee for the liquidity they provide. However, as other Lightning nodes are competing to transfer your payment for you, this costs much less than an on-chain transaction fee (unless the payment amount is huge).

6. Further reading:

How is a node in the middle prohibited from keeping the money in a routed Payment in Lightning network?
What are the trade-offs between transacting on LN and Bitcoin mainchain?
How are paths found in Lightning Network?

¹ This examples is a so-called “dual-funded” channel. Many channels are funded only by one party upon creation. Channels funded by one party start off with the entire balance on one side and therefore only capable of sending payments but not receiving. Dual funded channels were recently implemented by some Lightning Network implementations for the first time.
² The commitment transactions and justice transaction mechanism are why Lightning needed the transaction malleability fix from segwit. We can only rely on this chain of half-signed, unconfirmed transactions if the transaction id’s of the prior transactions can be predicted reliably.

Nice, I thought at some time that bitcoins would be a way of instant payment and be used in stores and everyday life, but in another stack exchange question someone explained to me that the delay to confirm transactions on blockchain would not aloud it. The LN brings a light to my previous thought. Nice explanation. I'll read after the article about tradeoffs between BTC and LN. I hope to understand better the implications of using SegWit and LN, if it's easy to be a general adoption, the only thing I know until now is the complain that miners won't receive fees for every transaction.

People would need to make a transaction with the blockchain from time to time, right?

@Jp_: Currently, the only way for people to do off-chain Bitcoin denominated value transfers is by using the same custodial third party platform (e.g. both sender and recipient being Coinbase wallet users). Miners have no reach at all into the instant transaction market. With Lightning Network the establishing and closing of channels must happen on the chain decentrally, so the miners reach is actually extended into a market they never had any access to before.

0.01BTC for a coffee?! Outrageous! ;-)

@fredsbend: You're always indistinguishable from others using your channel, because nobody knows more than the hop before and after themselves. However, the proxy nodes don't give a privacy benefit as far as I can tell. — I'd love to elaborate on this topic on a question, if you ask it.

@Murch , When you say "Your transactions don't get stored on the blockchain for eternity" Do you mean that even settlement transactions are not stored permanently in the blockchain?

No, just the off-chain transactions on the lightning network never hit the blockchain. When a channel is closed, this has to happen in an on-chain transaction, so that is recorded forever.

Lightning allows you to lock coins between two wallets, and then send special transactions between each wallet which only become "real" when they are added to the blockchain. But you don't do that, because on-chain costs you more fees, so you keep updating the transactions between each other.
Lightning not only makes it possible to send transactions off-chain from A to B, but also from A to B to C etc. Which would make it possible to create one big network, where most transactions happen off chain, you don't need to trust anyone and where all transactions are instantaneous.

Lightning Network is a layer on the top of the Bitcoin Blockchain. Le'me go in more detail.
It is a technology that makes bitcoin work faster, scalable and improve bitcoin in such a way that Bitcoin could handle hundreds or thousands of transactions each second, right now Bitcoin handles about seven transactions per second which is very low compared to Visa and Mastercard who handles hundreds or thousands of transactions per second. Bitcoin lightning network is a proposal which can help in moving from seven transactions per second to hundreds or thousands transactions per second without having any central entity and without losing trust among nodes.
How Lightning Network Works ?
It works by you and me where we can send each other bitcoins on a channel that is off the blockchain so we establish a channel between each other on the blockchain, we start communicating with each other and sending transactions to each other off the blockchain. We can do hundreds or millions of such transactions without broadcasting it back to the blockchain. When we create this channel that is outside the blockchain, we can do any number of transactions without burdening the entire network.
So in their whitepaper who have proposed this idea also in which I can send a transaction to some other person without creating a direct connection to that other person. Le'me explain guys...
Suppose Me and my friend are sending transaction to each other off the blockchain so may be my friend connects to some other person X so in the lightning network, it is possible to send funds from me to person X via my friend. I dont need to have a direct connection to person X. It's really a good way to propagate funds through the network without establishing many direct connections which also could burden the whole lightning network.

This is comparable with how the internet works today When i send a packet, it can get routed through many different nodes and the nodes dont really care where the packet is coming from and where it's going, they only care where they should send it next and so the next person may send it somewhere else and then it would finally arrived at final destination. It's similar to how lightning network work if i have a connection to my friend and my friend has a connection to someone else. I could send funds from me to someone else via my friend, my friend wouldnot even know if the funds are intended to go to person X or if person X is supposed to send person Y. If the person X is recipient then transaction is finished and can be broadcasted to the original blockchain so in this way we can do millions of transactions among each other without burdening the entire network and this could really scale the Bitcoin network.
Can you trust that middle person ?
I want to send some funds from me to my friend Sachin and i want to send those funds to Sachin via middle person Shivam so I have a channel from me to Shivam and then Shivam has a channel to Sachin, now i want to send my funds to Sachin. How can i trust Shivam? May be Shivam takes my funds for himself and doesnot send anything to Sachin so this thing is handled cryptographically and transaction will be refunded back to me if Sachin doesnot recieve my transaction in a certain amount of time.
Problems in Lightning Network ?
The worst thing that could happen to me in this lightning network is that some middle person who is unfaithful would hold my funds for a number of days and so after those days passes, I would get my funds refunded by the protocol of network.
Another problem with this network is that people could do many channels, they could open and close channels instantaneously for burdening the network. In order to open a channel, we need to broadcast this information to the main blockchain and so if some malicious person tries to open and close the hundreds of channels a second, this could really burden the blockchain. They are working in it.

authors: พนม เจริญทัพ


text:
I don't speak English well. Where can I get help with questions about Bitcoin?
I'm interested in Bitcoin but don't speak English well. Where can I find more information about Bitcoin, and get help with my questions in [my mothertongue]?
This is a canonical question to serve as a lightning rod for questions in Russian, Japanese, Chinese, Spanish, Turkish, Arabic[1], or other non-English languages that we do not support here.
[1] listing languages I've already seen on Bitcoin.SE.

A good starting point is Bitcoin.org website:
https://bitcoin.org
The site content is available in several international languages and provides a good overview of Bitcoin, and links to many helpful resources.

Bitcointalk
is a forum where you can exchange with others in different languages:
There are separate forum sections for Indonesian, Spanish, Chinese, Croation, German, Greek, Hebrew, French, Indian, Italien, Dutch, Korean, Filipino, Polish, Portuguese, Russian, Romanian, Turkish and sections for a number of other languages.

and, as this is a community driven project, and everyone can support (and you can help in the efforts on translation), have a look here:
https://www.transifex.com/bitcoinbook/mastering-bitcoin/languages/
Andreas book "Mastering Bitcoin" has already been translated into many languages, and serves as a very good start into the matter.

authors: Юра Кириченко


text:
How do Bitcoin and Litecoin compare in scalability?
Bitcoin and Litecoin are very similar, however they differ in the hash algorithm, the block interval and reward schedule. How do these characteristics impact the scalability in terms of e.g. transaction capacity, IBD, CONOP, light weight node requirements, and block verification times?

I don't understand.  Litecoin doesn't use scrypt anywhere in the verification of individual transactions, as far as I can tell.  Litecoin doesn't even appear to have a transaction script opcode to perform scrypt.  Is it possible this comes from someone conflating "verifying transactions" with "hashing blocks"?

Where did you hear this, and can you give a reference?

@NateEldredge: Ah sorry, I made a mistake. It must be blocks not transactions. I had a beer with some core developers and was going from memory, don't have a written source.

It's certainly true that scrypt is a few orders of magnitude more expensive than SHA-256 per hash.  For instance you can compare the hash rates of your favorite CPU or GPU for the two algorithms.  However, the difficulty for Litecoin is more than proportionally lower, and in fact I suspect mining one Litecoin block is much easier, computationally speaking, than mining one Bitcoin block.

So, given that you have to compute one scrypt hash to determine whether a Litecoin block shows appropriate proof of work, this costs more than the corresponding computation for Bitcoin.  But as a verifying node, you only have to do it once per block, and I would think this is far overshadowed by the cost of verifying all the transactions in the block.

I think I'll have to revisit this question with my colloquist. Thanks for your input.

Litecoin is using largely the same consensus rules as Bitcoin with a few exceptions:

its blockchain derives from a distinct Genesis block
it targets a block interval of 2.5 minutes (10 minutes on Bitcoin)
halvings happen every 840,000 blocks (210,000 on Bitcoin)
block hashes are calculated with Scrypt instead of SHA-256d

Since the more costly Scrypt hashing algorithm needs to be only performed once per block in block validation, the effect on the IBD should be negligible compared to other steps in the validation. H/T @Nate Eldredge.
Since Litecoin has also activated segwit, its transaction capacity is roughly four times that of Bitcoin. Theoretically, this could cause Litecoin's blockchain footprint to increase at up to four times Bitcoin's rate, presumably increasing the IBD at least at the same rate. I surmise that the IBD might increase superlinearly to the blockchain footprint as it would likely correspond to a higher UTXO count as well. In practice, Litecoin is only using a fraction of its blockspace and should have a significantly faster IBD.


text:
What is the reasoning for Grin's high inflation rate?
According to an interview with Yeastplume on What Bitcoin Did, Grin is going to have a flat reward schedule of 60 grin per block at one minute blocks. This translates to an annual inflation of 100% in the second year, 50% in the third year, 33% in the fourth year and so forth.
For comparison, many countries target around 2% inflation, which Grin will only achieve in its 51st year of operation. Even given that actual inflation of fiat currencies may be higher, Grin's high inflation seems to make it unattractive to store value in Grin for many years to come.
Has the Grin team elaborated their reasoning for choosing a reward schedule with such a high inflation?

See this page of the wiki for a brief set of reasons:
https://github.com/mimblewimble/docs/wiki/Monetary-Policy

There is a long discussion thread ongoing in the Grin forum at https://www.grin-forum.org/t/emmission-rate-of-grin/171

Can you point to somewhere in that discussion that specifically addresses the issue of a high inflation rate continuing 10-30 years out? Looking through it, I can't find much of use for this question.

Calling it "high" is a misunderstanding. An inflation rate of 60 Grincoin/block forever is EXACTLY THE SAME as an inflation rate of 600,000 Grincoin/block forever. Why? Because the number of units of currency don't matter. What matters is the percentage rate of inflation.
Creating new coins at a constant number per block tends toward a 0% inflation rate over time. See this graph: https://plot.ly/~Bobby_Digital/1/#plot
And I'm sure we can agree that a near-0% inflation rate isn't "high".

I downvoted this answer because it misses the point of my question. I've amended my question to make it even clearer that I'm well aware of the constant emission and its eventual low inflation.

Ah ok. I'd also be curious to know about whether the sustained high inflation rate even 20 years out has a solid logical foundation. It seems like many people commenting on the grin-forum subscribe to the old tired "deflationary currencies don't work" pseudo-argument. I imagine that pervasive misunderstanding of currency economics isn't an insignificant factor. Personally, I'd like to see a currency that aims to split the cost of securing the currency between payers and holders. Maybe targeting 10% of the cost paid by new emission, and 90% by transaction fees.


text:
What are Merklized Alternative Script Trees?
I have seen the acronym MAST floating around. I saw that it stands for Merklized Alternative Script Trees, but what does that mean? In what context do they appear and what can they be used for?

Too bad they changed the name from Merklized Abstract Syntax Tree since abstract syntax trees are a concept known to all computer scientists and would give them an understanding of the purpose of this structure.

They are well known to computer scientists. But leaves of a Merklized Abstract Syntax Tree aren't constrained to be mutually exclusive. So it isn't an syntax tree. https://en.wikipedia.org/wiki/Abstract_syntax_tree

The idea of Merklized Alternative Script Trees (or previously Merklized Abstract Syntax Trees) dates back to an idea Russell O'Connor had in 2012. The original idea was that you could have alternative scripts or script fragments stored as leaves in a Merkle tree and then the leaves of the tree that weren't used could be pruned away and not take up valuable space on the blockchain. Compare this to P2SH (Pay to Script Hash) where the entire script is hashed and then revealed on the blockchain at spend time. This brings block space efficiencies (and hence lower fees) as well as privacy benefits.
The earlier formalized proposals for MAST were BIP 114 and BIP 116 and the most recent proposal is of course Taproot (BIP 341). The reason why we moved away from using Merklized Abstract Syntax Tree terminology is that with Taproot (and BIP 114) only one single leaf of the Merkle tree can be executed. You cannot split one particularly long script path into multiple script fragments stored on different leaves of the tree and then satisfy a combination of these leaves. It is effectively a tree of ORs (no ANDs of different leaves and no IF, ELSEs that lead to satisfying different leaves on the tree). You can have ANDs and IF ELSEs but they are contained within leaves not between leaves. Satisfying a single leaf is sufficient to spend the UTXO. As Johnson Lau says in BIP 114:

Only one branch is allowed for execution, and users are required to transform a complicated condition into several mutually exclusive branches.

Pieter Wuille and Russell O'Connor discussed why this design decision was made for Taproot at London BitDevs in July 2020. One of the reasons was that you only need a logarithmic number of Merkle branch nodes to get to any given leaf. There is a combinatorial explosion if there is the potential to have different combinations of all the leaves. Another reason is that the design space had to be limited at some stage to give the proposal the best chance of obtaining community consensus and ultimately be activated.

You may have heard before that "Bitcoin is programmable money". Bitcoin uses a simple programming language called Script to encode payment conditions. While today the vast majority of transactions uses standard single-sig outputs (P2PK, P2PKH, P2WPKH) or one of a small set of common scripts (wrapped segwit, 2-of-3 multisig, 2-of-2 multisig with 1-of-2 fallback), Bitcoin's script language would allow for a multitude of other applications.
Originally, such scripts were encoded directly in the output script that a transaction credited. Pay to Script Hash (P2SH, BIP16) introduced locking the funds to the hash of the full redeemscript instead. The full script is hereby published on spending. One of the challenges of deploying more complex spending conditions with P2SH is that all possible outcomes have to be encoded into a single script which can make the script long and complicated. As the full script needs to be published upon spending, the resulting inputs are costly and reveal the full contract. Additionally, it is non-trivial to determine all possible outcomes of even moderately complex smart contracts.
The idea of Merklized Alternative Script Trees (MAST)¹ is to enumerate distinct spending conditions separately and to allow funds to be spent by fulfilling any one of the scripts.  Each script is compartmentalized into the leaf of a merkle tree. On receiving, the funds are locked to the root of the merkle tree. Spending requires revealing a single leaf's script, a merkle proof to show inclusion in the tree, and fulfillment of the spending conditions encoded in the leaf. The benefits of this compartmentalization are a reduced length and complexity in each leaf, that other spending conditions remain private, and the possibility to encode a multitude of spending conditions. The downside is the added cost of the merkle proof.
A variant of MAST is part of the BIP341 Taproot proposal which supersedes two earlier MAST proposals. Pay to Taproot (P2TR) output scripts are encoded in a single public key. Internally, these are composed of an inner key tweaked with the root of a MAST. A P2TR output can either be spent via the key path by issuing a signature satisfying the public key, or via the script path using one of the MAST leaves.

¹ Note that MAST was originally introduced as the abbreviation for Merklized Abstract Syntax Trees, but has since been backronymed to better fit the proposal's current scope. Also see Michael's answers, which goes into more detail on that.


text:
What impact on privacy does it have when a service like Coinbase starts using batching?
In the recent discussion of Coinbase's sending outage, the question was brought up how the privacy of Coinbase's customers would be affected if Coinbase started to use payment batching instead of sending each payment in a separate transaction.
It seems obvious that any recipient of a Coinbase withdrawal would be able to deduce that the other recipients also got money from Coinbase. However, this information seems to be readily available via publically available chain analysis results already: https://oxt.me/entity/tiid/483238635
What effects on privacy are to be considered when payments are batched? How does this affect the individual recipient's privacy? How does batching affect the privacy of the service provider?


text:
What do pruning nodes contribute to the network?
Pruning nodes are described in the sourcecode thusly:

-prune=<n>: Reduce storage requirements by pruning (deleting) old blocks. This mode is incompatible with -txindex and -rescan.

I’ve watched that my node has been consistently uploading less than it has been downloading since I set it to run in pruning mode.

What services do pruning nodes still perform?
Do they upload blocks and transactions?
Can they service thin clients?
What can a pruning node not do, that a non-pruning node does?

From release notes https://bitcoin.org/en/release/v0.11.0 :

For now, block pruning disables block relay. In the future, nodes with block pruning will at a minimum relay “new” blocks, meaning blocks that extend their active chain.

In the current version pruning nodes don't advertise themselves as having any blocks, so they don't upload blocks. So that explains your big reduction in upstream data. A future update will re-enable block relay in such a way that your nodes can efficiently let its peers know which blocks it owns and which it doesn't.
Yes your pruning node will do full validation and it will service lightweight nodes.

This answer should be updated to reflect the behavior of current versions. AFAIK, new versions of Core can now serve the blocks they have in store.

They always could relay new blocks - ever since the feature was introduced in 0.11. However, until BIP159 is implemented, they can't advertize the fact that they will do so. As a result, in practice it won't serve any light clients.

Pruned nodes do not advertise NODE_NETWORK. Thus, peers will not request buried blocks from them. However, pruned nodes relay blocks at the chain-tip and newly received transactions to their peers.
In 2017, BIP159: NODE_NETWORK_LIMITED service bit (Pull Request) proposed an additional service flag with which pruned nodes could advertise being able to serve the latest 288 blocks and thus most of the lightweight client requests. Support for NODE_NETWORK_LIMITED was then added in 2018 with Bitcoin Core v0.16.0 signaling NODE_NETWORK_LIMITED and Bitcoin Core v0.17.0 starting to make outbound connections to nodes signaling NODE_NETWORK_LIMITED.

A pruning node will trim the number of transactions you need to store. In the most extreme cases, they can store just the UTXO set and the most recent couple blocks, but the degree of pruning is variable, and up to the node operator. Think of it like this:
Alice sends 5 BTC from address 1www to Bob, at address 1xxx.

Bob sends 2 BTC to Carl at address 1yyy, and 3 BTC to Dave at address 1zzz.

Carl sends his 2 BTC to Dave at address 1zzz.

A normal node would need to store all the intermediate data, that is, (Alice -> Bob), (Bob -> Carl), (Bob -> Dave), (Carl -> Dave).
A pruning node, however, only needs to store the final link in each step. If Alice has no more coins in her address, there is no need to keep it around, you can safely discard it. The pruning node would only contain the data for the UTXO set, in this case, the 5 coins that Dave has.
Pruning nodes can validate transactions, verify that the sender does in fact have coins to send, and relay them to the rest of the network. They can also be used by the owner to check their balance completely privately, no need to ask someone else who has a copy of the pruned chain.

Sorry, but it seems to me that you think I'm asking about SPV clients which I'm not.

I'm in the middle of updating the answer to be less brief. I believe i'm addressing your question at the end (that is, what a pruning node can do for the network).

Okay, but pruning nodes do keep part of the blockchain, just not all of it.

I believe I indicated that in my answer, I'm definitely describing a pruning node and not an SPV client. Which part of the answer are you addressing?

The part where you say it only keeps the utxo set. A pruning node is an instance of bitcoind that does have the utxo set and n MiB of the blockchain. In my case that is 20,000 MiB. I'm wondering whether my node serves these blocks to peers as full nodes without pruning do, and especially whether it can serve SPV clients - which I doubt, but if they are asking about recent nodes would be a possibility.

No, a node with prune doesn't advertise itself as able to serve blocks.

The minimum you can keep with pruning is a couple of days worth of blocks, not a couple of blocks.


text:
Is there a way to create a transaction that it can only be confirmed after another unrelated transaction has been confirmed?
Is there a way to create a transaction A that cannot be confirmed until B has been included in a block, although A does not build on any UTXO B creates?
B would have already been broadcast by another user at that point, and you'd only be able to control A.

Background:
I was following a discussion on reddit, where a user was entertaining the scenario that in the future a mining cartel might censor transactions. He suggested creating transactions A that would only become spendable in the event of a confirmation for the censored transaction B, i.e. lending your fee as additional financial incentive for some miner to include B and break the censorship.
I was wondering whether that would actually be possible. Sorry, I wasn't able to find the thread.

Are you the creator of both A and B, or do you only have control over the creation of A?

Out of curiosity, what problem are you trying to solve, where the possibility of referencing previous outputs is not available? If it's not just a pure curiosity question, this may be a case of Nick ODell's favorite XY problem.

@Jestin: No, you're only the creator of A, and B already exists when you want to create A.

@StephenM347: Good question. I've added some background information to the post.

I assume A spending the UTXO of an intermediate transaction C, which spends a UTXO of B doesn't count as 'unrelated', as that's just two degrees of separation instead of one.
Here are three partial-solutions:

To state the obvious, you could simply wait until B is confirmed to publish A.
You could publish A with a lock time in the future and then update it at a regular interval with increasing sequences and extending the lock time each time, but that doesn't eliminate the possibility that earlier versions of A will get mined when their lock time expires. Then when B is mined you publish a new version of A without the lock time enabled.
If you only require that it doesn't affect the coins moving around in transaction B, You could add an output to B that doesn't have any coins in it, and is used only for the dependency tracking of transactions. This requires that you know that you plan to publish a dependent transaction, A, ahead of time though.

I think you'll find that there really isn't a good way to do what you are asking. Transaction dependencies are usually handled by referencing outputs of the previous transaction.

In terms of the scenario where you are trying to bribe miners to confirm transactions that they have been censoring, this is essentially trying to do Child-Pays-For-Parent with transactions that cannot reference outputs. While this is still not possible, you might be able to do something like this:
The community realizes that many transactions are being censored, and they want to pay miners to include their transactions. So everyone starts appending an extra OP_TRUE output to their transaction, with 0 coins in it. Then if you want to reward a miner for mining the transaction with an OP_TRUE output in it, you spend that output with an empty scriptSig and spend another output to provide some fees.
One downside to this is that a miner will only be able to accept one person's bribes, as there is only one OP_TRUE UTXO added. But, I think if Bitcoin gets to this point, then it will likely have failed.
You could also do an escrow, where you put coins into a 2-of-3 with you, the miner, and a trusted third party. If the miner mines B, then you sign the release transaction to take the coins out of escrow and give them to the miner. If the miner doesn't mine B after a certain amount of time, then you request that the trusted third party help you release your funds. This is a lot of work for a simple task, though.

The bribe transaction could itself include an OP_TRUE output, so if someone else wants to add a second bribe, they can spend the output of the first bribe; and they can include an OP_TRUE of their own and repeat ad infinitum.  This gets awkward if the censored transaction is very popular, because the bribes may step on each other.  Or, each one contains several OP_TRUE outputs; now the number of available places to hang a bribe grows exponentially.

The only way to do it - is to flood the network with transactions with higher priority and/or with SIGOPs-attack

Let's say A create a multisig tx.
A sign it a transfer the raw tx to an oracle.
The oracle listen network, check if B is included in a block.
If B is included, the oracle will sign A tx then send it to the network.
Keep it mind that an oracle in a another program "somewhere" and by working with it you trust a third party.


text:
Does anyone get custodial control of your funds when using Lightning Network?
When I open a payment channel on Lightning Network, do I need to subject my funds to custodial control of another party? Is there a counterparty risk in Lightning Network?

From my understanding on how the Lightning Network works (derived from the whitepaper and video), all parties commit an amount of funds in order to open a payment 'channel'.  The architecture itself forces the funds to be either transmitted correctly (potentially multiple transfers between the involved parties), or in case of a non-collaborating channel node, for the transactions to be pushed to the Bitcoin blockchain and therefore for the channel to close without any of the involved parties losing any of the funds (but potentially not completing the intended transactions).  The custodian is the channel itself and therefore all the participating channel nodes.  Taken directly from the explanation:

"This entry [multi-party blockchain entry] can be closed out at any time by either party without any
  trust or custodianship by broadcasting the most recent version to the
  blockchain."

Lightning Network relies on a network of payment channels.
When two users open a payment channel together, they create a new 2-of-2 multisig address. As they are funding it, they also create an exit transaction for each user. The exit transactions can be activated unilaterally.
To update the balances in the channel consent of both parties is required. Therefore, no other party can move your balance. The only counterparty risk with two honest users is that your channel partner could be unavailable to update the channel. If you decided to close the channel then, your funds would be locked for the agreed-upon waiting period of your exit transaction.
If your partner decides to close the channel unilaterally, or when you collaborate to do so, your funds become immediately available for spending.
In the case that your counterparty tries to dishonestly execute an outdated exit transaction, you fallback to an anti-cheat transaction that builds on your counterparty's exit transaction. You could monitor the network yourself to safeguard against this case, but the anti-cheat transactions can be safely distributed in the network and have an attached bounty to make it interesting for third parties to monitor on your behalf. When a third party broadcasts the anti-cheat they'd assign the bounty to themselves, but would be unable to touch the remaining funds.
The counterparty risks at most include loss of utility when a channel is closed prematurely on you, an agreed-upon waiting period when you close a channel, or the cost of a bounty at the gain of the dishonest party's funds in a cheating attempt. At no point does another party have custodial control of your funds.


text:
Mini-Blockchain proposal: How is the proof-chain secured against injections?
I have just finished reading the paper Purely P2P Crypto-Currency With Finite Mini-Blockchain by J.D. Bruce. While I got the impression, that the rolling blockchain as an idea might work, I was left wondering about one detail in the proposal.
It seems to me that the proof-chain fails to live-up to it's purpose:
Bruce suggests that it would be sufficient to keep the proof-of-work solutions of the blocks as a proof-chain. Yet, how could one verify the proof-chain if all the block data has been discarded as suggested? Wouldn't it be possible to replace any blockhash in the proof-chain with another valid blockhash and start a competing mini-blockchain from that point?
That way an attacker could spend any amount of time on the mini-blockchain and just insert it into the proof-chain whenever it is sufficiently long.
Am I missing something? Why would the proposal work as intended by the author? Or is it actually "broken"?

Block data is not necessary to check proof of work, or to check that past block headers has not been altered. This is because for a block to pass proof of work check, the hash of its header must be less than a certain value. So, the header (which is just 80 bytes in Bitcoin) has enough information to check proof of work. Also, each header includes the hash of header of the previous block. So, assuming that the hash function is collision-resistant, it is impossible to modify any of the previous headers without changing the hash of the last header, and it is impossible to change any header while keeping proof of any work done after the corresponding block. The only way to "fake" a mini-blockchain is to outrun the honest miners, which requires an attacker to have comparable amount of hash power.

Ha, I just revisited this question and realized that I now understood your answer sufficiently to understand why it completely answered the question. I guess two years ago I didn't know enough about the headers of Bitcoin blocks. :)


text:
I'm new to Bitcoin, how do I keep my bitcoins secure?
With the recent rally and media attention, lots of new people joining the Bitcoin community.
A lot are asking:
I'm new to Bitcoin, how do I keep my bitcoins secure?
and if they aren't that's the first thing you should teach them.

Use a desktop or mobile wallet (Electrum or Mycelium) to spend bitcoins (be sure to write down your recovery seed and store it like a paper wallet). To receive and store them, use offline paper wallets. As soon as a paper wallet exceeds some amount (50mXBC for instance), put it in storage and start a new one. If you are spending and your online wallet runs dry, break open a paper wallet to complete the transaction, any leftover coins will remain on the online wallet.
NOTE: with "online wallet" I mean wallets like Electrum and Mycelium, not web wallets like Coinbase or the Blockchain.info wallet.
Someone posted instructions for paper wallets on bitcointalk:
https://bitcointalk.org/index.php?topic=1559277.msg17075677#msg17075677
Do your own research before risking your coins following what someone told you.
Do not use web wallets.
EDIT: Brain Wallets (memorizing a passphrase that is hashed to produce keys and addresses) are highly controversial in the bitcoin community. The proper way to use them is to choose the passphrase uniformly and at random from a large set (at least 2^128).
Security improvements include:
Adding salt (something unique but trivial to remember, like your full name, phone number, or email address) to the passphrase to prevent hackers from attacking everyone at once.
Using key stretching WarpWallet is an algorithm that derives keys from a passphrase using a difficult, memory-intensive algorithm, this makes them much harder to hack.
To generate multiple wallets from one passphrase, you can attach an index to it (append a number to the passphrase).
The main advantage of brain wallets is that there is no physical wallet to steal or confiscate, and plausible deniability of having bitcoin.
Disadvantages include difficulty of remembering the passphrase (if you forget it, the coins are gone), possibility of theft (there are hackers constantly monitoring addresses created from weak passphrases, and they steal coins immediately), and the fact that in the unfortunate event of your death, your family would not be able to recover your coins.
If you decide to use them, they can be used in place of the paper wallets in the first paragraph.

Wallet
The wallet holds the most valuable component of the bitcoin network, your private key.
When you go to Bitcoin.org, there are several choices.
 A HD wallet (Hierarchical Deterministic) is more future proof.
Wallet    Feature        Caveats                   Example
Mobile    Convenience    Trust?                    Mycelium
Online    Backing of co  Trust?                    Coinbase
Hardware  Self contained Update your own firmware  Trezor
Desktop   Total control  Your responsibility       Bitcoin Core

Private Key
In Mastering Bitcoin, the private key is compared to your PIN (while the bank account number would be your public key).
 For HD wallets, the private key is more specifically referred to as the seed or root seed.
Using the analogy, how do you protect your PIN? (considering it is 64 alphanumeric digits)

Keep it safely stored separately as a back-up.
Never give it out. No one, no application will ask you for it.
Change it on a frequency (like the IT policy enforcement of office passwords). For your private key, you change it by using all the unspent value then starting a new paper wallet (see next section).
Don't lose it. This is where the analogy is weakest. You cannot call anyone to reset your private key. Don't lose it.

Paper Wallet
To protect your private key, there is a way to ensure it isn't visible to the bitcoin network. This is accomplished by using a paper wallet. The paper wallet is like the hardware wallet at the extreme, with all the electronics removed. The recommended practice is to receive payments in one or more transactions, but spend in one single transaction and starting a new paper wallet.
The manual steps:

Save the client-side javascript for Bitaddress onto USB drive
Disable network on your PC
Start a clean OS (Live CD of Linux)
Launch a web browser to run the page saved from step #1
Inspect the private key for a 6P starting prefix value
Never forget the pass phrase you chose
Print the newly created paper wallet
Store the print-out in a real lock safe

Proactive
Go to Blockchain.info, input your address, and check the activity. This is similar to how you might inspect your receipts from a store, scanning your monthly credit card statement, or balancing your checkbook. You are watching your financial accounts to catch mistakes, fraudulent activity, and dispute charges.

I think this link here is useful: https://bitcoin.org/en/choose-your-wallet
It shows the bulk of wallets available and if you click on it, it shows a brief summary.
For a general basic user wanting to send and receive, I would think that all of those wallet options are about the same. Of course they all have slight differences that anyone can further research on.

It is very important to secure and back up your bitcoin wallet. If you can’t follow this you could lose your bitcoin.Here are the eight easy to do tips to safeguard your bitcoins from losing or falling into the wrong hand: Eight ways to keep your bitcoin safe from wrong hands

authors: Максим Коновалов


text:
How to unstuck a low-fee transaction with blockchain.info?
I've sent a transaction from blockchain.info, but accidentally included too little fee. What can I do to cancel the transaction or speed up the transaction's confirmation?

This is a complementary question to Why is my transaction not getting confirmed and what can I do about it? which answers the question's broader implications and proposes mitigation mostly focused on Bitcoin Core.

this is a generic answer applying to "light" wallets - I don't know much about the blockchain.info-wallet

There are several approaches that may work, I've tried to list all the methods I know below.  I don't know how the blockchain.info-wallet works, but probably I would try things in this order:

Wait for the transaction to go through (see 0a below)
Do a "CPFP" (see 2 below)
Ask the pools for help (see 3 below)
Wait for the transaction to be forgotten and retry sending (see 0b below)
Try to do a double spend (see 1b below)

0) Wait it out.
0a) Wait for the transaction to go through.  Most likely there will be free capacity in the network after some hours, some days or a week.  In periods with free capacity, even low-fee transactions will pass.  Rarely one has to wait longer than the next Sunday evening.
0b) Wait for the transaction to be forgotten, and then create a new transaction with a higher fee.  In some few exceptional cases (notably around new year 2017/2018 and in 2021) several weeks or even months have passed without any free capacity.  The original transaction may eventually be forgotten by the network.  Some wallets will then offer to create a new transaction, Mycelium will offer to delete the old transaction, and with some luck a "double spend" will be possible - though this is very unreliable as the original transaction may be purposely or accidentally rebroadcast both by the sender, receiver and any third-party.
0c) From some wallets, the most intuitive panic action is to actively rebroadcast the transaction. This probably won't help at all, and it's the exact opposite of 0b, so it's probably not a good idea
1) Double spend with a higher fee (RBF).
1a) Using the "Replace by Fee"-protocol - this probably does not apply to you, but it's arguably the best way to "unstick" transactions.  If the original transaction is marked up with "RBF allowed", most of the network will accept a replacement transaction with a higher fee.  Not all wallets supports setting this flag, and even fewer has RBF turned on by default - for a good reason, the RBF protocol allows an unconfirmed transaction to be reverted, so using the RBF-flag is a terrible idea if you want someone to trust a zero-conf transaction.  (the RBF-feature has been removed from most Bitcoin Cash software, as they deem it both "harmful" and "not needed").
1b) Doing RBF/"Double spend" even if the original transaction was not marked as RBF.  Miners (and nodes) are supposed to ignore the double spend transaction - but you may be lucky.  You may need to use specialized software to perform such a double spend.  It may work, either because the original transaction has ended up in a "ghost-like" state where it's known by some nodes but not others - maybe some miners are unaware that you're doing a double-spend - or it may work because some miners deliberately accepts double-spent transactions as they can earn more fees on it.
2) Child Pays for Parent (CPFP). if a new transaction is made with a high fee, building on top of the old transaction, most of the miners will include the whole chain of transaction in the block they're mining at.
2a) Get the receiver of the funds to spend the funds they received on a new transaction, with high fee.  This may of course not always be possible, but ...
2b) If not all the money in the wallet was spent, the transaction will typically include two outputs, one "change UTXO" that goes back to the wallet.  If you can spend this one with a higher fee, the transaction may go through faster. Some wallets have a menu option for "accelerating" the transaction through "CPFP".  In some wallets one can manually decide what UTXOs to include in the transaction. One can also send all the funds in the wallet i.e. back to an address belonging to the same wallet, but the fee for that may become excessive as the wallet may be filled up with "dust" making such a transaction big and costly.  Electrum does support spending some specific UTXO, and Mycelium has the "CPFP" acceleration button.  If you can take out a backup seed phrase from your wallet, it can most likely be used in Electrum or Mycelium.
3) Ask the pools for help.  viabtc has their "transaction accelerator" at https://pool.viabtc.com/tools/txaccelerator/, antpool.com also has some similar service, there even exists services where one can pay by credit card to get the transaction prioritized.

Arrays start at 0. Very good.

It looks like your transaction finally went through. I've had a transaction take longer than 24 hours due to not including a large enough miner's fee
And currently there's no way to cancel a transaction after it's already sent, even if it's still unconfirmed. So it's a good idea to triple check the amount you're sending, the transaction fee and that it's going to the correct address.
I think it would be helpful if bitcoin had this feature in the future: cancelling transactions while they're still unconfirmed

I've merged the question this answer was posted on originally into this more canonical topic. Please check if you should edit it to adapt it to this topic.

Replace-By-Fee is this feature, but blockchain.com wallet doesn't have it seems

I want to delete my unconfirmed transactions from Blockchain.info?

Unconfirmed transaction means that your transaction is being broadcast through the network until some miner write it down into a block. If the unconfirmed transaction is not confirmed into the blockchain after some days, it is deleted from the network.
Nowadays, there is no easy way to delete your unconfirmed transaction. Unless you broadcast it again with a higher fee. In that case, the one that enters first into the blockchain (probably the one with higher fee) will automatically delete the other one from the unconfirmed pool (after a propagation delay).

Is there any way I can recover my bitcoins?

While your transaction has not being written into the blockchain, it means that you haven't spent your bitcoins yet. Theoretically, you could still write a transaction into the blockchain spending such bitcoins the way you like it.
However, the problem is that not the entire network accept that. Probably, you would have to broadcast it via the console of a bitcoin client.

Basically, you can double spend the input and add transaction fees. Firstly, this sounds crazy but it works! Somebody also made an introduction video on how to do this: https://www.youtube.com/watch?v=ycq7O48aPvQ

I've merged the question this answer was posted on originally into this more canonical topic. Please check if you should edit your answer to adapt it to this topic.

u cant as balance already reduced

If you're one of the recipients of the transaction (i.e. via change output), you can create a child-pays-for-parent transaction by spending the unconfirmed output in a new transaction with a sufficiently high fee.
From what I hear, you can specifically select the inputs for transactions on blockchain.info, so it should be easy enough to craft a transaction to that end.
If you're comfortable doing so, you might want to try to export the private keys corresponding to the unconfirmed transaction and export it into another wallet in order to create a doublespend transaction to recover the funds.
Finally, you'd always have the option wait it out, or to get in touch with blockchain.info's customer support.
Note: I've never used blockchain.info myself, so please provide feedback to improve this answer if you have better insight.

I am in the same situation. I contacted my wallet provider and this was the response.

Hello,
The bitcoin mempool is currently backlogged, which is causing a delay
with transaction confirmations. You can follow it live on this chart,
which shows all pending bitcoin transactions on the bitcoin network -
https://blockchain.info/charts/mempool-count. This is impacting the
entire bitcoin network, not just Blockchain.info.
An unconfirmed transaction will eventually be accepted into a block by
whichever mining pool mines the block, or the transaction will
eventually be rejected by the bitcoin network after an estimated one
to seven days. If it eventually is rejected, then the funds would
remain at the bitcoin address they were sent from. The only thing you
can do at this point is to wait and see if the transaction is accepted
into a block. Like all wallet providers, Blockchain.info has
absolutely no control over this, and cannot expedite transactions.
This is always dependent upon the bitcoin network of miners, which we
are not a part of.
Blockchain.info wallets utilize dynamic fees. The following link
explains how this works -
https://blog.blockchain.com/2016/03/16/introducing-dynamic-fees/.

I appreciate and i think the best thing to do right now is to wait and see what will happen

Mine have now confirmed, took 4 days, so its worth waiting, chances are it will confirm soon.

OK so finally the answer. I've submitted a couple of low fee transactions for a test and curious how this plays out. So in case of blockchain.com which doesn't support Replace-By-Fee, i.e. reissuing a transaction with higher fee, you have to wait "estimated one to seven days" for it to be rejected. I can't find any info on rejected transactions though

Seems like Blockchain.info/Blockchain.com is screwed up and anti bitcoin in general. The proper way of course is not to use it at all and go for RBF wallet. There is no guarantee tx gets rejected https://old.reddit.com/r/Bitcoin/comments/ldzkpo/could_someone_tell_me_what_i_can_do_about_this/gma8efl/

If you have access to the core API and there is 'change' from the txn, spend the change  with a high fee:
you will need

the stuck txn id
the change private key

vout is the output for the change address. Lookup the txn, the change address is the zero based output from the spend.
( if you don't know, ask - people will help)
1 Get the private key of the change address
bitcoin-cli dumpprivkey <Change Addr>
2 Spend the change
this spends 1.0 BTC adjust as reqd. For your own amount - figure the change amount minus a large fee. Make sure you understand  the fee will be the change from original txn minus the spend to the address. Normally protections are in place to prevent fee bloat - this method ignores them. calculate the amount carefully
bitcoin-cli createrawtransaction '[{ "txid": "the stuck txn", "vout": 1 }]' '{ "<address to send to>": 1.000 }'
you will get a result like this:
0200000001fae ... 088ac00000000
3 Sign the spend with the priv key of the change address
using the ouput from step 2 and the priv key from step 1 ...
the [] below indictaes we don't want to add any new txns into the spend (keep it simple)
bitcoin-cli signrawtransaction "0200000001fae ... 088ac00000000" "[]" '[ "<my change address PK>"]'
result will be ...
{
  "hex": "020000000 ..... 8ac00000000",
  "complete": true
}
4 Submit the txn to the network
in Step 3 we got a raw data transaction .... let's send it
bitcoin-cli sendrawtransaction "020000000 ..... 8ac00000000"

If transaction is unconfirmed you may just double spend it. It would probably require creating a transaction manually (I have used node.js with BitcoinJS for it), and then submitting it via the console of the bitcoin client. I would suggest also paying a bit higher fee (for the new transaction being confirmed before the old one) and not reusing any of source addresses used by either the old or new transaction, as double spend is easy to detect and people may not trust you.
If the point is to just make the original transaction confirmed you may just try to resend it (using console). It sometime helps as unconfirmed transactions are broadcasted by the network only for limited time.

no, is not double spent - You can see the transaction at https://blockchain.info/tx/92f565e23499437ed4d54bc946a044c56353c4d1f512cf514b40a31eits only unconfirmed after around 30 hours + the money is deducted from my balance - i cant re-send it, i cant send it again my question was how do I cancel the unconfirmed transaction and get back my coins?

@enockofori that link doesn't work. It looks like your Tx may have dropped out

Yeah, submit a higher fee double-spend transaction.

I've merged the question this answer was posted on originally into this more canonical topic. Please check if you should edit it to adapt it to this topic.

up until a transaction has been mined into a block it is not set in stone. therefore you can just issue a new transaction which spends the same txout as your original but which sends the funds to a different address.
would this be classed as doublespending? not technically because nothing at all has been spent until the transaction appears in a block.
this may be tricky (impossible?) to do in the standard client as it knows about the transaction you just created and so has deducted the funds in anticipation of them being mined into a block. but you can create your second transaction by:

downloading your private key from your wallet and loading it into a bitcoin client that knows nothing about your first transaction (note: never paste your private key into a website), or
manually creating a transaction using bitcoin-cli, and broadcasting it to the network

This is technically exactly the definition of a double spending.

no. doublespending would be if the same txout went to 2 or more txins in the blockchain itself. no txouts should ever be considered spent until there is a txin corresponding to them in the blockchain.

The qt client has an option now (-zapwallettxes=2) that will reload your transactions from the blockchain and give your balance back so that you can re-attempt the transactions that didn't confirm.

I've merged the question this answer was posted on originally into this more canonical topic. Please check if you should edit it to adapt it to this topic.

The only thing you can do is to wait for the transaction confirmation, like me now. This link show that more than 120.000 transaction unconfirmed including ours https://blockchain.info/unconfirmed-transactions

I've merged the question this answer was posted on originally into this more canonical topic. Please check if you can edit it to adapt it to this topic.


text:
What is the Lightning Network proposal? What problem is it trying to solve?
We already have a few questions about technical details of Lightning network, however, …

What is the Lightning network proposal in the first place?
What problem is it aiming to solve?

Two issues with Bitcoin's design
Scalability of "everyone checks everything"
Bitcoin is a gossip network:
P2P nodes connect mostly randomly to each other and pass-on new information to each other as they receive it. That way, information floods through the network quickly: each step further increases the nodes that were informed exponentially (until most are).
In Bitcoin every node receives and checks every piece of blockchain data, currently some are relayed even more than once. While this is a manageable problem at 1 MB blocks, this setup has a real cost: bandwidth usage, CPU load for verification, and storage-footprint on the hard drive.
At 1 MB, the Bitcoin network can support about 3 transactions per second (tps). To scale up to Visa-levels we'd likely need around 3,000 tps. To serve all internet commerce, a multiple of that. While there are some gains possible with more efficient use of the space we have (CoinJoin, Schnorr Signatures, …), it is obviously a much harder challenge to manage ~1 GB blocks every ten minutes. At that point, relay bandwidth would be a multiple of that, verification of 144 GB blockchain data per day would take a significant portion of an average home computer's computing power, and hard drives would tend to fill up fairly quickly.
It follows that there is a limit to what can be done with pure on-chain scaling.
Instant payments
Early Bitcoin merchants were comfortable to take the risk of accepting zero-confirmation transactions. The "first-seen" principle was firmly established as a node policy and even transactions without fees would confirm eventually.
Since then, blockspace demand has increased, some miners changed their policy to mine the transaction with the most fees instead of the "first-seen", and zero-fee transactions have become infeasible.
Meanwhile, payment processors and some merchants still take the calculated risk of accepting transactions before confirmation, but generally, a transaction is only reliable after it is confirmed.
Lightning Network
The Lightning Network (LN) proposal describes a structure to provide secure, instant transactions negotiated only among the involved users.
LN leverages payment channels, a type of multi-signature construct, to create jointly managed balances between pairs of users. By re-negotiating the balance's payout shares, the users can instantly transfer balance to each other. Each re-negotiation is recorded as an update to the smart-contract securing the funds of both parties.
By having multiple connections in the network at once, users can receive balances from one partner and forward them to another. Leveraging this network, Lightning Network is promising instant payments to every other LN participant and increased transaction capacity at a low-cost.
Should a user wish to close a payment channel, the smart-contract's current state can be executed on the Blockchain as a regular transaction.
Interested to read more? See → How does the Lightning network work in simple terms?


text:
Can unupgraded nodes that accept zero confirmation be fooled after SegWit?
Considering the following scenario:

After deployment of SegWit, there remain two old clients (with software that is unaware of SegWit) A & B.
A funds a transaction to pay B using a SegWit output which appears to both as ANYONE_CAN_SPEND.
  Upgraded nodes ignore this transaction, as it obviously isn't signed correctly under the rules of SegWit. (Perhaps even ban old nodes that relay this "invalid transaction" to them?) However, among old nodes the transaction gets propagated as valid.

In the case that B gets notice of the transaction, would it display an "incoming unconfirmed transaction"?
Could people get fooled that way if they accept Zero Confirmation (which I'm aware isn't safe)?

(Other answer, after clarification of the question)
Among old nodes, the transaction is not propagated because it is non-standard. Whenever a softfork for new features is designed, its encoding is chosen in a way that makes it incompatible with old nodes' standardness rules.
In the case of segwit, a witness program is encoded as two pushes in the scriptPubKey (or redeemscript), one an OP_n (with n between 0 and 16) and one a data push of up to 40 bytes. Spending such an output will always violate the CLEANSTACK rule that was added as standardness in Bitcoin Core 0.10.
Similarly, CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY used redefined OP_NOPn opcodes, which violate the DISCOURAGE_UPGRADABLE_NOPS rule that was added as standardness in Bitcoin Core 0.10 as well.

So the transaction is not propagated, but what if A connects directly to B's node and feeds him the transaction. Will B's node still ignore it because it is non-standard? Or will the transaction be displayed, tricking B into thinking he has been paid?

It won't be accepted at all.

If it is a transaction that pays B, that means that B chose that address. If B doesn't support SegWit, it won't ask for a SegWit output, so this cannot happen.
In practice, SegWit wallets will likely use P2SH initially; the SegWit output will be embedded in a pay-to-scripthash, and the address a SegWit wallets gives to sender will be the P2SH hash of the SegWit output script. However, in our scenario, B doesn't know anything about all that, and will just give out a normal old-style pay-to-pubkey-hash address, and A will pay to that.
More information about failure scenarios around softforks that introduce new transaction types: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html

I meant that A uses a SegWit Output in its Txin. Does that make more sense?

I've tried to clarify my scenario, could you please have another look?

@Murch I've added another answer, as both are potentially interesting I believe.


text:
What is Maxcoin?
How does Maxcoin compare with previous cryptocurrencies?

What hash algorithm does it use?
What reward schedule has been announced?
Does it solve any problems that Bitcoin or another previous crypto didn't solve?

MaxCoin is one of many altcoins, yet one of the few that were inspired by famous persons see, such as  RonPaul Coin and Coinye Coin.
As far as we know, MaxCoin is going to use the
SHA-3 (Keccak)  cryptographic hash function, which should in the beginning allow only CPU miners to mine. According to a statement of the creators, it is planned as a mine-coin for everyone having a GPU.
Technical aspects:
Scrypt or SHA-256? Keccak (SHA-3)
How many coins? 250,000,000
Block reward? 96 MaxCoin per block, halving every ~12 months
Difficulty? Retargeting using Kimoto Gravity Well algorithm.
Block time? 30 seconds
In fact this coin doesn't solve any significant Bitcoin (sometimes arguable) weaknesses.
If we take a look at the interest e.g. in Twitter followers that have grown from zero to 6.6k within 2 weeks this is a lot compared to e.g. Zerocoin that has 1.6k followers after about year and a half activity. We might speak about a cryptocurrency Dot-com bubble as this altcoin doesn't have any significant additional technical or economical value.
Edit No.1
My comparison about Twitter followers turns out being very misleading as the Coinye West Coin has now 22K followers and the it's real successor CoinyeCoin has just 2,2K.

Worth pointing out that Maxcoin uses the secp256r1 Random Curve, unlike Bitcoin that uses secp256k1 Koblitz Curve, for the synthesis of elliptic curve public keys from private keys.


text:
Reward schedule and maximum number of dogecoins?
According to Dogecoin's bitcointalk-thread there will be a maximum of 100 billion dogecoins. Yet, just below that figure is stated that the reward schedule offers a reward of up to 1 million dogecoins for each of the first 100k block, which would amount to 100,000,000,000 doges already rewarded for the first 100,000 blocks. The subsequent next 500k blocks would up the total doges to just shy of 170 billion dogecoins.
It also states that there will be a constant reward of 10k doges starting with block 600,001.
This information is inconsistent and I am wondering, how the reward schedule is actually implemented:
Is there a maximum of dogecoins or will the amount continue to grow infinitely as suggested by the constant reward?

The Dogecoin reward schedule
I subsequently found the information that the Dogecoin reward schedule provides random amounts sized between 0 and a halving maximum for the first 600,000 blocks:

Block 1 — 100,000: 0-1,000,000 dogecoins
Block 100,001 — 200,000: 0-500,000 dogecoins
Block 200,001 — 300,000: 0-250,000 dogecoins
Block 300,001 — 400,000: 0-125,000 dogecoins
Block 400,001 — 500,000: 0-62,500 dogecoins
Block 500,001 — 600,000: 0-31,250 dogecoins
Block 600,001+: 10,000 dogecoins

The random reward amounts are dependent on the hash of the previous block. (H/T @JesseBusman)
How much?
At optimal random distribution, the first reward interval would provide 50 billion dogecoins. Altogether, the first 600,000 blocks would provide an estimated ~98.44 billion dogecoins, leaving another expected 156,250 blocks to be mined with the subsequent constant block reward of 10,000 doges per block.
How long?
As the block time is aimed to be 60 seconds, the reward is expected to halve every 69 days, 10 hours and forty minutes. At optimal block time, the last block with a reward would be expected after 525 days, or one year and 160 days.
Update: Flat 10k reward forever
On February 1st, 2014 the Dogecoin developers announced that Dogecoin would not be capped at 100 billion dogecoins after all, but would continue to have a flat 10k dogecoin reward for each block after Block 600,000.
While not hard-capped, a constant tail emission is predictable and disinflationary:

I've heard the payout is random and the maximum is 1M Doge. So the average payout for the first 100,000 blocks is 0.5M Doge/block. So after the first halvening 50B Doge are in exisitance.

Kind of a short explanation and you start it out with "I've heard" make it sound like extremely suspicious info.

The math says that the coins will be fully mined-ish in 1.43 years (525 days) from the genesis block.
That's June 2015 folks