text:
Different hash while creating genesis block
I've created a genesis block following this instructions:
https://bitcointalk.org/index.php?topic=181981.0
Using this data:
./genesis 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f "The Times 2018/03/16 Detectives de bots: como desenmascarar a las cuentas falsas" 486604799

I've got:
Coinbase: 04ffff001d0104505468652054696d657320323031382f30332f3136204465746563746976657320646520626f74733a20636f6d6f20646573656e6d617363617261722061206c6173206375656e7461732066616c736173

PubkeyScript:     4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac

Merkle Hash: c029ee7dc05c55da997e0e1a0a926470d163ea1a795222e05e3f39a14f990499
Byteswapped:         9904994fa1393f5ee02252791aea63d17064920a1a0e7e99da555cc07dee29c0
Generating block...
1479761 Hashes/s, Nonce 94652275
Block found!
Hash: 000000006263afe74f41e4260a88bc16493f775ea5c3401c41b05b5d21db45d2
Nonce: 95416095
Unix time: 1521311547

But when I run it in Bitcoin code I get a different hash. I did changes here:
static CBlock CreateGenesisBlock(uint32_t nTime, uint32_t nNonce, uint32_t nBits, int32_t nVersion, const CAmount& genesisReward)
{
    const char* pszTimestamp = "The Times 2018/03/16 Detectives de bots: como desenmascarar a las cuentas falsas";
    const CScript genesisOutputScript = CScript() << ParseHex("04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f") << OP_CHECKSIG;
    return CreateGenesisBlock(pszTimestamp, genesisOutputScript, nTime, nNonce, nBits, nVersion, genesisReward);
}

And here:
// Creating genesis block with Unix time, nonce, nBits, version, and coin reward
genesis = CreateGenesisBlock(1521311547, 95416095, 0x1d00ffff, 1, 100 * COIN);

Hash I get from Bitcoin source:
b89d3d49beff21a6da00c8dc15ff82dfdba548e860ccaaf34669ecd94e9d1134

Hash I should get:
000000006263afe74f41e4260a88bc16493f775ea5c3401c41b05b5d21db45d2

I guess I'm forgetting to set something, or maybe the genesis code is outdated.

Maybe this is useful for someone: I didn't find why the hash was different, it's possible that the code I used for generating the genesis block is outdated.
Finally I used https://github.com/lhartikk/GenesisH0 and it worked, the only caveat was that I only was able to change the timestamp, when I tried to change other stuff (e.g. nBits) it failed.


text:
Wallet is encrypted and currently locked, How can get unencrypted (unlocked) it?
Wallet is encrypted and currently locked, How can I unencrypted the wallet to unlock?
Because of my Bitcoin wallet not getting synchronising currently, so I could not get bitcoin balance on one of my address in wallet.

What wallet software are you using?

I do not want to rain on your parade, but this may be hard to do. These wallets are made with the idea that outsiders will not get into them.
You could try to brute force the login, but it may take longer than a lifespan to break. However, here is something that you may consider. If you have a known rule-set for your password generation, you can substantially eliminate the possibilities in your brute force attack.
I am speculating that your passwords are complex, but there may be hope here based on the fact that password generation is not truly random. Because of this fact, there are rules that you (as the password generator) or a program like keepass (as the password generator) usually follow.
We really need more information to make an informed suggestion, but let me give you a couple scenarios.
If you create your own passwords:

Do you use spaces? Usually this is a yes or no for most people.
Is there a special character that you tend to focus on? Does it occur at a particular place (i.e. at the end)
Do you use words or phrases or is it always random?
What is the range of characters in your passwords? (i.e. Always type 6-10 characters).

If you use a generator for your passwords, there may be rulesets in place that help you eliminate possibilities:

Look at the number of characters allowed.
Are letters, upper case, lower case, numbers etc. required?
Are special characters allowed?

After you have answered this, and similar questions, you can begin to chip away at the total possible entries. So let us say you force at least one number and one capital letter and one special symbol and is 10 characters in length. Now, you can eliminate all possibilities that do not follow that pattern. You will not use brute force for any 9 character string, anything without a symbol, etc. Your possible result set can be reduced substantially because you inherently know the algorithm you use for password generation.
A goldmine for you is the eliminate the possibilities on a particular character in the string. Commonly, people will start or end a password with similar rules. For example, they put a $ at the beginning. Now you have reduced the search by a power factor. Keep this up with rules that you know would have been enforced and your set gets even smaller.
Now that your result set is reduced, work will be involved. Find a program to brute force a wallet, or utilize a script that you create to brute force. Most have APIs associated with them (i.e. https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list).
Technically, there are tools that will help with this process, (See: Forgot wallet encryption password, are any brute force tools available? ) so you may be able to find something useful there. Otherwise, if you cannot get a hold of those tools, pitch it to some computer science students at the local university to create such an app for a project :-) It would take a little bit to code and I am not sure of your programming abilities, but it would be very possible.
Good luck and I hope you get your wallet back!

If you've forgotten the password you'd set for the wallet, you'll probably won't be able to unencrypt/unlock your wallet nor spend your coins.

Wallet can be unlocked by this PHP API function: walletpassphrase (passphrase, timeout) and can locked by this: walletlock().

source: Stack Exchange

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

sort: votes


text:
Bitcoin's real-time Buy and Sell price API
What is the API to get Bitcoin's real-time Buy price and sell price on my site? and how can get it from to implement in my website developed in PHP.

For which exchange?

I do not need form a particular exchange, I want to get a global price for buy and sell for bitcoins, so I can decide my exchange rate.

@JagdishRam fact is there is no single global price because different exchanges have different prices. If you want an index or average price then there is the coindesk index, the bitpay one and the winkdex. They all have APIs that you can use. However if you want the price for purposes of trading then it makes no sense to use an indexed price. Use the price of the exchange you will actually use.

Bitcoin does not have one single buy and sell price. Bitcoins are exchanged on many different exchanges, each keeping track of their own market price.
However, BitcoinCharts.com has a useful API that summarises many of the largest exchanges according to their trading volume. You could use that to display the Bitcoin price on your website.

Thanks for the info, but I'm trying to add Bitcoin payments to a website and create a BTC invoice based on the current exchange rate and the USD price, I don't know how often people are going to want to pay via BTC and BitcoinCharts has this announcement on their api info page: Don't query more often than once every 15 minutes!, is there any other API or way to get the current exchange rate, thanks

That reply is quite old. Currently, CoinDesk has a pretty decent price API that takes multiple exchanges into account. Or you can just pick a single exchange and use their price.

Other interesting Bitcoin Price APIs that you might consider are those currently provided by Quandl and BitcoinAverage.
https://blog.quandl.com/getting-started-with-the-quandl-api
https://bitcoinaverage.com/en/api-collections

Another one again is https://blockchain.info/api/exchange_rates_api

8 years old, but for the record:

indices are usually (always?) a mid-market price; you probably want a real spot trade buy or sell price. Most likely you can only see that spread on the exchange you want to use.
Unless you actually check the order book volumes, you can't be sure the price you see will not slip as you buy/sell with volume.

Those differences may make up as much as a couple percent even for small volumes.

Check out 1Forge, they provide a free JSON API for several cryptocurrencies (Bitcoin, Etherium, LiteCoin, Ripple, Dash, and Bitcoin Cash). They also provide data for several standard Forex pairs + gold and silver.
Have a look at their documentation here: https://1forge.com/forex-data-api/api-documentation
If you’re using JavaScript/Node.JS, PHP, Python or Ruby then you can quickly bring in one of their libraries: https://1forge.com/forex-data-api/libraries

Here is an open-source one i found, and the most simple one:
https://github.com/coinconvert/crypto-convert
Instantly convert cryptocurrency and get price information.

Top 100 Crypto Currencies Supported

Top 30 Fiats Supported Price &

Ticker information updated on a configurable interval from multiple
secure sources (Binance, Bitfinex, OKEx)

Any pair can be converted, be it Crypto -> Crypto or Fiat -> Crypto.

The asker is looking for a source for the Bitcoin price. It's not clear to me why you think that a fullblown trading tool is a fitting answer here. In case this is your project, please note that we require users to disclose when they recommend their own products. If you are looking to advertise your project here, you're probably here for the wrong reason.

all_licenses: 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/


text:
Failed to build Bitcoin Core from source, Ubuntu 17.10
I'm building from source v0.16.0 on Ubuntu 17.10
I cloned the repo, checked out on v0.16.0, ran ./autogen.sh followed by ./configure CXXFLAGS="--param ggc-min-expand=1 --param ggc-min-heapsize=32768"
the make command however produces the following error:
Makefile:8224: recipe for target 'qt/qt_bitcoin_qt-bitcoin.o' failed
make[2]: *** [qt/qt_bitcoin_qt-bitcoin.o] Error 1
make[2]: Leaving directory '/home/angelag/src/bitcoin/src'
Makefile:9462: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/angelag/src/bitcoin/src'
Makefile:747: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

from the output of make command the errors started here:
...
...
CXX      qt/qt_bitcoin_qt-bitcoin.o
In file included from ./qt/paymentrequestplus.h:10:0,
                 from ./qt/paymentserver.h:35,
                 from qt/bitcoin.cpp:25:
./qt/paymentrequest.pb.h:12:2: error: #error This file was generated by a newer version of protoc which is
 #error This file was generated by a newer version of protoc which is
  ^~~~~
./qt/paymentrequest.pb.h:13:2: error: #error incompatible with your Protocol Buffer headers. Please update
 #error incompatible with your Protocol Buffer headers.  Please update
  ^~~~~
./qt/paymentrequest.pb.h:14:2: error: #error your headers.
 #error your headers.
  ^~~~~
...
...

I take it you have the dependencies specified in build-unix.md specific section Linux Distribution Specific Instructions - Ubuntu & Debian - all sections therein?

That error means that protoc was updated since paymentrequest.pb.h was generated (it is not part of the source distribution, protoc generates it). Do make clean and then make. That should fix this error.

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


