1) Bitcoin is a gossip network in which each (full) participant checks all activity of all other (full) participants. Such systems scale notoriously badly as the cost for each network event scales quadratically. Simple example:

Three participants creating three transactions leads to six transaction relays and verifications.
Six participants creating six transactions leads to thirty transaction relays and verifications.
Twelve participants creating twelve transactions leads to 132 transaction relays and verifications.

As you can see this obviously becomes unsustainable as more people adopt the network. Thus, a limit is needed to keep the workload manageable which is currently expressed in a consensus rule that limits the number of bytes per block to 1,000,000.

2) If we cannot process an unlimited number of transactions, there must be some sort of prioritization for transactions to get selected. At first Bitcoin transactions were confirmed by prioritizing larger and older transaction inputs, ensuring that everybody would get their turn. At some point block space demand was large enough that many blocks filled up and not every transaction would be confirmed within a few blocks. The miners gradually switched to a more efficient mechanism: Instead of prioritizing old inputs, they selected those transactions that maximized their revenue per block. Thus, transactions were sorted by largest fee rate, and an efficient fee market was established.

3) We've now reached the point where fees don't even drop significantly in traditionally low-demand times such as the weekend. Since transactions are selected by the fee rate per data size, transactions that transfer more value can naturally bid a higher fee than transactions of lower economic value. (Note that the amount of value transferred is decoupled from the data size of a transaction.) As transactions transferring thousands of dollars worth of money can easily pay several dollars and remain competitive with other payment services, it's obvious that low-value use-cases will be the first to get pushed out of the blockchain.

4) Strategic thought: The latter will occur inevitably, as even if we could sustain blocks of 1,000GB, only ~3,000 transactions per second would be possible—way too little for all sorts of microtransactions to remain feasible. If we had kicked down the can the road several times already as fee pressures started to peak, we'd eventually be in the situation where we'd have a community and industry accustomed to not having to deal with fee pressures, with wallets not having code to handle fee estimation, services not having logic to deal with unconfirmed transactions, and large business use-cases built around the availability of cheap blockspace—an utterly unsustainable expectation.

5) Personal opinion: It is thus important for the longterm development of the Bitcoin system to keep some fee pressure sustained in order to create the anticipation of the eventual exodus of micropayments as it will in the longterm be impossible for these payments to be on the blockchain. After seeing 530 satoshi/byte last week, we are overshooting at this point, and it's high-time to increase the capacity of the Bitcoin system. As I'm convinced that any hard-fork attempt will lead to two persistent forks of the Bitcoin blockchain, my preferred approach is to activate SegWit which has been tested for more than a year, and is active on multiple altcoin networks. Besides gradually providing more capacity as the network adopts the new segwit transaction format, it has better scalability properties for transaction verification, and provides the foundation for additional capacity and scalability improvements such as Lightning Network, Schnorr signatures, and signature aggregation.


how to validate testnet and mainnet bitcoin address via online api or offline for Android App?

Here are list of references to validate mainnet and testnet Bitcoin addresses:

Offline

IN JAVA

https://rosettacode.org/wiki/Bitcoin/address_validation#Java (mainnet + testnet)

https://github.com/timqi/btc_address_validator/blob/master/BTCAddrValidator.java (mainnet only)

IN GO

https://github.com/niksmac/btc-validate/blob/master/src/btc-validate.go

IN PHP

https://github.com/niksmac/btc-validate/blob/master/src/btc-validate.php

IN RUBY

https://github.com/niksmac/btc-validate/blob/master/src/btc-validate.rb

Online Api

https://blockexplorer.com/api/addr-validate/mjdkX5oxbc9ioTmbnRtc5g4Cojyr5esUuZ (mainnet + testnet)

Note: For around 30 languages we can take benefit of same by following reference:

https://rosettacode.org/wiki/Bitcoin/address_validation


How can I generate preimage for lightning network invoice? Should I?

As a rule of thumb it is probably best to let lnd generate the preimage for you.

If someone can guess your preimage they have the chance of steeling the payment. It is somewhat similar to guessing your Bitcoin private keys but probably not as bad as they can only get the current payment and technically even that might be tricky.

If you want to do it alone you should keep in mind three things :

The preimage should be truly random which for software is always hard to achieve
It should have a large enough size. Flipping a coin might be truely random but as there are only two possible outcomes one could guess / brute force those
It should be unique and never reused.

The third point is achieved in precise by following the first two points.

Also looking at BOLT 02 https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#removing-an-htlc-update_fulfill_htlc-update_fail_htlc-and-update_fail_malformed_htlc you will see  that the preimage is 32 bytes of data which gives you even less flexibility than my second point suggested.


Electrum wallet not restoring with the right address?

I wrote an FAQ about this here. It contains various things you can try.

Another possibility is that the address corresponds to an imported private key. In the past electrum used to allowed you to import private keys into HD wallets. These imported private keys are not restored when you restore from seed. So is this an address of an imported private key?


What is my incentive for sending old blocks?

Miners have spent money on mining hardware. The value they are able to get out of that mining hardware is tied directly to the price of Bitcoins and the mining difficulty.

If the price goes up, that will incentivize some additional miners and if the price goes down, more people will mine. But this doesn't happen immediately nor does it cancel out perfectly. Miners benefit from an increase in the price of Bitcoins and are harmed by a drop in the price of Bitcoins.

Your incentive for sending old blocks is that the utility of bitcoins drops if it's more difficult for new nodes to join the network. While this effect on the price of bitcoins is slight, the amount of old blocks you need to send is also slight.


how do nodes verify that a block has been solved and can be added to the blockchain

StephenM wrote a good answer to that:

  The difficulty (or nBits as it is called in the code) is shorthand for how difficult it is to solve the block. Essentially, it encodes a target value, and the hash of the block (when treated as a 256 bit integer) must be below that target value to be considered solved.


Why was the BIP33 ("Stratized Nodes") never implemented?

It seems to have expired
See BIP-0002

BIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph.

To see the exact details of the discussion of this proposal I believe you need to become a member of the bitcoin developers mailing list and bitcoin developers forum.
If you look at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-May/subject.html it seems this BIP was maybe superseded by some work on Bloom filters?
To get a complete picture, I think you'd have to dig around a lot more.


Validate Bitcoin address using Javascript

Use bitcoinJS's https://github.com/bitcoinjs/bitcoinjs-lib/blob/27a840aac4a12338f1e40c54f3759bbd7a559944/src/address.js#L101 toOutputScript function in a try-catch block


The transaction, like the block, is in a serialized format. A description of the format is available on bitcoin.org


To what degree can Bitcoins on a hard disk be protected against hacking?

You should completely forget about the notion of a Bitcoin being "located" online or on a particular computer.  It isn't a good metaphor for the way the currency actually works.

There are addresses, each one with an associated private key.  Each address has an associated balance; if the balance is greater than 0, then some bitcoins "belong" to that address.  The blockchain or transaction register, which contains information about the balances of all addresses, is stored "online" by all nodes on the Bitcoin network.  This is maybe what you are thinking of when you say "Bitcoin is somewhere online".

However, to actually spend coins, you have to have the private key, with which you can create a transaction sending some coins from the address to some other address.  The private key is an actual piece of data that can be stored on a particular computer (or a phone, or a piece of paper, etc).  It is normally held only by the owner of the coins, and not by anyone else.

When a customer buys coins on an exchange, initially the coins are held by the exchange itself, which means that they belong to an address whose private key is held only by the exchange.  They just update their internal books to indicate that this customer is now entitled to withdraw those coins (see below).  The customer doesn't have a copy of that private key.  If the exchange is hacked at this point and its private keys are accessed, the attacker can transfer the coins to his own address.  After that happens, the exchange's private keys become useless and can no longer control what happens to the coins, but the attacker can spend them as he pleases.  The coins have effectively been stolen by the attacker.  Neither the exchange nor the customer can get them back.  The exchange might reimburse the customer, but that is strictly between the exchange and the customer, and the Bitcoin protocol itself cannot force this to happen.

