text:
Why do all addresses begin with "1"? Why can't we just delete it?
The title is the question :)
All the addresses I have seen - from the very first block http://blockexplorer.com/b/0 to the very last one http://blockexplorer.com/b/229850 all begin with "1".
Why is that? And - if it's really like that - why do we need the redundant number there and not just cut it and make the addresses 1 letter shorter?

I tried to read https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses but I still don't see how the 01 suddenly appear in the RIPEMD hash. 00 is for the main network, I guess. But what for the 01?

If an address begin with "1" then it's a hash of a public key, "3" for a script hash, "5" for a private uncompressed key, etc
You can find a list of all prefixes here: https://en.bitcoin.it/wiki/List_of_address_prefixes

I am not sure what "script hash", BUT I am asking here - http://bitcoin.stackexchange.com/questions/9678/what-is-script-hash-address-exactly-and-how-does-it-work :)

This didn’t answer the “Why?”

Because bitcoin and all of its derivatives have addresses start with their own prefixes, I can  write a program that can tell between Litecoin, Namecoin, Bitcoin, and testnet addresses.
Imagine if you couldn't - lets say you see a *coin address on the website of an open-source project, and send some bitcoins to it. It turns out that it's actually a devcoin address. Of course, they could have clarified that it was a devcoin address, but that would take more than one character :)
It also reinforces the point that they're different coins.

"L"  is the prefix for a compressed pubkey ... or litecoin.   You can't use the prefix, only, to tell a damn thing.

@ErikAronesty Litecoin uses a version of 48, while Bitcoin uses 128 for private keys. An address parser can tell the difference, even if it starts with the same letter sometimes.

authors: Константин Ван


text:
How to get all addresses - including the "change" addresses - from bitcoind?
I want to get all my addresses - including the auto-generated "change" addresses - from a running bitcoind somehow.
I haven't been able to do it in a simple way. "getaddressesbyaccount" and all the other API options are only listing the "public" addresses and sometimes few additional ones, but never the already used change addresses. Can I do that somehow?

listaddressgroupings
I used the command listaddressgroupings from the bitcoin-qt console window and it listed all my addresses.  I then looked for one of my old send transactions here:
https://blockchain.info/
And found the change address.  It matches one of the addresses in the list.

I think you are correct. I will let you know and accept this if this is indeed correct.

I did that and there's nothing in my groupings.

When I use that command, I see every address that I've ever used.  Are you sure that the wallet is loaded?  It shows other tranactions and non-change addresses?  You can find your change addresses by looking up your addresses on blockchain.info

This also showed me the balance of each address, which was precisely what I needed.

is this only working when the address was linked to an account? edit: or do i have to complete syncing the chain? atm listaddressgroupings returns an emty array even though I called getnewaddress several times

I wish the GUI app would show these addresses!

This only shows used addresses in your wallet. The proper command is listreceivedbyaddress 0 true which lists all addresses in your wallet regardless of whether or not they have been used.

You may be able to use pywallet to get these.
Download a more updated version here.

The proper command is $ bitcoin-cli listreceivedbyaddress 0 true. It will list all addresses in your wallet, regardless of have being used or not
This answer was originally a comment by CR to Eyal's answer

source: Stack Exchange

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

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

sort: votes


text:
Why does a larger block size infer a bigger attack vector
I have read this in several articles that larger block sizes makes adversarial attacks easier. What I wonder is why is that so obvious? is it because in a larger block the number of transactions could increase to a number that it becomes hard to validate each one of them?

Usually Denial Of Service(DoS) attack may take place on larger sized blocks.So to avoid this condition initially block size Bitcoin was chosen to be 1Mb. Because attacker sends a lot of data in the network to make it busy so that the actual transactions are not able to take place.
Along with reducing block size other methodology which is adopted in Bitcoin are:

No forwarding of orphaned blocks
No forwarding of double-spend transactions
No forwarding of same block or transactions
Disconnect a peer that sends too many messages
Restrict the block size to 1 MB
Limit the size of each script up to 10000 bytes

On which evidence is the statement "Usually DoS attack may take place on larger sized blocks" based?

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


text:
Is BitCoin Mining Basically a Game? Do the Solved Math Equations do Anything?
So I've been trying to learn about bitcoin, I'm a kid. It is really confusing. Is BitCoin basically a game since you solve math equations for money? And also, do the math equations do anything or are they just random and because you solve them, you get a reward for your intelligence?

Yes, its kinda like solving really hard math equations.
Mostly done by specificaly made machines like this one:
Antminer S9
But this video explains it all https://www.youtube.com/watch?v=GmOzih6I1zs


text:
How to log sizes of each block
I am looking to do some research on the blockchain, is there anyway to easily the size of each block while i download it - i have seen graphs from coinbase etc, but these are not accurate for me as for the first 12 months they put the blockchain size as 0MB - Any ideas welcome, i have looked through the log file of bitcoin during the download and while it gives me data about the number of tx in the block etc it doesn't contain the size

What you can do it traverse back from the chain tip via RPC:

call getbestblockhash (RPC)
Use blockhash to call getblock (RPC)
Read size -> store it somewhere (CSV file, etc.)
Read previousblockhash and use it as blockhash for getblock
Goto step 2


text:
Buying bitcoin is easy, but how do you get it back?
I just signed up on coinbase to see how it works. I bought 2$ (CAD) worth of bitcoin. I even managed to change it back into Canadian $. But I don't see any option to withdraw the money. Without the option to withdraw the money at any time, it's really hard to rationalize buying bitcoin. The thing is, I really want to. Badly. What can I do?
After searching for a pretty long time, I found this post confirming my fears.

Our banking partner in Canada shutdown last year. With them shutting down, we no longer have access to deposit funds to Canadian Bank accounts. Fortunately, we were able to provide credit card/debit card access to our Canadian customers so they can continue buying digital currency. We hope to restore bank account access to provide Sells again, but we don't have a timeframe for this.

Sell bitcoins in an third party exchange. (First you need to send the bitcoins to address specified in exchange)
For example checkout a trade ad on localbitcoins.com

Hey, thanks for replying. I was already aware of localbitcoins but as you can see, the prices are a ripoff. First, you lose a % of your money when you buy bitcoins, then you lose an even greater % when you sell them at that site. It makes buying bitcoin very risky and not worth it. Is there no way to buy and sell at market value (or close)? That is really my question.


text:
Why volume from ticker in Kraken API is always whole number
You get something like this (formatted) when querying for ticker https://api.kraken.com/0/public/Ticker?pair=XXBTZUSD
{
    "error": [],
    "result": {
        "XXBTZUSD": {
            "a": [
                "3906.00100",
                "2",
                "2.000"
            ],
            "b": [
                "3906.00000",
                "4",
                "4.000"
            ],
            ...
        }
    }
}

Third numbers (volume) in a and b are always positive whole numbers. They never contain fraction part. Given that unit of this ticker is XBT it looks absolutely unrealistic. Comparing with https://www.kraken.com/charts it also looks completely wrong. Could you please explain it?


text:
Is GPU mining viable with any Cryptocurrency mining variations?
I have a GTX 960 2GB, and wouldn't mind some cash. I know mining bitcoin with it would maybe produce a few pennies a year, but someone told me there are other mining networks that aren't as inflated as Bitcoin. Also, I'm thinking about upgrading to a 1060 soon (for gaming) and use that for mining overnight/during school, if viable. Thanks.

You'll want to keep your eye on a cryptocurrency mining profitability website such as this:
http://www.coinwarz.com/cryptocurrency
Please note that much of the mining software for a lot of these coins contain malware, so be very, very careful before installing such things.

What mining software should I use then? Is cgminer?

depends on the altcoin. They usually have some modification on cgminer or bfgminer that you need to download which allows you to mine that particular coin.


text:
Problem with full node
I've found serious problem with bitcoinj's fullnode. I started downloading blockchain two days ago with bitcoin-qt and today it's complete. With bitcoinj I started downloading block chain about 4 months ago and now it's still downloading it. I've figured out that it's a problem with downloading speed because of these informations:
[PeerGroup Thread] INFO org.bitcoinj.core.PeerGroup - 0 blocks/sec, 0 tx/sec, 0 pre-filtered tx/sec, avg/last 2.81/0.00 kilobytes per sec (stall threshold <1.56 KB/sec for 10 seconds)
[PeerGroup Thread] INFO org.bitcoinj.core.PeerGroup - 0 blocks/sec, 0 tx/sec, 0 pre-filtered tx/sec, avg/last 2.50/0.00 kilobytes per sec (stall threshold <1.56 KB/sec for 10 seconds)
[PeerGroup Thread] INFO org.bitcoinj.core.PeerGroup - 0 blocks/sec, 0 tx/sec, 0 pre-filtered tx/sec, avg/last 2.19/0.00 kilobytes per sec (stall threshold <1.56 KB/sec for 10 seconds)
[PeerGroup Thread] INFO org.bitcoinj.core.PeerGroup - 0 blocks/sec, 0 tx/sec, 0 pre-filtered tx/sec, avg/last 1.88/0.00 kilobytes per sec (stall threshold <1.56 KB/sec for 10 seconds)
[PeerGroup Thread] INFO org.bitcoinj.core.PeerGroup - 0 blocks/sec, 0 tx/sec, 0 pre-filtered tx/sec, avg/last 1.56/0.00 kilobytes per sec (stall threshold <1.56 KB/sec for 10 seconds)
[PeerGroup Thread] INFO org.bitcoinj.core.PeerGroup - 0 blocks/sec, 0 tx/sec, 0 pre-filtered tx/sec, avg/last 1.25/0.00 kilobytes per sec (stall threshold <1.56 KB/sec for 10 seconds)
[PeerGroup Thread] WARN org.bitcoinj.core.PeerGroup - Chain download stalled: received 1.25 KB/sec for 10 seconds, require average of 1.56 KB/sec, disconnecting [127.0.0.1]:8333

