text:
Sendmany bitcoin core
I am trying to use the sendmany parameter of bitcoin-cli. My problem is as follows: is there any way that I could tell sendmany, to calculate the input accounts based on the balances, instead of using a specified account as the first parameter?
I've read, that the accounts parameter is deprecated, and shouldn't be used anymore, if this is the case, what is the proper usage of the sendmany function?
Others have written, that in this case, the first parameter should be simply ommited by adding a "" the empty string to it, but I somehow managed to create an address which has as it's account name, the empty string "". Whenever I try to use sendmany with the empty string it always says that I have insufficient funds (which is true, if we look at the address with the empty string as account name, but it would be false, looking at all the other addresses that I have).
I've tried to find a way, to delete the address which has the empty string as it's account name, but I couldn't find a way to do this.
Anyone facing/faced a simmilar situation that knows a solution to this?

I don't know the answer, but you should probably file a bug report that it's possible to get into this situation in the first place.  The only way I can think of to recover is to dump all your private keys and import them into a new wallet (without using accounts this time).

Basically, it looks like, that when I create my wallet, Bitcoin Core automatically creates an empty account for me, with an address.

Tthe empty string "" is for the default account, not for all accounts in your wallet. Whenever you add a label to an address, what you are really doing is adding it to an account. If you want to be able to spend from all of your addresses, you will need to move all of your addresses into the same account, i.e. remove their labels and make them the same label.

There is also a "move" command that simply increments the balance of one account and decrements another. You can use this to move all balance to one account.


text:
Understanding Kraken Trades API (market/limit)
I want to build historical OHLC data from the Kraken trades. Since Kraken does not provide historical OHLC data (at least not going far back), they recommend one builds it oneself using the list of trades (https://support.kraken.com/hc/en-us/articles/218198197-How-to-pull-all-trade-data-using-the-Kraken-REST-API). Their trades API does indeed return trades as far back as October 2013, but I do not understand how to interpret the data.
They return the following information for each trade (see https://www.kraken.com/help/api#get-recent-trades):

Price
Volume
Time
Buy/sell
Market/limit

All of these make sense except the last one, market/limit. How can a trade be a market trade or a limit trade? I am very familiar with market and limit orders, but I thought that every trade is a market order matched against one or more limit orders. So how can a trade be market or limit?
Can I perhaps treat a market sell trade as a limit buy trade and vice versa? And so it would just be random whether they call it market sell or limit buy? This would seem a little odd to me...
Any insight would be appreciated!

Hi Flecto. Building historical data from kraken as well. I'm looking for OHLCV for 1 minut as far as possible for BTCEUR. Do you have that?

No, I didn't download BTCEUR, since I'm only interested in USD and crypto pairs. Here's the Python script I use to download trade data from Kraken: https://pastebin.com/jeP2QEUQ This dumps all the trades in an HDF5 file. I then use other code to aggregate the trades into 1 minute (or any other timeframe) OHLCV data. Hope this helps!

Hi @Justme, I may have what you need. Let me know on gilmijar at gmail.

Indeed they don't specify what it means, but the only sane option is that market/limit tag comes from the type of order that closed the deal.
For example there are two lowest sell(ask) orders hanging in the order book:

0.05 BTC at 2000 EUR
0.03 BTC at 2300 EUR

I come to Kraken and place a Market order, buy(bid) for 0.07 BTC, thus the first trade will be for 0.05 BTC, and the second will be for 0.02 BTC. Both will have designation 'market'.
It is possible, however that I want to buy some bitcoin, (let's say 0.9 BTC), but not higher than 2300 EUR. Then to make sure I don't pay more than planned, I make a LIMIT order and the two awaiting orders are matched to mine and what is left of my order amount may hang in the order book on the Buy side. In this scenario the trades as seen via API will have designation 'limit'

source: Stack Exchange

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

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

sort: votes


text:
Error compiling litecoin clone, boost error
I am trying to clone litecoin for practice and for some reason this time around my build system isn't working right.
Here is the error I am having after trying to compile my clone AND litecoin 8.7.4 source
bitcoinrpc.cpp:984:52:   required from here
/usr/include/boost/thread/once.hpp:38:18: error: no matching function for     call to ‘call_once(boost::once_flag&, void (*&)())’
     call_once(flag,func);
              ^
In file included from /usr/include/boost/thread/once.hpp:20:0,
             from /usr/include/boost/thread.hpp:17,
             from util.h:24,
             from bignum.h:12,
             from main.h:8,
             from wallet.h:13,
             from init.h:8,
             from bitcoinrpc.cpp:6:
/usr/include/boost/thread/pthread/once_atomic.hpp:121:15: note: candidate: template<class Function, class ... ArgTypes> void boost::call_once(boost::once_flag&, boost::detail::thread_move_t<T>, boost::detail::thread_move_t<Args>...)
   inline void call_once(once_flag& flag, BOOST_THREAD_RV_REF(Function) f, BOOST_THREAD_RV_REF(ArgTypes)... args)
           ^
/usr/include/boost/thread/pthread/once_atomic.hpp:121:15: note:   template argument deduction/substitution failed:
In file included from /usr/include/boost/thread.hpp:17:0,
             from util.h:24,
             from bignum.h:12,
             from main.h:8,
             from wallet.h:13,
             from init.h:8,
             from bitcoinrpc.cpp:6:
/usr/include/boost/thread/once.hpp:38:18: note:   mismatched types ‘boost::detail::thread_move_t<T>’ and ‘void (*)()’
     call_once(flag,func);
              ^
/usr/include/boost/thread/once.hpp:35:13: note: candidate: template<class         Function> void boost::call_once(Function, boost::once_flag&)
inline void call_once(Function func,once_flag& flag)
         ^
/usr/include/boost/thread/once.hpp:35:13: note:   template argument deduction/substitution failed:
/usr/include/boost/thread/once.hpp:38:18: note:   cannot convert ‘func’   (type ‘void (*)()’) to type ‘boost::once_flag&’
     call_once(flag,func);
              ^
make: *** [obj/bitcoinrpc.o] Error 1

Could someone please let me know what this is? I tried an issue and change a line in rpcrawtransaction.cpp
<const CScriptID &>

to
<CScriptID>

and also tried code snippet from feathercoin, both unsuccussful.
Would be greatly appreciated if someone could help get my system buildable again.

Nevermind, sorry, I got past that part. I had clang as the compiler from update-alternatives, had to switch back to gcc. Currently compiling right now hopefully no more errors.

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


text:
ELI5: How does Segregated Witness (segwit) work?
Can someone ELI5 Segregated Witness (AKA BIP 141)? I've been doing research and understand that there are segwit addresses, there are segwit transactions, and there are segwit nodes.
I understand that segwit basically works by removing the witness from the scriptSig and somehow it's weighed 1 weight point while other bytes are weighed at 4 weight points, but how?
How do older bitcoin nodes handle the segregated witness? Do they just not receive that data? I know that older nodes will treat those addresses as spendable by anyone since no witness is present or needed. This makes me believe the witness isn't in the transaction at all. But how? Where is the witness actually stored?
Where do segwit addresses come into all of this?

Not all unspent outputs need signature scripts. Of course, this doesn't have many uses (but puzzles. for example, proof of SHA256 collision to redeem funds) but such a thing exists. UTXO that don't need a ScriptSig are called an AnyoneCanSpend outputs. Such transactions are considered nonstandard and are not relayed in the network. However, if a miner includes a nonstandard transaction in their block, their block will be valid and the transaction will be relayed.
A SegWit-P2WSH output looks like this:
00148ca0e5d2474900bf82376926da8c5f4464bd7bd3

Does it start with a version byte? ✓
Does it have a 20-byte Witness Program*? ✓
Is the ScriptSig empty*? ✓
*Doesn't have to be. Details: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
Congrats, that's a SegWit output! Legacy nodes see it as a nonstandard transaction, and don't relay it. The SegWit nodes check the output for the conditions above, understand that it's a SegWit output. Next, they check the transaction for a valid "witness". It's not a nonstandard transaction for them, and they relay it to the other SegWit nodes. After a miner puts it in their block, legacy nodes will understand that it's a nonstandard/AnyoneCanSpend script, and will honor it.

Makes sense, but where does the witness end up in this situation? And where does the segwit address come into play?

@arshbot Transactions have a witness part (https://bitcoincore.org/en/segwit_wallet_dev/#transaction-serialization example (enable advanced info): https://blockchain.info/tx/c586389e5e4b3acb9d6c8be1c19ae8ab2795397633176f5a6442a261bbdefc3a) The scriptSig carries the version + witness program, which is not the witness itself, but the hash of the pubkey in the witness part: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wpkh-nested-in-bip16-p2sh

I stumbled over the "not a nonstandard" phrasing. You could just say it's a standard transaction for segwit-enabled nodes. ;)

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


text:
non-mandatory-script-verify-flag (Locktime requirement not satisfied) (code 64)
I'm attempting to redeem the following htlc ( the python script below ) via timeout, however the redemption tx errors out upon validation with the error below:
bitcoin.rpc.VerifyRejectedError: {'code': -26, 'message': 'non-mandatory-script-verify-flag (Locktime requirement not satisfied) (code 64)'}

Deserializing the funding tx has a transaction locktime of 422 while the current blockheight is 433. The final tx has a locktime of 434, so I'm unsure what the issue could be.
htlc test script using python-bitcoinlib:
import sys
if sys.version_info.major < 3:
    sys.stderr.write('Sorry, Python 3.x required by this example.\n')
    sys.exit(1)

import bitcoin
from bitcoin import rpc
from bitcoin import SelectParams
from bitcoin.core import b2x, lx, b2lx, COIN, COutPoint, CMutableTxOut, CMutableTxIn, CMutableTransaction, Hash160
from bitcoin.core.script import CScript, OP_DUP, OP_IF, OP_ELSE, OP_ENDIF, OP_HASH160, OP_EQUALVERIFY, OP_CHECKSIG, SignatureHash, SIGHASH_ALL
from bitcoin.core.script import OP_DROP, OP_CHECKLOCKTIMEVERIFY, OP_SHA256
from bitcoin.core.scripteval import SCRIPT_VERIFY_P2SH # VerifyScript
from bitcoin.wallet import CBitcoinAddress, CBitcoinSecret

import hashlib
from utils import VerifyScript
from bitcoin.core.script import *
from bitcoin.core.scripteval import *
from bitcoin.core.scripteval import _CheckExec, _ISA_BINOP, _ISA_UNOP, _CastToBool, _CheckSig

SelectParams('regtest')
proxy = bitcoin.rpc.Proxy()

# Set the preimage. This is the secret Bob will need to redeem the htlc
preimage = bytes(b'preimage'.hex(), 'utf8')

# Hashed version of the preimage which we can safely store on the blockchain
# and use to verify against what Bob offers
h = hashlib.sha256(preimage).digest()

# Bob
recipientpubkey = proxy.getnewaddress()

# Alice
senderpubkey = proxy.getnewaddress()

# privkey of Alice, used to sign the redeemTx
sender_seckey = proxy.dumpprivkey(senderpubkey)

# privkey of Bob, used to construct the htlc
recipient_seckey = proxy.dumpprivkey(recipientpubkey)

# How long the htlc will last until it times out
lockduration = 1
blocknum = proxy.getblockcount()
redeemblocknum = blocknum + lockduration

# We construct the locking script in the form of a standard bip199 htlc
txin_redeemScript = CScript([
    OP_IF,
        OP_SHA256, h, OP_EQUALVERIFY,OP_DUP, OP_HASH160, bytes(Hash160(recipient_seckey.pub)),
    OP_ELSE,
        redeemblocknum, OP_CHECKLOCKTIMEVERIFY, OP_DROP, OP_DUP, OP_HASH160, bytes(Hash160(sender_seckey.pub)),
    OP_ENDIF,
        OP_EQUALVERIFY, OP_CHECKSIG
])

# Generate a P2SH address from the locking script
txin_scriptPubKey = txin_redeemScript.to_p2sh_scriptPubKey()
txin_p2sh_address = CBitcoinAddress.from_scriptPubKey(txin_scriptPubKey)
p2sh = str(txin_p2sh_address)

# Load the htlc
amount = 1.0*COIN
fund_tx = proxy.sendtoaddress(txin_p2sh_address, amount)

# Fast forward time
print('before height ' + str(proxy.getblockheader(proxy.getbestblockhash(), True)['height']))
print('locktime ' + str(lockduration))
proxy.generatetoaddress(lockduration + 10, proxy.getnewaddress())
print('after height ' + str(proxy.getblockheader(proxy.getbestblockhash(), True)['height']))

# Construct the transaction which will redeem the htlc via the first payment route
txinfo = proxy.gettransaction(fund_tx)
txin = CMutableTxIn(COutPoint(fund_tx, txinfo['details'][0]['vout']))
default_fee = 0.001*COIN
txout = CMutableTxOut(amount - default_fee, senderpubkey.to_scriptPubKey())
tx = CMutableTransaction([txin], [txout])
tx.nLockTime = proxy.getblockheader(proxy.getbestblockhash(), True)['height'] + lockduration
# Sign the redeem script with Alice's private key ( for whose address the first payment path
# is set up exclusively for )
sighash = SignatureHash(txin_redeemScript, tx, 0, SIGHASH_ALL)
sig = sender_seckey.sign(sighash) + bytes([SIGHASH_ALL])

# Load the script sig of Bob's redemption transaction with the appropriate values
txin.scriptSig = CScript([
    sig,
    sender_seckey.pub,
    0,
    txin_redeemScript])

# Verify
VerifyScript(txin.scriptSig, txin_scriptPubKey, tx, 0, (SCRIPT_VERIFY_P2SH,))

# Send
txid = proxy.sendrawtransaction(tx)

You're setting the tx.nLockTime to the current block height + how long you want to lock it. That's obviously still in the future.

Wouldn't that value only apply to the tx that seeks to redeem that transaction? ( that transaction being which redeemed the original htlc ). I went ahead and tried changing tx.nLockTime to the expected current block height and to a block height in the past - the same error persists

A transaction with an nLockTime in the future cannot be included in the blockchain. An OP_CHECKLOCKTIME oocode checks the nLockTime field of the transaction spending the output in which the script appears (it does not check the block height itself)


text:
Fundamentally what is the difference between the EOS and Ethereum platforms?
I know one platform is owned by a company, block.one which owns 10% of all EOS tokens, I'm aware of their ICO structure and it seems their tokens are used as a sort of API token - some have called the ICO and EOS a real estate purchasing system.
Contrasted to Ethereum where ether tokens are used to fund commands performed on the decentralized machine that is the EVM (Ethereum Virtual Machine) which can be in the form of account transfers to calling a function on a smart contract.
However, fundamentally what is the difference between these two platforms? How do they work and how are they different?

The jump between Ethereum to EOS isn't nearly as big as was from Bitcoin to Ethereum. The same concept of using smart contracts applies, but EOS has the following "improvements":
1) Ethereum is currently partially proof-of-stake but will be fully soon. EOS is launched as completely proof-of-stake.
2) EOS has no transaction fees. The developers realized that fees limit the growth of the network, because no dAPP running hundreds of transactions per second wants to pay a fee. The incentive to "Stake" your EOS tokens and confirm transactions as a block producer comes from inflation... at the rate of 5% per year.
3) EOS will certainly handle thousands of transactions per second when they mainnet launch in June. Ethereum currently has 7 tx/sec, which will very likely increase significantly. However, by that time EOS could potentially be running hundreds of thousands of tx/sec as their code is meant to run on parallelized servers.
4) Uses 21 block producers that act like state governments to that can vote to make changes to the constitution. Users and dAPPs vote for block producers that they think best benefit the community. Ethereum dAPPs don't have this governance structure, but there are a few emerging (ie. 0x).
5) Plans to implement cross-chain communication using state channels. This would mean EOS interoperability with Ethereum and Bitcoin. Technically Ethereum can do this, but EOS is heavily developing on this concept at the moment.

