text:
Is there an Electrum based USB Distro?
I would like to use a USB with a Linux distro, ideally with Electrum. The advantage of this is that the USB does not need to contain any information, just entering the seed would be enough, which provides extra security in my opinion.
Is there a distribution which does this? or there an instruction on how to do this?

I have considered building a electrum usb-distro but the problem is it would be hard to keep it updated after each new release. However if there is enough interest I might do so.
Your best bet is to simply take a debian live-usb and install Electrum on it; you can follow the instructions for linux on the electrum site.
If you have any specific Electrum questions you are always welcome to join #electrum on freenode and ask your questions there.

thanks, I think this could possibly be even better, because you know the image is secure. However, I can't install it. Question about that (on Ubuntu) here

on second thought, this is pretty irrelevant if you are always offline.

also, because of the offline nature, I don't think each new release would have to lead to a new build. Updating the online (transaction) version would probably be enough, right?

One thing to consider is that a newer version of Electrum is coming out with BIP 0032 wallets, these will have different keys for the same seed. To maintain the 'online' de-seeded wallet, you will need one capable of keeping Electrum-based keys around... or you will have to migrate all your offline coins to a newer wallet. Here are the scenarios to consider:

Keep old offline wallet

need to keep older version on PC for transaction generation

get to keep older one in USB

Update wallet

need to update usb wallet at least once

no need to keep old online wallet

Regarding a USB distro - I have tried Electrum on tails with some success: https://tails.boum.org/forum/Report:_the_electrum_bitcoin_client_in_tails/
The hardest thing is getting the proxy connection working to the onion address there, though.

@harningt, thanks for mentioning the seed issue (where can I read up on this?). I guess this would be cause for updating a possible distribution, but other than that, not too often right?

@harningt, regarding your second post, I would prefer to keep offline, and submitting transactions using export/import

okay there is a iso available here: https://blog.non.co.il/index.php/bitbuntu-livecd

After writing this message, I realize this thread is about a USB based distribution.
Yet I'm posting about a CD based solution in case it serves the ones who are still searching and deciding...
Here's how I did my setup to be able to exchange bitcoin and litecoin.
I don't want to use two computers for separate offline-and-watchOnly clients.
After searching and reading, I decided to use:

Electrum and Electrum-LTC from a CD-booted operative system,
rigorously offline (I unplug the ethernet cable from the PC so I
still have wifi for my phone), with a portable wallet on a pendrive
and a watch-only Electrum client in Windows (this can be
fully portable so I plug the pendrive just when I need to use the client
and nothing strictly related stays permanently on the PC which is often online)

HOW?
I grabbed the latest Electrum (1.9.8) and Electrum-LTC (1.9.8.6) clients from electrum.org (the Linux versions come with executable binaries, too) and I added them to the current slax distribution (with the necessary modules but not the electrum one, and the startup command launches from inside the electrum folder) and made a bootable CD of it (although it works offline, it's good to know that it cannot be modified like a pendrive-resident environment).
IS THAT SAFE?
As long as the offline part stays offline and as long as slax and Electrum do not contain malicious software which might store my seed phrase somewhere in my hardware, that's pretty safe... apart of course the Electrum servers considerations etc. etc. etc..
If I come to get very rich (but I doubt LOL), I'll start using the Tor network (I already have the connection setup in Windows). (*****)
I saw that another slax based solution was out, I had tried BTCVault, but

the Electrum client is a little old
because of that, I didn't spend more than a couple of hours on it but
I couldn't have Electrum create a new wallet on the pendrive (and in
volatile storage either) through the GUI and the right-mouse-button
contextual menu item "create new wallet here", sure I'm missing
something; I could have it create a new Multibit wallet but that's
not my choice for now.