text:
Bitcoin Solo Mining with bfgminer
I am trying to do solo mining with bfgminer but it does not seems to be working
./bfgminer --url 127.0.0.1:18443 --user test --pass test
On bitcoind logs I can see the request logs
2018-05-14T10:36:25Z Received a POST request for / from 127.0.0.1:43312
2018-05-14T10:36:25Z ThreadRPCServer method=getwork user=test
2018-05-14T10:36:57Z Received a POST request for / from 127.0.0.1:43330
2018-05-14T10:36:57Z ThreadRPCServer method=getblocktemplate user=test
2018-05-14T10:36:57Z Received a POST request for / from 127.0.0.1:43332
2018-05-14T10:36:57Z ThreadRPCServer method=getwork user=test
On bfgMiner I can see the following messages
[2018-05-14 16:10:49] No servers were found that could be used to get work from.
[2018-05-14 16:10:49] Please check the details from the list below of the servers you have input
[2018-05-14 16:10:49] Most likely you have input the wrong URL, forgotten to add a port, or have not set up workers
[2018-05-14 16:10:17] Pool: 0  URL: http://127.0.0.1:18443  User: test  Password: test
[2018-05-14 16:10:17] Pool: 1  URL:
http://localhost:8332/#getcbaddr#allblocks  User: test  Password: test
Any help

The error messages you see are exactly what you get if you just start bitcoind without any proper configuration.
Did you make sure

you started your bitcoind with the -server flag at all? Only that will prepare your bitcoin node to allow connections from external workers such as bfgminer.
you waited for it to sync with the network? That can take up to some
hours

This seems to be a good answer. However, please add some details, one-sentence answers are not well-received here.

first if your url is not on a mining server your not going to be able to mine (and probabalistically there may be a way but anyway). it would look closer to -o stratum+tcp://emc2.suprnova.cc:3366 and the 127.0.0.1 should be an API address not the url.
second, for everyone who is looking for help with BFGMINER if you do not:
export GPU_MAX_ALLOC_PERCENT=100
export GPU_USE_SYNC_OBJECTS=1
then it probabalistically will not work as well. The export commands sync bfgminer immediatly to my gpu: ASUS GTX 1080 and starts hashing around 900 k/hs.


text:
How can I find the "real" difficulty on testnet?
As is well known, testnet has a "20-minute rule": if no block is found within 20 minutes, the mining difficulty drops to 1 until a block is found.
From some experimentation, it appears that bitcoind's getdifficulty function reports the difficulty of the most recent block.  Thus, if the most recent block was mined under the 20-minute rule, getdifficulty returns 1.
In this case, how can I find the "real" difficulty level?  That is, the difficulty that would be required of a block submitted less than 20 minutes after the previous one?
The best approach I have found so far is to follow the blockchain back until I find a block with a difficulty other than 1 (or less than 20 minutes after the block preceding it).  But this will be prone to error if a difficulty adjustment has recently taken place.
bitcoind must know the real difficulty at all times; can I query it?

Why would bitcoind always have to know it? If the 20-minute-rule is hard, bitcoind will just accept any new block it receives after 20 minutes.
But I never heard of this rule, can you point out where you found out about it?

@StevenRoose: https://en.bitcoin.it/wiki/Testnet: "In addition, if no block has been found in 20 minutes, the difficulty automatically resets back to the minimum for a single block, after which it returns to its previous value."

@StevenRoose: If bitcoind receives a block that's less than 20 minutes newer than the previous one, it needs to use the "real" difficulty in deciding whether to accept it.

You can use the getblocktemplate RPC command and look at the target field.

authors: Лечение наркомании Украина


text:
Address and Public key
I am reading about cryptography in Bitcoin. Bitcoin adress is created by applying cryptographic hash function to public key of the wallet. I know that this function is a trap door function but what are possible vulnerabilities if the public key could be derived from the address? Public keys are used anyway when authenticating the creator of the transaction (signer of the transaction).

There are several aspects to not sending to a public key directly. Here are a few I can name

RipeMD160 shortens the address from 256 bits to 160 bits
A checksum is introduced to the address
An address doesn't expose the pubkey, so if the ECDSA gets compromised, funds are still safe ["quantum PC attack resistant"]
Pay to script hash is possible with the same address format; in later iterations with e.g. taproot this can greatly enhance privacy and functionality at little or no extra on-chain cost


text:
How to check ownership of wallet with segwit address
So .. this seems like a simple question.
If i have a wallet and someone wants to send me BTC. I want to make sure they own the wallet they claim to be sending funds from. Usually people do something like a satoshi test do confirm this.
Before segwit one could sign a message and with address given, you could decrypt the message to confirm they actually own the wallet containing that address.
After segwit that functionality is broken.
Furthermore, i can't take the getrawtransaction <trans> 1 command to find the vin of the transaction and the to extract the txid and vout of the vin. Then using that txid and again run getrawtransaction <trans> 1 and look at the coorepsonding vout and the "n" that matches the previous vout not longer works after segwit. (all of this makes sense as the way transactions are formed is completely different).
Therefore: If someone is supposed to send me 0.00001 BTC, how do i verify what wallet that came from.
In Simpler terms: How can i verify that someone owns a wallet with segwit addresses?

Before segwit one could sign a message and with address given, you could decrypt the message to confirm they actually own the wallet containing that address.

As you discovered, the signmessage and verifymessage RPCs in Bitcoin Core don't currently work with segwit.  There have been discussions about the best way to fix that, but as of this writing, updated code is not yet available.

Furthermore, i can't take the getrawtransaction  1 command to

The getrawtransaction RPC now takes true instead of 1 for detailed JSON output.  The txid, vout, and vin fields in the JSON output all the same for the way you're using them (they just have a few extra fields now for segwit outputs and inputs).

How can i verify that someone owns a wallet with segwit addresses?

There is no easy way at the moment using Bitcoin Core or any other software I'm aware of.  If possible, you may want to change your workflow so that you don't need to verify wallet ownership.  For example, if you currently receive all payments to the same address, you can start using separate addresses for each customer, so Alice pays $ADDRESS_1, Bob pays $ADDRESS_2, and you can tell the difference between their payments by which address they paid.
Alternatively, if you need to verify address ownership for refunds, you can have users provide a refund address at checkout.

I can see in this scenario that would make sense. I am talking about from a general scenario. Someone is claiming they have 10,000 BTC. How can i verify that claim.


text:
Generate Bitcoin address with privatekey
I am able to create new bitcoin address using jsonrpc by accessing the bitcoind client, where I am able to get only the account name and address but I could not get private or public key.  Is there anyother approach to create new bitcoin address with private and public key.

I can't tell you how to get the keys in the bitcoind client, but an address is ALWAYS generated by the public key and the public key is ALWAYS generated by the private key. Maybe that information helps you.


text:
What happens if full nodes don't check for double spends or deliberately lets a double spend TX pass and then this full node relays the transaction?
I am studying about Bitcoin and Blockchain tech via the Princeton crypto course, and it mentions that Full nodes do the following checks :
i)transaction is valid with the current blockchain,
ii)whether the scripts matches whitelist,
iii)transaction hasn't been seen before and
iv)doesn't conflict with others its relayed (to avoid double spend).
However, the lecturer also mentioned these checks are not enforced on a node. Lets say a full node may have a full set of of UTXO but still decides to relay a transaction that has been spent before (effectively ignoring the fact that the TX is not on the UTXO pool) , and eventually this TX is relayed around and makes it into a block. Since the miners trust these nodes to verify transactions , wouldn't the TX be put into the consensus chain ?
I understand that the mining process (POW) and resulting block reward can only be  claimed/collected if the block ends up on the long-term consensus branch, but this doesn't safeguard the malicious node behavior as I have explained since miners don't check for double spends.

The statement that miners trust these nodes might be wrong... a miner would want to check if his transactions and blocks are correct, otherwise he might get ignored from the network (when relaying wrong tx or blocks). Also he might loose his block reward, and would have performed the block calcs in vain?

Since the miners trust these nodes to verify transactions, ... since miners don't check for double spends.

What makes you think this? Miners are also nodes; they are a subset of nodes. Miners still receive and verify all transactions, they don't just blindly trust what some other node has given them. Miners are incentivized to check transactions as including any invalid transactions means that the block will also be invalid and thus be rejected by the other nodes and miners on the network.
If a miner produces an invalid transaction (e.g. by including a double spend), the block will be considered invalid. Miners do not determine what is valid and invalid, nodes do. So when the nodes on the network receive that invalid block, they will reject it as invalid and not add it to their blockchain. Furthermore, since miners are also nodes, other miners will reject the block and thus they will not mine on top of it.
If miners mine on top of the invalid block, there will be a blockchain fork. The nodes on the network will refuse to follow a chain that contains an invalid block, even if it has more work. They only follow the valid chain with the most work, and an invalid block makes that chain invalid.

thanks for your input. How long does a Miner usually take to check every single transaction in a block  it is mining against the UTXO set ?

It takes the same time as it does for any other node. It usually takes a few milliseconds. Furthermore, because miners are nodes, they have likely received and checked all of the transactions before they appeared in a block, so they can skip checking them again when they get them in a block.

Miners that don't check for double spends only connect to nodes that they fully trust. And there's a good reason for this -- every non-broken node will ignore an invalid block. So were a miner to ever mine a block that contained a double spend, every other node would ignore that block and it would never become part of anyone's view of the consensus chain.