What are some good resources to look at for technical details on what you've described on the EOS side of things?

I found this to be a good reference for when I first got into EOS. Don't let the title confuse you... It's certainly not meant for dummies! https://steemit.com/eos/@trogdor/eos-vs-ethereum-for-dummies


text:
rpc error: code = Unknown desc = dial tcp 103.102.44.207:9735: connect: connection refused
I'm getting connection refused when I try to connect to a public testnet node.
lncli --network=testnet connect 022ff54505fe9b50ce6c3c99c645c9aab67fe91abb01504c5211045b82a09aa757@103.102.44.207:9735

Error
[lncli] rpc error: code = Unknown desc = dial tcp 103.102.44.207:9735: connect: connection refused

You need to connect to a node which has:

RPC enabled
username and password are known
client IPs are whitelisted using rpcallowip
the router has its port forwarding enabled.

Usually, public nodes don't share their RPC parameters, because that'd be very insecure. My advice is, run your own node. Otherwise, you could use the experimental neutrino client.

I forgot to update my question with the answer, turns out the public node I tried to connect to was down, and the 2nd node I spun up was still syncing and therefor wasn't up. I tried more than a few on the list until I found one that worked. I'll mark yours as correct as those are valid steps.


text:
What is happening when a channel is pending?
What is happening when a channel is pending when opened? How long does it usually take? To open a channel with a node you're already connected to you don't need to get consensus from all the other connected nodes (as you would if you were sending a transaction on chain) so why the wait?

Opening a channel involves sending an on-chain transaction (with a multisig output controlled by the channel’s participants), so when the channel is ‘pending’ it simply means this transaction is not yet confirmed. How long it takes the transaction to confirm depends on the same factors as any other transaction.
Further, the participants will often wait for a certain number of transaction confirmations before starting to make channel payments. The number of confirmations required is negotiated in the minimum_depth parameter of the accept_channel message. From BOLT 2:

The funding_locked message indicates that the funding transaction has reached the minimum_depth asked for in accept_channel. Once both nodes have sent this, the channel enters normal operating mode

(thanks to @jnewbery for the added info)

@selfishminer you should add your edit as a separate answer since it is a complete re-write compared to mine, but I think it is helpful.

"Once the transaction confirms..." the participants actually wait for a certain number of confirmations before starting to make channel payments. The number of confirmations required is negotiated in the minimum_depth parameter of the accept_channel message. From BOLT 2: "The funding_locked message indicates that the funding transaction has reached the minimum_depth asked for in accept_channel. Once both nodes have sent this, the channel enters normal operating mode."

@jnewbery thanks for the clarification/extra info, I've edited the answer to include it

What is happening when a channel is pending when opened? How long does it usually take?

A node establishes a channel by sending an open_channel message to its desired peer. This message specifies the parameters under which the channel will operate (e.g. the number of bitcoin the channel will be funded with and the cost to route payments through the channel). The channel counterparty must reply with the accept channel message, one parameter of which is minimum_depth, wherein the number of confirmations the funding transaction must have (before the channel can be used) is specified. This protects channel participants from losing money in the event the funding transaction is double spent.

To open a channel with a node you're already connected to you don't need to get consensus from all the other connected nodes (as you would if you were sending a transaction on chain) so why the wait?

Establishing a network connection with a node is only one step in the process of establishing a lightning channel. The funds must first be secured in a multisignature output (2-of-2, with one key from each channel participant). Moving the funds to a multisignature output can only be done with an on-chain transaction. Without this step there is no way to restrict one party from stealing the funds outright. Once the funds have been moved to such an output, channel participants can make lightning transactions.


text:
how many htlcs can a lightning channel have pending at a given time
Channels can have pending HTLCs, or even handle multiple payments concurrently. Is there a max number of pending HTLCs a channel can entertain? What is that max, why is it set to that number, and what are potential ramifications of a higher value (is latency a concern?)

related: https://bitcoin.stackexchange.com/questions/93720/lightning-network-how-was-the-maximum-allowed-htlcs-in-flight-computed

483 because the commitment transaction might otherwise become too large if it hits the chain.
Ramifications are:

blackmail fee attacks (c. F. https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002735.html a similar attack is known as  flood  and loot)
possible congestion of channels (right now only if conducted by an attacker but later potentially due to payment delivery and high routing demand on channels.)

To mitigate those attacks currently most nodes have 30 htlcs as a default value.


text:
ScriptHash from bitcoin address with BitcoinJS
I need to interact with Electrum server API, in order to get UTXOs of a bech32 address.
Electrum doesn't support bech32 but supports searching by ScriptHash, which is  be obtainable from an address.
I think that the name ScriptHash is a little ambiguous here (i think locking script hash can make more sense)
So how can i get the scripthash from the address as in the following example using bitcoinjs :
       {'priv': 'L8g5V8kFFeg2WbecahRSdobARbHz2w2STH9S8ePHVSY4fmia7Rsj',
        'pub': '03e9f948421aaa89415dc5f281a61b60dde12aae3181b3a76cd2d849b164fc6d0b',
        'address': 'bc1qqmpt7u5e9hfznljta5gnvhyvfd2kdd0r90hwue',
        'minikey': False,
        'txin_type': 'p2wpkh',
        'compressed': True,
        'addr_encoding': 'bech32',
        'scripthash': '1929acaaef3a208c715228e9f1ca0318e3a6b9394ab53c8d026137f847ecf97b'}

