text:
1 block only allow about 2000 transactions. Does it mean every 10 minutes, bitcoin can allow 2000 transactions?
Hi I very new to bitcoin and don't understand this. Isn't this 2000 too small? I thought there would be more than 10,000 transactions going around every 10 minutes. Especially when there is an ICO going on.

2-3000 transactions can be included in each block. But that does not mean that only that many transactions can be made every 10 minutes. There can be, and has been, several thousands more transactions made than can fit into the next block. That just means that several thousand transactions won't be confirmed in the next block and will have to wait for blocks that come later.
There are many proposals that are in their activation stages that will increase the Bitcoin's capacity so that much more transactions can be included in each block. However these are all not yet deployed; they either require miner signalling or community consensus (everyone, including miners) to activate, and none of those have happened for any of the proposals yet.

Especially when there is a ICO going on

ICOs don't use Bitcoin.

thanks for the explanation. i contribute to TenX ICO using bitcoin

I can see there are many blocks(1-10000) that have only 1 transaction in it.So could not follow when you say there can be only 2-3000 transactions in each block

Blocks with only one transaction do not contain any transactions from the network. That one transaction is the coinbase transaction which only pays the miner that created the block. A block that is actually confirming new transactions will have at least 2 transactions.


text:
How does a merchant ensure sufficient value in light of the price volatility?
When a merchant accepts bitcoin payment (for example 10 btc for the purchase), the buyer send the payment of 10 btc and it is settled.
However, the 10 btc value will fluctuate every minute (up to 20% or more sometimes on a daily basis).  Let's say 1 btc = $2000 at the time of the payment and 1 btc = $1900 at the time when the merchant exchanged it for US dollars. The merchant lost $100 in this case and the opposite could happen.
How does a merchant ensure that the btc payment satisfies the cost of the product?
Please help me understand how this works. Otherwise, it does not make sense to me why Merchants need to accept btc payments.

The merchant concerned with volatility should price items in the local currency. Then only when a buyer says "I'd like to buy in bitcoin" convert that price according to the current value of bitcoin. And then of course convert to the local currency as soon as the merchant receives the bitcoin.

The merchant can quote prices in their native currency (e.g., dollar, euro, etc.). The amount of BTC required to pay for the products would vary according to the exchange rates of BTC/USD, BTC/EUR, etc. This would account for pricing fluctuations over longer periods of time (without needing to constantly re-adjust the BTC amount).
Concerning price movements during the confirmation period (usually up to 60 minutes), these would (usually) be minor and cancel each other out over the course of repeated purchases. Depending on the settlement contract the merchant has, the risk of abrupt changes in BTC-value may be transferred to the party that handles the exchange or another third party.

Merchants can automatically convert the Bitcoin they receive into fiat currency. This way they can minimize the risk of price fluctuation.
Although, the price can still change while it's in the blockchain waiting for confirmations (usually 10-30 minutes).

There is no way for the merchant to ensure that he receives full value. This is the nature of digital currencies and why many merchants decide to not accept bitcoin as a payment; it is volatile. However, there is also the chance that the value will increase, thus netting a profit for the merchant. All in all, any merchant who accepts bitcoin not only is hoping for an increase in the price of bitcoin but is also looking to appeal to more customers.

I see it the other way around.  Bitcoin is stable, but that darn $ keeps fluctuating...

Normally it depends on your payment processor and the contract. Transaction is been given some time (mostly defined in a contract) where it is reserved as the value. Here the payment processor has to provide it regardless of the fluctation. For that reason payment processor does use fees and insurance/reinsurance is also a must for the payment processor.
We had similar scenario with an ATM machine in one european country, it was very similar. I would strongly suggest you to contact some payment processors like bitpay or similar to ask them how do they secure those transactions. I would also say that there are some speculating projects where in cooperation with another payment processor, the variety of what can be done is huge.
I could write here more, but I think it would be offtopic, hope the info I wrote helps.

The same rules apply as for merchants who accept US dollars in many countries instead of their national currency as a form of payment, even though their expenses may be in national currency. Typically they'd need to monitor the exchange rate and adjust prices if there is a significant change; in the case of high volatility currency such as BTC, the practical way to address the volatility is add a significant premium to the price if paying with BTC.
You are correct to identify volatility of BTC/USD exchange rate as a deterrent for merchants to accept it as payment. Ultimately, the merchant needs to have confidence in bitcoin as a store of value if they're going to accept it as a form of payment. The same is true for any other currency or asset accepted as a form of payment. To date, bitcoin has proven long-term to be a very good store of value, appreciating significantly in US dollar terms over the past few years. Any merchant that has accepted BTC for years and kept it is better off now than they otherwise would have been.
Should the value of bitcoin stabilize and appreciate relative to USD in a slow gradual manner, as opposed to appreciating chaotically as it is now, I think it would be much easier for more people to trust it as a means of payment without worry of a significant loss in value.
It also helps to think of USD as a commodity in and of itself that fluctuates in value just like everything else. All stores of value have risk associated wtih them whether its holding assets, cash, equities, real estate, gold, other precious metals, cryptocurrency, or anything else. If you've been around long enough to compare prices of goods in USD terms from the 1970's to now, you'd know that cash itself has not been the best way to store value long term...

source: Stack Exchange

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

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

sort: votes


text:
How do you regenerate all 2-of-2 multisig addresses from two xPrivkeys?
If I want to get the private and public keys of all transactions that have happened on my multisig wallet. How would I do that?
It's a 2-of-2 multisig setup. I have an xPrivkey on my computer and an xPrivkey on my phone.
How do I combine these keys to generate the list of private keys and the corresponding list of public keys.
The purpose would be to redeem my BCH.

