text:
What is bcoin and what is it used for?
I would like to know what bcoin is exactly because I'm confused about what it does.
Is it an API for communicating with the bitcoin blockchain?
Is it to build a wallet system for other users to have their own accounts and use it for transactions between one another?
Or is bcoin used for building a personal wallet account for mining bitcoin?
I hope to get full answer because the bcoin website is not clear in what it does (Enterprise-level   Bitcoin   and   Blockchain    libraries.  Built   for   businesses,   miners,   wallets,   and  hobbyists)
What exactly does it provide for businesses?
Let's say I want to build a business that provides wallet services for end users.. is bcoin what I need?

@RedGrittyBrick bcoin is an open source project, it does not offer any commercial services.

bcoin is a Bitcoin protocol library written in Javascript for Node.js
It offers a Full Node, SPV node, BIP44 wallet with multisig, address indexer, JavaScript events, and plenty of other features that make it a little different from Bitcoin Core. It is also written as a library and can be integrated into other applications or even websites without requiring a full node or wallet (for example, you can use bcoin to generate or validate addresses on your website).
It's important to also note that over the last two years the project has lost its funding and support and is only minimally maintained by a slim group of contributors. For example it only recently added support for bech32m addresses but it does not yet fully validate Taproot. This makes the bcoin full node a risky option.

Let's say I want to build a business that provides wallet services for
end users.. is bcoin what I need?

Yes if your stack is already mostly Node.js you will find the bcoin wallet very easy to understand and integrate. bcoin IS NOT A SERVICE, and does not offer a public API or anything like that. You need to install, manage, configure, maintain, and integrate the software entirely on your own.
To learn more, join us on slack (https://bcoin.io/slack-signup) or IRC #bcoin (Libera)

bitcoind, the official reference Bitcoin full node software, is not really designed for high-traffic business use (such as high-volume storefronts). bcoin is an alternative Bitcoin full node, specifically designed for merchant/business use. It is software you download and install just like the official Bitcoin client, and once set up it offers an RPC API interface just like bitcoind does, but it comes with additional features business users would find useful.
For example: If you have ever tried to use the official bitcoind to set up, for example, a custom merchant storefront, you'd notice that a lot of what seems like common functionality is either missing or clunky. For example, it's missing the ability to check for transactions for a hierarchical key, aka xpub; with the bitcoind rpc you would have to individually subscribe to addresses. And due to the lack of xpubs, consider that to offer a customer a Bitcoin address to pay to, the way to create a Bitcoin address through the bitcoind RPC API necessarily requires that the private key be stored on the server, which is discouraged for public-facing servers.
If you use bitcoind for your storefront, you would need additional software/code libraries that include features like xpubs -- certainly will involve more parts to maintain, may be messy, will certainly be an inefficient design, and will probably run into design limits. So many storefronts will choose to use software like bcoin instead, to avoid those problems.


text:
How install electrum for other users on Windows?
I installes electrum on admin usage.
For security reasons I do not want to use admin account to use the wallet (the computer has no other use). I want to use normal account.
So I created another account.
It turns out that electrum not available on other accounts.
So I reinstall electrum on that other account.
I still don't see electrum shortcut anywhere. Not in desktop not in start up menu. Nowhere.
That strategy works with Exodus but not electrum.
So I can't use electrum on the non admin account and I have no idea why. Installing it will delete existing electrum on previous accounts and reinstall it again, but do not put any shortcut.
It's simply not installed.
My guess is electrum actually installed on all devices and I need to do is to create that default shortcut. However, there is no easy way to do so.

What operating system are you using?

Per Electrum's github, this issue appears to be Windows-specific and is caused by pyinstaller (an upstream dependency) running under the admin context. This means that the installer will only create icons and shortcuts for the admin account, even when run from a user account.
Take a look at https://github.com/spesmilo/electrum/issues/3219 and https://github.com/spesmilo/electrum/issues/2558 for more information. This seems fixable, either from modifying how electrum uses pyinstaller or by submitting a fix to pyinstaller directly.

Or temporarily turn the non admin account into admin account

It looks like electrum is not designed to be installed on non admin account.
So I changed the account into admin. I install electrum and I got things working

For more context, this issue is Windows-specific and appears to be an upstream issue with pyinstaller. Take a look at https://github.com/spesmilo/electrum/issues/3219 for more information.

source: Stack Exchange

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

sort: votes


text:
What does a Bitcoin lightning private key look like?
I know bitcoin private keys start with a 5... But how does a lightning bitcoin private key look like? Say I wanted to printed it out as a paper wallet.

Elliptic curve private keys are just scalar integer values between 1 and n (The order of G). These can be encoded by any means, but usually they are just represented as 256-bit integers with whatever endianness the platform uses. If interpreted as an array of bytes, it is simply a 32 byte sequence.
The WIF (Wallet Import Format) of Bitcoin takes the 32 byte sequence, prepends a version byte, then takes the double-SHA256 to generate a checksum. The first 4 bytes of the checksum are appended to the version and private key bytes to make a sequence of 37 byte in total. This is then Base58Check encoded to produce the textual representation of private keys you're familiar with. The reason they all begin with 5 is because of the version byte.
There is no specification for the storage or import/export format of private keys in any of the lightning specifications and it is left up to implementers to decide how to store them, or how to or export them, if at all. You can use the same WIF format if you want, as Lightning uses the same curve as Bitcoin for its signing and key exchange.
Private keys are used for two different purposes in Lightning. The Lightning node itself has a single, fixed private key, which is used both to identify the node (by its respective public key), and to sign messages proving that they indeed originated from that node. It is also used to perform an authenticated key exchange when connecting to peers to prevent MitM attacks.
The other private keys used in Lightning are entries of a bitcoin wallet, used to sign transactions regarding the channel states, which are standard bitcoin transaction outputs.
However, just knowing the private key for a particular channel is insufficient to spend from that channel, as they are 2-of-2 multisig outputs, and both parties need to sign off the transaction to spend it. You therefore need to have knowledge of a spending transaction and a signature from the other party for that transaction in addition to your own private key for the channel.
It is clearly not much use to just export these private key on their own - you would need a more detailed format which contains all of the necessary parts to reconstruct the current state of the channel at minimum. In practice, you should have a record of all previous channel states too, so that you are able to construct a justice transaction if the other party attempts to broadcast an expired channel state, unless you've delegated this role to a watchtower, who should have a record.

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


text:
How does a hardware wallet interact with the bitcoin network?
I tried to understand the principle how the hardware wallet sends transactions to another Bitcoin address since it is not connected via full node to the blockchain.
I found this answer: How do hardware wallets communicate with the outside world?
Do I understand it right that every hardware wallet company like Ledger, Trezor or Shiftcrypto run a full node (e.g. bitcoind) in their company network and every hardware wallet, which is connected via the locally installed company's software at the sender's computer just sends a request to this full node like this?
bitcoin-cli createrawtransaction "[{\"txid\" : \"mytxid\",\"vout\":0}]" "{\"myaddress\":0.01}"

If so, do companies run it's own (closed source) full node which works in a different way? The only exception seems to be BitBoxBase from ShiftCrypto, which is open source.
But basically, the principle of the transaction handling between the hardware wallet and the blockchain is always the same, right? So every company run it's own full node. Only the transmission "protocol" between the hardware wallet and this full node is different and non-standardized, right?

No.
The hardware wallet company sometimes runs a node, but you could just as easily use a client like Electrum instead, and use Electrum nodes instead with your hardware wallet. All the node is used for is checking for transactions and publishing transactions.
The wallet software will use the xpub from the hardware wallet to check for payments people have sent to your addresses, using one of these remote full nodes.
Now, let's say you received some Bitcoin and you'd like to spend it. Your wallet software will generate an unsigned transaction on your computer, then it will send that unsigned transaction to your hardware wallet for it to sign, then the wallet software will use the full node to publish this signed transaction.
So like the answer you linked to pointed out, all the full nodes are used for is 1) querying for existing blockchain data, and 2) publishing (NOT creating) an already signed raw transaction.

Do I understand it right that every hardware wallet company like Ledger, Trezor or Shiftcrypto run a full node (e.g. bitcoind) in their company network and every hardware wallet, which is connected via the locally installed company's software at the sender's computer just sends a request to this full node like this?

No.
At the basic level, a hardware wallet is just a device which can create and store private keys, and sign transactions, all in an offline environment. How that device interacts with the wider network is variable, but there is no requirement to use the node services of the hardware wallet manufacturer (note that doing so is generally not going to be good for the user's privacy).
Note that the Hardware Wallet Interface is a tool that can be used to interact with a hardware wallet, directly from your own bitocin-core node. The github page linked specifically mentions 8 different models of hardware wallet that are currently compatible.


text:
Is Bitcoin deflationary and inflationary at the same time?
I was wondering as Bitcoin is represented in the public and media as a deflationary currency (for more adept media as payment protocol). Is it really deflationary?
Deflation is described on Wikipedia as:

In economics, deflation is a decrease in the general price level of goods and services ...
  This allows one to buy more goods with the same amount of money over
  time.

Inflation is described on Wikipedia as:

Economists generally believe that high rates of inflation and hyperinflation are caused by >an excessive growth of the money supply.

At the moment there is really an excessive growth of Bitcoin supply - in the past 4 years there was mined over 12 millions of bitcoins and will continue
 with every block rewarded by c. 2140 when all bitcoins are expected to be mined. So there will be only transaction fees as block rewards, which will  end the growth of the units supply.
Can we consider Bitcoin as inflationary and deflationary currency until 2140, because there are still new bitcoins generated until c. 2140?

It appears to me that while the money supply of Bitcoin is growing, the price has been stable or going up. Therefore, "excessive growth" doesn't describe it fittingly, i.e. Bitcoin is not inflationary.

This is a tough question.
I'd consider Bitcoin as being just deflationary. Why?
Because, instead of thinking about mining as "adding new currency", you could consider that mining is just "enabling" more coins each block from the 21 million total coins. Everyone knows that ultimately there will be 21 million coins, just not all of them are spendable.
Quoting Wikipedia on inflation:

In economics, inflation is a persistent increase in the general price level of goods and services in an economy over a period of time.

It's clear that the increase of the amount of Bitcoin in circulation is not persistent. I ends. We all know when and why and how much there will ultimately exist.
That said, why is Bitcoin deflationary. Again quoting Wikipedia:

Deflation occurs when the inflation rate falls below 0% (a negative inflation rate).

One can argue that after the last block reward has been paid, the amount of bitcoins will stay the same. That's not true. Now already, bitcoins are getting lost. People lose bitcoins every day by losing the private keys. So, bitcoins will become scarcer whenever the rate at which people lose them tops the generation rate through mining.
So ultimately, the number of spendable bitcoins will decrease, but firstly, as bitcoins tend to increase in value, people will probably become more careful with them over time. And second, bitcoins can be divided to the order of 10^8, so even when there is only a fraction of the 21 million bitcoins left, people will be able to spend regular amounts using the bitcoin protocol.

The answer to this question depends on the terminology used. "To inflate" normally means "to increase the volume". "To deflate" is the opposite.
In this sense, bitcoins were inflationary in 2013 (the inflation was ca 15%) and will be inflationary in 2014 as well.
At the same time, bitcoins were undergoing hyperappreciation in 2013 (bitcoin appreciation relative to USD was 5783%).
Also, bitcoins were undergoing hypermonetization in 2013 (bitcoin monetization, i.e., increase in liquidity expressed in USD was 2995%).

Bitcoin is an inflationary currency. Again from Wikipedia:
"In economics, inflation is a persistent increase in the general price level of goods and services in an economy over a period of time."
Inflation/Deflation is the measurement of price levels. The Bitcoin community consistently gets this wrong in that they are referring to the unit of measurement when discussing inflation/deflation.
With that said, Bitcoin is infinitely divisible and as the demand begins to outpace supply you will see:
A) Inflation in the price value of Bitcoin, and
B) The units of Bitcoin required to buy a good decrease.
To recap, we do not consider changes in the number of units required to buy something inflation or deflation. Inflation/Deflation only refers to price levels.
Thank you.