The customer can also withdraw the coins, by instructing the exchange to transfer them to a new address, of which the customer (and only the customer) holds the private key.  After this is done, the customer is the only one who controls those coins; the exchange's private key is now useless.  If the exchange is hacked at this point, nothing happens to those coins.  However, if the customer is hacked (or accidentally erases her private key, etc), then she loses the coins.  The exchange cannot do anything to help recover them, since it never had a copy of the customer's private key.  (In the case of hacking, the private key wouldn't help anyway.)


I want to generate a BIP32 version number for Namecoin and other altcoins

I can not tell you really how you generate them, but to partially answer your question, here is a list of known Bitcoin and Altcoin prefixes, including Litecoin and Darkcoin:

EXT_SECRET_KEY, EXT_PUBLIC_KEY # Network                 : Prefixes
----------------------------------------------------------------------
0x0488ADE4,     0x0488B21E     # BTC  Bitcoin    mainnet : xprv / xpub
0x04358394,     0x043587CF     # BTC  Bitcoin    testnet : tprv / tpub
0x019D9CFE,     0x019DA462     # LTC  Litecoin   mainnet : Ltpv / Ltub
0x0436EF7D,     0x0436F6E1     # LTC  Litecoin   testnet : ttpv / ttub
0x02FE52F8,     0x02FE52CC     # DRK  Darkcoin   mainnet : drkv / drkp
0x3A8061A0,     0x3A805837     # DRK  Darkcoin   testnet : DRKV / DRKP
0x0488ADE4,     0x0488B21E     # VIA  Viacoin    mainnet : xprv / xpub
0x04358394,     0x043587CF     # VIA  Viacoin    testnet : tprv / tpub
0x02FAC398,     0x02FACAFD     # DOGE Dogecoin   mainnet : dgpv / dgub
0x0488ADE4,     0x0488B21E     # VTC  Vertcoin   mainnet : vtcv / vtcp
0x02CFBF60,     0x02CFBEDE     # BC   Blackcoin  mainnet : bcpv / bcpb
0x03A04DB7,     0x03A04D8B     # MEC  Megacoin   mainnet : mecv / mecp
0x0488ADE4,     0x0488B21E     # MYR  Myriadcoin mainnet : myrv / myrp
0x0488ADE4,     0x0488B21E     # UNO  Unobtanium mainnet : unov / unop
0x037A6460,     0x037A689A     # JBS  Jumbucks   mainnet : jprv / jpub
0x0488ADE4,     0x0488B21E     # MZC  Mazacoin   mainnet : xprv / xpub

I've taken them from the pycoin api implementation which supports HD wallets.
https://github.com/richardkiss/pycoin/blob/master/pycoin/networks.py


How can you make sure that there will be routes with large enough balances to handle transactions?

This is not so easy. Infact it seems almost impossible to be done in an elegant way. While the capacity of public channels is known to everyone on the network the balance of each channel is unknown.

As nodes sharing their balance is

a privacy issue,
technically in a peer-to-peer network difficult as the channel state / balance might change several times per second and gossip protocol propagation takes longer and
Hard to proof validity of a published the channel Ballance

We usually don't know the balance.

Thus a Sender could just use try and error which is particularly inefficient in large networks as the number of paths grows quite quickly.

In practice node operators could use "manipulated onions" to probe nodes for a current minimal channel balance. Which obviously is also difficult as the balance might change quickly.

In precise people work on AMP routing which means doing several small payments (maybe even over several paths) instead of a large one or JIT routing which allows nodes along a path to rebalance their channels if they don't have enough balance to forward the onion. (disclaimer I proposed JIT routing and it is not clear yet if it becomes a lightning standard)

On a Side note :maybe you want to add my youtube channel with lightning educating to your mega thread (which in the past helped me a lot! Thanks!)


Are Bitcoin core devs contributing to ISO/TC 307 Blockchain and distributed ledger technologies

Opinion:

Committee efforts which have to aim of standardizing anything to do with the bitcoin protocol should be considered attacks against Bitcoin. Bitcoin was created specifically to eliminate the need for a (trusted/centralized) "committee". The rules of the Bitcoin protocol are decided independently by each user running the software which validates them, of their own volition. Bitcoin Core developers can only provide software to enable users to interact on the network which they choose to interact. They cannot force users to follow any rules.

There is not, and will never be a committee to decide these rules. The market decides which Bitcoin rules will succeed. This will not stop bad actors from trying to control it. You should make the effort to call them out as hostile, because they are hostile, even if they did not intend to be - they just don't yet understand that Bitcoin has made their role as rulemakers obsolete.

There is no harm in attempts to standardize methods and software surrounding Bitcoin (such as POS systems, hardware, wallets, network protocols), but these efforts are already being standardized as part of the BIP and BOLT processes, and by developers finding opportunities in the market, and these move far faster than any ISO committee will ever be able to keep up with.

This committee essentially has nothing to do with bitcoin at all. It is another "blockchain not bitcoin" effort which can only do damage to Bitcoin. It is initiated by people who are unable to accept the concept that nobody is in charge and nobody decides the rules. If they were interested in bitcoin they would be contributing on github and the mailing lists. The fact that they don't and just want to stick an ISO stamp on it is clear where their proirities lie. For them, the world seems chaotic without standards, but for Bitcoin, the chaos is its strength - it means that it is immune to external influence from specific parties and it does not need to conform to any societal norms which currently exist, or may exist in the future. Bitcoin is the free market. There are a lot of people who hate free markets and will make any effort they can to undermine Bitcoin.

I believe the majority of Bitcoin Core developers feel similar, and will ignore any attempts from ISO to influence decision making in the development of Bitcoin Core, as well as other Bitcoin clients.


The Answer is No, you can not do this. Reasons are below.

It seems you may be confused.

The point of a cold wallet it to store the coins offline, adding a watch-only address to a cold wallet does nothing, other then letting you see that address.

(I could add your address as a watch-only and see your balance as well, but that doesn't give me access to your coins)

If the coins are in the cold wallet then you have to send them from there, generally by creating and signing an offline transaction.

If they are in the hot wallet (even if being watched by the cold wallet) they you can send them from the hot wallet.


Why is it important that the hash algorithm is puzzle friendly?

In the most straightforward terms: Given a hash function H, that takes some input X from the user, and produces output Y, a good 'puzzle friendly' algorithm will not show any pre-determinable correlation between input X and output Y. That is to say, you cannot select a certain X, with hopes of returning a certain Y.

In practice, the bitcoin network accepts a block hash that is lower than some value (determined by the current network difficulty). The user should not be able to select inputs based on any sort of expected output value, the entire rang of input values* should have an equal chance of returning the desired output.

Otherwise, the user could discriminate against input values within certain ranges, thus narrowing their search field, and increasing their chance of finding a valid output. This would break the function as it is required for a POW cryptocurrency, by allowing users to make 'educated guesses'. In such a broken system, the more 'educated' a guess is, the higher chance the output will be the desired value. So the more you understand the (broken) algorithm, the less resources you would have to spend in order to compute a valid block hash.

Contrast this to the 'ideal' case where every user guess is equally likely to create a valid output. This is what is desired, and what is being referred to as a 'puzzle friendly' here.

*Note: user input includes more than just the nonce value. All input values that the user can alter would be included, there is no functional difference between changing the nonce, or changing the transaction structure


Installed bitcoin-qt and Tor, allowed firewall, Tor connects, but Bitcoin doesn't

Bitcoin Core works fine with Tor. There is a current setup guide in this question. The only thing that you may need to adjust is if your current Windows setup uses port 9150
(instead of port 9050) for the Tor Socks5 proxy.


How widespread is OP_RETURN forwarding and mining (as of February 2014)?

It will take until bitcoind version 0.9 for wide spread support for relaying OP_RETURN.

Adding fees will not help. Currently, transactions with OP_RETURN are by default not relayed by the main net (last sentence):
https://en.bitcoin.it/wiki/Script#Provably_Unspendable.2FPrunable_Outputs

P2Pool seems to accept them, so that could be a solution for you: submit them to a P2Pool node.


I have noticed the same. I am afraid that we have to live with it since even on bittrex website charts are delayed by 3 minutes approximately. You can see that if you get the 1-minute chart plotted. Market history is on time though. If you need this sort of speed, you could build a script to catch ticks from market history list.


If you rely on bitcoind and JSON-RPC API you could try launching daemon with -walletnotify option.

bitcoind -daemon -waletnotify="process-txn.sh %s"

This will call process-txn.sh with transaction id on the input. Then you can query the daemon for transaction details.


How can I physically give someone bitcoins for easy redeeming?

Most paper wallets include a QR Code (2D barcode) of the address and private key to save you from typing them in by hand.  Some bitcoin wallets allow you to scan a QR code to sweep the funds out of it - I know blockchain.info's online wallter will let you use your webcam to scan a private key.


Understanding signing messages with bitcoinjs-lib

That particular line of code asserts that the private key fits into a 32 byte-sized byte array properly with the necessary zero paddings. As the private key is simply some random Big Integer between 0 ~ 2^(256-1), javascript may encode that integer into different byte array sizes. For example, if the d value was simply 1, then it could easily fit into a 1 byte-sized byte array and you would not have the leading/trailing zeroes required depending on the endianess of your encoding of choice.


When was the last time a block was solo-mined?

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

The payout values have nothing to do with solo mining.


Won't happen because of pure greed, if people start leaving difficulty will drop and then it will become profitable again plus even if the normal person can't mine we will have some big company that will profit from mining and keep the network running. This poses other issues when big company's get involved but that's out of scope for this question.


Historical Prices Immediately Following Bitcoin Halving

First halving happened on 2012-11-28, the price was around $12, after the event the prices started to rally and by April 10th, 2013 it reached over $250, after which it crashed to around $60.

Second halving happened on 2016-07-09, the price was around $575, after the event it fluctuated for a couple of months and then we know what happened next.. $20k top and now it is around $3.5k

The third halving will happen approximately on May 25th 2020
Source and countdown: https://www.bitcoinblockhalf.com/

You can check the dates and see how the price acted on this chart:
https://www.tradingview.com/chart/?symbol=BITSTAMP:BTCUSD


For some reason the isntalled bitcoinjs-lib didn't include the whole payments folder. I pasted it and then I modify index.js to include and now it works.
I don't understand why the installation goes wrong.


How can I split blockchain data over two hard drives?

You can either move a whole folder to you other disk and link it back to your original location with soft links, or move the files and make hard links for all of them.
The windows command for doing this is mklink. It's like creating shortcuts to files in other locations/drives.
I've only tested creating soft links (I moved index folders from HDD to SDD for speed) and I can confirm it works. I think hard links should work as well.
In your case, moving the folders wouldn't solve your issue, since the data would still be on only one drive. So the solution would be to move the large files to your "empty" disk and make hard links for all those files.


Are there any legal implications when using localbitcoins.com?

I'm not a lawyer. In the U.S., the lack of mens rea in your example would not cause you to have violated any laws.  As a person selling your coins, it is not your responsibility to determine your buyer's intentions.

Of course, this is not quite so simple.  Money transmitters have regulations that include AML/KYC (know your customer) requirements which might be a factor here.   FinCEN has asserted that the conversion of bitcoins to and from cash (or other substitutes for value) is transmission of money.  So if you are engaged in trading as a business (i.e., not as an "infrequent" trader) you would likely be expected to be registered as a money service business (MSB), be licensed as a money transmitter and follow the AML/KYC requirements when conducting those trades.   Those requirements would involve gathering identity in certain instances, keeping records (for five years), and reporting suspicious activity.

Now, whether law enforcement will pursue a trader for trading without registering or following AML/KYC is unknown.  There are multiple individual traders whose banks have taken action to shut down service to their customers whose banking activity might be linked to providing Bitcoin exchange services.

So regardless of whether there is legal risk, there are other hurdles when engaging in trading to consider.


Those files are created by Bitcoin Core software. The important one is wallet.dat, do not delete it. You can download and run bitcoin core to open the wallet, but that will probably take a long time to sync. You could open it and dumpwallet, and then check each address on a block explorer or import them into a different wallet like electrum


Where to store coins while I do a factory reset on my computer?

Rutger's response is probably the easiest. Other options would require an understanding of the wallet(s) used. They might have private keys that can be used to allow immediate setup after reinstalling. For example, the Ripple (Rippex) desktop wallet has a secret key that can be used.


HD wallets are coin agnostic. The BIP32 and 49 systems simply dictate how the key derivations from a root key work. Once any particular private key is generated, it functions the same way as a non-HD key.

Thus, you can technically use an HD wallet system for ripple. However, since Ripple addresses require a minimum funding of 20 XRP, which is permanently locked in that address, wallets will usually make you use only 1 address so that you aren't forced to burn 20 XRP each time you make a transaction.


Generate address (for receiving) on GNU/Linux without Bitcoin client?

I recommend simply using vanitygen like this:

vanitygen -1 1

This will generate a small number of addresses that you can use, as well as their private keys.

vanitygen is trivial to install on any POSIX system and is proven to work.

Alternatively, you can try bitcoin-bash-tools. Source that from your .bashrc or simply run it, then you can create a new keypair with newBitcoinKey.


There is only one (Bitcoin) chain, and the Genesis Block is the first block in that chain.

This block was created by Satoshi Nakamoto as the first link in the blockchain. It is hard-coded into the refernce Bitcoin client. To create it, it was "mined" like every other block, except it was at the minimum difficulty level, and contained arbitrary data.

The following quote from The Financial Times is embedded in the block's binary data

  The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

This serves to prove it was generated on or after January 3rd 2009, as well as a political statement regarding the global economy.


Yes, I have built exchanges with PHP and MySQL. I would also recommend Redis for caching.


The current multi-account system is deprecated in Bitcoind (AFAIK Litecoind uses the same one) and has a bug that makes negative balances appear in accounts:

https://github.com/bitcoin/bitcoin/issues/9887


A blockchain is composed of many blocks. The bitcoin blockchain has 660,000+ blocks currently. Bitcoin blocks are limited by the Bitcoin rules to be at most 4KWU (kilo weight units). This is equivalent to 1MB of data per block, however, thanks to the Segwit upgrade, additional information can be stored in each block, making the maximum possible data per block be 4MB. The average block contains ~1.3MB of data.
The blockchain itself keeps growing as more and more blocks are added to it, so yes, storage requirements are rising 1.3MB / 10 minutes. Currently, a computer which stores the entire blockchain (all blocks) plus extra metadata and other indexes, takes up around 330GB - 400 GB.


How to install minergate-cli in centos 6.6

To solve this, it is necessary install the missing dependencies, in my case I have installed the epel repository too:

~$ sudo yum install -y libXrender mtdev libproxy xcb-util-wm xcb-util-image xcb-util-keysyms mesa-libEGL mesa-libGL compat-libxcb

or

~# yum install -y libXrender mtdev libproxy xcb-util-wm xcb-util-image xcb-util-keysyms mesa-libEGL mesa-libGL compat-libxcb


why does Indian Bitcoin exchanges offer huge spreads( Bid and Ask)?

Both Bitstamp and BTC-e are international exchanges that focus on worldwide customers.  Because of that, the market is much larger and more liquid and the spreads are more narrow.  However, none of these exchanges will convert rupee (INR) or provide local deposits and withdrawals.

The local bitcoin exchanges do significantly less volume, so they have to charge a bit more. In addition, they provide services such as bid/ask in INR and integration with local Indian banks.

As more competition comes to the local exchange market, spreads will likely narrow, but still not match a Bitstamp or btc-e.


blockchain.info wallet doesn't show transactions made through api

The problem

When you make requests from the Receive V2 API, we create new addresses for you sequentially, ensuring that you don’t give two users the same address. If you request several addresses on behalf of your users without any of them making a payment, this will leave empty gaps between addresses with funds. This is fine unless this consecutive empty address gap reaches 21 addresses or more.

Most wallet software will only look ahead 20 addresses from the highest index address it can see (due to the BIP 44 standard we are following). Let’s say you get paid to the first address, address 1 — the wallet will look ahead 2-21 addresses to see if there are any additional funds or transaction history in those addresses. If it doesn’t find anything, it will stop looking. So, if you get paid to address 22, the wallet software will not see the funds because it stopped at 21. However, if you get paid to address 2, the wallet software will look ahead addresses 3-22, see the funds that were sent to the address 22, and then look an additional 20 ahead (addresses 23 – 43).

How to know if you’re affected

You can call the checkgap API via the following endpoint:

https://api.blockchain.info/v2/receive/checkgap?xpub={xpub}&key={apikey}

You’ll get a JSON response that looks like:

{ “gap”: 1 }

This gap value represents the difference between the index of the most recent address paid to, and the most recently-requested address. If that value is 20 or greater, funds paid to any further addresses created will be hard to access until earlier addresses receive funds.


BIP deterministic seeds, number of words and compatible wallets

AFAIK, the two most common sets of HD wallet mnemonic seeds used are BIP 39 compliant or Electrum Wallet compliant.  Most of the more secure hardware HD wallet devices support the BIP 39 standard, which appears to be deprecating the older set of Electrum HD seed words. People should not have to do a deep dive into Electrum Python code to find the list of wallet mnemonic seeds. The old Armory paper mnemonics backups are too difficult for non-technologists to utilize, and should be treated as deprecated.

With the BIP 44 standard being defined across a plethora of altcoins, and HD hardware wallet vendors supporting BIP 39, I'm thinking the prevalence or days of using Electrum mnemonic seeds will be numbered.

For whatever reason, Monero cryptocurrency choose to use Electrum seeds, and yet also SLIP 44 registered their altcoin. This confuses wallet developers needing to support Monero while ensuring customer wallet portability across different implementations. End users will demand the simplicity of using one set of mnemonic words to reconstitute their wallets across multiple cryptocurrencies, not two. This means the reference offline JavaScript available at probably needs a redo.


Are there any HD Bitcoin mobile wallets with the mnemonic seed in traditional Chinese?

Here is the bip39 for traditional Chinese word list.

https://github.com/bitcoin/bips/blob/master/bip-0039/chinese_traditional.txt

Also, there are some useful pages that explain how to implement Mnemonic code for generating deterministic keys as following,

https://github.com/bitcoinjs/bip39

https://iancoleman.io/bip39/#chinese_traditional


You can just login to coinbase then go to Accounts section and choose bitcoin and click on the recent transaction (on the top) and then next to a To (the top text) you will see the address you sent the coin to


Bitcoind returning "Invalid JSON-RPC 2.0 response"?

As it turns out, the library I am using does not like JSON responses that contain both the field "error" and "response", even if the "error" field is set to null. I have already notified the creator of the library to possibly fix that issue and I have patched it myself as well:

In the private Map<String,Object> parseJSONObject(final String jsonString) function, one needs to add this at the end:

    Map<String,Object> answer = (Map<String,Object>)json;

    if (answer.containsKey("error")){
        if (answer.get("error")==null){
            answer.remove("error");
        }
    }
    if (answer.containsKey("result")){
        if (answer.get("result")==null){
            answer.remove("result");
        }
    }

    return answer;


Verification of transaction once trasaction is broadcasted

1) Since block is created after constant number of transactions is it the case that, until that number of transactions are accumulated all transactions remains on hold?

Your premise is false. Blocks are not created after a constant number of transactions. They are created whenever someone manages to create one.

  2) Since there is only one coinbase transaction per block does this mean that all the rewards are accumulated in single transaction and then distributed among the winners?