text:
What does a bitcoin transaction contain?
I'm learning about basic transactions and know that a transaction should contain:
i) Signature of the sender using some operator: sign(private key,message)
ii) Receivers Public key (wallet address)
iii) Hash Pointer pointing to the originating transaction / previous owner (i.e. A hash of the previous transaction's hash, signatures, etc)
I'm not sure if this is all that a transaction should contain, and also whether my understanding of point i) and especially iii) is correct. Hash pointers are a bit confusing; I understand the 'direction' of the arrow to mean we are pointing to what we are hashing, as opposed to the direction of flow of information.
Interested to hear your thoughts to help my understanding!

Transactions consist of a version number, a list of inputs, a list of outputs, and a lock time.
Each input contains a reference to the output it is spending. This reference is the hash of the transaction containing the output followed by the 0-based index of the output's position in list of outputs. Then there is the input script which contains whatever data is necessary to satisfy the conditions of the output script. Lastly there is a sequence number.
Each output contains the amount of Bitcoin in satoshis and an output script that defines the conditions necessary to spend that output.
It is important to note that addresses are not included anywhere; rather they encode data that is then used to construct the output script. It is also important to note that output scripts are not just public keys (although a public key can be included in the output script) and input scripts are not just signatures (although signatures can be included in the input script).
A description of the actual transaction format can be found on bitcoin.org.

Thanks Andrew. Regarding my understanding of hash pointers, am I right to say that it simply points to the 'output' it is hashing ? (i.e referencing)

The hash itself does not point to the output. It points to the transaction. The index number, combined with the hash, points to the output.


text:
Looking for whitepapers on pool-resistence mining
I have seen several cryptocurrencies list the feature of decentralization of mining through ASIC-resistance and pool-resistance. However, I have not yet found any whitepapers which explain how the pool-resistance feature is implemented and what are the proofs that such feature actually accomplishes its stated purpose. I want to learn more about ASIC-resistance and pool-resistance by reading some indepth white papers.

ASIC resistance is a buzzword thrown around by scammers trying to sell you what is actually impossible as well as a bad thing. Pool resistance doesn't sound much better.
https://download.wpsoftware.net/bitcoin/asic-faq.pdf

To expand on @Jannes’ answer:
‘ASIC resistance’ is not technically possible in the absolute sense. No matter the algorithm, it is theoretically possible to create some hardware that can run the algorithm more efficiently than a general purpose device (such as a GPU). What ASIC resistance does accomplish is making situations in which creating a more efficient device is much more difficult, and perhaps only possible by a select few skilled and connected individuals and manufacturers.
So with this in mind, ‘ASIC resistance’ actually leads to outcomes of more intense centralization since a smaller group of individuals will have access to create/run the specialized hardware. Generally this is counter to the original intent of making an ‘ASIC resistant’ algorithm in the first place.
I have not seen any claims of ‘pool resistance’,  but I suspect the same principle will apply: Making it harder to create/join a pool will only give the technically capable a larger advantage at the end of the day, because an absolute ban on pools does not seem technically possible.

Thanks for the better answer. And to expand even a bit further: the only way to get some sort of real asic resistance is by having humans change the algorithm, which puts those corruptible/bribe-able/blackmail-able humans squarely in control, i.e. another form of centralization.

An algorithm can be designed that makes creating an ASIC a lot more expensive. If the cost of an ASIC is exceptionally high it could actually deter them and help decentralization.

@blues reread my answer, high cost of development is a centralizing force, you have it backwards. If a system becomes valuable enough (which is the goal, to create value) then we should expect someone to create an ASIC. The easier it is to create an ASIC, the more decentralized the mining power can be.

Only up to some threshold. The cost can be prohibitively high: if asics aren't really profitable they are not going to be used, which in turn helps decentralization. I'm also not talking about hight cost of development, I do mean high cost of manufacturing. (High compared to the gain derived from using them.)

@blues practically, such an upper limit does not seem to exist for any algorithm used by a coin that becomes worth anything at all. 'ASIC resistance' is pretty much a scam sold to uninformed users. Having a high cost of manufacturing/development means a smaller number of people will be able to create the ASICs, and this is the very definition of 'centralization'. For a good overview of ASIC manufacturing in this regard, see this article: https://blog.sia.tech/the-state-of-cryptocurrency-mining-538004a37f9b

I found multy-pool resistance:
https://github.com/goldcoin/wiki/wiki/GoldCoin-Whitepaper#multi-pool-resistant
And for asic-resistance see https://whitepapersindex.com/?q=%22asic-resistance%22
there are ~100 whitepapers found.


text:
How do offchain transactions get validated/confirmed whilst using Lightning network?
How do offchain transactions get validated whilst using Lightning network?

Individual transactions on the lightning network will never be confirmed on the blockchain.
However, the net sum of value passed back and forth on a single channel (regardless of how many lightning transactions that is) will be validated on the blockchain as part of one closing transcribe for the channel.  This is similar to how money is transferred in the traditional financial system using a process called "deferred net settlement".


text:
why do we need to hash before we use a private key to digitally sign a transaction? isn't just using a private key enough?
why is a hash needed for digital signatures? isn't it redundant since the point of hashing is to ensure contents are not tampered with , which the digital signature can do as well (on top of ensuring txn comes from the person)

I  addition to Claris' answer, if your question is about ECDSA, the hashing step is actually an essential part of the signature scheme and not just a step we choose to do before invoking it. Without it, the signature would not be secure. This is because given a public key, it is possible to compute (signature, message hash) pairs such that the signature is valid for the given public key and computed message hash. However, the message hash won't be the hash of a known message then, and thus making ECDSA verifiers redo the hashing is sufficient to prevent this attack.

Hashing ensures we get a constant length input for the signature operation.


text:
Public key cryptography question - Is Private or Public key used to sign? Confusion between which key is used to sign and which is used to encrypt
I am relatively new to cryptography and blockchain and am learning about how public key cryptography works, and its application in Bitcoin's environment.
I read two different articles , the 1st which made sense, but the 2nd confused me.
From the 1st article (https://www.blockchain-council.org/blockchain/how-does-blockchain-use-public-key-cryptography/), I understand that the sender's private key is used to sign the digital transaction and the sender's public key is used by the miner/receiver to verify the senders signature.
However,a 2nd article I read (https://www.ibm.com/support/knowledgecenter/en/SSB23S_1.1.0.14/gtps7/s7pkey.html) about public key cryptography has it the other way around; using Public key first then the private key after. I have attached the picture from the 2nd link:

What am I understanding wrongly? Why is the use of keys in opposite order?
Thank you in advance for your input...

What am I understanding wrongly?

You are mixing up several distinct uses of cryptography, several different purposes:

authentication
non-repudiation
privacy
proof of integrity

Cryptography in General
Purposes
Privacy
If you want to send a private message to someone, in a way that no-one intercepting the message can read it, you typically encrypt the message using a symmetric (secret-key) algorithm and a newly created secret-key. You then encrypt the secret-key using the intended recipient's public key. This ensures that only the intended recipient can decrypt the secret-key for the message by using their private key (which no one else knows). After decrypting the secret key, the intended recipient is able to decrypt the message using the symmetric algorithm.
Note that you only use a symmetric algorithm to encrypt the message because such algorithms are far far faster than asymmetric (public-key) algorithms. It is primarily for efficiency, not for any other reason.
Authentication
If you want to send a message to someone and provide proof that you sent the message, you use a different procedure. You create a cryptographic hash of the message using a hashing algorithm. You then encrypt that hash with your private key (that only you know). The encrypted hash is sent with the message. This encrypted hash is known as a digital-signature. The recipient of the message can use your public key to extract the hash and compare that with a freshly computed hash of the message, if the hashes match it is proof that you sent the message.
Types of Encryption
Assymetric
Asymmertic means you use different keys for encrypting and decrypting. There is both a private key and a public key. hence the name "public-key cryptography".
Symmetric
By contrast, an example of a symmetric (not asymmetric) algorithm is DES which is a symmetric encryption algorithm because there is only one key, the same key is used for both encrypting and decrypting. The key is a shared "secret-key" - hence the names "secret-key cryptography" or "shared-key cryptography".

Cryptography in Bitcoin
From what I've read, Bitcoin uses

Hash algorithms

SHA-256 for proof of work

Digital signatures

ECDSA for signatures on transactions

Note that ECDSA is asymmetric
Note also that Bitcoin cares about anonymity and not about privacy (the blockchain is public not private). Therefore Bitcoin does not use encryption for privacy purposes. Your Wallet software might use encryption to hide your secret keys behind a password - but that is not part of the BitCoin spec.

References

Satoshi Nakamoto, Bitcoin Whitepaper. Sections 2 and 4.
Bitcoin Wiki, ECDSA

so Bitcoin uses the 'Authentication' method you mentioned correct? and not the 'Privacy' Method. The other response to this question by MCCCS states 'asymmetric encryption' is not used by Bitcoin; but your response suggests that 'we create a cryptographic hash of the message'. Not sure if im overthinking this!

@DCH: The algorithm used for a cryptographic hash is a "one-way" or "trapdoor" algorithm, not an encryption algorithm. Asymmetric encryption is used to create digital signatures. See https://en.bitcoin.it/wiki/How_bitcoin_works "public-key cryptography" is another name for "asymmetric encryption". See https://en.wikipedia.org/wiki/Public-key_cryptography

The first article is about how Bitcoin signs (the hash of) data to prove ownership (and to spend) coins. There's nothing encrypted, it's used as an authentication scheme.
The second article is about asymmetric encryption. It's for encrypting data, not for authentication. It's not what Bitcoin uses. (See also: ECIES)
They have different purposes. Don't let them confuse you.

The two articles are talking about two very different things.
The 1st article is about digital signatures, which are used to prove that someone has written a message and was not impersonated. These are used extensively in Bitcoin. The sender of the message uses his own private key to sign, the receiver uses the sender's public key to verify that the signature is authentic.
The 2nd article is about encryption, which is used to hide the contents of a message from everyone but the intended recipient. This is not used in Bitcoin at all. In places where it is used, the sender uses the receiver's public key to encrypt, and the receiver uses his own private key to decrypt and gain access to the information.


text:
Should i send bitcoins to hash160 or normal address
I am a bit confused here.
I know that a public address is generated from the private key which you should keep secret, or else, anyone who has it will be able to spend the coins "in that address".
However, when i was checking this link:
https://blockchain.info/address/dd9c56410b2e734e551fc34331a056b70e939c98
containing the hash160 address, blockchain.info showed me that the address from which this hash160 was made is the following: 1MCmcsjzocP68LyBZznA3tjRMvGd4eQRx1
However, if i navigate to this link:
https://blockchain.info/address/3MtnYRESMWhUDWfch6SkUX6MWSZLcYpRc1
blockchain.info will show me that the hash160 generated from the address : 3MtnYRESMWhUDWfch6SkUX6MWSZLcYpRc1 is the same as the one generated from 1MCmcsjzocP68LyBZznA3tjRMvGd4eQRx1.
I know that hashing is not a one to one function, it 'is' a many-to-one function but in this case,
My sub-questions are the following:
1) is it possible to get the real address (e.g : 1MCmcsjzocP68LyBZznA3tjRMvGd4eQRx1 or 3MtnYRESMWhUDWfch6SkUX6MWSZLcYpRc1) from the hash160 address (dd9c56410b2e734e551fc34331a056b70e939c98)?
2) why is blockchain.info showing me the the address of the hash160 (dd9c56410b2e734e551fc34331a056b70e939c98) is 1MCmcsjzocP68LyBZznA3tjRMvGd4eQRx1 and not 3MtnYRESMWhUDWfch6SkUX6MWSZLcYpRc1?

To generate an address from a hash160 you need two inputs. The hash and the version byte. Version byte 0x00 corresponds to a P2PKH address (starting with 1) and version byte 0x05 to a P2SH addres (starting with 3)

Both P2SH and P2PKH use HASH_160. That's what the h stands for in them.
Each HASH_160 is valid in both addresses. As to which address you need to send your BTC to depends on if you are using a redeem script or a public key to spend it.
If you send it to an address starting with 1, your output is encoded as OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG. To spend this, you require a private key that leads to the public key to which the hash belongs, and sign the tx using that.
If you send it to an address starting with 3, your output is encoded as OP_HASH160 <RedeemScriptHash> OP_EQUAL. In this case, to spend the output, you need to provide a redeem script for which the HASH_160 equals the one used in the address (along with any information that the redeem script might use, such as the signatures for a multisig address, or witness for a segwit address).
Due to this, each HASH160 can effectively be used to generate two addresses. Blockchain.info defaults to showing the 1-address.
DO NOT send any coins to the 1-address if your original address was a 3-address, and vice-versa. You will not be able to recover them.

thank you raghav! and why is hash160 useful then?

1) is it possible to get the real address (e.g :
  1MCmcsjzocP68LyBZznA3tjRMvGd4eQRx1 or
  3MtnYRESMWhUDWfch6SkUX6MWSZLcYpRc1) from the hash160 address
  (dd9c56410b2e734e551fc34331a056b70e939c98)?