Bitcoin is deflationary, like Gold or any other natural resources. The value of Bitcoin is limited and it will be exhausted by 2140. This limited supply of bitcoin will make sure that it will become rarer and precious with time. Its value increases as time passes. Now, as the value increases, it will encourage people to hoard it and people will not spend it. This will pull out the Bitcoins from the economy, and increases its value. So you will get more product or services for the same number of Bitcoins, ie. value of good and services decrease.
This is different from an inflationary currency based system where government pump more money in the economy and this, in turn, leads to less value for currency and price increase.
Both of these type if the economy has pros and cons.

There is no guarantee that Bitcoin's value will keep increasing over time.

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


text:
Have I backed up my wallet sufficiently?
I'm trying to make sure I'm backing up my bitcoin wallet sufficiently. I only have about $60.00 worth, so I'm not looking for super secure encryption or anything. I just want to make sure I can restore my wallet if my computer crashes.
Anyway, I'm using MutliBit. I went to Tools -> Export Private Key.  I then selected a location on my network drive, added a password, and hit the export button.
If something happens to my computer, I could just redownload the multibit client and install it on another computer, and then use the Restore Private Key function and direct it to the file on my network drive to restore my wallet.  Is that correct?

Your premise is correct, although you are also correct it is not a "super secure" solution.

I would recommend making copies or your wallet.dat file and storing it in several secure places. Also you should encrypt it.

You are safe if you don't use that wallet, if you do you should backup whenever you do a transaction or coins will be lost.

@Loourr, there is no “wallet.dat” in Multibit. The file is called multibit.wallet

@YoMismo: Does MultiBit not use a key pool or something similar to allow keys to be backed up before they are used? That's kind of surprising.

I don't know about multibit, but if pool is limited as it is bitcoin-qt, when that pool is gone new keys are generated, if you backup just before the new ones are generated you will miss those and some of your coins will be lost in new transactions.

I suggest to use paper wallet with encrypted private key, so called BIP-38.
Fundamentally, the only way to loose the access to those funds is by physically destroying the paper/forgetting the passphrase. Note that, keeping paper safe is much easier than keeping safe wallet.dat in computer that is connected to internet.
Following guide takes 2 minutes and is 100% secure if enhanced by using computer that has never been and never will be online - can be formatted before and after creation of cold storage.

Go to: bitaddress.org
Download .zip file on the buttom of page or from GitHub repository
Extract .zip and run file bitaddress.org.html
Move your mouse to generate random entropy for generating new bitcoin address
Navigate to Paper wallet tab
Fill 1 address to generate and check BIP-38 Encrypt checkbox
Enter the passphrase (only you would know and need to remember)
Click generate, and print this on the paper
Scan the Load & verify Public key and transfer there funds from MultiBit
You do not even need to keep the paper safe now, since person who would scan the Spend QR need to know the passphrase which is only in your brain

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


text:
ATM paper wallet mistake
I purchased Bitcoin from a BTC ATM many years ago and got a paper wallet receipt with pup and Priv keys.
I swept the funds into Mycelium wallet and I then thought I was sending to someone else but somehow I ended up sending the full balance right back to the paper wallet.
I already tossed the paper wallet after I had the funds swept. It's a P2PKH, so my question is:
If I still had the mycelium wallet and the Tx details were there, would there be a way to get the funds sent back to that mycelium wallet?

Since the purpose of sweeping is to move all funds out of the control of a private key, it seems unlikely that the wallet developers perceived any need for their wallet to retain the emptied private key.
Which suggests to me that the answer is likely to be no.


text:
My passphrase in Bitcoin Core is not recognised with parsing JSON error
I am currently in a bad situation, as I can't access my wallet on Bitcoin Core anymore. The wallet passphrase I have chosen does not seem to not work.
When I try it, I see the following message: "Error: Error parsing JSON:est"
I have the following characters in the passphrase:

spaces
/ character
letters with accent