Trying to generate all possible combinations would probably go on forever. I would suggest you figure out what the derivation path used on you BCH wallet was (will probably be /m/44'/145'/0') and then loop through different combinations to generate different multisig addresses.
How come you only have the xPrivkeys and not the mnemonic words?
If you had the mnemonic words I would suggest recreating the wallet on the same wallet app by importing your seeds and the wallet should scan addresses associated with those keys.

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


text:
What is the memory every node allocates locally for the Bitcoin blockchain?
https://blockchain.info/charts/blocks-size states that the current size of the Bitcoin blockchain is ~134,000MB.  That is 127GB.  Does that mean that every machine that is mining currently allocates 127GB+ for the blockchain?

I think you meant 134,000MB instead of 131Mb. Lowercase b is bit, while uppercase B stands for byte.

Not all mining machines need to store the whole blockchain, as a miner you would normally have one or a few nodes which do that, and then just send a block template to all the actual mining machines (ASICs) to mine without caring about the blockchain.
All non-pruned full nodes store the entire blockchain. It's possible to run in pruned mode which means older blocks are pruned and only the newest ones are kept, so you need less space, but this means those nodes can't serve old blocks to new full nodes trying to sync

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


text:
Why cant i retreive my BTH coins from my blockchain wallet
I logged into my wallet on blockchain.com today. I followed the links through and saw that I had been credited with a equivalent number of bitcoin cash coins that I had been expecting.
I had a few other things to do whilst there so did those first then when I went back to deal with the BTH coins they were no longer showing. what can I do to reclaim my BTH?
btw the other things I did were to move BTC from addresses into my wallet  I also backed up my wallet and recorded a new 12 word phrase but these shouldn't has had any bearing on my entitlement to BTH

What is BTH?  If you mean Bitcoin Cash, the usual abbreviations is BCH (some people use BCC).

Welcome to the site! This may be an issue best followed up with the blockchain.com site itself.

I assume by BTH you mean BCH for Bitcoin Cash.
Blockchain.info does not support Bitcoin Cash so you cannot retrieve your Bitcoin Cash as that is an altcoin. However you can take your 12 word seed phrase and use it in a Bitcoin Cash wallet software that supports BIP 39 like Electron Cash to recover your coins.

hi Andrew @highly thks for thoughts.I wrote to blockchain.info  same day as I posted here but no reply. To clarify, blockchain.info do support BCH and I followed their instructions &found my BCH in my wallet but after I had moved my addresses into the wallet & made a  backup the BCH that I saw earlier had gone.  I was going to try to use the Bitcoin cash wallet site called BTC.com who say I can use a tool they have devised to recover my BCH from blockchain.info into my BTC.com wallet but to do this I have to insert my seed phrase and don't know if it is wise/safe to do this.

The only way for you to access your Bitcoin Cash is to enter you seed phrase into some other wallet software. That seed phrase is what allows the software to generate your private keys so that you can access your BCH. However that same seed phrase also allows them to generate the private keys for your Bitcoin, so you should move your Bitcoin to a different wallet entirely (not address, wallet) before continuing.


text:
Bitcoin Core - Go back to a specific block?
I have a full node of Bitcoin Core wallet. I would like to know if it's possible to delete data after a certain block. For example Bitcoin is currently at block 504385. There was a fork around block 500000 and I would delete all block data after that so I can use the blockchain data I have with the new fork wallet.

You can't delete the block data themselves, but you can reset the blockchain state to a specific block by using the invalidateblock command. This command will mark a specific block and its descendants as invalid thus setting the chainstate to the block immediately before it. Note that this may not necessarily work to switch to a blockchain fork and may still not be able to use the forked blockchain.
If you want to go back to the 500,000th block, you would invalidate the 500,001st block with the call invalidateblock 0000000000000000005c9959b3216f8640f94ec96edea69fe12ad7dee8b74e92. By invalidating the 500,001st block the chainstate resets to height 500,000.

How do I make it go back to block 500000 with that commands? "invalidateblock 500000" ?

You would do invalidateblock 0000000000000000005c9959b3216f8640f94ec96edea69fe12ad7dee8b74e92. That will invalidate the 500001st block thus setting the chainstate to the block at height 500000.

Would restarting your node with the startup options -reindex and -stopatheight=500000 also work?


text:
How does the new database design used by Bitcrust work?
I've recently learned about a new Bitcoin node implementation in Rust called Bitcrust. They state that they have found a novel way of storing the Bitcoin blockchain as a "Spend tree" instead of tracking the UTXO set and claim to have significantly improved the performance of database interactions that way.
Can someone explain how the Bitcrust-db achieves that?

Did you ever find out?

@RedGrittyBrick: Sorry, haven't picked that question back up since.

My understanding after a quick look at the code is that they use this sequential scan of stacked records of spends only for the recent 3 blocks (https://github.com/tomasvdw/bitcrust/blob/556375ccfaa81ca241b25f7b5b7f00fb97d5bd6b/src/store/spend_tree/record.rs#L296)
If the sequential scan did not find a match (if the input is from older blocks), they use this huge 2^58-bit bitmap, that is sparsely mapped to sparse files (if the filesystem does not support sparse files, they will use 16GB of storage for each 'range' that contains at least one bit set)
the code that uses 58-bit index:
https://github.com/tomasvdw/bitcrust/blob/556375ccfaa81ca241b25f7b5b7f00fb97d5bd6b/src/store/spend_index.rs#L67 (more exactly, a 52-bit index to a map of U64 values)
the 'hash' variable there does not contain a true hash, it is just a mapping of the internal storage indexes to 58-bit value: https://github.com/tomasvdw/bitcrust/blob/556375ccfaa81ca241b25f7b5b7f00fb97d5bd6b/src/store/spend_tree/record.rs#L168


text:
Can anamurminers.com be trusted?
I'm thinking about ordering two 63 GH/s Bitcoin miner's from Anamurminers.com Also see: http://anamurminers.com/asic-miner. Can this company be trusted? They say they can ship two to the UK straight away.

There's no way this is legitimate.

Domain is less than a month old
All product photos can be found elsewhere on the web. http://www.stss.ru/products/workstations/tesla/RX240T8.2.html http://www.fractal-design.com/?view=product&prod=94
Address/phone number/name on Contact Us page differs from address/phone number/name on WHOIS record.
They say their miner connects over USB. However, they don't have any drivers for it on their website, or say what OS it works with.
They said that they're too busy to take a video, or post an non stock-photo image, but they would in a week. They said that 10 days ago.
They claimed that they designed, wrote, sourced, soldered, and tested the whole thing, front to back, in 3 weeks. Then somebody on bitcointalk pointed that out, and now it took them 3 months! Still implausible, though. Unless you're willing to pay insane markups, your shortest turnaround time on an ASIC is around 6 months, and that's if you already have your design done.
They offer local pickup (in the Czech Republic)
This gem:

Due to Czech law, we MUST, give you back your money even after 14 days, if you are not satisfied with the product.

I doubt that.

So yeah. Scam. I'm guessing that Antonio Barreto is the brains of the operation, and Anamur Silif is the fall guy.

Certainly nobody except the owner or local auditors can tell you if its a scam, all you can do is gather as much information as possible. Maybe the only real deal would be to visit the company locally or get documents that proof what they claim.
Concerning the website, its a very basic opencart shop one can setup in 30 minutes.
Below is what i got on a fast search.

Information about us
www.anamurminers.com is a site operated by Anamur Silif, s.r.o.
  ("We"); we are a company registered in Czech republic under
  registration number 241 65 280. Our registered office is Primátorská
  296/38, Prague 8   180 00.

#

The domain/hosting whois reveals:   Email Search: is associated with
  about 213,056 domains NS History: 3 changes on 4 unique name servers
  over 0 year. IP History: 3 changes on 4 unique IP addresses over 0
  years. Whois History: 13 records have been archived since 2013-05-04 .
  Reverse IP: 629 other sites hosted on this server. Log In or Create a
  FREE account to start monitoring this domain name Preview the complete
  Domain Report for anamurminers.com
Registrant:  Anamur Silif s.r.o.  Kasparova 590  Liberec,  46312  CZ
Domain name: ANAMURMINERS.COM
Administrative Contact:
      Barreto, Antonio Joaquin
      Kasparova 590
      Liberec,  46312
      CZ
      +420.774984192    Fax: +420.000000000
Technical Contact:
      a.s., INTERNET CZ
      Ktis 2
      Ktis,  384 03
      CZ
      +420.383835353    Fax: +420.383835354
Registration Service Provider:
      INTERNET CZ, a.s.,
      00420-38-3835353
Registrar of Record: TUCOWS, INC.  Record last updated on
  10-May-2013.  Record expires on 30-Apr-2014.  Record created on
  30-Apr-2013.
Registrar Domain Name Help Center:
      http://tucowsdomains.com
Domain servers in listed order:
      NS2.GOSHAWK.ARVIXE.COM
      NS1.GOSHAWK.ARVIXE.COM
Domain status: clientTransferProhibited
                  clientUpdateProhibited

#

Google search on Anamur Silif, s.r.o
https://www.google.com/search?q=Anamur+Silif%2C+s.r.o&ie=UTF-8&sa=Search&channel=fe&client=browser-ubuntu&hl=en

#

More lookups:

http://rejstrik.penize.cz/24165280-anamur-silif-s-r-o
http://www.bizbiz.cz/v2/firmy/239749/anamur-silif-s-r-o
http://topkontakt.idnes.cz/f/anamur-silif-s-r-o/1945713/

seems like they are also discussed here:
http://bitcointalk.org/index.php?topic=233346.0


text:
Miner hardware problem
So, I have been mining LTC with a custom rig (see below for hardware details) and this morning it was down. When I restarted it, it worked fine for two minutes then shut down again without beep nor blue screen. Here is what I have try to understand where the problem comes from.

Tried a different power bar
Let the PC run without the miner software enabled (PC don't crash in that case)
Let the PC run with the miner but only 3 GPUs working (PC don't crash in that case)
Let the PC run with the miner but 4-5-6 GPUs working (PC crashes)

I have few hypotheses.

Add4PSU which plug the two PSU in serie doesn't work: I don't know if the 6 GPUs would start in that case, however, since three are plugged on the second PSU.
For some reason, heat make the PC shut down (sensors broken or something strange)
One of the PSU can't get enough power when the GPUs work at 100%

I do not know if someone has any idea. I'll post this also on superuser stack. Here is my hardware:

Mobo: MSI Z77A-G45 ATX LGA1155 Z77 DDR3 3PC I-E16 4PC I-E1
GPU: 6 PowerColor PCS+ AX7950 3GBD5-2DHPP Radeon HD 7950 3GB 384-bit GDDR5
CPU: Intel Celeron G1620
Mem: 2 Viper Xtreme 1600Mhz, 2GB
PSU: 2 Corsair Professional HX850W 850W ATX 12V 70A 24PIN ATX Modular (Gold rated, plugped with Add2PSU)

Here's another hypothesis: The AC power available at the plug(s) is inadequate or unstable.


text:
Reliable, efficient way to parse the blockchain into a SQL database
I need to generate a SQL database (preferably SQLite3) of every transaction that has occurred in the blockchain. Is there an efficient way to do this using open-source software? I'm attempting to do it myself using a Haskell script that makes system calls to bitcoind but I'm having trouble making it sufficiently fast.

Does it have to be SQL or can you use LevelDB?

I know that bitcoind (if you changed the settings, which I have) creates a LevelDB database for its own use. However, there is very little documentation on LevelDB in general, and even less in my language of choice (Haskell). I want something that I can easily use in a clearly correct way in code that analyzes the data, and SQL seems like the only option for that.

I created a fork of blockparser with a 'csvdump' command that will generate a details dump of the blockchain in CSV format.  There are also some support scripts in that repository for creation, population and periodic update of a PostgreSQL database.
Be aware that the resultant database is pretty large; you might want to consider PostgreSQL over SQLite for this one.

I remember blockparser being slow as sin for single transaction and account data when I first tried it, but I'll give the CSV dump a shot and see how long it takes. Do you remember how long it took for you? If so, what were the specs of the machine you ran it on?

blockparser is relatively CPU and memory intensive.  I just carried out a full csvdump on my machine and it took 9 mins, maxing out at just under 9GB memory used.  It will definitely help if you have a decent CPU and SSDs for storage.

I'm currently running the SQL dump. It's much faster than Bitcoin-Abe; it looks like it's only going to take about five hours. However, I wonder whether it parses the transaction data or just leaves it in raw hex.

Depends what you mean by 'data'.  Information is supplied on individual transaction inputs and outputs, but there is no work carried out to parse the signatures.

This works great, but I have one qualm: why don't the transactions have timestamps?

Individual transactions do not have timestamps in the blockchain.  See https://en.bitcoin.it/wiki/Transaction for details

I can't find another way to contact you, but you should consider changing the sql.cpp file in that fork to just make temporary CSV dumps and then parse them into a database using the MariaDB (or equivalent) LOAD DATA INFILE command. That would take less than an hour on a weak machine, where as sql.cpp takes days. I'd help, but I don't know C++.

Haven't looked at the existing sql.cpp much because it didn't gather all the info that I needed.  Feel free to fork znort's code and send him a pull request.

Also, have you noticed that InputTxHash and InputTxIndex are always null in outputs.csv?

Yes they will be.  You'll need to post-process the data to link the inputs to the outputs.  There is some example SQL to do this for PostgreSQL somewhere in the database load files.

Would h2 work? I am interested in storing only the UTXO set, indexed by addresses.

Possibly checkout ABE - Alternative Block Parser. It uses python and a SQL-based database but you can hook up other databases based on the driver.
https://github.com/jtobey/bitcoin-abe

This is a legitimate option. However, it's getting to be unrealistically slow as the blockchain grows. With SQLite3, it now takes days, from what I can tell.

Well start it, then have a client that keeps it up to date. Yes, it'll grow, as you're asking for a database that will encompass the blockchain. There's no immediate solution to that unless you want a database that has a reference to points in the chain. Did you want something "fast"? Use LevelDB.

Or mcdee's blockparser.

You can always use BlockchainSQL Server for SQL querying the Bitcoin blockchain.
The web version is free, the server is commercial.
Disclaimer: I am the developer.

Website seems down

To transfer to a SQL Server database you can try BitcoinDatabaseGenerator.
You can download it from https://github.com/ladimolnar/BitcoinDatabaseGenerator/releases
Sources and wiki: https://github.com/ladimolnar/BitcoinDatabaseGenerator
The transfer is very fast. At the time of writing this, the transfer of 266 blockchain files totaling 33 GB took less than one hour and 30 minutes on my development machine. Of course, the time will vary depending on hardware and configuration.

is it working under linux?

BitcoinDatabaseGenerator is Windows only.


text:
How is the recipient address for closing a Lightning Channel derived?
I've recently opened a payment channel in the Bitcoin testnet LN.
The funding TX ded9fc8b1ee5506037e057a37057a598c362c4b698a40076e75ea88e2ae8a2a2 decoded:
{
  "txid": "ded9fc8b1ee5506037e057a37057a598c362c4b698a40076e75ea88e2ae8a2a2",
  "hash": "4357b13721588eae4979c6f2814be14bad60535ce284b495f089b3eb68c24e03",
  "version": 2,
  "size": 405,
  "vsize": 243,
  "weight": 972,
  "locktime": 0,
  "vin": [
    {
      "txid": "9d25bdb718e534d6ada203c1291c123a64e96b9cfa9c0c50041499a60034cc0b",
      "vout": 1,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "30440220064b2596e29dd361e76839bc2aa9c3f98690a6b181bfa7809aaddd6faa656ae602201882cc8b29fe2e5e2cdbfd42dbdaa432e69d38fd4b0a018878b4f04d284d70ba01",
        "02aaf68be77ecf046ba50f6aa04f7feca52ca10f8e9a728962d47dabc590170b70"
      ],
      "sequence": 4294967294
    },
    {
      "txid": "cf4e8553b976f05e3dba2189c50a682c3e8801d6cc8506b90eba35aefb915aa8",
      "vout": 0,
      "scriptSig": {
        "asm": "001473b9bbe0a9c3753c77e0e2a75ea80284c0573568",
        "hex": "16001473b9bbe0a9c3753c77e0e2a75ea80284c0573568"
      },
      "txinwitness": [
        "304402207b325f4a5f4dae4fdae611826b8358845f5393322814d564e4d87fd40563eff702203dcb12991ff0207d2855b088221ee79d65f034636eb285317a67aa6b1642120101",
        "03d4926529290be91f2290b017b5dbf0f2bcf9d33a2bf0c90ed86138ceeb1d4970"
      ],
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 0.01188846,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 3d8f9974dc89ea3ad4b7306c6820ff64083bf4d1",
        "hex": "00143d8f9974dc89ea3ad4b7306c6820ff64083bf4d1",
        "reqSigs": 1,
        "type": "witness_v0_keyhash",
        "addresses": [
          "tb1q8k8ejaxu384r449hxpkxsg8lvsyrhax3xh2lsc"
        ]
      }
    },
    {
      "value": 0.01400000,
      "n": 1,
      "scriptPubKey": {
        "asm": "0 00c3e38f885b98f1d536bfc9f3e6c4b15bbe3879094e191936b8c5d792de6252",
        "hex": "002000c3e38f885b98f1d536bfc9f3e6c4b15bbe3879094e191936b8c5d792de6252",
        "reqSigs": 1,
        "type": "witness_v0_scripthash",
        "addresses": [
          "tb1qqrp78rugtwv0r4fkhlyl8ekyk9dmuwrep98pjxfkhrza0yk7vffqpzuhga"
        ]
      }
    }
  ]
}

and to closing TX a867d06e9841b8c60318554bb4efc9bcf050dae4789f63403737597adc864af8   decoded:
{
  "txid": "a867d06e9841b8c60318554bb4efc9bcf050dae4789f63403737597adc864af8",
  "hash": "dde0cc812f55df3a3163de5963bf74ba5cc51e1fbc0a5bd568eb3cf9fc10b28f",
  "version": 2,
  "size": 304,
  "vsize": 139,
  "weight": 553,
  "locktime": 0,
  "vin": [
    {
      "txid": "ded9fc8b1ee5506037e057a37057a598c362c4b698a40076e75ea88e2ae8a2a2",
      "vout": 1,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "",
        "3045022100fb500b4d35fe0e64aca0bd5311e58182aaec09345eba79b470d7985a7f5824cb022044a98de94465c520a06b9e4084f5d2b92d3e042bf51e603f8b8e1d318e23e09e01",
        "3044022050a97294e904033fc32b313db771c7fa81c96a2cd51f868b1d35ec100224bc5a02207e8528e2ba002a127ed9ca85fc35804c1bbd98f106e6ab0920b08af794b5b4bf01",
        "5221025fce122008fae0295572467c5f28ae5c2dda9653be88038b85fc70e501be062b2103db50a4a1c290e2570ba36317709cc5ea6f9d94d43532581f9c8da945f7baeba852ae"
      ],
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.01399770,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 f75a397c32f4bb83df13f684cc34d9a51bd98b4a OP_EQUAL",
        "hex": "a914f75a397c32f4bb83df13f684cc34d9a51bd98b4a87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2NFo6yaTxo78vvCHe3bk6gGVngRyp2Psvnk"
        ]
      }
    }
  ]
}