Yes. It is possible and very easy
const QString MyKey20::toString ( ) const
{
  quint8 tmp1 [21];
  tmp1 [0] = NET_BYTE;
  memcpy ( tmp1 + 1, constData ( ), 20 );
  const MyKey32 key ( tmp1, 21 );
  quint8 tmp2 [25];
  memcpy ( tmp2, tmp1, sizeof ( tmp1 ) );
  memcpy ( tmp2 + 21, key.constData ( ), 4 );
  char addr [40];
  memset ( addr, 0, sizeof ( addr ) );
  BASE58::encodeBase58 ( tmp2, sizeof ( tmp2 ), addr, sizeof ( addr ) - 1 );
  return QString ( addr );
}

const QString MyKey20::toStringP2SH ( ) const
{
  quint8 tmp1 [21];
  tmp1 [0] = P2SH_BYTE;
  memcpy ( tmp1 + 1, constData ( ), 20 );
  const MyKey32 key ( tmp1, 21 );
  quint8 tmp2 [25];
  memcpy ( tmp2, tmp1, sizeof ( tmp1 ) );
  memcpy ( tmp2 + 21, key.constData ( ), 4 );
  char addr [40];
  memset ( addr, 0, sizeof ( addr ) );
  BASE58::encodeBase58 ( tmp2, sizeof ( tmp2 ), addr, sizeof ( addr ) - 1 );
  return QString ( addr );
}

2) why is blockchain.info showing me the the address of the hash160
  (dd9c56410b2e734e551fc34331a056b70e939c98) is
  1MCmcsjzocP68LyBZznA3tjRMvGd4eQRx1 and not
  3MtnYRESMWhUDWfch6SkUX6MWSZLcYpRc1?

Because blockchain.info programmers haven't implemented this kind of search request. (In fact it was available several years ago, but later they throw it)

thank you for your answer however, i don't get it. if i give my friend the hash160 address, the bitcoin will be sent to which address?

you should not give 160bit hash because no client would accept it as valid bitcoin address


text:
What does the ledger number correspond to in ripple?
I'm playing around with Ripple's data on https://xrpcharts.ripple.com.
What does the Ledger # correspond to and how does that number relate to the gateway?


text:
Bitcoin wallet file location in smartphone
I would like to know where is the wallet file (or private keys) stored on usually in the Bitcoin mobile wallet such as Android wallet (Mycelium or Bitcoin wallet)? Because I installed Bitcoin wallet and I could not find where are the private keys storing

The android Bitcoin Wallet application stores data using androids MODE_PRIVATE in the following location:

/data/data/de.schildbach.wallet/files/wallet-protobuf

It is worth noting that this is not compatible with your standard wallet.dat file from bitcoin-qt but may be compatible with other bitcoinj clients that support protobuf formats.
Some actions in the app cause a backup file to be created in up to two locations.  The first is a key backup at:

/data/data/de.schildbach.wallet/files/key-backup-protobuf

The second is the external backup feature which  is stored on the SD card at the following location:

/sdcard/Download/bitcoin-wallet-backup-<yyyy-MM-dd>

Here is the link to detailed specs of the Android bitcoin wallet

For the Bitcoin Android wallet, you can do a backup from inside the app.  The backup will be located here by default /sdcard/Download/bitcoin-wallet-backup-<yyyy-MM-dd>.  See the Files section of this page for more details.


text:
How to change the data directory with bitcoin-cli?
I am trying to change the data directory used by bitcoind and I am uder the impression that the command -datadir was removed as I can't find it with bitcoin-cli help, when I try to use it I get Too few parameters and bitcoin-cli help datadir says datadir doesn't exist. I need to specify a directory that is not on the root partition, how to do it ?
Also why bitcoin core is so user unfriendly, it's quite surprising I thought it was the main bitcoin program. It started downloading the blockchain on my root partition without me even being aware of it (just start bitcoind and it starts silently downloading).

Yeah, it would be better if it asked us where we wanted to store the large data files, when we install via the command line. It does not. Not even a warning or anything. Glad I found this post. :-)

you should use it like this bitcoin
bitcoind -datadir=/your/external/path

Hope this helps!

Relative paths work too: bitcoin-cli -datadir=. stop

If you would like to do this permanently create a ~/.bitcoin/bitcoin.conf file and include:
datadir=/your/path

I just tried this and it doesn't work.  Can you please verify that the commands are still valid?

You probably forgot to move the bitcoin.conf file from your non-default data directory to the default location. (~/.bitcoin/bitcoin.conf)
Then when you rund bitcoind, it access the bitcoin.conf file in the default way, and that file tells bitcoind to put blocks where datadir= specifices.

that does work but then it creates another bitcoin.conf under the provided datadir path, and that's what bitcoin-qt also opens up... it is a bit confusing, should I set other conf settings in the .bitcoin/bitcoin.conf or new datadir's bitcoin.conf


text:
Bitcoin-qt taking forever to acquire the blockchain
I thought that this was the old days when it took forever for bitcoin core to acquire the bootstrap but it looks like it's still the case. I basically ran the program for 2 hours and I'm still under 10h. Any idea on how to fix the problem or download the blk files elsewhere ? Why can't I find the equivalent of the bootstrap as a torrent ?

I don't think you have a problem, but are seeing expected behavior.
Bitcoin Core is downloading and verifying about 80 GiB of data. Even with all the improvements that have been added, this will take several hours to days depending on your hardware.
Bitcoin Core is a full node. It mirrors all the information of the blockchain, and checks it first hand. By running Bitcoin Core, you become part of the users that verify and provide the network's data for others.
You could take a shortcut and acquire an already verified set of data, but then you'd be trusting a third party that they didn't add incorrect information to trick others in the network. However, that's exactly the point of why you'd run a full node in the first place: When you do, you can be certain that you have a correct copy of the blockchain.
If you don't require full node security or feel that it is too much hassle to synchronize with the network, you might find it more comfortable to run a user oriented wallet. You can find a comparison at Choose your wallet.

to be fair I can download at 10m/s downloading 80G should be a matter of 2-3 hours but here I'll need 48h+ just like in the old days

Not the download but the verification of the blockchain is the bottleneck.

I remember when bootstrap was still a thing that I downloaded bootstrao via torrent and then the setup was quite fast. Isn't there a way to do that anymore ?

The bootstrap provided only a quick way to download the whole data set, it still had to be verified then. If you remember it being faster then, that was probably only due to the blockchain being much smaller then: The blockchain almost doubled in size in the last twelve months. Bootstrap is deprecated now, because the download from the network was improved with the header first policy, torrent shouldn't be faster anymore. However, when you download from the network instead of the bootstrap, you can already start the verification in the background while downloading.

I'm not convinced I will probably have to let it run for a week h24 when with the bootstrap it was quickly over, and now I have a much more powerful computer but whatever

The bottleneck when synching up w/ Bitcoin Core is likely to be hard drive access and I/O time.
I have a 5 year old (full size) HP pavilion dv6 laptop running Windows 7... CPU usage rarely exceeds 20%, so changing the task priority does nothing to speed up the process.
With a 56 Mbps connection there can be many minutes when the network usage is only a percent or two, followed by periods where it's 10-50% or more; after sucking down the data it then has to crunch it all. So connection speed likely won't make a big difference.
Go into Task Manager (ctrl-alt-delete) and under the Performance tab there's a button for the Resource Monitor, which has a tab for the Disk; this will show processes with disk activity, and you can see there how bitcoin-qt.exe is keeping the disk activity pegged near the max (10 Mb/s for me) most of the time. Task Manager also has a Networking tab where you can follow what's happening there.
I still have 31 weeks to go and it's now taking ~1 hour per week of progress, or a little more. Back when I was still 1½-2 years behind it was 10-15 minutes per week of progress; at ~3-4 years behind I first began to notice it taking several minutes to click down another week.
Current total blockchain size is 86 Gb, and it's adding ~1 Gb per week of progress, so I'm guessing it'll total out at ~120 Gb.
This is definitely an issue for BitCoin if the thing pyramids in size to where nobody new can synch up with it.
I first started ~7 weeks ago and have been working on it ~3 hours a day maybe 3-5 days a week; with all the disk usage my machine is not very usable when it's doing this.
Hope this helps someone.

I've found that using a SSD helps to speed-up synchronization significantly and if you run the newest version of Core, you should also notice a significant speed-up due to the new "assumevalid policy".

You can download a compressed bootstrap.dat to reduce the first time block synchronization. i.e. https://flo.sh/bitcoin-qt-bootstrap-dat/
Using a bootstrap.dat file may also be useful if you need to setup multiple nodes and want to avoid every node loading the complete blockchain itself.