Got the answer via github
let script = bitcoin.address.toOutputScript(address)
let hash = bitcoin.crypto.sha256(script)
let reversedHash = new Buffer(hash.reverse())

console.log(address, ' maps to ', reversedHash.toString('hex'))

Note that -for some reason- Electrum uses the reverse scripthash

can you post the result of the output please?

Ya, most things in bitcoin need to have big-endian/little-endian conversion


text:
Why do you have to mine 432 blocks to activate segwit on regtest?
According to Rusty Russel, you need to mine 432 blocks to activate segwit on regtest. Why this specific blockheight?
Sources:

https://rusty-lightning.medium.com/segregated-witness-for-developers-8fa9042f43ed#.6ur6kr5nf
https://github.com/ElementsProject/lightning/blob/f4e94147a7281ec05e078ff9f3e6d65893417bad/test-cli/scripts/generate-block.sh#L11

Note that since 0.16, Segwit is always active on regtest from the genesis block.
Prior to 0.16, Segwit on regtest is defined to have a start time of 0 and can be activated through the BIP 9 versionbits mechanism. In BIP 9, the genesis block always has the state of DEFINED, which means that the signaling period beginning with the genesis block is DEFINED and any signaling in that period does not count for segwit.
Segwit would become STARTED in the second signaling period and only then would signaling blocks be counted. If the threshold is reached, then it will become LOCKED_IN during the third signaling period. Once the third signaling period concludes, Segwit will be active. So under ideal circumstances where all blocks signal for Segwit, 3 signaling periods are needed for Segwit to become active.
In Regtest, each signaling period is 144 blocks. 144 * 3 = 432 blocks need to be mined for Segwit to become active.


text:
How much information can a single taproot output hold?
Does taproot make OP_RETURN obsolete? How much information can I stuff into an output? A tapscript leaf? Is there a max depth to the tapscript tree?

I think your question is confusing two things:

Commitments to data: using the blockchain as proof that some data existed before some point in time
Publishing data: making everyone actually see the data.

There are fundamentally different goals, and what you need depends on the purpose:

In case you want to timestamp something, a commitment is sufficient. A commitment can be achieved using a transaction with an OP_RETURN that contains a hash of the data, but there are many other, and more private, approaches. For example, it is possible to create a completely ordinary ECDSA signature on-chain, for a normal transaction that actually moves money, to an address that wasn't in any way specially designed for this purpose, which in fact "mixes in" some additional data. The signature cannot be distinguished from a normal signature, but together with an external proof, is evidence that this signature could not have been made without using said data. This approach is called sign-to-contract.
Commitments are not sufficient if you want to use a transaction to convey information to the recipient, like a message. This is a bad idea for several reasons, but ignoring that: if you'd use a commitment like sign-to-contract here, the recipient wouldn't know a message existed. You'd need to give them the message and the proof the transaction commits to it out of band, and if you need to communicate with them out of band, you could just give them the message directly there.
Commitments also do not prevent you for example from committing to two "conflicting" pieces of information. For example keybase.io periodically publishes a hash of their entire database on the Bitcoin blockchain. Even though it is only a hash, a commitment would not suffice, as the entire point is making allowing users to verify that keybase.io is providing the same database for everyone. With just a commitment, they could maintain two distinct trees, and reveal one to some users, and the other to other users.

Mechanisms for publishing include OP_RETURN outputs in transactions, or stuffing things in the keys raw multisig outputs, or stuffing data in witnesses (by using a script with an OP_DROP for example). Mechanisms for commitments include storing a hash using a publishing mechanism, but also the aforementioned sign-to-contract (which commits to data in signatures) or pay-to-contract (which commits to data in public keys).
Now back to your question: taproot does not help in either case. Yes, the taproot script Merkle tree means you can commit to lots of pieces of data, but you can already do that: just compute a Merkle root yourself of these pieces of data, and then commit/store that root. It also doesn't help with publishing, because the leaves are not published on output (only the tweaked public key is). You could reveal data when spending a P2TR output (by having the data in a leaf, and then spending through that leaf), but that doesn't let you do anything that isn't already possible with P2WSH.
Lastly, the script tree in taproot is limited to max 128 levels, but this doesn't affect the rest of what you're asking about.

I don't see how P2TR would benefit OP_RETURN applications at all. The scripts in the leaf are only published on spending which doesn't happen for NULLDATA outputs at all.


text:
What are the malleability threat vectors when passing PSBTs to other actors?
If I am passing a PSBT (Partially Signed Bitcoin Transaction) between multiple people, and I pass on my signature for my UTXOs for given inputs, can someone take advantage of malleability and cheat me out of the outputs I'm expecting?
What are the full ramifications of this? What is the most I can be taken advantage of, and is there any defense other than using funding with segwit spends? Can you be specific on how exactly such an attack would occur, and what portions of the PSBT might a malicious actor pay most attention to

If I understand right what you are suggesting, I don’t think this attack is feasible.
Assuming your inputs use the SIGHASH_ALL transaction commitment, it does not matter whether you are the first or last to sign the PSBT: your signature will only be valid for a transaction that creates exactly the outputs that you signed for. When another participant malleates one of your signatures, they will only change the final transaction’s txid (wtxid if they malleate the signature on a segwit input). While a changed txid could be a problem in the context of a pre-signed chain of transactions, it will not alter the outcome of the transaction itself.


text:
Questions about Bitcoin Transactions
I was playing around with my Bitcoin Node, to try and understand how does Bitcoin Transactions work.
For this purpose, I used the sendtoaddress API call for bitcoin-cli, to send some XBT to my own Bitcoin Blockchain.Info wallet. The transaction was processed, and I was trying to understand the information that I get from gettransaction bitcoin-cli command, and the information that the Blockchain.info website shows about the transaction.
So, here is what I did:

I've generated a receiving address for myself in Blockchain.Info (17tzZwAi722L7V8V27bUGEKwJpRYVNRKVW)
In my Bitcoin node, I used the following command: bitcoin-cli sendtoaddress 17tzZwAi722L7V8V27bUGEKwJpRYVNRKVW 0.001

This gave me back a transaction id: 4f299e7313af7e4e091ea519bbf5983526d18fe4765b679ce1827bd9f75dbaff

I then checked the information that the bitcoin node gives about that transaction with: bitcoin-cli gettransaction 4f299e7313af7e4e091ea519bbf5983526d18fe4765b679ce1827bd9f75dbaff

What I noticed here is that the bitcoin-cli command gave me back the address I sent the money to, the fee it took to get the address, but it didn't tell me from which address the transaction was sent from.
Then I checked the information that Blockchain.info provides about the transaction: https://blockchain.info/tx/4f299e7313af7e4e091ea519bbf5983526d18fe4765b679ce1827bd9f75dbaff
Here, it can be clearly seen that an amount of 0.06611392 BTC was sent from 12bFMAPz7dhKmLxsoipfUqmCCjqENCDzKb XBT address, to two different outputs. One of the output is the address, Blockchain.Info gave me to receive the Bitcoin. The other output is an address unknown to me.
So I started thinking:
Am I correct, that when sending a bitcoin transaction, all of the amount from a specific address gets placed in the input, a part of it(the part which I specify) gets sent to the address I wish to send, and the rest gets transfered to a newly created address on the same wallet, from which the send operation was initiated?
Some other questions which arise to me:
How is Blockchain.Info able to retrieve information from any kind of Bitcoin Transaction, while I, using a full Bitcoin Node, can only find transactions which was either initiated by the node, or which has a receiving address which is in the nodes wallet?

but it didn't tell me from which address the transaction was sent from

Indeed, there is no 'from address' in a bitcoin transaction. (More info)

Am I correct, that when sending a bitcoin transaction, all of the amount from a specific address gets placed in the input, a part of it(the part which I specify) gets sent to the address I wish to send, and the rest gets transfered to a newly created address on the same wallet, from which the send operation was initiated?

Correct, inputs are spent all at once, there's no way to partially spend it, so you have to send some change back to yourself. The sendtoaddress manages that all for you.

How is Blockchain.Info able to retrieve information from any kind of Bitcoin Transaction, while I, using a full Bitcoin Node, can only find transactions which was either initiated by the node, or which has a receiving address which is in the nodes wallet?

That's a lot of data that bitcoin core doesn't usually need or use, so it's not usually indexed or accessible by bitcoin core. It's possible to use the -txindex configuration option to index all transactions including those not related to your wallet. But blockchain.info and similar block explorers probably run their own databases of information rather than querying it from a bitcoin node every time, allowing them to do more complicated searches in the data.

How is Blockchain.Info able to retrieve information from any kind of
  Bitcoin Transaction...

It is not only blockchain.info who can decompose your transaction. The format of a transaction is layed out on bitcoin.org. So if you take your own transaction, you as well can decompose it into it's pieces.
You can have a look at the details of your (or any other) tx with
https://blockchain.info/rawtx/
I just did the same with "my" local tools, and got this from the script sig:
 TX_IN[0] Script Sig (uchar[])
  4730440220415AE7C712D07CD1F0A98170021FBE3A073DECB569A66F63B28FD2725471EE57022061FE1093885C39D23E1EFE19700D1B8E49619DF526AD0D63CDBF985E2178C34C0121025AB144C5BDD83410487BF2694CA398E3D860D2465E0305DCEC429BA6F1CF8C59
  ##################################################################
  ### tcls_in_sig_script.sh: decode SIG_script OPCODES from a TX ###
  ##################################################################
    47: OP_DATA_0x47:     push hex 47 (decimal 71) bytes as data
    30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
    44: OP_LENGTH_0x44:   length of R + S
    02: OP_INT_0x02:      type tag indicating INTEGER
    20: OP_LENGTH_0x20:   this is SIG R
        415AE7C712D07CD1:F0A98170021FBE3A
        073DECB569A66F63:B28FD2725471EE57
    02: OP_S_INT_0x02
    20: OP_LENGTH_0x20:   this is SIG S
        61FE1093885C39D2:3E1EFE19700D1B8E
        49619DF526AD0D63:CDBF985E2178C34C
    01: OP_SIGHASHALL:    this terminates the ECDSA signature (ASN1-DER structure)
    #########################################################
    ### procedure to strictly check DER-encoded signature ###
    #########################################################
    Minimum and maximum size constraints                        - ok
    scriptsig always starts with 0x30                           - ok
    length 136 chars is less than actual sig length (142 chars) - ok
           (hex 0x44, decimal 68, 136 chars)
    length of R coordinate (64) >= 0                            - ok
    length of S coordinate (64) >= 0                            - ok
    S-Value is within scriptsig boundaries                      - ok
    Make sure the R & S length covers the entire signature      - ok
    S-value must be smaller than N/2                            - ok
    strictly check DER-encoded signature                        - ok
    #########################################################
    21: OP_DATA_0x21:     type tag indicating LENGTH
    02: OP_INT_0x02:      type tag indicating INTEGER
        5AB144C5BDD83410:487BF2694CA398E3
        D860D2465E0305DC:EC429BA6F1CF8C59

    * This terminates the Public Key (X9.63 COMPRESSED form)
    * corresponding bitcoin address is:
   12bFMAPz7dhKmLxsoipfUqmCCjqENCDzKb