I am having a hard time to figure out how I can know the receiving address ("2NFo6yaTxo78vvCHe3bk6gGVngRyp2Psvnk") prior to the closing of the channel? Is it an address in the outputs of the funding transaction? Because I can't find this address there. So, how did the building of the closing transaction take place?
I'll be happy to understand more about the funding and closing tx scripts / process.

I will only give the answer for a mutual close. The situation for unilateral (forced) channel close should be similar only that you have too look in the commitment transactions and that you have to look for local_delayedpubkey instead of localpubkey.
You can look at BOLT 03: Transactions where it is specified. In particular the section closing transaction. From there we quote:

txout script: as specified in that node's scriptpubkey in its `shutdown message``

This means we look in BOLT 02: Peer Protocol for the closing shutdown message. There the following is specified:
Either node (or both) can send a shutdown message to initiate closing, along with the scriptpubkey it wants to be paid to.

type: 38 (shutdown)
data:
[32:channel_id]
[2:len]
[len:scriptpubkey]

which means that the shutdown message basically specifies a channel and a scriptpubkey to which the amount is being paid. Furthermore it is specified that the sender:

MUST set scriptpubkey in one of the following forms:
OP_DUP OP_HASH160 20 20-bytes OP_EQUALVERIFY OP_CHECKSIG (pay to pubkey hash), OR
OP_HASH160 20 20-bytes OP_EQUAL (pay to script hash), OR
OP_0 20 20-bytes (version 0 pay to witness pubkey), OR
OP_0 32 32-bytes (version 0 pay to witness script hash)

The spec also mentions the ability to specify the closing scriptpubkey during channel establishment in the announcment messages. The spec keeps silent about the form of the output address.
To a first approximation it seems that every implementation can choose those keys for themselves as long as they are of the above form. However - while this might work - the spec tells something different (in order to make privacy watch tower services possible). So looking at another section of the bolt3 about key derivation we find learn:

These pubkeys are simply generated by addition from their base points:
pubkey = basepoint + SHA256(per_commitment_point || basepoint) * G

The localpubkey uses the local node's payment_basepoint
The corresponding private keys can be derived via:

privkey = basepoint_secret + SHA256(per_commitment_point || basepoint)

This means that we have to figure out how to derive the basepoint_secret and the per_commitment_point which is also explained in this BOLT and so much detail that I haven't looked at it yet.


text:
How can I set a fixed fee sufficient for transaction success in bitcoind?
I used to use sendtoaddress with bitcoind and a fixed 0.0001 btc transaction fee in the wallet UI to do the job and every transaction was sent without any problems.
Since version v0.12.0 I can see that the fee is not fixed, plus some transactions don't transmit to the network.
How can I send transaction with bitcoind that will be 100% relayed ?

You can try:
txconfirmtarget=1

If paytxfee is not set, include enough fee so transactions begin confirmation on average within n blocks (default: 6).
So putting it equal to 1 will automatically set the fee to be included in the next block.
Note that this isn't a "fixed amount solution".

Since 0.14, you cannot ask for a confirmation target of 1 anymore, because there is basically no fee that can guarantee inclusion into the next block (it may happen within seconds, giving miners not enough time to include it). If you ask for 1, it will be rounded up to 2, or whatever number sufficient data is available for.


text:
How can I get the DateTime of when bitcoind last received a block?
Is there a command to get the DateTime of when bitcoind last received a block?

This question was just pushed back to the frontpage. I've tried to rework it to make it as clear as possible and added some more tags. Please feel free to further edit or improve the post, or revert my changes if it isn't asking what you were interested in anymore. If it already has been answered to your satisfaction it would be helpful if you accepted an answer, so that it doesn't show up as "unanswered" anymore.

I think people look at the bitcoind log files to see the received times.  Possibly a grep on the log file might be what you need?

What you probably want to do is set up a -blocknotify= script when you start your daemon. For example, you could echo the block hash with the %s formatter, and echo the time it was received, directing the output to a file:
./bitcoind -daemon -server -blocknotify="echo %s; date"

No, there isn't.
getblockcount can only get the number of blocks in the best chain, but not the last received block.
You might need to write a new rpc to get the last received block.
First, add a new data structure in main.cpp and record blocks received order in ProcessBlock().
Second, write a rpc to print out that data structure.

If you mean the number of blocks in the entire chain, getblockcount gives you that.
The commands getinfo and getblockchaininfo also both contain "blocks" in their reply. The latter also includes "headers", which should show you a higher number than "blocks" when bitcoind has not caught up yet but has heard about a newer block.


text:
How is a blockchain split resolved?
Let's say two miners created 2 different blocks and broadcast them into the network. Now some clients see blockchain 1 and other blockchain 2 which are different from each other.
I would like to understand technically as possible how in the end the majority of clients will continue with only single chain and the other be abandoned?
Why will they choose one over the other?
I would like to believe this is done automatically by the clients / miners without human touch, only by some kind of coded logic. That logic is what I'm after.
Related question: What happens to extinct blockchains, and transactions inside of them?

a.k.a. An orphaned block. A valid block that achieved some network propagation but a "better" block came along at the same time and took over.

You're looking for CBlockIndexWorkComparator, which operates by three rules. The rules are applied one at a time, and if a rule leads to a tie, then the next rule is applied.

Which blockchain has the most work?
Which one was received first? (This can be different for different clients, which is why the previous rule is applied first.)
Which one has a larger pointer address? (This is largely random, and different for different clients.)

Please explain the meaning of the 3rd rule.

@HaddarMacdasi Programs on a computer use memory, and pointers tell the program where it can find the data it wants to see. What pointer address each one gets is decided by a memory allocator, which is usually part of the operating system. The purpose of this rule is to provide a tie-breaker that can always break ties.

If clients will get into deciding the chain to go with based on the 3rd rule, which has I understand is just like flipping a coin, won't the decision splits again 50% going with the 1st chain an the rest with the 2nd ?

@HaddarMacdasi Exactly. But that split won't last forever, because of rule #1. Eventually some miner will win.

If a node receives a second split block, do they drop it immediately or do they keep it around? If they drop it immediately, how do they resolve it if that block they dropped ends up being part of the longest chain?