text:
Is it possible to run HD derivation with an encrypted master node or seed?
Given either a seed or the private part of a master node, that is encrypted using AES-256-CBC (or another secured symmetrical cypher) with key K, is it possible to run derivation such as described in BIP32 to obtain derived private keys also encrypted using the same algorithm and the same key K?

Though EC-point operations exhibit homomorphic properties: (a+b)G = A+B, homomorphic encryption of a HD key pair and deriving its encrypted child is not possible from what I can think of:
Such an encryption scheme would need both encrypted and unencrypted key pass through the HD child derivation step with their relationship intact. Given that the HD child derivation involves a one-way HMACSHA512 function, this seems very hard.

@JamesC. Shoot. If you can provide some relevant links and a more detailed explanation, feel free to turn your comment into an answer.

look into bip38. this does what you want. i am not a cryptologist so can't explain how it does it but it does do it.

It seems like you are looking for an encryption scheme which allows operations to be performed on cipher text, which would result in the same as the same operations being applied to the unencrypted data.
Example: Homomorphic encryption which supports addition

E(data0) + E(data1) = E(data0 + data1)
k being the encryption key, and E(...) the encrypted cipher text.

In then case of HD keys, the desired encryption scheme would need to enable the following

hd_child_derivation(E(m)) = E( hd_child_derivation(m) )
hd_child_derivation() involving a HMACSHA512 function and EC-point operations

I am not sure which encryption schemes would fulfil the above requirements, but fully homomorphic encryption schemes seem to be possible: https://crypto.stanford.edu/craig/craig-thesis.pdf

Thanks for the answer. I'll try to build something upon it and check if it's possible =)


text:
BOP: Not authorized to receive from the temporary destination
I'm trying to run my own BOP (BitsOfProof) server and connect to it. I appear to be able to connect, but I am unable to execute any commands. I am connecting with the following:
    StompJmsConnectionFactory connectionFactory = new StompJmsConnectionFactory();
    connectionFactory.setBrokerURI("tcp://localhost:61613");
    connectionFactory.setUsername("admin");
    connectionFactory.setPassword("password");
    JMSServerConnector api = new JMSServerConnector();
    api.setConnectionFactory(connectionFactory);
    api.setClientId(UUID.randomUUID().toString());
    api.init();

    Transaction t = api.getTransaction("07eec690b003f13ffe73608be35f22e3da6deb55bfd479dbc67c5f44c8d48963");
    System.out.println("t:" + t.getHeight());
    System.out.println("t:" + t.isDoubleSpend());

    Block b = api.getBlock("0000000000fb2149b0a8c0418041513b122e129e17992e22276c558ee7e8269b");
    System.out.println("b: " + b.getHeight());

and the error I am getting is:
Caused by: org.fusesource.stomp.client.ProtocolException: Received an error: Not authorized to receive from the temporary destination. Principals=[org.apache.activemq.jaas.GroupPrincipal(admins), org.apache.activemq.jaas.UserPrincipal(admin), org.apache.activemq.apollo.broker.security.SourceAddressPrincipal(127.0.0.1)]
at org.fusesource.stomp.client.CallbackConnection.processStompFrame(CallbackConnection.java:110)
at org.fusesource.stomp.client.CallbackConnection.access$0(CallbackConnection.java:92)
at org.fusesource.stomp.client.CallbackConnection$1.onTransportCommand(CallbackConnection.java:61)
at org.fusesource.hawtdispatch.transport.TcpTransport.drainInbound(TcpTransport.java:659)
at org.fusesource.hawtdispatch.transport.TcpTransport$6.run(TcpTransport.java:538)
at org.fusesource.hawtdispatch.internal.NioDispatchSource$3.run(NioDispatchSource.java:209)
at org.fusesource.hawtdispatch.internal.SerialDispatchQueue.run(SerialDispatchQueue.java:100)
at org.fusesource.hawtdispatch.internal.pool.SimpleThread.run(SimpleThread.java:77)

As far as I can tell, the admin user should have access to everything.  I tried creating a new user to connect with, and the same error was encountered.  Anyone have any idea what I'm doing wrong?

Tamas has already found a workaround for this issue over on the Apollo JIRA
You need to change your apollo.xml to use the "default" virtual host id, instead of the one that is configured by the Apollo deployment.  Its possible that the client side (BOP) needs to be configured to specify the virtual host to use somewhere, but I have no idea where, so this works for now.
<virtual_host id="default">


text:
When Schnorr signatures are part of Bitcoin will it be possible validate each block with only one signature validation?
In a recent talk Pieter Wuille talked about speed up verification when using Schnorr signatures and various algorithms for verifying multiple signatures.
Would it really be possible to verify one single block by aggregating the keys and signatures of all transactions? (In theory even more transactions over several blocks)
I assume this does imply that the old ECDSA scheme would not be used anymore. If we were backwards compatible we could probably only do this for transactions that used Schorr signatures where as the other ones would have to be verified one by one.
(Leaving aside politics of drastic protocol changes) Couldn't we even save more space if we adopt the block header to include one aggregate Schnorre signature for the block and leave out all the schnorr signatures of the single transactions within that block?
Did I miss anything? The talk did not give many details but just mentioned the idea.

Yes, one validation per block, but not one signature per block.
To clear up confusion, there are 3 distinct technologies involved here:

(1) non-interactive aggregation is the ability for a third party (who does not hold any private keys) to combine multiple signatures, each with their own message and public key, into a single signature that can be verified by someone who knows all messages and public keys.
(2) interactive aggregation is the same, but when the signers need to be aware of the aggregation, and communicate with each other to jointly produce a single signature.
(3) batch validation is the ability for a verifier to verify whether multiple (pubkey,message,signature) tuples are all valid or not, faster than verifying the individual signatures. If one or more of the tuples are invalid the verifier will not learn which ones, in this case.