No. Each block has a coinbase transaction that rewards the miner who generated that block.

  3) When transaction is verified what exactly it verifies and how it verifies ? Here major part of my confusion is. As per my understanding it checks each and every transaction from beginning of time by verifying signatures to check whether given transactions are unspent or not which I feel is unpractical.

You don't have to actually do this. You just have to produce the same results as you would if you did this. Since you check each transaction as it occurs, there's an obvious optimization -- there's no need to check transactions you've already checked. That will be every past transaction.

Basically, you check that the transaction is well-formed, properly signed, doesn't spend out more money than it pulls in (unless it's a coinbase transaction), and that all the funds it pulls in come from valid transactions and haven't yet been spent.


blockexplorer.com does show the right balance. However, you are looking up in the Testnet blockchain.

The right request is the following:
http://blockexplorer.com/address/134dV6U7gQ6wCFbfHUz2CMh6Dth72oGpgH

If you open that link, you will see that it shows the right balance.

As you have mentioned, blockexplorer.com is open source, so you probably want to look at the source code to find out how the mechanism you are interested in works.


Can the Bitcoin network be used for cracking?

Short answer: no.

Long answer:

Blocks are exactly 80 bytes long. When have you ever seen an 80 character password?
Blocks start with a bunch of null bytes in the version field. Again, when have you seen that in a password?
Each miner is mining a different block. You don't know the merkle root of what they're mining because that contains a hash of a secret address.
Bitcoin uses SHA256(SHA256(x)) as a hash function, which is not very common in password hashing.
Miners won't publish their results unless they solve a block. They only solve a block if it starts with 12 zeros (at time of writing). The odds of your hash starting with 12 zeros is 0.000000000000003034%.


The purpose of the difficulty is to maintain a 10 minutes average delay between each block and by the way to ensure the Bitcoin emission rate.

The difficulty is adjusted every 2016 Blocks (2 weeks) to compensate the increase or the decrease of the network calculation power.