The third rule only applies to old blocks, loaded from disk. It should never affect the outcome on the network, because as soon as a block is received from the network, the second rule takes precedence (one block must have been received before another).

This is explained in the Bitcoin paper:

Nodes always consider the longest chain to be the correct one and will
  keep working on extending it. If two nodes broadcast different
  versions of the next block simultaneously, some nodes may receive one
  or the other first. In that case, they work on the first one they
  received, but save the other branch in case it becomes longer. The tie
  will be broken when the next proof-of-work is found and one branch
  becomes longer; the nodes that were working on the other branch will
  then switch to the longer one.

The idea is that it's quite rare for the network to find 2 different blocks at around the same time. If it happens, you'll have peers working on one chain and others on the other. It becomes even rarer for it to happen in succession, so it's just a matter of time that the network will converge on a single chain.


text:
How to check testnet address balance
I have an address mpc1rKeaMSCuQnJevMViLuq8uWjHwgdjiV
I check it via json rpc and get balance = 4.6 with 6 confirmations
When I check http://blockexplorer.com/testnet/address/mpc1rKeaMSCuQnJevMViLuq8uWjHwgdjiV
I get nothing.. is it OK ?

I’ve collected all of the below mentioned testnet block explorers in the linked community wiki today.

The testnet Block Explorer doesn't seem to be working. If you go to http://blockexplorer.com/testnet, the most recent block it shows is from August 29, about two weeks ago.

BTC Look's Testnet is still online. Try http://testnet.btclook.com/addr/mpc1rKeaMSCuQnJevMViLuq8uWjHwgdjiV.

not working anymore

BlockStream and BlockCypher are useful:
https://blockstream.info/testnet/address/tb1qhmwlez06e5p78lnycypnaqctcuczhmznwhq5zu
https://live.blockcypher.com/btc-testnet/address/tb1q4mcpay7xczhqnj5gpcz5eckw0rjlr35tkezw45/

Thanks, I started a community wiki to keep a list of testnet explorers here: https://bitcoin.stackexchange.com/questions/121054/where-can-i-find-a-testnet-or-signet-explorer

There is also Blockr.io Bitcoin TESTNET

not working anymore in 2021

A reasonably fast & stable testnet API I could find is Blocktrail
JSON
https://api.blocktrail.com/v1/tbtc/address/mpA7LkZe8TKNMgTPJVbn5StQ6Yh28fXg1d?api_key=MY_APIKEY
HTML
https://www.blocktrail.com/tBTC/address/mpA7LkZe8TKNMgTPJVbn5StQ6Yh28fXg1d/transactions

site is dead in 2021

The Block Cypher website has a testnet blockchain explorer. https://live.blockcypher.com/btc-testnet/


text:
Why is utxo time a priority for miners?
I've understood (maybe mistakenly) that once free transactions arrived to be collected into new block the miner will prioritize them by fee, then by maturity, meaning will take the transaction with the oldest inputs. Why?
What kind of incentive does the miner have to do so?

First of all, this is a slight oversimplification: after taking transactions with fees, the standard policy is that priorities of remaining transactions are weighted by age and amount transacted.  For each input to the transaction, the age of the input being spent (counted by number of confirmations) is multiplied by the bitcoin amount of the input, and the result is summed over all inputs to get the priority of the transaction.  So a large-value transaction spending a fairly recent input might get higher priority than a very small-value transaction spending an old input.
There's certainly no requirement for any given miner to follow this policy (miners have complete freedom as to which valid transactions they include in their blocks), nor is there any direct financial incentive for them to do so.  However, there are a few indirect incentives.

The policy described above is the default behavior of Bitcoin Core.  A miner who is willing to use this policy can use Bitcoin Core for their transaction processing, rather than having to spend time and money to find or develop some other software.
Since miners are out to earn bitcoins, they have an incentive to behave in ways that help make the currency convenient and desirable for people to use, since that should increase adoption of the currency and ultimately increase the value of a bitcoin.  So if they believe this policy is helpful to the community as a whole, it is in their interest to use it.  Even if they are not sure this policy is inherently the best, there is some benefit in using it simply because it is standard; it is good for the currency's transaction processing to behave consistently, so that users know what to expect.

One more thing:  Isn't the coin age the best deterrent against the free spamming the blockchain?

@linhares Yes and no. You're assuming that spamming the blockchain is "impulsive": a little planning would circumvent this.


text:
Why bigger blocks will bring bigger memory usage for miners?
I see the different proposals for the block size and I keep wondering why bigger blocks means a bigger chain ? If the block limit size will rise to twenty-megabyte, it is just a limit, to fill it it requires twenty-megabyte of transactions. so if there are twenty-megabyte of free transactions a block will be twenty-megabyte size but it all still depends on the total size of valid free transactions and now it doesn't even get to 600k in average. yes in time the block will be filled I guess it will take years but it is the natural growth of the system. so my question is why bigger block size means immediately bigger memory for miners ?

Mike Hearn pointed out earlier on the mailing list, Satoshi added a block limit to avoid people mining "troll blocks". These are blocks where a miner includes a Gb worth of transaction output/scripts in the coinbase transaction, or thousands of small transactions. A hard block limit puts a cap on our exposure to this.
There is no minimum block size, since you can still have empty blocks, so increasing the block limit will have no effect on miners.

But "troll blocks" could become bigger ,so now every miner can just fill up 20 mega of block with Hugh coinbase transaction ?

You're assuming only the block size has changed, but the network has grown quite a lot since the 1Mb limit was introduced.


text:
What is the motive of a miner to include transaction in a block?
My question is divided into different parts :

Can a block include only coinbase transaction ?
Why should a miner wait \ include more transaction after starting to create a block ?
If a miner stops the mining process for including new arrived transaction, does that makes him re calculate the previous nonce possibilities for creating the block ?

Blocks can contain whatever is valid, anything beyond that is up to the miner to decide. Including no transactions other than the coinbase transaction is valid, and there is no way of having a rule where this is not the case (was there transactions to include at that point in time?). Miners will absolutely not wait for transactions to be available to mine, as their main source of income is the block reward.
Miners are incentivized to include transactions by the creator of the transaction paying a fee, and the miner collecting it. Including no transactions mean they miss out on income.
Mining is progress free, each attempt is completely unique and has the same chance of winning no matter how many you have made previously or what the contents of those attempts were. Inclusion or exclusion of transactions has zero effect on the chance of a block winning or not as the header is exactly the same length for each and every attempt.

soo.. all in all they just include because otherwise system wouldn't work (imagine you can't confirm transactions) and thus miners btc deposits would be worthless, and they would run out of business..

That's one way of rationalising it, certainly.


text:
Do I need to wait for Bitcoin-Qt to sync with the network before using GUIMiner?
I'm waiting for Bitcoin-Qt to synchronize with the network, but it takes a long time. I'd like to know if I can start using GUIMiner while it's Bitcoin-Qt is still synchronizing.

The answer depends on whether you're using a pool to mine.

If you use a pool to mine, you don't need Bitcoin-Qt to mine, so you can mine straight away.
If you don't use a pool, you need Bitcoin-Qt to be at the most recent block.


text:
What are the relevant hardware-mining options as of 13 May, and and how should one choose one over another?
After reading on the topic of bitcoin for the past few hours I've heard a few terms again and again: mining with the CPU (pointless as of today), GPU mining (lots of people doing this), and then ASIC, and FPGA (field-programmable gate array).
With just a few hours experience in this, and although I've obviously seen the wiki's here and there which compare this hardware to that, the answer to this question could take into account some real-world factors, especially concerning the availability of the ASIC units (which are said to be much more efficient). E.g., there's talk of one particular one shipping, yet orders aren't being filled, doubts as to if they ever will be, etc.
So with that, an ASIC might be worth less consideration than another setup. The answer I'm looking addresses these different types of hardware (excluding CPU which we know are worthless) and which one might be right for someone who wants to join in on bitcoin hobby-wise, and eventually break even in terms of investment (within say, a year). This is only considering hardware and not pools, which I'm aware of.

7950 maybe? Or a used 5870 might be your best bets