Schnorr signatures (and any other known discrete logarithm based signature schemes) support (2) and (3), but not (1).
The lack of (1) means there cannot be a single signature for an entire block (*), as the miner who constructs the block is a third party who isn't participating in signature creation.
Due to (2), the best we can hope for (as long as we're restricted to DL-based signatures), is one signature per transaction. Even that requires cross-input aggregation, which has complexities beyond just the implementation of on-chain Schnorr signatures (see this post for example).
However, because of (3) it is correct that there can be a single validation per block, however not a single signature per block. The speedup that is possible through batch validation does become nontrivial, in fact. Each of the 4 lines is an optimization technique that is currently implemented in libsecp256k1, which will pick the best one based on the size of the problem and the memory constraints.

(*) There exists a form of non-interactive "half aggregation" for DL based signatures, where N signatures can be non-interactively combined into a single signature of size (1+N)/2 original signatures. This could be used for blocks, though the gains aren't that great, and there are complexities around block-wide aggregation that make it less interesting.

I guess I have to read up the details again but wasn't the idea of the plain public key model and the construction of musig exactly that non interactive aggregation would become possible? Or should I have asked for musig signatures? I thought musig is just the exact scheme that is currently aimed to be used when people talk about schnorr. Do not mark as correct yet as I still have open questions (which are probably my fault)

MuSig allows non-interactive setup - signing is still interactive.

And MuSig is just one of the things wallet can choose to use when Schnorr validation on chain exist (because the signatures that come out of MuSig signing are compatible with a Schnorr verifier). There are (interactive setup) constructions that let you build k-of-n with a single key for example, or even arbitrary and/or-combinations of participants.

"There exists a form of non-interactive "half aggregation" for DL based signatures, where N signatures can be non-interactively combined into a single signature of size (1+N)/2 original signatures." --
Couldn't this be iterated for O(log(N)) iterations?

@Martin Schwarz What do you mean by iterated? The construction (for Schnorr) is that you combine (R1,s1), ..., (Rn,sn) into (R1,...,Rn,s) where s = H(L,1)*s1 + ... + H(L,n)*sn and L = H(R1,...Rn,P1,...,Pn,m1,...,mn), and Pi are the pubkeys and mi are the messages.

Oh, I see. OK, that doesn't work.

Just saw this today -- very nice figure, why not include into the bip-schnorr?


text:
Why is the length of the transport messages on the lightning network encrypted?
From BOLT 08 we can see that every message is sent in the following way:
2 byte: length
16 byte: MAC
[length] byte: Encrypted message
16 byte: MAC

In reality these messages will be send over TCP/IP on the internet. The ip header specifies the length of the data package that is being sent. If we extract the length and subtract 34 byte for the header plus the two MACs we would know how long the message is.
Is the idea to always send a 2^16 byte ip package and fill the rest with junk data? If yes why isn't that specified in the BOLTs? If no: why encrypting the length anyway?
I assume that an attacker would be able track all tcp/ip packages on the lightning port and would at least be able to deduct which messages are being sent even though the messages themselves are safe.
Assume the message length can indeed be deduced can't that be used together with the MAC to reconstruct the session key for that message?

TCP and other stream based protocols do not have a 1-to-1 correlation of application level messages and IP packets. If you call send() 3 times, it might result in sending a single IP packet over the wire (eg, due to Nagle's algorithm which is enabled by default), it might get sent individually as 3 packets, as you would expect from a packet oriented protocol like UDP, or the messages might end up being split into several packets each because the IP layer has an MTU.
It is generally out of your control at the application layer. You therefore, cannot rely on reading the length from the IP header to tell you about the length of messages. You need to encode the lengths into the data stream and reconstruct the data coming in from the stream into the individual messages as understood by your protocol.
The reason to encode the length separately in the BOLT#8 specification is that each message must be decrypted as a single operation, because each decryption must increase the counter used in the ChaChaPoly cipher. You need to know the exact length of the message before calling the decrypt function on the encrypted payload.
In the BOLT#8 protocol, you send the exact lengths of the encrypted message+MAC, with no padding added. The receiver should first explicitly call recv(buffer, 18, ...), decrypt the result to get msg_len, then call recv(buffer, msg_len, ...) to retrieve the encrypted message, which can then be decrypted in full. recv may also return fewer bytes than requested, so in both cases, the result of recv must be checked and if less than the expected length is read, recv should be called again with the remaining expected length.


text:
How do I decipher the output script one op code at a time
I have an output script:  OP_DUP OP_HASH160 629dba50de30602afbf52b89bd0de056b0ad0e92 OP_EQUALVERIFY OP_CHECKSIG
and an input script for a next transaction:  script_asm" : "30450221008d928cf86eec73535e401e22db895f23d2a04ecb355fa3acfaa6c88de278606602200b34186f5bb90023c06f68bc401276ae7db55433eb0e5b5846a0edb3938876e601 026c6090ef2c100a1beea5c0584de29925d070ebc614fd00f52832250c5b66873c
My understanding is that the output script is a set of conditions that have to to be presented to claim ownership of the coins.
Unfortunately, the page here: https://en.bitcoin.it/wiki/Script
is not very clear as to how the output script is executed step by step.
What I mean is what happens at each stage of these OP codes:
OP_DUP
OP_HASH160
629dba50de30602afbf52b89bd0de056b0ad0e92
OP_EQUALVERIFY
OP_CHECKSIG

Doesn't this help? https://screenshotscdn.firefoxusercontent.com/images/58380c05-2488-4982-800f-56c6453d7acf.png

@MCCS not really, is there any example out there where I can see thne script in action? Not just the description of the script

I think what I'm really trying to ask is, how I manually verify the scriptpubkey against the scriptsigkey


text:
Why is the value of the input way higher than the output resulting in a second change output?
Background: I'm experimenting on the LTC testnet client.
My client has a balance of 0.4 LTC and I sent 0.1 LTC to another wallet address.
https://chain.so/tx/LTCTEST/cc7d6e5e488593fded214e3073195fbaca3807a27d18a7f2550b6fc4909c48f6
Why is the value of the input 0.19 instead of 0.1? Why is this type of transaction created?
Why can't a transaction just be created with 0.1 input and 0.1 output without any change returned?
Thanks in advance.

Looks like mw1eydzkEHohfjcL9xBJNaJEQbFF93Y25F
Got a donation of 0.09

Why is the value of the input 0.19 instead of 0.1? Why is this type of transaction created?

Bitcoin works on a system of transaction outputs. Transaction outputs are spent as inputs to another transaction. When they are spent, they must be spent in full. The input of your transaction is spending an output with value 0.19, so all 0.19 Bitcoin must be spent in full in this input. The remainder must then be sent to a change output.

Why can't a transaction just be created with 0.1 input and 0.1 output without any change returned?

Inputs don't actually have a value attached to them; what block explorers show you as the input value is really the value of the output being spent.


text:
Why this transaction is valid?
The before transaction is @ https://www.blocktrail.com/tBTC/tx/da58f6688b0727a7f1bf3eec899099bde1f18b9c7099f9d2c79556db238e623d
Its output script is "OP_HASH160 da1745e9b549bd0bfa1a569971c77eba30cd5a4b OP_EQUAL".
The current transaction is @
https://www.blocktrail.com/tBTC/tx/839b903b9f79c3372792ceb95917047c46d1b919ed1f6471f5a19d7c865ab32c?txinIdx=0
Its input script is "51".
I verified the transaction manually but it failed.
Why the transaction was accepted and confirmed?
The evolved stack is as below. What's wrong?
628850cb844fe63c308c62afc8bc5351f1952a7f = RIPEMD160(SHA256(1))

The transaction is valid. This golang code gives the correct result.
You need to HASH160 51, not 1.
Additionally, make sure you run the hash on 0x51, not "51" or int(51).

Thank you for your answer, Raghav! I cannot access the golang code on github. Could  you please update the url link? Thanks again.

@JDoe That's odd. Seems to work for me. Here's the same code on pastebin


text:
create a p2sh_script with btcruby gem
I try to create a custom p2sh script using the btcruby gem.
Here is the code I used to generate my script:
def self.create_script
    myscript=BTC::Script.new
    myscript<<BTC::Script::OP_IF
    myscript.append("026edc650b929056b58e4247274a02e3f1665dd10fb1da2575ebae27447f24363e")
    myscript<<BTC::Script::OP_CHECKSIGVERIFY
    myscript<<BTC::Script::OP_ELSE
    myscript.append("f1887875")
    myscript<<BTC::Script::OP_CHECKLOCKTIMEVERIFY
    myscript<<BTC::Script::OP_DROP
    myscript<<BTC::Script::OP_ENDIF
    myscript.append("026edc650b929056b58e4247274a02e3f1665dd10fb1da2575ebae27447f24363e")
    myscript<<BTC::Script::OP_CHECKSIG
end

here is how I generate the transaction to spend from this script (output_script is the script generated by create_script):
def self.create_transaction(output_script, private_key)
    tx = BTC::Transaction.new

    tx.add_input(BTC::TransactionInput.new(previous_id: 'baacd6ca42f27d707795b5e7a8a346de57a9eb2c333cbf404106f612b3504499',
                                  previous_index: 0))

    tx.add_output(BTC::TransactionOutput.new(value: 80_000, script: PublicKeyAddress.parse("14EEEdn7fVBCYawkEAdcjqnKbxvejoZAT9").script))

    key = BTC::Key.new(wif: private_key)
    hashtype = BTC::SIGHASH_ALL
    sighash = tx.signature_hash(input_index: 0,
                            output_script: output_script.p2sh_script,
                            hash_type: hashtype)
    tx.inputs[0].signature_script = BTC::Script.new
    tx.inputs[0].signature_script.append(key.ecdsa_signature(sighash) + BTC::WireFormat.encode_uint8(hashtype))
    tx.inputs[0].signature_script.append_script(input_script)
    tx
end

When I try to execute this transaction I have the following error:
64: scriptsig-not-pushonly

What does this error mean?
Is there a mistake in my logic fore creating the spending transaction?


text:
Effective way for transferring cryptocurrency money from one wallet to other
For example, I created a wallet on one trade platform. My friend has some money in some cryptocurrencies (BTC, ETH ...) for example. So here is my flow:

friend's cryptocurrencies  --(1)--> my wallet on trade platform
  --(2)--> convert to BTC if needed --(3)--> trading here

Base on above flow, my friend can give me by 2 ways:

send me BTC directly. So I don't need to trade again to BTC on trade platform.
send me other cryptocurrencies (i.e: Etherium). Then I convert back to BTC on trade platform with some fee. (normally small)

At step (1), As I see, the fee for bitcoin transaction is too high comparing to other cryptocurrencies. So my question is: is the second way is better. That means receive from my friend's wallet on different cryptocurrencies and then converting back to BTC later on trade platform. (This is doable because he own amount of money on different cryptocurrency)
Thanks

Yes, it is probably cheaper to have your friend send you an altcoin, but if your end goal is to own BTC, then just have him send you BTC. I say this because:

The exchange you're going to send to will have its own fees (trades/withdrawal fees are common)
Storing coins on an exchange is not a good idea, if that exchange closes or gets hacked, then your coins might be gone forever. So you'll want to remove them from the exchange (which will probably incur fees)
Altcoins can be volatile (even more than bitcoin), what happens if while waiting for them to transfer to the exchange the price in btc drops 30%?

Right now the network is congested, so tx fees are higher than normal. Last week I sent a few transactions for less than a dollar, if you can afford to wait a few days btc fees may drop.


text:
Purpose of token standard interfaces when implement smart contract
I am studying to write smart contract and see that there are some token standards such as ERC20. My question is: what is the purpose of those standards ? Why do we need to add those interface to our code rather than just implement "some" functions that we need.
Thanks

It's a standard.
ALL those ERC20 based tokens have (at least) the same attribute names, the same method names.
So I do automaticly know that I need to call the method "transfer" when I want to transfer my tokens. No one would name it "transfer_tokens_hello_world". Irrelevant which of the thousands of token I want to transfer: It's always the same method.
The advantage for exchanges and/or user interfaces is that it's really easy to implement. If an exchange list token A and B, then token C has the same structure and it's easy to implement it, too.

Thanks. In case exchange tokens, I have 2 points that I don't understand: 1. Who decide transfer rate between 2 different tokens. 2. Why does ERC20 support exchange token ? thanks.


text:
Bitcoin Wallet: Will 2 payments within 10 minutes cause double spending
I'm using a bitcoin wallet for managing all my transactions. For example, If I have bitcoin 2, 3 and 5. Firstly, I buy a product with price 5. Bitcoin wallet will create a transaction from 2 and 3. When my first payment haven't verified yet, I make second payment by a product with same price is 5. This time will bitcoin wallet choose 2 and 3 or bitcoin 5 for my second payment ? I ask this because first payment haven't confirmed yet.

If you have enough Bitcoin in your balance it will be all good. Double-spend transactions should only really be made maliciously by reusing the same inputs. If you are using a known wallet you should not have any issues.

thanks. that means my wallet will choose 5 on second payment right.

Theorically yes but remember there is also a fee to pay and it will be added on top of the payment. It all makes sense after a while, I promise :)


text:
Why so many transaction send bitcoins to the sender?
While browsing the blockchain I noticed that there are a lot of transactions that send bitcoins to the sender (most part of the transaction) and a tiny fraction to another address.
E.g. this transaction sends more than 99% to the sender and the rest to another address.
What is the purpose of those kind of transactions?

@Murch Feel free to mark this question as duplicate, but I think my question is a little bit different than the one you mention since in my case I didn't understand in the first place that an output must be spent completely.

For me the question would rather be whether the answers on the linked topic completely answer your question. I should have written "related" instead of "duplicate". That would have been more accurate. ;)

Sure, I just marked it as duplicate.

An output of a previous transaction can only be spent wholly. So if you have 3BTC and want to send 0.5 to someone, you make a transaction that sends the 0.5 and then 2.5 back to your own address. This is called "change", just like you get change when paying in the supermarket, except in this case you give the change to yourself so you don't need to worry about the other person running of with it.
Note that this change address is supposed to be a brand new address (owned by yourself) and NOT the same address. Address re-use is bad for privacy: as you've just discovered you can in those transactions easily determine which part of the transaction was change and which was actually sent to some other person.

Hi Jannes.  This is a very common question that gets asked a lot, and in such cases, it is better to mark the question as a duplicate rather than post a new answer.  If you have something to add to existing answers of the previous question, post a new answer there rather than here.  That way information is kept in a single accessible place, rather than being spread across dozens of similar questions.

@NateEldredge You're right, I was going to link to other "change" questions, but I was on mobile earlier. It seems good to me to have a short explanation here and then link further for details. Anyone searching for an answer but not knowing the term "change" could find this topic before another.