If the difficulty is so low that the network generates blocks in less than 5 seconds this would be highly unsecure because this would not let time for the blocks to be shared on the network. The result would be a lot of orphan blocks.

Some altcoins were launched with 15 seconds blocks target. Many of them like smallChange failled and doesn't exists anymore.


Electrum has a text-only version, although I found I had to set it up first time using the gui. Here's my write-up on running it on a Raspberry Pi via SSH though, which sounds like it might do what you need:

http://bitcoinlife.wordpress.com/2013/05/29/running-electrum-on-a-raspberry-pi/


Can the Bitcoin client be used without any incoming ports being opened?

Your firewall allows outgoing connections.

Bitcoind creates 8 outgoing connections (by default), over port 8333.


How can I execute a 3-way escrow with 1 unknown party?

Yes, P2SH seems to be the way to go here. If you do a redeem script like:

redeemScript: DUP HASH160 {B's pub key id} EQUALVERIFY CHECKSIGVERIFY 1 {c1 pub key} {c2 pub key} {c3 pub key} {c4 pub key} {c5 pub key} 5 CHECKSIG

Hash it and use the P2SH hash as the address. Then you could spend this output with a scriptSig like:

scriptSig: {any one of c1-c5's signatures of the transaction} {B's signature} {redeemScript}

I'd do some testing with these on a testnet network before doing this for real.


There is currently no real need for an OP_PUSHDATA4, which would allow pushing up to 4GB onto the stack. It was in the original script definition and simply was not disabled when the 520 byte limit was introduced. The only possibility for it to appear in today's scripts is as a non-minimal push and may be caused by a custom client or transaction malleability.


Can the lightning network be subject to DoS attacks due to message flooding?

The protocol is purposefully built in such a way that DoS attacks are mitigated and reduced in impact. Each channel_announcement contains a reference to the funding transaction, and each node verifies that this funding transaction matches the information in the announcement. This makes the creation of a channel_announcement non-free, and binds some resources of a potential attacker, and a channel may only be announced once. channel_updates are only valid if they are preceded by a matching channel_announcement making them also non-free. The same is true for node_announcements which must be preceded by at least one channel_announcement announcing a channel for that node.

While channel_announcements are unique, this is not true for channel_updates and node_announcements, which can update the parameters of a channel/node. To mitigate a potential flood of updates the protocol specifies that a staggered broadcast must be used, which buffers incoming gossip messages and waits 60 seconds for in-memory replacements before forwarding them. This coalesces multiple updates for the same channel or node into a single message then being actually broadcast. So if you attempt to broadcast loads of updates they'll be aggregated at the first hop, and only the latest one will ever be forwarded.

This reduces the number of messages that a node may broadcast to 1 channel_announcement per channel, and 1 node_announcement per node per 60 seconds and 1 channel_update per channel per 60 seconds.

(Disclaimer: I am one of the spec authors and the author of the staggered broadcast proposal)


How do new Cryptocurrencies prevent a 51% attack?

One possible reason to not attack a coin with weaker security is the lost opportunity cost. In order to attack a network, the attacker will need to devote hashing power to the attack.

If they did not stage an attack, they could use that hashing power to mine a profitable coin instead. The benefit of the attack must at least outweigh the lost opportunity cost of engaging in the attack.


Changing something like coin generation has two major risks:

a) You fork the network.  If you make a change and it doesn't have universal support then those supporting the old network will see new blocks as invalid and those supporting the new network will see old blocks as invalid.  To users who don't want to get caught up in a "fork war" the results will be confusing. If user on fork A send coins to user on fork B they will be gone but user B will never get them (unless he modifies his client to fork A).

b) You cause a loss of confidence.  Bitcoin is based on "nothing".  Part of its intrinsic value comes from the fact that nobody can make changes and thus like the "rules" or don't like them you at least know the rules won't change.  Anytime you make a change someone gains and someone loses.  For example if the Federal Reserve lowers interest rates that helps debtors but hurts savers.  Once you start changing the rules Bitcoin becomes open to manipulation with each party pushing for changes that help them.  There is a real risk that will cause a huge loss of confidence.  IF you can gain enough support to change the generation rate you can change just about anything and some people won't like that ambiguous future.

Those risks aside to change the rate of generation you need to
a) decide on a future block in which to change generation
b) reach near unanimous consensus among users (at least among users you can reach)
c) provide updated client which incorporates changes at the preset future block.
d) encourage rapid and widespread adoption of clients with new changes prior to the change block.
e) at the "change block" be prepared for significant issues from users with out of date clients.

There is no way to force this (or any other) change on the Bitcoin community.  Any change require consensus and for something as devisive as generation change that would be difficult.  If it has low support the "inflation fork" will die off.  If it has high support, then even those who dislike it will eventually adopt it and the original fork will die off.  A worst case scenario would be a "fork war" where both versions have roughly equal support and neither one gains an upper hand.  That likely could crippple Bitcoin or at least push it back significantly.


Does using Ripple to accept Bitcoin reduce risk of Bitcoin fraud?

With Bitcoin there are various ways to mitigate the risks and issues you mention to allow some use of payments with zero confirmations instead of waiting for sufficient confirmations to be sure the payment is irreversible.

With Ripple, once a transaction is validated it is irreversible. Ripple transactions usually validate within seconds (5-20 seconds depending on various things). So no such mitigation is required and double spends and related issues are not a problem.

However, within Ripple for any currency other than native XRP, the balance/asset that is irreversibly transferred is a balance with another party. Until you redeem that balance (or spend/trade it within Ripple) you have counter-party risks that bitcoin doesn't have (at least bitcoin in wallet/address you directly control). Although the risks are explicitly limited by "trust lines" you've setup in Ripple (e.g. you may trust Bitstamp for 10 BTC and DividendRippler for 2 BTC) and require no trust in the payment sender.

This risk is analogous to receiving PayPal or BitPay payments. Until they transfer your funds to your bank (and possibly even after that depending on your bank) you're relying on them to make good on their balance to you. Also analogous to using a hosted Bitcoin wallet or other intermediary service where you rely on that party to hold your funds temporarily.


How does a mix between Proof of Work/Stake work? (Peercoin)

I am not an expert on Peercoin, but a hybrid consensus model of Proof-of-work (PoW) and Proof-of-Stake (PoS) already exists with Decred (DCR), and I know a couple of things about it.

Differences between PoW & PoS:

PoW needs miners who use mining hardware to find blocks and verify new  transactions sent to the network.
PoS needs stakeholders who stake/lock up coins to validate blocks already mined by the miners. The stakers can vote to invalidate blocks created unfavourable PoW-mining behaviour, like mining empty blocks.

Similarities between PoW & Pos:

Both PoW- and PoS-miners have voting power to create consensus of code changes on the blockchain.
Both PoW- and PoS-miners gain block rewards or a percentage of the reward.
Both PoW- and PoS-miners can use mining pools for a more consistent and stable flow of funds.
Both PoW- and PoS-mining are methods of making the network more secure against attacks.

Decred PoS ticket system (simplified):