In order of hashrate:
ASIC >> FPGA > GPU >> CPU
">" meaning "more powerful", while ">>" stays for "completely outclasses".
Currently there are some ASICs out there, but not so many to totally destroy the chances for the other devices to mine anything, so there's still some people mining with FPGAs and some with GPUs.
Of course those using FPGAs and GPUs already have them, and it would be a pretty bizarre business decision to start using one of them right now (might make some kind of sense for the resell value: an ASIC's only purpose is mining bitcoins, while the other devices once obsolete might be used for something else).
Officially there are three ASIC manufacturers:

Avalon: first to complete an ASIC, ships big devices, but currently isn't taking new orders.
Butterfly Labs: vapourware! Started collecting money almost one year ago, and constantly misleads his customers stating they are going to be "ready in two weeks". Recently shipped a few devices to some selected members (journalists, etc.) and they were very inferior to their specifications.
ASICMINER: instead of focusing on selling hardware, they produce their own devices and use them, selling you shares in their company, giving you dividends; recently they also started accepting orders for small USB ASIC miner.

To say that BFL's miners were very inferior would be incorrect.  They didn't meet the specifications for power use and heat dissipation, but exceeded the hashrate specification.
That being said, it'd be nice if they'd actually nail down a date for us, even if it's not what we would have liked.

All of the statistics you are after are on the Mining hardware comparison page of the Bitcoin wiki.

In my experience, GPU mining has been the most profitable and the least risky as they can be used to mine other crypto-currencies besides Bitcoin. Also GPU hardware can be re-sold to gamers should crypto currency mining fail. Here are several excellent guides to assembling your own Bitcoin mining hardware.


text:
How do I prevent lnd from participating in new channels?
I have a lnd node that I would like to to cycle down completely. I would like to close all its channels and prevent that the node participates in any new channels while I'm waiting for the force-closed channels to mature.
What settings do I need to use in lnd to prevent my node from creating new channels, and to decline any new inbound channels?

LND has a ChannelAcceptor call which is available in API that allows you to block all incoming channel requests. However, I'm unsure if it is available in the RPC interface on the daemon with ln-cli

You can set the option --maxpendingchannels=0 to disallow peers to open channels to your node.


text:
How do light clients using compact block filters get relevant unconfirmed transactions?
I was discussing various light client models and we got into unconfirmed transactions. With the BIP37-based bloom filters, a light client would subscribe to updates from full node peers by submitting its filter to the full nodes. A BIP37 filter could be applied to the mempool and a full node could notify the light client of unconfirmed transactions.
As far as I understands, compact block filters (CBF) are only created for confirmed blocks. This implies that a CBF-based light client would only hear about transactions after confirmation unless they had another mechanism to hear about unconfirmed transactions. Keeping up with the mempool would incur a lot of traffic. How would CBF-based light clients learn about relevant unconfirmed transactions without having all the downsides of BIP37-based wallets?

There's no design consideration in Neutrino / BIP157 for unconfirmed transactions, but it's not as much of a concession with context. A light wallet can effectively do nothing with information about an unconfirmed transaction as they can not verify anything about its validity to begin with. At best it is a suggestion that a transaction may have occurred, but this is even weaker than a normal unconfirmed transaction sent to a fully validating wallet.
It has always been an issue with "SPV" wallets that they can be duped into showing completely absurd false data, for BIP37 especially it was completely possible to sniff the incoming filter and dynamically produce transactions paying to the addresses that likely matched it billions of dollars. The client, as dumb as it is, can only show them to the user and hope that common sense on the part of the user prevails.


text:
Why is there no such thing as a redirected, forged, or fake transaction?
In the past, we had numerous questions about "fake" or "forged" transactions. Such transactions could supposedly be created even without holding any bitcoins, yet would end up in the mempool or even get accepted by the network once they are mined into a block. Other times, the recipient creates a conflicting version of the sender's transaction, or a majority attacking miner would simply redirect all transaction outputs to themselves.
With this topic I mean to create a canonical question for a topic which is described by the following variants of a questions:

Why can I not just make up bitcoins?
Why will fraudulent transactions not get relayed on the network?
Why can only the owner spend their funds?
Why can a third party not alter the recipients of a transaction?
What prevents a miner from taking the funds of your transaction when creating a block?

In other words, let's comprehensively explain:
What makes a transaction valid, how is a transaction protected against tampering, and how can nodes tell?
Here are some examples of topics that might be redirected here in the future:
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11,
12,
12,
13,
14,
15,
16,
17,…

related:
https://bitcoin.stackexchange.com/q/54253/5406,
https://bitcoin.stackexchange.com/q/23430/5406,
https://bitcoin.stackexchange.com/q/62275/5406,
https://bitcoin.stackexchange.com/q/41165/5406,
https://bitcoin.stackexchange.com/q/36152/5406,
https://bitcoin.stackexchange.com/q/51231/5406,

The Bitcoin protocol follows a Unspent Transaction Output system to track the existence and state of all Bitcoin in the system. These are known as UTXOs.
All transactions that transfer Bitcoin do so by consuming one or more UTXOs, and create one or more new UTXOs. The only exception to this is the Coinbase transaction, which is limited to being the first transaction in a block, and is only allowed to create UTXOs that total block reward + block fees or less.
Due to this basic structure of a transaction, it is impossible to create a bitcoin transaction that spends non-existent bitcoin. As the UTXOs being consumed do not exist, the transaction is rendered invalid the moment it is created.
Although this is impossible, why it is impossible is not immediately obvious to people unfamiliar with the details of how Bitcoin works - thus, many people, especially newcomers to the space, seek out such things as a way to quickly get some Bitcoin at no or low cost. Several scammer groups are aware of this, and put out videos showing edited block explorers/wallets that seem to allow them to initiate fake transactions.
These groups then offer to give you access to this software for a small fee, or just let you download it for free - however, not only does it not work as advertised, most of these programs are trojan horses, and contain code to steal Bitcoin wallets on your system, or grant the scammers persistent remote access to your machine.
Answering each point directly:

Why can I not just make up bitcoins?

As all bitcoin in the system are the result of either a coinbase transaction, or the outputs of a transaction that moved previously extant bitcoin, it is not possible to introduce new Bitcoin into the system without being detected. Any UTXO at any point of time must always be traced back to one or more coinbase outputs.

Why will fraudulent transactions not get relayed on the network?

All well behaved nodes on the network validate transactions before accepting them to their mempool, or rebroadcasting them further - part of this validation is checking all utxos in the transaction against the node's own list of valid utxos. If the transaction claims to spend a UTXO that does not exist in the node's list, the transaction is deemed invalid and dropped.

Why can only the owner spend their funds?

Standard Bitcoin addresses rely on one (single key addresses) or more (multisig addresses) private keys. The public keys corresponding to these private keys are encoded into the address itself, inside its locking script (also known as the scriptPubKey). During the evaluation of these scripts, the signature on that input is matched against the embedded public key(s). If the signature does not match, the transaction is deemed invalid.
Note that it is possible to create outputs with no "owner" - The Bitcoin script does not require all locking scripts to include a key check, and it is possible to construct a non-standard script that requires no signatures to spend. However, no consumer wallet does this, and essentially all addresses a normal user will encounter will be backed by one or more private keys.

Why can a third party not alter the recipients of a transaction?

Standard transactions are signed using the SIGHASH_ALL signature flag. This means that the signature for any one input signs all inputs and outputs (in effect, signing all material aspects of the transaction). If any input or output is altered, removed, or otherwise changed, the signature is no longer valid as the data it signs has changed.
It is possible to construct a transaction using other signature flags, as described in my blog post here. However, once again, no consumer wallet uses anything except SIGHASH_ALL.

What prevents a miner from taking the funds of your transaction when creating a block?

Similar to the previous point, a miner is also unable to alter the outputs of your transactions due SIGHASH_ALL signing the entire transaction. If a transaction is intentionally signed with SIGHASH_NONE, a miner could very well take the funds. However, as no sane wallets performs such a signature, this does not happen.


text:
Why is the locktime set at transaction level while the sequence is set at input level?
Giacomo Zucco pointed out the oddity of there being one timelock field per transaction, but one sequence per input.
Even for the original use of determining the order of replacement, it would seem that only the maximum sequence is relevant in the context of the whole transaction rather than each input. Is there a known reason or benefit for each input having a sequence or is it a quirk in the transaction design? What about locktime, would there be a benefit if it also was set per input instead of only once per transaction?

See @RedGrittyBrick's answer for historical context for why there is a per-input nSequence field. The evolution since includes:

nLockTime's meaning has been unchanged since the early days; it indicates the earlier time or height when the transaction can be included in a block (consensus rule). BIP65 later added script functionality for putting constraints on the spending nLockTime value, but the semantics of nLockTime themselves have been unchanged.
nSequence was designed for transaction replacement, and in the original design for transaction replacement, every input could be replaced independently (and could signal independently whether it could be replaced). Originally, nSequence only had one consensus-affecting impact: if all nSequence were 0xFFFFFFFF, the transaction is always eligible for inclusion (even if nLockTime hasn't passed yet). The meaning of nSequence was however changed completely:

The original replacement semantics were disabled in August 2010, rendering the distinction between all non-0xFFFFFFFF nSequence values meaningless.
Non-eligible-for-inclusion-in-blocks transactions were disallowed in January 2013 for relay and mempool acceptance (due to DoS concerns) entirely.
Later, BIP68 added a consensus meaning to nSequence, as a "relative locktime", repurposing the old field that had become redundant. Simultaneously BIP112 added script functionality to put constraints on the spending nSequence.
BIP125 added new transaction replacement rules that didn't involve sequencing anymore.

In retrospect however, I believe it would actually have been better if both absolute and relative locktimes were per-input. Absolute locktimes (the per-transaction nLockTime field) suffer from the problem that one cannot specify both a height-based and a time-based one, which implies that two UTXOs which (through BIP65's OP_CHECKLOCKTIMEVERIFY) require distinct types of locktimes cannot be spent simultaneously in the same transaction.

I'm not sure if you will have already seen this:

From: Satoshi Nakamoto <satoshin@gmx.com
Date: Wed, Mar 9, 2011 at 5:15 PM
To: Mike Hearn mike@plan99.net
Subject: Re: Open sourced my Java SPV impl
[...]

I haven't fully
understood why sequence numbers are a property of the tx inputs rather
than the tx itself.

It's for contracts.  An unrecorded open transaction can keep being replaced until nLockTime.  It may contain payments by multiple parties.  Each input owner signs their input.  For a new version to be written, each must sign a higher sequence number (see IsNewerThan).  By signing, an input owner says "I agree to put my money in, if everyone puts their money in and the outputs are this."  There are other options in SignatureHash such as SIGHASH_SINGLE which means "I agree, as long as this one output (i.e. mine) is what I want, I don't care what you do with the other outputs.".  If that's written with a high nSequenceNumber, the party can bow out of the negotiation except for that one stipulation, or sign SIGHASH_NONE and bow out completely.
The parties could create a pre-agreed default option by creating a higher nSequenceNumber tx using OP_CHECKMULTISIG that requires a subset of parties to sign to complete the signature.  The parties hold this tx in reserve and if need be, pass it around until it has enough signatures.
One use of nLockTime is high frequency trades between a set of parties.  They can keep updating a tx by unanimous agreement.  The party giving money would be the first to sign the next version.  If one party stops agreeing to changes, then the last state will be recorded at nLockTime.  If desired, a default transaction can be prepared after each version so n-1 parties can push an unresponsive party out.  Intermediate transactions do not need to be broadcast.  Only the final outcome gets recorded by the network.  Just before nLockTime, the parties and a few witness nodes broadcast the highest sequence tx they saw.

Quoted from https://www.bitcoin.com/satoshi-archive/emails/mike-hearn/13/
Also seen at https://plan99.net/~mike/satoshi-emails/thread4.html
Mike Hearn replied

Ah ha. A whole unexplored area of the system opens up before my eyes :-) The concept of forming distributed contracts and escrow transactions without needing to trust an intermediary is a concept nearly as novel as BitCoin itself, I think.

I believe the above explains Nakamoto's motivation for the choices initially made with respect to sequence and locktime. Or at least I believe Nakamoto believed it answered that specific question.

As I expect many people know, use of these data fields has subsequently been affected by adoption of ideas such as BIP-68 and forced closure of Lightning channels etc.


text:
What is the problem with the recent "One-Shot Replace-by-Fee-Rate" Proposal?
There recently was a proposal to allow replacements that only beat the original by feerate, instead of by both the feerate and absolute fee.

One-Shot Replace-by-Fee-Rate
We can mitigate Rule #3 transaction pinning in a miner-incentive
compatible way by replacing transactions (or alternatively,
transaction packages) that do not qualify for replacement based on the
existing rules, if they qualify under these alternative rules:

The new transaction (package) has a fee-rate more than r times higher than the fee-rate of the transactions it replaces.
The new transaction (package) has a sufficiently high fee-rate to place it into the upper N blocks worth of the mempool.
The highest mineable replaced fee-rate is not high enough to place the replaced transactions in the upper N blocks of the mempool.
Highest mineable replaced fee-rate in this context refers to the
fee-rate a miner can obtain by mining one or more of the replaced
transactions, taking unconfirmed parents into account.

Setting r=1.25 and N=1 would be reasonable.

I saw a claim that this proposal introduces an infinite relay DOS vector. How would this attack vector work?

TL;DR: Due to the two asymmetric sets of rules for replacement, a total of five transactions is sufficient to make a cycle of replacements that beat each other in turn. This allows an attacker to rebroadcast the same transactions over and over while at most paying for one small transaction per block.

In all of the graphics an arrow points from child to parent, while a dotted line with a socket and ball points from original to replacement with socket and ball at the side of the replacement. A socket without ball (see Step 4) indicates an indirect conflict with the socket on the side of the replacement.
You have three confirmed UTXOs c1, c2 and c3. Let’s say 20 s/vB is the bottom of the first block.

You create tx_LL, a large low-feerate transaction with 100,000 vB at 1 s/vB (fee: 100,000 s). It spends the confirmed output c1 and has an output tx_LL:0.
You attach a small low-feerate transaction tx_LS as a child with 100 vB at 1 s/vB (fee: 100 s) by spending tx_LL:0.

You replace tx_LS with tx_HS a high-feerate transaction that spends c2 and tx_LL:0. tx_HS has 5000 vB and pays 21 s/vB, but since it spends an output of a low-feerate parent, its mining score is only 1.95 s/vB.

You replace tx_LL with tx_LM that has 100,000 vB and pays 3.05 s/vB (fee: 305,000 s) by spending the outputs c1 and c3. tx_LM also indirectly replaces tx_HS even while tx_HS has a higher individual feerate. This is permitted, since tx_LM pays a higher total fee than the replaced transactions and because it only conflicts directly with tx_LL it only has to beat the feerate of tx_LL but not the feerate of tx_HS.

You use the new RBFr rules to replace tx_LM with a small high feerate transaction tx_RBFr with 200 vB paying 20 s/vB (fee: 4000 s) that spends c3 and makes it into the top block of the mempool. tx_LM was not going to be in the next block, and tx_RBFr pays more than 1.25× the feerate of tx_LM. So this is permitted under the new rules.

As no transaction in the mempool spends c1, you then rebroadcast tx_LL and tx_LS.

You immediately replace both tx_LS and tx_RBFr with tx_HS. tx_HS has a feerate of 21 s/vB which is higher than tx_RBFr (20 s/vB) and tx_LS (1 s/vB), and pays more absolute fees than both (105,000 s vs 2000 s + 100 s). But since it’s a child of tx_LL it only has a mining score of 1.95 s/vB.

Repeat 4.–7. to make every node on the network cycle the same five transactions ad nauseam. Roll the locktimes or sequences to make the transaction have a new TXIDs in each iteration, while spending the same UTXOs. The only transaction that is ever in any danger of getting mined is tx_RBFr which costs you 4000 sats. If it it does get included in a block, just start over with two new confirmed UTXOs as your c2' and c3'.


text:
Why is there going to be only 21 million bitcoins in circulation?
Bitcoin production will stop at 21 million bitcoins. Why 21 million and why was the limit put in place?

By limiting the amount of bit coin in the market one can hedge against inflation and avoid the firey demise coming to the rest of the world's fiat currencies. Though bit coin is not backed by any "hard money" it has a natural scarcity that will help keep its value consistent.


text:
How do I figure out the balance of an individual address on Bitcoin for Android?
I have just installed the bitcoin wallet for android on my device and created two addresses.
I transferred some BTC to one address and some to the second one.  I thought the wallet will show the individual balance associated with each of those addresses, but I was wrong.  Bitcoin wallet is now showing me one single balance for the BTC associated with these two addresses.
My question is, I assume that since I cannot send BTC out of each address for more than what it owns in the address (for example, address A - 0.5 BTC, address B - 1.5 BTC), I cannot send 1 BTC out of address A.  But now since bitcoin wallet is mixing the two together I am unable to find out how much BTC each of them own...
Or there is some other way that I am not aware of?

You are trying to use addresses for accounting, but they aren't designed for that.
What you actually want is the accounts feature of bitcoind, though I doubt any mobile wallet implements such a thing.
If you say explicitly why do you think you need to do that, someone might have an answer. Meanwhile, just use the whole balance, and create a new address for each incoming payment, without worrying about specific address balances.

Maybe I got a very wrong impression of bitcoin address.  I always think that bitcoin address is individually holding on to a particular amount of bitcoin.  My question is, if I have 2 addresses in this wallet, AAAA and BBBB, how can I find out which address is used to send the bitcoin out?  Would it appear to the receiver as two addresses?  Or the wallet will just use one?

@beemachine that's the point: every address contains a number of bitcoins, but you should (almost) never care about which address is used to send coins.

Very few, if any wallet client softwares will enable the user to view an address's individual balance. The client will handle sending amounts from multiple addresses seamlessly if a single address does not have a sufficient balance to satisfy request transaction amount.
The only way to do that is to copy the address to the clipboard and use an online service such as Blockchain.info.
If you are wanting to completely separate addresses and make it impossible to mix addresses, you'll need to use two different clients. It may be possible to use one of the web wallets on your phone for one purpose and use Bitcoin for Android for another purpose.

Does all bitcoin wallet work like this?

I've not encountered a wallet that separated addresses.


text:
How does the Kimoto Gravity Well regulate difficulty?
Maxcoin will use the Kimoto Gravity Well (KGW) to regulate the difficulty. From what I could find about the KGW, it retargets after every block and adjusts very quickly, e.g. when multipools add and retract mining power to a smaller coin's network.
Apparently, KGW = 1 + (0.7084 * (PastBlocksMass/144)^(-1.228)) (-> Introductory post by Kimoto) describes how to calculate the Kimoto Gravity Well. On another source, it was stated that "KGW is applied if the hash rate is high, and 1/KGW when the hash rate is low" (-> Post on Catcoin's adoption of KGW).
This leaves me with three questions:

What does PastBlocksMass refer to?
Does KGW only rely on the time required to find the previous block?
Why/How does the above formula produce the described fast adaptation of the difficulty?

Here's where KGW is implemented in Megacoin. https://github.com/megacoin/megacoin/blob/master/src/main.cpp#L1276

That did help: PastBlocksMass is apparently a count of blocks up to a maximumParameter or the genesis block. Unfortunately, there are no comments and the function itself takes a number of parameters.

The explanations on the web are all very vague and mystical, on purpose maybe. Here is my take in simple words, just reading the megacoin source code from the above comment.
The goal is to have a more adaptive way of adjusting the difficulty instead of just averaging the last 2016 blocks like bitcoin. This is needed because of multipools which might switch the coin they are mining, and a sudden change in hashrate  can occur (both increasing or decreasing). Especially when a multipool switches away you get stuck too long with a too high difficulty.
The algo loops backwards through the blocks, starting from the current one. The PastBlocksMass is just the number of blocks, so it starts at one and increases in each loop.
In each loop an adjustment factor is computed, which is the target block time divided by the actual block time, in a cumulative fashion, so at loop 10 we would have the 25 minutes target time divided by the time it actually took to compute the last ten blocks. When the hashrate increases, we get shorter times and an adjustment factor greater than one and vice versa.
The loop ends whenever the average adjustment factor is larger than the kimoto-value, or smaller than 1/kimoto-value. To understand this look at this python script and an example plot:
from pylab import *

one_day = 1440 / 2.5   # how many 2.5 min blocks per day

nmin = one_day / 4     # PastBlocksMin
nmax = one_day * 7     # PastBlocksMax
x = arange(nmin, nmax)   # PastBlocksMass

# start with 2.5 minute blocktime + some noise
t0 = 2.5 + randn(nmax) / 4
t1 = 2.5 + randn(nmax) / 4

# t0 has 20% more hashrate, so shorter blocktime in the beginning
t0[:one_day] = 2.5 / 1.2 + randn(one_day) / 4
# t1 has higher blocktime in the beginning
t1[:one_day] = 2.5 / 0.9 + randn(one_day) / 4

s = arange(nmax)

adjust0 = (arange(1, nmax + 1) * 2.5 ) / cumsum(t0)
adjust1 = (arange(1, nmax + 1) * 2.5 ) / cumsum(t1)

# the magic function
def kimoto(x):
    return  1 + (0.7084 * pow((double(x)/double(144)), -1.228));

plot(x/one_day, kimoto(x))
plot(x/one_day, 1/kimoto(x))
plot(s/one_day, adjust0)
plot(s/one_day, adjust1)
legend(["kimoto","1/kimoto", "20% increase in hashrate", "10% drop in hashrate"])
xlabel("days")
ylabel("adjustment factor (target/actual blocktime)")
show()

The script produces a figure like this .
It shows two constructed examples when the hashrate increases and when it drops for one day. Best is to play with different settings for a while to get a feel for what is going on.
You see that the lines cross through the Kimoto formula at some point. This is when the algo exits and uses this adjustment factor to compute a new target/difficulty. For large adjustment factors this happens earlier than for the ones closer to one. This is to have a quick adaptation if the hashrate changes a lot, and a slower one if not - then we want a longer period to get a better average. The parameters of the Kimoto formula are adjusted in such a way that one roughly adjusts in one day to a 10% change and in seven days to a 1.2% change. A minimum of 144 blocks determine the new difficulty and at most 4032 (0.25 days or 7 days for a 2.5 minute blocktime).
Summary: the Kimoto gravity well algo has a fancy name and determines the number of blocks which contribute to the evaluation of the new difficulty. It gives fewer blocks for high hashrate changes and is therefore more adaptive.

Thank you, this is very helpful. One thing I am not sure I understood: What happens when the minimum of 144 blocks isn't reached or the maximum of 4032 blocks is exceeded. Is the KGW then used or is it then not used?

The minimum is 144 blocks. So if the adjustment factor is larger than 1+0.7084, then the factor for 144 blocks is taken. At 4032 the algo stops and the average for 4032 is taken no matter what. KGW gives an answer for both boundary cases.

Okay, thanks, now I get what you meant with that sentence. Excellent answer, thank you very much.


text:
When a Ripple-Gateway charges a fee for third parties exchanging their IOU, how is it determined who pays the fee?
When a Ripple-Gateway charges a transit fee for third parties exchanging their IOU, who pays the transit fee?

Extremely similar to your other recent question: http://bitcoin.stackexchange.com/questions/13249/when-a-trade-offer-in-ripple-incurs-transit-fees-who-pays-them

Mh, I wasn't sure how similar they are, because of course with the trade there might be transit fees occuring for IOU moving in either direction. Maybe I should consolidate the two questions, what do you think?

When a Ripple user sends funds, he sets the amount that he wants the recipient to receive and the system will offer a proposition on how much the input for the transaction needs to be.
Upon execution the transaction is atomical (either it happens completely or not at all). The system will use the ledger to find the optimal path and the sender pays all transit fees occurring along the path.

See also https://ripple.com/forum/viewtopic.php?f=2&t=3402&p=15126#p15126


text:
How can you construct a cycle with LND to rebalance one of your channels with another?
I have at least two open channels, one of which has inbound capacity and the other has outbound capacity. How can I find a route and construct a payment to rebalance my channels against each other just using the LND commandline?
As in, what steps are necessary to stitch two routes together to form a cycle?

Just to make sure: the lnd commandline means any commandline using a chain of lnd commands? Because if it was just about command line you could use lndmanage ( https://github.com/bitromortac/lndmanage ) I would post this as an answer if you are happy with this.

I've seen multiple third-party tools that would construct these transactions automatically for me, but I don't want to introduce more review/trust. We've succeeded at sending a two-hop by manually editing route information, and I was hoping that there would be a better way to do it without quite as much manual intervention but without third party tools.

Create an invoice for yourself: lncli addinvoice <amt>
Pay the invoice specifying the outgoing channel and the last hop to take before paying you: lncli payinvoice --allow_self_payment --outgoing_chan_id <outgoing_chan> --last_hop <last_hop> <payreq_from_1>

To get the outgoing channel id use lncli listchannels --active_only. I usually have to grep for the remote_pubkey that I get from Zeus interface and then look for the chan_id string.
The last hop is the remote_pubkey of the node associated with the channel you want to increase the local balance on.
I learned this from this pull request documentation: https://github.com/lightningnetwork/lnd/pull/3736
Good luck rebalancing!


text:
Is centralization in the Lightning network inevitable? Why (not)?
Especially keeping in mind the possibility of single-funded channels (see Tadge's Google Doc Slides), buying from an exchange and concurrently opening a payment channel on the Lightning network would seem a particularly simple entry to the LN.
Exchanges and payment-providers would therefore seem to be in a natural position to become well-connected.

Is it fair to expect emergence of a network topology strongly centered around well-connected nodes such as the aforementioned and other liquidity providers?
What incentives are there for establishing additional connections with less well-connected nodes?
Is it reasonable to expect the network to "flesh out" with alternative connections around the center nodes?

Frankly, I think we're like blind men describing an elephant. If the routing protocol hasn't been specified yet, we can't say whether the protocol as a whole is inherently X.

@NickODell There is some merit to this assessment, but luckily this question can just remain open and be updated with future information! :)

“Centralization” is now a word constantly repeated but is one that, generally speaking,
   no one tries to define accurately.  ---Alexis de Tocqueville, Democracy in America, Vol.1, Part 1, ch.5.

Lightning Network channels will naturally tend to form along the paths of economic
activity.  If you assume (as I do) that most economic activity in
Bitcoin today is from individuals to large Bitcoin businesses (mostly
exchanges), then you should further assume that most channels will be
between users and those very same large businesses.
You can call the centralization if you wish---but it is not a
centralization of Lightning's making; it is a centralization that already
exists for Bitcoin users.
Moreover, even though Bitcoin commerce and trading is dominated by large
businesses, there are quite a few of those large business.  I haven't
looked up figures, but I would suspect that Bitcoin commerce has a much
less centralized distribution than mining at the present time---and with
new businesses offering Bitcoin-payable services all the time, Bitcoin
commerce would seem to be in a steady of progressively becoming more
decentralized.

The "centralization" that most people talk about is really about limiting who can effectively (and profitably) participate.
If we're talking about the blocksize debate, the idea is that larger block sizes require faster internet connections to remain competitive and at a certain point this might make it infeasible for any but a few large companies to be profitable mining blocks. If this is true, because bitcoin is essentially controlled by miners, this could lead to a different group of people controlling bitcoin than do now (ie perhaps a group we don't want controlling bitcoin).
If we're talking about the lightning network, the idea is that larger hubs would have the advantage over smaller hubs because they'd be more likely to have a route to whoever you want to pay and those routes are likely to have fewer hops. The thing is, if this is true it doesn't really affect Bitcoin. Even if the result is that everyone is connected to one single hub, that hub has 0 power to influence miners. If that megahub ends up being a bad actor, someone can easily switch to another hub. There might be some privacy issues with a megahub, and they could censor transactions, and that kind of thing, but it wouldn't be able to steal your bitcoins nor would it be able to hijack the consensus rules of bitcoin for its own gain.
My opinion is that the advantage of having fewer network hops isn't really much of an advantage. Its much more likely that many medium-sized hubs will be created, not the least reason being that people are going to want to connect to multiple different hubs in the case that one of them goes down for some reason.
So tl;dr, the LN doesn't really have a major centralization pressure, and even if it did, the centralization wouldn't cause any major problems.

Sad to see people downvoting this question.
Contrary to Harding's statement that "Lightning Network channels will naturally tend to form along the paths of economic activity", in LN channels... there are no such paths, there is no routing.. there are only channels with btc stuck between 2 parties.
So, yes, if one party is Amazon, you may be able to get an enormous amount of different goods.  And if it's your local tomato-farmer, you can only get tomatoes from them.
So centralisation becomes a certainty in LN, be it coinbase, bitpay, amazon, of whomever is big enough to attract inflows of btc... the only incentive is to get big, and get big fast.

Sad to see people downvoting this question. Huh? I don't see any downvotes on either Harding's answer or Murch's question.

Could you please cite a source for there being no routing in Lightning Network channels?  The protocol described in the LN paper (as well as the modifications to switch to a segwit-based construction and using shachains) describe a network that allows payments to be routed without intermediaries being able to steal any payments.

@NickODell: I think that he may be referring to the /r/bitcoin topic I linked this in, it's currently at a score of zero.

@linhares: Payment channels by themselves would only be useful for multi-payments, as most business relationships are asymmetric. My question is based on the fully implemented Lightning Network which includes payment routing.

Premise in answer assumes LN locks funds between 2 parties and ignores the fact that despite that LN still allows to routing payments to other (than those 2) parties.


text:
Where can I find the current fee level for LTC?
I'm currently working on something that needs to estimate the fee for Litecoin transactions. Where can I find an overview of the Litecoin fee market?
The Litecoin wiki on Fees has been last updated in Nov 2015.
The Litecoin client used to specify a flat fee rate of 100,000 litoshi/kB until about two weeks ago, which appears to have been replaced with a dust limit of 100,000, and a new default minimum of 1,000 for block inclusion.
Is there an overview where I can learn how fees work today in Litecoin?

Looking at Litecoin coming from Bitcoin, most blocks have plenty of space: right now most are between 2 and 30 transactions only. It turns out, that most transactions appear to only pay the default minRelayTxFee, which is currently set to 100,000 litoshi per kilobyte in the master branch of Litecoin.

Update: There are some changes in the Litecoin fee structures outlined in this blog post: Understanding Default Minimum Fees. In summary, the recent Litecoin Core 0.15.1 release lowers the minRelayTxFee to 1,000 litoshi per kilobyte and the minFeeRate to 10,000. Eventually, the latter is supposed to be dropped to 1,000 litoshi per kilobyte as well.


text:
Can a Bitcoin transaction have the same address for input and output?
Can a Bitcoin transaction have the same address for input and output, i.e. spend some of the coins that are linked to an address and send the rest back to that same address? Is there some reason why it is imprudent to do so?

At the protocol level, there is no such thing as "balance of an address". There are individual unspent outputs (like coins in a wallet), which must be individually spent. You can't partially spend an output, but you can split/combine it.
So for example, you have a 70 BTC output assigned to an address, and a 80 BTC output assigned to the same address. Some software will show this as 150 BTC balance of that address, but you still need to know the individual outputs to spend them. If you want to send 100 BTC to someone, you would consume those two outputs in a transaction, and create two new outputs using it, a 100 BTC one (to the recipient) and a 50 BTC one (back to yourself).
Whether you use a new address for that 50 BTC "change" output doesn't matter to the protocol. You can reuse the old one, but will make it obvious to everyone in the world which who was the sender and who was the recipient in the transaction. Using a fresh address improves privacy.
Seen otherwise: reusing the same address may look convenient, as it allows you (and software you use) to more easily distinguish what your balance is, but it does this at the cost of making it obvious to everyone in the world. This hurts Bitcoin's privacy - not just yours, but that of everyone in the system.

Yes it can. See this transaction below.
https://blockchair.com/bitcoin/transaction/b345c51064074f5d6c0e11187326567765eb4fa3236ca1be440ccb5745775238

Yes, and you might want to read up on handling change as that's one good reason to do so.

You can even have a transaction with only 1 input and 1 output, both being the same address

authors: Валентина Дурбало


text:
What are Channel Factories and how do they work?
One of the open research questions for Lightning Network is that it will take a massive amount of on-chain transactions to create enough payment channels for all the Lightning Network users. Lately, I've seen the term "Channel Factories"¹ pop-up in this context.
What are Channel Factories? How do they work? How does that help scale the Lightning Network?

¹ Apparently, the term was introduced by the paper Scalable Funding of Bitcoin Micropayment Channel Networks by C. Burchert, C. Decker and R. Wattenhofer

What are Channel Factories?

In short, Channel Factories are payment channels that can be used to create more payment channels.  That sounds weird, but it's really pretty simple:
In a regular payment channel, you always have a transaction signed by all participating parties that's ready to commit the current channel balances to the block chain.  For example, in a channel between Alice and Bob, this transaction might have two outputs, one paying Alice 0.25 BTC and one paying Bob 0.75 BTC.  If this example transaction were broadcast, it would close the payment channel between Alice and Bob.
However, it's possible to format the ready-to-commit transaction as a transaction that not only closes the existing payment channel but which also opens a new payment channel.  In that case, the same security that allows the initial payment channel to have zero-conf security also extends its security to the second payment channel.
The key feature of a regular payment channel is the ability to securely update the state (balance) of the channel many times without creating extra on-chain transactions, so the key feature of a Channel Factory is the ability to securely create and destroy new payment channels without creating extra on-chain transactions.

How do they work?

At least two people and preferably ten or more get together to create a payment channel (channel factory) deposit transaction.  This has the regular payment channel logic that allows all of the participants to spend the money if they all agree, or for a dissatisfied participant to individually withdraw his funds if the other participants become uncooperative.
When the deposit transaction has enough confirmations to satisfy all the participants, they update the state of the initial payment channel (channel factory) to create a bunch of non-broadcast payment channel opens between themselves.  (The channels need to be between themselves because they each need to ensure none of the bitcoins used to open the channel are spent twice, i.e. double spent.)
Since the initial payment channel (channel factory) already has sufficient confirmations, opening the secondary payment channels is instant.  The second payment channels can then be used like normal payment channels (e.g. for routable payments Lightning Network) except that when it comes time to close them, the participants have the option of either committing the final state to the block chain or simply updating their balances in the channel factory in order to start a new channel.

How does that help scale the Lightning Network?

Let's assume we have a bunch of users who all want to open payment channels to each other.  For n users, they need to open m channels where m = n(n-1)/2.  For current-generation Lightning Network channel open, they'll probably spend at least two inputs and generate at least three outputs (about 240 vbytes times m channels).  For a channel factory, they'll have about n inputs (at 70 vbytes) and n + 1 outputs (at about 25 vbytes) plus 10 vbytes overhead.  Here's the savings accounting:

This doesn't count channel closing costs, which are harder to calculate since channels may remain open for variable lengths of time.  Also not included is the additional savings available from Schnorr signature aggregation---if that should be activated on Bitcoin, it will increase Channel Factory efficiency moderately by decreasing the amount of space used by the inputs.  Please note, numbers used here are a rough approximation.
Note that although channel factories provide significantly lower costs even for small numbers of participants, where they really excel is at making it cheap to build a dense web of payment channels between users.  This will likely significantly improve the quality of service of a widely-distributed Lightning Network by ensuring most paths from spender to recipient stay short, which helps the widely-distributed network further effectively compete with a more centralized network that has short paths between large hub-like entities.

Thanks for the explanation. The paper also says: "The new layer addresses the scalability problem by enabling trust-less off-blockchain channel funding.". What do they mean by "off-blockchain channel funding"? To my understanding, funding a channel can also happen off-blockchain currently: if your channel is exhausted, you can "refund" it by simply getting paid (buying from an exchange on the LN).

@LucaMatteis I believe it means that you can be added to an existing channel factory with no new on-chain transactions required.  For example, imagine Alice, Bob, and Charlie start a channel factory.  Now they can open any payment channel they all agree upon---including opening channels for Dan who was not part of the original set.  This does require allocating to Dan some of the BTC that was used to create the channel factory, but that just means Dan bought the BTC from (say) Alice.  Once Dan's channel is open, his funds are secured by the ability to commit on-chain if necessary.

So new users would be able to join the network without creating a blockchain transaction? That's interesting. Thanks!

@LucaMatteis Sorry, on reflection, I don't think what I described previously is secure: you need your pubkey to be part of the multisig set used to open the channel factory in order to securely use channels created by it.  I now think the clause you quoted refers simply to the ability to trustlessly create and destroy channels within a single factory's set of users.  E.g. Alice initially opens a 1 BTC channel to Bob and 2 BTC channel to Charlie; later she closes those channels and opens a 1.5 BTC channel to each, all done off-chain.

What are the disadvantages?
Uncooperative users more dangerous?

@DavidA.Harding You say "the same security that allows the initial payment channel to have zero-conf security". What zero-conf security are you referring to? How is it that zero-confirms are secure?

@GiovanniDiStasi I can't think of any new security risks.  An uncooperative participant can prevent new channels from being created by the channel factory at any time, but can't otherwise affect any already-established channels besides his own, so basically the same security as LN.  Participants in a channel factory may gain more information about each others' balances than in pure LN, but there's even less data going to the public block chain, so channel factories seem privacy neutral or slightly privacy improving.

@almel All payment channels I've heard described (Spillman, CLTV, HTLC, Duplex) use some variation on multisig security.  Alice and Bob each deposit 0.5 BTC into a 2-of-2 multisig address that requires both of their signatures to spend.  They wait for this to confirm.  Now Alice can sign a transaction spending from that address giving Bob 0.75 BTC and returning 0.25 BTC to herself.  Bob can securely accept that transaction immediately without seeking confirmation because the transaction also requires his signature to be complete, so there's no way Alice can take back the 0.25 BTC she paid him.

@DavidA.Harding: I think you should clarify that your mention of "zero-conf security" refers to the commitment transactions created by updating the channel, not the initial funding of the transaction.


text:
When did the ASIC mining era begin?
I am trying to figure out when the ASIC mining era began. A Bitcoin magazine article from January 23rd 2013 announces the imminent arrival of the first batch of Avalon miners in early February.
Is there more accurate information: What day did the first ASIC miner become operative?

I'd say you are pretty close with that date. It's fun to go hover over this chart (https://blockchain.info/charts/hash-rate?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=)  and follow the hash rate over time. It jumped back and forth from 10-20,000 from 2011 - 2012. From spring to summer 2013 there was a very large increase from about 30,000 to 300,000.

What about FPGA? They out-performed early ASIC, they were 2012 or earlier.

Jeff Garzik received an Avalon miner on january 30th, 2013 and posted pictures at http://garzikrants.blogspot.com/2013/01/once-upon-time-in-china-package-shipped.html and http://garzikrants.blogspot.com/2013/01/avalon-modular-room-to-expand.html
The next day he posted a review at http://garzikrants.blogspot.com/2013/01/avalon-asic-miner-review.html
For many this was a milestone that you might call the beginning of the ASIC era. Of course the manufacturer had the first bitcoin ASIC chip operative long before this. Also, this did not mean that you could just order an ASIC miner and receive it within a reasonable timeframe. But it did mean that the first bitcoin ASIC machine had shipped. For better or worse, it had begun.


text:
Which receiving address does my block reward go to when mining through bitcoind?
I'm wondering where goes the BTC as my bitcoin server finds a block?
Using bitcoind, I see no setting for a bitcoin address..

I guess it makes a new address for the reward.

Apparently, bitcoind creates a new address for the block reward and puts it directly in your wallet.dat file.
I suppose it is stored in your default wallet, but as a new address.


text:
How can I find my bitcoin wallet?
I had to update the software on my computer and had to delete everything on my computer. I wasn't aware that my Bitcoin wallet was like a physical wallet. I thought I'd be able to download the wallet and enter my address into it and get everything back. I don't know what to do. I'm freaking out and don't know how and if I can get my Bitcoin wallet back. I know the address of my wallet but I don't have any of the files on my computer.

TL;DR if you have lost your wallet.dat, there is nothing you can do. Try with some recovery software, such as PhotoRec.

Unfortunately once you lose your wallet, there is no way of getting it back.
The wallet is so inportant because it contains your private key, this key is used to send money from your wallet to other people. Without it you can't do anything.
Next time consider writing down the private key and keep it locked up, or keep an offline version of your wallet.dat file. however be careful with keeping online versions, since anyone who has your private key can send money anywhere.
Just for clarity, you talk about your 'adress', is this your public or your private key? With other words, did you use it to send money? Or to recieve money?


text:
BitCoins to solve human scientific problems
I just learned about BitCoins' existence last 2 weeks.
At first, I thought BitCoins could be used to process human scientific problems. I know it is not computing any really useful thing right now. I wonder if someone has thought about this? (I mean, in the scientific community and BitCoins community). Maybe integrate Grid computing with BitCoins processing?
Or, due to the nature of the block solving algorithm in Bitcoins, whose purpose is solely to verify length of processing, it cannot solve anything useful. Could someone confirm this?
Thanks!

I'm not sure I understand the question here. I think you are asking if the Bitcoin protocol could have been designed to solve scientific problems as part of the proof of working involving in mining? (i.e. could there be a Bitcoin alternative that has a proof of work related to scientific computing?)

Also, I would avoid the word "useful" as many would argue the mining the blockchain is quite a useful activity in and of itself.

@DavidOgren even more useful Works fine as is.

Yep, agreed. I think that dup that was found is a great answer. I just had a reaction to the original "I know it is not computing anything really useful right now". David Schwartz's answer to the dup was exactly what I wanted to say, but in more detail and better words than I could have managed.

You are right. I put it that way, thinking it would be a waste of resources to do only hashes, but missed the point the hashes help secure the transactions. Thank you for your comments and the dup question.

Bitcoin mining calculation is simply double SHA256 hashing and has no other known application.
The hashing algorithm is highly unlikely ever to change, although there are other digital cryptocurrencies that use another mining algorithm. Litecoin, for example, uses scrypt hashing in place of sha256.


text:
What is the difference in hashing algorithm between bitcoin and litecoin?
I am having trouble finding litecoin mining specifications. I would first of all require something like this:
https://en.bitcoin.it/wiki/Block_hashing_algorithm
Except for litecoins. I need to know how to dissect the getwork data, what kind of operations to do on it (eg. hex to uint32 conversions, byte order shifts, etc.) and what specification of scrypt to use and what are its input, difficulty and expected output.
I would really love to have some input/output data, on which I can write BDD specifications so I can write a miner on top of that.
Anyone know for some good resources I could use?
Thanks
Edit: I would really appreciate some sample input/output, I can figure out the rest myself.

Here you find an example, how to extract the data from getwork and call the scrypt function
http://litecoin.info/Scrypt
Unfortunately it is not clear (to me) what the resulting values of the scrypt should be. First I thought it is the result of the valid block above, but that has a different nounce.
If you find a valid result, please let me know the value.

From the wiki page it looks that you replace the double hash by (using python scrypt package):
scrypt.hash(header_bin, salt=header_bin, N=1024, r=1,p=1)[::-1][-32:].encode("hex")

The algorithm is basically the same, just exchange SHA256 with http://www.tarsnap.com/scrypt.html

The bitcoin hashing is double sha, so sha256(sha256(data)). So I do scrypt just once?