text:
does Lightning Network can work and solve Bitcoin scalability problem?
from what i managed to understand(if i got it right), the lightning network is supposed to work by using "channels" which can be created by some users with some seller and also be used by anyone who have a channel with someone who have a channel open with the seller so there is a network of users connecting each other to other users so when someone have an open channel with someone he doesn't have to open another channel for every seller that sell stuff in exchange for bitcoin. and basically people pay with the lightning network by using bitcoins from other people's channels?.
anyway i readed this article https://medium.com/@jonaldfyookball/mathematical-proof-that-the-lightning-network-cannot-be-a-decentralized-bitcoin-scaling-solution-1b8147650800
i didn't got too much into the details of the article but it claims that the lightning network is "Completely Unworkable System" and won't help with the bitcoin scalability problem. so who is right? the LN developers or the writers of this article?.

It appears the main claim of the article is that the LN cannot be decentralized, which seems to be an assertion that may or may not be directly related to scalability.

I've responded to Fyookball's article here: https://medium.com/@murchandamus/i-have-just-read-jonald-fyookballs-article-https-medium-com-jonaldfyookball-mathematical-fd112d13737a

as far as predictions into the future can be right or wrong, only future will tell!
When it comes to the author of the article, he is a deep proponent of the idea, that lightning is a bad thing for the future of bitcoin. You can read alot more about his position and corresponding posts on bitcointalk.
There are two things that get repeated over and over again (mostly by proponents of the bcash world): bitcoin cannot scale with lightning, and lightning is centralized ("banking hubs").
The current reality looks a lot different: there are more than 2500 nodes and more than 6000 channels open, and for a beta phase software for micro payments I think this is a huge success. I am convinced it can help to solve bitcoin scaling issues. For sure! It might not solve everything, but there are others activities next to lightning, and that's good. But look, this is only my personal opinion.
Hence I propose to close the question, as it is mostly opinion based, and only time will tell, what becomes true.

Agreed, a better q would be how does LN solve the scalability problem, or even better specific questions about how it works.


text:
Do I spare 80Gb to only keep the blockchain and do I need it to be always present?
I am new to Bitcoin, reading a book and just downloaded a client. On site I read the note that I would need about 65-80gb to keep the whole history of transactions.
What happens when it downloads the whole data set? Do I have to keep it on my hard drive all the time I use Bitcoin? Or can I remove it once it syncs or whatever?
The other question is, does it seem realistic to use Bitcoin on mobile devices as the space needed for the blockchain is so huge for mobiles? What are the alternatives to having this data in the internal storage?

There are different ways of interacting with Bitcoin. If you just want to make an occasional payment, and don't want to handle large sums, you'll probably be happy to run a Thin Client on your smartphone. They rely on full nodes to provide data, but when you wait for a few confirmations are sufficiently secure. To learn more about different types of wallets, you may want to have a look at Choose your Wallet.
If you want to support the network or want to make extensive use of Bitcoin for business, you may be interested in running a full node. If you want to have and be able to serve a complete copy of the blockchain, you'll need to keep all of it, but if you're only interested in working off a fully validated representation of the network's state, you can instead opt to run in pruning mode. Nodes in pruning mode are as secure as other full nodes, but cannot serve all historical data.


text:
Can I safely share my bitcoind instance for separate LND instances of different users?
Currently I have my own full bitcoind node running on a VPS and an LND instance connecting to it and working fine.
However I am thinking, what if I share access to my bitcoind node to some other users willing to connect their own LND instances to it? So, in the end there will be independent LND instances serving for their users but running on top of a single bitcoind instance.
Do I have a risk of exposing data/balances/transactions between these users? Do users have risks of me taking the control over their wallets?

A Lightning node needs a full Bitcoin node to be secure. If the Bitcoin node is operated by someone else, there are some rather trivial attacks that can be used to steal money from you. For example, the Bitcoin node operator might open a channel with you and later close it with an outdated state. Since they control which transactions your Lightning node knows about, it will never learn of the channel close and won't broadcast a penalty transaction (unless you use an external watchtower).
Sharing a bitcoind instance (which presumably doesn't run a wallet) doesn't come with as big of a risk, but Bitcoin Core's RPC interface is not meant to be exposed to the internet since it doesn't scale well for multiple users and can be easily overloaded.

Thanks for the detailed answer, Vojtěch! RIght, I am running a full node. I think I can expose only a limited set of methods to a limited number or users by whitelisting via using a reverse proxy, e.g. nginx and configuring it properly.


text:
How to make sure the user receives lightning payment?
I am working on a side project to allow users to receive some payments from it. When a user clicks a button to withdraw to a lightning address, my webapp makes a request to the host of that lightning address and makes a payment.
I can see the transaction has finished and everything is fine.
But I face situations when people say they didn't receive anything even though the logs show that it should have been received and all settled.
I know it can be some shady users actually receiving funds but claiming they didn't to try to get more from me. On the other hand, it can be that users have some technical issues or lack of experience using lightning and they really didn't receive anything.
So, I cannot say with confidence when it's a case with fraud and when it's really some issues on their side.
Is there a way to protect and to know if users try to cheat on me or if they need help?

I can see the transaction has finished and everything is fine.

Then everything is fine, the user has received the payment. Once the lightning channel is updated the sats have been "moved" and that's that. They are probably looking at the wrong part of their lightning wallet or something (for example, looking and seeing no new BTC transactions on-chain not realizing their lightning channel's distribution of funds has changed).


text:
Smart Contracts on Bitcoin's blockchain
Will projects build on top of Ethereum's blockchain be able to transit to Bitcoin's blockchain when the smart contract platform is up and running?

what do you want to transit?

What smart contract platform? This sounds like it should be posted on Ethereum.stackexchange

I would like to explain a bit the smart contract situation in bitcoin, as a "smart contract platform" is not a fixed wording in bitcoin world.  As such your question is not clear. Bitcoin already has smart contracts. A good summary was provided by Andrew Poelstra here.
When you mention Ethereum, then usually solidity is used, which is "turing complete". People tend to state, that only turing complete machines are "real smart contracts". This is opinion based... Bitcoin has no plans to implement turing complete language, at least not directly. There is the concept of "Bitcoin Simplicity", and it's worthwhile to read the discussion thread in bitcointalk. There is also a link to the Simplicity white paper.
Another development is going into side chains, like this.
A whitepaper for descreet log contracts is presented here.

Will projects build on top of Ethereum's blockchain be able to transit
  to Bitcoin's blockchain when the smart contract platform is up and
  running?

At the current point in time, it is not visible, that people are working on making bitcoin compatible with ethereum smart contracts. It looks more like bitcoin devs are heading in a different direction, to avoid the problems of smart contracts with turing complete machines. When reading through the threads, you'll see how deep the politics are involved on this...

Thanks for your reply and for all the references. On twitter, Diego Gutierrez, founder and CEO of Rootstock, replyed on the exact same question I made here: "The platform is already running, any #Solidity application can be almost seamlessly ported and run with a transactional cost of 3.5 cents USD, we're also working on a bridge so tokens can be moved back and forth between Ethereums and RSK" Reference: https://twitter.com/dieguito/status/967003785653637121


text:
How to protect the early stages of a proof-of-work application?
For a given cryptocurrency or other blockchain application, proof-of-work provides intrinsic security in the algorithm itself that makes it unlikely that someone can attack the network unless they have more than 50% of the computational power of the network under their control.
This makes sense and works once the network has a considerable size, but every network has to start somewhere, and when a new application is born and the number of miners is still very small, it would seem very easy to outpower the network to insert fraudulent transactions and still be the longest chain of blocks.
Is there a way to mitigate this risk?

... insert fraudulent transactions ...

No, fraudulent transactions and blocks containing them are rejected when nodes follow the consensus rules.
There is a greater risk of chain reorganisation, meaning miners who successfully mined a block may not eventually have the reward for that when their block is no longer part of the longest chain.
The great risk of a 51% attack is that the attacker could outpace the rest of the network to assert that the attacker's version of the blockchain is longer, re-writing history with valid transactions and claiming block rewards, or undoing their own transactions when re-writing history by spending the utxo's back to themselves first, making their previously valid transaction seem like a double spend, for example, and stealing from a merchant.
To protect a new proof-of-work application it is only necessary that the work is reasonably distributed. For example, in the case of a Bitcoin full clone the same ASIC miners would be valid, however, the cost-for-benefit would be very low initially and so an attacker must ask, what benefit do I derive?

I don't think there is a risk of this happening because there would be very little incentive for someone to insert fraudulent transactions. Bitcoin has achieved success and is a significant store of value so there is huge incentive to launch 51% attacks against it but because of the size of the network and the amount of honest miners it has not happened yet. So, in my view until a cryptocurrency achieves a significant value or use it has no risk of fraudulent activities and by the time it reaches a value that makes it worthwhile to hack then the network is too large to launch attacks against it.

Use SHA256 : Force the attacker to think whether its worth their time loosing bitcoin in attacking you
Publicize : You need as many people to mine since the start as possible
Ponder why you are asking this question : If the product you built is truly decentralized(and not for your profit) and has utility, don't worry about it dying. The code cannot die. Give it a few years and somebody will reboot it and will do what it was meant to do, out there in the world.

Yes, you are absolutely right. This can happen! Which is why it's very important to use a proof of work algorithm that is centralization resistant. In other words ASIC/mining-whale attack resistant. In other words come up with a novel proof of work which can only be mined on CPU's (single entities not entire pools) or GPU's. This is not an easy thing to do and one of the coins which has done this very well is Biblepay.
There are of course other ways to do this like adjusting the difficulty and other features but nothing as good as a great POW algorithm

Yours is a valid question, even though you can't include fraudolent transactions in a environment where the witness nodes are honest.
Early attacks on blockchains are a thing and already happened (CoiledCoin for example), and the biggest threat in such attacks is that attackers willingfully lose their money in order to sabotage the newly created currency.
Risk mitigation depends on how much the system is decentralized, adjusting the difficulty so that the attacker wastes lot of resources on computing the PoW (thus this would be giving up system availability for a while). One can even think to ask other mining pools for cooperation to keep the hashing power uniformely distributed during the early stages of a new cryptocurrency.