Tickets have a price. e.g: 100 DCR. (see https://dcrstats.com for current ticket price.) This amount varies depending on how many tickets are are bought in total on the network. When you buy a ticket, the amount is staked/locked up and is still in your ownership.
After a period of time (from 28 days to 142 days), if the ticket has successfully vote, then the DCR are sent back to your wallet + a portion of the block reward. This reward amount varies depends on many factors, and can be everything from 10-30% reward per year.
Decred is developing ticket-splitting pools so stakers wouldn't need the whole ticket price to begin staking.

I looked up PeerCoin (PPC) Staking/Minting

Staking PeerCoin is done by having the coins stay in your synced wallet. This means you are running a PeerCoin node, and this will reward you ~1% per year. This is called 'Minting'. (Read https://peercoin.net/minting for more info.) I didn't find many technical details in the Whitepaper of PPC.

I hope this clarifies some things about PoW/PoS Hybrid Consensus System, and I'm sorry I can't provide more specific info about PeerCoin.


What is the DAO, and what is its connection with Ethereum

So what is the DAO's connection with Ethereum, and what is its purpose?

The DAO was a decentralized autonomous organization designed to invest in DAPPs built on Ethereum

Why is the operation of the DAO so crucical to warrant a fork?

Whether a hard fork is warranted is being hotly debated. Ultimately miners will have to make that decision. "Too big to fail" and the sheer amount of money invested in the DAO are some of the most cited reasons by those trying to justify a fork

pro fork:

https://blog.colony.io/an-ethereum-hard-fork-is-not-a-bailout-its-foiling-a-bank-robbery-db2a472fe9e1#.x7rn8026i

anti fork:

https://www.reddit.com/r/ethereum/comments/4oithy/a_too_big_to_fail_political_hard_fork_is_very/

I also see mentions of a company called Slock.it being involved somehow, what was their role in this ordeal?

Slock.it designed the code theDAO is built on and was likely to be one the largest recipients of theDAO investment


Using only Javascript and JS related Bitcoin Libraries. How do you extract the Bitcoin Address from a private key?

Try bitcoinjs-lib

The following will generate a P2SH(P2WPKH) address

const bitcoin = require('bitcoinjs-lib')

let ecpair = bitcoin.ECPair.fromWIF('L34XqVbrw1VSHsiavdpm4QGTRrFyH7RKAp7SFYf36gYcyLX2ieWi')
let address = bitcoin.payments.p2sh({redeem: bitcoin.payments.p2wpkh({ pubkey: ecpair.publicKey })}).address

> '3F1JMjuxgNFuK4kBxv4JXMEdQ2yvjuz939'


Why is my transaction not getting confirmed and what can I do about it?

How Bitcoin Mining Works

Bitcoin transactions are mined (processed) by Miners, and Miners want to benefit from their work. By mining transactions with higher fees, they make more money. Some miners can decide to mine all transactions no matter the fee but they still must compete with every other financially motivated miner.

Why is it taking so long for my transaction to confirm?

If you have sent a transaction

  without (or with an exceptionally small) transaction fee

expect it to be ignored for an unknown amount of time until a miner decides to process it and solves the block; this could be several days to several weeks, possibly never. Your wallet and any Bitcoin node will show it as unconfirmed, your transaction is stuck in limbo.

Block sizes are limited, which means that only a limited number of transactions can be processed in a certain timeframe. In the beginning of bitcoin, there was lots of free space in each block because there were not many transactions. However, now that Bitcoin is quite popular there are more transactions than can be processed into the current block. This is why transaction fees have increased, and as long as someone is still willing to pay more they will keep increasing.

What can I do to speed-up the transaction’s confirmation?

Nothing. The next best thing is to cancel and resend the transaction.

Make a note of the individual bitcoin address(es) that the unconfirmed transaction was sent from.
Run Bitcoin Core with the -zapwallettxes option (or wait a few days until your wallet stops broadcasting the transaction and it falls out of the global transaction mempool). (Issue with mempool.dat resolved by #10330 in 0.15.0).
Send all your bitcoins from the addresses recorded in step 1 to a new address with the recommended or higher than recommended fee.
Make original transaction again using the recommended fee.

What to watch out for

Sites that claim to "speed up your unconfirmed bitcoin transaction". From personal experience, these sites are either scams or just don't work.
DOUBLE PAYMENTS. If the addresses used in the original transaction have sufficient bitcoin in them to cover the transaction, it can always be completed at a later date. To avoid this, follow step 3 to empty the associated addresses and do not reuse them.

What is the recommended fee?

Transaction fees vary by the size of your transaction, and not all transactions are the same size. The fee for same sized transactions also depends on how busy the bitcoin network is at the moment.
An estimate (at the time of original post) was between 11-20 satoshi/byte (0.00011-0.00020BTC/kB) but now can be much higher.
Most wallets have a feature which dynamically calculates the rate based on network congestion.

See https://bitcoinfees.earn.com/ for a live chart of suggested transaction fees


How to update my RaspNode? no GUI only CLI

You should uninstall the installed version first completely with sudo apt-get remove bitcoind before manually building the binaries from source. Make sure that you backup your wallet (and eventually Blockchain) first (so Keep your data-directory).

Don't run the build in teh bin folder! The sudo make install command will install more than just the binary on your machine! Use e.g. /home/git/bitcoin/ to clone the repository and run your configure and make commands there.

Then instlall bitcoin like described on github. after your make -j2 command you should run sudo make install to install bitcoind on your computer. (Binaries are intalled under /usr/local/bin/).

I have installed it on my raspberry Pi a week ago. Works fine :-)

Blockchain-sync lasts almost forever ....

If didn't use the --disable-wallet flag. You could use the wallet with bitcoin-cli


Why don't nodes resume all existing outbound connections at restart?

First, let me clarify that the Erebus attack does not require rebooting the victim. It is only for speeding up the attack process. The attacker can patiently wait for the existing legitimate connections to expire and occupy them.

Coming back to your question, I guess you suggested to prioritize reconnecting the current outbound peers among all tried IPs.
It actually doesn't help much because: 1) the victim may reconnect to shadow IPs controlled by the attacker and 2) again, the attacker can wait for legitimate connections to expire.

The bottom line here is that, because Bitcoin is permissionless, you may not be able to know which are good peers and bad peers to reconnect to. If a node strongly trusts some peers, it can simply whitelist them. But overall whitelisting is bad for decentralization.


Why the system does not try to optimize and put maximum number of transactions in blocks?

There is no single 'system' that can be optimized, there are hundreds of miners running different software to mine. The bitcoin protocol have incentives in place to maximize the number of transactions per block, like the fees charged by each transaction. But they are not mandatory.

Only the miners could answer for what they did what they did. But possible reasons are:

An internet connection outage that prevent them to receive new transactions to be mined.
A bug in the mining software.
Disregard for the low value of the fees present in transactions at that moment
Use of ASIC-boost or some other optimization that favors small blocks.


Transfer bitcoins from Coinbase account to an offline Script/Paper

Ok. You've asked multiple questions, so I'll split my answer up.

How to transfer from Coinbase to Paper Wallet

If your paper wallet is made by a good quality generator, it should have a private key, a public address and a qr code printed on it. You can scan the QR code with coinbase's send function, or if you don't have a camera, you can type the public address in by hand.

Is there a max/minimum amount I can send to a Paper Wallet?

Nope. Think of your paper wallet simply as an access key. To actually use it, you need a wallet client to use the private key. It's the same as any other wallet.

Pre-made paper wallets that come with something covering the public key?

There are some specially made ones that you can buy with tamper-proof stickers, however these are made more for a visual appeal than actual use and you really don't need them. Fold your private key unwards, so that the private key can't simply be glanced at. Then put it somewhere safe where only you know it's whereabouts.


How to watch lots of wallet addresses for new bitcoin transactions?

Here are a couple strategies I've used:

Run a bitcoin node: bitcoind has a -blocknotify flag you can run that will allow you to execute a command with each new block. You can then use JSON-RPC to query your node for all transactions/addresses in the block. It will take a bit of work to set this up, but it will work

Use a service: I've used https://www.blockcypher.com/ which works well, but it can be pricey. https://blockchainwebhooks.com is much more affordable, but not as many features.

Hope this helps! Let me know if you have any questions


converting RUBY script into PYTHON ( Recovering private key when someone uses the same k twice )

Here's what I've been doing recently in Python. This isn't a very complete solution (it doesn't validate its input, it requires that you've already decoded the signature into r & s, it doesn't derive a public key or address from the private key, it doesn't deal with signature malleability issues, it only works with certain types of curves such as Bitcoin's secp256k1), but it should be adequate in most cases.

n  = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141  # order of base point G
r  = 0xd47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad1
s1 = 0x78c9d47ef31caf0102f9ae2489d7c78ab51692ddd898b6eb20b16a0d25b01c78
z1 = 0x4435b0704795962ac9efe71b841a5366434f552d8b5beca04a48426c15fd9ad7
s2 = 0x240bcda3967d66c71c92ffc4c4486d99968183f198c5fe1612a5cc99a05ba99a
z2 = 0x6b8bb3201a7ce4c7ed72eddc46d9b6d7350bc2eb8c28df9763518de8d66b0b52

def modinv(x, n=n): return pow(x, n-2, n)  # modular multiplicative inverse (requires that n is prime)

k = (z1 - z2) * modinv(s1 - s2) % n ; print('k = {:x}'.format(k))
print('privkey = {:x}'.format( (s1 * k - z1) * modinv(r) % n ))  # these two should
print('privkey = {:x}'.format( (s2 * k - z2) * modinv(r) % n ))  # be the same

Updated code

Here's a more complete (but also more difficult to read) version which which (a) displays different possibilities to compensate for negated s values (as noted by David Grayson in this answer), and (b) verifies the private key against the signature-derived public keys if you have pycoin installed.

# order of base point G of secp256k1
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141

# modular multiplicative inverse (requires that n is prime)
def modinv(x, n=n):
    return pow(x, n-2, n)

# the two k candidates which aren't just negations of themselves
def k_candidates(s1, z1, s2, z2, n=n):
    z1_z2 = z1 - z2
    yield z1_z2 * modinv(s1 - s2, n) % n
    yield z1_z2 * modinv(s1 + s2, n) % n

# generates two tuples, each with (privkey, k_possibility_1, k_possibility_2)
def privkey_k_candidates(r, s1, z1, s2, z2, n=n):
    modinv_r = modinv(r, n)
    for k in k_candidates(s1, z1, s2, z2, n):
        yield (s1 * k - z1) * modinv_r % n,  k,  -k % n

r  = 0xd47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad1
s1 = 0x78c9d47ef31caf0102f9ae2489d7c78ab51692ddd898b6eb20b16a0d25b01c78
z1 = 0x4435b0704795962ac9efe71b841a5366434f552d8b5beca04a48426c15fd9ad7
s2 = 0x240bcda3967d66c71c92ffc4c4486d99968183f198c5fe1612a5cc99a05ba99a
z2 = 0x6b8bb3201a7ce4c7ed72eddc46d9b6d7350bc2eb8c28df9763518de8d66b0b52

try:
    from pycoin.ecdsa import *
    pubkeys = possible_public_pairs_for_signature(generator_secp256k1, z1, (r, s1))
    for privkey, k1, k2 in privkey_k_candidates(r, s1, z1, s2, z2):
        if public_pair_for_secret_exponent(generator_secp256k1, privkey) in pubkeys:
            print('k       = {:x}'.format(k1))
            print('or k    = {:x}'.format(k2))
            print('privkey = {:x}'.format(privkey))
            break
    else:
        print('privkey not found')

except ImportError:
    for privkey, k1, k2 in privkey_k_candidates(r, s1, z1, s2, z2):
        print('possible k       = {:x}'  .format(k1))
        print('possible k       = {:x}'  .format(k2))
        print('possible privkey = {:x}\n'.format(privkey))


XPub to YPub Converter (python) - Last digits wrong

The base58.b58decode and base58.b58encode functions only do the Base 58 decode/encode. However xpubs are encoded with Base 58 Check encoding. The difference is that Base 58 Check encoding computes a checksum of the payload and appends the first 4 bytes of that to the payload before the base 58 encoding.
You need to be using base58.b58decode_check and base58.b58encode_check which will drop the checksum for the decode, and add the checksum for the encode.


Without knowing what country you are in it's hard to answer fully.

But, as Nick said, you can use Circle to purchase Bitcoins for USD using a credit card.

To further elaborate, Bitcoins are a currency, so the only real way to get them is either Mining, Faucets, or by converting your government currency into Bitcoin using an Exchange.


Don't we actually mean stale blocks when talking in context of selfish mining?

You always mean stale blocks, never orphan ones.

An orphan block is one that you can not connect to your local chain because you are missing a parent, in the current version of the software you can never get into the situation where this happens. When most people are talking about an "orphan block" they mean "stale block", the syncing behavior is not something users ever come into contact with.

This misnomer comes from when users mined with bitcoin-qt, when a block became stale the transaction paying the coinbase output into their wallet would gain the tag "orphaned". People associated the term "orphan transaction" with "orphan block" incorrectly, not helped by the fact that many popular websites also use this term to describe stale blocks as well.

  Furthermore I'd love to know if and which of stale or orphaned blocks are pruned from history?

They are retained on disk in case they are used again in the future. There is no process for removing stale blocks from disk specifically.


QuantumQrack: the answer is no, it's supporting the "payment protocol", which is a way of attaching some extra data to a transaction, such as a refund address. however, the refund is still up to the merchant to agree to give you; once you've given money to the merchant, you can't take it back without them giving it back to you.

Asked in #bitcoin on freenode.  This is the reply.


What is the average size of a bitcoin transaction?

Just to give a few exact numbers, the current average transaction size (of all existing transactions until block height 498920) is 522.45 bytes.

If we take into account just the first 100000 blocks, then the average transaction size was indeed 238.51 bytes.

This is a plot of the average transaction size (aggregated monthly):

The peak on mid 2015 is produced by this 999657-bytes transaction.

These values can be computed using BlockSci.


It's possible to spend a BTC without fee to forge a payment?

The simplest protection is to not consider a payment to have been made to you until it receives some number of confirmations. The number can depend on the value of the payment. For small payments, one is probably sufficient. For large payments, some have decided to wait for as many as six confirmations.


The transaction fee is based on the size of the transaction (in bytes), among other factors. Each output adds some length to the transaction, so more destinations will mean a higher fee. With the current transaction fee schedule, roughly every five destinations adds an additional .0005 BTC to the standard fee.


Which release fixed CVE-2010-5141 (attacker can spend any coin)

The 0.3.7 update does indeed fix the script execution bug that is being described, the vulnerable code below is removed and replaced with functions that execute the scriptSig and then the scriptPubKey on the same stack.

if (!EvalScript(txin.scriptSig + CScript(OP_CODESEPARATOR) + txout.scriptPubKey, txTo, nIn))

Previously what would happen is that the two script tapes were literally concatenated, then executed as one. The problem here is simply that we can use a trailing OP_PUSHDATA in the scriptSig push the entire scriptPubKey to the stack as a single data element rather than discrete opcodes. Our scriptSig would simply be a push opcode for the length of the scriptPubKey plus an OP_CODESEPERATOR. At the end of execution the only element remaining on the stack is not zero, so the evaluation returns true and we can spend any coins we like.


Is scaling Bitcoin heading it to a dead end?

You're confusing different things here.

Parties incentivized to verify transactions are those that receive payments. Miners are only incentivized to do Proof of Work. (Although they have to be careful to not include invalid transactions while doing so.)

Mining is actually very profitable now. You can tell by looking at how fast the hashrate keeps growing. In the long term though, profitability is supposed to be near 0 because of competition: if there's free money to be collected, it would be weird if nobody came around to take it. Those who have cheap electricity inherently have an advantage.

Scaling solutions don't have much to do with any of this, other than possibly hurting the entire system by having blocks become too big. Scaling implies more transactions per block so which means, all things equal, more total fees for miners. Of course not all things are equal in practice, but assuming enough demand to fill blocks, a new equilibrium will be achieved.


Can Ripple facilitate business-to-business barter transactions?

Currently currencies are limited to three-character codenames, so although this can be done and will work it will probably be useful to establish some convention(s) that will help people to not get too confused.

For example your examples seem to amount, in general, to "store credits", like airmiles or giftcards in a way. Thus it might be better to use a code for them that is different from the national cash they might happen to be useable on par with "at the store". So maybe instead of having lots of "different" IOUs labelled as USD most of which are not really someone owing an actual USD but, rather, someone owing in store credit, in other words goods or services, whose retail price happens to be in USD, it might be good to use USC or USX or whatever, the three letter code conventions only use two for the nation, deliberately leaving one for distinguishing between variants (such as day old dollars or tomorrow dollars or some such strangeness I think).

In general though, ripple docs already say that it is okay for a gateway to refuse to cash out people who are not actual members of that gateway, so that gateways can insist on knowing the customer and having anti money laundering data about that customer and so on. So we are told up front already that gateways are not under any obligation to actually make good on their IOUs to just any Tom Dick and Harry. Since that is already said, why not take it a step farther and say "oh yes I am a gateway, but only to people who buy my merchandise, and only up to the actual amount, per such person, that person spends at that moment on my merchandise".

I just think that would be a heading toward being kind of sleazy as compared to right up front setting your IOUs as not being USD but store credits, so people don't end up confusing them with actual fiat debt.

-MarkM-


Cannot broadcast bitcoin testnet transaction

Can you let us know, which tool or software you used to generate this output? I have one observation:

    47: OP_DATA_0x47:        push hex 47 (decimal 71) bytes on stack
    30: OP_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
    44: OP_LENGTH_0x44:      length of R + S
    02: OP_INT_0x02:         type tag INTEGER indicating length
    20: OP_LENGTH_0x20:      this is SIG R (32 Bytes)
        76731C7063163D36:D0650B7573EC46AF
        795C46F7860940D4:EE8A48F7B1C66C0D
    02: OP_INT_0x02:         type tag INTEGER indicating length
    20: OP_LENGTH_0x20:      this is SIG S (32 Bytes)
        CA417E99B3549CE8:0ED1DB7964DB3597
        CABF709CC614A22F:1FE7B81769775D36
    01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)