I have tried two more live CDs, Tails 1.2.2 and Ubuntu 14.10, but the boot time is much greater than with slax, and anyway I need the online watch-only part to run on Windows, and in the offline part of the process I wouldn't use the extra features that Tails and Ubuntu might (or not) offer over slax.
(*****) The only advantage of Tails which is evident to me even for offline use: Tails wipes the memory before shutting down... I don't know how much time I should wait after shutting down slax, before switching on the PC again, no idea.
I hope this helps some other crypto currencies newbies!
With the first "crypto-bucks" I will hopefully earn (I'm offering online lessons, trumpet, rhythm, musical theory :D ), I think I shall have to donate to the Electrum and slax developers, and I promise I'll try to avoid dust transactions and will not be stingy with tx fees.

You can make the standard client portable if you use the "-datadir" flag.
Assuming that the application "bitcoin" is accessible from your working directory and that you want to store information in a directory named "data", the script you want looks like this:

#!/bin/sh
bitcoin -datadir=./data

Source: https://bitcointalk.org/?topic=809.0;wap2

thanks, I am mostly interested in Electrum because of the ability to restore wallets from seeds, and because it does not download the blockchain

BTCVault (http://dswd.github.io/btcvault/). The client is a little old but the concept works great.

I realize this is an old thread.  Since it is showing in google search, it might be worth to reply still.
Check out EROAS.

EROAS stands for "Electrum Running On A Stick". It runs Electrum wallet, the best open source bitcoin wallet, on cheap USB drives, with cold-wallet level security and warm-wallet like convenience. It is meant to operate like a saving account for infrequent transactions (perhaps <1 transaction per day). Its strong security level makes it suitable to protect assets over millions of dollars.

Check out BitKey.
It is a pre-bundled collection of software allowing you to perform bitcoin mutations in an air-gapped environment by running it of a USB key or other removable media. Electrum is currently part of their package.

Thank you very much, I've checked Bitkey, it's very interesting and very promising, however: - It didn't recognize an USB storage device which works fine with slax (it is a 32 GB SD card in a card reader, I didn't try with these two pendrives because I have them ready for the offline and onlineWatchOnly parts of the solution I mentioned in my previous post). Also, the boot time is a bit longer than with slax. (cont.)

Bitkey aims at working online too (it's fine that they warn about the security level which would be "medium" instead of high), but I read in a forum that Debian and derivatives are plagued with backdoors by NSA guys... they mentioned Arch Linux as a safer base. Although I doubt the NSA would steal my earnings, I don't know if those backdoors can be exploited by somebody else.
Besides, now, as mentioned, I need the onlineWatchOnly part to run on Windows, but of course a solution able to boot and face an online and potentially dangerous situation too would be interesting in another scenario.


text:
added security/safety to multiple blockchain.info wallets
If I want to store a substantial number of Bitcoins, would there be any add security or safety to doing this in multiple blockchain.info hybrid ewallets, in stead of all in one?

For large numbers of coins, software wallets (online or desktop), no matter how well designed, are not safe. Online clients aren't safe because the ones that are encrypted your side (like blockchain) might somewhat be susceptible to man-in-the-middle attacks. As Lohoris mentioned, Blockchain uses js verification with Github, requiring both websites to be compromised - of which there is a slim chance. Standard desktop clients are inherently not safe either, not when you're storing thousands of $/£ in coins. Even with all the safeguards in place, the absolute safest storage method is to keep the keys offline.
You would be much better off generating a large number of keys using an offline computer and storing them on encrypted flash drives in safe locations. This is what the biggest known BTC hoarders (Winklevoss) do.
You can then add the addresses without the keys to Blockchain for easy monitoring and zero risk.

Totally a FUD. Online wallets aren't safer than standard clients, they only have different security concerns.

I didn't recommend a standard client. I recommended generating keys that never touch the network - this IS safer. Every single bit of advice for large volumes of coins states that they are best kept offline where they cannot be accessed without the physical pen drive or bit of paper (depending on method). No FUD, just good practice.

"online wallets, no matter how well designed, are not safe" this is misleading, then. A reword could make this post much better.

I qualified my statement in a previous edit. They aren't safe because even the really good ones with browser side encryption (Blockchain.info et al) are subject to man-in-the-middle attacks. For someone storing a substantial value in Bitcoins (as per the question), this would present an unacceptable security risk. Edit: I see how it could be edited to say that any "wallet software" online or desktop, is unsafe. I will reword to this effect.

Good edit. I've modified it just a bit since they aren't really always susceptible to MITM attacks, since blockchain.info for instance has a JS verifier against github, hence you'd need to crack both blockchain.info and github to make the attack work.

I didn't know that. Thanks for your help with clarification :)

Revised to include @Lohoris info on MITM attacks.

source: Stack Exchange

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

sort: votes


text:
Paying for testnet coins?
If testnet coins are this difficult to get, what's the chance people start throwing in some real money to speed along the process?
If only to just have to not wait to test, say if you have an important time sensitive simulation you want to run?

I don't think people should pay for testnet coins. I was able to finally mine 50 btc. I'll send you enough to get started if you send me your address.

I don't think they should either, it could happen though, as an unexpected side effect of the whole bitcoin ecosystem.

This question needs rewording; the primary question seems to be "What are the chances..." which could simply be interpreted as a request for funds (this isn't the best place for that kind of request).

I think I should make some testnet wallet and faucet to help people with their testnet Bitcoin needs...

There's always testnet-in-a-box if you really need coins to run something.

@ThePiachu Last I checked Testnet faucet was down/empty or not working

@makerofthings7 That's why I should make my own... with blackjack... and hookers! ;)

Sent a few hundred to tpfaucet, great idea!

I have recently created a TestNet Faucet. It is available on
http://tpfaucet.appspot.com/
I hope this remedies the situation
To answer your question - while there is nothing stopping people from charging for TestNet coins, I think they should be freely available to anyone for testing. It lets newcomers get a feel for what Bitcoin is without risking their money. I hope that a few Bitcoin developers (or even the Bitcoin Foundation) will provide TestNet Bitcoins for free as long as the Bitcoin project is used.

The server seems to be down!

You can always try to hit up a developer on #bitcoin-dev IRC channel (Freenode).
Also, there is now a faucet:

http://tpfaucet.appspot.com

As an alternative to the great tpfaucet, we also give away free testnet coins at
http://testnet.mojocoin.com
We should help out our fellow developers with testnet bitcoins. There's no need to pay for them.

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:
Why would a miner mine with a difficulty other than 'the' difficulty?
Why would a miner mine with a difficulty other than the network difficulty? Both of these questions describe miners mining in such a way. What's the benefit of this? What even does it mean?

To understand this we should first explain that a block with a high difficulty, let's say D, is also a share of low difficulty d < D, therefore if we find such a block for difficulty D we automatically have a block of difficulty d. This also means that if I as a miner am looking for a share with difficulty d I might by chance find a block of difficulty D (with the probability d/D). This is exactly the reason why mining pools exist: they assign the miners the task to find blocks of difficulty d in the hope that they will eventually find one for D, i.e., the real network difficulty, which pays for the whole pool operation.
Commonly these blocks at a lower difficulty are called a share, and are used to gauge the hashing rate of the individual miner, giving the pool a way to determine who has what probability of finding the next block and distributing the reward accordingly.

Network and share difficulty are commonly referred to as D and d, I recommend editing to be consistent.

Blocks which only satisfy the requirement for a lower difficulty than the real network difficulty are called "shares". They are found naturally in the process of looking for valid blocks, and there is no way to find shares without doing the work needed to find blocks.
Thus, shares prove that work has been done by the miner. Pools use these shares to determine how much to reward each miner.

If a miner solves a block that does not satisfy the real network difficulty then he hasn't solved a block, correct? Wouldn't the miner and the pool be better off spending all its effort trying to find a truly valid block rather than trying to prove to the pool that its been working?

@KinnardHockenhull: It's exactly the same work. The miner is trying to find a valid block; he finds shares along the way, and these prove that it has been working.

@KinnardHockenhull: Besides, miners won't do any work at all if they're not rewarded for it, and the pool will not reward them if it doesn't know that they have indeed been working.

So is a share an invalid block?

@kuchi: Some shares are valid blocks (that's the idea, whenever a miner finds a share there's a chance it will be a block, so is rewarded for it). Some invalid blocks are invalid because they contain something illegal unrelated to the difficulty, and are not shares. But yes, most shares are like blocks, except that they are not valid because the hash is not below the target (but it is below the max target, and in some deployments even below an even lower target).

Sorry if my question is becoming out of the topic here. I just want to understand how it works since most of articles I find is too technical for me. So who sets the max target is it the pool? what does "and in some deployments even below an even lower target"

@kuchi: Max Target is a constant of the Bitcoin protocol, equal to (2^16 - 1) * 2^208. Difficulty is the ratio between Max Target and Target. Originally pools used shares with a target equal to the max target, that is, difficulty 1. As mining hardware became stronger, pools started using more difficult shares, with a target lower than max target. The pool chooses which target to accept; if it wants, it can allow the users to choose their own target. The value of each share is always scaled proportionally to the difficulty.


text:
How are fractions of bitcoin implemented and spent?
If the ability to spend bitcoins and therefore bitcoins depend on/correspond to private keys, how can fractions of coins exist? Can the key be split up? How are fractional transactions signed versus integer transactions? I am not asking what the subdivisions of bitcoin are or how it can be further subdivided.

The analogy of "coins" as individual objects that can be handled is misleading. The atomic unit in Bitcoin is a satoshi, but satoshis are not handled individually, rather in each transaction it is specified how many satoshis (as an integer variable) move from where to where. The total number of satoshis in the input must be at least as great as in the output, and all the inputs must be digitally signed by the owners.
The private key is what allows you to prove ownership of given outputs. The way it is used for signatures doesn't really depend on how many different outputs you have and what is the value of each.
There isn't even a meaningful concept of "a bitcoin" in the software, a bitcoin is just shorthand for 100,000,000 satoshis.

Bitcoin doesn't use the concept of "balances" it uses transactions.  A transaction consists of inputs and outputs.
The transaction amount is the total of all inputs.  Each input in a transaction is spent in its entirety during the transaction.   And the outputs can total any amount up to the total transaction amount.  Any amount remaining (inputs - outputs) goes to the miner as a fee.
So a transaction might look like:
INPUTS:
25 BTC
50 BTC

OUTPUTS
40.2 BTC
34.7 BTC

So the 75 BTC total inputs, less 74.9 BTC total outputs means 0.1 BTC goes to the miner.
Now, at the protocol level, the 25 BTC amount is really 2,500,000,000 because each 1 BTC is actually 100,000,000 Satoshis.
So the 34.7 BTC output was really the number 3,470,000,000.
So there are no fractions.  These are all integers.
When the client displays these numbers, it shows them in whatever units the client is configured to use (BTC, mBTC, uBTC).

The private keys you mention is nothing but "permission" to make changes to the P2P General Ledger known as the bitcoin network.  A "Bitcoin" really doesn't exist, rather a Bitcoin is just an entry in the GL, with a deposit into your "public key" (aka account).
When money is added to your account, someone else (the spender) signs the transaction and dedicates the funds to your public key.  When they do this, they use their private key to create a "spend entry" and assign a number (or fraction thereof) to you.
So think of the key as "permission to spend the account, or subtract any decimal value up to eight (0.00000000 BTC) decimal places".  If you lose this private key, you lose the ability to spend the money and it's lost forever.  If someone hacks your computer, or steals your key, they have permission to spend your coins.


text:
How to get best hashing results AntMiner S4
Does anyone have any helpful tips on getting the best hash rate out of my miner?
My miner works fine, it just that I'm getting a crummy 1.65 to 1.89 TH/s rate.


text:
Mining Pool Hub: how to understand if it is mining?
I have just set up Mining Pool Hub, how can I understand if it is actually mining bitcoins (or other crypto-currencies)?
Because sometimes I see yellow alerts
PoolApi  AHashPool has failed
PoolApi NiceHash has failed
Also sometimes it appears "Status: Failed"
Could you explain, for beginner users, how to understand if the software is mining or not? And better, how to understand if the software it's mining at its best?
Right now this is what I see:

From your screenshot, I can see that you are using MultiPoolMiner. When you took the screenshot, MPM was busy running a few benchmarks in order to determine what algorithm is the best to mine with your hardware.
The Nicehash API probably failed due to the hack that they had in December 2017.
The software does not mine Bitcoin. It mines other currencies such as Ethereum, ZCash, Monero and a few others. In Mining Pool Hub, you have the option to setup auto exchange to a specific coin. Just log into MPH and look for "Auto Exchange" on the left hand side menu.
The simplest way to determine if the software is mining, is to have a look for another console window, and then scroll through that window to see if shares were submitted. You can also have a look in MPH at the "Balances" section in the left hand menu to see if you are getting balances in. For a more granular view, you can click on the currency in the balances view, that will take you to the currency pool, where you can view a dashboard with info.
How to understand if the software is mining at its best - it really comes down to how often you cash in and if you have the auto switch on. As the currencies fluctuate, you might get a less favorable exchange rate, so although you mined a coin that was most profitable a while ago, it might not be the case anymore. The best is to do your own research, and to monitor your miner. There are a few websites that can help you with crypto currency related info:
https://whattomine.com/
https://coinmarketcap.com/
You can also check on the Mining Pool Hub home page what currencies are more profitable.


text:
Does calculating how many bitcoins I have take longer as time goes on?
I have read that the blockchain is a series of transactions that record one person giving bitcoin to another.  Please correct me if this assumption is wrong as it is the basis for my question.  So, over time, doesn't it take an increasingly long time to figure out if you can accept Bitcoin from someone because you will have to go through every transaction in the history of the blockchain to validate that the person giving you Bitcoin does indeed have that Bitcoin in the first place?

Sure, or even what's the incremental difference from one year to the next.

With a naive implementation, yes, but in practice, no, it is not a problem.
This is because any developer that knows what they are doing is smart enough to create a database which, at the very least, records each transaction (or its position on disk) and its verification status. So when you receive a new transaction, instead of having to walk back through history, you just need to look back to the referenced previous transaction. As part of validating a transaction, you check if the previous transaction was valid. So if a transaction is marked as valid in your database, then you can be sure that the transactions that preceded it  are also valid. Thus there is no need to actually look through history and re-validate those transactions.
Since it ultimately just comes down to a simple database lookup, it does not become harder to validate new transactions.

The calculation time will degenerate very slowly the longer time goes on as the mechanisms used are very efficient. Consider a simplified payment verification node (SPV) that is interested in incoming payments to an address in its wallet. The SPV node will establish a bloom filter on its connections to peers to limit the transactions received to only those containing addresses of interest. When a peer sees a transaction that matches the bloom filter, it will send the block using a merkleblock message. The merkleblock message contains the block header as well as a merkle path that links the transaction of interest to the merkle root in the block. The SPV node can use this merkle path to connect the transaction in the block and verify that the transaction is included in the block. The SPV node also uses the block header to link the block to the rest of the blockchain. The combination of these two links, between the transaction and block and between the block and the blockchain, proves that the transaction is recorded in the blockchain. All in all the SPV node will have received less than a kilobyte of data for the block header and merkle path which is very efficient and the calculation time will degenerate very slowly as more blocks are added.

If I'm reading you right, you're sayihng you can only look at certain transactions to figure out how much Bitcoin is in a wallet.  But I don't see how this can be true.  For each transaction giving to the wallet, for example, don't you ahve to verify that those people have the necessary funds in their wallet, which would cause a scan of all those wallets and so on?  So aren't you essentially scanning all transactions in the blockchain every time?

The fundamental building block of a bitcoin transaction is a transaction output.  Transaction outputs are indivisible chunks of bitcoin currency, recorded on the blockchain and recognised as valid by the entire network. Bitcoin full nodes track all available and spendable outputs known as unspent transactions or UTXO. When a users wallet receives bitcoin it means that the wallet has detected UTXO that can be spent with one of the keys controlled by the wallet.

A users bitcoin balance is the sum of all UTXO that a users wallet can spend which may be scattered amongst hundreds of transactions and blocks. The transaction output consists of the amount in Satoshis and a cryptographic puzzle that determines the conditions required to spend the output. This puzzle is also known as a locking script. This means that all the conditions required to prove ownership are contained in the transaction script and the wallet does not have to scan the blockchain to check if the person that sent the bitcoin actually has the  funds.


text:
Got 64: non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) when submitting segwit transaction
I got the above error when submitting this transaction:
010000000001013894a4bdcfa20ef5a6cbfe1d22c5fe5041eab586a5ea2b044f969a02dab6b3d200000000171600141a982a7d2712fc33d47c990cd8cde15c87ca2e07ffffffff015e3f01000000000017a914fb2dc3b4dd0731c8f2559506c7d0cb876b0e71298702483045022100c68dac735a3529d84fdbfc3a8a11d313d59a9791b046fc39bbfc55db71d6d2010220028f2bbfba78c393858e3cb7ad51e24e8dfd2260d4a3cbbf8feb4d4c6005967701210371b63ebaa78a70420bc36159bed610b8f788e9a7b953558f06bb40622d9cbfe400000000

A previous transaction from the same P2SH-P2WPKH address was successfully spent but I got this error whenever I try to spend this transaction:
d2b3b6da029a964f042beaa586b5ea4150fec5221dfecba6f50ea2cfbda49438

I already attempted to sign the transaction again a few time but still got the same error.

How did you create this transaction? What commands did you use? What software?

I used the ruby gem to build and sign this transaction

I found out it was because of a precision error in our code. The amount that used to build the input segwit transaction is incorrect leading to this error.

Please write an answer to your own question if you found a solution.

You will receive this error if the value you are signing is not the exact amount of the entire unspent output value.
For example, if your unspent output value is 35,000, and you only want to send 30,000, your output value would be 30,000, and your signing amount would be 35,000. If you sign for only 30,000 (not the full amount of the unspent output) you will receive this error.
Visual Example Using BitcoinJS:
//add input
txb.addInput(txid, outn, null, scriptPubkey);

//add output
txb.addOutput(receivingAddress, 30000); //amount less the mining fee

//signing
txb.sign(0, keypair, null, null, 35000); //NOTE the amount is the FULL amount of the unspent output, NOT the amount being sent

I've faced the same error and it is very confusing. I'm sure that in my case sign gets exact full amount of input, because I walk through UTXOs and pass utxo[i].satoshis as amount. Can anything else cause this error?

I'm using bgoldjs-lib - fork of bitcoinjs-lib for BTG

I have gotten this error not only when specifying an incorrect input amount, as mentioned elsewhere in this thread, but also when sorting signatures incorrectly on a multisig transaction.

When I try to submit that transaction I don't get that error message. To me it looks like you are only sending 1 satoshi as transaction fee in total. Try to send it with a higher fee.

I found out it was because of a precision error in our code. The amount that used to build the input segwit transaction is incorrect leading to this error.

I got the same error when create transaction via bgoldjs-lib. Say that it's confusing like say nothing. I'd no problem with bitcore-lib, bitcoincashjs to create BTC, BCH, LTC txs. Think it's open source !^_^! or I've not so deep learning in this area. I found one solution https://github.com/Ayms/bitcoin-transactions. There're tx.js script, but in min.js format. It's created success broadcasted txs for me. There're one unsuitable output that i'm going to remove in a near time.


text:
Paper wallet imported to blockchain.info with private keys
Recently I added my paper wallet address and private key to my blockchain.info account. Now I cannot find an option in the app or in the website to delete the imported private key, does that mean that blockchain.info now holds my private key? In that case, I won't be able to add my wallet into another similar app because it's already synced with blockchain.info with my private keys! I am new to this whole bitcoin thing so I am still trying to figure things out.
Regards,
Bince

No point of asking for deletion. Consider it compromised and move your funds to a new wallet.

The private key is a 256-bit integer used to generate a public key. A bitcoin wallet address is a hashed version of your public key.
The private key allows you to sign transactions (send BTC to another address).
With the private key of a given address you can sign any transaction, anywhere.
That means that if you have that private key, you can use it in any wallet. Although blockchain.info stores your private key now, you still have it, so you can import it on any other wallet.

does that mean that blockchain.info now holds my private key?

Yes, but not exclusively. You still have your private key on paper, so you still hold it. If you don't (i.e. you lost your paper wallet or destroyed it), you can still get your private key from blockchain.info.

In that case, I won't be able to add my wallet into another similar app because it's already synced with blockchain.info with my private keys!

No, that is not how Bitcoin works. Anyone who holds the private key can spend your Bitcoin. You also hold it on your paper wallet, so you can still import it into another wallet software. There is nothing that prevents you from doing that; it's not like something that can only be imported once.
If you don't want blockchain.info to have your private key, just make a new paper wallet and send your Bitcoin there from blockchain.info. If you want to access your Bitcoin from a different wallet than blockchain.info, then just import your private key into a different wallet.

The safest possible thing you could do is to send the money from your blockchain.info wallet to your local wallet in a normal Bitcoin transaction.  This might be a few bucks, but it is worth the peace of mind.
You could delete your blockchain.info account and then open another one if you like, but this is no guarantee that they will delete your private key.  I advise sending an email to Blockchain.info asking what their policy is on keeping and removing private keys.
In general, it is best not to import private keys from wallets that you do not have full control over.  You don't know what they are going to do with your private keys and the sure fire way to safeguard your money is to just send it to a wallet you have FULL CONTROL OVER using a normal Bitcoin transaction.


text:
How to create your own bitcoin mining software?
Can we create mining software, if yes, how?

Yes, it is possible

Take an editor (notepad.exe is good one)
Write a program
Compile and test it
Thats all. Profit!

Yes of course.
If you are looking for a place to start, look at the mining related functions of the Bitcoin RPC (bitcoin-cli help) for the input data you will need for any mining application.


text:
0/unconfirmed and now no transactions anymore
So recently (2days ago) I made this transaction:
Status: 0/unconfirmed, in memory pool
Date: 20.12.2017 23:30
To: N**** 1LecRzTpKXh9kCgqXbUXtdXfQjE145BR87
Debit: -0.00447735 BTC
Transaction fee: -0.00003840 BTC
Net amount: -0.00451575 BTC
Transaction ID: 850a72da35784c22c7fe1e39ac51cdc639923b26ab8bf7322f3cb7af4ffed263
Transaction total size: 191 bytes
Output index: 0

As you can see, the Bitcoins weren't sent and according to the Transaction ID the transaction wasn't done, as you can see here:
https://live.blockcypher.com/btc/tx/850a72da35784c22c7fe1e39ac51cdc639923b26ab8bf7322f3cb7af4ffed263/
So now I started to look around in different posts to get my coins back.
I found a post with the same problem... it told me to start Bitcoin Core like this:
E:\Programme\Bitcoin\bitcoin-qt.exe -zapwallettxes

but now i dont see my transactions anymore and i have 0 BTC in my balance.
I have no clue what to do now and how I can get my BTCs again.

Was the transaction suppose to deposit Bitcoins at your address?

Have you tried to do a E:\Programme\Bitcoin\bitcoin-qt.exe -rescan to force a rescan of all your transactions?

Thanks the -rescan solved the first Problem so now i see my transactions agian but still with 0/unconfimed, in memory pool. And no the transaction wasnt supposed to deposit bitcoins at my own addres its suppost to pay on a website.

You transaction fee is too low, it will probably never confirm. You have a few options

Did you have a transaction problem? We have the same problem! Tell me how you solved it?

I have observed from other experts that if you 'abandon transaction' your data will eventually be forgotten by other nodes and return to your account. You can 'abandon transaction' from the GUI console in 'transactions' by right clicking on it and selecting 'abandon'. This might take some time as even one outdated node might re-broadcast it again and it will get picked up by other nodes. Patience is what I have read. From there delete mempool and restart.

The Problem is i dont have the Transaction anymore its not there...

Ok now i have my transactions back but i cant press abandon transaction... probably because its in memory pool already


text:
Is there anything specific to the design of the Sapio language that makes it well suited to writing covenant scripts?
I think I understand at a high level the goals of both CheckTemplateVerify (CTV, BIP 119) and the Sapio language.
Is there anything specific to the design of the Sapio language that makes it well suited to writing covenant scripts? Other than being a high level language like Minsc that eventually compiles down to Miniscript?
To use Sapio for CTV scripts, both Miniscript and Script have to support CTV. So is there a test environment (e.g. signet or sidechain) where CTV is enabled for both Miniscript and Script?

excerpted from Designing Bitcoin Contracts with Sapio
How do we think about Smart Contracts and CTV?
Before CTV, in most Bitcoin smart contracts, we think at the key-level. That
is, what is a complex set of signers and satisfactions to unlock a specific
coin. But once we unlock a coin, the smart contract usually does not encode
any further restrictions on how it may be spent.
You could think of this as "a key to a car". If it unlocks the car, you can
take the car wherever you want.
With CTV, we hope to encode a bit more information about how coins should
move by providing the paths that the coins must move through as well. So
rather than just being the key to a car, you could think of it a bit more
like the keys to train -- still required to start the engine, but you have to
stay on the tracks and there is a finite number of tracks to pick at any
juncture.
That's all a bit abstract. Think back to the Hello World example we saw earlier. We
created a coin with the following options:

Alice and Bob Agree --> coin goes anywhere
Timeout --> coins go back to Alice and Bob

Now imagine we wanted to change the rules a little. What if instead of rule 2
apply after a timeout, what if we wanted the timeout to be measured from the
time that Alice or Bob claimed they wanted to use the escrow.
This puts us in a little bit of a pickle. Sure we could just re-write the rules:

Alice and Bob Agree --> coin goes anywhere
Timeout since Alice or Bob requested --> coins go back to Alice and Bob

But Bitcoin doesn't have a script level notion of "since" a part of a witness was constructed. The CTV way to think of this script is to define a state machine with two states  S in {Normal, Closing} and the rules:

S <-- Normal:

Alice and Bob Agree --> coin goes anywhere
Alice or Bob Requested --> (S <-- Closing)

S <-- Closing:

Alice and Bob Agree --> coin goes anywhere
Timeout since (S <-- Closing) --> coins go back to Alice and Bob.

What drives the transition from Normal to Closing? Just a standard Bitcoin transaction!
So What is Sapio
Sapio is an embedded domain specific language for defining these sorts of
state transition rules to build smart contracts for Bitcoin.
CTV is used as the mechanism to enforce that specific state transitions occur.
When we write a program in Sapio, we are designing an arbitrary state
machine that can run any program.
When we compile a Sapio program, we run that state machine to completion and merkelize the resultant program states into a fixed graph.
As such, Sapio  is a very powerful framework for designing Bitcoin smart contracts, but we're constrained to the set of contracts where we can enumerate all possible end states.

BIP-119 Emulation
Changes to Bitcoin take a long time. The star player in making Sapio work is
BIP-119, and that might take a while to get merged. To get around this, Sapio
provides some tools to enable similar functionality today by emulating
BIP-119 with signatures.
The Default Emulator
Sapio CTV Emulators defines implementations of a local emualator that can be
used by sapio compiler library users. To use such an emulator, a user can
generate a seed and create a contract. After creating the contract and
binding it to a specific UTXO, a user should be able to delete the seed,
ensuring that only the compiled logic may be used. Alternatively, they can
retain the seed and promise not to improperly use it.
This crate also defines logic for servers that want to offer emulator
services to remote compilers. This is convenient since the emulator server
must be kept secure, so an organization may want it to be more tightly
safeguarded.
The emulator definitions include wrapper types that compose individual
instances of an emulator into a federated multisig. This is useful
for circumstances where a contract is between e.g. 2 parties and both
have a emulator server. Then the contract can be "immutable" unless
both collude.
To aid in experimentation, Judica, Inc operates a public emulator server for
regtest.
[
    "tpubD6NzVbkrYhZ4Wf398td3H8YhWBsXx9Sxa4W3cQWkNW3N3DHSNB2qtPoUMXrA6JNaPxodQfRpoZNE5tGM9iZ4xfUEFRJEJvfs8W5paUagYCE",
    "ctv.d31373.org:8367"
]

How it works
See the source code for more detailed documentation.
CheckTemplateVerify essentially functions as a self-signed transaction. I.e.,
imagine you could create a public key that could only ever sign a transaction
which matched a certain pattern?
To implement this functionality, we use BIP-32 HD keys with public derivation.
On initialization, a server picks a seed S and generates a root public key K
from it, and publishes K.
Users generate a transaction T and extract the CheckTemplateVerify hash H for
it. They then take H and convert it into a derivation path D of 8 u32's and 1
u8 for non-hardened derivation (see hash_to_child_vec).
This derivation path is then applied to K to generate a key C. This key is
added with a CheckSig(SIGHASH_ALL) to the script in place of a CTV clause.
Then, when a user desires to spend an output with such a key, they create the
entire transaction they want to occur and send it to the the emualtor server.
Without even checking to see that the key is used in the transaction, the
server generates the template hash H' (which should equal H) and then signs,
returning the signature to the client.
Before creating a contract, clients may wish to collect all possible
signatures required to prevent an availability fault.
This scheme has the benefit that:

contract specification can occur without any online processes
The server has no intelligent logic, all guarantees are structural.
Server is completely stateless.
Availability/malfeasance can be controlled for with multisig
1:1 functionality mapping to CTV

The downside of this approach to emulation is that:

It is somewhat inefficient for scripts which have many branched possibilities.
No inherent mechanism to delete keys after use to protect against future exfiltration.

Why BIP-32
We use BIP-32 because it is a well studied primitive and derivation paths are
compatible with existing signing hardware. While it is true that a tweak of
32 bytes could be directly applied to the key more efficiently, easier
interoperability with existing tools seemed to be the best path.
Customizing Emulator Trait
This emulator trait crate is a base that exports a trait definition and some
helper structs that are needed across the sapio ecosystem.
Defining the trait in its own crate allows us to use trait objects in our
compiler internals without needing to have the compiler directly depend on
e.g. networking primitives.
As a user of the Sapio library, you can define your own custom emulator logic
but that's out of scope of this book.
Future Work
There is a plan to make
emulation more efficient based on Merkelization, but it is not yet
implemented because it messes with the current way the compiler works.
The efficiency issues are also solvable, more or less, with taproot.

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


text:
Which exchanges or wallets offer the option to open Lightning channels with them at the time of writing?
Which exchanges or wallets offer the option to open a channel with a Lightning routing node they operate at the time of writing (June 2023)? (I know Lightning Labs' Pool and liquidity ads attempt to provide a solution to the inbound capacity problem but for now I'm just interested in outbound capacity.)
Of those that do are there any particular requirements (e.g. minimum channel capacity, uptime requirement)?
I understand that I could speculatively try Lightning nodes from 1ML or Amboss but I'm capital and time constrained.
Also any exchanges or wallets offer the option to open signet channels with them at the time of writing?

This is a draft answer. As always alternative answers are welcome.
River is advertising the option to open Lightning channels with them but recommends contacting them via email before doing this.
Breez has documentation on how to do this and has set a minimum 10 million satoshis (~$2,700) capacity. (I asked on the Breez Telegram why this minimum capacity was set and smaller channel opens were apparently causing routing failures. This seems like a problem with present day path finding algorithms as additional channels/routes are additive by definition and shouldn't increase routing failures.)
Kraken has a minimum 1 million satoshis (~$270) channel capacity. (Thanks Poseidon for finding this)

Also any exchanges or wallets offer the option to open signet channels with them at the time of writing?

I'm not aware of any. See this post for guidance on setting up a routing node on signet.

https://support.kraken.com/hc/en-us/articles/9829766858260-Connecting-to-Kraken-s-Lightning-node
I found this for Kraken Centralized Exchange.


text:
To what extent does BIP32 key derivation impact the design of secure key aggregation multisig and threshold schemes like MuSig and FROST?
I have seen it discussed in various places (e.g. 1, 2) that using BIP32 key derivation impacts the design of secure key aggregation multisig and threshold schemes like MuSig(2) and FROST.
What are the relevant security concerns here? Is it hardened or non hardened derivation (or both) that are relevant here? Is BIP32 key derivation one of the reasons why Bitcoin design decisions are often different to those made in research papers without a focus on Bitcoin?

I cross-posted this question here: https://www.satsoverflow.io/questions/fa5fa7002060403389fcb805cd5d18c8

Alternative answers as always are welcome.
BIP340 does actually (at least partially) answer this.
Key prefixes were included in the design of BIP340 Schnorr signatures as without them "related key attacks" (e.g. attacks with BIP32 unhardened derived keys) are possible. Related key attacks are where you are able to produce a signature for a BIP32 unhardened derived child key without access to that key if you have the signature of that same message from the parent key.

a third party can convert a signature (R, s) for public key P into a signature (R, s + a⋅hash(R || m)) for public key P + a⋅G and the same message m, for any given additive tweak a to the signing key. This would render signatures insecure when keys are generated using BIP32's unhardened derivation and other methods that rely on additive tweaks to existing keys such as Taproot.

Key prefixes are defined in BIP340 as:

...we choose key prefixed Schnorr signatures which means that the public key is prefixed to the message in the challenge hash input. This changes the equation to:
s⋅G = R + hash(R || P || m)⋅P.
It can be shown that key prefixing protects against related-key attacks with additive tweaks. In general, key prefixing increases robustness in multi-user settings, e.g., it seems to be a requirement for proving the MuSig multisignature scheme secure (see Applications below).

BIP340 also links to this paper (On the Security of the Schnorr Signature Scheme and DSA against Related-Key Attacks).

Is it hardened or non hardened derivation (or both) that are relevant here?

As far as I can work out hardened BIP32 derivation isn't affected by related key attacks or any other security concerns so we are only concerned with unhardened BIP32 derivation when designing secure key aggregation multisig and threshold schemes like MuSig(2) and FROST. The design of these schemes are obviously constrained by the design decisions in BIP340 as they need to generate valid BIP340 public keys and be able to produce valid BIP340 signatures under the rules of SegWit version 1.


text:
Transfer bitcoin from gdax to my nano s and now it’s pending
I transferred 1.05 bitcoin using gdax to my nano s
and now it is pending in my Coinbase account without
any miners fee or transaction ID. I was never given a
chance to review the transaction! The receiving
address is correct. What do I do?

Quoted from GDAX:

Withdrawal transactions will be generated instantly, and the value
  withdrawn from your account.
There are occasional delays with both deposit and withdrawal
transactions. If you believe that your transactions are taking too
  long, please contact us and provide as much of the following
  transaction information as possible:


text:
Compiling an ALTCOIN on Ubuntu, getting errors during make
Hi I am compiling an ALTCOIN forked from another coin, I'm using Ubuntu Server 16.04 LTS via SSH from a remotely hosted server. I believe I installed all dependencies because I have already compiled about 4 coin source codes.
But with this particular source I am getting build errors, I will copy and paste the errors from the command line.
So I typed in
make -f makefile.unix USE_QRCODE=1

the here is the results.
  -MMD -MF obj/key.d -o obj/key.o key.cpp

key.cpp:30:5: error: ‘secp256k1_context_t’ does not name a type
     secp256k1_context_t* ctx;
     ^
key.cpp: In constructor ‘{anonymous}::CSecp256k1Init::CSecp256k1Init()’:

key.cpp:32:9: error: ‘ctx’ was not declared in this scope
         ctx = secp256k1_context_create(SECP256K1_CONTEXT_SIGN);
         ^
key.cpp: In destructor ‘{anonymous}::CSecp256k1Init::~CSecp256k1Init()’:

key.cpp:35:35: error: ‘ctx’ was not declared in this scope
         secp256k1_context_destroy(ctx);
                                   ^
key.cpp: In member function ‘bool CKey::SetPrivKey(const CPrivKey&, bool)’:

key.cpp:472:61: error: ‘class {anonymous}::CSecp256k1Init’ has no member named ‘ctx’
     if (!secp256k1_ec_privkey_import(instance_of_csecp256k1.ctx, (unsigned char*)begin(), &privkey[0], privkey.size()))
                                                             ^
key.cpp:472:118: error: ‘secp256k1_ec_privkey_import’ was not declared in this scope
     if (!secp256k1_ec_privkey_import(instance_of_csecp256k1.ctx, (unsigned char*)begin(), &privkey[0], privkey.size()))
                                                                                ^
key.cpp: In member function ‘CPrivKey CKey::GetPrivKey() const’:

key.cpp:491:66: error: ‘class {anonymous}::CSecp256k1Init’ has no member named ‘ctx’
     int ret = secp256k1_ec_privkey_export(instance_of_csecp256k1.ctx, begin(), (unsigned char*)&privkey[0], &privkeylen, fCompressed);
                                                                  ^
key.cpp:491:133: error: ‘secp256k1_ec_privkey_export’ was not declared in this scope
     int ret = secp256k1_ec_privkey_export(instance_of_csecp256k1.ctx, begin(), (unsigned char*)&privkey[0], &privkeylen, fCompressed);
                                                                                ^
key.cpp: In member function ‘CPubKey CKey::GetPubKey() const’:

key.cpp:507:65: error: ‘class {anonymous}::CSecp256k1Init’ has no member named ‘ctx’
     int ret = secp256k1_ec_pubkey_create(instance_of_csecp256k1.ctx, (unsigned char*)pubkey.begin(), &clen, begin(), fCompressed);
                                                                 ^
key.cpp: In member function ‘bool CKey::Sign(const uint256&, std::vector<unsigned char>&) const’:

key.cpp:529:57: error: ‘class {anonymous}::CSecp256k1Init’ has no member named ‘ctx’
         if (secp256k1_ecdsa_sign(instance_of_csecp256k1.ctx, hash.begin(), (unsigned char*)&vchSig[0], &nSigLen, begin(),  secp256k1_nonce_function_rfc6979, NULL))
                                                         ^
key.cpp: In member function ‘bool CKey::SignCompact(const uint256&, std::vector<unsigned char>&) const’:

key.cpp:553:75: error: ‘class {anonymous}::CSecp256k1Init’ has no member named ‘ctx’
         if (int ret = secp256k1_ecdsa_sign_compact(instance_of_csecp256k1.ctx, hash.begin(), &vchSig[1], begin(), secp256k1_nonce_function_rfc6979, NULL, &rec))
                                                                           ^
key.cpp:553:159: error: ‘secp256k1_ecdsa_sign_compact’ was not declared in this scope
         if (int ret = secp256k1_ecdsa_sign_compact(instance_of_csecp256k1.ctx, hash.begin(), &vchSig[1], begin(), secp256k1_nonce_function_rfc6979, NULL, &rec))
                                                                                ^

key.cpp:553:17: warning: unused variable ‘ret’ [-Wunused-variable]
         if (int ret = secp256k1_ecdsa_sign_compact(instance_of_csecp256k1.ctx, hash.begin(), &vchSig[1], begin(), secp256k1_nonce_function_rfc6979, NULL, &rec))
                 ^

key.cpp: In member function ‘bool CKey::Load(CPrivKey&, CPubKey&, bool)’:

key.cpp:569:61: error: ‘class {anonymous}::CSecp256k1Init’ has no member named ‘ctx’
     if (!secp256k1_ec_privkey_import(instance_of_csecp256k1.ctx, (unsigned char*)begin(), &privkey[0], privkey.size()))
                                                             ^

key.cpp:569:118: error: ‘secp256k1_ec_privkey_import’ was not declared in this scope
     if (!secp256k1_ec_privkey_import(instance_of_csecp256k1.ctx, (unsigned char*)begin(), &privkey[0], privkey.size()))
                                                                                ^
key.cpp: In member function ‘bool CPubKey::VerifyCompact(const uint256&, const std::vector<unsigned char>&) const’:

key.cpp:633:10: warning: unused variable ‘fComp’ [-Wunused-variable]
     bool fComp = IsCompressed();
          ^

key.cpp: In member function ‘bool CPubKey::IsFullyValid() const’:

key.cpp:655:60: error: ‘class {anonymous}::CSecp256k1Init’ has no member named ‘ctx’
     if (!secp256k1_ec_pubkey_verify(instance_of_csecp256k1.ctx, begin(), size()))
                                                            ^

key.cpp:655:80: error: ‘secp256k1_ec_pubkey_verify’ was not declared in this scope
     if (!secp256k1_ec_pubkey_verify(instance_of_csecp256k1.ctx, begin(), size()))
                                                                                ^

key.cpp: In member function ‘bool CPubKey::Decompress()’:

key.cpp:670:69: error: ‘class {anonymous}::CSecp256k1Init’ has no member named ‘ctx’

int ret = secp256k1_ec_pubkey_decompress(instance_of_csecp256k1.ctx, (unsigned char*)begin(), &clen);
                                                                     ^
key.cpp:670:104: error: ‘secp256k1_ec_pubkey_decompress’ was not declared in this scope

int ret = secp256k1_ec_pubkey_decompress(instance_of_csecp256k1.ctx, (unsigned char*)begin(), &clen);
                                                                                ^
key.cpp: In member function ‘bool CKey::Derive(CKey&, unsigned char*, unsigned int, const unsigned char*) const’:

key.cpp:712:70: error: ‘class {anonymous}::CSecp256k1Init’ has no member named ‘ctx’

bool ret = secp256k1_ec_privkey_tweak_add(instance_of_csecp256k1.ctx, (unsigned char*)keyChild.begin(), out);
                                                                      ^
key.cpp: In member function ‘bool CPubKey::Derive(CPubKey&, unsigned char*, unsigned int, const unsigned char*) const’:

key.cpp:731:69: error: ‘class {anonymous}::CSecp256k1Init’ has no member named ‘ctx’
     bool ret = secp256k1_ec_pubkey_tweak_add(instance_of_csecp256k1.ctx, (unsigned char*)pubkeyChild.begin(), pubkeyChild.size(), out);
                                                                     ^

makefile.unix:206: recipe for target 'obj/key.o' failed

make: *** [obj/key.o] Error 1

I have been trying to debug but I cant seem to get anywhere, can someone please help me out?
Thanks.

Try downloading and compiling this: https://github.com/bitcoin-core/secp256k1

I did that before I tried running the makefile.

Does it need to be included into the system environment? And if it does what specific file needs to be included?

1) Make new folders called obj and obj-test inside the src folder
2) Try to recompile


text:
Bitcoin withdrawal from blockchain
Greeting of the Day,
hi , I'm from India and i have bitcoin balance in my blockchain account but i don't how i convert it into real cash and withdraw.
you are requested to kindly guide me and suggest me the way.
Awaiting for you reply.
Thanks & regards

The term for converting something other than cash into cash is "selling". What you want to do is sell your bitcoins.

The process would be to deposit the bitcoins into a bitcoin exchange, sell them there, and withdraw your cash from exchange account to your bank account. but make sure the exchange must be able to send money to your bank.
Also you have one more option is "Bitcoin ATMs" but I think in we don't have any ATM machine.


text:
What does this Blockchain info mean? Clueless

This is the info but it'S all greek to me. I'm pretty nerdy about PC's but clueless in terms of bitcoins. Tell me where I can get definitive comprehensive information would be a help too.

No it’s not greek :-)
You’re first step in understanding might be to have a look at the book „Mastering Bitcoin“ by Andreas M. Antonopoulos. And if you need a translation, you might want to look here: https://www.transifex.com/bitcoinbook/public/.
The second resource is „www.bitcoin.org“, where you can find a description of the whole eco system, also in many languages.
The picture displays info about a wallet address, and it’s transactions, followed by  corresponding data to handle such a transaction in the bitcoin network. At the top left you can see the bitcoin address (1CYQ…), and it’s hash representation (look into the references I gave, why you would have hash representations). In the top middle section you see the amount of transactions for this address, and to the right a graphical representation of the address („QR code“). With QR codes you can e.g. transfer information between mobile devices via their integrated cameras. So if someone wants to send you money, he just scans the picture, instead of typing the address.
And the bottom section shows the previous transactions for this address, how values got „transferred“ from source addresses to target addresses.