text:
LSAT - stateless proof of payment through specific form of preimage
I am aware LSAT consists of macaroon and preimage. Preimage is part of the HTLC construction to route payments in lightning. It is generated by the receiver and eventually known by all participants on the path (if all goes well). And point of a macaroon is that anybody having one can add caveats w/o asking for permission and give out a more restricted version.
Macaroon itself is quite stateless as far as I get it (it can encode everything a client is able to do from the server perspective). But preimage doesn't seem so. How does that usually work then - you have some cache of paid invoices or need to ask LND - can you even query based on preimage to determine whether a specific LSAT is valid or not?
My idea is to use a deterministic preimage so a web server could instantly know whether a token is valid.
It would be in the form
timestamp, HMAC(timestamp, secret)

where secret is the same thing used to verify macaroons. So web server and LND would share this, but wouldn't need any further communication after initial invoice generation.
Or actually since somebody can just take preimage and attach it to some other LSAT, you could do:
timestamp, HMAC(H(timestamp + serialized macaroon w/o additional caveats), secret)

The obvious drawback is that you lose some bytes of entropy for the preimage, but that should just be a few bytes. To somebody just looking at payment hash it looks indistinguishable. And if secret is compromised you can forge invalid macaroons anyway. Is there any other problem with such a scheme? Or is there some easier solution?


text:
Lightning Wallet (lnd) - Export Private/Public Keys?
Is it possible to export keys from a Lightning Wallet, specifically lnd? I started opening my first channels, and most of what I'm reading says that you want to monitor your wallet balance (in the absence of watchtowers, which aren't implemented yet). I was looking to get the public key for my Lightning wallet so I can have a watching-only copy. I suppose I can do that by just having the address with some wallets, but it would also be nice to have the raw private keys for backup.
I know how to get the keys out of a normal bitcoin wallet, but not sure how to do that with lnd, since they're stored in wallet.db.

I think is not possible. They are still working on it.
https://github.com/lightningnetwork/lnd/issues/732

It looks like it's not possible with just lnd, but seems possible with chantools?


text:
Is there an open database to query bitcoin transactions
My goal is to get all addresses with a balance of more than 0.01 BTC. In order to get this data, I have to sync the full bitcoin node but I want to avoid it. Maybe there is any open SQL or MongoDB database somewhere. The speed is important.
Thanks in advance

https://blockchair.com/bitcoin/addresses?q=balance(1000000..)&s=balance(asc)# ?

Google Cloud provides a dataset for most public blockchains, including bitcoin. You can directly query the dataset via their BigQuery Tool - you can use standard SQL
Bitcoin Dataset on GCP:
https://console.cloud.google.com/marketplace/product/bitcoin/crypto-bitcoin?filter=solution-type:dataset&id=7fd60425-cb95-4a58-b59f-ab3789642844


text:
Which wallet provide lock-time feature?
I try to understand how the lock-time and sequence number work, but I got many different explanations, it is really confusing. I like to send a Bitcoin with lock-time to myself, but I don't know how to send contain a lock-time? I use Bitcoin-core right now.
or someone has an example transaction on blockchain.info, I want to see a transaction with lock-time and sequence number, but not 0xffffff。
thanks.


text:
Average payout of mined bucket?
What is the average payout of mined btc from blockchain to blockchain wallets?

Can you elaborate more on what you're asking? Average payout per what?

The block reward for successfully mining a block is currently 12.5 BTC.
By participating in a mining pool the group has a significantly higher chance as a whole of solving a block. Rewards are then shared based on a formula. It can be suggested, though it is not always the only factor in the formula for a mining pool, that your individual hash rate as a share of the pool total hash rate determines your share percentage.


text:
Bitcoin core dump private key gives a wrong key which corresponds to a different bitcoin address
According to  this and this stackexchange answer and so many other resources, I can get my wallet's private key by using the dumpprivkey command on the debug console of Bitcoin Core (Qt) and import it into another wallet like Electrum or blockchain.info or many other wallets.
So I follow the instructions to export the private key for one of my bitcoin addresses found on 'receiving addresses' of Bitcoin Core desktop application. The private key is dumped successfully, then I create a wallet on Electrum using this private key. The wallet is created successfully. The problem is it shows my balance as 0, and also in addresses tab, my bitcoin address is totally different from what I had in Bitcoin Core.
I also tried creating the wallet using the public address (watch-only address) which shows the balance correctly but as the name suggests, I cannot spend it because the wallet is created using only the public key.
I dug a little deeper and tried to create the wallet using uncompressed private key format (I used bitaddress to get the uncompressed key) but the result was exactly the same with the exact same bitcoin address which is different from my original bitcoin address.
I also tried all the steps for blockchain.info wallet, but no luck, the result was the same again.
I'm really depressed and beginning to think that I've messed up somehow and cannot transfer my bitcoins from this wallet and may try to move on and forget about it. So my question is, have I done something wrong or I should download all the transactions on my laptop to be able to transfer BTC?
One thing that I forgot to mention is that I could not download all the transactions on Bitcoin Core client because of free space limitation on my ssd. So I cannot transfer any BTC using this application.

Were you using a segwit address in Bitcoin core?

@RaghavSood I'm sorry I don't know what segwit address is. I just added a new address in 'receiving addresses' window of Bitcoin Core.

What is the first letter of your address in Bitcoin Core?

it starts with '3'. private key starts with 'K'.

That's a p2sh-wrapped segwit address, in that case. If you want to import it into Electrum, you can see this answer

Yes thanks, I should just prepend 'p2wpkh-p2sh:' to my address and works like a charm! I did a lot of search and read tons of Q&As and finally find out that it was this easy! Thank you so much.
thank you very much.


text:
How transaction manipulation handles in Blockchain?
I'm new to Blockchain and would like to understand few concepts in a detail.
After reading about basics of Blockchain, one thing is unclear to me about tx. manipulation.
For instance, A has some (i.e: $10) money and A is sending half($5) of it to B.
but C manipulate that transaction before going to Blockchain and set $10 instead.
Now, A wanted to send only $5, but some how A's account will get empty since miner will check A has enough balance or not.
How Blokchain resolves this type of scenario?

For instance, A has some (i.e: $10) money and A is sending half($5) of it to B. but C manipulate that transaction before going to Blockchain and set $10 instead.

This is not possible, provided the original transaction is signed correctly. In a regular transaction, you sign the inputs and the outputs. If someone changes the input or output amount, the signature is invalid, and the transaction will not be mined.


text:
Can I confirm a transaction myself as a node?
I see notes that when I make a transaction, I can set the fee myself. But, if I set it too low, then the miners may decide not to take it because the fee is too low.
Can I make confirmation myself as a node or does it mean I will have to run a powerful machine and mine cryptocurrency in order to be able to select and confirm my own transactions?
Is it feasible to run my own node and process those transactions that I do myself?

Possible duplicate of https://bitcoin.stackexchange.com/q/146/5406

Transactions are confirmed when miners include them in a block, which is then subsequently mined (by finding the right nonce - which is computationally hard). As you mentioned, they like to receive a fee for their services.
To answer your question: Unless you are able to mine the next block (e.g., by employing strong mining hardware), you can only broadcast and validate transactions. So while you may be able to create your own transactions, you ultimately rely on miners including them in blocks they mine.

By running a node, you verify that your transactions are actually valid and will be accepted by the network. However, to add it to a block, and hence the blockchain, you must solve the PoW challenge, as the difficulty is so high, you'll need some powerful machines and tons of electricity.


text:
What cryptocurrency is most suitable to send small amounts?
I'd like to build a service to allow users to send small amounts, e.g. equal to $0.5-$1 per transaction without having to pay enormous (in relation to the amount sent) fees.
I read that technically bitcoin allows to send 0.00001 BTC a a minimum amount and it's $0.44 currently. But the commission will be larger than the amount sent to it doesn't make sense.
So, are there other cryptocurrencies where I can send such small amounts and pay something that is more reasonable?

You may use Lightning Network, a Bitcoin Layer 2 solution for micropayments. It's instant, cheap, and reliable.

Other chains might be off topic here, but Bitcoin offers you at least two options. You can choose one from three, the first two are Bitcoin:

Enhance your calm. Using minimum fees it'll take longer, but it might cost as few as ten cents.

Use the Lightning Network or some other second layer system or side chain.

Use an alternative cheaper chain.

With lightning you can send 1 sat (or even less) and there is almost no fee.

Indeed, I don't see why anyone would look for "another cryptocurrency" when the Lightning Network just works. Can send down to millisat (1/1000 of a sat) with very low fees. Depending on who you are sending to, if for example you make frequent payments to one node, you can just open a channel to that node.

Basically, for all coins, if you use the native wallet (full node wallet) the fees will be as you want.
Just take a coin that you like, install the desktop full node wallet and see how small the fee is.


text:
Is a lightning wallet registered in bitcoin blockchain?
Say, I create a wallet with an lnd create command. As everything is initially on Bitcoin blockchain, will the wallet address/metadata be written into blockchain?
So, can I find the address of my Lightning wallet in Bitcoin blockchain and send BTC in an old-fashioned way?

Opening a channel with another party involves creating a 2-of-2 multisig address and sending funds there.  This is an an address where funds are controlled by both your lightning node and the other party according to the rules of the script with fallbacks that allow you to always receive back as much as you put in.

can I find the address of my Lightning wallet in Bitcoin blockchain and send BTC in an old-fashioned way?

If I am understanding correctly, you would like to send an on-chain payment directly to the generated multisig address to add funds to your channel balance?
Sorry, that won't work as expected for a number of reasons... It sounds like you are looking for a Submarine Swaps which are trustless / atomic.
Edit: I see you are using lnd, so you can use Loop In for this purpose.


text:
Can I connect my LND to someone else's bitcoin node?
Now I am running my own Bitcoin full node on my local machine and connect to it with LND.
I see some open bitcoin nodes on https://bitnodes.io and wonder if it's ok to connect my LND not to my own node but to someone else's one? Is this possible, performant and worth it or should I run my own node?

LND connects to Bitcoin Core's JSON-RPC interface, it doesn't use the peer-to-peer protocol. Thus, publicly reachable Bitcoin nodes will be useless unless they also expose the RPC interface, which they should not do anyway because it's not safe.
In any case, you should run your own node. Relying on someone else's node exposes you to attacks.