The S-Value starts with CA417E99... this value in a signed int is above the allowed value. See Pieter's post at the bottom of this link.
Values higher than one should be preceeded by "00". But before doing so, it should be checked wether it is larger than N/2. Further explanation here.


What exactly are the rev00000.dat files?

Indeed, you can consider transactions to be 'patches' against the set of unspent outputs (the UTXO set): they consume some outputs, and they create some new outputs. Blocks are aggregated patches.

And indeed, to be able to undo the effects of a block on the UTXO set, a record with the reverse patch is written to the rev*.dat files (corresponding to the blocks in the same blk*.dat file).

The format is custom and very compact. For every transaction input (excluding the coinbase's, which does not spend anything) it contains the script and amount of the output being spent and whether it was created by a coinbase. If the output was the last of a particular transaction being spent, the transaction version and height in the chain it was created at are also stored.


How do I tranfer bitcoins from my Zebpay wallet to my blockchain wallet?

Click "Request" tab on blockchain wallet, it will give you a bitcoin address where your bitcoins will be transferred from your zebpay wallet.
Then find "send" or similar button on your zebpay wallet and copy&paste the bitcoin address you previously acquired from blockchain wallet to here.

Zebpay probably cut a commission fee for this transaction. You can find info on their website how much they will charge for the transaction.


What percentage of altcoins are based on Bitcoin?

Map of Coins is a great resource for this.

As of May 2016 they are tracking a total of 710 cryptocurrencies. Of those, 667 are based on Bitcoin's code, which is 94%!


No. Monero's ring signatures draw on Monero's complete TXO set to create a larger anonymity set.

Monero's method has the disadvantage that since it is unclear which TXO were actually spent, they can never be marked as spent and therefore spent TXO  hardly ever leave the TXO set.

In Bitcoin mixers, you're actually dependent on other users also using the same mixer.


Does any open source software exist for an e-wallet service?

It seems like the project was abandoned, but you might be able to recycle the code.

  During the last days I started hacking together a little online-wallet
  and thought some of you might be interested.

  It is based on the bitcoind RPC API for handling accounts and adds
  custom labels stored in database.

  If you want to send coins to a labeled address, just start typing the
  label and it will autocomplete.

  It is a Ruby/Rails application released under the MIT license, so you
  can setup your own online wallet or even run it locally and use it
  instead of the default client UI.

  Note that this is just a very early development version which still
  needs a lot of work.

  Project/Source: http://open.sourceagency.org/projects/webtc Demo
  (testnet): http://webtc.interesthings.de (There is a demo Account:
  foo@bar.baz / password, but feel free to create new accounts, the
  email doesn't have to exist)

  Feedback, bug reports, patches and donations welcome

bitcointalk.org


Bitcoin Core Wallet doesn't accept my passphrase

Are there any circumstances under which the wallet would behave like this?

If your passphrase contains non-ASCII characters, then you could have an encoding issue. I would try typing in the pass-phrase rather than cutting it out of Notepad and pasting it.
Unicode has multiple normalisation forms and this is another thing that could theoretically trip up software.

Could my wallet be corrupt ...

Yes, but your backups show the same result. If you successfully used the passphrase anytime after making a backup it is very unlikely that wallet corruption is the cause.

... and if so can it be repaired anyway?

No-one can tell you that. Repairing an encrypted file is improbable.


It's considered a source code fork, or an altcoin, neither a hard fork nor soft fork of bitcoin. To be classified as a soft/hard fork, it should share some of the same chain from the genesis block. LN has a completely different chain right from the start so it's not a fork of the bitcoin chain.

Note that even coins sharing the same chain as bitcoin from the genesis block, e.g. BCH, are not considered hard forks by most people because they are not "bitcoin". They are generally termed "forkcoins"


Can we construct a UTXO which is spendable only via proof of work?

The answer depends on what you are trying to accomplish with this construction. I have three guesses in this regard:

a set of determined recipients can spend if they perform the PoW: you can have a transaction that can be spent if someone provides: a value whose hash is less than a specified amount (that determines difficulty) AND a signature that describes the set of allowed entities (potentially any multisig).
anybody that performs the proof of work can spend (AND you can spend without PoW): this is trickier since a simple hash based PoW would not work, a miner can just change the destination address of the spending transaction to one under his control. You need to prove that you know a secret (the result of the PoW) without actually including it in the tx so that miners are not able to take the money without repeating the PoW: this is what digital signatures accomplish. As suggested in the comments you can contsruct a utxo that can be spent by signing with a certain private key known by you alone and that contains part of it under an op_return. So one has to try any private key in the set of the allowed ones until he can produce a valid signature. This does not leak the private key itself so the miner cannot sign the same tx with a different destination address.
anybody that performs the proof of work can spend (AND you can NOT spend without PoW): I thought about this a while and I can't find an easy construction for this, it might be hard even with stronger scripting capabilities than bitcoin's. My best guess is that you have a provably random public key (for instance using a VDF on the nonce of the last block) and everybody has to brute-force the private key to spend. I see two major issues: miners can have some advantage in selecting nonces to influence the randomness of the PK and it's hard to tune the difficulty, you need a custom signature scheme that has the security level you want and that's not trivial with bitcoin script.

This is NOT a complete list, it's just the first ideas that came to my mind. Especially the second case, which looks the most likely to me, can be constructed in several different ways: for instance you could also publish the hash of the private key in an op_return (so the private key doesn't have to be included in the transaction) and you would turn it into a hash-based PoW since hashing is a lot faster than signing.