Even when my node is connected with loclahost bitcoin-qt only, it takes about 5-7 minutes to download one block (I've also checked bitcoin-qt logs and depending on the statistics, 1MB has been send to my bitcoinj node). After this, downloading peer is closing and bitcoinj is searching for new downloading peer. Also there is a problem with this:
[Script verification] INFO org.bitcoin.Secp256k1Context - java.lang.UnsatisfiedLinkError: no secp256k1 in java.library.path

Is it a serious issue or should I forget about this information?

I don'y know many specifics of bitcoinj, but are you using bitcoin-core's whitebind feature? bitcoinj may be getting DoS banned; connecting to the whitebind port will prevent that.

What do you need the fullnode functionality for? The bitfoinj full validation feature was incomplete at the time it was written, and AFAIK has not been maintained for several years.

From my experience the process of syncing the blockchain is CPU bound, not IO bound (You can check this on Linux by running the top command). bitcoinj has two ways of verifying signatures, either using native code based on the secp256k1 library, or using java code based on the spongycastle library. Your last error message indicates your are not using secp256k1 which is most likely a source of performance degradation and a cause of slow syncing process.
In order for java to use the secp256k1 library, you need to set the environment variable LD_LIBRARY_PATH to a path where the file libsecp256k1.so is located (I am on Debian, this file may have different names on various systems). For example, you could use the command:
$ env LD_LIBRARY_PATH=<path-to-directory> java -cp <classpath> MyJavaClass

However, even if you happen to already have the library libsecp256k1.so on your system (because you installed some other piece of software which relies on it), the above command will not work unless the library was built with the --enable-jni option so as to enable java to interface with it.
In order to build a java-enabled libsecp256k1.so, you can do as follows:
$ git clone https://github.com/bitcoin-core/secp256k1
$ cd secp256k1
$ ./autogen.sh
$ ./configure --enable-jni \
              --enable-module-ecdh \
              --enable-experimental
$ make
$ make check

The library file will then be located in the .libs directory. You can decide to overwrite your existing system file with this new version (but you take the risk of messing up something), or you can simply put this file anywhere you want (or a symbolic link to it) and make sure the LD_LIBRARY_PATH environment variable is properly set to the directory in which it (or a symbolic link) is present.


text:
Does miner with CPFP look through all the possible combinations of descendants to find the one with the highest fee?
When there is a transaction with more descendants, does CPFP policy look through all possible combination of descendants to consider "together", to find which one has the best fee?
For example, when there is a dependency graph, looking like this

there are 6 possibilities to consider for A - {A}, {A, B}, {A, B, C}, {A,C}, {A,C,D}, {A,B,C,D}. Does CPFP miner look through all of them?
In this graph, there will be 25 such combinations, if I count correctly. Would bitcoin core look through all of them?

One can read the code.  But there is no way it literally considers all combinations.  A block with, say, 10000 transactions would have up to 2^10000 combinations.

I don't understand the code enough. There are not that many dependent transactions in mempool

If we run the getrawmempool true RPC, we can look at the data Bitcoin Core has for each of its mempool transactions.  Here's an example:
"3a0af489e500322159db85ad95174ffa3dd9924dbd0b68b041364a8c8eac03cc": {                                                                                "size": 226,                                                                                "fee": 0.00001130,                                                                                "modifiedfee": 0.00001130,                                                                                "time": 1507465582,
    "height": 488876,
    "descendantcount": 24,
    "descendantsize": 5412,
    "descendantfees": 27120,
    "ancestorcount": 2,
    "ancestorsize": 451,
    "ancestorfees": 2260,
    "depends": [
      "3da9c837b8560eadea2f8c48a050e9dd3f4d7637b5209bdf98c19175906529bb"
    ]
  },

Notice the ancestorsize and ancestorfees fields.  These represent the total byte size and fees for this transaction and all of its ancestors. It's then simple to divide the fee by the bytes and produce a sorted list to find which transaction pays the best feerate (fee per byte), including its ancestors.
Then the remaining transactions can have have their ancestor feerate recalculated by removing from consideration whichever transactions were added to the block proposal above, have those new feerates sorted, and find the new best feerate transaction including its ancestors.  Repeat this step until the block proposal has less remaining space than any of the transactions in the mempool.
Calculating these ancestor sizes and fees is pretty fast: you don't need to calculate the values for every ancestor, you just grab the values from your immediate ancestors (which already have all of their ancestors factored in) and then add the current transaction's values to that.
Also, to keep things fast, Bitcoin Core only looks at transaction chains of depth 25 or less.
For more information, this is the patch that added CPFP to Bitcoin Core.  It's relatively short and quite well commented.

Thanks for the answer; I will accept when I am at home and have time to read through thoroughly, but it looks good. I haven't understood the code in either the original Luke-Jr code or in the new one, since they seem too technical to me

Shouldn't it be "including fees of its descendants" instead of ancestors? Child pays for parent, so you should be interested in the descendants, no?

@KarelBílek it's ancestors.  Per consensus rules, child transactions can only be added to a block if their parents are in the same block or an earlier block, so CPFP means a child pays a high fee in order to get its low-fee ancestors confirmed.  A high-fee ancestor does nothing towards having its low-fee descendants confirmed.

Oh OK, I had it reversed. I thought that for each transaction, you check its descendants, if they pay for it. But it's the other way, for each transaction, you check its ancestors, if it pays for them. Cool


text:
Where are the new smart fee estimate data saved? Can the file be re-used?
Are the data for smart fee estimation (in bitcoin core with version 0.15.0 or larger) saved?
Where is it saved, what is the format?
Can they be re-used on a different node - so the estimates are accurate, even when the node is just started? If the file (or files) is moved from node to a different node (that has a different chain state), will the fee estimates still be accurate?

In the bitcoin data directory, there is a file called fee_estimates.dat.  This file is only written when bitcoind or bitcoin-qt exits so it is not up to date until that point. After that you could copy it and use it on another node to start with up to date estimates.
There is some trickery if the nodes are at different chain heights, but it should mostly do the right thing. It tracks the block height that the estimates were written as of and the new node won't affect the estimates until it's active chain has advanced beyond the latest recorded block in the old file.  Also if the chain in the new node is past the last recorded block in the file, then the estimates are decayed under the assumption that the data is no longer as meaningful.
In general if you start from scratch, you should only need to wait for about twice as many blocks as the target you would like an estimate for before you are able to get a somewhat reasonable answer.

This is some very useful information @morcos. I was wondering what happens if a node hsa been running for a very long time and then it's stopped and restarted one month later. Are the estimates from one month ago decayed so much they are negligible or they still bear a heavy wait because it was "just before it restarted"? Also, is there a way to deserialize the information in fee_estimates.dat? I would like to take a look at the information stored in there.


text:
What prevents similar time-warp attacks in Bitcoin as happened to Verge?
Right now (may 2018), Verge (an altcoin with proof of work)  was attacked by time-warp attack. More can be read here
https://blog.theabacus.io/the-verge-hack-explained-7942f63a3017
What exactly prevents from similar attack to happen to Bitcoin?
Verge has different hash logic (more frequent retarget, more concurrent hash algorithms), but the logic of the attack should, in my reading, apply also to bitcoin.
Since it did never happen in Bitcoin, I probably missed something. How is Verge different from Bitcoin that this happened in Verge, but not in bitcoin?

Nothing directly prevents it in Bitcoin, and indeed the attack has been demonstrated on testnet3 many times---it's the primary reason that testnet3 currently has almost three times as many blocks as Bitcoin, despite being launched several years after Bitcoin mainnet and with a something similar to[1] Bitcoin's 10-minute average block interval.
Indirectly, there are several reasons the time warp attack is less practical on Bitcoin mainnet than testnet3 or altcoins like Verge:

Obvious: once blocks used in a time-warp attack are broadcast, anyone can see that median-time-past (the monotonic clock in Bitcoin) is lagging far behind real time.
Slow: the time warp attack exploits the formula used for retargeting, but retargeting only runs once every 2,016 blocks (two weeks at normal rate) and can only reduce difficulty by a maximum of 75% per period.  Now, 75% is a lot, but so is spending two weeks executing a publicly-visible attack.  Further difficulty decreases can be executed faster due to the modified difficulty, but they're still pretty slow: 3.5 days for the second retarget; about 1 day for the third; about 6 hours for the fourth; etc...
Easily fixable by miners: if honest miners control the majority of the hashrate, they can simply refuse to build on top of blocks whose timestamps are too far in the past.  If median-time-past is restored to its normal trailing average before the end of the initial 2,016-block retarget period, difficulty won't be changed any more than normal.

If all these reasons do indeed provide indirect mitigation, then why do we see the attack on testnet3 every few months?  Mainly because testnet3 uses the same SHA256d proof of work function as Bitcoin and so anyone who wants to mine blocks really quick can hook up some modern ASIC miners to create a bunch of testnet blocks quickly.  This would normally rapidly increase difficulty, but the increase is prevented using the time warp attack.  That said, in at least one case in the past where a time warp attacker made testnet3 unusable for an extended amount of time, some generous person pointed their own huge mining rig at testnet3 to overwhelm the attacker and bring difficulty back up.
On Bitcoin mainnet, if the attack was ever executed, I think the story would be different.  Within days, a large percentage of the userbase would know the attack was ramping up and would start to pressure honest miners to reject the attacker's blocks.  I personally expect miners would comply (as the next step would be for people to start throwing around phrases like "PoW function change"), which would defeat the attacker and cost him expected revenue for every rejected block.
If attackers expect the scenario would play out basically the same way I think it would, then there's no point in them starting the attack in the first place---which I think is what ultimately prevents time warp attacks on Bitcoin.
[1] Testnet3, unlike Bitcoin, has a rule that if no block has been mined within 20 minutes (according to block header time), that a miner can create a difficulty-1 block (the lowest difficulty).  That means that even completely honest mining on testnet3 is faster than on mainnet, as on mainnet something like 20% of blocks take longer than 20 minutes to find.

Some extra notes:

A fork could change the retarget calculation to use median-time-past instead of raw block header time.  This could fix the time warp attack on Bitcoin, but it would probably have to be a hard fork.
Since the BIP113 soft fork, median-time-past has been used to restrict which nLockTime transactions miners can include in their blocks.  Not many transactions use nLockTime with a time at present, but if there was a time warp attack, users could start doing so to create a large fee incentive for miners to bring median-time-past closer to real time.

It's interesting that most of these defenses are social rather than technical. It depends on majority of miners not colluding.

@KarelBílek: If a majority (>50%) of miners are colluding, then you've already lost.

Also, on testnet3, due to a quirk of how the difficult readjustment works, if the last block in a retarget period takes longer than 20 minutes to find, it will not only reset that block's difficulty to 1 but all blocks for the next retarget period will also have a difficulty of 1. That makes testnet3 easily gameable to have a very low difficulty.

@David A. Harding.  In this sentence:  "Further difficulty increases can be executed faster due to the modified difficulty", do you mean “decreases”  or the generic “changes” rather than "increases" ?

@dbkeys fixed, I meant "decreases".  Thanks.

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


text:
API for top bitcoin addresses sorted by available balance
Is there any API from where I can get the list of top bitcoin addresses sorted by available balance? I know there are many websites out there listing Bitcoin rich list but I need an API.

This should works: http://www.tokenview.com:8088/address/richrange/btc/1/100
API documentation: https://tokenview.com/en/api


text:
How to generate these bitcoin addresses?
For the private key KwaZRh42fdQD4iUN6sy2GtEC5gfSAYXrQgp16KPV4Pxsspi5ChRb, I have the following addresses:

1N7jKvQ1fHezb61eNsGEaF4gcj5sQXhb2m (P2PKH)
14MNoFYWheu7sLkj8urvXCpYEdCuL4m2PH (P2PKH)
3G4BoJsFB6N3Eejtovr8PUnvz4LRDhWmxk (P2SH)
bc1qu7s8s2ga69a9068s85e9vpxh7uvneet292wa5n (P2WPKH)
bc1qxr7lhfgnynvw7dk3e0asw2hsxhdvp4cgp7u0z09stm26gaxqn6zqd9muau (P2WSH)

I am looking for a utility (like the ku utility from https://github.com/richardkiss/pycoin) which can generate all these address given the private key (the ku does not generate the P2WSH address). The utility I am searching for can be in C, C++, Go or Python.

https://godoc.org/github.com/btcsuite/btcutil ?

@RedGrittyBrick Thanks but I already know about this one. Looking for a executable like ku so that I don't have to write any code.

It's not clear to me why you would generate a *SH address from a single key. Could you outline what sort of script that should contain?

from bitcoinlib.keys import *

pk = 567
address_U = Key(import_key=pk, network='bitcoin', compressed=False)
print(address_U.address())
print(address_U.public_hex)
print(address_U._x)
print(address_U._y)
print(address_U.hash160.hex())
print(address_U.wif())
print('***************')
address_C = Key(import_key=pk, network='bitcoin', compressed=True)
print(address_C.address())
print(address_C.public_hex)
print(address_C._x)
print(address_C._y)
print(address_C.hash160.hex())
print(address_C.wif())
print('***************')
print(Address(address_C.public_hex, encoding='base58', script_type='p2sh', witness_type='p2sh-segwit').address)
print(Address(address_C.public_hex, encoding='bech32', script_type='p2wpkh').address)
print(Address(address_C.public_hex, encoding='bech32', script_type='p2wsh').address)

I have a tool which does that in my bcutils repository:
python3 bcaddr.py KwaZRh42fdQD4iUN6sy2GtEC5gfSAYXrQgp16KPV4Pxsspi5ChRb
privkey             : 0ab9bb56315ce08019d61dd3480e51c35d6339c4618ad5c9824d0e47bedcc957
wallet              : 5Hu1YsmBoMwCLsdZRSbSfVNZsTCt1oZpSkunncS2ptsitRnbe3m
cwallet             : KwaZRh42fdQD4iUN6sy2GtEC5gfSAYXrQgp16KPV4Pxsspi5ChRb
version: 128          compressed: 1
compressed          : 03418fe8f11fa50cd9584b290fcbfc60c5af9a713facf3faac27792921910dbd5a
full                : 04418fe8f11fa50cd9584b290fcbfc60c5af9a713facf3faac27792921910dbd5a7ccb3081ca2a2f06f2944b2405c622860af42ce5e91351f428c0199c6055dc85
comp: e7a078291dd17a57e8f03d325604d7f7193ce56a:   0 1N7jKvQ1fHezb61eNsGEaF4gcj5sQXhb2m - bc1qu7s8s2ga69a9068s85e9vpxh7uvneet292wa5n
full: 24c2e464c447a78950949c8649729865dd41e5e7:   0 14MNoFYWheu7sLkj8urvXCpYEdCuL4m2PH - bc1qynpwgexyg7ncj5y5njryju5cvhw5re08yvasde
p2sh: 9d92bd57e9a882fe08c200b8f325efecbb2cb2c0:   5 3G4BoJsFB6N3Eejtovr8PUnvz4LRDhWmxk - bc19nkft64lf4zp0uzxzqzu0xf00ajajevkqvgd0xt
p2sh(full): 6ce28aa65204eabc762e5adcc7b7146810a54bc0:   5 3BckHeXP5Gb6n5iXRepyDpWAVjXu58YRb4 - bc19dn3g4fjjqn4tca3wttwv0dc5dqg22j7qtkf620
p2wsh: 30fdfba51324d8ef36d1cbfb072af035dac0d7080fb8f13cb05ed5a474c09e84: - bc1qxr7lhfgnynvw7dk3e0asw2hsxhdvp4cgp7u0z09stm26gaxqn6zqd9muau

from bitcoinlib.keys import *

priv_key = '0000000000000000000000000000000000000000000000000000000000000237'

U_pub_key = Key(import_key=priv_key, network='bitcoin', compressed=False)
C_pub_key = Key(import_key=priv_key, network='bitcoin', compressed=True)
C_hex = C_pub_key.public_hex

U_wif = U_pub_key.wif()
C_wif = C_pub_key.wif()

add_U = U_pub_key.address()
add_C = C_pub_key.address()

p2sh_segwit = Address(C_hex, encoding='base58', script_type='p2sh', witness_type='p2sh-segwit').address
p2wpkh = Address(C_hex, encoding='bech32', script_type='p2wpkh').address
p2wsh = Address(C_hex, encoding='bech32', script_type='p2wsh').address

print(add_U)
print(add_C)
print(p2sh_segwit)
print(p2wpkh)
print(p2wsh)
print(U_wif)
print(C_wif)
print(priv_key)
print(U_pub_key)
print(C_pub_key)

13sjRRtRsDD3gQVW2XDXHM8ahBEBzVNyrK
1KCvMjHxAKv7pdzCFLhhKrQNpVWN1eyeAb
32MAGHunMfYDb1cCC1hDxiovYCUg6oNxhU
bc1qc7ekz48gzmds2sedh9vm59j3yezg33d392fzj3
bc1qu4t4gt4dpzjhr357yxmnjjsqaakuc75vt8qhct9kgraq7pd7xgys8hw8eg
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsrfGd4hTb9
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUBuithWYeP
0000000000000000000000000000000000000000000000000000000000000237
0455faaaee59a20b9a3784d1719ea529cc1b7ab3a329f26dfaa3b11bd667ba15c1a9f8939b52ac53e35ed4771d8e47065c0d7f2805a7e5475c37353ddf182f4a65
0355faaaee59a20b9a3784d1719ea529cc1b7ab3a329f26dfaa3b11bd667ba15c1


text:
Generating P2WSH addresses | Is there a standard WitnessScript?
For the examples below I am going to be talking of 1-of-1 multisig only derived from a single private key.
For P2WPKH, the address is generated using using hash160 of the public key which acts as the witness program.
For P2WSH, is there any standard witness program? The demo in https://bc-2.jp/tools/bech32demo/index.html uses <pubkey> OP_CHECKSIG[0xac] as the WitnessScript. While bitcoinaddress pip package uses a different approach (see https://github.com/fortesp/bitcoinaddress/blob/master/bitcoinaddress/address.py#L130-L133 )
(Please excuse any wrong nomenclature I might have used in this question)

Note that witness program and witness script are not the same thing (the first is the OP_n + hash placed in the scriptPubKey; the second is the actual script executed. Also, you're asking about a standard witness script to do what? A 1-of-1 multisig is pointless.

@PieterWuille Thanks for your reply Pieter (SegWit designer). So what I am asking is about a standard witness script to create a P2WSH address. (In Samourai wallet, I have noticed I have P2WSH addresses, and so I was wondering how it was created.)

A standard witness script for what? A script is a program, it does something. The question is what do you want it to do?

First of all, like pointed out in the first comment on your question, you're confusing the "witness program" and "witness script". The witness program for p2wpkh is OP_0 followed by the 32-byte SHA-256 hash of the witness script.
So it seems that you are actually asking about the witness script.
To answer your question directly: no, there are no standard witness scripts.
The witness script obviously depend on what you are trying to achieve. The most common use case for p2wsh would be multisig addresses, but they can be used for various other use-cases like policies with time-locked backup spend paths, lightning channel setup, etc.
Each use-case and in fact each application will have to specify the Script they use in the p2wsh policy. There is no real standard among those scripts. However, there are some things to consider:

Whatever Script you are using, you need to remember the script in order to spend the money that is in them. Usually this is something that your wallet will do, but for example if the wallet you are using goes out of service, you will need to know the type of script they use in order to recover your money, alongside the seed phrase.

Many users will use tools like miniscript Script descriptors to turn a script policy into a Bitcoin Script. These users can store the Script descriptor as a backup together with their seed phrase. Script descriptors were introduced exactly to overcome the problem of each wallet having their own scripts.

In several cases, among multisig-enabled wallets that don't support miniscript descriptors yet, the "Script template" they use is either very trivial (a simple multisig f.e., even though f.e. the order of keys also matters here, already making it less trivial), or the template is documented online and a user could potentially find out how to recover their money when they only know their seed phrase.

To conclude, witness scripts used in p2wsh addresses are not standardized and ideally your wallet provider would instruct you to backup a miniscript descriptor alongside the seed phrase so that users can actually recover their coins in the event where the wallet provider disappears and/or the wallet app becomes unusable.

It is 0 and a 32-byte push of Sha256 of the scriptPubKey (which is the script you use to generate the address). You can find an example here: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wsh
The Python example you linked uses WP2PSH as WP2PKH. You can see the how WP2PKH works here: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wpkh


text:
How many possible addresses per bitcoin private key?
Based on my research every bitcoin private key (compressed or uncompressed) can have 4 different addresses:

P2PKH compressed and starts with 1
P2PKH uncompressed and starts with 1
P2SH and starts with 3
Bech32 and starts with bc1

Are there any other types of address that can be created from a private key?

It depends a lot on the kind of locking condition you want to satisfy. The addresses that you have mentioned would depict 'standard' locking condition where the user reveals their public key and associated signature in order to spend the locked bitcoins. However, you can create custom scripts and then convert them into standard addresses.
For example, locking some bitcoins in a CLTV script using the same private key will generate a completely different address. You can use CSV or any other custom opcodes like OP_ADD to generate those custom scripts and then wrap the script in P2SH or P2WSH. When you spend the funds you need to reveal the custom script and the signatures should match. When you include the possibility of generating standard addresses from the custom made script, the possibilities are endless.
Also, a point to note is that a compressed public key will generate a completely different address as compared to an uncompressed public key.

While the answer is technically correct, I think for most users, you really only end up with a handful of addresses: p2pkh compressed, p2pkh uncompressed, p2pk uncompressed, p2sh-p2wpkh compressed - anything else would likely require significant effort to generate and spend

@RaghavSood Agreed! But I think OP was looking for a more comprehensive answer. btw you missed native P2WPKH in your comment.


text:
What is "fed-peg" and "predefined functionaries" with sidechains?
I am reading about side-chains, and what I read in this article is:

The initial sidechain included in Sidechain Elements works on a
  federated security model; while it’s still peer-to-peer and
  consensus-based, security for the blockchain is provided by a set of
  predefined functionaries in an arrangement called a Fed-Peg. A number
  of academic groups and individual contributors have agreed to run the
  Sidechain Elements Fed-Peg, including blockchain groups at Stanford,
  MIT, and Princeton. The sidechain does not include mining or
  proof-of-work at this point.

I have no idea what that means. What is "fed-peg"? Why is that needed? Does it change in any way the security of the main chain? How does it differ from decentralized PoW?

I have no idea what that means. What is "fed-peg"? Why is that needed?

When you're creating a sidechain, you need a way to move Bitcoins from the main network to your sidechain. This is pretty straightforward. Counterparty, Ethereum, and NXT had various ways of doing this. (Admittedly, none of these allowed people to turn Bitcoin into the assets on these networks after they started, but I suspect that's due to economic reasons rather than technical ones.)
The more complicated, and more important issue, is how you move Bitcoins that are on the sidechain back into the main network. I've heard multiple proposals on how to do this, but all of them are either

insecure,
centralized,
or require very complicated changes to the Bitcoin protocol.

This approach is centralized.
The idea with that you have several authorities, each of whom has a private key. Those private keys together control a multisignature account. When you move Bitcoins onto the sidechain, you deposit them into the multisignature account. When you want to move them back to the main chain, you do so on the sidechain; those federated authorities will independently validate that transaction. Then, all of them sign a withdrawal from the multisignature account to the main network address you specified in your sidechain transaction.
The blockstream paper suggests a 3 of 5 multisignature account. The issue with this is that if 3 of those keys are compromised (or if 3 of them collude) then they can take all of the money out of the multisignature account.

Does it change in any way the security of the main chain?

No. It doesn't modify the main network. Future incarnations might, though. There's not enough detail about those possible future systems to answer that at present.

How does it differ from decentralized PoW?

The federated authorities have two roles in this system: gating transactions into the system by producing timestamped blocks, (something normally done by miners) and the previously mentioned multisignature account.

Federated peg is described in Appendix A of the sidechain whitepaper, https://blockstream.com/sidechains.pdf . I don't completely understand the details but here is an overview. In order to implement sidechains in the ideal fashion, the Bitcoin protocol must be modified. It is difficult to gain consensus for such a modification. However, in the meantime, "federated peg" is proposed as a temporary measure for implementing sidechains.
The idea of sidechains is to set up a system that allows you to effectively transfer Bitcoins from the main chain onto the sidechain, and then later transfer those Bitcoins back from the sidechain onto the main chain. While the Bitcoins are 'effectively' in the sidechain, from the perspective of the main chain they are just sitting in some address ('locked'). I like to imagine that the 'locked' Bitcoins on the main chain are 'sleeping' deep in a trance, projecting their 'astral body' into the 'astral plane' of the sidechain. When they finish their business on the sidechain they can then later 'return to their body' and 'wake up' on the main chain.
With federated peg, in order to transfer the Bitcoins from the main chain to the sidechain, you transfer it to an address on the main chain and give control of that address to a small set of trusted parties using a multisignature transaction (eg perhaps you choose 5 trusted parties and then use a 3 of 5 multisig; then in order to move the coins back to the main chain, 3 out of 5 of them will have to agree). These trusted third parties are called 'functionaries' in the paper.
Then, on the sidechain, the trusted third parties inform the sidechain that you have just transferred in those Bitcoins. The 'astral bodies' of your Bitcoins can then be transferred to others on the sidechain. Perhaps at some time in the future, a future owner of some or all of these 'astral bodies' wants to move them back to the main chain. This person informs the trusted third parties (the functionaries) of the main chain address that e wishes to send the coins to, and attaches a proof-of-ownership showing that they are the current owner of the 'astral bodies' on the sidechain. The functionaries inspect the proof-of-ownership and if it is valid, they then delete (or otherwise remove from circulation) the astral bodies from the sidechain, and use their multisignature authority on the 'locked' coins on the main chain to unlock them and send them to the requested address.
This method is called 'federated peg', presumably because it is a type of 'peg' (connection between coins on the main chain and coins on the sidechain) enforced by a 'federation' of trusted third parties (functionaries). This method requires trust in the trusted third parties (functionaries) because if 3 of 5 of them collude (or however many of them there are), or get their keys stolen, then the 'locked' Bitcoins can be stolen on the main chain. However, the goal is for this to just be a temporary measure, until such time as consensus is gained to modify the Bitcoin protocol to implement sidechains using a different method, called 'SPV peg'. After that, you would be able to stop using 'federated peg' and use 'SPV peg' instead; unlike federated peg, SPV peg allows you to transfer Bitcoins between chains without trusting anyone.
'Federated peg' does not modify the Bitcoin protocol or require the cooperation (or even knowledge) of anyone outside of the users of the sidechain, so it has no impact on the security of the main chain.

It means that, unfortunately, they still can't figure out how to make a sidechain work without either a central authority or its own independently-mined chain (i.e. a full-fledged altcoin).
This is sad, because it was the one thing they kept promising sidechains would bring us.
But yet we're still back where we started: if you want a cryptocurrency with a feature bitcoin doesn't have, and you don't want a central trusted authority (like Ripple), you need to start an altcoin.  Sidechains have not changed anything here.

Well, I still don't understand what does it actually mean and how is the pegging done.

Well there's a trusted third party whose public key is hardwired into the code.  Any difficult questions that come up or disagreements, basically the trusted party decides the answer.  Same as Ripple pretty much.

Here, check out https://github.com/ElementsProject/elements/blob/alpha/contrib/fedpeg/constants.py -- basically you must "rippleize" the sidechain by hardwiring its central authority's public key on line 15.  Without it, no sidechain.

I think that's why they started lightning.. because they weren't getting anywhere with sidechains.. and now we have to bear their blocking of the block size increase.. -.-

Afaict it's not that they "can't figure out" how to make sidechains work without a central authority, it's just that their primary proposal (SPV peg) requires a modification to the Bitcoin protocol, which requires gaining consensus. So, as a temporary solution in the meantime, they propose "federated peg". The plan outlined in the paper is to persuade others of the safety and desirability of SPV peg and then switch to that later. (I am not taking a position on whether an SPV peg is actually safe and desirable, I'm just saying that the paper presents it as such).

Although afaict it's true that SPV peg has not yet been IMPLEMENTED; but i think the proposers would claim that it has been 'figured out' but just not yet implemented (not sure about this).

A tiny bit of detail on this was added as an "Appendix A" to the sidechains paper at some point:

By adopting some additional security assumptions at the expense of the
  low trust design objective, it is possible to do an initial
  deployment in a completely permissionless way. The key observation is
  that any enhancement to Bitcoin Script can be implemented externally
  by having a trusted federation of mutually distrusting functionaries
  evaluate the script and accept by signing for an ordinary
  multisignature script. That is, the functionaries act as a protocol
  adaptor by evaluating the same rules we would have wanted Bitcoin to
  evaluate, but cannot for lack of script enhancements. Using this we
  can achieve a federated peg.

Basically it's a cabal of "trusted miners".
Since the main bitcoin chain miners don't understand the sidechain's cool new features they can't validate those blocks.  So the sidechain has to be run Ripple-style where there is a pool of trusted miners and one of them has to sign off on each block.  These trusted miners (which they call "functionaries") hold special private keys, and the corresponding public keys are hardwired into the source code.  These central authorities have the power to block the chain's progress, exclude transactions, or even freeze accounts.

Is there some reason why you made two answers instead of editing your first answer?

@NickODell it enables him/her to "sidechain" his answer.


text:
Manually generating seed for Trezor T
Is it possible to manually create a seed from the BIP 39 English word list, and enter them in the Trezor Model T recovery to create a wallet from those words. I know that choosing the 12 words doesn't work, because the last word is a checksum of the previous 11. Is there a way to determine the 12th word from the first 11?

Warning: DO NOT use a human to choose the seed words, use a proper cryptographic library. Humans are a very bad source of entropy, there is a very real chance your funds will be stolen if you ignore this.

Remember that even if you properly generate the seed on a computer, you have lost a part of the security already if your computer isn't airgapped (which it probably isn't). The purpose of a hardware wallet is to be a lightweight airgapped computer with specifically this as its job.

Here is an easy working example that will augment https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch05.asciidoc#using-a-bitcoin-wallet.
% bx mnemonic-new 0C1E24E5917779D297E14D45F14E1A1A
army van defense carry jealous true garbage claim echo media make crunch
The following will provide even greater insights what is going on under the hood.
% echo 0C1E24E5917779D297E14D45F14E1A1A | bx sha256 | cut -c 1-1
7

 0   C   1     E   2   4     E   5   9     1   7     7   7   9     D   2   9
 00001100000  11110001001  00111001011  00100010111  01110111100  11101001010
000001100000 011110001001 000111001011 000100010111 001110111100 011101001010
0x060        0x789        0x1CB        0x117        0x3BC        0x74A
96           1929         459          279          956          1866
97           1930         460          280          957          1867
army         van          defense      carry        jealous      true

   7   E   1     4   D     4   5   F     1   4   E     1   A   1     A   7
 01011111100  00101001101  01000101111  10001010011  10000110100  00110100111
001011111100 000101001101 001000101111 010001010011 010000110100 000110100111
0x2FC        0x14D        0x22F        0x453        0x434        0x1A7
764          333          559          1107         1076         423
765          334          560          1108         1077         424
gap          claim        echo         media        make         crunch

The possible secret + checksum bit lengths from BIP39 are:

Entropy Lengths: 128, 160, 192, 224, 256 bits
Corresponding checksum Lengths: 4, 5, 6, 7, 8 bits

Each word represents 11 Bits. Therefore, for a 12 word phrase represents a total of 132 bits, of which 128 are entropy and 4 checksum. So note that the 12th word "includes" the 4-Bit checksum but not exclusively.
To generate your 12-word passphrase, simply determine:

128 bit secret
4 bit checksum (first four bytes of sha256(secret))
Concatenate above, split into 11 bits and determine word conversion via wordlists.

Wordlist documentation:
https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md


text:
Ledger: is the private key tied to the device or the wallet?
Context: I have a Nano S since before, with one recovery phrase and a wallet with some minor BTC on it. Bought a Nano X, set up with a new phrase, and a new wallet, and put some coins in that. Then I imported the old wallet to the new device as well via Ledger Live, so there's two wallets. But then I started wondering:
Is the recovery phrase per device or wallet, or how does it work? If someone gets my old phrase, can they unlock my new device as well, or can they only unlock the old wallet?
It seems it would be possible to unlock the old wallet with either the new or old phrases, but the new wallet only with the new phrase?
Been scouring through the docs but it doesn't really say how this works. I guess when I imported, it should have regenerated that same old wallet but with new keys? But would want to be sure.
Not too worried about the old wallet, but the new. So if someone still can recover only the old one, I would not care that much, but is my new wallet on both phrases somehow I guess is my question, or is it only on my new Nano X devices phrase?

The keys are tied to the mnemonic (or seed phrase or recovery phrase) that you use. The keys are derived directly from it. If any gains access to the mnemonic, they can directly produce the private keys that you used without access to any of the physical hardware. Furthermore, having the mnemonic does not allow them to unlock your hardware wallet - the PIN you use is independent of and unrelated to the mnemonic and the private keys. But that is moot because if someone has the mnemonic, they don't need your hardware to take your Bitcoin.
Importing means that you setup a new device with the same mnemonic. So anyone with the mnemonic can still take your Bitcoin. If they get access to the old device and figure out the PIN, then they can also take your Bitcoin because it is the same private keys.

Still not sure that is what I mean. The new device is setup with a completely new recovery phrase, and a new wallet. Then I also imported the old wallet via the Ledger Live app. The only thing I actually care about is if both wallets are accessible through the old phrase or if the newly created at least is separate. The old wallet is not that important, even though there's some value in it for now. If importing from the old device somehow made double recovery phrases I will have to start over the process, because I don't trust that one 100%

To be extra clear, since I setup and created the new device and wallet first, I would at least not expect the import to throw away that phrase, but does it recode the imported value, save both phrases or what? And so on...

The new phrase is independent of the old one. If someone gets access to the old one, they cannot get access to the new one or any coins associated with the new phrase. I'm not sure what the import does, but there's no way for it to link the two phrases together like how you are suggesting.


text:
Is there actual economic value in trading crypto currency?
When you invest in a stock, you're helping the company to raise capital.
It seems like trading crypto currency is nothing more than putting money into a pool (market cap) and trying to predict when other people will put more money into the pool. No economic productivity happens here except for money changing hands. Is there actual any value in trading coins or is it just money changing hands?

When I buy a share of stock, I typically buy it from someone else, not from the company.  Unless the company itself is the one selling me the shares (as in an IPO), they don't see a dime from the trade. Trading stock generally does not help the company raise capital.

Yes, there is.
People who trade currencies (or commodities, for that matter) broadly belong to two groups - those who actually need to convert one thing to another; and those who hope to buy low and sell high for profit.
In Bitcoin's case, typical examples of the first group are an individual who receives his salary in USD, and converts the USD for BTC to use it; and a business which receives payment in Bitcoin, and converts to USD to pay its suppliers. In both cases, economic value is created by enjoying Bitcoin's advantages; and in both cases, trading BTC/USD was needed to allow activity that would be impossible or less efficient without trading.
The second group is simply people who trade BTC/USD for profit, and often come out with the same currency with which they went in. To be successful, they need to buy low and sell high - and if they manage to do that, they are actually providing a service to the first group. Since buying drives the price up and selling drives the price down, buying low and selling high keeps the price stable at some midrange. This makes the price more stable, and reduces slippage costs, thus making the usage of the currency more efficient. So they are also creating economic value by making it easier to use the currency for commerce.
This is true even over long periods of time. A Hodler who buys a bitcoin for $1, and only sells decades later when the price is $1M, is helping the economy by giving the currency a push when it is nascent and underappreciated, and only realizing her gains once Bitcoin has reached its potential.
Of course, a dumb or unlucky trader can buy high and sell low; in this case, he is actually adding volatility to the price, and creating economic harm. But he will also take a loss himself if he does that. As long as the trader is making a profit, she is creating economic value.

No there is no economic value, exactly like when trading any other currency.
There lies some kind of value in declaring trust in a currency, or the legal entity that stays behind a currency. However, with bitcoin the trust is shared among the participants. So with, investing, you declare your trust in the existing participants. But besides that trust, there is no value.

When you have a medium to transfer money without any intermediary, which is deflationary, secure and kinda anonymous, the demand for it is obviously gonna go up.

Until something better comes along, or its usefulness otherwise decreases, in which case the demand will go down...


text:
When creating a transaction, how can you prove that you own your address without exposing your private key?
I'm trying to understand how Bitcoin works under the hood, but there's something I don't get at all, and can't find it.
Suppose I own address A (I have the public key, A-public, and the private key A-private) and I want to transfer 1 BTC to address B (I know its public key, B-public).
In order to be able to do the transaction, I must, somehow, prove that I own A, and the only way to do that is to show A-private. But, if I show A-private, then I'm exposing my private address, so, someone, somehow, could get it.
To sum up: in the Bitcoin blockchain, how do I prove that I own a certain amount of bitcoins without exposing my private key? Or, alternatively, how does the Bitcoin protocol handle that?

https://en.wikipedia.org/wiki/Digital_signature

In Public-Private Key Cryptography, you can use your Private Key, (without sharing it with anyone), in a way to create a message that is completely tied to your Public key.
Anyone can look at that message, and your Public key, and deduce that the only way that message could be generated is by someone who knows the Private key, even though they don't know what the Private key is.
The fact that the message can be confirmed with your Public key proves that you must know the Private key, and must be the owner of the Public Key and the Wallet Address.
Think of it as a lock that is left closed all the time.
You can unlock the lock anytime with your secret key, without showing anyone your key.
Anyone can look at that lock, and come to the conclusion: "This lock must have been opened by the owner who has the key; no one else could have opened it", but you still never shared the key with anyone.

This is the exact response I was looking for.


text:
How do I read this cryptocompare table?
in the Cryptocompare table I don't understand what the columns mean, e.g. there is Price, "Open 24H", "Range 24H", etc... Does anyone know what the different columns mean?

24H means 24-hours period.
Open 24H:
The price of the first transaction 24 hours ago.
Range 24H:
H - High: Highest price reached.
L - Low: Lowest price reached
Last Trade:
Value of the last transaction that took place.
Volume 24H:
The amount of BTC that change hands.
Change 24H:
Price and % change during the past 24 hours.


text:
Can I easily use Bitcoin as a inexpensive way to transfer my money into another currency?
I have a home business in the US and I am spending a significant amount of time in Europe.I have both a US and a EU bank account as well as a coinbase account. I am wondering if I can by bitcoins in USD and then sell them back to my EU bank account in Euro? My normal bank charges $35 plus they give me an exchange rate 4.5% more than the market. So, for each $1,000 I send, I pay almost $45 in exchange fees plus the $35 transfer fee...I am wondering if using bitcoin can help me significantly reduce my costs for this type of international money movement? has anyone done this and can you tell me of any problems or pitfalls? Thank you!

I have done this successfully in the past, just like you for USD to EUR.
You'll pay probably pay around 0.5% to move USD into Bitcoin, then another 0.5% to move them to Euro. In any case, you should probably be able to stay below $80 on $1000. ;)
You might need a bank account denominated in Euros though, and it will take a few days. (For me it was something like 20 minutes for the exchange to confirm that the bank transfer to my account was on the way and two days until it was in my account.) Depending on the price movement of Bitcoin you might win or lose additional points.
I did this almost three years ago, so maybe it's not quite as easy anymore with the increased AML and KYC going on.

Thanks for the answer. I am still waiting for a response from Coinbase since they only allow me to have US based banks in my account. I figured it would be possible, just have not figured out exactly how yet..

You can also get a Xapo account, create a Wallet and request their debit card associated with this wallet. Once you get your Xapo debit card you can transfer BTC to the associated wallet and:

Spend EUR directly from the debit card (no fee if the debit is in the same currency as the card)
Withdraw EUR bills from an ATM which you can use later or deposit in your European bank.

There is a certain limit of money (~2500 EUR) you can spend with this card without an identity proof, but you can try it first, and if you like how it works, you can send your proofs to Xapo later.


text:
Is it possible to extract legacy address from segwit address?
After 24 aug 2017 starting from block #481824 blockchain DB consist transactions with the segwit-addresses.
For example (have a look to the address, specified in the output):
https://btc.com/461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6
address
bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak
or (how I understand it is the same address, but in another format)
cdbf909e935c855d3e8d1b61aeb9c5e3c03ae8021b286839b1a72f2e48fdba70
I have to notice that only btc.com parsed this output (for example, blocktrail.com or blockexplorer.com couldn't parse this).
In the same time json-rpc of bitcoin-core client couldn't parse this address too.
[vout] => Array
(
[0] => Array
(
[value] => 0.005
[n] => 0
[scriptPubKey] => Array
(
[asm] => 0 cdbf909e935c855d3e8d1b61aeb9c5e3c03ae8021b286839b1a72f2e48fdba70
[hex] => 0020cdbf909e935c855d3e8d1b61aeb9c5e3c03ae8021b286839b1a72f2e48fdba70
[type] => witness_v0_scripthash
)
)
)
How we see - no section "addresses" in the section "scriptPubKey" (in case of "legacy" addresses json-rpc returns information about the addresses).
So what I want to ask:
1) What is the difference between
bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak
and
cdbf909e935c855d3e8d1b61aeb9c5e3c03ae8021b286839b1a72f2e48fdba70
? Is it different formats of 1 address?
2) How could I know hash of legace-address of the followed transaction? Is it possible? May be I have to parse scriptBubKey hash for this?
3) Why bitcoin-core json-rpc doesn't provide this info? I use last version of bitcoin-core client.
Thanks a lot for the any information.