as you can see, it contains your address in the last line. The script sig is part of a transaction, and the tx is stored in the block chain. So as long as one can read the blockchain, one can finally decompose the tx.
The bitcoin wallet just doesn't show the details you were asking. I think the command "decoderawtransaction" would help to display the structure.
Oh, there is no need to ask twice or more in different forums (https://bitcointalk.org/index.php?topic=2187720.0). This is meaningless bloat...

authors: Лолита Сонина


text:
Can I find a list of possible error codes and their meanings for bitcoin-cli?
Can I find a list of all of the error codes and their meanings which a bitcoin node can return when using the RPC commands?

Here is the list inside the Bitcoin Core v0.15.0.1 source code:
https://github.com/bitcoin/bitcoin/blob/v0.15.0.1/src/rpc/protocol.h#L32L87

not to easy, you might want to read the code:
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list#Error_Codes


text:
Litecoin-cli validates segwit bitcoin address as valid litecoin address
I was messing around with litecoin-cli and found some strange behaviour. If I try to validate a segwit bitcoin address, with the litecoin-cli it returns as a valid litecoin address.
Is this the intended behaviour, or is this a bug?
[user@server ~]# bitcoin-cli getnewaddress
13nKR2gooAr6MEZev2NsQ5RjQPHBs4vY8g
[user@server ~]# litecoin-cli validateaddress 13nKR2gooAr6MEZev2NsQ5RjQPHBs4vY8g
{
  "isvalid": false
}
[user@server ~]# bitcoin-cli addwitnessaddress 13nKR2gooAr6MEZev2NsQ5RjQPHBs4vY8g
39kzm57uJi8iZ9qJWGivVjf44XYJFLur9M
[user@server ~]# litecoin-cli validateaddress 39kzm57uJi8iZ9qJWGivVjf44XYJFLur9M
{
  "isvalid": true,
  "address": "39kzm57uJi8iZ9qJWGivVjf44XYJFLur9M",
  "scriptPubKey": "xxxxxxxxxxxxxxx",
  "ismine": false,
  "iswatchonly": false,
  "isscript": true
}

`

No, this is working as intended. When litecoin first introduced segwit, they also used 3.... adresses. They were (are) generated the same way ( Using the same P2SH as bitcoin.).
These now start with an M.., but because of backwards compatibility these 3... adresses are still valid. (but no longer used.)
I guess this issue covers what you are facing pretty well - https://github.com/litecoin-project/litecoin/issues/433


text:
Are Bech32 addresses safe for mainnet usage?
According to github bitcoin/bips, BIP-173 is still a draft. And i saw today that Electrum wallet start using it.
Is this means that the specs for BIP-173 won't change in the future ? or the final version won't introduce breaking changes to the draft version ?
I just learned about Bech32 addresses this week and this gets me a little confused

Yes, they are. Bech32 addresses allow for native Segwit outputs, which offer higher efficiency and security than the legacy P2SH nested Segwit outputs. https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Reference_implementations has reference implementations in C, C++, JS, Go, Python, Haskell, Ruby, and Rust along with tests courteous of Pieter Wuille

Thanks a lot @satoshi_ghost ! i have been waiting this answer for a long time :D

Pieter Wuille just moved the BIP from draft to proposed (https://github.com/bitcoin/bips/pull/627).


text:
How does TXID gets created and at which point
I see TxID in bitcoin transaction input as reference of the UTXO. How does TXID gets created and at which point, wallet or node?

The TXID, the transaction ID, is a hash of the serialized (non-witness) transaction whose UTXO is being spent. It gets created at the same time as the transaction does

Thanks for the answer. So what gets broadcast on network, Only TxID or both TxID and serialized entire transaction? I believe second.

You only need to send the serialized transaction itself, because anyone can hash it to find the txid. But generally the txid would be sent first so the client can see if they already have it or not


text:
how many miners should validate a block before its considered valid?
How many miners should validate a block before it gets added to the blockchain?
Or does every miner add the blocks it receives to its local blockchain?

Miners don't really actively validate blocks during the mining process. Miners find valid blocks and broadcast them to the network. It is up to the full-validating nodes on the network as to whether a block is accepted or rejected.

The miner adds the blocks it receives to its local blockchain (normally).
When a miner receives a new block he will likely check whether that block is valid. No one forces the miner to do that but if he does not check the validity of the new block he takes the risk of mining on an invalid block. If a miner mines on an invalid block he wastes his resources because the network won't accept his block in case he finds one.
After the miner made sure that the new block is valid, he will probably add it to his copy of the blockchain. I write probably because again you cannot know what the miner will do. He might also decide to dismiss the new block even though it is perfectly valid. He would however again risk to waste his resources in this case.


text:
Who managed bitcoin and ethereum decision making? Who approves Bitcoin upgrades and forks?
To my knowledge in Bitcoin and Ethereum decision makings are decided by the miners and developers. I like to know who makes the final say on the approval of a change to Bitcoin/Ethereum code or process? Is it a selection of miners/developers? Or is there a consortium or a foundation that has the final say for major/minor changes to the blockchains?
How are the developers who merge the bug fixes and other changes to the main(Master) blockchain Git branch are selected?
Is most of the decision making done on random forums and by websites volunteerly deciding to participate in these tasks? Why would a website decide to show the progress of voting on a particular blockchain fork? and how to ensure that site is credible?

You pose several interesting questions regarding the centralization of the governance and development of Bitcoin and Ethereum.
You accurately mentioned that decision making is done by miners and developers. There are some centralized repositories where the development of Bitcoin and Ethereum takes place. However, nothing prevents a developer from independently forking the code and adding their own changes which are not approved by the maintainers of the main git repository.
Who has the final say on the approval of a change to code? A change in the code is approved by the maintainers of the respective repository. These changes are reviewed, approved and merged by developers, not miners. However, even if a change is merged in the main repository, this does not mean that a miner will necessarily adopt it. If the repository maintainers approve a code modification that is undesirable, then some independent party observing the code changes (there are many who are looking at the pull requests and merges into the Bitcoin and Ethereum repositories) who does not have the ability to approve, disapprove, or merge code, will point out the problem in public forums. If an important problem is pointed out, it is possible that miners will not update their software. If miners choose not to update their software, the update will not take place, regardless of whether it is merged into the main repository.
Is there a consortium or a foundation that has the final say? While there are various foundations associated with Bitcoin and Ethereum, it is not possible that an individual or a group of individuals, solely based on their identity, will have the final say on any decision regarding code or process of a blockchain. The reason is that this would make the blockchain a centralized system. Instead, changes proposed must be accepted by miners. If a miner approves of a change, they will download the new code and run it; if not, they will remain in the older version.
A miner can always choose to run an alternative version of the software not approved by the main repository maintainers or foundations. That way, if the maintainers of the main repository are asked to put in a backdoor and someone detects this, it will not be possible to infiltrate the bitcoin network, as the miners will refuse to upgrade. A similar situation holds for changes that are economically undesirable to miners.
If a portion of the miners agree with a software upgrade, but another portion of the miners does not, then a fork will be caused. If the upgrade is soft-fork-compatible and the miners who do not upgrade are a minority, then they will be "carried over" to the blockchain produced by the majority who have upgraded, causing a "soft fork". This will force them to upgrade their node or risk losing their profits. If the upgrade is a hard fork, then the chain will be split into two, regardless of whether the majority upgrades. The minority will maintain their own chain. This is what happened between Bitcoin and Bitcoin Cash, where the change of block size increase was not approved by the majority, but constituted a hard fork change. The decision of which code version survives is hence up to the adoption policy of miners.
More details about the different forks are described in the paper "A Wild Velvet Fork Appears", which appeared in Financial Crypto '18.
Why does a website show the progress of voting on a particular blockchain fork? This display is purely informational and does not affect the decision. Decisions to upgrade or not are indicated on the blockchain by miners. These decisions are advertised through a "signaling" mechanism by which miners include their vote in their coinbase transaction, the transaction which pays them their profits. Because that transaction is verified by proof-of-work, it is impossible to fake - the miner that created that block really did signal their decision. Miners observe the signaling by other miners to decide whether they will upgrade.
For example, an activation period can be allocated by the developers during which miners can vote, by including their signal in their coinbase transaction, to indicate their preference. During this activation period, the feature is not activated. If a minimum threshold of signaling is indicated during the activation period, such as 90% of blocks, miners agree that they will adopt the new feature. This helps avoid soft forks where the majority has not upgraded. As long as most miners signal truthfully, this mechanism works. Signaling does not require developer or foundation approval and the adoption of a feature is not based on observing the statistics off of a website.
Despite the above, in practice, a lot of development relies on a few individuals who are major contributors. The fact that few people are involved in the actual development is studied in the paper "Egalitarian Society or Benevolent Dictatorship:
The State of Cryptocurrency Governance" by Azouvi, Maller and Meiklejohn which appeared in Financial Crypto '18.
To conclude, there are no individuals or foundations which have the final say on which feature will be included. Governance is performed in a decentralized manner in which software adoption by miners indicates which protocol will be followed.


text:
Is the transaction within Genesis block spendable?
Are the transactions added to the genesis block spendable, just like any other transactions from other blocks, or is that an unspendable coinbase transaction.
In other words..
Is the transaction within the Genesis block spendable, provided the corresponding private key of the bitcoin recipient is found?
and If I fork the Bitcoin code, and generate my own genesis block. Can I use the private key/public key I used as bitcoin recipient of the transactions  hard-coded with the genesis block?

See https://bitcoin.stackexchange.com/questions/76831/is-the-transaction-within-genesis-block-spendable/77049#77049

Are the transactions added to the genesis block spendable, just like any other transactions from other blocks, or is that an unspendable coinbase transaction.

Transactions aren't spendable; transaction outputs are.

Is the transaction within the Genesis block spendable, provided the corresponding private key of the bitcoin recipient is found?

The single transaction output in Bitcoin's genesis block is not spendable. It is not known whether this was an intentional choice by the system's creator, or an accident. Regardless, the reasons why currently don't matter, as no Bitcoin full node software would accept such a spend.

If I fork the Bitcoin code, and generate my own genesis block. Can I use the private key/public key I used as bitcoin recipient of the transactions hard-coded with the genesis block?

In your own software you can enforce whatever rules you like.

Are the transactions added to the genesis block spendable, just like
  any other transactions from other blocks, or is that an unspendable
  coinbase transaction.

The coinbase transaction of the genesis block is not spendable.

If I fork the Bitcoin code, and generate my own genesis block. Can I
  use the private key/public key I used as bitcoin recipient of the
  transactions hard-coded with the genesis block?

Yes, but you have to make some modifications to the source code, because it's "unspendability" has been hard coded to avoid a hard fork.
How to make it spendable
chainparams.cpp

Mine your own genesis block by providing all the necessary information in chainparams.cpp, mainly CreateGenesisBlock and Line #123 (for mainnet, similar for testnet and regtest in same file).

validation.cpp
You need to make it so the transaction is added to the index, and bypass some checks that make it unspendable. In v0.16:

You can find where it is not added to the index in validation.cpp Line #1812. Comment out Line 1817 return true to avoid skipping this.

You might also need to skip validation tests (for example if your genesis block difficulty is lower, if you have a premine) in places such as:

Skip nLockTimeFlags |= LOCKTIME_VERIFY_SEQUENCE; on Line #1891 by adding a check around it:
if (block.GetHash() != chainparams.GetConsensus().hashGenesisBlock)
{
    if (VersionBitsState(pindex->pprev, chainparams.GetConsensus(), Consensus::DEPLOYMENT_CSV, versionbitscache) == THRESHOLD_ACTIVE) {
        nLockTimeFlags |= LOCKTIME_VERIFY_SEQUENCE;
    }
}

Also similar exceptions (check that != genesis block) for if (!WriteUndoDataForBlock(blockundo, state, pindex, chainparams))
return false; on Line #1988
Similar exception for Line #1805, Lines #1873-1876

Basically, you need to run it and try and see where it fails in the logs, because you're breaking a bunch of rules.


text:
does bcoin support simplified payment verification (SPV)?
Does bcoin support simplified payment verification (SPV)? I can't seem to find anything about it online

Yes, it supports SPV out of the box. Bcoin actually started out as an SPV project according to Buck Perley.
Here is an example on how to start up a bcoin node in spv
https://github.com/bcoin-org/bcoin/blob/master/docs/Examples/spv-sync-wallet.js


text:
what is the macaroon max length
In an LND node, what is the max size, in bytes, of a macaroon. If there is no explicit max length, what can you reasonably expect to be the size of your macaroon?

A macaroon consists of three parts:

The header: Identifies the macaroon and contains three fields.

The version: 1 byte, always set to 0x02 in lnd
The location: variable length string, always set to "lnd" in lnd
The identifier: variable length binary data, contains protobuf serialized data in lnd containing the permissions of the macaroon. More on that later.

The caveats: Restricts the capabilities of the macaroon. This is a variable length list of strings. lnd currently only implements two possible restrictions, the time-before and the ipaddr restriction.

Example with maximum characters:
["time-before 2006-01-02T15:04:05.999999999Z07:00", "ipaddr 255.255.255.255"]

Which is roughly 70 bytes plus some encoding overhead.

The signature: An HMAC-SHA256 hash, so 32 bytes plus encoding overhead.

The permissions
As mentioned above, the macaroon identifier contains a list of permissions. Currently this just contains a protobuf serialized list of {Entity string, Action string} pairs that correspond to permission sets in lnd. For example, the pair {Entity: "info", Action: "read"} would give a user read-only access to informational calls.
These permissions make it a bit tricky to estimate the maximum size of a macaroon in lnd. At the moment, the maximum number of distinct entity/action pairs that exists is 17, which is given to the automatically created admin.macaroon. That admin macaroon currently is around 280 bytes in size.
But soon, you will be able to customize the permissions of a macaroon even further by specifying individual URIs that are allowed to be accessed. A user could could then, for example, add a permission pair of {Entity: "uri", Action: "/lnrpc.Lightning/ExportAllChannelBackups"} to a custom macaroon.
Just for fun, I went ahead and created a maximum-sized macaroon with all currently available URIs which turned out to be 4041 bytes in size.
From that, I would summarize that limiting user input when uploading a macaroon to 4096 or 5120 bytes should cover almost all cases of custom macaroons.


text:
Has a spend from a hybrid public key ever made it to the blockchain?
If so, could you please give the TXID of a transaction that spends from a hybrid public key?

Surprisingly, there's a number of UTXO entries for the obscure hybrid key format. The transaction 657aecafe66d729d2e2f6f325fcc4acb8501d8f02512d1f5042a36dd1bbd21d1 makes a number of interesting P2PK outputs, two each of which are 0x06 and 0x07 respectively.
OP_PUSHBYTES_65 06da9be28d6e6266ddc0bc71b09032f3a810ffc917b5876e23a03c118f24f6a84dae4a9a5244fbf47860bc0760102d6bde6257bfcb7155d3dd66b97181119f98c5 OP_CHECKSIG

OP_PUSHBYTES_65 07d19ef6ba5b92b87078dba3a00df392efc16917defb2be08f22e41ce2873335705bff95fed463550f291d3b1fd559af11e432256a47e738572be3b74fc6f73ed0 OP_CHECKSIG

None are spent, but there's no technical reason for this, the outputs are valid.

Looks like a good way to waste btc on fees by adding more bytes to your transaction to me ;-)


text:
What would happend if a country were backed by its own cryptocurrency?
What would happen if instead of depending on dollars or gold, a country were backed by its own cryptocurrency, would this benefit its citizens and the country itself? How?
I've read this answer but it's mostly about bitcoin, and not about a country's coin.
Sorry if the question is out of place.
Thanks!

As this has not happend yet, the only thing we can do is "speculate" about the answer.
However, this may change in the near future, Estland is currently creating it's own cryptocurrency.
One of the key advantages for citizens of the country would be that they would have a currency which does NOT devalue / inflate like something as the dollar / Euro, since you can't just suddenly make another billion of them.
However this at the same time is also probably the reason why it will never work.
Countries can't for example "press" more money.
But, the cryptocurrency could also make life easier in the following ways,

Imagine for example if you as en r-resident could charge Estonian customers in estcoins,
pay your corporate taxes and public services in estcoins,
and estcoins is accepted as legal tender in the same way as euros in Estonia. If this actually happens, then there is no limit on how deeply integrated cryptocurrencies could become in everyday life.

Also, it would, if the coin is bitcoin based ( open ledger blockchain.) protect the citizens from their own government.
Meaning they can for example see and verify exactly where their money is going, due to the blockchain.

It is possible to have a controlled cryptocurrency and apply monetary policy (doesn't need to be mining-based). As it will be backed by the country's financials, it will eventually be the same (in terms of devaluation/inflation) with current fiat money, but with the cool features blockchains offer.

Couldn't a country design a cryptocurrency with no limit? and control its inflation? What'd be the benefits? How can they see where the money is going?


text:
What is the supply for Bitcoin Cash (BCH), how is supply being regulated?
We know that for BTC there is a max supply of 21 million.
50% reduction of 50 BTC per block for every 210000 block.
However, what is the mining reward per block, how is the supply being regulated? Can't seem to find any materail on it?

Bitcoin Cash has the same hard limit as Bitcoin, almost 21 million. In terms of supply, it is identical to Bitcoin, with the same halving of supply, at the same block heights.
However, there is a difference in the difficulty adjustment algorithm. Difficulty is the variable that ensures that there is one block mined every 10 minutes. It increases as the number of miners/hashpower in the network increases. In Bitcoin, the difficulty is adjusted every 2016 blocks, based on how long it took for those 2016 blocks to get mined. So every 2 weeks (approximately) the difficulty is adjusted based on how much hashpower was added to the network in that time.
Initially, Bitcoin cash had the same difficulty adjustment algorithm with one addition, which was called Emergency Difficulty Adjustement (EDA). If no blocks had been found for 12 hours, then the difficulty would reduce by 20%. This was put in place to prevent the chain from stagnating  and dying due to lack of hashpower as it was unknown as to how much support BCH would receive from miners.
This algorithm, however, was susceptible to being gamed by the miners. Miners would intentionally abandon mining BCH for a period of time. This would trigger EDA multiple times, and then when the difficulty was low enough to be profitable, they would start mining BCH, and mine 2016 blocks in 3-4 days (instead of 2 weeks). After 2016 low-difficulty blocks are mined, the difficulty would be readjusted to a sufficiently high amount, and the miners would abandon the BCH chain again.
If you compare the supply of BTC and BCH, in the 4 months since the fork, there is a difference in approximately 120,000 coins. This was problematic as BCH blocks were no longer predictable. The block times varied from 12+ hours to less than a minute.
On November 13th, Bitcoin Cash underwent a hard fork to change the difficulty adjustment algorithm. Now the difficulty is readjusted every block based on the previous 144 blocks, to try and keep block times as close to 10 minutes as possible.

Bitcoin cash is the same as bitcoin except it has SegWit2x implemented and it has bigger blocks (2MB I think). Bitcoin cash is hard fork of Bitcoin.
The benefits of bigger blocks are more transactions per block, the current Bitcoin block size is 1MB, which means Bitcoin Cash can process 2x more transactions.
The other difference - SegWit essentially moves part of block data into separate block and therefore can hold even more transactions. Transactions are faster and the fees are lower because there is less waiting to be processed transactions.
But with bigger blocks it is more expensive to support full node. Full node keeps all transactions locally.
With 1MB block and ~144 blocks per day mined, you will need 144MB per day, 1GB per week and 31GB for every month.
With 2MB blocks you'll need 144MB*2 per day, 2GB per week and ~62GB for every month. Who can afford this? Only big players and this means only one thing - centralization, we already have centralized banks and we don't want that, we want the opposite.
This calculations are based on the assumption that every block is filled to the max, with the current Bitcoin Cash blocks this is not the case because not so much transactions are going on right now and the blocks are ~100KB.

Yo. Thanks for the info man. Do you know if the community actually has documentation / white paper abt their implementation, can't seem to find anything substantiative online.

I think it is better to stay away from Bitcoin Cash. Bitcoin cash is just alternative coin that is using Bitcoin for PR and will die eventually.

Bitcoin Cash removed SegWit, so SegWit will only activate on the Bitcoin chain.

@PieterWuille - You are right, Bitcoin Cash uses SegWit2x which is SegWit + 2mb block size.

No, SegWit2x is yet another fork, planned for november.

Okay, I'm confused, where is the official info, can you give us link?


text:
unconfirmed transaction for over 2 days what to do?
sent from exchange to wallet  2 days ago still not confirmed ?
https://blockchain.info/tx-index/277169110

The recommended fee for a transaction is of 450 satoshis ber byte.
Your transaction is 226 byte long.
450 x 226 = 101700 shatishi
101700 shatoshi = 0.00101700 Bitcoin
The transaction fee you included is of 0.0003842 Bitcoin which is 0.0006328 BTC lower than the recommended.
I wouldn't be surprised if you had to wait even more.
Data source: bitcoinfees

All you can do now is that You need to wait!!!!! For a looooooong time. Probably will never get through, then your wallet should refund you For a looooooong time. As for now, 170 sat/B is not high enough a fee to get process, 450 sat/B is recommended. 170 sat/B give you the processing time from 60-Infinite minutes. If you have paid 450 sat/B, then processing time would be about 60 minutes. so basically you are fked if the seller need to get pay soon.


text:
MyMonero wallet recovery with phrase
I'm sorry to both you with this.
Mymonero.com has been down for several days and I'd like to remove the monero from my wallet on that website.
All I have is the original phrase I set it up with years ago though.
I downloaded the monero wallet from getmonero.com but it requires a 25 word phrase, I think mine is 13 words.
So I'm confused. Did mymonero.com use its own phrase to wallet system?
Most importantly:
Is there anyway for me to recover the wallet without using MyMonero.com?
Thank you very much for your help!


text:
Bitcoin Core transaction stay unconfirmed
My transaction from Bitcoin Core to Trezor Wallet stays unconfirmed. Because of too low transaction fee ? How do I resolve ?
Status: 0/unconfirmed, in memory pool, broadcast through 9 node(s)
Date: 23.08.2017 11:39
...
Transaction fee: -0.00005760 BTC
...
Transaction ID: 3d9a0ab7d39bf553584a19433280e61065225891f257cca4f9f00811939d2189
Transaction total size: 192 bytes
Output index: 0

Found solution in related posting a looong way down into previous answers:
Make use of the free ViaBTC Transaction Accelerator service (requires a minimum fee rate of 0.0001 BTC/kB): "https://pool.viabtc.com" under "Tool".


text:
The amount of coins in the wallet is too small for sweeping
I want to make a present to my friend for his wedding - a bitcoin paper wallet.
I managed to print it and send 100uBTC (0.0001BTC) to the paper wallet for a test.
Then I chose "Sweep paper wallet" and I got a message that the coins are there, but "the amount of coins in the wallet is too small for sweeping".
What is the minimum amount that I can sweep?

Sweeping is just sending all bitcoins to another address. As such, there is a network fee involved.
Network fees will come out of the value of the paper wallet.
Depending on what you are using for sweeping, you can vary the fees. Though
a lower fee will take longer to complete:
https://bitcoinfees.21.co/
At the risk of dating this answer, I would currently allow 0.001 BTC in your friend's gift for fees for fast transactions, about 5 USD, (yes fees are pretty high right now.)

Sweeping is a two step process.

Import the paper wallet's key, necessarily compromising its security in the process.
Immediately send the balance of the paper wallet to a new, uncompromised address.

The second step, sending the bitcoin to a new address, requires a fee which is taken from the balance of the paper wallet. If the balance of the wallet is lower than the required fee for the network to clear the transaction, then it is not possible to sweep the transaction because it will never get confirmed.
The minimum amount you can sweep is one satoshi more than the transaction fee you (or your wallet software) decides to pay for the transaction.
If you have a paper wallet that is too small to sweep, you can still import the private key into a wallet without sweeping. This is more risky because anybody who has or gets access to the exposed key can spend the bitcoin until it has been transferred to a new address. It can be transferred to a new address by combining it with other bitcoin from the wallet to which it was imported as part of a larger balance transaction.


text:
Is ViaBTC the only public Bitcoin Cash pool?
Is ViaBTC the only public Bitcoin Cash pool?
I have spent hours in searching but could not find another one.
As the price of Bitcoin Cash surges, a lot of people want to mine it.
Thank you in advance for your answers!

https://bcc.suprnova.cc/ -this is the second pool which I found

No, http://pool.Bitcoin.com also offers BCH mining as far as i'm concerned, see
https://news.bitcoin.com/bitcoin-com-pool-members-now-have-the-option-to-mine-bitcoin-cash/
Which is https://stratum.bcc.pool.bitcoin.com:3333/

Coinfoundry is running a Bitcoin Cash Pool as well: https://coinfoundry.org/pool/bch


text:
HELP i sent btc from a tor wallet, The recipient hasnt recieved it
I have been on blockchain and seen the transaction into the tor wallet. https://blockchainbdgpzk.onion/address/1BMbBKshk9ihrQWMseoDt5bXJvQgQPeRkA?filter=5
my torwallet recieve address is     1BMbBKshk9ihrQWMseoDt5bXJvQgQPeRkA
How do I see what was sent out? As I sent out 2.55 btc, It went to an addy that has not changed so i desperately need to track this down. and see why it hasnt landed

I don't know what tor wallet is but you shouldn't be using any web wallets. Just use a SPV wallet and connect through tor. I really like electrum though I haven't used it with tor.
...
Why take the risk? Just run bitcoin core or electrum over tor:
https://bitcointalk.org/index.php?topic=1697290.0

I am confused. I like blockchain.info but for some reason I seem to get two completely different results depending on whether I check this link or this link but, I suppose that the result of the transaction is the same even if the displayed details are different. I would sure love to hear the reason that they are different though. Either way, your bitcoin, if I have your original address correct, probably went to bitcoin:1PFvdddNKGKrmJcn7pYLeMX186cd1Kfi7e as part of a larger payment.

https://blockchain.info/address/1BMbBKshk9ihrQWMseoDt5bXJvQgQPeRkA

https://blockchainbdgpzk.onion/address/1BMbBKshk9ihrQWMseoDt5bXJvQgQPeRkA

The second link isn't down, you just have to have your application interface configured.

I see that your wallet sent out a total of 2.69947368 BTC in this transaction  on June 2nd, in block 469404, which has now been confirmed 1000+.

what do you mean 1000+? also the 2.699 was recieved in my wallet, However I remember only sending out 2.55 because of a charge.

Deposit BTC: 1BMbBKshk9ihrQWMseoDt5bXJvQgQPeRkA     Balance: BTC 0.018074 i have that left in the wallet... so i recieved 2.699 but could only send out 2.55 due to fee... I dont get how this has happened? and not the address i wanted


text:
Transaction stuck because of "Dust"?
been waiting 8 days for this transaction because Bitcoincore couldn't be arsed working out the network fees.  Not a big transaction, but has caused a lot of grief because recipient now thinks I'm dishonest, even though I sent again from an online wallet which went through !!
if anyone can help the transaction ID is
7fb10192748c0cea3d441a98789086d9905c6d83de11bc19b716b4be6ade5c04
I don't even mind if it is confirmed and sent to original vendor as, at least, my reputation will be restored
Thanks in advance

You used a fee-rate of 6 sat/B. Even though fees have dropped drastically over the week, that's about factor ten too little to confirm. Additionally, one of your outputs will cost its own value to spend at 3 sat/B. Even at today's exchange rate it's only worth about 1.5¢, you should try to avoid creating outputs that small as they're unspendable burnt money. That's the output that triggered the dust categorization.


text:
Is it possible to have proof of stake and proof of work transactions in the same block ?
To understand more of the blockchain technology i asked myself , is it possible to have proof of stake and proof of work transactions in the same block ?

What system/blockchain are you asking about? Bitcoin doesn't have PoS, and Pow only applies to blocks as a whole (transactions individually don't have PoW).

I asked because there are some hybrid blockchains who uses POW and POS mecanism and i want to understand how they get stored in the blockchain. POS blocks + POW blocks or mixed Blocks ? could be that there is a fundamental thing that i dont understand.

Proof of Stake and Proof of Work are two strategies of arriving at consensus. I'm not aware that the transaction format would need to be impacted whatsoever by having one or the other in play.


text:
Where is the Signature stored in a SegWit transaction?
I understand that SegWit makes transaction blockdata smaller, by not storing the signature in the Block, so that can fit more transactions in 1MB. This is because the signature is not anymore stored in the blockchain. The Signature makes nearly 70% of the data weight of the Block. So in a SegWit transaction it is 70% less stored in the Blockchain. But where are the signature stored if not in the Blockchain ?

That's not accurate. The witness is stored in the blockchain.
In the segwit format, the signature is part of the witness, the witness is part of the transaction and the transaction is written to the block in full. Nodes that understand segwit will download and store the complete transaction including the signature.
However, segwit is constructed in a forwards compatible manner. It's made so that it is possible to produce a "stripped version" of a segwit transaction that omits the "witness". This stripped version is a non-standard valid transaction according to pre-segwit rules. This means that pre-segwit nodes will not propagate it when it is unconfirmed, but accept it when it is included in a block. Segwit-enabled nodes would consider the stripped version incomplete and therefore depend on receiving the complete version of the transaction from another segwit-enabled node.
Since the transaction outputs are part of the stripped transaction (because they are not part of the witness), pre-segwit nodes will come to the same conclusion regarding the ownership of funds by following the stripped blocks as segwit-capable nodes that read the complete blocks.
Part of the criticism of segwit is that pre-segwit nodes will not verify the signature of segwit transactions, as they do not receive the witness and wouldn't know what to do with it. This means that a legacy node might accept an segwit-invalid block until that block is no longer part of the most-work chain-tip. However, such a block would not propagate well on the network, as about 89% of the nodes on the network are segwit-capable. If you're receiving a significant amount of funds from a segwit transaction and are running a segwit-incapable node, you might want to wait for  additional confirmations before taking it at face value. However, for significant amounts that would be a great idea regardless.

Thank you for this thorough explanation, however I'm not sure to understand the very last sentence

@EricLavault: If you're receiving a large amount of money, it can become interesting for people to try to trick you. If you wait for more than one confirmation, it'll be more costly and harder for them.

This is not a answer to my question ... my question was ; where is the signature stored when its seperated from the transaction ( SegWit Format ) ? in the blockchain or outside the blockchain ?

@laizess: In the blockchain. See my second sentence: "In the segwit transaction format, the signature is part of the witness, the witness is part of the transaction, and the transaction is part of the block." Really, the signature is not separated from the transaction, but it is just separate from the rest of the input script but still inside the same transaction.

@Murch That's confusing. If the witness is in the block, then why doesn't it count towards the block size? Assume the possibility that it's not part of the block, and instead comes in from a separate channel. In that case, it's clear that there's less data being stored on the blockchain for each transaction. What you're describing puts exactly the same amount of data onto the blockchain; so I don't see how it resolves the problem.

New question here: https://bitcoin.stackexchange.com/questions/81727/how-can-segwit-increase-transaction-throughput-if-the-same-amount-of-data-is-sto

It's still kept in the blockchain. It's just kept in a way that non-segwit clients never see or store the signature.

If the Signiture its still in the blockchain, how is then possible to save 70% of the blockspace to put more transactions without the signature in the same block ?. independently if non-segwit clients can see them or not ?  If the Signiture is still in the Blockchain, seperated from the transaction, how the signiture can be identifed at any time, that the transactions where valid ( signiture ) ? if transaction and signiture are seperated but both saved in the blockchain, why seperate them in the first place ?

Segwit doesn't really 'save' blockspace. It's an accounting trick. It moves bytes from the area counted against block size to an area not counted by (presegwit) block size. A non-segwit node never sees and cannot validate segwit signatures. There are two major reasons to do this. 1) Effective block size can be increased without a hard fork. 2) It's nice to have an identifier for the transaction which can't be changed without re-signing the transaction.

@laizess: Also see Is SegWit a blocksize increase or more efficient use of blockspace?


text:
How it is possible to create coins only with the proof of stake system?
Nick Szabo comes 2011 with a alternative proof system wich he calls proof of stake POS. This system was used later by varios coins ( NXT, Peercoin, Blackcoin etc.)  but all of them had the genesis coins premined or have them created in the beginning with the proof of work system. But how it would be possible to create coins only with the proof of stake system from the beginning ?

The problem you are describing is: how do you mine coins in proof of stake if you have no stake? In essence; you can't, depending on the implementation obviously. If you don't have any coins, you won't be able to mine new blocks. The easiest solution is obviously buying coins from another. If the original creator(s) of a PoS coin simply sell most of their early work, others could start mining as early as the third block (genesis block to finance the creator, second block to transact to others).


text:
Transaction order in the blockchain
What is the difference between segregated witness (segwit) and canonical transaction ordering (CTOR) ?

TTOR (Topological Transaction Ordering) is used by Bitcoin and pre-CTOR Bitcoin Cash. In TTOR, there might be multiple possible ways to sort transactions. The only requirement is, chain of transactions should be sorted by time and the coinbase transaction must be the first.
Let's say there are A, B and C transactions, and assume that there's no coinbase transaction. A and B are usual transactions, but C spends at least one output of B. The possible orderings are:
A B C
B A C
B C A

Amaclin is right, SegWit didn't change anything related to them.

Do you think the CTOR ordering is more efficient then TTOR ordering ? Are there any downsides ?

It was needed, because Graphene, which is an enhanced Compact Blocks, requires any ordering algorithm that had no more than one way to order. CTOR was chosen and analyzed here. A critique can be found here.

These things are not related to each other at all. So, talking about differences between them is nonsense.


text:
Smart Contract token
Ones tokens are issued by smart contracts on a existing blockchain, for example Bitcoin and distributed to the community, who and in wich currency the transaction fees will be realized ?

This is highly implementation specific.
For common token platforms, namely Bitcoin and Ethereum, fees for transactions must be paid in Bitcoin and ether respectively.
Your contract or token mechanisms can impose a further fee in your token, or another token, but the platform itself requires the transaction cost to be paid by the native currency.
There are various proposals (1, 2), mainly for ethereum, that would allow tokens to be used to pay base transaction fees as well. However, these will require a hardfork, and are not currently usable.

Thank you very much for your response. If i understand it well, so for example people who have OmiseGo, wich is a token on the ethereum blockchain, and wants to transfer omiseGo tokens to each other, have to pay in ethereum the transaction-fees ?

That's correct.


text:
Regtest not paying address in mined block
I have set up a local 5 node bitcoind regtest network with unique ports using compiled bitcoin core 14.2. I can generate blocks, send transactions between nodes, and mine those transactions using a python miner that I constructed. However, the payout for mining always goes to the node that I last generated 101 blocks and not to the address in the minded block for the node I am using to mine.  I have verified that the correct address is included in the mined block and have started to look at the bitcoid code to see what might be happening on that side of the equation. When I spin up the 5 nodes I am using the same binary but with different command line config params.
I am new to bitcoin and have been doing this for the past two months to learn how it works.  I've tried researching this problem and so far nothing has turned up and I will continue to debug the miner and core.  In the meantime, I would greatly appreciate if anyone has any suggestions about what could be going on and how to address it.
Thanks,
:D

Newly generated coins cannot be spent until 100 blocks have been mined on top of the block creating those coins. This requirement means that it will seem like the address from 101 blocks ago was paid, but rather it is just that the coins mined 101 blocks ago are now spendable.


text:
How do payment processors like bitpay work?
How do payment processors like bitpay work?
As far as i understood you can only have one address per key pair, so do they generate a whole new pair for every payment? Or can this be done using HDWallets?

They generate a private key and an address corresponding to that private key everytime you see BitPay's payment page (even if you don't pay they keep the private key and that private key is generated only for one payment). When they receive payment to that address, they send your money from that address to their main wallet.

They possibly using a wallet
You first request a payment then the server-side generates a bitcoin address, when it generated, it send back to the client side, they will then the page automatically refresh to see if the coin is sent to the address, if not then wait (until the timer) and if sent, it will continue to refresh until it meets the requirement for the confirmations. When it is meet then depend on your provider, they either choose to save the amount they owned you on a database or immediately send u the coin.
If they choose for the database then they will send u the coin after the requirement is meet with the receive address you provided.
If they choose to send you immediately then as soon as the coin is receive and has the confirmation, an api will be called to send u the coins.


text:
Should i invest in a Antminer L3+ or a Antminer S9
i've been looking to invest in a antminer s9, at the moment the earning i can get from that machine is around 10$/day. but it's a litecoin miner (Antminer L3+) for the exact same price that i could earn 30$ a day from. people say that the value of bitcoin will rise like a rocket, but i dont know about litecoin.

Per our [tour]: Please don't ask for investment advice. To discuss investments, please use another platform such as /r/cryptomarket, /r/mining or Bitcointalk.

Invest? Run the math first on bitcoinwisdom.com. Unless you have free power (and won't get into trouble drawing a kW of AC 24/7; it won't be profitable for long.
Difficulty rises and will continue to do so; until the correction comes; which- it will.
Now would be a bad time to buy a miner. I would wait for a major price correction-- even if BTC hit 10k before the correction- the money to make would be after it drops back down to 5k and the miners are all worthless; then start them up after the price rebounds.
Bitcoin mining is too hot to touch right now if you are not already heavily invested in the game.

So, now that BTC hit 10k, and it's reaching 20k, what do you think?


text:
Can I receive BTG to my BTC address after BTG hardfork?
I read that on 25. oct. 2017. the BTG hardfork will happen and every one holding BTC on their address will receive BTG for their BTC in 1:1 ratio.
What happens if I have X amount of BTC on my address A, and after the hardfork happens I still receive BTC to that address.
Can I change that BTC to BTG in 1:1 ratio even some time after the hardfork happened?
For example if I have 1BTC on my address, then at the time of the hardfork it will be converted to 1BTG. Then let say, weeks later I receive 1BTC to the same address.
Can I spend 2BTGs then?

No
Bitcoin Gold has replay protection.  After the fork, all further transactions on the BTC chain will not transfer BTG, nor vice versa.
In your example, when someone sends you 1 BTC after the fork, the corresponding 1 BTG will still belong to the sender, not to you.  You will not gain any BTG from the transaction.  (Of course, they could send it to you separately if they wanted.)
It will also not be possible to spend BTC as BTG or vice versa.  To exchange one for the other, you will have to find someone to make a trade with, and agree on an exchange rate, which will probably not be 1:1. (You can use an organized exchange to make this efficient, but it's the same thing in principle.)

No, on the fork date only the BTC present will reflect on the BTG chain as the fork already happened. Further transactions on the BTC chain will not be taken into account. This also means you can spend BTC without it affecting you BTG balance.
Also BTG addresses are unique so from what I understand you can't send BTG to an old BTC format address but they can be converted and indeed BTG addresses will employ the conversion algorithm in addition to the address creation algorithm for new addresses.


text:
Blockchain gap limit
I was trying to figure out how exactly the Blockchain gap limit works. I've read the following question on Bitcoin Beta: How to solve Blockchain 20 address gap-limit problem? and started thinking. Maybe I am not getting this right, but in the answer to that question, it says, that the Blockchain will always look ahead 2-22 addresses, to see if any payment came inside, starting from the index of the address, that received payment last.
Am I correct in stating, that, if for example, 2 users try to send me a payment of XBT.
User 1, asks to deposit some XBT to me, gets an address from my site, with index 1. Then, a minute later, user 2 does the same, and gets an address with index 2. If in this case, user 2 makes the payment faster then user 1, the Blockchain won't see the payment from user 1, because from this onward, only addresses with index 2-24 will be checked?
If this is the case, this seems like a serious issue to me, maybe I am understanding something incorrectly, can anyone clear this up to me?

No, that's not how it works. Blockchain (and most other HD wallets by default, as set in BIP 44) look forward 20 addresses before deciding that no more are being used, it doesn't ignore the ones before that. Its purely a way of telling which ones you're using, because you can generate effectively as many as you want using incremental indices, and you wallet shouldnt have to check them all every time you update your balance. So it checks index 1, then 2, and so on, until it finds a stretch of 20 unused addresses in a row before assuming it's reached the end of the addresses you are using currently. If at some point in the future, you received a payment on one of those 20 in the gap, the wallet would begin looking 20 indices higher from that one.
So the only way you could miss payments is if they were too far in the higher indices not lower, e.g. no payments on indices above 10 but one on 30 would go unseen, because the wallet would give up looking after 20 unused. That's why blockchain usually warns you if you're approaching the gap limit rather than silently letting you.

what happen if we reach the gap limit? is always something that we can fix just increasing that number in our wallet or we could loose the funds forever in some cases? my question here: https://bitcoin.stackexchange.com/questions/88128/gap-limit-is-always-a-problem-possible-to-fix


text:
Can't restore Multibit HD 0.4.1 wallet into Electrum, Electron-Cash wallet for BCC
I've followed some advice from messageboards and stackoverflow on how to transfer my Multibit HD wallet into either of these 2 (Electrum, Electron-Cash) clients, and I keep coming up with 0 btc (before I drained my Multibit HD wallet) or bcc in both with no transactions or history. I have the password and all the wallet words for the Multibit HD wallet, but it seems like that's of no help.
The things I've tried:

Seed words into either client, BIP39 seed option checked, changed derivation to m/0', FAIL
https://iancoleman.github.io/bip39/, put seed words into BIP39 Mnemonic, BIP32 tab selected, Multibit HD as the client selected, copy-paste BIP32 Extended Private Key into either client, FAIL
Same as 2, look through over 10,000 derived address to see if I could match any of the public addresses to ones in my wallet so I could write down the private keys, no derived addresses match the ones in my wallet, FAIL

Has anyone successfully obtained BCC from a pre-chain split Multibit HD wallet, or even transferred a wallet from Multibit HD 0.4.1 to Electrum (which would then be an easy copy to Electron-Cash)?
As a side note, I have sent all funds in the Multibit HD wallet to an Electrum wallet on another computer, so I'm free to experiment with the Multibit HD wallet without any risk of loss of funds.
I'd be willing to give the first person to successfully help me get the BCC, $25 of BCC as a little thank you. Not much, but then again I didn't have much Bitcoin to begin with :\

Look at the answer at https://bitcoin.stackexchange.com/questions/57422/how-to-sweep-private-extended-key-from-mycellium-into-coinomi-for-bitcoin-cash-c/ to understand how to get hold of the addresses and how to sweep. If needed ask more.

MultiBit HD uses a different derivation path from all other wallets; it does not use the BIP 44 standard for derivation paths. Thus you cannot use your MultiBit HD mnemonic or extended private key with other wallet software because they use different derivation paths and no wallet currently allows you to set an arbitrary derivation path.
The only way that I know of for you to get the MultiBit HD private keys is to use https://iancoleman.github.io/bip39/. Enter your seed words, choose the BIP 32 tab, and choose the option for MultiBit HD. If you don't see your addresses, try toggling the Hardened Keys option and see if that makes a difference.

I used multibit 0.5.1 how ever this could work:

Before fork, I moved bitcoins from multibit to Electrum by using multibit seed. I checked the BIP 39 option but did not touch derivation or other defaults.
Electrum wallet was created successfully with all bitcoins in it, however for some reason it was somehow 'seedless', in other words the 'seed' command in Electrum menu was greyed out. Otherwise normal send/receive capable wallet though.
Post-fork, moved bitcoins out of this wallet elsewhere and got bitcoin cash with following procedure:
3.1 Export private keys from Electrum. This creates 2 lists of keys, only keep the longer ones.
3.2 Create Electron Cash wallet from those keys by copy&pasting the list.
result:
Bitcoin Cash wallet with correct amount of coins created


text:
Bitcoin library in python
I need a good library for bitcoin and other BTC-like cryptocurrencies in python.
I'm looking for something similar to bitcoinjs but in python.
Minimal requirements:

generate an EC keypair and get public address from the public key
generate an EC keypair and compress it to WIF format.
get an EC keypair from WIF
generate a number of EC keypairs (a HD wallet) from a given seed
build a transaction
broadcast transaction

If you know any good cryptocurrency libraries let me know!

Take a look at Peter Todd's python-bitcoinlib.
From the github repo:

This Python2/3 library provides an easy interface to the bitcoin data structures and protocol. The approach is low-level and "ground up", with a focus on providing tools to manipulate the internals of how Bitcoin works.

Check-out the node-directory within my Github repo experimenting with a scalable cryptocurrency.

Take a look at https://pybtc.readthedocs.io , pybtc python bitcoin library


text:
With just standard desktop or laptop, is it possible to mine obscure altcoins in the hope that one of them will take off?
So just from the listing at coinmarketcap.com, there seems to be 954 cryptocurrencies right now. I imagine it's a bit like a startup, in that most of them will not survive.
It's too late to mine the big ones - like bitcoins, ethereum and litecoins - you probably need dedicated rigs with ASIC to mine them. But is it possible to just mine the smaller ones? The ones that are in the beginning stages in the hope that maybe one day they will take off? Would it be like mining bitcoin in 2009?

Yes, it is possible. Most altcoins are setup with low enough difficulty that you can CPU or GPU mine them, like you could with Bitcoin in the early days. However there are so many of these small obscure altcoins and almost all of them are just useless clones of some other coin or pump and dump scams, so you are likely going to just end up wasting electricity.


text:
Definition of `Idx`
idx is an integer in source code of bitcoin related softwares.
https://github.com/decred/atomicswap/blob/70f795e/cmd/btcatomicswap/main.go#L391
https://github.com/btcsuite/btcd/blob/efa50e6abc7a9be4478e44216a0677efa8fdf4ce/txscript/stack.go#L108
https://github.com/bitcoin/bitcoin/blob/aa624b61c928295c27ffbb4d27be582f5aa31b56/src/qt/bitcoinaddressvalidator.cpp#L32
What does idx stand for?

idx = index, as in the index of an array/list or similar data structure, usually (and in most cases such as this one) an index is zero-based, meaning the first element of the array has an index of 0, the second has an index of 1, and so on.


text:
How to tell if a cryptocurrency exchange or trading platform is trustworthy?
I've seen a good-looking website for buying and selling cryptocurrencies, should I trust it with my money?

Here's a few checks I'd advise anyone to do.

Does it promise to earn you more than 10% profit in less than a month? If so it is a fraud.

Does it make implausibly impressive claims like "SEC awards {businessname} as one of the best Trading platform of 2018 with 247 contact"? (hint: that's not the sort of thing the SEC ever does).

Are there very many spelling errors and poor grammar?

See if the website is a copy of another website. Take a jargon-phrase from the website, it should be around a dozen words and not include the business name (or other things copiers change) and put it in quotes in a web search engine. See if other websites are using the same phrases. See if any found websites are nearly identical copies. e.g. "We are the only binary options broker that truly places emphasis on you" (LOL!)

Use a "whois" service to look up the domain name registration

if the website is http://example.com/ look up example.com. Was it only registered a few months ago?
Where was it registered? Is the registrar located in a faraway country with a poor record for investigating online crime? Do you want to deal with a business that you have no way to sue? A place with no feasible legal remedies for you as a foreigner?

If the website claims for example "7 years of forex experience" but was only registered 1 year ago you should regard it as probably untrustworthy.

Check the website for contact details. Does it give a physical address?

if not I'd say it is untrustworthy.
Is it a full address or something vague (one site has "west midlands UK" as a contact address - which is obviously deliberately vague and useless as a contact address).
Use something like streetview in Google Maps to view the contact location.

Some websites give an address that is actually a small wooden home in farmland or suburbia - this is obviously a fake address chosen at random.
Some websites give an address in an office building that rents tiny
offices by the day - this is suspicious

Look for company registration details. For example, if the site says it is registered company 123456 in the UK, go to the UK companies house website and look up that company number.

If details don't match, don't trust the website
If details do match check how long ago the business was first registered and whether they have filed accounts etc in the last year. Are they shown as active or inactive, have they changed names. Look for evidence of a bad business - sometimes you find a winding-up notice or de-registration notice.

Related:

How do I recover from a cryptocurrency scam?

Main points I'd look at are check the contract. Make sure real people and real addresses are involved if they are some new groundbreaking idea like "crypto as a utility".
Attempt to find out if the contract has been audited by a reputable company.
and a personal one is...Have the people promoting it said "kindly" way more often than you'd hear it on a regular day.


text:
How to reduce the amount of transactions with handling wallets?
i'm working on a Web Application that will allow users to deposit Bitcoin into their own wallet, leading to a service that invests their funds in X(lets say alt-coins).i'm having issues on how to approach this.
So, if i'm not mistaken it will go like this:
Bob deposits BTC to wallet W => W sends to service S => Bob wins money => S sends funds back to W.
Until bob has funds again it takes 2 transactions
If the goal is to minimize fees by reducing the amount of transactions,
Would you create a private key for each of the users? or is there a way to create different public addresses that point to the same private key?
I Thought about initially giving Bob the option to deposit directly to the service S but the whole idea is giving funds to more than one service.
Thanks for any advice.

Sounds like you're making an exchange? Or is it different to that?

different, its a site where you can choose a well known investor to play with your money for you

Since your service will control the wallet it is not necessary to do the actual transfer out of the wallet to the service, just show the user a lower balance and do not let them spend or withdraw more than this. This means that your service will have to maintain strict control of the private keys. Also, if you maintain a backend float BTC balance, you can show the user an increased balance immediately without waiting for a return transaction to process. To do this, effectively you will need to control all addresses used by your service. This amounts to virtual wallets.
A note on security, there have been previously several high profile services which hold a balance for users, which have been hacked so you will need to ensure your entire security regime is "A" Grade across your entire organisation.

minimize fees by reducing the amount of transactions

Exchanges do this by not amalgamating withdrawals into large transactions.
See Processing multiple transactions very fast


text:
Get filtered block for a given transaction using bitcoinj
I am currently working with bitcoinj to interact with bitcoin node.
I am trying to obtain a filtered block for a given transaction or public key. Is it possible?


text:
I have the identifiers for my wallet, but I don't know how to access it
I am a cryptocurrency novice, so I apologize in advance if this question is too basic. About a year or so ago I created 2 bitcoin wallets and put a small amount of money in them. I forgot about them until recently when I found the sheet of paper where I wrote down the identifiers for them.
In addition, there is a long list of random words associated with each wallet. My question is, I know this should be enough information to access my wallet, but I don't know what to do with the information. Any help would be greatly appreciated.

If your list of words is 12, 18, or 24 words long, it is likely a BIP 39 seed. This means that you should be able to access your Bitcoin by using any software that supports BIP 39 seeds (such as Electrum) and restoring your wallet from those words. Note that not all wallets that support BIP 39 will derive addresses in the same way; some derive them with a different derivation path so you may not necessarily see your Bitcoin and may have to use a different wallet. For most wallets though, it should work.
The exception is MultiBit HD. If you think you used MultiBit HD, you can only use MultiBit HD to restore the wallet. MultiBit HD will not be able to restore your Bitcoin if you a different wallet generated the seed (well technically it will restore, you just won't see any balance).