MtGox is an exchange (i.e. a place to sell and buy bitcoins for USD, EUR, GBP, etc.). If you want to get a few coins quickly you can buy them there.

To generate blocks you need to use your computer's processing power (this is called mining). Currently, it is very hard to produce a block by yourself so most people mine in group and split the rewards (pool mining). Check this question for more information:

How can I start mining Bitcoin?


In the Electrum wallet for pc, it is possible to modify a wallet from
  normal password to 2fA (two factor authentication ) without creating a
  new wallet?

No, it is not possible to add two-factor authentication to an existing wallet. these are two different wallet types.

  the fee for the 2fA it's billed only when sending funds from the 2fA
  wallet to outside, and not when we receive, right?

The sender always pays the fee.


The first two commands extract private keys from the electrum wallet. So you can simply pass on your private key (wif) and destination address to electrum sweep.

However, if your private key isn’t listed in electrum wallet, it may not know/hasn’t indexed which utxos this specific key can spend, which is necessary information for sweeping funds controlled by that private key. I am not sure if electrum indexes by all addresses(incl. those spendable by your private key), that will be critical to your ability to sweep.


Walking through a transaction script - blockchain.info

This transaction is a Pay-to-pubkey transaction, so there is no OP_DUP and no OP_HASH160. When validating an input, you first need to find the scriptPubKey of the output that this input spends from. The first input of your transaction spends from the first output of https://blockchain.info/tx/ff3dc8b461305acc5900d31602f2dafebfc406e5b050b14a352294f0965e0bf6. The scriptPubKey of that output is

04c9560dc538db21476083a5c65a34c7cc219960b1e6f27a87571cd91edfd00dac16dca4b4a7c4ab536f85bc263b3035b762c5576dc6772492b8fb54af23abff6d OP_CHECKSIG

To evaluate the input script, we concatenate the input script with the output script, so our final script is

3046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01 04c9560dc538db21476083a5c65a34c7cc219960b1e6f27a87571cd91edfd00dac16dca4b4a7c4ab536f85bc263b3035b762c5576dc6772492b8fb54af23abff6d OP_CHECKSIG

The first array of bytes (3046...5d01) is the signature. That is first pushed to the stack. Then the second array of bytes (04c9...ff6d) is pushed to the stack; that is the public key.

So the stack now looks like

04c9560dc538db21476083a5c65a34c7cc219960b1e6f27a87571cd91edfd00dac16dca4b4a7c4ab536f85bc263b3035b762c5576dc6772492b8fb54af23abff6d
3046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01

Lastly OP_CHECKSIG is performed. It pops the top two items on the stack. The first item popped is treated as the public key (and in this case it is the actual public key) and the second item popped is treated as a signature (and in this case it is the actual signatures). Then the signature is verified, and if it is, OP_TRUE is pushed to the stack.

For a P2PKH transaction, lets use the second input of https://blockchain.info/tx/12e753ef5cc30925a6eee2c457aa7f53022443ca013ea81882a6b59b69e342a6. This points us to the first output of https://blockchain.info/tx/6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516 which is a P2PKH output.

The output script is

OP_DUP OP_HASH160 12ab8dc588ca9d5787dde7eb29569da63c3a238c OP_EQUALVERIFY OP_CHECKSIG

and the input script is

304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601 044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c

Concatenating the two scripts gets us a final script of

304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601 044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c OP_DUP OP_HASH160 12ab8dc588ca9d5787dde7eb29569da63c3a238c OP_EQUALVERIFY OP_CHECKSIG

So following the execution, the first two items (the signature and pubkey) are pushed to the stack, so our stack is

044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601

OP_DUP tells us to duplicate the top item (the pubkey), so our stack is now

044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601

OP_HASH160 pops the top stack item and pushes the RIPEMD160 of the SHA256 of that item, so our stack now looks like

12ab8dc588ca9d5787dde7eb29569da63c3a238c
044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601

The 20 byte hash is not pushed to the stack, so we get

that item, so our stack now looks like

12ab8dc588ca9d5787dde7eb29569da63c3a238c
12ab8dc588ca9d5787dde7eb29569da63c3a238c
044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601

OP_EQUALVERIFY pops the top 2 stack items and checks that they are equal. If they are not equal, the script execution bails out and fails. Otherwise nothing else happens. So now our stack is

044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601

Lastly we do OP_CHECKSIG like we did with the P2PK output. The signature verifies, so we are left with

OP_TRUE

as our stack. And thus the script execution is successful.

Also, it is important to note that script execution is no longer actually concatenating the input and output scripts. Rather the input script is first verified, and then its resulting stack is examined for whether it is valid (i.e. there were no errors validating the input script) then that stack is passed as an initial stack to the output script verifier and the output script is run.


Below is an explanation how forging works at the current moment, in the future this will be slightly changed.

Every block has two fields - BlockSignature and GenerationSignature.

The former is filled by signing the block data with the private key of an account that generated a block and has almost nothing to do with forging process.

The latter is filled by computing SHA256(GenerationSignatureOfPreviousBlock+PublicKeyOfAccount).

The first 8 bytes of the hash give an unsigned 64-bit number in little-endian format, this number is called "hit".