Any help is appreciated as my savings are at stake :(

Are any of your backups of the wallet earlier than the passphrase?


text:
ERROR: AcceptBlock: high-hash, proof of work failed (code 16)
I followed this medium link to create a coin just like bitcoin . https://medium.com/@jordan.baczuk/how-to-fork-bitcoin-c39139506443
Based on this tutorial i update DEFAULT_MAX_TIP_AGE to int64_t nMaxTipAge = DEFAULT_MAX_TIP_AGE * 4000; but it does not work, i did not able to mine block but when i add -maxtipage=432000000 to my command line daemon then mining work i was able to mine genesis block . but then i thought it would be better if i can create my own geneisis block.
so i followed this link : How can I create a new Genesis Block?
I made changes to pszTimestamp, nTime and nNonce , hashGenesisBlock and hashMerkleRoot.
I was able to run the daemon without any assert issue . First i got this error

ERROR: ReadBlockFromDisk: Errors in block header at
  CBlockDiskPos(nFile=0, nPos=8) 2018-11-08T10:12:47Z *** Failed to read
  block

Then after running command line daemon with -reindex . the previous error vanishes but got a new error

ERROR: AcceptBlock: high-hash, proof of work failed (code 16)

How can i resolve this issue
EDIT:
Based on the suggestion given by @JBaczuk . I used genesisgen to generate block information
https://github.com/liveblockchain/genesisgen
CMD Syntax:
./genesis [options] <pubkey> "<timestamp>" <nBits> <startNonce> <unixtime>

My CMD:
./genesis 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f "NDTV 08/Nov/2018 India Wants To Locally Manufacture, Export Bullet Train Coaches" 486604799 2083236893 1541690605

OUTPUT:
nBits: 0x1d00ffff
startNonce: 2083236893
unixtime: 1541690605

Coinbase: 04ffff001d01044c504e4454562030382f4e6f762f3230313820496e6469612057616e747320546f204c6f63616c6c79204d616e75666163747572652c204578706f72742042756c6c657420547261696e20436f6163686573

PubkeyScript: 4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac

Merkle Hash: 94b4efc7769b39ccad3ad6cebbde8ad9d74e837e19978d9acc2ae499609d895d
Byteswapped: 5d899d6099e42acc9a8d97197e834ed7d98adebbced63aadcc399b76c7efb494
Generating block...
124397 Hashes/s, Nonce 20632283897
Block found!
Hash: 000000004c7d908bd3c911a21b849d3cdca124131d2fb8a1af009698742ad672
Nonce: 2063257030
Unix time: 1541690608

Changes in code:
static CBlock CreateGenesisBlock(uint32_t nTime, uint32_t nNonce, uint32_t nBits, int32_t nVersion, const CAmount& genesisReward)
{
    const char* pszTimestamp = "NDTV 08/Nov/2018 India Wants To Locally Manufacture, Export Bullet Train Coaches";
    const CScript genesisOutputScript = CScript() << ParseHex("04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f") << OP_CHECKSIG;
    return CreateGenesisBlock(pszTimestamp, genesisOutputScript, nTime, nNonce, nBits, nVersion, genesisReward);
}

......
......
......
genesis = CreateGenesisBlock(1541690608, 2063257030, 0x1d00ffff, 1, 50 * COIN);
consensus.hashGenesisBlock = genesis.GetHash();
assert(consensus.hashGenesisBlock == uint256S("0x000000004c7d908bd3c911a21b849d3cdca124131d2fb8a1af009698742ad672"));
assert(genesis.hashMerkleRoot == uint256S("0x94b4efc7769b39ccad3ad6cebbde8ad9d74e837e19978d9acc2ae499609d895d"));

I got this assertion error:
chainparams.cpp:125: CMainParams::CMainParams(): Assertion `genesis.hashMerkleRoot == uint256S("0x94b4efc7769b39ccad3ad6cebbde8ad9d74e837e19978d9acc2ae499609d895d")' failed.
Aborted (core dumped)

Downvoted. We have many questions regarding programming issues when creating a new altcoin. I don't believe such questions benefit a general audience, and this is a Q&A site, not a place for support. Furthermore, as a learning experience, contributing to an existing project is far more valuable.

There obviously is an audience, since there are many questions, but is stackoverflow the place for these? I have no preference, I just wonder what to suggest for help.

@PieterWuille . Inorder to contribute to existing project . i have to learn how things work in code level so i did little changes to existing bitcoin code and trying to understand  the concept.

These questions are helpful to others @PieterWuille

This is because you didn't mine the block, i.e. you didn't search for a nonce that results in a block hash less than powLimit (the initial difficulty target) defined in src/chainparams.cpp consensus.powLimit("00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff"), for mainnet. To do this:
Serialize the block header. Concatenate (in this order, little endian, hex format) the version, previous block hash, merkle root, unix epoch time, difficulty target (bits), and nonce. Then calculate the HASH256 or the SHA256(SHA256()). If it is not less than powLimit you must change the nonce and try again, keep doing this until you are successful, this is mining.
There are scripts out there to do this, for example: https://github.com/liveblockchain/genesisgen
Update (example from question above):
Example usage of genesisgen
./genesis [options] <pubkey> "<timestamp>" <nBits> <startNonce> <unixtime>

./genesis 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f "NDTV 08/Nov/2018 India Wants To Locally Manufacture, Export Bullet Train Coaches" 486604799 2083236893 1541690605

    nBits: 0x1d00ffff
    startNonce: 2083236893
    unixtime: 1541690605

    Coinbase: 04ffff001d01044c504e4454562030382f4e6f762f3230313820496e6469612057616e747320546f204c6f63616c6c79204d616e75666163747572652c204578706f72742042756c6c657420547261696e20436f6163686573

    PubkeyScript: 4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac

    Merkle Hash: 94b4efc7769b39ccad3ad6cebbde8ad9d74e837e19978d9acc2ae499609d895d
    Byteswapped: 5d899d6099e42acc9a8d97197e834ed7d98adebbced63aadcc399b76c7efb494
    Generating block...
    124397 Hashes/s, Nonce 20632283897
    Block found!
    Hash: 000000004c7d908bd3c911a21b849d3cdca124131d2fb8a1af009698742ad672
    Nonce: 2063257030
    Unix time: 1541690608

You need to use the Byteswapped merkle root and the block hash in the assertions and the newly found nonce in the genesis block creation functions.

Thanks for your answer. I will try and let you know

The genesisgen example has two nonce: startNonce and Nonce which should i use in my program

You can just use 0 as the start nonce, unless you already know the nonce :)

It does not work . i got me assetion error. i have updated my question . please check

I believe the merkleroot is wrong endianess, try using the Byteswapped: 5d899d6099e42acc9a8d97197e834ed7d98adebbced63aadcc399b76c7efb494

Thanks it works . I was able to generate genesis block without any issue :)

Also please update your answer


text:
Crypto credit/debit card provider - Process of Crypto to Fiat
How do crypto credit/debit card provider organise their crypto to fiat exchange process?
I thought that they would manually exchange crypto to fiat on exchanges through a bot. However, this would not be instant, right? Even if they used an exchange that allows "market trading" and a bot doing the exchange, I cannot see how that would be instant.
Any ideas how the card providers solved the problem?
EDIT: Could it be that they buy crypto in bulk, thus there does not happen an exchange at the very moment (probably OTC)?

What card providers are you talking about? I don't think any major ones support cryptocurrencies at all.

Yes, the major ones do not support it. I am talking about the specialised one: Xapo, Shift, BitPay to name a few.
The payment processor is either Mastercard or Visa.

there are many card provider services. Wirex is one of the popular bitcoin debit card provider. I found this article with list of best bitcoin debit card providers
There are exchanges inbuilt within the wallets to convert cryptos into eachonther as well as they support crypto to fiat exchange.

I am talking about the specialised one: Xapo, Shift, BitPay

Xapo
Closed
BitPay
Pre-paid
Shift
It seems you have to have a Coinbase account and authorize Shift to make some use of it. Presumably Shift don't authorise any Visa transaction for which your Coinbase account lacks adequate funds? If Shift have their own Coinbase account they can presumably instantly transfer any amount from any other custodial wallet at Coinbase that they have been authorised to use by the customer.


text:
Implementation of getdata
I am confused about how getdata() is actually implemented at full nodes.
Suppose a full node receives a getdata() request with MSG_BLOCK flag and a hash H of some block B. Then would it simply look up H into its levelDB database to fetch B from its disk and return it to the caller (in constt time) or something more expensive is done?
Can I also get some references to read about it?

There isn't even a database lookup in Bitcoin Core. All blocks and mempool transactions are indexed by hash in memory. It's typically just serializing from memory, or one disk read directly sending disk data to the network.


text:
Block Explorers search on TxID
As per this post bitcoin nodes do not maintain an index from addresses to TxIDs and hence querying for the unspent tokens by addresses essentially involves traversing the entire UTXO set.
However, the blockchain explorers enable search by addresses not just on the unspent outputs but on the entire blockchain. They list all the transactions that involve an address. I have the following questions:

How do the block explorers do the search by addresses -- do they search the entire blockchain at query time, which is very inefficient, or do they maintain some sort of index which they update iteratively?
If they maintain an index, it looks like the index will be pretty huge since it will always keep on growing. So how big is the index currently?
Also, can the blockchain nodes currently do such a search (of course efficiently)?

How do the block explorers do the search by addresses -- do they
  search the entire blockchain at query time, which is very inefficient,
  or do they maintain some sort of index which they update iteratively?

The block explorers parse all of the transactions one by one and create their own database and index using the address generated from the scriptPubKeys. This is expensive the first time, but not as bad when it just needs to stay up to date.

If they maintain the index, it looks like the index will be pretty
  huge since it will always keep on growing. So how big is the index
  currently?

It is at least as big as the blockchain itself (assuming they are storing all of the data, raw blocks, etc.). As for the specific number, you'd have to ask the specific block explorer.

Also, can the blockchain nodes currently do such a search (of course
  efficiently)?

If you enable -txindex flag you can search by txid but Bitcoin-core offers no such functionality (search by address) unless it is one of your wallet addresses.


text:
Arbitrary access to already confirmed transactions
This link mentions that
"[getdata] can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed..."
But can't an SPV node do the following to have the arbitrary access to a transaction T (I am assuming that the SPV node knows the block hash H of the block B containing T):

set a bloom filter using filterload for T at some full node
send getdata request with type MSG_FILTERED_BLOCK and block hash H
then in response, the full node will generate two messages for the SPV node: first, a merkleblock of B; and second, the transaction T (as mentioned here and here)

Doesn't this mechanism actually gives arbitrary access to transactions?

That only works for a node which has transaction-index activated. If it doesn’t, it would not offer this service during the p2p handshake (version message indicates available services), and it would not be possible with this peer.

That is based on the minimum indexing required to run a full-node.
A getdata msg to peers can only request TX resources in mempool (valid, unconfirmed). Not all full-nodes index confirmed transactions. UTXO and mempool tx are necessarily indexed for validation and tx propagation/block template creation respectively.
Confirmed transaction are supplied as part of getdata request with blockhashes. Blocks are indexed by all full-nodes. (Since new block-headers must reference previous headers, even if they are branch-extending, vs strong-chain extending)
Correction(see comment below):

This is not correct. The approach suggested by OP (using BIP37) would work, but it is highly inefficient (it requires the full node scanning through the whole chain, but does not need an index). That's why of the reasons why BIP37 is being discouraged.

Wow, an entire chain scan? Thanks for the correction - I would never have thought that this is done without index.

It's no different from a full blockchain download, but while giving a filter first. The BIP37 bloom filter approach can't be easily sped up using an index anyway (as an index would inherently not have false positives, and thus leak a lot of privacy). See BIP157 for a more modern approach (which uses some precomputed data, but still not an index).


text:
SPV clients and full nodes
Suppose an SPV client goes offline at block X (meaning it has block headers until block X) and then comes back online when the blockchain is at block Y. At that point, it needs to resynchronise its UTXO set. So, it does the following: (1) get the block headers of blocks X to Y; (2) construct a bloom filter for its addresses and request a full node to send all the transactions matching this bloom filter from block X to Y; (3) the full node does so and if a match is found, sends the transaction data along with a merkle proof to the SPV client; (4) SPV client verifies the proof and if it's correct updates its UTXO set accordingly.
Is this the way things actually happen?
If yes, then my question is then why can't the full node simply do the following: (1) send its UTXO set to the SPV client; (2) SPV client then filters the UTXOs of its interest and put those UTXOs in its own UTXO set.
Is this method not followed because it doesn't involve any verification from SPV client and this the full node can give the SPV client a totally wrong UTXO set?

Welcome to Bitcoin.stackexchange. In general, it is best to ask one question at a time. The more questions you ask at the same time, the less likely anyone is to attempt to answer it. I could answer parts of this but I won't because I an unsure about other parts and I don't want to write a partial answer. See the [help] and how do I ask a good question

Is this the way things actually happen?

Yes

If yes, then my question is then why can't the full node simply do the following: (1) send its UTXO set to the SPV client; (2) SPV client then filters the UTXOs of its interest and put those UTXOs in its own UTXO set.

The UTXO set is large and a proof for every UTXO would be required. Proofs for every UTXO would be expensive to build and an extremely large amount of unnecessary data would be sent over the wire thus consuming network bandwidth that could be better used elsewhere.


text:
Developer example for p2sh-multisig sees sendrawtransaction consistently return the "non-mandatory-script-verify-flag" error [Solved]
Overview
The following transaction: 0200000000010121c787a1ca54292403d4200d6953ee0edcd4a1d33721a09938f5d5e067e9c70600000000232200205d577278a6dfefffaa4e04ef23fd1172e923f9e7b4949f991b3d7f2af89abb83ffffffff01993a00000000000017a9144920d433d073267b904ae23df3b15ea47aec950387040047304402202c9946f1d50a974f3b7cf24a99002f3f3ca18af7b54939bf2ec1acf6f5528b07022029aaa63fde914735b8e92c202ce3d4b02ea8ded1d2b47821670dd3c6d8dcb02b0147304402201e5e933e674f7e4597c1066b48cdb4ca1c7382235b53d411608c2e3a22a31df7022022fc673d696987146effcbb9ce43265ab9ee19da05eaef0bb35ced729fe9592501695221036ef3ee62456676a49b3087df3f0d804eb09bfcfa95ca606465bee5cfeab4da98210386518595790f10fa1915bb119a0b41d96a380eeb3f3a76ae0694acc9fd2fb333210371d090dd98316a9f8f63c1d925b42cf157f265d1eff84b65620629914b43019c53ae00000000
when passed to sendrawtransaction(), generates the following error:
error code: -26
error message:
non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) (code 64)
The bitcoin source seems to suggest the transaction's rejected for being non-standard:
my transaction was based on the developer example at https://bitcoin.org/en/developer-examples#p2sh-multisig which I thought would be standard, and the error occurs on testnet where I thought the related isStandard() checks are turned off.
I am looking for insight into where I've managed to go wrong!
Detail: code, output, conf files, versions, transaction decode, redeem script decode
I have rewritten the developer example as a self-contained bash script that resets regtest back to a known state then works through the snippets, or attempts to run on testnet. Where necessary, the calls have been adjusted to reflect API changes such as signtransactionwithkey vs signtransaction:
#!/bin/bash
#
# This code to implement p2sh-multisig example as worked through at
# https://bitcoin.org/en/developer-examples#p2sh-multisig
#
echo "[Setting up run ...]"
DEBUG=true
USE_REGTEST=false  # If false, use testnet
ADDRESS_TYPE="p2sh-segwit"
BITCOIND_HOMEDIR="/home/bitcoind"
BITCOIND_CONFDIR=$BITCOIND_HOMEDIR"/.bitcoin"
if [[ "$USE_REGTEST" = "true" ]]
then
    AMOUNT0="49.99900000"
    AMOUNT1="10.00000000"  # Differs from example to forestall float and rounding issues
    AMOUNT2="9.99800000"
    REGTEST_PARAM="-regtest"
    REGTEST_DIR=$BITCOIND_CONFDIR"/regtest"
    BITCOIND_CONFFILE=$BITCOIND_CONFDIR"/regtest.conf"
    TEST_SPEND_FROM_NONCOINBASE=true  # Test if it matters that funds were generational
else
    AMOUNT0="49.99900000"  # Unused on testnet
    AMOUNT1="0.00030001"
    AMOUNT2="0.00015001"
    REGTEST_PARAM=""
    REGTEST_DIR="/dev/null"
    BITCOIND_CONFFILE=$BITCOIND_CONFDIR"/testnet.conf"
    TEST_SPEND_FROM_NONCOINBASE=false
fi
TXFEE="0.00013000"
BITCOIN_CLI="/usr/local/bin/bitcoin-cli -conf="$BITCOIND_CONFFILE" "$REGTEST_PARAM
BITCOIN_DAEMON="/usr/local/bin/bitcoind -conf="$BITCOIND_CONFFILE" "$REGTEST_PARAM" -daemon"
TEST_PUBLIC_KEYS_ONLY=true  # Public keys vs Addresses test

#
# Get regtest network back to a known state: stop if going, unlink regtest directories,
# restart, and generate first 101 blocks to get 50btc in funds. Give a short period
# to allow cleaning up etc. The 101 is important as it limits our balance to 50btc
if [[ "$USE_REGTEST" = "true" ]]
then
    $BITCOIN_CLI stop
    sleep 1
    rm -rf $REGTEST_DIR && $BITCOIN_DAEMON
    sleep 2
    $BITCOIN_CLI generate 101 >/dev/null
fi

#
# I see references such as at https://github.com/bitcoin/bitcoin/issues/7277
# that one cannot send funds from coinbase to p2sh addresses over regtest.
# This code to send almost whole balance over such that a later spend to
# fund p2sh address cannot but come from a non-coinbase address
# Ignored on testnet
if [[ "$TEST_SPEND_FROM_NONCOINBASE" = "true" ]]
then
    NONCOINBASE_ADDRESS=`$BITCOIN_CLI getnewaddress $ADDRESS_TYPE`
    TXID=`$BITCOIN_CLI sendtoaddress $NONCOINBASE_ADDRESS $AMOUNT0`
    if $DEBUG
    then
    echo "Sending coinbase funds to new key"
    echo "[NONCOINBASE_ADDRESS]: "$NONCOINBASE_ADDRESS
    echo "[TXID               ]: "$TXID
    echo "-----"
    fi
fi

echo "[...Create and fund a 2-of-3 multisig transaction...]"
#
# Create the addresses we will use
NEW_ADDRESS1=`$BITCOIN_CLI getnewaddress $ADDRESS_TYPE`
NEW_ADDRESS2=`$BITCOIN_CLI getnewaddress $ADDRESS_TYPE`
NEW_ADDRESS3=`$BITCOIN_CLI getnewaddress $ADDRESS_TYPE`
if [[ "$DEBUG" = "true" ]]
then
    # Example says addresses start with m, this code sees them start
    # with 2. Problem?
    echo "Creating new addresses:"
    echo "[NEW_ADDRESS1]: "$NEW_ADDRESS1
    echo "[NEW_ADDRESS2]: "$NEW_ADDRESS2
    echo "[NEW_ADDRESS3]: "$NEW_ADDRESS3
    echo "-----"
fi

#
# Obtain one public key - not sure why. To prove we can
# use either address or public key to create the
# multisigaddress? To show how to obtain the data for
# passing on to others? ("all of which will be converted
# to public keys in the redeem script.")
# NB: validateaddress in example superceded by getaddressinfo
if [[ "$TEST_PUBLIC_KEYS_ONLY" = "true" ]]
then
    RV=`$BITCOIN_CLI getaddressinfo $NEW_ADDRESS1`
    NEW_ADDRESS1_PUBLIC_KEY=`echo $RV | sed 's/^.*"pubkey": "//' |
                      sed 's/".*$//'`  # Checked
    RV=`$BITCOIN_CLI getaddressinfo $NEW_ADDRESS2`
    NEW_ADDRESS2_PUBLIC_KEY=`echo $RV | sed 's/^.*"pubkey": "//' |
                      sed 's/".*$//'`  # Checked
fi
RV=`$BITCOIN_CLI getaddressinfo $NEW_ADDRESS3`
NEW_ADDRESS3_PUBLIC_KEY=`echo $RV | sed 's/^.*"pubkey": "//' |
                  sed 's/".*$//'`  # Checked
if [[ "$DEBUG" = "true" ]]
then
    echo "Obtain public key per address:"
    if [[ "$TEST_PUBLIC_KEYS_ONLY" = "true" ]]
    then
    echo "[NEW_ADDRESS1_PUBLIC_KEY]: "$NEW_ADDRESS1_PUBLIC_KEY
    echo "[NEW_ADDRESS2_PUBLIC_KEY]: "$NEW_ADDRESS2_PUBLIC_KEY
    fi
    echo "[NEW_ADDRESS3_PUBLIC_KEY]: "$NEW_ADDRESS3_PUBLIC_KEY
    echo "-----"
fi

#
# Obtain the address and redeem script needed to obtain the funds.
# NB: createmultisig in example superceded by addmultisigaddress
if [[ "$TEST_PUBLIC_KEYS_ONLY" = "true" ]]
then
    RV=`$BITCOIN_CLI addmultisigaddress 2 '''
      [
       "'$NEW_ADDRESS1_PUBLIC_KEY'",
       "'$NEW_ADDRESS2_PUBLIC_KEY'",
       "'$NEW_ADDRESS3_PUBLIC_KEY'"
      ]'''`
else
    RV=`$BITCOIN_CLI addmultisigaddress 2 '''
    [
      "'$NEW_ADDRESS1'",
      "'$NEW_ADDRESS2'",
      "'$NEW_ADDRESS3_PUBLIC_KEY'"
    ]'''`
fi
P2SH_ADDRESS=`echo $RV | sed 's/^.*"address": "//' |
           sed 's/".*$//'`  # Checked
P2SH_REDEEM_SCRIPT=`echo $RV | sed 's/^.*"redeemScript": "//' |
             sed 's/".*$//'`  # Checked
if [[ "$DEBUG" = "true" ]]
then
    echo "Obtain p2sh address and redeemScript:"
    echo "[P2SH_ADDRESS      ]: "$P2SH_ADDRESS
    echo "[P2SH_REDEEM_SCRIPT]: "$P2SH_REDEEM_SCRIPT
    echo "-----"
fi

#
# On regtest, send funds from the first 50btc block we can spend
# to the p2sh_address determined above.
# On testnet, send part of our balance
if [[ "$USE_REGTEST" != "true" ]]
then
    RV=`$BITCOIN_CLI settxfee $TXFEE`
fi
UTXO_TXID=`$BITCOIN_CLI sendtoaddress $P2SH_ADDRESS $AMOUNT1`
if [[ "$DEBUG" = "true" ]]
then
    echo "Fund p2sh address"
    echo "[UTXO_TXID]: "$UTXO_TXID
    echo "-----"
fi

#
# Get everything thus far into a block
# $BITCOIN_CLI generate 1 >/dev/null

#
#

echo "[...Redeem the 2-of-3 transaction]"
#
# Obtain details about the funded transaction. We want whichever output
# was the 10btc output even though the example suggests there is only
# one output.
# NB: second parameter in example superceded after v0.14.0
RV=`$BITCOIN_CLI getrawtransaction $UTXO_TXID true`
UTXO2_VALUE=`echo $RV | sed 's/^.*"value": //' | sed 's/,.*$//'`  # Checked
UTXO2_VOUT=`echo $RV | sed 's/^.*"n": //' | sed 's/,.*$//'`  # Checked
UTXO2_OUTPUT_SCRIPT=`echo $RV | sed 's/^.*"scriptPubKey"//' | sed 's/"reqSigs".*$//' |
              sed 's/^.*"hex": "//' | sed 's/".*$//'`  # Checked
UTXO1_VALUE=`echo $RV | sed 's/"addresses":.*//' | sed 's/^.*"value": //' |
          sed 's/,.*$//'`  # Checked
UTXO1_VOUT=`echo $RV | sed 's/"addresses":.*//' | sed 's/^.*"n": //' |
         sed 's/,.*$//'`  # Checked
UTXO1_OUTPUT_SCRIPT=`echo $RV | sed 's/"addresses":.*//' | sed 's/^.*"scriptPubKey"//' |
              sed 's/"reqSigs".*$//' | sed 's/^.*"hex": "//' |
              sed 's/".*$//'`  # Checked
if [[ "$UTXO1_VALUE" = "$AMOUNT1" ]]
then
    # Use first output (change is the second output)
    UTXO_VOUT=$UTXO1_VOUT
    UTXO_OUTPUT_SCRIPT=$UTXO1_OUTPUT_SCRIPT
else
    # Use second output (changes was the first output)
    UTXO_VOUT=$UTXO2_VOUT
    UTXO_OUTPUT_SCRIPT=$UTXO2_OUTPUT_SCRIPT
fi
if [[ "$DEBUG" = "true" ]]
then
    echo "Capture which outputs we'll use:"
    echo "[1 VALUE            ]: "$UTXO1_VALUE
    echo "[1 VOUT             ]: "$UTXO1_VOUT
    echo "[1 OUTPUT_SCRIPT    ]: "$UTXO1_OUTPUT_SCRIPT
    echo "[2 VALUE            ]: "$UTXO2_VALUE
    echo "[2 VOUT             ]: "$UTXO2_VOUT
    echo "[2 OUTPUT_SCRIPT    ]: "$UTXO2_OUTPUT_SCRIPT
    echo "Vout and Output script chosen:"
    echo "[UTXO_VOUT          ]: "$UTXO_VOUT
    echo "[UTXO_OUTPUT_SCRIPT ]: "$UTXO_OUTPUT_SCRIPT
    echo "-----"
fi

#
# Now create the address redeemed to
NEW_ADDRESS4=`$BITCOIN_CLI getnewaddress $ADDRESS_TYPE`
if [[ "$DEBUG" = "true" ]]
then
    echo "Create redeem-to address:"
    echo "[NEW_ADDRESS4]: "$NEW_ADDRESS4
    echo "-----"
fi

#
# Create a new transaction, slightly less value to accomodate mining fee
RAW_TX=`$BITCOIN_CLI createrawtransaction '''
   [
      {
        "txid": "'$UTXO_TXID'",
        "vout": '$UTXO_VOUT'
      }
   ]
   ''' '''
   {
     "'$NEW_ADDRESS4'": '$AMOUNT2'
   }'''`
RAW_TX_SZ=${#RAW_TX}
if [[ "$DEBUG" = "true" ]]
then
    echo "Generate unsigned transaction:"
    echo "[RAW_TX]: "$RAW_TX
    echo "-----"
fi

#
# Get 2 of the 3 private keys
NEW_ADDRESS1_PRIVATE_KEY=`$BITCOIN_CLI dumpprivkey $NEW_ADDRESS1`
NEW_ADDRESS3_PRIVATE_KEY=`$BITCOIN_CLI dumpprivkey $NEW_ADDRESS3`
if [[ "$DEBUG" = "true" ]]
then
    echo "Capture private keys for use in signing:"
    echo "[NEW_ADDRESS1_PRIVATE_KEY]: "$NEW_ADDRESS1_PRIVATE_KEY
    echo "[NEW_ADDRESS3_PRIVATE_KEY]: "$NEW_ADDRESS3_PRIVATE_KEY
    echo "-----"
fi

#
# 1 of 3 sign off the transaction
# NB: signrawtransaction in example superceded by signrawtransactionwithkey
# NB: order of parameters reverse, and amount becomes mandatory
RV=`$BITCOIN_CLI signrawtransactionwithkey $RAW_TX '''
    [
      "'$NEW_ADDRESS1_PRIVATE_KEY'"
    ]
    ''' '''
    [
      {
        "txid": "'$UTXO_TXID'",
        "vout": '$UTXO_VOUT',
        "scriptPubKey": "'$UTXO_OUTPUT_SCRIPT'",
        "redeemScript": "'$P2SH_REDEEM_SCRIPT'",
    "amount": '$AMOUNT2'
      }
    ]'''`
PARTLY_SIGNED_RAW_TX=`echo $RV | sed 's/^.*"hex": "//' | sed 's/".*//'`
PARTLY_SIGNED_RAW_TX_SZ=${#PARTLY_SIGNED_RAW_TX}
if [[ $PARTLY_SIGNED_RAW_TX_SZ -eq $RAW_TX_SZ ]]
then
    echo "Transaction didn't change size at PARTLY_SIGNED_RAW_TX_SZ. Eh?"
    exit
fi
if [[ $PARTLY_SIGNED_RAW_TX_SZ -eq 0 ]]
then
    echo "Failed at PARTLY_SIGNED_RAW_TX"
    echo "Response: "
    echo "[RAW_TX                  ]: "$RAW_TX
    echo "[UTXO_TXID               ]: "$UTXO_TXID
    echo "[UTXO_VOUT               ]: "$UTXO_VOUT
    echo "[UTXO_OUTPUT_SCRIPT      ]: "$UTXO_OUTPUT_SCRIPT
    echo "[P2SH_REDEEM_SCRIPT      ]: "$P2SH_REDEEM_SCRIPT
    echo "[NEW_ADDRESS1_PRIVATE_KEY]: "$NEW_ADDRESS1_PRIVATE_KEY
    exit
fi
if [[ "$DEBUG" = "true" ]]
then
    echo "Transaction after first signature:"
    echo "[PARTLY_SIGNED_RAW_TX    ]: "$PARTLY_SIGNED_RAW_TX
    echo "-----"
fi

#
# 2 of 3 signs off the transaction
RV=`$BITCOIN_CLI signrawtransactionwithkey $PARTLY_SIGNED_RAW_TX '''
    [
      "'$NEW_ADDRESS3_PRIVATE_KEY'"
    ]
    ''' '''
    [
      {
        "txid": "'$UTXO_TXID'",
        "vout": '$UTXO_VOUT',
        "scriptPubKey": "'$UTXO_OUTPUT_SCRIPT'",
        "redeemScript": "'$P2SH_REDEEM_SCRIPT'",
    "amount": '$AMOUNT2'
      }
    ]'''`
SIGNED_RAW_TX=`echo $RV | sed 's/^.*"hex": "//' | sed 's/".*//'`  # Checked
SIGNED_RAW_TX_SZ=${#SIGNED_RAW_TX}
COMPLETE=`echo $RV | sed 's/^.*"complete": //' | sed 's/\W.*//'`  # Checked
if [[ "$COMPLETE" != "true" ]]
then
    echo "Second signature did not lead to completed transaction. Eh?"
    echo $RV
    exit
fi
if [[ "$DEBUG" = "true" ]]
then
    echo "Transaction after second signature:"
    echo "[SIGNED_RAW_TX]: "$SIGNED_RAW_TX
    echo "-----"
fi

#
# And now broadcast it
TXID=`$BITCOIN_CLI sendrawtransaction $SIGNED_RAW_TX`
if [[ ${#TXID} -eq 0 ]]
then
    echo "Broadcast has gone wrong. Eh?"
fi
if [[ "$DEBUG" = "true" ]]
then
    echo "TXID from broadcasting:"
    echo "[TXID]: "$TXID
    echo "-----"
fi

The code above generated the following output on the testnet run:
$ ./p2sh-multisig.sh
[Setting up run ...]
[...Create and fund a 2-of-3 multisig transaction...]
Creating new addresses:
[NEW_ADDRESS1]: 2NAWwgmSnPcXFshHX41ewLHaN4nYLTzEdHn
[NEW_ADDRESS2]: 2NAoFjMziphkxULu7p4dtcBKLXicnvvcX53
[NEW_ADDRESS3]: 2Mu3S24XuasYheQsinhKAabDnGnH6eakm2X
-----
Obtain public key per address:
[NEW_ADDRESS1_PUBLIC_KEY]: 036ef3ee62456676a49b3087df3f0d804eb09bfcfa95ca606465bee5cfeab4da98
[NEW_ADDRESS2_PUBLIC_KEY]: 0386518595790f10fa1915bb119a0b41d96a380eeb3f3a76ae0694acc9fd2fb333
[NEW_ADDRESS3_PUBLIC_KEY]: 0371d090dd98316a9f8f63c1d925b42cf157f265d1eff84b65620629914b43019c
-----
Obtain p2sh address and redeemScript:
[P2SH_ADDRESS      ]: 2N3G8rhzkMBmfRp54A4rfpW5jTcd65m7hCs
[P2SH_REDEEM_SCRIPT]: 5221036ef3ee62456676a49b3087df3f0d804eb09bfcfa95ca606465bee5cfeab4da98210386518595790f10fa1915bb119a0b41d96a380eeb3f3a76ae0694acc9fd2fb333210371d090dd98316a9f8f63c1d925b42cf157f265d1eff84b65620629914b43019c53ae
-----
Fund p2sh address
[UTXO_TXID]: 06c7e967e0d5f53899a02137d3a1d4dc0eee53690d20d403242954caa187c721
-----
[...Redeem the 2-of-3 transaction]
Capture which outputs we'll use:
[1 VALUE            ]: 0.00030001
[1 VOUT             ]: 0
[1 OUTPUT_SCRIPT    ]: a9146ddd64168434e4e7cf8f7a2a2b485fa1fc8f987e87
[2 VALUE            ]: 0.00005412
[2 VOUT             ]: 1
[2 OUTPUT_SCRIPT    ]: a9146ecbcb78f6ab60ebe53cc69532407a32973af9aa87
Vout and Output script chosen:
[UTXO_VOUT          ]: 0
[UTXO_OUTPUT_SCRIPT ]: a9146ddd64168434e4e7cf8f7a2a2b485fa1fc8f987e87
-----
Create redeem-to address:
[NEW_ADDRESS4]: 2MyuteHEFmxvG2rX8r817DTKhqj8f2ncsmt
-----
Generate unsigned transaction:
[RAW_TX]: 020000000121c787a1ca54292403d4200d6953ee0edcd4a1d33721a09938f5d5e067e9c7060000000000ffffffff01993a00000000000017a9144920d433d073267b904ae23df3b15ea47aec95038700000000
-----
Capture private keys for use in signing:
[NEW_ADDRESS1_PRIVATE_KEY]: cVT8F8PGF9HJSeBgQir5ZHj5Ng4upSPAJHyVnk2puYw6Zs5GdbyR
[NEW_ADDRESS3_PRIVATE_KEY]: cSakmVL2kdR5jTukCFNBPCifcmg3jjQ6eGEvtagnsAoSdDWcu4fT
-----
Transaction after first signature:
[PARTLY_SIGNED_RAW_TX    ]: 0200000000010121c787a1ca54292403d4200d6953ee0edcd4a1d33721a09938f5d5e067e9c70600000000232200205d577278a6dfefffaa4e04ef23fd1172e923f9e7b4949f991b3d7f2af89abb83ffffffff01993a00000000000017a9144920d433d073267b904ae23df3b15ea47aec950387040047304402202c9946f1d50a974f3b7cf24a99002f3f3ca18af7b54939bf2ec1acf6f5528b07022029aaa63fde914735b8e92c202ce3d4b02ea8ded1d2b47821670dd3c6d8dcb02b0100695221036ef3ee62456676a49b3087df3f0d804eb09bfcfa95ca606465bee5cfeab4da98210386518595790f10fa1915bb119a0b41d96a380eeb3f3a76ae0694acc9fd2fb333210371d090dd98316a9f8f63c1d925b42cf157f265d1eff84b65620629914b43019c53ae00000000
-----
Transaction after second signature:
[SIGNED_RAW_TX]: 0200000000010121c787a1ca54292403d4200d6953ee0edcd4a1d33721a09938f5d5e067e9c70600000000232200205d577278a6dfefffaa4e04ef23fd1172e923f9e7b4949f991b3d7f2af89abb83ffffffff01993a00000000000017a9144920d433d073267b904ae23df3b15ea47aec950387040047304402202c9946f1d50a974f3b7cf24a99002f3f3ca18af7b54939bf2ec1acf6f5528b07022029aaa63fde914735b8e92c202ce3d4b02ea8ded1d2b47821670dd3c6d8dcb02b0147304402201e5e933e674f7e4597c1066b48cdb4ca1c7382235b53d411608c2e3a22a31df7022022fc673d696987146effcbb9ce43265ab9ee19da05eaef0bb35ced729fe9592501695221036ef3ee62456676a49b3087df3f0d804eb09bfcfa95ca606465bee5cfeab4da98210386518595790f10fa1915bb119a0b41d96a380eeb3f3a76ae0694acc9fd2fb333210371d090dd98316a9f8f63c1d925b42cf157f265d1eff84b65620629914b43019c53ae00000000
-----
error code: -26
error message:
non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) (code 64)
Broadcast has gone wrong. Eh?
TXID from broadcasting:
[TXID]:
-----
$
The regtest and testnet conf files used (credentials redacted):
$ cat regtest.conf
regtest=1
server=1
rpcuser=xxx
rpcpassword=xxx
rpcallowip=127.0.0.1
deprecatedrpc=createmultisig
deprecatedrpc=generate
debug=1
[regtest]
rpcport=18443

$ cat testnet.conf
testnet=1
server=1
rpcuser=xxx
rpcpassword=xxx
rpcallowip=127.0.0.1
rpcport=18332
The versions used:
Master:
Bitcoin Core Daemon version v0.17.99.0-g6d0a14703e288d72ff19d4d89defbc853233899f
Bitcoin Core RPC client version v0.17.99.0-g6d0a14703e288d72ff19d4d89defbc853233899f
v0.17:
Bitcoin Core Daemon version v0.17.1.0-gef70f9b52b851c7997a9f1a0834714e3eebc1fd8
Bitcoin Core RPC client version v0.17.1.0-gef70f9b52b851c7997a9f1a0834714e3eebc1fd8
A decode of the transaction:
{
  "txid": "e875677a43c3ea91f7ed5790f3133d130fdcbb9e0cc51f098971bb79517c7103",
  "hash": "8d0701cf48cbf48823ede2250832311cea93b6ea0ab116f9e6b4f40c64153027",
  "version": 2,
  "size": 372,
  "vsize": 182,
  "weight": 726,
  "locktime": 0,
  "vin": [
    {
      "txid": "06c7e967e0d5f53899a02137d3a1d4dc0eee53690d20d403242954caa187c721",
      "vout": 0,
      "scriptSig": {
        "asm": "00205d577278a6dfefffaa4e04ef23fd1172e923f9e7b4949f991b3d7f2af89abb83",
        "hex": "2200205d577278a6dfefffaa4e04ef23fd1172e923f9e7b4949f991b3d7f2af89abb83"
      },
      "txinwitness": [
        "",
        "304402202c9946f1d50a974f3b7cf24a99002f3f3ca18af7b54939bf2ec1acf6f5528b07022029aaa63fde914735b8e92c202ce3d4b02ea8ded1d2b47821670dd3c6d8dcb02b01",
        "304402201e5e933e674f7e4597c1066b48cdb4ca1c7382235b53d411608c2e3a22a31df7022022fc673d696987146effcbb9ce43265ab9ee19da05eaef0bb35ced729fe9592501",
        "5221036ef3ee62456676a49b3087df3f0d804eb09bfcfa95ca606465bee5cfeab4da98210386518595790f10fa1915bb119a0b41d96a380eeb3f3a76ae0694acc9fd2fb333210371d090dd98316a9f8f63c1d925b42cf157f265d1eff84b65620629914b43019c53ae"
      ],
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.00015001,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 4920d433d073267b904ae23df3b15ea47aec9503 OP_EQUAL",
        "hex": "a9144920d433d073267b904ae23df3b15ea47aec950387",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2MyuteHEFmxvG2rX8r817DTKhqj8f2ncsmt"
        ]
      }
    }
  ]
}
The redeem script decodes to:
{
  "asm": "2 036ef3ee62456676a49b3087df3f0d804eb09bfcfa95ca606465bee5cfeab4da98 0386518595790f10fa1915bb119a0b41d96a380eeb3f3a76ae0694acc9fd2fb333 0371d090dd98316a9f8f63c1d925b42cf157f265d1eff84b65620629914b43019c 3 OP_CHECKMULTISIG",
  "reqSigs": 2,
  "type": "multisig",
  "addresses": [
    "mpZQSfgndvkjqcoXdvofNsE3aJeRAXjrvM",
    "mz9eLLofqQKQcuhwGjHxxNhSVxvoYWZDrY",
    "mkZv5XqarsoFMoTWSgMfqE9yihvUu8AHAY"
  ],
  "p2sh": "2MxYTNmXWUFwv8miRAcoCsqAr7MduFCjEAV",
  "segwit": {
    "asm": "0 5d577278a6dfefffaa4e04ef23fd1172e923f9e7b4949f991b3d7f2af89abb83",
    "hex": "00205d577278a6dfefffaa4e04ef23fd1172e923f9e7b4949f991b3d7f2af89abb83",
    "reqSigs": 1,
    "type": "witness_v0_scripthash",
    "addresses": [
      "tb1qt4thy79xmlhll2jwqnhj8lg3wt5j8708kj2flxgm84lj47y6hwps0je8zu"
    ],
    "p2sh-segwit": "2N3G8rhzkMBmfRp54A4rfpW5jTcd65m7hCs"
  }
}
Many thanks if you got down this far. You're great! Clearly I've misunderstood something. But what?

It looks like in the signrawtransactionwithkey stage that your are setting the amount to be signed to be :
"amount": '$AMOUNT2'

If I followed your flow correctly, that is the amount that you want to send by redeeming the utxo.  If so, this is incorrect.  You need to sign the amount amount of the utxo itself (the one in the funding transaction).

@AlistairMann: You can accept the answer, however; click the check mark on the left.

Your answer is exactly right, and I'm sorry I'm not allowed to +1 you; the script now completes properly both on regtest and testnet. I'll elaborate beneath.

Good to hear!  Don't worry about the +1 :)

@arubi has posted the correct answer, many thanks to him.
For anyone else in future, my mistake was in both the above signrawtransactionwithkey() calls where I used the amount I wanted to send FROM the p2sh address when the parameter requires the amount sent TO the address. On reflection this should have been obvious: all the other values in the second parameter are inputs, and I was adding an output.
I've uploaded the corrected code and the output from a regtest and testnet run to https://github.com/Csi18nAlistairMann/bitcoin-p2sh-multisig-example


text:
Source and (mis)handling of the private key for a basic tx
I'm looking to get "hands on" with signing, however when I adapt Runeks' thorough answer at https://bitcoin.stackexchange.com/a/5241/89798 my code invariably fails reporting that I've used the wrong private key. Am I sourcing the private key wrongly, or mishandling it in some way? Where in my process below am I getting it wrong?
I'll start by noting Runeks' code as it stands executes correctly, that I'm using v0.13.2 bitcoind and bitcoin-cli in order to get the legacy transactions used in his answer, and I'm using regtest rather than mainnet.
My process:

I use a script to reset the regtest network and generate 101 blocks so I've a single coinbase I can use:

CURDIR=`pwd`
cd /home/bitcoin14/.bitcoin
/usr/local/bin/bitcoin-cli -conf=/home/bitcoin14/.bitcoin/regtest.conf -regtest stop
sleep 1
rm -rf /home/bitcoin14/.bitcoin/regtest && /usr/local/bin/bitcoind -conf=/home/bitcoin14/.bitcoin/regtest.conf -regtest -daemon
sleep 2
/usr/local/bin/bitcoin-cli -conf=/home/bitcoin14/.bitcoin/regtest.conf -regtest generate 101 >/dev/null
cd $CURDIR

I send the coins to a new address in order not to use that coinbase transaction

$ /usr/local/bin/bitcoin-cli -conf=/home/bitcoin14/.bitcoin/regtest.conf getnewaddress
mk5U6xEDnTmfNrHcCXkdKrXziYH1YMygVw
$ /usr/local/bin/bitcoin-cli -conf=/home/bitcoin14/.bitcoin/regtest.conf sendtoaddress mk5U6xEDnTmfNrHcCXkdKrXziYH1YMygVw 49.99
675eac8d9aebe4f84aa2bb18a9f02304d11cb8937ca103b6ccf00fdf0de69727

I obtain the hex and vout of the above transaction as containing the coins whose move I wish to sign

$ /usr/local/bin/bitcoin-cli -conf=/home/bitcoin14/.bitcoin/regtest.conf gettransaction 675eac8d9aebe4f84aa2bb18a9f02304d11cb8937ca103b6ccf00fdf0de69727 | egrep 'vout|hex'
      "vout": 1,
      "vout": 1
  "hex": "0100000001fe37d2309bb4b4f4de102ff08f08e049acaecd4c1ee195328404c02406e596c6000000004847304402206eef31e0114c8e31180da39c644fc518624e9c5f354f6c375bfffba8a3c0dc6d022021056d74ea16155036663b7aaab1e297715231747718e48ab94aefd05cded83d01feffffff0254330f00000000001976a91486d1e65bc7f89b24724f50fa5db3a7f102d9644d88acc0aff629010000001976a9143206b266d2998b1092fcd1737165c363c0e31b6c88ac65000000"

I obtain a new address to which the coins will be redeemed

$ /usr/local/bin/bitcoin-cli -conf=/home/bitcoin14/.bitcoin/regtest.conf getnewaddress
n42ui4Tbd2mVPiRtAUr4RYW7KC7qUmXDTt

I obtain the private key generated at "2" above

$ /usr/local/bin/bitcoin-cli -conf=/home/bitcoin14/.bitcoin/regtest.conf dumpprivkey mk5U6xEDnTmfNrHcCXkdKrXziYH1YMygVw
cPMjUqc3d4WhDG8Evn2G3RrVWMyetHtwiTZhpKW1T1QUrBhYGVnG

I convert the private key into the hex equivalent as per https://bitcoin.stackexchange.com/a/52954/89798 (This on a different machine)

$ ./bitcoin-tool --input-type private-key-wif --input-format base58check --output-type private-key --output-format hex --network bitcoin --input cPMjUqc3d4WhDG8Evn2G3RrVWMyetHtwiTZhpKW1T1QUrBhYGVnG
3500dba7a3363e7127cd72273b0e475c5dbb1d378496b803edaf06f8eb3ee160

I take the above and edit them into place in Runeks' code

HEX_TRANSACTION="0100000001fe37d2309bb4b4f4de102ff08f08e049acaecd4c1ee195328404c02406e596c6000000004847304402206eef31e0114c8e31180da39c644fc518624e9c5f354f6c375bfffba8a3c0dc6d022021056d74ea16155036663b7aaab1e297715231747718e48ab94aefd05cded83d01feffffff0254330f00000000001976a91486d1e65bc7f89b24724f50fa5db3a7f102d9644d88acc0aff629010000001976a9143206b266d2998b1092fcd1737165c363c0e31b6c88ac65000000"
...
OUTPUT_INDEX=1
...
SEND_TO_ADDRESS="n42ui4Tbd2mVPiRtAUr4RYW7KC7qUmXDTt"
...
PRIVATE_KEY=0x3500dba7a3363e7127cd72273b0e475c5dbb1d378496b803edaf06f8eb3ee160

I run the code (again different machine to the above)

$ python2 sign3.py
Traceback (most recent call last):
  File "sign3.py", line 144, in <module>
    (OUTPUT_INDEX, hash_160_to_bc_address(tx_info['txOut'][OUTPUT_INDEX]['scriptPubKey'][3:-2], bytes[0]))
RuntimeError: The supplied private key cannot be used to redeem output index 1
You need to supply the private key for address mk5U6xEDnTmfNrHcCXkdKrXziYH1YMygVw

The error is clear: I have not supplied the correct private key. Where is my mistake? Thanks all!
Edit
It appears that bitcoind-0.13 provides a pubkeyhash based on a compressed public key, and that the code beneath acts on the uncompressed public key that the private key reveals. The two hashes being different, the later conditional fails.
k = ecdsa_ssl.KEY()
k.generate(('%064x' % PRIVATE_KEY).decode('hex'))

#here we retrieve the public key data generated from the supplied private key
pubkey_data = k.get_pubkey()

Investigations continue...

The issue is public key compression, as noted in your edit. The original code does not handle compressed public keys.
Try adding
k.set_compressed(True)

before
#here we retrieve the public key data generated from the supplied private key
pubkey_data = k.get_pubkey()


text:
error: Authorization failed: Incorrect rpcuser or rpcpassword
After installing bitcoin on CentOS/AWS, an error occurs when connecting with cli.
$ bitcoind -daemon -conf=/.bitcoin/bitcoin.conf
Bitcoin server starting
$ bitcoin-cli getbalance
error: Authorization failed: Incorrect rpcuser or rpcpassword

The following is bitcoin.conf.
mainnet = 1
txindex = 1
server = 1
rest = 1
rpcuser = a
rpcpassword = a
rpcport = 8332

The following is displayed when executing bitcoind.
Binding RPC on address ::1 port 8332 failed.
Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcauth for rpcauth auth generation.

-conf=/.bitcoin/bitcoin.conf is unusual as it suggests you're keeping the .bitcoin outside your /home folder. If that's a mistake, it would explain why bitcoin-cli can't find the credentials - the conf file you're specifying doesn't exist. Are you sure you sure you don't mean -conf=/home/<user>/.bitcoin/bitcoin.conf?

Thank you for answering.I created bitcoin.conf with the following command. Is that wrong?
mkdir ~/.bitcoin
vi ~/.bitcoin/bitcoin.conf

If that's two commands then they do seem right. However your question says you used /.bitcoin/bitcoin.conf which is not the same as ~/.bitcoin/bitcoin.conf. The first says start in the root of your file system, the second - with a tilde '~' - says to start in your home folder.

In case you changed your /etc/systemd/system/bitcoind.service make sure you run
 sudo systemctl stop bitcoind
 sudo systemctl daemon-reload
 sudo systemctl start bitcoind

to apply the changes.

While this advice may be useful, the question doesn't ask anything about systemd or with changing systemd service files.


text:
Running multiple Bitcoin nodes on same network
I want to run a bitcoin node on two separate devices (computer + dedicated hardware device) on the same network (and would like them to be externally accessible).  Specifically, I have a Casa Node with bitcoind, and I have a Mac with bitcoind. Both on my home network.
I've read it is critical that you forward port 8333 on your router to the IP address of the computer that is running your node, so I'm not sure what to do on the dedicated hardware device then.
I've seen you can add port and rpcport arguments to the bitcoin.conf file, but I'm can't figure out exactly how this setup will work on the same network with two different bitcoin nodes.
Any help by someone more expert (most people likely ha) than me would be appreciated, thanks!
Bitcoin.conf file
daemon=1
server=1
prune=750
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333
rpcuser=xxx
rpcpassword=xxx

Not a full answer, but if you want to expose your node to the internet (which isn't critical at all, it's your choice if you want to help strengthen other's connections; the node gives you the same security and benefit regardless of whether it is reachable), you can just make one of the two reachable, and use the 'addnode' option to connect your two nodes to each other.

Note you can do this with different node implementations. You might have your bitcoind connected to outbound/inbound peers, but add a permanent peer connection to your second Libbitcoin server, which is in your local network without any other connections configured. The Libbitcoin node will receive all “validated” resources from the Bitcoind, and its strong chain will reflect the venn intersection between Bitcoind and Libbitcoin Validation spaces (Useful, in the case of potential implementation bugs in either implementations)

@PieterWuille thanks for breaking the addnode option down for me, I hadn't even see that, but now I know about it and feel like I understand it enough from your response too. Awesome!

@JamesC. thats really interesting, had no idea!

Note that the 'addnode' command will only work if the added node has a fully synced chain (flag “NODE_NETWORK”).


text:
How do I interpret Bittrex's minimum trade size?
The following description from https://bittrex.zendesk.com/hc/en-us/articles/360001473863-Bittrex-Trading-Rules confuses me:

All cryptocurrency orders placed on the Bittrex platform are subject
  to the following minimum order sizes:
The minimum trade size is 50,000 Satoshis. There is also a minimum
  trade quantity.  For example, DOGE trades at 22 satoshis.  The minimum
  trade quantity is 4500 DOGE and the minimum trade value is 50,000
  Satoshis.  The smallest order in the book is 50000 DOGE at 1 satoshi
  each.  The largest order in the book is 4500 DOGE at 2 btc each.

So if I have the BTC-DOGE pair for example. The https://api.bittrex.com/api/v1.1/public/getmarkets API says MinTradeSize = 480. I assume this means the minimum quantity of DOGE I can buy is 480. How does the minimum trade size of 50,000 satoshi from the trading rules above work with this?
Does it mean X DOGE x current price >= 50,000 satoshi and X DOGE >= 480 for a trade to be accepted?
I have tested the first comparison (X DOGE x current price >= 50,000 satoshi) which seems to be correct. However I am unable to test the second (X DOGE >= 480).
Also what happens when the quote currency is USD, USDT or ETH?


text:
How do I find out what the latest protocol version is?
How do I find out what version Protocol specification is describing?

The latest protocol version can be found by looking at the latest canonical Bitcoin client implementation source code currently v0.8.5 at https://github.com/bitcoin/bitcoin/blob/v0.8.5/src/version.h#L28. This should tally with what is described at https://en.bitcoin.it/wiki/Protocol_specification.

As of october 2013, the protocol version is 70001. It's not linked anymore to client versions (so it doesn't correspond to version 0.7.0.1 in particular; 70001 was introduced in 0.8.0), and is intended to go up in increments of one, as changes specified in BIPs are implemented.

Thanks! How do you find this out? Is there a reason why it is not stated on the Protocol specification?

Updating the specification on the wiki, and adding the protocol version in which every field was introduced would be an interesting project :)

All it needs is a sentence right at the top of the wiki page saying: 'The current protocol version is 70001.' Ideally it would also have a short description of the changes. I would update the wiki myself if I was allowed to edit it. Also where did you check to see what the current protocol version is and when it was updated?

"current" protocol version... it's a bit more complex than that. Two clients negotiate which version to use when they connect; a few dozen versions numbers exist. It's not very useful to know what the latest protocol is without knowing what it entails. And I looked here: https://github.com/bitcoin/bitcoin/blob/v0.8.5/src/version.h#L28

Thanks for the help. I assumed the [https://en.bitcoin.it/wiki/Protocol_specification](Protocol specification) wiki page was designed to tell you what the protocol entails.

There's now a good overview at https://bitcoin.org/en/developer-reference#protocol-versions. The latest as of March 2014 is 70002.

This is actually out-dated. It's 70016


text:
How does Bittrex charge its commission?
Assume I want to trade the BTC-BCH pair. I have only one BTC in my exchange wallet and want to buy one BTC worth of BCH.
What currency will the 0.25% commission come out of?
Will I need to trade 1 BTC - 0.25% so there is enough funds in my account to cover the commission?
The same question goes for selling BCH to receive BTC Where I have only 100 BTC in my exchange wallet and want to convert it all to BTC. Will I need to ensure that I only convert 100 BCH - 0.25%?

I can't be "Bittrex specific", but i can provide a general answer to how it would work and have seen it work across a half dozen systems that are crypto specific and dozens of financial systems that are non crypto specific:
When you set up a sell order (or just click sell) it's usually not a "1 and done" situation. You are selling 'x' amount for at least 'y' value. As the system matches up the purchases of your 'x' amount to buy orders, a fee is applied when the match is made and the "trade" occurs. The fee can be taken out of BOTH sides of the trade. You have a .25%.. the buyer may have a .25%. That means if the trade completes, whatever you are "due" they will remove it before handing it over. THEY get BCH. The person buying it get's a fee too.. they paid in BTC. Once the trade completes, they pay their fee in BTC.
Sorry this isn't specifically a Bittrex answer, it's a "how these things normally work". I can't imagine how else it could be accomplished as it would mess up all normal accounting practices.
In sum, to maintain accounting: The trade is completed. Fee's are assessed against the results.

Thank you for your thorough answer. I have opened another question https://bitcoin.stackexchange.com/q/83136/6707 with the nuance I am looking for more clearly described.


text:
REST API to create Stellar account?
In the REST API documentation, I didn't see an option to create an account. Obviously then, the code snippet here to create an account has to be front-ended by some other API so that a request to create an account can be catered to. I am not sure why this is so. Is there a HTTP POST REST API to create an account?
Also, normally, to build a REST interface, one starts with identifying all 'resources' whose state changes over time and can be changed in a state-less operation. Then, for every such resource, the CRUD operations are implemented. For example, in Stellar, the resources could be account, anchor, trustlines, transactions, etc.

There is no REST endpoint to create an account. An account is implicitly created after receiving at least 20 lumens.
To create an account:

Generate a private/public keypair. You can use the Stellar Laboratory Account Creator for that.
Get at least 20 lumens, either from an exchange or through another account, sent to the public key you just created.

That's it.
Official guide : https://www.stellar.org/developers/guides/get-started/create-account.html

Hello there Mr. Weller, so, is there a way to generate the private/public keypair without having to resort to using the SDKs?

@jlstr Yes, you will need to use a crypto library that implements ed25519. You can see how the Stellar SDKs do that for reference. For example, Here's the Java keypair implementation.

Just as the documentation clearly mentions,

To create a test account, send Friendbot the public key you created. It’ll create and fund a new account using that public key as the account ID.

Create your own public key use ED25519 public-key signature system
Perform a GET to the request friendlybot https://friendbot.stellar.org/?addr=

I think he wants to get a real account, not a test one, and he's asking how to create it without going through an exchange


text:
double spend attack: Is this actually true for the more time progress the higher the probability of success for attacker
I'm new here.
I have  a question here. Some experts keep saying that this assumption isn't formally correct and I don't really understand why or why they might be wrong.
In the double spend attack; you have attacking network and honest network.
Total Hash rate is split between those.
some experts keep saying that time is not a factor in determining how fast you can generate blocks. That's something I don't really get.
So, is it incorrect to say that the probability of success of the attacker
increases with the time T it takes to generate z transactions since they have more time to secretly mine their alternate blockchain ?
update:
@G. Maxwell. I am not sure what i am asking for exactly. So let me try this.
Perhaps I am asking whether the assumption that the time to mine blocks is memoryless ? And how this clashes, if it does, with the proposition that the probability of success an attacker increases with time T it takes to mine the z transactions since they have more time to secretly mine their alternate blockchain.
I am not assuming any other external attacks other than mere hashpower.

I added some text that might answer your requested clarification.

I believe you are asking if the inter-block interval matters for the success rate of a high hashpower reorg attack.
It does, because if it is too fast the honest participants will spend a substantial fraction of their time not working on the same (honest) chain, because they haven't heard of each others blocks or have created their own blocks before other honest blocks arrived.
So the attacker pillages the village while the defense is diluted and not working together perfectly.
Slowness in this case is always relative to the overall processing and propagation time. So a system which worked without substantial dilution normally could run into problems when flooded with transactions or if an attacker started also DOS attacking nodes.
Mining a block is memoryless, but mining a chain makes progress. But both the attacker and the honest network make progress, so when considering their relative advantages their success depends on their relative hashrates.  If in fact the honest network takes longer (due to bad luck) to mine this particular block then it is easier for an attaker to be successful during that time.
So, for example, in your risk calculation if you observe that blocks have been slower than expected recently it may be reasonable to require more confirmations for two reasons: One reason is because if the honest network was unlucky an attacker with a secret chain might have done better with only average luck. Another reason is because the reduced block speed may in fact be because part of the network has split off to attack.

Why is transaction flooding considered DOS? They are anonymous, pay a sufficient fee for propagation, and any validating node can restrict mempool acceptance criteria if resources too low, or forego mempool altogether.

Fee is not for propagation, it's for getting into a block. Also he said "flooded with transactions OR DOS" not necessarily equating the two.

Ok. Minimum fee is also required for propagation (node policy, see libbitcoin server). Of course fee ultimately for confirmation payment.

A transaction that never confirms never pays a fee.  Moreover, at best a fee can make an attack more expensive, it is not a magic totem that turns an attack into not an attack. :)

unrelated, libbitcoin isn't actually used on widespread basis in Bitcoin so generally you shouldn't use it as a benchmark of what Bitcoin does in practice. (though on there being minimum fees used it's consistent)


text:
Bitcoin ECDSA signature in the compact format
I would like to understand how to get Bitcoin ECDSA signature in a compact format, when it's exactly 65 bytes.
In the bitcoin-core repository, secp256k1_ecdsa_recoverable_signature_load is responsible for this. As far as I understand, in it r and s are separately reduced to a 32 byte representation using secp256k1_scalar_set_b32, but I don't understand how it function works. What is a EXHAUSTIVE_TEST_ORDER? Why does the resulting representation of 32b scalar remain valid after it? I would be very grateful if someone could explain it to me.

What you are looking at is just an implementation detail that you really don't need to worry about. It's just converting from an internal format (which may use different coordinate systems and bit lengths, especially for tests) to the standard output format. Within the library itself, the data in the signature may be easier and more efficient to handle when in other formats or coordinates systems. So the structures that represent that data store the data differently. However when outputting results, it must all be in a standard format, so that's what these conversions do: change from internal representation to a standard output format.
This is done for any of the signature serialization outputs that libsecp256k1 does. The compact format is just the two 256 bit values for R and s concatenated with each other. The first 32 bytes is R, the second is s. For standard compact signatures, that's it. For compact recoverable signatures (which is what you are looking at), there is an additional byte for the recovery id that is prepended to the compact signature.

In fact, I want to get a compact format of signature using the OpenSSL library. it has ECDSA_do_sign function which returns a structure consisting of two pointers to BIGNUM. Could you please tell me how to convert this internal representation from the OpenSSL into a standard one? I cannot find in the interface a function similar to the function from bitcoin-core.

Of course you won't be able to find how to do that in Bitcoin Core because Bitcoin Core does not use OpenSSL for signature operations anymore. The ways that libsecp and openssl represent things internally are different from each other.  You can use ECDSA_SIG_get0 to get the BIGNUMs for r and s, then use BN_bn2binpad to get the BIGNUMs serialized as 32 byte big-endian integers. Then just concatenate the two byte strings to get the compact signature.

How to verify the compact signature? as bitcoinjs-message nodejs library throw error Error: Invalid signature length.

@AndrewChow, i believe the recovery ID byte is prepended to the signature (r,s). It is the first byte, not the last.

@SachinMeier Oh, indeed it is the first byte. I have updated the answer.


text:
Representation of coordinates in signature. OpenSSL
I want to calculate the v-value from the signature obtained using the OpenSSL ECDSA_do_sign function. I found that this value is calculated using the parity of y-coordinate of r. Here I also found that the parity of y is equal to the parity of r. I want to understand whether it depends on the implementation. Can anyone tell exactly how the coordinates x and y are stored inside r in OpenSSL. I can't find it in the code.
edited:
  I understand how v is calculated. My question is how to get the y-coordinate of r in the specific implementation of ECDSA in the OpenSSL library.

The value r is just a number and doesn't explicitly store or encode any point coordinates.  In a signature, r is set to the X coordinate of the point R, which is really k*G, where k is the secret nonce used during signing, then reduced mod the curve order.
In secp256k1, this usually means that r is in fact the X coordinate (because r itself is usually very big), but it is not always so.
During verification, the verifier attempts to reconstruct the original R point by from the signature values (s, r), the message z and the signer's public key P by solving the equation s*R' = z*G + r*P, then reduce the X coordinate of R' mod the curve order and check that it is equal to r given in the signature.
I've never used openssl, but the process seems to be in ossl_ecdsa_verify_sig().  So you can see R' being computed here :
https://github.com/openssl/openssl/blob/master/crypto/ec/ecdsa_ossl.c#L396-L404
After these lines, the reduction mod the order is done and finally the equality test.  In simple signature verification, the Y coordinate of R' is not used, but it is available from the value point (which is R') in openssl's implementation.
edit:
Also, I just realized I should add a something about pubkey recovery since you mention the v or recid value in your question.
When doing pubkey recovery from message and signature (as in the case when the signer's pukey is not given), to get the Y coordinate from a possible R' point, you would try a few values based on r as the candidate X coordinates.
The possible X coordinates of R' will be r itself, or r + curve_order (and both can be valid X's).  You can then solve the curve's equation y^2 = x^3 + 7 to get the possible Y values for each.


text:
How to provide a proof-of-payment to an offline Lightning Network vending machine?
I'm considering building a Lightning Network vending machine that is offline but has the capability to create LN invoices and verify payments.
As an example the scheme has:

One offline vending machine.
One online node to validate payments.
One user (online with a cellphone).

For that there must be:

A way for the vending machine to provide valid invoices that can be paid to the online node.
A way for the user to communicate a prof-of-payment to the vending machine.

Is this currently viable? Is this something that can/should be standardized so every wallet can implement it?

Stepan Snigirev had basically provided an explanation how to do the tricky part described at https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002009.html
The idea is that the vending machine creates an invoice with a routing hint that goes through the online node and the online node can construct the preimage from the onion that will be send.
Another way would be to have a deterministic way of preimage generation as explained in this video:  https://youtu.be/bihYeAeNi0g - which was already inspired by Stepan but is not as elegant as his solution.
Regarding the proof of payment the phone would just display a qr code of the preimage which a vending machine could scan


text:
How to re-secure a multisignature wallet if private key is stolen
Here are two attack scenarios on bitcoin private keys:
1) Assume  that,  BitCorp has just noticed that a Mallory  has just compromised one of their servers holding their Bitcoin Private keys. Luckily, they are using a 2-out-3 multi-signature wallet, so Mallory has learnt only one of the 3 sets of keys. The other two sets are on different servers that Mallory cannot access. How do that re-secure their wallet and effectively revoke the information that Mallory has learned?
2) If BitCorp uses 2-out-,2 instead of 2-out-3 wallet, what steps can they take 'in advance' so that they can recover, even in the event of one of their servers getting broken into(and Mallory not just learning but also potentially 'deleting' the key material on that server)?

How do that re-secure their wallet and effectively revoke the information that Mallory has learned?

They would have to generate new keys and send the Bitcoin to the multisig address that uses those new keys. If Mallory has/had access to one wallet, she could record any and all keys in that wallet. Thus all keys in that wallet must be considered compromised and never used again. Any Bitcoin associated with those keys should be moved to a newly generated wallet that is not compromised.

2) If BitCorp uses 2-out-,2 instead of 2-out-3 wallet, what steps can they take 'in advance' so that they can recover, even in the event of one of their servers getting broken into(and Mallory not just learning but also potentially 'deleting' the key material on that server)?

They can create pre-signed timelocked transactions that send the coins to another address that they control where those private keys are stored on separate servers. In the event that Mallory compromises and deletes the private key for one key in the 2-of-2, that transaction can be broadcast after the timelock and the coins moved to a new address where the private keys exist.


text:
Bitcoin-core how to get all transactions hashes?
Please, can anyone help me how to get all transactions hashes? How to browse all the transactions hashes used in blockchain?
P.S. How simply get a list of all transactions IDs (as a simple text list) if I only have running syncronized bitcoin node on my PC and I do not have any other data such as addresses or something else?

You can use any block explorer that has an API, but that could take a long time, what are you trying to accomplish?

The questions aren't very clear, what are you try to do with the hashes or how would you get those hashes (e.g. by public address, TXID, etc.). Please edit to include as much details as possible.

Browse BlockChair to find the list of transactions: https://blockchair.com/bitcoin/transactions
Then uncheck every box other than TXID (hash):
https://blockchair.com/bitcoin/transactions#f=hash
Then use export, and pay them if needed.

I need the list (hashes) of all transactions used in blockchain. Just list of all hashes that are in Bitcoin blockchain database. I need this for my theoretical research work. I think it is not possible to retrieve them from this site.

The website says they'd give the data for free for research purposes. What you're looking for is the export button on the right.

...how to...?

The answer is: write a program for parsing blockchain. Such program is not too difficult. I've written it from my existed sources in five minutes. The result is here: https://cloud.mail.ru/public/GsXh/iLwmeSQ14
Symbol "c" in first column means that this transaction is coinbase
Of course, this file contains only 2k lines, I do not want to dump all transactions into the file. Mail me alistermaclin@mail.ru if you need such program.


text:
How do the JavaScript SecureRandom() vulnerabilities affect me?
A recent post on the Bitcoin-dev mailing list talks about multiple vulnerabilities in JavaScript SecureRandom() class. Apparently this class has been used in multiple cryptocurrency wallets that use JavaScript to generate private keys.
What products are affected by these vulnerabilities? As a user of these products, what should I do to make myself no longer vulnerable?

What products are effected by these vulnerabilties?
-- Not Sure specific products, but watch out for products(wallets) using javascript lib to generate private keys.
As a user of these products, what should I do to make myself no longer vulnerable?
-- you should immediately move your funds to new addresses, make sure new wallet does not suffer from this known vulnerability.


text:
Bitcoind JSON-RPC - PHP user handling
I asked this question on bitcoin forum too (just for the record):
https://bitcointalk.org/index.php?topic=430972.new#new
I am trying to develop a php web application (a game, and not a gambling site) where users can make in-game purchases. Now if I am understanding it right, The architecture (using bitcoind and Json-rpc api) should be:

When a new user registers - generate a new address for the new user:

$bitcoin->getnewaddress("username");

Store that wallet address for later use in my DB.
Display that address and let a user send bitcoins to that address.
Check the balance of that address using the

$bitcoin->getbalance($username,0)

for unonfirmed balance  and

getbalance($username,6)

confirmed balance.
Now I can let the user buy my in-game items
and use

$bitcoin->move($useraddress, $myaddress, $amount)

to debit his account and give him the stuff he needs.

Questions:
1. Does this sound about right?  Or am I completely off here!
2. How long does it take for the unconfirmed balance to show up?  [$bitcoin->getbalance($username,0)]
3. $bitcoin->move($useraddress, $myaddress, $amount)  is a change of bitcoins between addresses within my wallet, so this should be
offchain and instantaneous, right?
4.  How can some gambling dice sites like coinroll.it ( https://bitcointalk.org/index.php?topic=191176.0) accept unconfirmed
transactions and lets  people play instantly? are they just taking
the risk or there is something that I am not aware of.
5. How can I test out my bitcoind/php application with testnet? Anyone has any experience of this?
6. Suggestions on Security are welcome...

I am going to make parts of my code open source when I figure this shit out

Do not use bitcoind's accounts feature. Handle user/address associations in your DB instead.
Even Gavin Andresen himself has said:

... the bitcoind "accounts" code hasn't been optimized for that.  For
  example, computing an account's balance loops through all transactions
  in the wallet, so will take an increasing amount of time the more
  transactions you have in the wallet.

https://bitcointalk.org/index.php?topic=40430.0
As for how to handle transactions/purchases in your game, I'd recommend setting up a field in your users table to store a user's balance. When a user deposits to their personal deposit address you'd update the field with their new balance. Set up a cron task that runs every minute and calls a script that does something like this:

Pull latest 10000 transactions from bitcoind and store them in an array.
Filter out transactions with less than 2 confirmations, or whatever number makes you feel comfortable.
Insert all confirmed transactions into a DB table called "transactions." Don't allow duplicates. Add a boolean field called "processed"
When you're ready to process transactions to the users' accounts, pull all rows where processed = 0 and category = 'receive'. Process each deposit by adding the value of the transaction to the user's account, and set processed = 1 on the processed transactions.

When a user buys something in-game, just subtract the purchase amount from their balance.
This will be a lot more efficient, scalable, and easy-to-use than relying on bitcoind for user balance-keeping. It will also be a lot easier to migrate data around in the future, if necessary.

You are very correct, but:

I would use getaccountaddress instead of getnewaddress. If the user doesn't exist, which is the case for a new user, the wallet will create a new one anyway.
I always would use the user's name to recover from the wallet his address, there's no sense to store it again on a DB. ¿?

The time for a balance to be confirmed depends on the coin and its network.
$bitcoin->move($useraddress, $myaddress, $amount) Yes, it is instantaneous. There's no transaction broadcasted to the net.
How can I test out my bitcoind/php application with testnet? Anyone has any experience of this? ---> Go to the wiki, U have to set a specific parameter on bicoin.conf

You are correct on most of it rest can be experienced in development process. So I suggest you to start development and ask if you find it difficult to fix issues.

https://en.bitcoin.it/wiki/Running_Bitcoin gives you either the command line option or the configuration file option to use testnet.


text:
Got an issue compiling
After working my way through many errors compiling an alt-coin windows qt.
Everything compiles fine right until the final stage when the system is putting together the exe.
You can find the error below. leveldb is installed and libleveldb.a and libmemenv.a files are correctly in src/leveldb ... Any help resolving this issue would be appreciated.
uuid -lgdi32 -lboost_system-mgw48-mt-1_54 -lboost_filesystem-mgw48-mt-1_54 -lboo
st_program_options-mgw48-mt-1_54 -lboost_thread-mgw48-mt-1_54 -lboost_chrono-mgw
48-mt-1_54 -lQtGui4 -lQtCore4
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x433): undefined reference to `l
eveldb::DB::Open(leveldb::Options const&, std::string const&, leveldb::DB**)'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x73f): undefined reference to `l
eveldb::Status::ToString() const'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x866): undefined reference to `l
eveldb::WriteBatch::~WriteBatch()'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x89f): undefined reference to `l
eveldb::WriteBatch::WriteBatch()'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x921): undefined reference to `l
eveldb::WriteBatch::~WriteBatch()'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x944): undefined reference to `l
eveldb::Status::ToString() const'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0xac4): undefined reference to `l
eveldb::WriteBatch::Iterate(leveldb::WriteBatch::Handler*) const'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0xaf5): undefined reference to `l
eveldb::WriteBatch::Handler::~Handler()'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0xb24): undefined reference to `l
eveldb::Status::ToString() const'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x14a9): undefined reference to `
leveldb::Status::ToString() const'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x176f): undefined reference to `
leveldb::WriteBatch::Put(leveldb::Slice const&, leveldb::Slice const&)'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x18b2): undefined reference to `
leveldb::Status::ToString() const'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x1a57): undefined reference to `
leveldb::Options::Options()'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x1ae0): undefined reference to `
leveldb::Options::Options()'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x1b35): undefined reference to `
leveldb::NewLRUCache(unsigned int)'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x1b44): undefined reference to `
leveldb::NewBloomFilterPolicy(int)'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x1b9c): undefined reference to `
leveldb::NewBloomFilterPolicy(int)'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x2021): undefined reference to `
leveldb::WriteBatch::~WriteBatch()'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x211d): undefined reference to `
leveldb::Status::ToString() const'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x35c3): undefined reference to `
leveldb::WriteBatch::Delete(leveldb::Slice const&)'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x6488): undefined reference to `
leveldb::WriteBatch::~WriteBatch()'
./build\txdb-leveldb.o:txdb-leveldb.cpp:(.text+0x64b8): undefined reference to `
leveldb::WriteBatch::~WriteBatch()'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: ./build\tx
db-leveldb.o: bad reloc address 0x2 in section `.text$_ZN5boost16exception_detai
l10clone_baseD1Ev[__ZN5boost16exception_detail10clone_baseD1Ev]'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: final link
 failed: Invalid operation
collect2.exe: error: ld returned 1 exit status

Are you linking to LevelDB?

@DavidSchwartz I believe the bitcoin makefile will automatically link the leveldb library. I had once a similar issue, that costed a lot of time to resolve. I will post it as answer.

Check if your libleveldb.a compiled all necessary files correctly. Could you run the following commands please and post the output back?
ar tv libmemenv.a and ar tv libleveldb.a. If the output is something similar to
rw-rw-rw- 0/0 432255 Apr 15 16:56 2014 memenv.o
rw-rw-rw- 0/0  21322 Apr 15 16:56 2014 port_win.o

then the problem could be that your Windows find.exe is overruling your MSYS file.exe. They both work very differently and are not interchangeable. The makefile of LevelDB uses the Unix style find.exe. You can fix this by explicitly putting your MSYS find.exe directory before the Windows find.exe directory (which should be something like C:\Window\System32\find.exe).
This was a very hard problem to track down and you can see my progress (and that of Ron, who kindly helped me a lot, thanks Ron!) on the 'official' building Bitcoin thread on bitcointalk.org. Starting at page 28 and continuing down until you don't see my name anymore (I'm called Jori there too, it's my real name).

that mean leveldb not compiled properly, on cygwin I use
make -f makefile.unix clean
TARGET_OS="Linux"; make -f makefile.unix

with mingw TARGET_OS maybe Linux or NATIVE_WINDOWS
also try change permission leveldb/build_detect_platform to make it as executable


text:
Transaction version 2 - bytes between tx version and number of inputs
In the bitcoin transaction version 2, there are additional two bytes (hex: "0001") between transaction version (hex: "02000000"), and number of inputs (hex: "01"). What it is?
Here's an example https://btc-explorer.com/tx/4f692e7fb63256e4e741b952935e929ad545838d3697c5ee3f044a250c45fb4a
transaction hex: "020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff4b031a0608048187145b622f4254432e434f4d2ffabe6d6dec50b9ca7f0e6731e89a2516f3df5fd7d65462ed2e68df7bf8e375232b7b28c701000000000000006200de217cb2aaea00000000ffffffff0212b0bf4a000000001976a91478ce48f88c94df3762da89dc8498205373a8ce6f88ac0000000000000000266a24aa21a9ed89dbbf72d51df862d19e0baa551d87e69b65a452496ec9d8203de66c754c30330120000000000000000000000000000000000000000000000000000000000000000000000000"

That is not something specific to version 2 transactions.
What you are looking at are the marker and flag bytes for a segwit transaction. Segwit transactions have a slightly different transaction format which is specified in BIP 144.

You might be interested in my article The Bitcoin Script Language. A part of that is to go into details of the transaction format. Especially helpful is this graphic I've created:

To answer the question directly: The first one is called "marker", the second one is called "flag". BIP 144 gives more details:

Rationale for not using just a single 0x00 byte as marker: that would lead to empty transactions (no inputs, no outputs, which are used in some tests) to be interpreted as new serialized data.
Rationale for the 0x01 flag byte in between: this will allow us to easily add more extra non-committed data to transactions (like txouts being spent, ...). It can be interpreted as a bitvector.

See BIP 141