I thought segwit addresses starts with 3?

Native SegWit addresses use the bech32 encoding and start with bc1, for now, most people use SegWit with P2SH addresses that start with 3

While technically it is possible to generate one address from another, after all they are simply representations of public keys, it is strongly discouraged to do so, if you are not the owner of the address (at which point the wallet should provide you with an option to use either format). The problem is that if you send a transaction to a segwit address, that the recipient is not expecting/supporting then they will not recognize the payment.
Now for the apparent aliasing you mention above: the recipient address of the transaction you link to is a P2WSH (pay-to-witness-script-hash) address. cdbf909e935c855d3e8d1b61aeb9c5e3c03ae8021b286839b1a72f2e48fdba70 is the hash of a script that currently only the owner knows (until an output to that address has been spent). The bc1... representation is the bech32 encoded BIP142 address, which includes a checksum and a human readable currency identifier bc. It contains exactly the same information, i.e., a P2WSH script of the form `0 .


text:
What is DrahtBot on Bitcoin Core pull requests?
I see DrahtBot on a lot of Bitcoin Core pull requests (PRs) e.g. here. What does it do? Is it open source?

The primary use of DrahtBot is to add automated comments to a PR that list other PRs that conflict with the PR you are viewing. It was written and is managed by Marco Falke but it is not currently open source (it is "ugly" code and wasn't written with the intention to make it open source). Marco stated on IRC:

DrahtBot is basically a while true; ./label_rebase.py ; done, where the Python script just imports a Github API library and then tags all pulls needing rebase

There could be additional features added to it in future. One idea Jeremy Rubin had on IRC is an additional label that shows when the PR was last updated so reviewers could assess whether merge conflicts with master had been addressed before reviewing. Another idea Jeremy had was counting commit tagged ACKs for the current Git tip as a heuristic for reviewers and maintainers.


text:
Is it normal or acceptable behavior for a c-lightning plugin not to shut down after lightningd is stopped?
Is it normal if a plugin that I've written doesn't shut down (ie the Python process is still running) after I've called stop_ln (in the startup_regtest, start_ln setup)? Is the plugin opened as a subprocess? Should it handle a particular signal?
This was asked on Telegram.

In c-lightning, we give time to the plugin to shutdown, and after some time (30 seconds) if the plugin doesn't answer to shutdown we kill it.
However, some type of plugin can keep going because they can be run by a bash script or something else, and c-lighting kills only the bash script process and not the real project.
This happens with plugins written in Java or Kotlin, with the library clightning4j.
In conclusion, some of these plugins make a fake closing, in particular, if the plugin answer to the shutdown notification, c-lighting could not kill it, but assume that the plugin kills itself (with simple an exit(0)), this can be a use case where the plugin is badly written, but for sure have an example can help to debug the use case
This is the procedure that makes the trick https://github.com/SimonVrouwe/lightning/blob/81325097eddde6dfff911331c09963d5a316a6cc/lightningd/plugin.c#L2090

This is a draft answer from answers on Telegram. Alternative more detailed answers are welcome.
Plugins are subprocesses that are started by the main lightningd daemon. They work in cooperation with lightningd.
The plugin should stop when stdin is closed. The default behavior is that the plugin closes with normal signals.


text:
How do I use sqlite3 to view the contents of the wallet.dat file? Anywhere else to look for records of lost coins?
I think I've lost some testnet coins in my Core wallet and I'm not sure how. I do bitcoin-cli -testnet listwallets and it doesn't show any wallets for me to load. But I definitely had testnet coins a number of weeks ago in the Core wallet and I haven't deleted or edited the wallet.dat file manually.

Apart from looking in my wallet.dat file is there anything I should do?

I try to open my wallet.dat file using sqlite3 wallet.dat and then .dump but this returns an error code saying wallet.dat is not a database. What am I doing wrong here? How do I dump the contents of the wallet.dat file?

Might this wallet.dat be a pre-descriptors BDB wallet file? Only descriptors wallets use sqlite. What does getwalletinfo say?

@PieterWuille: Possibly... I have BDB installed and hence legacy wallet support should be built too. How do I do a listwallets for legacy/descriptors=false? I'm looking around https://github.com/bitcoin/bitcoin/issues/20160 but I haven't found instructions yet

getwalletinfo says No wallet is loaded

What does file say on the wallet.dat file?

wallet.dat: Berkeley DB (Btree, version 9, little-endian). So it is BDB. I'll try to dump the BDB file

Also: listwallets only lists loaded wallets. You need to load the wallet first before you can see it. Is the problem that funds are missing, or just that the wallet isn't loaded?

I can't remember what I named/labeled the wallet. So I don't know what to load. At the moment funds are missing or I just don't know how to access the wallet with the funds in. Is there no CLI command to list the possible wallets that are available to load?

Just look in $DATADIR/testnet3/wallets. I think there is a listwalletdir command too. If the wallet is elsewhere, you'll need to remember where you put the file...

Wait... you have the filename, how are you invoking file otherwise? If so, you can just loadwallet that filename.

Aha yes. I can get the filename from the testnet datadir and then loadwallet that file name . That works and I've located my testnet funds. I swear listwalletdir wasn't working until I loadwallet the file name. Was returning empty. Strange

With help from Pieter above (in the comments) I located my testnet coins.
The CLI command listwalletdir should return the available wallet names (also located in $DATADIR/testnet3/wallets) but I'm pretty sure this didn't work for me initially.
You can't use the CLI command listwallets though as this only lists wallets that have been loaded. If a wallet exists but hasn't been loaded it won't be listed in the output of listwallets.
If you know the name of the wallet (located in $DATADIR/testnet3/wallets) you can run bitcoin-cli loadwallet insert_wallet_name and then the wallet should show up in the output of bitcoin-cli listwallets.

I try to open my wallet.dat file using sqlite3 wallet.dat and then .dump but this returns an error code saying wallet.dat is not a database. What am I doing wrong here? How do I dump the contents of the wallet.dat file?

My wallet.dat file was a legacy BerkeleyDB Core wallet (can check with file wallet.dat) rather than a non-legacy SQLite Core wallet so obviously couldn't be viewed using sqlite3.


text:
Do you need a configuration flag to be able to obtain detailed debug logs?
Do you need to configure Bitcoin Core with --enable-debug to be able to obtain detailed debug logs when running bitcoind with -debug=category?

No they are orthogonal. --enable-debug creates unoptimized binaries which are more usable when you're trying to attach a debugger (e.g. gdb, lldb). It is unrelated to debug output. Debug output is controlled at runtime using -debug=X flags.
Thanks to the individuals who answered this on IRC.

Just a small elaboration on --enable-debug: it also enables more runtime checking. If all you need is the ability to run a debugger, consider specifying ./configure CXXFLAGS='-O0 -g3'.


text:
Why do testnet blocks have future timestamp?
I am playing experiments with testnet blockchain, and it seems like the best block is always set about 2 hours into the future.
For example, now, the block has timestamp 90 minutes into the future. I am not linking the block itself since it will be quickly outdated anyway, but you can look at https://testnet.blockexplorer.com and the newest block will always be into the future.
How is that possible? Shoudln't the network check the timestamps, if they are sensible? Also, if anyone can fake the timestamps, do they have any reason to exist at all?
This extends both to mainnet and testnet; however, I haven't seen it happen on mainnet. Why?

That "timestamp" varies depending on from where you access the website. If I access https://testnet.blockexplorer.com/block/0000000051b24881f7ab79c2f80e2706fa38e62da4279f9f297f76c0297233c3 from Germany, it says "Oct 7, 2016 1:13:20 AM". However, If I access it from France, it says "Oct 6, 2016 11:13:20 PM".

@UTF-8 it should always tell local time. It's strange, because - as far as I know - Germany and France have the same timezone.

Germany and France do share the same time zone. To test whether my statement is correct, just connect to a VPN or use to Tor or something. I find it strange in general to use localized time on an international website (but that might be due to my general dislike of localization). If localization of time is used (which it shouldn't!), the used time zone should be stated next to it.

@UTF-8 yeah, it's not great. But it's not really the issue I asked; if I try to look at the actual unix timestamps of the blocks, they are still 90 minutes in the future. You can report the time issue to bitpay on their github - https://github.com/bitpay/insight-ui

Testnet is frequently attacked, abused, due to the complete lack of value and proof of work. A piece of code which is intended to allow a difficulty 1 block is none has been found in 20 minutes also enables a person to "warp" forward and mine multiple in a row. If this is exploited over the difficulty adjustment, the entire chain difficulty is reset to difficulty 1.
The result is that it is trivial to make forks hundreds of thousands of blocks long, with insane timestamps that only vaguely match reality within the consensus rules. They're never going to make a lot of sense as a result. This doesn't happen on mainnet because the difficulty reset code doesn't exist there.

Ok, I understand that. Is there any plan to add difficulty to testnet ? Such behavior makes test environment quite far from reality. Also adding auto adjustable difficulty would make block times more stable, wouldn't it?

Note the temporary difficulty adjustment on testnet after 20 minutes of no block being found isn't the same as a time warp attack where miners try to create blocks with the earliest-possible time stamps for every block but the last block in a difficulty period (giving that block the latest possible time stamp).


text:
Does parent also pay for child?
One Bitcoin core mining policy is CPFP - child pays for parent. That is, transaction with high fee pays for its parent.
Does it also work the other way - that is, does transaction with high fee pays for child transaction that has low fees, given that they are both in the mempool? Or is the policy only "one way", from child to parent.

Does it also work the other way - that is, does transaction with high fee pays for child transaction that has low fees, given that they are both in the mempool? Or is the policy only "one way", from child to parent.

The policy is one-way: the parent doesn't pay for the child.
The child can't be included unless the parent is included, so effectively the miner can choose to include none of them, only the parent, or both the parent and the child.  The miner will choose what pays the most for its resources. This means sometimes it will include a low fee parent in order to be able to include a high fee child but it only works in that direction.

One Bitcoin core mining policy is CPFP - child pays for parent. That is, transaction with high fee pays for its parent.

This works because a high paying child transaction will incentivise a miner to also include a low-paying parent transaction so as long as the transaction fee for the entire transaction chain averages out to be worth more on a fee/byte basis.

Does it also work the other way - that is, does transaction with high fee pays for child transaction that has low fees, given that they are both in the mempool? Or is the policy only "one way", from child to parent.

This is a given since a high fee transaction is naturally incentive-compatible and a miner will include it regardless even if there's a low paying child. The only consequence is that the child transaction may never be selected to be included in a block if the fee/byte is insufficient.

I am not sure if we understand each other. If there is a transaction A with a high fee and transaction B with a low fee, and B is child of A, and both are in mempool, are the fees averaged for the chain A-B and the parent help the child be confirmed sooner?

No. Since at the time that the parent is included, the child may not have existed. So the the policy only applies "one-way". On top of that, there's no reason to consider the child transaction anyways because there's no dependency on the child transaction to reap the Transaction Fee rewards.


text:
Multisig address for website?
I am trying to sort out the use case of a published funding address on a web page, to which everyone can spend. Internally in our company, I want to avoid, that a single person can spend these funds. It shall require  more than one signature, to be able to spend the funds. I had the idea to use a multisig address, but this seems to be unsuccessful. The many stackexchange links don't cover this scenario, they all seem to cover how to spend from msig addresses...
When using a multisig adress, it looks like spends to this address requires the redeemscript. All examples I found use the redeemscript. So this is somehow a no-go for a multisig address on a webpage?
What I have done so far:
- I was thinking that "people" could send to the msig adress from a normal wallet (aka P2PKH script). That doesn't work out, as the pubkey script wouldn't find "true" on the stack. Given a standard pubkey script would require s.th. like this:
    DUP     HASH     PKH     EQ_VFY CHK_SIG
     |       |        |        |      |
     |       |        | PKHASH |      |
     |  PK   | PKHASH | PKHASH |      |
PK?  |  PK   |   PK   |  PK    | PK   |
SIG  |  SIG  |   SIG  |  SIG   | SIG  |  TRUE/FALSE

The first column (SIG and PK?) being the sigscript. For the multisig address there is no public key in the first column. For sure I could play with the redeem script at the very beginning, and hash it, to satisfy the "OP_EQUALVERIFY". But then the script wouldn't terminate "TRUE" at the end, cause it would leave the sig and a "hashed" hash on the stack.

I could publish the redeemscript. Disadvantage: this makes the user experience difficult
I could use a std. P2PKH address, and "forward" regularely the funds from the webpage P2PKH address to a multisig in the background. Disadvantage: with current fees, nearly idiotic, when only small amounts are spent. (Yes, I could write code to collect until spent amount >= tx fees ...)

Is there an easy (more intelligent) way to receive bitcoin payments on a website, that come with a condition to be spent only with multiple signatures?

There is no way to spend from a multisig without knowing the script, just like there is no way to spend from a public key without knowing the secret key.

Where do you see that multisig addresses need to have the redeemscript in order to spend to them? The redeemscript is only necessary for spending from a multisig address, there is no need for it when spending to one. Multisig addresses (aka P2SH addresses) begin with a 3. Your use case does not seem to require anything special, just a typical m-of-n multisig which many wallets can do.

Yes, thx! I had a false assumption in my first bullet point. I need to tell the sender, send me funds to my "3xxx" address (a P2SH address). I don't provide a  redeem script, I provide the hash of a redeem script, which is Base58check encoded with a prefix of '05':
base58check.Encode("05",  RIPEMD160(SHA256(redeemScript)))
The sender's wallet must know, that it cannot use P2PKH (OP_DUP, OP_HASH, PUBKEYHASH, OP_EQUALVERIFY, OP_CHKSIG), as I assumed in my example above. The wallet must use P2SH logic (OP_HASH160, P2SHAddress, OP_EQUAL) in the pubkey script.

and what happens on the stack, is well described here: https://bitcoin.stackexchange.com/questions/42521/pay-to-script-hash-execution

Are you saying it's difficult because the user would have to sign their own transaction manually? P2SH isn't really at a "typical" user level. For multisig to work as it's intended to, it assumes each potential signor knows how to sign a transaction. A website that would require it's users to sign their own P2SH transactions would have a pretty small target audience. Aside from building your own native desktop app that makes multisig signing easy for the average user, I'm not sure what other options you would have.

yup, multisig "as is" has a better use case for escrow services, where each party knows each other. On my website model, the users wouldn't go into a contract with my company, they just would like to spend. I was trying to secure the collected funds, so that no single person can run away with it. Maybe an elegant solution appears when lightning comes in (reducing fees).

I think I found a way to do what I need. I offer a QR code qith the address and the redeem script, each in its own line.
I understand that the wallets might not understand it, and there is no "automatic" creation of the transaction. But it is a step towards the right direction, sufficient for me.


text:
Current FPGA Competitiveness
I know CPUs and GPUs can't really compete with ASICs anymore but what about FPGAs?  Are they still reasonable?  Anyone have a ballpark idea of what kind of Gh/s (or Mh/s) has been done with something like a Spartan 6?

On https://en.bitcoin.it/wiki/Mining_hardware_comparison there is a report of 100 Mhash/s on a Spartan 6 device.  They don't list power consumption though, which is a critical question.  The other FPGA miners described there are 1-2 orders of magnitude less efficient in power than current ASICs, and 4-5 orders of magnitude more expensive per hashrate.

First a bit of perspective on FPGA mining.
Around 2011 some miners started switching from GPUs to FPGAs, (Field Programmable Gate Arrays), after the first implementation of Bitcoin mining came out in Verilog, (a hardware design language that’s used to program FPGAs).
The general rationale behind FPGAs is to try to get as close as possible to the performance of custom hardware while also allowing the owner of the card to customize it or reconfigure it "in the field".
By contrast, custom hardware chips are designed in a factory and do the same thing forever. FPGAs offer better performance than graphics cards, particularly on “bit fiddling” operations which are trivial to specify on an FPGA.
Cooling is also easier with FPGAs and, unlike GPUs, you can theoretically use nearly all of the transistors on the card for mining. Like with GPUs, you can pack many FPGAs together and drive them from one central unit, which is exactly what people began to do.
Overall, it was possible to build a big array of FPGAs more neatly and cleanly than you could with graphics cards. Using an FPGA with a careful implementation, you might get up to a GH/s, or one billion hashes per second.
This is certainly a large performance gain over CPUs and GPUs, but even if you had a hundred 141 boards together, each with a 1 GH/s throughput, it would still take you longer than 50 years on average to find a Bitcoin block at the current difficulty level.
Despite the performance gain, the days of FPGA mining were quite limited. Firstly, they were being driven harder for Bitcoin mining — by being on all the time and overclocked — than consumer grade FPGAs were really designed for. Because of this, many people saw errors and malfunctions in their FPGAs as they were mining. It also turned out to be difficult to optimize the 32‐bit addition step which is critical in doing SHA‐256. FPGAs are also less accessible‐you can't buy them at most stores and there are fewer people who know how to program and set up an FPGA than a GPU. Most importantly though, even though FPGAs improved performance the cost‐per‐performance was only marginally improved over GPUs. This made FPGA mining was a rather short‐lived phenomenon. Whereas GPU mining dominated for about a year or so, the days of FPGA mining were far more limited — lasting only a few months before custom ASICs arrived.
However- the cycle repeats itself.
It’s worth noting that several smaller altcoins have indeed used a
different puzzle than SHA‐256, but have seen a similar trajectory in mining as Bitcoin.
For ASICs there is still a long lead time between designing a chip and shipping it, so if a new altcoin uses an new puzzle (even just a modified version of SHA‐256), this will buy some time in which ASICs are not yet available. Typically, mining will proceed just at Bitcoin did from CPUs to GPUs and/or FPGAs to ASICs (if the altcoin is very successful, like
LiteCoin). Personally I'm quite interested in Zcash.
Much of the content for this answer was drawn from this excellent resource.


text:
What's the difference between BTC and BCH transaction capacity?
If Bitcoin can process x transactions per second, how many transactions per second can Bitcoin Cash process?

tldr - BTC = 3.33-6.66tx/second, BCH = 27 tx/second
For non-segwit-enabled Bitcoin nodes, transaction capacity is determined by Bitcoin's 1MB block size limit. A 1MB block will contain about 2000 transactions on average (see here). Because 1 block is mined every 10 minutes, this works out to roughly 3.33 tx/second.
BCH transaction capacity is determined by its 8MB block size limit. Because a given non-segwit BTC transaction should be roughly equal in size to its equivalent BCH transaction, this puts the transaction capacity of BCH at 8x that of BTC without segwit, or roughly 27 tx/second.
For segwit-enabled BTC nodes, transaction capacity is limited by the 4MB block weight limit (Note that block weight ≠ block size, see here for more info). It is estimated that roughly 2x the amount segwit transactions can be fit into a BTC block as can their non-segwit equivalents (see here and here). This would make the transaction capacity of a fully segwit-enabled BTC network roughly 6.66 transactions/second.
A few things worth noting:
1) Visa typically processes ~2,000 transactions/second and can process up to 24,000 transactions/second (see here).
2) As of Feb 2018, roughly 14% of BTC transactions are segwit transactions (see here)
3) On average, a serialized BTC block full of segwit transactions should take up ~2MB on disk.
4) Increasing the block size limit increases the amount of disk space and RAM required by miners to operate full nodes.
5) Generally speaking, the BTC community plans to increase transaction capacity via an overlay network (e.g. the lightning network) whereas the BCH community plans to increase transaction capacity by continuing to increase the block size.


text:
resetting blockchain and transactions won't clear stuck transaction
I'm using MultiBit Classic (sorry) and I have a stuck sent transaction due to low fee.
I keep resetting the blockchain and transactions in the application, but the transaction in question keeps showing up.
Should I be just waiting longer for the transaction to drop? Is constant opening MBC just making the problem worse?

related: https://bitcoin.stackexchange.com/q/54447/5406, https://bitcoin.stackexchange.com/q/53851/5406

Not sure if this is the real solution, but I exported my MultiBit Classic private keys and imported my address to blockchain.info wallet service.
Once I did that my transaction was confirmed within 24hrs.


text:
preventing fraud in a mining pool
If a group of people participate in a mining pool and person 1 finds a valid proof of work on their machine what prevents them from submitting this proof of work for themselves and not giving it to the pool to share between the participants?

The very last line of a block effectively contains:
Reward for Solving this Block: Add 12.5BTC to Account for [Mining Pool].

If the miner tried to change that line to read
Reward for Solving this Block: Add 12.5BTC to Account for [My Personal Account].

the altered line would change the block, which would change the hash, and their Proof of Work answer would no longer be valid.
So if a miner solves a block on behalf of the pool, they cannot submit that block for themselves; it will no longer be a valid solution.

This is correct in the essence, to be more specific though, the payout instruction is in the coinbase transaction.


text:
Litecoin Core wallet.dat
I am trying to recover my old LTC account. I still have the address (on blockchain I can still see the correct amount of LTC) and I still hold the old wallet.dat file, which I saved in the past.
I've downloaded LTC core in order to make a few transactions, but obviously I couldnt see the LTC balance. I've checked out this website and read I had to replace the wallet.dat file by the old wallet.dat file, which I did. Restarted LTC Core, but still can not see anything.
The synchronising seems to be up to date though.
What to do?
Many thanks!!

OK. I've just managed to solve the issue.

It appears I also had to rescan.
"C:\Program Files\Bitcoin\litecoin-qt.exe" -rescan
So for all those in the near future encountering the same prob as me; these were the steps I had to follow:

download LiteCore
synch (which took me 3 days)
replaced new wallet.dat by old wallet.dat
run -rescan as per above

Thanks Fred for answering your own question. Could you please post it as an answer instead of a comment? :)


text:
What is the purpose of Bitcoin timestamps
Why do we even need timestamps on the blocks?
Has it something to do with the consensus?

I think I found it out, but I'm not sure. I think timestamps are part of the difficulty adjustment of Bitcoin mining. To measure the time it took to mine the last x blocks. Can somebody confirm that?


text:
Cryptographic problem - locks

Three players, Bob, Alice and Ted are seated at a poker-table and are
  playing a game of Texas Hold’em. Bob is the dealer, and he generates a deck of 52 cards on his machine, only he can view the cards. Using Fisher-Yates /dev/urandom he shuffles the deck of cards, and then encrypts the deck with the same encryption key on each card, making the deck unreadable to anyone but himself. He then passes the now encrypted deck to Alice, who does the same thing: shuffles the deck of cards and then encrypts them. Finally, Alice passes the deck to Ted who goes through the same process.
  The deck is now in its final ordered state, 1 through 52, and this order does not change throughout the course of the hand. Ted passes the now 3x encrypted deck of cards back to Bob, who takes off his “shuffle lock” and now encrypts each individual card with a different encryption key: B1, B2….B52. He passes the deck to Alice, who does the same thing: removes her “shuffle-key” and encrypts the deck with a unique encryption key A1, A2….A52. Alice then passes the deck back to Ted, who completes this same process.

How is it possible that Bob can remove his encryption key of a string that is completely random for him, because Alice and Ted encrypted it?
Is this a feature of asymetric cryptography? If so a jsfiddle or so mayb be nice :)
I understand that you can encrypt something with a private key and decrypt it with a public key, but is it like that that this also works on strings that somebody else also encrypted (like in the example above)? So can I just simply remove my encryption?

This seems to be a question for https://crypto.stackexchange.com/

I'm voting to close this question as off-topic because it has nothing to do with Bitcoin.

This seems to be a variation of Shamir's 3-pass protocol.
I guess that the card trick requires commutative encryption to work, meaning that encrypting with a key K_1 and then with another key K_2 will produce the same result as encrypting with K_2 and then K_1.
Most public-key encryption algorithms do NOT have this feature (at least, RSA and Elgamal do not).


text:
Understanding signing messages with bitcoinjs-lib
I'm trying to understand what a specific line of code does when signing a message using bitcoinjs-lib. Here's the code:
var bitcoin = require('bitcoinjs-lib')
var bitcoinMessage = require('bitcoinjs-message')

var keyPair = bitcoin.ECPair.makeRandom();
//private key
var privateKey = keyPair.toWIF();
// Address
var address = keyPair.getAddress();

console.log(privateKey);
console.log(address);

privateKey = keyPair.d.toBuffer(32)
var message = 'your message'
var messagePrefix = bitcoin.networks.bitcoin.messagePrefix

var signature = bitcoinMessage.sign(message, messagePrefix, privateKey, keyPair.compressed)
console.log(signature.toString('base64'))

The line I'm curious about is this one:
privateKey = keyPair.d.toBuffer(32)

What exactly is this code doing and why is it necessary?
Thanks,
Connor

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.

Ah ha! That makes sense. Thank you for the great clarification.


text:
What is the difference (or relation) between a Bitcoin "Block" and a GPU workunit called a "Block"
I'm looking at OpenCL and GPU programming and see the term "Block" used to describe a unit of work sent to a GPU.
What is the relation between a Bitcoin Block and a GPU workunit called a block?
If there is a relation, was this intentional?

No, these two terms are completely unrelated.
Bitcoin block is a record of some or all of the most recent Bitcoin transactions that have not yet been recorded in any prior blocks.
GPU block is just an unit of organization of threads running in parallel. The threads running on GPU are organized in blocks, and threads belonging to same block have effective means of interacting with each other. The size of single block and number of blocks affect application performance, and optimal parameters differ between different hardware. Surprisingly, while most GPU miners are written in OpenCL and not in CUDA, the 'block' term comes from CUDA and OpenCL specs use 'workitem' to refer to this concept.


text:
How many different formats can a public address take?
I'm creating an offline index to report off of the block chain.  I plan on indexing each transaction based on the address displayed in the TX.
Are all addresses Base58?   I believe I also read about a compact address and an address type that was used in the beginning of the blockchain before Satoshi knew of/implemented address compression using Base58.

Small correction: address compression isn't part of bitcoin; it's part of OpenSSL.

I believe that the earlier format that you are referring to is the Hash160 which is formed by taking the sha256 of the public key followed by taking the ripemd160 of the result:

Hash160 = ripemd160(sha256(pubkey))

Further, what we usually refer to as a Bitcoin address is formed by first concatenating the Hash160 with four checksum bytes (to make it extremely unlikely that you can type the wrong address into a bitcoin client by accident). Then, a network identifier (0x00 for main network) is prepended and the string is base58 encoded:

address = base58(0x00 + Hash160 + checksum)

As you can see these two formats can easily be converted from one to the other. In addition the public key can be encoded either compressed or uncompressed. This results in two different addresses. However, since you can obtain the public key from neither the Hash160 nor the base58 address it is not possible to convert an address of an uncompressed public key to the address corresponding to the compressed public key, and vice versa.

Address version for the main network is 0, not 1. The rest is all true.

@Gigi you are right, fixed.

Not all transactions can be decoded into an address.
For example, this transaction could be claimed by putting the genesis block in the output script. That's not a standard address type, nor will it ever be.


text:
How is it possible that transactions can be added to a block currently being mined?
It seems counter-intuitive that the current block can be hashed and transactions can be added to it, however that is what this thread indicates.
Can someone help me connect the dots (not necessarily regarding that linked network attack) and understand how something under active computation can have its underlying data (list of transactions) changed?
In other words, if a tx isn't "bound" to a block via hashing, how do they relate to each other?

You're thinking that mining a block is a single long computing process, like computing the trillionth digit of pi or something like that. This is wrong. Each attempt at solving a block takes almost no time at all, and each attempt is independent of the others. Miners make many attempts every second. Each attempt has a very small chance of solving the block. It's a lottery, not a race. Modifying the block between attempts isn't a problem.
Another common misconception related to this is that everyone is working on the same block. This is also false. Every miner works on a different block.

I'll add to answer the OP's last question - the binding between a transaction and the work involved in finding a block is probabilistic. You could find a valid block with the transaction computing just one hash. But the probability of this is negligible, and the block proves that, on average, a lot of computational work was done acknowledging this transaction.

Mining is a series of independent attempts at finding a good hash for a block.
Since all attempts are independent from each other, modifying the block between one attempt and the other have no negative effect.

Just adding to the other answers. A transaction is still bound to a block and the block hash still has to match with the transaction included. However, when more transactions are added, the next attempt will create the hash of a different block. Using this new hash with the previous block will not be accepted by the network. So from what I gather, when attempting the hashing, they not only change the nonce but the data as well. The probability to succeed is the same either way.

One small addition to the other answers:
When a new transaction shows up, the miner stops for a moment, adds it to the transaction list, and starts mining again.  This slows him down because for a short while, he isn't mining.  But, according to the protocol, a client is supposed to accept the transaction history that includes the most transactions.  So, if the miner doesn't stop to add new transactions, he's at risk of succeeding but then someone else succeeding with a longer transaction list.  And then he doesn't get paid.
Edit: Oops, I thought that I read this somewhere but looking again, I didn't.  So why does a miner have any incentive to pause his mining and recalculate the block's hash?  Unless a transaction has a fee.

Eventually a miner will increment the nonce to a point where "extranonce" is needed.  At this point a new header is generated.  Often instead of using extranonce, it's possible to add transactions, regenerate the merkle root, and start the rehashing.  Yes, outside of fees, there isn't much incentive for a miner to include a tx that has a zero or too low of a fee.  Read Microsoft's paper on "Bitcoin and red balloons" for an alternate approach

I admit, that paper was too dense for me.  Is there a shorter explanation to solve the problem: How do we cause nodes not to hoard new transactions?


text:
How do I test that blockchain p2p replication is properly, securely exposed to the internet?
I have bandwidth and CPU to spare and I'd like to participate in the P2P nature of sharing the blockchain to other peers.  How can I properly, and securely participate?
Also, how can I test or verify my client that its working correctly?
Can I participate in the same (port 8333) blockchain replication if I run in server mode?

If you already have bitcoin up and running for some time, just open terminal/commandline window and run:
netstat -b (Windows)
netstat -tnp (Linux)
In the Local address column output, note whether there is port 8333 used with any bitcoind connection. If yes, you know that your node is reachable from internet and thus you are fully participating. Otherwise you need to allow connections to port 8333 from outside in your firewall, so that you don't have to depend on other nodes accepting connections. Also, healthy and up to date node is sending/receiving transactions quickly.
Other concerns, like security, are handled by bitcoind automatically, as it verifies all received data. The bitcoin-qt GUI is working in exactly the same way, I just presume you'd prefer running bitcoind as a background service.


text:
generating master public key from address
I want to know is it possible to generate master public key from an address? if not, what is needed to generate xpub key?

It's not possible.
An address is created though a hash160 (RIPEMD160) which is a one-way function.
Creating a xpub key (bip32 extended public key) requires the according pubkey and the chaincode.
Alternatively you can calculate an xpub from an xpriv (extended private key).