Every account has a so-called EffectiveBalance which is usually (but not always) higher if the account holds more coins. EffectiveBalance is multiplied by some value that is the same for all the accounts - BaseTarget (it's adjusted every block trying to keep block generation rate at 1 minute) - and by number of seconds that have passed since the previous block. The resulting value is called "target".

If "hit" is less than "target" then peers accept a block and attach it to the blockchain.

This is the essential part of forging. I omitted such obvious things as validation of transaction signatures, checks for double-spending, etc.


How can I transfer my bitcoins from my wallet to a market place?

Marketplaces (as well as ATM's for this matter) typically require you to send the bitcoins to an address of theirs. As soon as that transaction confirms, they send you cash via a traditional bank account, paypal etc...

Any trustworthy marketplace will describe that process in detail. Here is some information from btcdirect, for example: https://btcdirect.eu/en-ie/purchase-order


Where can I find the rpc api endpoints for electrum?

Electrum RPC methods a little different from full bitcoin node RPC. You can run help command in order to get all methods. Here is an example:

"addrequest",
"addtransaction",
"broadcast",
"clearrequests",
"commands",
"create",
"createmultisig",
"createnewaddress",
"decrypt",
"deserialize",
"dumpprivkeys",
"encrypt",
"freeze",
"getaddressbalance",
"getaddresshistory",
"getaddressunspent",
"getalias",
"getbalance",
"getconfig",
"getfeerate",
"getmasterprivate",
"getmerkle",
"getmpk",
"getprivatekeys",
"getpubkeys",
"getrequest",
"getseed",
"getservers",
"gettransaction",
"getunusedaddress",
"help",
"history",
"importprivkey",
"is_synchronized",
"ismine",
"listaddresses",
"listcontacts",
"listrequests",
"listunspent",
"make_seed",
"notify",
"password",
"payto",
"paytomany",
"restore",
"rmrequest",
"searchcontacts",
"serialize",
"setconfig",
"setlabel",
"signmessage",
"signrequest",
"signtransaction",
"sweep",
"unfreeze",
"validateaddress",
"verifymessage",
"version"


Reject all other Blocks and allow only my own mined blocks

I suspect that this is an instance of the XY problem, but I'll answer anyway.

If you modify ProcessMessage so that it drops any inbound block messages, that would do it.

Change

    else if (strCommand == NetMsgType::BLOCK && !fImporting && !fReindex) // Ignore blocks received while importing
    {

to

    else if (false) // Ignore all blocks
    {


The short answer is momentum.

Imagine for a second that you are a neutral observer and you see that the price of Bitcoin has been rising over the past few days. Even if you have no reason to think it will continue to rise over the long term, it makes sense for you to buy Bitcoins. After all, it's unlikely that the rise will end just as you buy, and if the price starts to drop, you can always sell. Your buying puts upward pressure on the price, maintaining the momentum.

Now imagine the price is falling. Even if you believe Bitcoins will go up over the long term, it makes sense to sell now. You can always buy your Bitcoins back for less if the price starts to rise. Your selling puts downward pressure on the price, maintaining the momentum.

So, essentially, if the price displays momentum, it's logical to assume it will continue to do so for at least a short period of time, and thus it's logical to perform a transaction that contributes to that momentum.

Negative publicity can start downward momentum. Positive publicity can start upward momentum. Momentum can't really be maintained forever though and when upward momentum stops, everyone fears that downward momentum will begin. They sell to take advantage of the high price and start downward momentum. The same is true when downward momentum ends -- everyone who is bullish over the long term wants to take advantage of the low price. This starts upward momentum.

Just be aware, trading on momentum is essentially a zero-sum game. Everyone's trading profit is someone else's loss. You are probably not "smarter" than everyone else and so are just as likely to be a winner as a loser.

However, the long term upward trend is not a zero-sum game and can mean that there are more winners than losers. Essentially, people who see Bitcoins as an investment are hoping that the Bitcoin system creates real value over the long term.


Relation between bitcoin price and other cryptocurrencies prices

It depends, obviously. Short answer, yes.

Bitcoin used to make up a huge percentage of the value of all Cryptocurrencies, so obviously since Bitcoin was the largest and most used, if it were to crash or change in price drastically, obviously most of, if not all other cryptocurrencies would be affected.

Bitcoin still makes up a large percentage of the Cryptocurrency Market Cap, over 34% on January 25, 2018, followed by Ethereum with 18%.

This is important not to be mistaken though. Perception is what controls the price of Cryptocurrencies.

since bitcoin is the leader of all cryptos, if news were to come out that someone figured out how to exploit it's "proof of work" algorithm, or something giving Bitcoin a negative perception, it would loose value.

Because Bitcoin is so prominent in the crypto world, all other coins would be impacted too, because its literally the "leader".

of course if news comes out that a very small and unknown cryptocurrency would grant you super powers if you owned enough, just that cryptocurrency would go up, not really impacting others because it doesn't have a large market cap.

So in short, the larger market cap, the larger the impact on other currencies


Submitting transaction ID is not a safe way to verify payments. As you know bitcoin transactions are public and anyone can get see all TXIds. Same reason why even the donor bitcoin address is not a good method to verify. Someone else can see that address on blockexplorer and claim himself to be donor.

I can suggest few options:

Ask the donor to sign a message proving ownership of the source address in TX. Most wallet have this functionality
Ask the participant to submit his xpub (extended public key) instead of address. When donor wants to donate, generate a unique address from this xpub for each attempt. This way you are sure, this donor paid to that address


Do all Bitcoin client enforce checkpoints?

The short answer is no, because you can run Bitcoin Core with -nocheckpoints, and different versions may have different checkpoints.

The long answer is that it doesn't matter. If checkpoints ever actually prevent a reorganization of a fully synchronized client, it means that the assumptions on which Bitcoin's security relies (collusion of a majority of hashpower to rewrite the blockchain is too uneconomical to ever be a problem) are fundamentally broken. Checkpoints are not a security feature for this reason, and are often mistaken for one.


I've contacted the Rootstock they provided me the following link https://github.com/RSKsmart/rskj/wiki

which provide a wiki for :

Install RskJ and join the RSK Ginger Testnet

Compile and run a RSK node locally

Getting started with Smart Contracts development

Convert your Testnet Bitcoins to Ginger Smart Bitcoins and viceversa

Besides there is a blog listing all the news : http://media.rsk.co/


Don't confuse the way bitcoin clients talk to each other (peer to peer, speaking the Bitcoin protocol) with the way the bitcoin client talks to RPC clients (server to client, with bitcoind acting as an HTTP server speaking JSON-RPC).

When the bitcoin client speaks RPC, it uses HTTP. Long polling is much more efficient than HTTP without long polling, which is why long polling was created and why it's recommended if you're using RPC.

However, using RPC for miners to talk to the systems that issue them work is rapidly becoming obsolete. Stratum replaces that, and it uses a native method that's more efficient than long polling.


They are identical in functionality, data store, and wallet storage.

You can run one or the other, but not both at one time (this will throw an error if you attempt it).


What's the advantage of using bitcoin to buy coffee?

There are billions of people that don't have access to credit cards and banking facilities that the privileged people take for granted. There are also people that get into financial trouble and lose all credibility in the banking system. Bitcoin provides a way for these people to transact without being part of the banking system. Coffee, however is a very superficial use case. One of the pressing needs is for people to send money back to their families in foreign countries, the current system of international payments makes it extremely expensive and very slow, Bitcoin and the lightning network can really help in cases like these.


Why is difficulty measured in a hash’s leading zeroes?

The "leading zeros" are a simplification. The difficulty is encoded as a target which is essentially a 256 bit number. Since block hashes are produced by SHA-256, they're also a string of 256 bits. If a block candidate's hash interpreted as a number is numerically smaller than the target, the block candidate is a valid block.


What stops a wallet from stealing bitcoins?

What stops malware from being malicious?
Nothing
What can you do to ensure that the wallet you are using is a secure way to access your bitcoin?
Use an open source bitcoin wallet, download from the original source and verify authenticity before use. If you understand code, review and build it yourself.
Obviously, if a person creates a wallet to steal bitcoin from users, they would not share its source code to be reviewed by everyone. Although, even that is possible and I have seen a few altcoin smart contracts that were created to steal user funds. Since not everyone is able to understand code and review it, in that case a few people ended up being victims before word got around.


How to prevent double spending Bitcoins?

When a transaction is created by your node and relayed to full nodes, they will check to ensure that the transaction is valid (no double spending is one condition amongst them). Full node maintains a set of UTXO list in the chainstate folder and is aggressively cached in memory. If a transaction is valid, the full nodes will remove the UTXOs that are consumed in the transaction and add the outputs of that transaction to the UTXO set. Then the node will add that transaction to the mempool and relay the transaction to other full nodes connected to it.

Most full nodes/mining nodes operate on first seen basis. That is if they see another transaction spending the same UTXO as to the first one, they will discard it as invalid and will not relay it further (unless it is RBF). So if you send two transactions consuming the same UTXO then it might be the case that half of the nodes will use a different transaction in the mempool as compared to the other half. This issue will be resolved when a block is mined containing one of the two transactions. The miner will only include first transaction that it has seen in the block it mines. When the full nodes receive the mined block, the ones that had seen the other transaction will roll back the changes to the UTXO set and converge on the transaction mined in the block.

If you want to include the other transaction, you will now have to mine two blocks: one at the height that was just received (by removing the mined transaction and including the other) and another block incrementing that height so that nodes accept that version of the chain (since nodes accept the longest PoW chain). That is the reason PoW is very important in resolving conflicts in a decentralized P2P system that does not have a central authority to dictate which transaction is the valid one.


You lose your money.

To mitigate this encrypt your wallet and do regular backups to several other places. I think wallets will have the backup functionality built-in soon, but it is not here yet.


Does more fees means quicker transaction ?

There is no definitive answer.  Each miner can make their own decision to include either of the two transactions (or neither) in either case.  Whichever miner is lucky enough to find the next winning nonce, their decision determines which transaction is confirmed.  (If that miner chose neither transaction, then the can is kicked down the road.)

In practice, a miner's "decision" depends on the algorithm used by their mining software.  A "greedy" algorithm might choose the higher-fee transaction in all cases; if they get the lower-fee transaction first, they would initially include it in their candidate blocks, but then replace it with the higher-fee one if that one arrives later.

A "naive" algorithm might just choose the first transaction which is seen by the miner, and not replace it by a later transaction, even if the fee is higher.  (Even if they are sent at the same time, the miner has to process one of them first; this might come down to infinitesimal differences in network propagation, and make the choice practically random.)

You could also imagine more perverse algorithms that always choose the lower fee, or the later arrival, or make the choice in some other bizarre way.

There's also the possibility that a miner receives one of the transactions, adds it to their candidate block, but finds a winning nonce for that block before the second transaction arrives.  In that case, they would presumably already have published their winning block, so they can't do anything with the second transaction even if they want to.

I don't know whether there are any statistics as to what fraction of miners use which algorithm.


Can you have a transaction without a change output?

Yes, absolutely you can. I think the article intend "the simplest case" in the real world usage, where is highly unlikely that you have to pay the exact amount of one of your UTXO, if not they are wrong and your example is the simplest transaction you can made.


Will the transaction fee economy in Bitcoin follow the commission model?

Not entirely. In a commission model you generally pay a percentage of what the transaction is, whereas in Bitcoin you just pay for the bytes the transaction requires. The setup is less like a commission model and more like a bank transfer fee model - banks generally don`t charge you for how much you transfer, but for the transfer itself.


who store the private key adresses of these seed phrases,

The private-keys are generated from the seed-phrase by a mathematical function. There is no need to store a list of seed-phrases and corresponding private-keys.

  I suppose it is the wallet software provider

No, you should be the only person to know or store your seed-phrase. Ideally it should not be stored on a computer of any sort. Best practise is probably something like punch it onto metal plates - you can buy letter punch kits to help with this. Ideally you'd provide a few trusted relatives with overlapping subsets so that any two of them working together can retrieve your legacy if an airplane lands on you in five seconds from now.


How does the Bitcoin client make sure transactions were accepted by the network?

The client doesn't ensure peers accept it. If none of your peers relay the transaction, then it will likely never get into a block and will remain unconfirmed forever. Your client will continue to make attempts to relay the transaction periodically, and you may eventually connect to a client that will relay transactions that have no fee or your coins may eventually get old enough that the standard client will relay them with no fee.


Are there any risks of publicizing a Lightning network invoice?

Does it affect -most importantly- the safety of the funds?

It does not. Funds are not affected by publishing a LN invoice.

  Does it negatively affect the privacy or something else?

If a lightning invoice is published, 3rd parties may learn some semi-private information about the payer and payee. First and foremost, they learn the amount that was paid and to which node that amount was paid. Since an invoice can contain a short description, they may also learn what the payment was for by reading the description.

LN invoices also may contain specific routing information, particularly for private nodes. Revealing a LN invoice may also reveal a private node's existence, public key, and a channel id of that node.

  Could the actual payer prove (cryptographically) that they were the one that paid the invoice?

Anyone in the route (including the payer) can prove that they were in the route by revealing the payment preimage. I'm not sure whether the payer can prove that he was the payer, but he can prove that he was involved in the payment as either a forwarder or as the payer.

However if the payer is involved in a dispute with the payee, he can prove that he paid by presenting the payment preimage.