This picture describes transactions, which are things that move money around between addresses. You can search for the incoming and outgoing payments to a particular address.


text:
how can I create a block chain?
How can I reate a block chain and a bitcoin wallet as I want to start trading in bitcoins.  I have never opened a bitcoin waller or block chain and am not sure if I should have both?

Please see: I am new to Bitcoin, how can I get started?

A blockchain is the basic data structure used to record the transactions in the network. It already exists, you don't need to create it. This is like asking "I want to send an email, how do I create an internet?".
You need Bitcoin wallet software. See https://bitcoin.org/en/getting-started for more information.

Go to blockchain.info.  Click on wallet at the top, then click on Create wallet.   Fill out and then it will send an email that you will need to confirm.  After you login, you'll need to complete security information but it's really self explanatory at this point.
It depends on where you live if you can purchase bitcoin on blockchain or not.  If you live in USA, you can't and will need another waller to buy.

People often fund BTC purchases into a personal wallet via Bitcoin ATMs or via bank transfers of fiat to an exchange, transacting there, and withdrawing into the wallet.

authors: صادق شکیبایی


text:
bitcoin random key
$blockchain_receive_root = "https://api.blockchain.info/";
$mysite_root = "mysite url";
$secret = "CHANGE_TO_RANDOM_SECRET";
$my_xpub = "CHANGE_TO_XPUB_KEY";
$my_api_key = "CHANGE_TO_API_KEY";

I have api key and xpub key but how to set the random secert key

The secret can be anything you want it to be. It's intended to prevent malicious users from running your callback URL manually.
Your callback will do a check similar to:
if ($secret !== "mycoolsecret") { die (); }


text:
End-user security measures to protect your Bitcoins
I am trying to make a presentation on Bitcoin for my Security and Risk Analysis class.
Currently, my research question is : What bitcoin security measures can enhance user-protection and reduce theft?
My professor needs the topic to be scientific, atleast that it sounds like one.
I need your help to paraphrase my question to make it more worthwhile for research.

You're going to need to narrow down your question a bit. Are you asking about security measures that ordinary end-users can take? Are you asking about security measures that website operators can take? Are you asking about security enhancements that the Bitcoin developers could add?

Most Bitcoin thefts occurs due to user careless and ignorance, like not using two-factor authentication and sharing email and password across questionable websites. The risk of theft can be easily reduced by taking the basic security measurements which you should follow in any case when you are dealing with Internet.
Here are some things you should include in your presentation

Don't use questionable Bitcoin services or exchanges (see: Mt.Gox) - if you are unsure ask the Bitcoin community about the integrity of the service. Any "free bitcoins" sites are definitely no go.
Always enable two-factor authentication when using Bitcoin services (exchanges, web wallets)
Keep most of your Bitcoins in a cold wallet or vault service which is not directly connected to Internet
Don't install unnecessary software on the computer you use to handle Bitcoins. Especially don't install software from download sites (even legit ones) or from Bittorrent. Always download software directly from the site of the author.
Don't install unnecessary browser extensions
Don't use the same computer to surf on questionable sites (adult entertainment, illegal software, tor) - you usually get malware infection from sites like this
Keep your computer software up-to-date
Don't click phishing links
To reduce the risk of malware, use safer operating systems like OSX or Linux instead of Microsoft Windows. Please note that this only lowers the malware risk, it doesn't guarantee immunity if you don't follow the other advices mentioned here.

More information about Bitcoin end user threats can be found in this question.


text:
BIP38 on multisig? Does it work?
I was making a multisig account with 3 of my Bitcoin addresses. The multisig account needs 2 of 3 private key to spend the Bitcoins in there. Then, I came up with an idea that nobody on the internet (at least, nobody on the first page on google) had tried or thought about.
Can I use BIP38 encryption on the private keys (in multisig)?

Yes, you can use BIP38 with multisig.
It's not exactly a brand new idea, though. I've spoken with some people from Gem (https://gem.co/), that's exactly what their API lets you do.

Thanks man. You maked me thinking twice and now I understand it :D


text:
How do I prevent the standard Bitcoin client from sending some of my Bitcoins to a change address?
I found somebody that imported a paper wallet with 100BTC then used 2BTC BUT the other 98BTC were sent to a change address. Why and how can I prevent this; how can I enter a custom change address?

Where DO you want the change to go, if not to a change address? Back to the same address? You could make the raw transaction yourself, telling where to send each of the outputs. That might be a little too technical for what you're looking for, possibly. If not, I can post an answer detailing how one would do that.

Obviously I don't mean like making the transaction byte by byte, by hand. I mean you can use the RPC commands and manually say where you want all the coins to go.

The standard client doesn't have any built-in options for this. You could manage it yourself if you built the transaction by the RPC API commands or, more easily, by using a client with that feature built in, like Armory:

Or, if you know what inputs will be used and the exact amounts involved, you can add the "change" yourself as an additional output. This will make it so the client won't need to generate any additional change back to itself. Remember to subtract a transaction fee, if necessary.

How do I do in blockchain?

@Tor Are you referring to blockchain.info?

Blockchain.info's wallet has a feature a little like Armory: you can choose where the change goes, as long as it's an address already in your wallet (Armory lets you send it anywhere).

@NickODell plz... I want help not money...

How do I report comments...

@Tor when you hover over a comment, there's a "flag" icon in the lower left corner. For the record, I don't see anything wrong with any (existing) comments by NickODell: just one asking if by "blockchain" you mean "blockchain.info", which is a perfectly reasonable and polite clarification question: in short, a perfect comment.


text:
Are Bitcoin fees optional?
I was making a multisig account in coinb.in. Then I tried to make a transaction (spend funds). At the bottom there was a box for writing the fee.
What fee? I thought bitcoin sending was free! Beside the box, it said, "Make sure you include an adequate fee, otherwise your transaction may be rejected. 0.0005 BTC or more is recommended."

The fee is optional; however, including your transaction in the next found Bitcoin block is also optional.
The miner who finds a block gets to decide which, if any, transactions are recorded with the block they found.
Factors that influence whether your transaction is included in that found block include:

The block size limit.  Sometimes the transactions are too large to all fit into the block, so most will prioritize higher fee transactions to be included first.
Local settings for the person finding the block can be set to ignore transactions with fees lower than an amount of their choosing.
Some people will include all the transactions they have seen, as long as they will all fit, but this is not the normal default mode of operating for miners.  If you do not include any fee, then this would be your only chance.

But how do I calculate the priority? In the bitcoin wiki I didn't understand what input_value_in_base_units is.

The input size is the bitcoin value of your source wallet.  DeathAndTaxes explains it more here: https://bitcointalk.org/index.php?topic=95312.msg1053439#msg1053439

Does input_value_in_base_units means total amount of bitcoin?

In any given wallet you will have fragments from many transactions, each one is a separate input source.  Assuming you have a new empty wallet and send it 10 bitcoins, then 10 bitcoins will be the size of your input source for your next outgoing transaction (regardless of how much of that 10 bitcoins you are giving someone).  The transaction will essentially send all 10 bitcoins in a split - part to the person you sent, and the remainder back to yourself.

You can check this link  that explains everything clearly. So, I will summerize the content.
First of all, to spend d bitcoins, you need to have d bitcoins in your wallet. So, you refer to all transactions (Say T1, T2, ..., Tk) as inputs to your new spend transaction, from which you received at-least d bitcoins collectively. As you may know already, to get the priority of a transaction you need to multiply the age of Ti with its BTC value, sum over all i from 1 to k, and then divide this sum by your spend transaction size. Now, you need not calculate the exact size of the transaction, as you can use an approximation on the upper size limit (USL) = function(#i/p, #o/p).
if((USL < 1000 bytes) and (priority >= 0.576)) then no txn fee is required
else you need to pay at-least 0.0001 BTC per 1000 bytes of your spend txn.

Yes, but it's up to the miners if and when they'll include your transaction. Miners get the fee you pay when they put your transaction in a block. Tip your miner, and he will include you faster.
Miners often include no-fee transactions, but if the blocks are full (they have a size limit) they might not be included at all! These transmission fees are a thorn in the collective eye, but in Bitcoin they are essential to security.


text:
How to verify ECDSA of a sample litecoin tx using pycoin?
I'm using the litecoin testnet network for testing. I have a UTXO at 053baee857adfdc16959e9dbc9618e0e935f0a1e51e226e651fcd67242f1f462 with a vout of 0.
I make a raw transaction sending the coins to myself (at a different address):
$ ./litecoind createrawtransaction '[{"txid":"053baee857adfdc16959e9dbc9618e0e935f0a1e51e226e651fcd67242f1f462", "vout":0}]' '{"mroLyo22ptLfq5LKMijnCyD35mEsAWTkF9":0.039}'
 010000000162f4f14272d6fc51e626e2511e0a5f930e8e61c9dbe95969c1fdad57e8ae3b050000000000ffffffff0160823b00000000001976a9147bc2f9c3a30a18cc307d74fd014e4ddf7323398488ac00000000

Then I sign the raw transaction using signrawtransaction:
$ ./litecoind signrawtransaction 010000000162f4f14272d6fc51e626e2511e0a5f930e8e61c9dbe95969c1fdad57e8ae3b050000000000ffffffff0160823b00000000001976a9147bc2f9c3a30a18cc307d74fd014e4ddf7323398488ac00000000
signrawtransaction hash: eed300fc63a973b668af66af746fde378ec6556f4b330ec1eeccc6a77aa535b0
{
    "hex" : "010000000162f4f14272d6fc51e626e2511e0a5f930e8e61c9dbe95969c1fdad57e8ae3b05000000006a4730440220258ad2725e66da0ae9825bb849a8e73f86e4767cf256c9fae44d18fbc1aacc2e0220406638a5b3369bb83d8a4f38a17b2f048c1495ebfd6fdff1a8c7b268e07f69cd012103ec539eb3d882c07575f6143d891c18d580cd9d2726add0d71d262f2f6f2d4ccfffffffff0160823b00000000001976a9147bc2f9c3a30a18cc307d74fd014e4ddf7323398488ac00000000",
    "complete" : true
}

Note that the hash being signed here is eed3.... I added a print line t the code so that I could see the uint256 that is being signed. Specifically, in script.cpp, where the signing for signrawtransaction takes place, I added an extra boolean parameter to log the hash and the lines below.
bool SignSignature(const CKeyStore &keystore, const CScript& fromPubKey, CTransaction& txTo, unsigned int nIn, int nHashType, bool printHash)
{
    ...
    // Leave out the signature from the hash, since a signature can't sign itself.
    // The checksig op will also drop the signatures from its hash.
    uint256 hash = SignatureHash(fromPubKey, txTo, nIn, nHashType);

    if (printHash)
    {
        std::cout << "signrawtransaction hash: " << hash.ToString() << std::endl;
    }

Next, I decoderawtransaction and take the first element on the asm stack, which is the signature.
30 44 02 20
258ad2725e66da0ae9825bb849a8e73f86e4767cf256c9fae44d18fbc1aacc2e
02 20
406638a5b3369bb83d8a4f38a17b2f048c1495ebfd6fdff1a8c7b268e07f69cd
01

Here, with some help from Pieter Wuille (Why the signature is always 65 (1+32+32) bytes long?), we can see the R and the S elements.
Next I put them in to my pycoin test file. Pycoin is an easy to use python library for bitcoin ((https://github.com/richardkiss/pycoin)).

from pycoin.ecdsa import *

import string

def verify_sig(sig, prefix, xpub, signed_val):
    is_even = (prefix % 2 == 0)
    pub_pair = public_pair_for_x(generator_secp256k1, xpub, is_even)
    print("sig: (" + hex(sig[0])      + ", " + hex(sig[1])      + ")")
    print("pub: (" + hex(pub_pair[0]) + ", " + hex(pub_pair[1]) + ")")
    print("hex: "  + hex(signed_val))

    print("is valid: " + str(verify(generator_secp256k1, pub_pair, signed_val, sig)))

sigR = 0x258ad2725e66da0ae9825bb849a8e73f86e4767cf256c9fae44d18fbc1aacc2e
sigS = 0x406638a5b3369bb83d8a4f38a17b2f048c1495ebfd6fdff1a8c7b268e07f69cd
sig  = (sigR, sigS)
x    = 0xec539eb3d882c07575f6143d891c18d580cd9d2726add0d71d262f2f6f2d4ccf
hash = 0xeed300fc63a973b668af66af746fde378ec6556f4b330ec1eeccc6a77aa535b0
compressed_char = 0x03

verify_sig(sig, compressed_char, x, hash)

And the result that is printed:

sig: (0x258ad2725e66da0ae9825bb849a8e73f86e4767cf256c9fae44d18fbc1aacc2e, 0x406638a5b3369bb83d8a4f38a17b2f048c1495ebfd6fdff1a8c7b268e07f69cd)
pub: (0xec539eb3d882c07575f6143d891c18d580cd9d2726add0d71d262f2f6f2d4ccf, 0x227874efbedb02b88568b55106634b9b4e3eca128ab46fa98abe7066aece0a51)
hex: 0xeed300fc63a973b668af66af746fde378ec6556f4b330ec1eeccc6a77aa535b0
is valid: False

I am really not sure what could be going wrong here, since this is just straight ECDSA verification. Are there any values there that seem strange, or any other reason that this would not validate?

Found the problem! Bitcoin is very inconsistent about big/little endian integers. I reversed the hash and the signature was verified!
Final program:

from pycoin.ecdsa import *

import string
import array
import binascii

def verify_sig(sig, prefix, xpub, signed_val):
    is_even = (prefix % 2 == 0)
    pub_pair = public_pair_for_x(generator_secp256k1, xpub, is_even)
    print("sig: (" + hex(sig[0])      + ", " + hex(sig[1])      + ")")
    print("pub: (" + hex(pub_pair[0]) + ", " + hex(pub_pair[1]) + ")")
    print("hex: "  + hex(signed_val))

    print("is valid: " + str(verify(generator_secp256k1, pub_pair, signed_val, sig)))

sigR = 0x258ad2725e66da0ae9825bb849a8e73f86e4767cf256c9fae44d18fbc1aacc2e
sigS = 0x406638a5b3369bb83d8a4f38a17b2f048c1495ebfd6fdff1a8c7b268e07f69cd
sig  = (sigR, sigS)

x    = 0xec539eb3d882c07575f6143d891c18d580cd9d2726add0d71d262f2f6f2d4ccf
char = 0x03

revhash = "eed300fc63a973b668af66af746fde378ec6556f4b330ec1eeccc6a77aa535b0"
hash = ""
for i in range(0, len(revhash), 2):
    hash = revhash[i:i+2] + hash

verify_sig(sig, char, x, int(hash, 16))

And the result:

sig: (0x258ad2725e66da0ae9825bb849a8e73f86e4767cf256c9fae44d18fbc1aacc2e, 0x406638a5b3369bb83d8a4f38a17b2f048c1495ebfd6fdff1a8c7b268e07f69cd)
pub: (0xec539eb3d882c07575f6143d891c18d580cd9d2726add0d71d262f2f6f2d4ccf, 0x227874efbedb02b88568b55106634b9b4e3eca128ab46fa98abe7066aece0a51)
hex: 0xb035a57aa7c6cceec10e334b6f55c68e37de6f74af66af68b673a963fc00d3ee
is valid: True


text:
Would it be possible to add an RPC call to be able to determine if a node is fully synced?
After reading this answer, where Peter Wuille talks about how a node can't really tell if it is synced or not, it got me wondering if there is a way we can tell that a node is as synced as it possibly can be given the peers it is connected to.
Could we add an RPC call like getsyncstatus that would have the node ask its peers for their highest known blocks and if a majority (or some percentage) of their peers all agree on the best known block height, then it could use that info to be able to say (with not perfect reliability) how synced the node is?
So, for example, if a node has 8 peers, and 7 of them are returning 330448 as the best block height, and the client has information about block 330448, then it could give a status code and message signalling that it is up to date. If the peers give different answers (which could happen if you connect to a malicious node that is falsely reporting it's best known height OR if other peers are not fully synced), then it could give a status code and a message indicating that the search was inconclusive and they should try again later. And lastly, if 87.5% of nodes are saying 330448 and the node is only synced up to block 1000, then it can give a status code and message indicating that the node is likely not sufficiently synchronized.
I think this would mainly be useful as a way to determine whether servers are sufficiently synchronized with the network for use on some application. The responses to this question describes a way to see if nodes are up to date, but they all seem kind of hacky, and I'm not sure they would be reliable enough.

Existing Methods
The Bitcoin client does have a way of detecting if it is not sufficiently synchronized. However, to my knowledge, it's not really exposed to RPC in a nice way.
It's called IsInitialBlockDownload(), and it will consider itself not synchronized if any of the following are true:

The client is importing from bootstrap.dat or reindexing the blocks it has.
The client has not reached all of its block checkpoints.
The client has received and verified a block in the last 10 seconds AND that block has a timestamp of more than 24 hours ago.

You can call getblocktemplate, and if IsInitialBlockDownload() is true, it will come back with an error of RPC_CLIENT_IN_INITIAL_DOWNLOAD (or -10).
Drawbacks

If your Bitcoin node is down for less than 24 hours, this won't detect anything wrong when it comes back up.
It's a bit ugly.
When your client gets within 24 hours of the current block, it'll think it's up to date, when it probably needs to get ~144 blocks.
If your client stops downloading blocks while it's still synchronizing, this won't detect anything wrong.

New RPC call
Let's suppose that we're designing a new RPC call from scratch. As other posters have noted, it's not possible to determine this perfectly in the presence of malicious actors. What factors could we measure to make an educated guess?

Node uptime. Has the node been up for at least five minutes?
Node downtime. Has the node been down recently? If so, take the amount of time that it was down, and divide it a thousand. If your node has not been up at least that long, then it is not synchronized.
Block timestamp. The network is fairly liberal about enforcing this rule, but my unscientific guess is that it's usually within half an hour or so. You could use this information in a similar way to how IsInitialBlockDownload() does.
Block height of central node. This is the "Look at blockheight of blockexplorer," solution mentioned in the other question.
Your method would probably work. The only issue I can think of is that if you connected to another node that was still syncronizing, you'd fail to fail.

What if the client has received a block recently but it is not done processing it, what will getblocktemplate do in this case?

@StephenM347 It looks at when it finished validating the tip of the best blockchain. (So, it doesn't take blocks that haven't been validated into account.)

Okay, thanks. I wish this were exposed in the RPC interface in a less hacky way.

So won't this method fail if the client is synced past all of the checkpoints, but has been offline for like 8 hours?

@StephenM347 Well, it'll fail to fail. :) In all seriousness, you're correct.

So, unfortunately this doesn't really solve the problem then... :/

But it does answer my question, so if you update it to include the stuff you told me in this commenting, I'll mark is as the right answer. And adding a new RPC call could fix this, you think, right?

Well bitcoind is opensource so it is entirely possible for you to try to integrate something like that yourself. However, rather than make changes to the base code, you might be able to get similar functionality using the rpc calls that are already implemented. Essentially, the bitcoin client already somewhat does what you're explaining. When you connect to a peer, part of the handshake process is sharing each other's current block; if one is higher than the other's and is valid, the other starts to download from the more current peer. If you look at the debug.log file you can see this happening, along with a running "progress" field that gets logged showing you the percentage you have downloaded.
However for your idea, where you aggregate information, you can try using the "getpeerinfo" rpc call. You could take the information from there and analyse it in anyway you wish without having to to make a native rpc call.

No, there is no way to tell, because there is no definition of "being synchronized". Are you still synchronized at the very moment some miner finds a new block? How would you know?
What you describe has no benefit over the already implemented methods of detecting whether the node is far behind (also it is already implemented as Pieter Wuille explains in the answer you linked, though it is not available in the API).
What is it exactly what to try to achieve with this information? Why do you need to know if a server is sufficiently synchronized? You will encounter the real blocks much sooner than any reasonable attacker can generate them.

Example usage: You have an payment processing application, and you want it to disable itself if it's blockchain download is not up to date, rather than some features mysteriously not working.

Just like Nick said.

@StephenM347 How many payment processing application do not run continuously? Even then, you can still just check the time stamp in the last block and compare it to the system time. I don't see the advantage.

Those timestamps in blocks are pretty unreliable, so I don't think that's a possibility. We have a more complicated use case in mind, but I don't really want to go too far into it. What we really want is a way to know if a server is too far behind to be reliable.

And even if it runs continuously, you need to know when it's ready after the initial download.

@StephenM347 Why are they not reliable? They are at least equally reliable as querying random unverifiable nodes for their block height.

They're not reliable because miners change them frequently to get more work, and the network allows for a certain amount of flexibility when interpreting these block times. I don't think they would be as reliable as querying the nodes who you are connected to, since bitcoin only really works if most nodes are honest nodes.

May or may not be of use to you, but just to check sometimes I have a little script/webpage that gets the current block height from each of my bitcoind nodes - if any of them are lower than the majority then they are out of sync. Obviously you'd need nodes on different networks and machines else an error could mean all nodes are out of sync. Works for me though, it's simple and uses an existing RPC call.


text:
What is the state of Witcoin?
There used to be a forum site called Witcoin. It was interesting in that in order to post, you'd have to pay bitcoins, and when someone replied or upvoted, you made bitcoins.
The site went away.
What is the current state? Are there plans to bring it back? Will there be a chance for users to recover their coins?

Witcoin was written and run by mizerydearia. At some point he became unable to run the site, but he was/is unwilling to give the witcoin database or wallet to anyone else. (Someone else owns the domain name.) Mizerydearia was very intelligent, honest, and active, but it seems likely that he's developed some sort of mental illness (as you'll see if you read his forum posts). It's very sad. Hopefully he'll someday recover enough to run witcoin again or at least refund the BTC.

Apologies for witcoin going down.
I have had a lot of internal issues with the administration of the old
  site and I hope to recover access to your accounts soon so please stay
  tuned for updates. For this I humbly apologise. Feel free to submit
  anything to this blog as I have left it open for you to post things
  to. Contact me by asking a question and once again, I am  sorry.
Dave , cryptocoinmedia , witcoin.

Posted 2 months ago


text:
Should I always run "make clean" between building different PR branches of Bitcoin Core?
I am switching between building different PR branches (ie I built one PR author's branch and now I am building a different PR author's branch).
Jon Atack's doc suggests:

On the other hand, when you change the build configuration, and in some cases when testing different PRs, or when the build isn't working, it's often best to start with a clean slate using make clean or make distclean before configuring.

Should I always run make clean in between builds?
edit: Jon Atack has since updated his doc. Here is the updated guidance.

On the other hand, when you change the build configuration (e.g. for a fuzz build), or you are building a branch containing substantial changes to the autoconf/automake scripts, or when the build isn't working, it's often best to start with a clean slate using make clean or make distclean.

You could always run make clean between builds but a lot of the time it won't be necessary and it is slower.
Pieter Wuille usually doesn't run make clean and only runs it when the build fails.
If it still fails after that he runs git clean -dfx. Warning: This deletes everything and resets your work directory to a fresh checkout. You'll need to autogen.sh again.
(Glen Willen suggests running git clean -dfX instead of git clean -dfx as X only removes ignored files, x also removes locally added non-ignored files, including e.g. new code you did not yet call git add on)
make clean is only necessary when the configuration changes. This could be because you run ./configure with different flags or it could be because there are substantial changes to the autoconf/automake scripts when changing branches. Of course the act of changing branches isn't relevant as the build system doesn't know or care that you are using Git. The build system just sees some code and/or configure scripts changed and re-runs them as necessary. Without make clean it will just see existing .o files not realizing that the rules used to build them have changed
Jon Atack usually doesn't run make clean but does if there is slight weirdness or if switching to fuzz build or back.
Thanks to Pieter Wuille, Jon Atack, Marco Falke and Glen Willen for answering this question on IRC.


text:
How do I join the Bitcoin Core PR review club meetings on IRC?
I would like to learn about reviewing Bitcoin Core pull requests at the Bitcoin Core PR review club. How do I join the ##bitcoin-core-pr-reviews channel on IRC (Libera.Chat network) and which IRC client do you recommend I install?
I can use the command line but I would prefer to maximize convenience and minimize setup time.

On Ubuntu, I like weechat.
On OSX I've used Colloquy before but have recently upgraded to Textual which is not free -- unless you build it from source :-).
There is even a web interface for freenode, but I'm not sure if it requires authentication to join the channel.

I don't know about android but I do have an iOS app called Mutter that works - I've joined review club from the subway!

The Bitcoin Core PR review club site links to this beginner's guide to IRC.
There are more impressive IRC setups such as Pieter Wuille's setup.

My setup is: juicessh on my phone, ssh into my VPS (non-tor), where I run irssi in screen, which connects via tor to freenode and other networks

But you said you wanted to minimize setup time. In that case I would recommend Textual on MacOS (as pinhead does in his answer). It isn't free, the license costs $7.99 at the time of writing (September 2020). There is a FAQ for using Textual here.
This will allow you to join the Bitcoin Core PR review club meetings but you won't be able to receive messages or view discussion that has happened on channels while you were offline. You would need to set up a bouncer on a virtual private server to do that (or refer to third party conversation logs). For that I recommend ZNC but first get set up with a IRC client like Textual.
Further discussion on terminal based IRC clients.


text:
Sending regtest Bitcoin fails with an error message. How do I resolve this error?
When I try to send regtest Bitcoin using bitcoin-cli:
./bitcoin-cli -regtest sendtoaddress bc1q09vm5lfy0j5reeulh4x5752q25uqqvz34hufdl 0.1

I get the error message:
error code: -6
error message:
Fee estimation failed. Fallbackfee is disabled. Wait a few blocks or enable -fallbackfee.

How do I resolve this so I can send regtest Bitcoin?

I think it was already addressed in https://bitcoin.stackexchange.com/questions/97174/using-bitcoin-client-and-bitcoind-for-regtest-error-regarding-fallback-fees/97223#97223 ?

Thanks, darosior. Voted to close this one.

You could enable -fallbackfee as it says in the error message but the easiest or quickest way to resolve this is to set a fee. In this example we are setting a fee of 1 satoshis per byte.
./bitcoin-cli sendtoaddress "bc1q09vm5lfy0j5reeulh4x5752q25uqqvz34hufdl" 0.1 "" "" false true 1 sat/B

If you do
./bitcoin-cli -regtest help sendtoaddress

you will see what those arguments after the regtest address represent.
Alternatively if you want to set the fallback fee see this StackExchange question.
This PR 16524 merged in October 2019 disabled -fallbackfee across all chains (mainnet, testnet, regtest) by default.


text:
What are the different types of spam that the Lightning Network is subject to?
What are the different types of spam that the Lightning Network is subject to and what are the possible strategies for dealing with such spam?

I've unquoted this as this isn't a quote. It is just me writing what question Rusty is answering.

There are three types of spam problem in the Lightning Network. Let's
call them "local","fast" and "slow".
Local spam is someone sending or requesting too much data: that's a simple batter of code with rate limiting etc.
Fast spam is sending many failed payments.  You can't tell what will succeed and you can't blame the sending peer (they may not be the
source).  This attack is free since we only pay on success. The answer
is to require an up-front payment but it has to be small (making sure
your incentive is to succeed) and it should not leak information on
where you are in the path.  I've been unable to find a scheme I'm
happy with though, see my latest attempt here.
Slow spam is sending a long-lived payment. This consumes capacity > 1000x expected for a normal payment and is similarly free (if you fail). The only solution I like here is to penalize slow payments by
requiring proof-of-channel closure but you can't always tell if
the payment was really in the channel and what if the close
transaction pays super-low fees / conflicts?  You need a Merkle tree
of claimed HTLCs, plus onion unwrapping, agreement on valid closes,
handling of fake Merkle trees... all possible but real work.
Summary: We can mitigate some attacks but real fixes need spec
improvements and implementation.  More attention from Smarter People
Than Me (hi!) will help us here.

This question was answered by Rusty Russell on Twitter.

Hi Michael, love the content you have been putting up here lately. Please be sure to format quotes as such when you copy them. Stuff like "solution I like" become a bit confusing when it's not clear that the whole answer is a quote.

Sure. Will do. Thanks for the feedback!


text:
How can I obtain a better understanding of the P2P messages between my full node and its peers?
I am interested in how my full node interacts with its peers, what messages it exchanges (e.g. gossip about other nodes on the network, transactions, blocks) and why my full node disconnects with certain peers (is it my full node making the decision to disconnect or the peer?).
I know there is an open PR from Troy Giorshev (also covered in this Bitcoin Core PR review club) to make some of this possible to do within Bitcoin Core. What insights will I be able to garner from using this tool? For example will I be able to work out why a peer disconnected (e.g. because it went offline, because my full node was asking for too much information/too demanding, because I sent it transaction(s) it wasn't interested in?) What is possible currently with this PR and what is possible for future improvements of this tool?
(Also will playing around with this tool let me answer this question on falling back unnecessarily on DNS seeds?)

I'm surprised that you introduced the new tag "Wireshark" here. Wireshark is just a tool that you are using to track the network messages, but as far as I can tell, Wireshark is neither subject of the question nor has anything to do with Bitcoin specifically itself. The actual topic of your question seems to be "network-messaging-analysis" or similar. Open to suggestions, because that sounds like a mouthful.—Maybe we should think about what distinguishes the tags [tag:network], [tag:p2p], [tag:peers], etc.

Just spotted there were a few Q&As on using Wireshark with Core and thought it would be useful to group them together with a label. An alternative to using Troy's tool is Wireshark as far as I understand so not entirely irrelevant to the question. I'm interested in what you can do with Wireshark, what you can do with Troy's tool and what you might be able to do in future. Maybe p2p-tools as the label rather than wireshark?

I've merged [wireshark] into [network].

Wireshark understands the Bitcoin P2P protocol and it's one of the most popular packet capture tools.

It doesn't really support the modern p2p network at all, so isn't that useful over just debug=net honestly.


text:
Lost money with Bitcoin Core wallet
I was sent $750 worth of BTC on 11/29/17. On 1/7/18, I finally got to 11/29/17 while syncing the blockchain to the core wallet and my coin arrived. However, on 1/7/18 I tried to send part of it to the Bread wallet and the rest to an online site. The Core wallet debited the coin and I was expecting that when it synced to 1/7/18 the money would arrive to those places. However, the blockchain has passed 1/7/18 and my coin has not reached the receivers.
These are the transactions that have not arrived:
https://blockchain.info/address/15x75nezMGZvF9KS4DxnSoJ33gdDy8C72a
https://blockchain.info/address/1FymHcBdWnoHtecA2qEkbwYpTzAJqDiNjc

You linked adresses. Not transaction ID's.
It seems to me that you A. either failed to broadcast your transaction, or B. you broadcasted it with a fee that was so low that nodes eventually dropped your transaction.
( Or maybe your coins got double spend?)
A is much more likely. Are you sure you are spending the right outputs? I can't really give a solution other then that you should try to simply rebroadcast your transaction with the information i currently have.

I am not sure about A. How would I broadcast them? It shows as being sent in the wallet and they deducted the coin immediately. Also not sure about B. I just checked the box that said to deduct the fee which in the Core wallet said was estimated to be .00002 or something.

Could you give me the transaction ID or raw transaction hex? I think somehow your bitcoin core is blocking you from broadcasting the tx. ( Check if you're connected to a node.

Also, the Bread wallet showed how much the transaction is worth even though I never gave it the amount, only the address. The coin even appeared in my wallet for a few minutes before it vanished. So they obviously recognized this at least temporarily.

f095e4d01ee07e03c3a075f33da5ce3bb88958e343c5a3fa283b6f92411f8e60

that is the ID for one of the transactions. if you can provide directions on how to make sure it broadcasted please let me know. I'll happily send you $50 worth of bitcoin if you can solve this for me.

Open up the RPC console and then you try abandontransaction f095e4d01ee07e03c3a075f33da5ce3bb88958e343c5a3fa283b6f92411f8e60, then resend/rebroadcast it? If that doesn't do it Then use -zapwallettxes

I don't know how to do that. Can you explain? I am on a Mac.

Click Help -> Debug -> Console

Can you be more specific? Is this code I am supposed to enter? Not sure exactly where to put it.

Go to the mac terminal, close your bitcoin core, and run, bitcoin-qt -zapwallettxes, then restart your bitcoin core.

i had to leave so I can't restart the wallet until i get home later tonight. but when i put this code into the Terminal it says command can not be found

You'll need to go into the /Applications/ where you located bitcoin core

I don't see where to enter that code in the Applictions

I found all the blockchain transactions in that Applications file.


text:
How to unlock colored coin?
In chapter 12 in Mastering Bitcoin it is talking about bitcoin application and one of them is colored coins.
There is an example for colored coin output:

The second one is colored coin output. It is just a "OP_RETURN {some encoded value}". I understand that in the output, we can decode and get some information, but how can they transfer assets represented by the encoded value to others?
Because there is no signature or other information in the output can be used as a unlocking script, the output, whatever it is, cannot be certified as it is owned by someone.

Why there is no signature information in output?
Can you give an example or a real colored coin output?

bitcoin wiki states that
OP_RETURN:

"[...]Marks transaction as invalid. A standard way of attaching extra data to transactions is to add a zero-value output with a scriptPubKey consisting of OP_RETURN followed by exactly one pushdata op. Such outputs are provably unspendable, reducing their cost to the network[...]"

There's no point in a signature of an unspendable output I guess but I might be wrong here.
I found chapter 7 of mastering bitcoin helpfull where it explains the
"Data Recording Output (RETURN)."
Also check this blog post for a different spin on it.
I'm very interested in the colored coins idea but noticed that active implementations are rare from what I could find.
Coindesk reported coinprism shut down in 2018 and the underlying protocol open asset hasn't had any commits in years.
Same goes for colored coins by Colu github repo.  Colu announced a colored coin lightning integration in 2016 which I'm also starting to investigate as an alternative but their demo site is also down.
Counterparty makes use of op_return so you might want to check that out.
You should also check out this post which gives a colored coin example for the  Omni Layer that @Murch mentioned in his answer.

Colored coins are second layer networks that run another protocol on top of the Bitcoin (or another) blockchain. While they transmit the full transaction information within their network, they don't use their own blockchain. Rather, they anchor their transactions into OP_RETURNs on the carrier chain for confirmation. Instead of spending such an OP_RETURN directly, the recipient may craft another OP_RETURN that references previous payment outputs and proves authorization to spend.
Nodes of the colored coin network understand both the colored coin network's messages and consume the Bitcoin blockchain to infer the network state. When the recipient of such a colored coin transaction wants to spend their funds, they encode another message into an OP_RETURN.
Colored coins can be used to represent other assets such as stocks or property.
A current example of such a network is Omni Layer which to transact with Tether. Omni Layer spans its network using Omni Core, an extended variant of Bitcoin Core.


text:
What is transaction not found on blockchain mean? Does that mean transaction still waiting in mempool, unconfirmed or never broadcasted on blockchain?
I requested from my exchange (GEMINI) to withdraw bitcoin and send to my another exchange (BITTREX) on 11/11/17, four days ago. I have still not received my bitcoin at BITTREX receiving exchange; the transaction does not show in pending at receiving exchange.
Gemini exchange transaction history shows a withdrawal of bitcoin transaction with a link 'view transaction'. If I click on this link it takes me to https://insight.bitpay.com/ and shows "TRANSACTION NOT FOUND". I also searched in blockchain.info and some other explorers all show transaction not found.
So far not much luck from Gemini support. I am getting desperate with Gemini.
Here is the transaction ID;
e1e405bdd06b3ab23c3099f41f5da58ea0f5cf0bd2f891850c1d5c70fedfdb20
What is happening with this transaction?  What does "transaction not found" mean?

Is this waiting in miner's mempool to be picked up?
Is this unconfirmed and already dropped from the blockchain network.
Transaction have some error to start with and never broadcasted on blockchain network?
None of the above and have some other issue?

Is this waiting in miner's mempool to be picked up?

No. Broadcasted transactions are visible on block-explorer sites (in most cases)

Is this unconfirmed and already dropped from the blockchain network.

It is unconfirmed, but not because already dropped, but because not yet broadcasted

Transaction have some error to start with and never broadcasted on blockchain network?

May be. Only sender knows the correct answer

None of the above and have some other issue?

If it is not seen - it does not exist. Point.

I think probably this transaction never got broadcasted on the network for some reason. I will keep pressing the Gemini Exchange, hopefully one day they will look into this matter. Thanks again.

This kind of problem can also occur if you get confused about which blockchain/cryptocurrency you are working with.
eg if you try sending BCH to a BTC address, the transaction will show up on a BCH block explorer, but not a BTC one.
At the time of writing, the given transaction id is now showing 20 confirmations from blockchain.info so it looks like you're good to go.